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 precisava identificar por si mesmo entre 11 candidatos. Toda consulta analisável foi executada no banco de dados real e seu conjunto de resultados comparado com o conjunto de resultados da consulta gold do BIRD. Consultas ausentes, malformadas e com falha de execução foram pontuadas 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 chamadas de ferramentas descrita na página de roteamento, que analisa chamadas de ferramentas que o parser padrão rejeita. Quinze execuções são anteriores a isso e duas atravessam a mudança.
Métricas explicadas:
Correspondência de execução estrita: Correspondência de execução sobre as perguntas que o modelo encaminhou corretamente. Condicionar pela rota correta elimina falhas diretas de banco de dados errado, mas não isola totalmente a capacidade de SQL, porque cada modelo chega a um subconjunto diferente de perguntas.
Gold-clean: A mesma medição, removendo do denominador as perguntas cujo SQL gold consideramos quebrado. Essas perguntas não são pontuadas como acertos; são removidas.
Adjudicada: O extremo superior. Um júri cego de três modelos, escolhido de famílias diferentes da do modelo sob teste, revisa todas as respostas que a comparação estrita rejeitou, quando o modelo encaminhou corretamente, o SQL executa e suas linhas se sobrepõem às do gold em menos da metade. Ele decide se a consulta é uma formulação diferente, mas equivalente, se o gold está errado ou se o modelo está errado. Respostas equivalentes e golds quebrados são creditados.
Todas as três começam com o conjunto completo de 759 perguntas, e não com o subconjunto difícil, e nenhuma delas usa 759 como denominador. Cada uma é medida sobre as perguntas que o modelo encaminhou corretamente, e a coluna gold-clean então remove os golds sinalizados. O acaso não se aplica a esse eixo, porque uma consulta retorna o conjunto de resultados do gold ou não retorna.
Descobertas do benchmark de Text-to-SQL
Respostas corretas no formato errado custam 22.7 pontos a um modelo
claude-sonnet-5 registra 0.311 na correspondência de execução estrita, 33rd entre os 36 modelos e a linha mais baixa de qualquer Anthropic. Sob adjudicação cega, a mesma execução pontua 0.710, 0.007 abaixo do 0.717 do qwen3.6-27b.
O ganho de 39.9 pontos se divide em dois. 154 de suas 679 perguntas pontuadas, 22.7 pontos, são respostas que o júri leu como equivalentes ao gold em um formato diferente. Outras 117, 17.2 pontos, são perguntas em que o júri considerou que o próprio gold estava quebrado. O estilo de resposta explica a primeira dessas duas parcelas, não a soma. Nenhuma parte disso é explicada por falha do harness, porque a execução não registrou consultas ausentes, teve uma falha e nenhuma resposta não recuperada.
Essas mesmas 154 respostas são 34% dos 453 erros do sonnet-5 que chegaram à adjudicação. Equivalente em formato significa que a consulta retorna as informações corretas em uma projeção diferente, uma coluna extra, uma ordem de colunas diferente ou uma contagem quando o gold retornou as linhas. A correspondência de execução estrita pontua isso como falha.
A tendência corre por família de modelo, e não por nível de capacidade. Famílias com projeção rica perdem de um quarto a um terço de seus erros adjudicados dessa forma: no Claude 25 a 34%, no Kimi 24 a 34%, na linha de raciocínio 5.x da OpenAI 26 a 32%, no DeepSeek 31%, no MiniMax 26 a 30% e no GLM-5.x 28%. Modelos que escrevem no formato do gold perdem bem menos: Google 9 a 17%, Llama 9%, Mistral 18%, Grok 19% e os próprios modelos pequenos da OpenAI 19 a 20%. O 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 conclui que 46% das respostas rejeitadas de um modelo não são erros do modelo
Pegamos 314 das 346 respostas que a comparação estrita rejeitou para o gemini-3.5-flash-lite em perguntas que ele encaminhou corretamente, aquelas cujo SQL executou e cujas linhas se sobrepuseram às do gold 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, e não apenas os difíceis, de modo que correspondem à população coberta pelas colunas de SQL.
O júri as dividiu em quatro categorias. Defeito do gold, quando o modelo está certo e a consulta gold do BIRD está errada, ficou com 29.3%. Formato equivalente ficou com 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, e não sobre todas as 346 respostas rejeitadas. Os 32 retidos falharam na execução ou se sobrepuseram demais ao gold para serem uma discordância clara.
A rigidez do comparador não explica a diferença. Flexibilizar a correspondência de ordem das colunas rende 0.5 pontos, e 92% dos erros se sobrepõem ao resultado do gold 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 de 0.464.
Os erros que o júri classificou como defeito do gold se concentram onde nenhuma correção publicada alcança, em 33% dos erros da divisão de treino desse modelo contra 20% dos erros da divisão de dev. Toda correção determinística disponível para nós já foi aplicada. Repontuar contra a própria versão corrigida de dev do BIRD mudou 0 de 92 erros de dev; um conjunto de correções externas cobriu 39 deles e mudou 1; e uma auditoria de engine MySQL contra SQLite encontrou 4 golds divergentes em todo o conjunto, juntos cerca de 1% dos 314.
Nossa auditoria com cinco modelos sinaliza 31.1% das consultas gold do BIRD como quebradas
Auditamos o próprio gold. Cinco modelos de fronteira, um por família, avaliaram todas as 759 consultas gold em relação às suas perguntas e esquemas. Nenhum jurado viu qualquer saída de modelo. O painel sinalizou 236 de 759 golds como quebrados, 31.1%, a um custo de $20,55 e sem chamadas do júri com falha.
A taxa se divide por partição do BIRD: 204 de 560 golds de treino (36%) contra 32 de 199 golds de dev (16%). Um painel independente de três modelos executado anteriormente alcançou 29.1%, e 207 de seus 221 sinalizadores de quebrados, 94%, estão quebrados 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 de 151 exemplos, e coloca a taxa em 32.5%. As auditorias revisadas por pares do BIRD cobrem a divisão de dev por design explícito, então os 151 exemplos da MotherDuck permanecem como a única verificação externa sobre as 560 perguntas de treino em nosso conjunto congelado, 73.8% dele.1
Remover os golds quebrados do denominador move o melhor modelo estrito de 0.551 para 0.677, e os ganhos por modelo variam de +4.5 a +13.3 pontos. A camada superior mantém sua 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 pontuação estrita mais baixa, 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. O 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 bracket. Nas pontuações adjudicadas, o qwen3.6-27b é décimo quarto com 0.717, enquanto o 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 o melhor do painel de 0.677. O gemini-3-flash-preview inverte isso, roteando 0.753 com esse melhor SQL gold-clean do painel. O gpt-5.6-terra roteia a 0.772 e escreve 0.447.
Os dois eixos não são medidos sobre um mesmo denominador. Cada modelo escreve SQL para as perguntas que encaminhou corretamente e nenhuma outra, e os melhores roteadores ganham um conjunto mais difícil, o que puxa para baixo qualquer associação medida entre os eixos.
A auditoria do gold e o júri de adjudicação
Dois júris fizeram dois trabalhos diferentes.
O júri de validade do gold avalia as consultas gold. Seus cinco jurados (claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5, deepseek-v4-pro) veem, cada um, uma pergunta, o SQL do gold e as listas de colunas das tabelas que a consulta toca, e respondem se o gold responde à pergunta. Nenhuma saída de modelo é mostrada em momento algum. Seus veredictos são congelados em um arquivo com hash fixado e alimentam a coluna gold-clean.
O júri de adjudicação avalia o erro de um modelo específico. Três modelos de famílias diferentes da do modelo sob teste veem a pergunta, a consulta e o resultado do gold e a consulta e o resultado candidatos, com posições embaralhadas, e votam em qual das quatro categorias o erro pertence. Ele executa 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 otimista ajustado por adjudicação, em vez de uma verdade fundamental independente. Ela pode errar em qualquer direção. Uma resposta ambígua que era de fato correta não recebe crédito, e um falso positivo do júri credita uma que não era. Três propriedades medidas limitam o quanto ela pode ser forçada.
A revisão é assimétrica. Erros recebem uma segunda olhada e acertos nunca recebem, então 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 erros e consultas que não executam permanecem 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 parcela de defeito do gold 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% defeito do gold e 19% erro genuíno, enquanto os do llama-4-maverick são 13% e 50%.
Vinte e quatro dos 36 modelos ficam em ou acima de 0.68 adjudicado.
Como a geração de SQL funciona neste benchmark
O modelo nunca recebe um schema antecipadamente. Ele escolhe uma das 11 ferramentas de banco de dados, lê a lista de tabelas que retorna, pede as colunas de uma tabela quando precisa e pode executar consultas exploratórias contra o banco de dados pelo qual se decidiu antes de confirmar. A saída de schema é limitada a 4.000 caracteres e os resultados de consulta a 50 linhas.
A consulta final chega em uma chamada obrigatória de finalização enviada sem ferramentas anexadas, junto com o banco de dados que o modelo declara. A pontuação executa essa consulta e a consulta gold 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 é onde uma resposta certa pode pontuar como erro. Uma consulta que retorna as mesmas linhas com uma coluna extra, em ordem diferente de colunas ou como contagem quando o gold 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, que rende 0.5 pontos.
Metodologia do benchmark para text-to-SQL
Este benchmark compartilha sua infraestrutura com o benchmark de RAG agentic, que descreve em detalhe a seleção de bancos de dados, a taxonomia de dificuldade, a anonimização, o loop agentic e o orçamento de turnos. Ambas as páginas relatam o mesmo subconjunto congelado de 759 perguntas do BIRD-SQL, executado sobre 11 bancos de dados entre os quais o modelo precisa 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 gold 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 encaminhou corretamente. Forma relatada: um bracket de três valores, correspondência de execução estrita, depois gold-clean, depois adjudicada. Auditoria do gold: 5 famílias de fronteira, um modelo cada, 759 golds avaliados, 236 sinalizados como quebrados, hash fixado. Adjudicação: 3 modelos por candidato, de famílias disjuntas do modelo sob teste, cega e com posições embaralhadas. Painel: 36 modelos, uma única execução cada, $874,53 pelas execuções e $208,81 pela adjudicação
Por que nenhum LLM julga a correção no piso. Medimos a alternativa antes de escolher. Em 2.203 registros do benchmark anterior, um juiz LLM nunca reprovou uma consulta que a execução aprovou, em qualquer limiar. Esse juiz viu os dois conjuntos de resultados, então seu veredicto não é independente do resultado da execução, e o zero não estabelece que um juiz não possa ser mais rígido. A execução permanece como piso e o júri aparece mais acima no bracket, onde sua leniência é o ponto.
Por que a dica é omitida. O BIRD envia uma dica de domínio com cada pergunta. Fornecê-la vale de 6 a 9 pontos de correspondência de execução e também altera a precisão de roteamento em 5.7 pontos, o que a torna um vazamento no eixo de roteamento. Ambas as páginas, portanto, relatam a condição hint-free, e os números de SQL aqui ficam abaixo do que os mesmos modelos pontuariam sob as condições padrão do BIRD.
Precisão de SQL em todo o painel, de três maneiras
Classificado pela coluna adjudicada. Seis linhas ficaram abaixo de 759 registros após duas tentativas de repetição, e as perguntas ausentes estão fora de todos os denominadores, em vez de serem contadas como falhas.
Limitações do eixo de SQL
O gold é emprestado e contestado. Nosso número de 31.1% de gold quebrado é nosso próprio subconjunto auditado, não uma verdade fundamental multi-anotador. Não há passada dupla cega, não há índice de concordância entre anotadores, e a verificação humana foi feita pelo proprietário do benchmark, e não por um anotador independente. Os jurados viram as listas de colunas das tabelas que a consulta gold toca, então um gold que consulta a tabela errada é indetectável dessa visão e tais defeitos são perdidos. O painel também pode sinalizar um gold funcional, um erro na outra direção. Nenhum anotador independente repetiu a passada, então o erro residual não é medido em nenhuma direção e o número não é um piso.
A coluna adjudicada é um instrumento de LLM, não uma segunda verdade fundamental, nem 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 de SQL, e nenhum humano releu os veredictos.
O comparador erra nas duas direções. Ordem das colunas e contagem de colunas causam falsos negativos, enquanto normalização de maiúsculas e arredondamento de floats com seis algarismos significativos causam falsos positivos. O erro do comparador e o erro da consulta gold são fontes separadas de incerteza e podem mover uma pontuação em direções diferentes.
A correspondência de execução estrita é medida sobre as próprias perguntas corretamente encaminhadas de cada modelo, e os melhores roteadores recebem 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 é de 0.96 (Pearson, sobre a contagem média de vizinhos entre bancos de dados) e de 0.97 em relação à proporção das perguntas mais difíceis nesse denominador. Em termos concretos, o 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, e não como um ranking entre modelos, e leia as três colunas como níveis. Para fechar a lacuna, é necessária uma execução com rota oráculo, na qual 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 apresenta estimativas pontuais, e os intervalos de Wilson para as colunas estrita e gold-clean estão no CSV publicado ao lado de cada linha. Os intervalos carregam o ruído de amostragem das perguntas, e não a incerteza dos júris nem a dos sinalizadores do gold. Duas execuções do painel repetidas em condições idênticas alteraram a precisão de roteamento em 1.6 a 2.7 pontos, e esta página não relata medição repetida para as colunas de SQL.
Esses números são hint-free por construção, portanto não são comparáveis às pontuações do leaderboard do BIRD para os mesmos modelos.
Conclusão
A correspondência de execução estrita em relação às consultas gold do BIRD varia de 0.190 a 0.551 entre os 36 modelos, e esse mesmo painel varia de 0.316 a 0.824 depois que um júri cego releu todos os erros. 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 em que 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 por modelo, então as três colunas são diagnósticos, em vez de um leaderboard controlado.
O teto desse eixo é o gold, não os modelos. Um terço das consultas gold 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 ambos júris de LLM, e não anotadores humanos. Avançar o eixo exige uma execução com rota oráculo para que cada modelo escreva SQL para as mesmas perguntas, e uma anotação dupla humana independente de uma amostra estratificada do gold. Nenhuma dessas coisas foi feita.
Adicionar como fonte preferencialLeitura adicional
- Benchmark de RAG Agentic: Roteamento Multi-Banco de Dados entre 36 LLMs
- 200+ Principais Benchmarks de IA
- HALC-Bench: Alucinação de LLM em Benchmark de Recuperação de Contexto Longo
- +100 Datasets para Modelos de ML & IA
- Melhores Ferramentas, Frameworks e Bibliotecas de RAG
Perguntas frequentes
Porque as consultas gold 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 cujo gold consideramos quebrado, e a coluna adjudicada credita respostas que um júri cego leu como equivalentes. O claude-sonnet-5 passa de 0.311 para 0.710 nesse bracket, de modo que um único número deturparia o painel em até 39.9 pontos.
Não. O BIRD envia 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. A dica sozinha vale de 6 a 9 pontos de correspondência de execução.
Não neste painel. Cada modelo escreve SQL para as perguntas que encaminhou corretamente, de modo que um roteador melhor recebe um denominador mais difícil, com uma correlação de 0.96 entre a precisão de roteamento e a dificuldade do denominador. O kimi-k3 roteia 0.832 e escreve 0.482 gold-clean, enquanto o gemini-3-flash-preview roteia 0.753 e escreve o melhor do painel, 0.677.
Uma consulta gold que não responde à sua própria pergunta, conforme avaliada por cinco modelos de fronteira 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}
}Registro de alterações
9 atualizações- 2026
Substituídos os resultados do benchmark text-to-SQL por um painel de 36 modelos avaliado por correspondência de execução strict, gold-clean e adjudicated.
Adicionado um changelog à seção de benchmark RAG Agente: roteamento multi-banco de dados e geração de consultas.
Substituída a seção de metodologia por um resumo e uma referência a outro artigo.
- 2025
Atualizado o número de grandes modelos de linguagem na introdução.
Atualizada a seção Conjunto de dados e verdade fundamental com o nível de dificuldade do conjunto de dados BIRD-SQL.
Substituído o exemplo de um filtro ausente na seção 'Filtros ausentes ou incorretos'.
Adicionada uma seção, "Como os LLMs geram SQL: uma visão passo a passo", ao artigo.
Substituída a seção de metodologia por uma estrutura de geração aumentada por recuperação (RAG) agêntica.
A seção "Metodologia de benchmark para texto para SQL" foi movida.
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.