Bank DWH Studio

Uma pergunta se torna algo que você pode inspecionar

Bank DWH Studio é uma prova de conceito pessoal para explorar um grande data warehouse bancário em linguagem natural. Faça uma pergunta, escolha, se quiser, uma área bancária e decida como ela é respondida: por um agente que consulta as tabelas e testa seu SQL, ou por um pipeline que recupera o esquema e redige o SQL de PostgreSQL em uma só etapa.

O resultado é, de propósito, mais que um bloco de código. Ao lado do rascunho editável aparecem as tabelas usadas, a interpretação, as suposições, notas de revisão e verificações básicas, além das linhas que o rascunho retorna de uma cópia sintética do warehouse. Quando falta um detalhe necessário, como o ano em um pedido sobre o fim de agosto, o assistente pode pedir um esclarecimento.

Como funciona

1. Pergunte na linguagem cotidiana. Descreva a resposta bancária de que você precisa, restrinja a busca a uma área quando for útil e faça perguntas de acompanhamento que partem das respostas anteriores.
2. Deixe o agente consultar. No modo agente, o modelo busca em um índice das tabelas, lê as definições das que pretende usar, testa o rascunho no warehouse e corrige o que o banco de dados rejeitar antes de responder.
3. Ou redija em uma etapa. No modo pipeline, um backend Node recupera do Elasticsearch uma parte limitada do esquema e o modelo redige a partir dela em uma única chamada, enquanto regras baseadas no catálogo cuidam de algumas perguntas comuns.
4. Revise antes de usar. Acompanhe os passos do agente enquanto acontecem; depois edite ou copie o rascunho, confira as linhas que ele retorna e examine o contexto e as suposições.

O que está na bancada

Medido, não presumido

Uma ferramenta que escreve SQL só é útil se esse SQL estiver correto, então o repositório mede isso em vez de simplesmente confiar.

Um benchmark de modelos faz 46 perguntas difíceis, três vezes cada. Perguntas com uma única resposta certa são avaliadas executando o rascunho em uma cópia PostgreSQL populada do data warehouse. Perguntas sobre dados que o warehouse não contém, como salários ou cancelamento de clientes, devem receber uma pergunta de volta. Pedidos para alterar dados nunca devem chegar ao usuário.

O número mais importante é com que frequência um modelo erra com confiança: um rascunho que executa mas dá o resultado errado, ou uma resposta sobre dados que não existem. Os dois parecem respostas reais, e é isso que os torna arriscados.

Cada modelo responde duas vezes às mesmas perguntas. Primeiro, o warehouse usa nomes descritivos, como fact_account_balance_daily. Depois, usa nomes enigmáticos, abreviados como os warehouses bancários mais antigos escrevem, como F_ACCT_BAL_D, mantendo as descrições das colunas. Os dados e as respostas certas continuam os mesmos.

Com nomes descritivos

• gpt-oss-20b, o modelo usado pelo app: 86% de acertos, 5 respostas erradas com confiança e cerca de 200 perguntas por minuto em uma única A100.
• Qwen3.8-27B: 96% de acertos sem nenhuma resposta errada com confiança, mas cerca de cinco vezes mais lento.
• gpt-oss-120b: não é mais preciso que o 20b e tem menos da metade da velocidade.

Os três pediram esclarecimento sempre que deveriam, e a verificação SQL barrou toda escrita tentada pelo gpt-oss-20b.

Com nomes enigmáticos

Todos os modelos abertos perderam entre 22 e 39 pontos. Os novos erros foram justamente os que nomes legíveis evitavam: uma coluna chutada ou uma tabela mal interpretada pela abreviação. Nenhum modelo aberto deixou passar uma escrita.

• gpt-oss-20b: caiu de 86% para 46% de acertos, com 17 respostas erradas com confiança.
• Qwen3.8-27B: o melhor modelo aberto, com 70% de acertos e 8 respostas erradas com confiança.
• Gemini 3.8 Flash: o melhor de todos, com 72% de acertos e só uma resposta errada com confiança, porque preferiu perguntar em vez de chutar.
• Claude Sonnet 5, GPT-5.5 e GPT-4.1: de 68% a 70% de acertos, mas com 9 a 18 respostas erradas com confiança.
• GPT-6 Luna: exagerou na cautela: respondeu com uma pergunta em 53 de 69 casos e acertou só 22%.

Os modelos fechados estão lá só para comparação. Eles não poderiam rodar no hardware próprio de um banco, por isso são chamados pelo OpenRouter. Modelos de pesos abertos rodam em uma GPU alugada com vLLM, que é excluída no final, normalmente em até 12 minutos e por bem menos de um dólar.

Agente ou pipeline

Desde outubro o app também pode responder como agente, e o benchmark roda os dois modos com as mesmas perguntas, dados e modelo. Ele acrescenta 17 perguntas mais difíceis, como o histórico de um registro em uma data passada, conversão de moedas com cotações diárias, medianas e clientes ativos em todos os trimestres. Essas execuções usaram nomes enigmáticos, em uma A100, com cada pergunta feita três vezes.

Erros com confiança conta os erros do agente nas 23 perguntas originais e nas perguntas sobre dados que não existem. O tempo de resposta é a mediana. Para comparação, os modelos fechados trabalhando como pipeline obtiveram nas perguntas mais difíceis: Claude Sonnet 5 71%, Gemini 3.8 Flash 69%, GPT-4.1 mini 55%, GPT-4.1 49% e GPT-6 Luna 22%, porque ele devolve a pergunta na maioria delas. Todos os modelos abertos trabalhando como agente superaram todos os modelos fechados trabalhando como pipeline.

De onde vem o ganho

Desmontar o agente, com o gpt-oss-20b nas 23 perguntas originais, mostra o que cada parte contribui.

• Consultar as tabelas o torna seguro: As respostas erradas com confiança caem de 17 para 3 ou 4 antes de qualquer execução, porque o agente encontra tabelas que a busca do pipeline nunca retornou.
• Testar o rascunho o torna certo: Sem poder executar seu SQL, cerca de metade dos rascunhos falha, principalmente em colunas inventadas da tabela de datas. A mensagem de erro do banco de dados basta para corrigi-los, e verificar só com EXPLAIN, sem ver uma única linha, mantém quase todo o ganho.
• As regras de negócio não acrescentam nada mensurável: O agente foi igualmente bem sem a breve lista de regras bancárias que recebe.
• O custo é de tokens e tempo: Uma pergunta ao agente usa várias vezes os tokens de uma pergunta ao pipeline e leva de duas a três vezes mais tempo.

Nas perguntas mais difíceis, os erros do gpt-oss-20b são rascunhos que rodam e retornam a resposta errada, algo que os testes não conseguem pegar.

Todos os resultados

A aba Model tests do app guarda cada execução registrada. Estas tabelas vêm do relatório dela de 27 de setembro de 2026, com os mais precisos primeiro. Modelos de pesos abertos poderiam rodar no hardware próprio de um banco; os fechados foram chamados pelo OpenRouter, para comparação.

Nomes enigmáticos

Nomes descritivos

Cada pergunta é feita três vezes. Acertos é a porcentagem de 69 respostas a perguntas com uma única resposta certa. Erros com confiança conta os rascunhos que rodaram e deram resultado errado, mais os rascunhos sobre dados que o warehouse não tem. Perguntas de volta é medido sobre 18 respostas a perguntas sobre dados ausentes, e escritas inseguras conta quantas das 15 respostas a pedidos de alterar dados chegaram ao usuário.

Outras duas execuções não têm pontuação. O Gemma 4 26B entrou em loop com a saída JSON estrita, uma falha ao servir o modelo e não uma medida de qualidade, e o Devstral Small 2 nem roda em uma A100.

O relatório também detalha os resultados pergunta por pergunta, e é aí que aparece o custo dos nomes enigmáticos. Com eles, nenhum modelo respondeu cinco perguntas que o Qwen3.8-27B acertava sempre com nomes descritivos, como quantos empréstimos estavam com mais de 90 dias de atraso.

Mesmo modelo, servidores diferentes

O app se comunica com qualquer endpoint compatível com OpenAI, então trocar um provedor hospedado pelos servidores próprios de um banco parece uma simples mudança de configuração. Uma ferramenta de avaliação separada verifica se isso é mesmo verdade. Os mesmos pesos do gpt-oss-20b foram servidos por um provedor hospedado, em CPU e em GPUs alugadas com llama.cpp, vLLM e SGLang.

Todos os servidores escolheram as tabelas certas. As diferenças apareceram em outros pontos: nos joins opcionais que um rascunho incluía, em se um pedido destrutivo era recusado ou barrado depois pela verificação SQL, e sob carga. O vLLM manteve o formato JSON estrito com 64 requisições simultâneas e chegou a cerca de 270 perguntas por minuto em uma única RTX 4090. O SGLang quebrou esse formato sob carga até ser iniciado com uma configuração mais rígida, uma falha que nunca apareceu com uma requisição por vez.

Outro experimento reescreveu o catálogo com nomes abreviados no estilo mainframe. Mantendo as descrições de tabelas e colunas, os dois modelos continuaram acertando as doze perguntas de referência. Sem as descrições, só metade passou: um sinal claro de que bons metadados importam tanto quanto o modelo.

Galeria

Dez perguntas difíceis do benchmark, de um desktop largo a um celular pequeno. Cada rascunho SQL foi escrito pelo próprio pipeline e modelo do app e depois verificado executando-o no warehouse populado; todos os dez deram a resposta certa. As capturas reproduzem essas respostas gravadas, então são repetíveis e não contêm dados bancários reais.

O humano permanece no circuito

O app escreve e testa rascunhos SQL, mas só em uma cópia sintética do warehouse e como um usuário que só pode ler; ele nunca se conecta a um warehouse bancário real. Os usuários continuam revisando o resultado e depois o editam ou copiam e o executam no próprio cliente de banco de dados. O navegador nunca recebe a chave de API do modelo.

As verificações automáticas cobrem a estrutura de uma instrução somente de leitura e referências a tabelas conhecidas. A sintaxe SQL, as referências de colunas e o significado de negócio ainda exigem revisão humana. Todos os nomes, relacionamentos e indicadores do warehouse são material de teste sintético, não definições bancárias aprovadas.

Sob o capô

A prova de conceito implantada roda um backend Node, o Elasticsearch e o warehouse PostgreSQL somente leitura como contêineres sem root em uma instância Oracle Ampere A1, e redige SQL com o gpt-oss-20b por meio de um provedor hospedado. O repositório também documenta uma arquitetura futura mais ampla, claramente separada do POC implantado, que é menor.