Benchmarks Públicos Diziam 90%. Em Quatro Warehouses Reais, o LLM Tirou Zero.

Um modelo de linguagem puro, apontado para quatro data warehouses corporativos reais e encarregado de responder perguntas que usuários de negócio de fato fizeram, produziu acurácia zero.

O número vem do Beaver, um benchmark de text-to-SQL construído por Michael Stonebraker, professor do MIT e ganhador do ACM A.M. Turing Award de 2014, junto com Peter Baile Chen, doutorando do MIT CSAIL. Nos leaderboards públicos que fornecedores citam em deck de vendas, a mesma tarefa parece resolvida. O Spider 1.0 fica na faixa de 80 e poucos por cento. O BIRD-SQL reporta acima de 90 por cento. Soluções agênticas no Spider 2.0 também passam de 90 por cento.

Uma distância de noventa pontos ultrapassa em muito o que arredondamento ou ajuste fino explicariam. Ela sinaliza que os benchmarks públicos medem uma tarefa que não existe dentro da sua empresa.

Como o Beaver Foi Construído

A metodologia é a parte interessante, porque qualquer empresa consegue reproduzi-la em uma semana.

Stonebraker e Chen partiram do próprio data warehouse administrativo do MIT: um sistema Oracle com mais de 1.400 tabelas. Extraíram consultas reais do log de produção. Depois pediram a usuários de negócio reais que escrevessem a pergunta em linguagem natural que cada consulta respondia. O resultado é um conjunto de pares (linguagem natural, SQL de referência) em que as duas metades saíram da organização, não da imaginação de quem escreve benchmark. O exercício foi repetido em três outros warehouses.

Nada nesse procedimento exige laboratório de pesquisa. Você tem log de consultas. Tem usuários de negócio. Tem um warehouse cujo schema ninguém entende por completo. O benchmark que sai desses três ativos vale mais do que todos os leaderboards públicos somados, porque é o único que mede o seu warehouse.

A Escada da Acurácia

O artigo reporta uma progressão, e o formato dela importa mais do que qualquer número isolado.

Um LLM puro tirou zero. Somar RAG, engenharia de prompt e andaime agêntico levou a acurácia para a faixa de 10 e poucos por cento. Em seguida os autores fizeram algo que nenhum sistema em produção consegue fazer: entregaram ao modelo as tabelas do from-clause e as cláusulas de join reais, extraídas do SQL de referência. Com a parte mais difícil do problema resolvida de antemão, o modelo chegou à faixa de 30 e poucos por cento.

O modo como os autores enquadram esse teto merece citação: “Note that this is 50+% lower in accuracy that the public benchmarks and is the difference between the technology has promise and the technology does not work.” (O erro de digitação está no original.)

Leia a escada como diagnóstico. De zero a dez é o que ferramental compra. De dez a trinta é o que conhecimento de schema compra, e ele foi contrabandeado do gabarito. Ninguém demonstrou ainda o que fecha de trinta a noventa em um warehouse real.

Por Que Warehouses Reais Quebram o Modelo

Quatro propriedades dos repositórios de produção explicam o colapso, e cada uma é artefato de governança antes de ser problema de modelagem.

Apodrecimento de schema. Os autores dão um exemplo concreto: pode haver seis colunas diferentes, em tabelas variadas, todas chamadas salary, com semânticas sobrepostas e não documentadas. Uma pode ser líquido depois de impostos e comissões. Outra pode ser bruto. Um analista humano resolve isso perguntando ao colega que está na casa há oito anos. Um modelo resolve chutando. Mudanças de schema entram várias vezes por ano, então qualquer documentação que existisse já nasce vencida.

Dados idiossincráticos. O calendário do MIT inclui um “J-term”. Os prédios são numerados em vez de nomeados, e por isso o Stata Center é oficialmente o Building 32. Nenhuma quantidade de conhecimento geral de mundo recupera esse mapeamento. Toda empresa tem a sua versão: um código de produto que só significa algo para o financeiro, uma flag de status cujo quarto valor foi criado para uma migração de 2019 e nunca removido.

Complexidade das consultas. Consultas reais “raramente têm apenas um join, e frequentemente têm dois ou três”. As consultas de benchmark tendem a ser mais simples. Seleção de join é exatamente onde o modelo precisou do gabarito.

Contaminação estrutural. Esta é a parte que deveria reformular a conversa de compras por inteiro. Nas palavras dos autores: “It is widely known that an LLM can only find data it has seen before. Almost all data warehouses we know about are behind serious enterprise access controls and are not publicly available.”

A reflexividade aí incomoda. A governança de acesso que você construiu para proteger o warehouse é a mesma razão pela qual nenhum modelo de fronteira foi treinado em algo que se pareça com ele. Quanto melhores os seus controles, mais longe o seu schema fica da distribuição de treino, e pior um modelo de propósito geral se comporta contra ele. Maturidade de governança e acurácia de text-to-SQL fora da caixa andam em direções opostas.

Já argumentamos que agentes herdam a camada de dados que os humanos vinham absorvendo em silêncio, e que a camada semântica deixou de ser assunto de BI. Os dois argumentos eram qualitativos. O Beaver fornece a quantidade: o custo de semântica não documentada, expresso em acurácia, é de cerca de sessenta pontos percentuais.

O Modo de Falha Silencioso

Um agente de geração de código que erra normalmente se denuncia. Testes ficam vermelhos, o build quebra, o linter reclama.

Um agente de text-to-SQL que erra devolve um número. O número tem o tipo certo, magnitude plausível e um gráfico em volta. Ele segue para um deck de conselho. Ninguém vê stack trace, porque não houve erro: o SQL era válido, apenas fez join na coluna salary errada.

Por isso a acurácia aqui é número de governança antes de ser número de qualidade de produto. Com 30 por cento de acurácia e nenhum sinal de erro, cerca de duas de cada três respostas que chegam a um tomador de decisão estão erradas e são indistinguíveis do terço correto. É o mesmo formato de falha que descrevemos em o muro da competência de domínio: a saída do modelo é fluente em um domínio onde fluência e correção não têm correlação. E é por isso que métricas de artefato são burladas enquanto testes de resultado resistem se aplica diretamente. Nota de leaderboard é métrica de artefato. O seu log de consultas é o teste de resultado.

Uma divulgação antes da recomendação: Stonebraker e Chen construíram tanto o Beaver quanto o Rubicon, o sistema alternativo que passam a recomendar. Eles têm interesse na conclusão de que LLMs puros falham. A metodologia é reproduzível de forma independente, e isso é o que torna o achado utilizável qualquer que seja o interesse comercial dos autores. Verifique no seu próprio warehouse e os incentivos deles deixam de importar.

Faça Isto Agora

Construa o seu próprio Beaver. Duas semanas, um analista, nenhum fornecedor envolvido.

Extraia as 100 consultas mais executadas do log de produção do seu warehouse, com peso maior para tudo que alimenta relatório recorrente.
Peça aos usuários de negócio donos desses relatórios que escrevam, em linguagem simples, a pergunta que cada consulta responde. Não deixe um engenheiro escrever isso; a formulação é o teste.
Congele esse conjunto como pares (pergunta, SQL de referência). Esse é agora o seu benchmark privado, e por construção ele não vaza para o treino de ninguém.
Rode todo fornecedor de text-to-SQL e todo protótipo interno contra ele. Pontue equivalência de resultado de execução, não similaridade de string de SQL.
Coloque o número resultante no documento de compras. Torne a nota publicada do fornecedor irrelevante para a decisão.

A regra de compras dos autores é mais direta do que qualquer coisa que escreveríamos: “any text-to-SQL benchmark should address the difficulties of real-world data stores. Those that do not are of academic interest only and do not reflect reality.”

Há uma segunda alavanca escondida na escada. Os dez a trinta por cento vieram de resolver semântica de schema. Isso significa que documentação de schema passa a ter preço mensurável, expresso em pontos de acurácia em um benchmark que você controla. Cada ano em que seis colunas chamadas salary seguem sem documentação tem um número ao lado. Leve esse número a quem se recusa a financiar trabalho de governança de dados.

Fontes

BLOG@CACM. “If You Think You Can Do Real-World Text-to-SQL.” Michael Stonebraker (MIT) e Peter Baile Chen (MIT CSAIL), 2026.
Beaver. “Benchmark e leaderboard públicos.” 2026.

A Victorino ajuda times de dados e engenharia a construir benchmarks privados a partir dos próprios logs de consulta antes de assinar contrato de analytics com IA: contato@victorino.com.br | www.victorino.com.br