Text-to-SQL: Comparação da Precisão de LLM
Executamos 36 grandes modelos de linguagem em 759 perguntas do BIRD-SQL, cada modelo escrevendo SQL contra um banco de dados que ele mesmo teve de identificar dentre 11 candidatos. Toda consulta analisável foi executada no banco de dados real e seu conjunto de resultados comparado com o da consulta de referência do BIRD. Consultas ausentes, malformadas ou com falha de execução foram contabilizadas como erros.
Todas as execuções foram feitas com temperatura 0, zero-shot, sem a dica de domínio do BIRD. Dezenove das 36 execuções usaram a camada de recuperação de chamada de ferramenta descrita na página de roteamento, que analisa chamadas de ferramenta que o analisador padrão rejeita. Quinze execuções são anteriores e duas ficam no meio da mudança.
Métricas explicadas
Correspondência de execução estrita. Correspondência de execução sobre as perguntas que o modelo roteou corretamente. Condicionar à rota correta elimina as falhas diretas por banco de dados errado, mas não isola totalmente a capacidade de SQL, porque cada modelo atinge um subconjunto diferente de perguntas.
Gold-clean. A mesma medição com as perguntas cuja SQL de referência consideramos defeituosa removidas do denominador. Essas perguntas não são contadas como acertos, são removidas.
Adjudicado. O limite superior. Um júri cego de três modelos, escolhidos de famílias diferentes do modelo em teste, revisa toda resposta que a comparação estrita rejeitou, onde o modelo roteou corretamente, o SQL é executado, e suas linhas sobrepõem as da referência em menos da metade. Ele decide se a consulta é uma formulação diferente mas equivalente, se a referência está errada ou se o modelo está errado. Respostas equivalentes e referências defeituosas são creditadas.
Todas as três partem do conjunto completo de 759 perguntas, não apenas do subconjunto difícil, e nenhuma delas usa 759 como denominador. Cada uma é medida sobre as perguntas que o modelo roteou corretamente, e a coluna gold-clean então remove as referências sinalizadas. O acaso não se aplica a este eixo, pois uma consulta ou retorna o conjunto de resultados de referência ou não.
Resultados do benchmark Text-to-SQL
Respostas corretas em formato errado custaram a um modelo 22,7 pontos
claude-sonnet-5 registra 0.311 na correspondência de execução estrita, 33º entre os 36 modelos e o mais baixo de qualquer linha da Anthropic. Sob adjudicação cega, a mesma execução marca 0.710, 0.007 abaixo dos 0.717 do qwen3.6-27b.
O ganho de 39,9 pontos se divide em duas partes. 154 das suas 679 perguntas pontuadas, 22,7 pontos, são respostas que o júri considerou equivalentes à referência, mas em formato diferente. Outras 117, 17,2 pontos, são perguntas em que o júri considerou a própria referência defeituosa. O estilo de resposta explica a primeira, não a soma. Falhas do ambiente não explicam nada, pois a execução não registrou consultas ausentes, teve uma falha e nenhuma resposta não recuperada.
Essas mesmas 154 respostas representam 34% dos 453 erros do sonnet-5 que chegaram à adjudicação. Formato equivalente significa que a consulta retorna a informação correta em uma projeção diferente, uma coluna extra, uma ordem de colunas diferente, ou uma contagem onde a referência retornou as linhas. A correspondência de execução estrita pontua isso como falha.
A tendência segue por família de modelos, não por nível de capacidade. Famílias com projeções ricas perdem de um quarto a um terço de seus erros adjudicados dessa forma: Claude 25 a 34%, Kimi 24 a 34%, a linha de raciocínio 5.x da OpenAI 26 a 32%, DeepSeek 31%, MiniMax 26 a 30% e GLM-5.x 28%. Modelos que escrevem no formato da referência perdem muito menos: Google 9 a 17%, Llama 9%, Mistral 18%, Grok 19% e os modelos pequenos da OpenAI 19 a 20%. Grok quebrou nossa primeira explicação desse padrão. Ele está no nível de raciocínio e perde 19%.
A medição adjudicada coloca o sonnet-5 em 17º, uma diferença de 16 posições.
O júri constata que 46% das respostas rejeitadas de um modelo não são erros do modelo
Apanhamos 314 das 346 respostas que a comparação estrita rejeitou para o gemini-3.5-flash-lite nas perguntas que ele roteou corretamente, aquelas cujo SQL foi executado e cujas linhas sobrepuseram as da referência em menos da metade, e as enviamos ao júri cego de três modelos com ordem embaralhada. Essas 346 abrangem todos os níveis de dificuldade, não apenas os difíceis, portanto correspondem à população coberta pelas colunas de SQL.
O júri as classificou em quatro categorias. Defeito na referência, onde o modelo está certo e a consulta de referência do BIRD está errada, representou 29,3%. Formato equivalente 16,6%, erro genuíno do modelo 33,4% e ambíguo 20,7%. Somando as duas primeiras, 144 dos 314 erros adjudicados (46%) não são erros do modelo. Essa proporção é sobre os 314 que chegaram ao júri, não sobre todas as 346 respostas rejeitadas. As 32 excluídas ou falharam na execução ou sobrepuseram demais a referência para serem uma discordância clara.
A rigidez do comparador não explica a diferença. Flexibilizar a correspondência de ordem das colunas agrega 0,5 pontos, e 92% dos erros sobrepõem o resultado de referência em menos de 0,5. A adjudicação, em vez de um comparador mais flexível, coloca esse modelo em uma faixa de 0.606 a 0.687, contra um estrito 0.464.
Os erros que o júri classificou como defeito na referência concentram-se onde nenhuma correção publicada alcança: 33% dos erros da divisão de treino deste modelo contra 20% dos erros da divisão de desenvolvimento. Toda correção determinística disponível já foi aplicada. Reavaliar contra a versão corrigida de desenvolvimento do próprio BIRD virou 0 de 92 erros de desenvolvimento; um conjunto externo de correções cobriu 39 deles e virou 1; e uma auditoria de engines MySQL contra SQLite encontrou 4 referências divergentes em todo o conjunto, juntas cerca de 1% dos 314.
Nossa auditoria com cinco modelos sinaliza 31,1% das consultas de referência do BIRD como defeituosas
Auditamos a própria referência. Cinco modelos de ponta, um por família, avaliaram todas as 759 consultas de referência em relação às suas perguntas e esquemas. Nenhum jurado viu a saída de qualquer modelo. O painel sinalizou 236 das 759 referências como defeituosas, 31,1%, a um custo de $20,55 e sem nenhuma chamada de júri falha.
A taxa se divide pelas partições do BIRD: 204 de 560 referências de treino (36%) contra 32 de 199 referências de desenvolvimento (16%). Um painel independente de três modelos executado anteriormente atingiu 29,1%, e 207 de suas 221 sinalizações de defeito, 94%, aparecem como defeituosas neste. Em todas as 759 perguntas, os dois painéis concordam em 92,9%.
Uma estimativa publicada cobre a divisão de treino do BIRD, a auditoria da MotherDuck em 151 exemplos, e coloca a taxa em 32,5%. As auditorias revisadas por pares do BIRD cobrem a divisão de desenvolvimento por design explícito, de modo que os 151 exemplos da MotherDuck são a única verificação externa sobre as 560 perguntas de treino em nosso conjunto congelado, 73,8% dele.1
Remover as referências defeituosas do denominador leva o melhor escritor estrito de 0.551 para 0.677, e os ganhos por modelo variam de +4,5 a +13,3 pontos. O topo mantém a ordem e os vizinhos do meio da tabela se movem em até três posições.
Um modelo de 27B ocupa o quinto lugar em precisão estrita de SQL
qwen3.6-27b registra 0.471 estrito e 0.590 gold-clean, quinto no painel atrás de gemini-3-flash-preview (0.551 / 0.677), gemini-3.1-pro-preview (0.536 / 0.669), claude-fable-5 (0.531 / 0.655) e claude-opus-5 (0.523 / 0.643). Todas as linhas da OpenAI, Kimi e DeepSeek registram uma pontuação estrita inferior, e a execução custou $15,28.
A coluna é medida sobre as rotas corretas de cada modelo, de modo que um roteador mais fraco é avaliado em uma seleção mais fácil. qwen3.6-27b roteia 0.679, e a seção de limitações mede esse efeito com uma correlação de 0,96 entre a precisão de roteamento e a dificuldade do denominador.
A ordenação muda quando se usa o extremo superior do intervalo. Nas pontuações adjudicadas, qwen3.6-27b é o décimo quarto com 0.717, enquanto claude-opus-5 lidera com 0.824.
Habilidade de roteamento e habilidade de escrita de SQL são eixos separados
kimi-k3 roteia 0.832, atrás de claude-opus-5 com 0.848 e empatado com qwen3.8-max, e escreve 0.482 de SQL gold-clean contra a melhor do painel, 0.677. gemini-3-flash-preview inverte isso, roteando 0.753 com aquele melhor SQL gold-clean do painel. gpt-5.6-terra roteia 0.772 e escreve 0.447.
Os dois eixos não são medidos no mesmo denominador. Cada modelo escreve SQL para as perguntas que roteou corretamente e apenas para elas, e os melhores roteadores ganham um conjunto mais difícil, o que reduz qualquer associação medida entre os eixos.
A auditoria da referência e o júri de adjudicação
Dois júris fizeram dois trabalhos diferentes.
O júri de validade da referência avalia as consultas de referência. Seus cinco jurados (claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5, deepseek-v4-pro) cada um vê uma pergunta, a SQL de referência e as listas de colunas das tabelas que essa consulta toca, e responde se a referência atende à pergunta. Nenhuma saída de modelo é mostrada. Seus veredictos são congelados em um arquivo com hash e alimentam a coluna gold-clean.
O júri de adjudicação avalia um erro específico de um modelo. Três modelos escolhidos de famílias diferentes do modelo em teste veem a pergunta, a consulta e o resultado de referência, e a consulta e o resultado candidatos, com posição embaralhada, e votam em qual das quatro categorias o erro pertence. Ele é executado por modelo a cerca de $6, e seus veredictos alimentam a coluna adjudicada. A adjudicação em todo o painel de 36 modelos custou $208,81.
A coluna adjudicada é um ponto final ajustado por adjudicação, otimista, e não uma verdade fundamental independente. Ela pode errar em ambos os sentidos. Uma resposta ambígua que estava de fato correta não recebe crédito, e um falso positivo do júri credita uma que não estava. Três propriedades medidas limitam o quanto ela pode ser forçada.
A revisão é assimétrica. Erros recebem uma segunda análise e acertos nunca, portanto um erro na direção de aprovação não pode ser detectado. Veredictos ambíguos, 15 a 23% dependendo do modelo, nunca são creditados, e quase-acertos e consultas que não executam permanecem como erros.
Ela não elimina o piso dos modelos fracos. Como controle negativo, adjudicamos o nova-lite-v1, a linha mais fraca do painel. Sua pontuação sobe de 0.190 para 0.316 e permanece 0.150 abaixo da linha seguinte. O piso se mantém em llama 0.466, mistral 0.509 e gpt-5.4-nano 0.512.
A proporção de defeitos de referência acompanha a força do modelo com uma correlação de postos de 0.906, medida em 33 modelos. Os erros do gpt-5.6-sol são 40% de defeito de referência e 19% de erro genuíno, enquanto os do llama-4-maverick são 13% e 50%.
Vinte e quatro dos 36 modelos alcançam ou ultrapassam 0,68 adjudicado.
Como a geração de SQL funciona neste benchmark
O modelo nunca recebe um esquema de antemão. Ele escolhe uma das 11 ferramentas de banco de dados, lê a lista de tabelas que retorna, solicita as colunas de uma tabela quando precisa e pode executar consultas exploratórias no banco de dados escolhido antes de se comprometer. A saída do esquema é limitada a 4.000 caracteres e os resultados da consulta a 50 linhas.
A consulta final chega em uma chamada de finalização obrigatória enviada sem ferramentas anexadas, junto com o banco de dados que o modelo declara. A pontuação executa essa consulta e a consulta de referência do BIRD no mesmo arquivo de banco de dados e compara os dois conjuntos de resultados, com um sentinela NULL e um modo sensível à ordem para perguntas que especificam uma ordem.
A comparação é a etapa estrita, e é aí que uma resposta correta pode ser pontuada como erro. Uma consulta que retorna as mesmas linhas com uma coluna extra, em uma ordem de colunas diferente, ou como uma contagem onde a referência retornou as linhas, falha na comparação. Essa é a lacuna que o júri de adjudicação mede, e não a que um comparador mais flexível fecharia, o que renderia 0,5 pontos.
Metodologia do benchmark para text-to-SQL
Este benchmark compartilha seu ambiente com o benchmark agentic RAG, que descreve a seleção de banco de dados, a taxonomia de dificuldade, a anonimização, o loop agentic e o orçamento de turnos por completo. Ambas as páginas reportam o mesmo subconjunto congelado de 759 perguntas do BIRD-SQL, executado em 11 bancos de dados que o modelo deve escolher, com temperatura 0 e sem a dica de domínio. A página de roteamento traz o eixo de roteamento, e esta página traz o eixo de SQL.
Pontuação: correspondência de execução. A consulta final do modelo e a consulta de referência do BIRD são ambas executadas no banco de dados real e seus conjuntos de resultados comparados, com um sentinela NULL e um modo sensível à ordem para consultas cuja pergunta especifica uma ordem. Denominador: perguntas que o modelo roteou corretamente. Forma de relato: um intervalo de três valores, correspondência de execução estrita, depois gold-clean, depois adjudicado. Auditoria da referência: 5 famílias de ponta, um modelo cada, 759 referências avaliadas, 236 sinalizadas como defeituosas, hash fixo. Adjudicação: 3 modelos por candidato, de famílias disjuntas do modelo em teste, cego e com posição embaralhada. Painel: 36 modelos, uma execução cada, $874,53 para as execuções e $208,81 para a adjudicação.
Por que nenhum juiz LLM avalia correção no nível básico. Medimos a alternativa antes de escolher. Em 2.203 registros do benchmark antecessor, um juiz LLM nunca reprovou uma consulta que a execução aprovou, em qualquer limiar. Esse juiz via ambos os conjuntos de resultados, de modo que seu veredicto não é independente do resultado da execução e o zero não estabelece que um juiz não possa ser mais rigoroso. A execução permanece como o piso e o júri aparece mais acima no intervalo, onde sua leniência é o ponto.
Por que a dica é omitida. O BIRD fornece uma dica de domínio com cada pergunta. Fornecê-la vale de 6 a 9 pontos na correspondência de execução, e também move a precisão de roteamento em 5,7 pontos, o que a torna um vazamento no eixo de roteamento. Portanto, ambas as páginas reportam a condição sem dica, e os números de SQL aqui ficam abaixo do que os mesmos modelos pontuariam sob condições padrão do BIRD.
Precisão de SQL no painel, de três formas
Classificada pela coluna adjudicada. Seis linhas ficaram abaixo de 759 registros após duas tentativas de repetição, e as perguntas ausentes estão ausentes de cada denominador em vez de contadas como falhas.
Limitações do eixo SQL
A referência é emprestada e contestada. Nosso índice de 31,1% de referências defeituosas é nosso próprio subconjunto auditado, não uma verdade fundamental com múltiplos anotadores. Não há uma segunda passagem cega duplicada, nem índice de concordância entre anotadores, e a verificação humana foi feita pelo proprietário do benchmark, não por um anotador independente. Os jurados viram as listas de colunas das tabelas que a consulta de referência toca, então uma referência que consulta a tabela errada é indetectável dessa perspectiva e tais defeitos são perdidos. O painel também pode sinalizar uma referência correta, um erro na outra direção. Nenhum anotador independente repetiu a passagem, então o erro residual não é medido em nenhum sentido e o número não é um limite mínimo.
A coluna adjudicada é um instrumento de LLM, não uma segunda verdade fundamental, e não um limite superior estrito. Seus três jurados são modelos, então a coluna herda o que um painel de modelos erra sobre equivalência em SQL, e nenhum humano releu os veredictos.
O comparador erra em ambos os sentidos. Ordem e contagem de colunas causam falsos negativos, enquanto normalização de maiúsculas/minúsculas e arredondamento com seis algarismos significativos causam falsos positivos. O erro do comparador e o erro da consulta de referência são fontes de incerteza separadas e podem mover uma pontuação em direções diferentes.
A correspondência de execução estrita é medida sobre as perguntas corretamente roteadas por cada modelo, e os melhores roteadores ganham um conjunto mais difícil. A precisão de roteamento acompanha a dificuldade das perguntas que chegam ao denominador de SQL de um modelo. Entre os 36 modelos, essa correlação é 0,96 (Pearson, sobre a média da contagem de vizinhos entre bancos de dados) e 0,97 contra a proporção de perguntas mais difíceis nesse denominador. Em termos concretos, claude-opus-5 escreve SQL para 717 perguntas, das quais 21,8% estão entre as 184 mais difíceis, enquanto o nova-lite-v1 escreve SQL para 285 perguntas, das quais 7,7% estão. Um roteador fraco é avaliado em uma seleção mais fácil. Trate esta coluna como um diagnóstico por modelo, não como um ranking entre modelos, e leia as três colunas como níveis. Para fechar a lacuna, seria necessária uma execução com rota de oráculo, onde cada modelo escreve SQL para as mesmas perguntas. Essa execução não foi feita.
Os intervalos de confiança cobrem apenas o ruído amostral. A tabela acima imprime estimativas pontuais, e os intervalos de Wilson para as colunas estrita e gold-clean constam no CSV publicado ao lado de cada linha. Os intervalos carregam o ruído da amostragem de perguntas e nem a incerteza dos júris nem a das sinalizações da referência. Duas execuções do painel repetidas em condições idênticas moveram a precisão de roteamento em 1,6 a 2,7 pontos, e esta página não reporta nenhuma medição repetida para as colunas de SQL.
Estes números são dica-gratuito por construção, portanto não são comparáveis às pontuações do placar de líderes do BIRD para os mesmos modelos.
Conclusão
A correspondência de execução estrita contra as consultas de referência do BIRD varia de 0.190 a 0.551 entre os 36 modelos, e esse mesmo painel varia de 0.316 a 0.824 uma vez que um júri cego releu cada erro. A distância entre essas duas leituras é a descoberta. Para o claude-sonnet-5, são 39,9 pontos, dos quais 22,7 vêm de respostas que retornam a informação correta em um formato que o comparador rejeita.
Para uma carga de trabalho pontuada por correspondência de execução estrita, o gemini-3-flash-preview registrou 0.551 bruto e 0.677 gold-clean a $7,67 por execução. Para uma carga de trabalho onde uma resposta equivalente em uma projeção diferente é aceitável, o claude-opus-5 registrou 0.824 adjudicado contra 0.785 do gpt-5.6-sol, dentro de um intervalo de confiança. Para qualquer comparação por modelo, o denominador difere entre modelos, então as três colunas são diagnósticos em vez de um placar controlado.
O teto neste eixo é a referência, não os modelos. Um terço das consultas de referência do BIRD falha em nossa auditoria, os defeitos se concentram na divisão de treino onde nenhuma correção publicada alcança, e os dois instrumentos que enxergam além deles são júris de LLM, não anotadores humanos. Para avançar o eixo, é necessária uma execução com rota de oráculo para que cada modelo escreva SQL para as mesmas perguntas, e uma anotação independente dupla por humanos de uma amostra estratificada da referência. Nenhum dos dois foi feito.
Adicionar como fonte preferencialLeitura adicional
- Benchmark Agentic RAG: Roteamento Multi-Banco de Dados em 36 LLMs
- 200+ Principais Benchmarks de IA
- HALC-Bench: Alucinação de LLM no Benchmark de Recuperação de Longo Contexto
- +100 conjuntos de dados para modelos de ML & IA
- Melhores Ferramentas, Frameworks e Bibliotecas RAG
Perguntas frequentes
Porque as consultas de referência são do BIRD e um terço delas falha em nossa auditoria. A correspondência de execução estrita é o piso, a coluna gold-clean remove as perguntas cuja referência julgamos defeituosa, e a coluna adjudicada credita respostas que um júri cego considerou equivalentes. claude-sonnet-5 vai de 0.311 a 0.710 nesse intervalo, portanto um único número distorceria o painel em até 39,9 pontos.
Não. O BIRD fornece uma dica de domínio com cada pergunta e fornece o banco de dados. Este benchmark omite a dica e faz o modelo escolher o banco de dados entre 11. Apenas a dica vale de 6 a 9 pontos na correspondência de execução.
Não neste painel. Cada modelo escreve SQL para as perguntas que roteou corretamente, então um roteador melhor ganha um denominador mais difícil, com uma correlação de 0,96 entre a precisão de roteamento e a dificuldade do denominador. kimi-k3 roteia 0.832 e escreve 0.482 gold-clean, enquanto gemini-3-flash-preview roteia 0.753 e escreve a melhor 0.677 do painel.
Uma consulta de referência que não responde à sua própria pergunta, conforme avaliado por cinco modelos de ponta de cinco famílias diferentes, nenhum dos quais viu qualquer resposta candidata. O painel sinalizou 236 de 759, e um painel anterior de três modelos sinalizou independentemente 221, das quais 207 se sobrepõem.
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Text-to-SQL: Comparação da Precisão de LLM}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Acessado em 7 Agosto 2026}
}Links de referência
Comentários 1
Compartilhe suas ideias
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.
Curious, how much of the context engineering and specific prompting did you apply in your benchmarks. Or, was it to review the models only? I have found much higher return of correct and consistent responses. A higher fidelity. To do that, I needed to provide a most sophisticated prompt that fed the context window as the question was being asked. Not perfect, but better than those scores represented in this article when using the Grok 4.x .
Great point. This benchmark intentionally uses zero-shot, minimal prompting with temperature=0. No few-shot examples, no domain-specific instructions, no iterative refinement. The goal was to measure each model's baseline text-to-SQL capability. So your experience with Grok 4 getting higher fidelity through sophisticated context engineering is completely expected. A well-crafted prompt with detailed schema descriptions, few-shot examples, and domain-specific rules will improve any model's performance significantly. What this benchmark isolates is how well the model performs out-of-the-box when given only the raw question and retrieved schema, which helps compare the models' inherent SQL reasoning abilities on a level playing field. We'll make this clearer in the methodology section. Thanks for raising it.