Benchmark BIRD: A Lacuna de Bancos de Dados Reais em LLM Text-to-SQL

O benchmark BIRD (NeurIPS 2023 Spotlight) é o artigo que sempre pretendo ler quando alguém argumenta que o GPT-4 pode "consultar um banco de dados em inglês comum". Ele faz uma pergunta direta: os LLMs podem realmente servir como uma interface de banco de dados em bancos de dados reais, e não em esquemas acadêmicos de brinquedo? A resposta é sóbria de formas que se mapeiam quase diretamente ao que uma camada de consulta em linguagem natural para livros contábeis do Beancount enfrentaria.

O artigo

"Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs", de Jinyang Li e uma grande equipe da DAMO Academy, HKU, UIUC e outros, apresenta o BIRD: 12.751 pares de pergunta-SQL em 95 bancos de dados reais, totalizando 33,4 GB em 37 domínios profissionais. Essa escala é o ponto central. Spider e WikiSQL, os dois benchmarks que dominavam a pesquisa de text-to-SQL antes deste, usam bancos de dados pequenos e limpos com, no máximo, algumas centenas de linhas. O BIRD utiliza bancos de dados extraídos de instituições reais — registros financeiros, relatórios toxicológicos, conjuntos de dados governamentais — onde os valores são "sujos", a semântica das colunas exige conhecimento de domínio e a eficiência da consulta realmente importa. O artigo também introduz duas métricas: Acurácia de Execução (EX), que verifica se o resultado do SQL corresponde à resposta correta, e a Pontuação de Eficiência Válida (VES), que penaliza consultas corretas, porém lentas.

Ideias principais

• O GPT-4 alcança apenas 54,89% de acurácia de execução no conjunto de testes quando fornecido com evidências de conhecimento externo curadas. Sem essa evidência, cai para 34,88% — uma lacuna de 20 pontos percentuais que revela o quanto o modelo se apoia nas dicas fornecidas em vez de seu próprio conhecimento de mundo.
• O desempenho humano está em 92,96% no conjunto de desenvolvimento, deixando uma lacuna de 38 pontos mesmo após o GPT-4 receber o contexto de domínio das respostas.
• O conhecimento externo é fornecido como uma "sentença de evidência" por pergunta (ex: "account.type = 'OWNER' significa que o titular da conta é o proprietário principal"). Modelos que não conseguem recuperar ou inferir esse contexto por conta própria estão, essencialmente, prejudicados desde o início.
• O domínio financeiro, que é o mais relevante para o Beancount, apresenta a maior taxa de ruído de anotação: uma auditoria de acompanhamento descobriu que aproximadamente 49% dos pontos de dados do domínio financeiro contêm algum erro — erros de ortografia, perguntas ambíguas ou consultas SQL incorretas.
• O ranking (leaderboard) mudou consideravelmente desde a publicação. Em 2026, o sistema líder (AskData + GPT-4o) atinge 81,95% no conjunto de testes, com o desempenho humano ainda em ~92,96%, mas a lacuna foi fechada principalmente por meio de pipelines multi-etapas elaborados, e não pela capacidade bruta do modelo.

O que se sustenta — e o que não

A contribuição principal se sustenta: benchmarks no estilo Spider genuinamente subestimaram a dificuldade de text-to-SQL ao usar esquemas sanitizados. A insistência do BIRD em valores de bancos de dados reais e conhecimento externo revela modos de falha que nunca aparecem em dados limpos, e a variação de 20 pontos percentuais ao adicionar evidência de conhecimento é uma descoberta reprodutível e importante.

Mas o benchmark possui uma falha de design que seu próprio trabalho de acompanhamento reconhece. A evidência de conhecimento externo é escrita à mão, por consulta, por anotadores com expertise no domínio. Esse não é um cenário de implantação realista. Um agente NL-para-SQL real não recebe uma dica pré-escrita para cada pergunta; ele deve recuperar ou inferir o contexto de domínio relevante por si mesmo. O artigo SEED (2025) mostra que evidências geradas automaticamente podem igualar ou superar evidências escritas à mão em alguns cenários, o que enfraquece a suposição implícita do BIRD de que o gargalo do conhecimento é a parte difícil.

A auditoria de ruído é mais prejudicial. Vinte e duas consultas SQL no conjunto de dados estão totalmente erradas. Quando corrigidas, as classificações dos modelos mudam: o GPT-3.5 zero-shot supera o DIN-SQL e o MAC-SQL, que foram projetados para vencer o GPT-3.5 no benchmark não corrigido. Isso é um sinal de alerta. Um benchmark cujas classificações se invertem após uma limpeza está nos ensinando tanto sobre artefatos de anotação quanto sobre a capacidade do modelo. A taxa de ruído de 49% do domínio financeiro, em particular, torna as conclusões específicas desse domínio pouco confiáveis.

Há também uma questão mais sutil com o VES. Recompensar a eficiência da consulta é um objetivo sensato no mundo real, mas para que um benchmark treine e avalie a eficiência, é necessária uma verdade fundamental sobre o que "eficiente" significa para um mecanismo de banco de dados e distribuição de dados específicos. O VES funciona aqui porque o BIRD controla o ambiente de execução. Essa condição não se aplicaria a um agente Beancount executando o beanquery contra o livro contábil pessoal de um usuário em hardware heterogêneo.

Por que isso importa para a IA nas finanças

A linguagem de consulta do Beancount, BQL (exposta através da CLI bean-query e da biblioteca beanquery), é sintaticamente próxima ao SQL: suporta SELECT, WHERE, GROUP BY, funções de agregação e joins entre as tabelas integradas de lançamentos (postings) e saldos. Uma interface de linguagem natural que traduz perguntas do usuário em BQL é a porta de entrada mais natural para usuários não técnicos, e as descobertas do BIRD enquadram diretamente esse desafio.

O problema do conhecimento externo no BIRD se mapeia perfeitamente ao Beancount. Um usuário pode perguntar "quanto gastei com despesas médicas no ano passado?" e o agente precisa saber que os custos médicos do usuário vivem sob Expenses:Health:* ou Expenses:Medical, dependendo de como ele organizou suas contas. Esse mapeamento é pessoal, não está em nenhum corpus de treinamento. A descoberta do BIRD de que o GPT-4 perde 20 pontos sem evidência sugere que qualquer agente de geração BQL precisa de uma etapa de recuperação que aprenda a própria taxonomia de contas do usuário — essencialmente uma base de conhecimento por usuário.

O problema dos dados sujos também se mapeia diretamente. Transações bancárias importadas frequentemente possuem nomes de estabelecimentos inconsistentes, artefatos de OCR e codificações mistas. O BIRD quantifica o custo disso em termos de correção de SQL, e o número é grande o suficiente para tornar o pré-processamento uma preocupação de primeira classe, em vez de uma reflexão tardia.

O que o BIRD não cobre: construtos específicos de livros contábeis, como asserções de saldo, diretivas pad ou lançamentos multimoeda, não têm equivalente no SQL padrão, portanto, qualquer agente BQL enfrentará uma camada de complexidade que o BIRD não mede. O benchmark é um limite inferior útil, não um teto.

O que ler a seguir

• Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (arXiv:2502.04306, ICLR 2025 Oral) — estende o BIRD para ambientes corporativos com bancos de dados em nuvem e fluxos de trabalho de múltiplos arquivos; o próximo passo natural para entender as lacunas de implantação no mundo real.
• SEED: Enhancing Text-to-SQL Performance and Practical Usability Through Automatic Evidence Generation (arXiv:2506.07423) — aborda diretamente a suposição de evidência escrita à mão do BIRD com um pipeline automatizado.
• DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction (arXiv:2304.11015, NeurIPS 2023) — uma das principais referências do BIRD; mostra como decompor uma consulta SQL complexa em subproblemas melhora a acurácia, uma técnica diretamente aplicável a consultas BQL multi-etapas em livros contábeis do Beancount.