Texto para SQL: Comparação da precisão do LLM
Utilizo SQL para análise de dados há 18 anos, desde a minha época como consultor. Traduzir perguntas em linguagem natural para SQL torna os dados mais acessíveis, permitindo que qualquer pessoa, mesmo sem conhecimentos técnicos, trabalhe diretamente com bancos de dados.
Utilizamos nossa metodologia de benchmark de texto para SQL em 34 grandes modelos de linguagem (LLMs) para avaliar seu desempenho na geração de comandos SQL:
Erros comuns em SQL gerado pelo LLM
Os LLMs (Long-Level Modeling) frequentemente cometem quatro tipos de erros: junções defeituosas, erros de agregação, filtros ausentes e erros de sintaxe.
Lógica de junção incorreta
Os modelos frequentemente tinham dificuldades em identificar e implementar corretamente as operações `JOIN` necessárias entre as tabelas, por vezes omitindo-as completamente ou utilizando subconsultas menos otimizadas.
O LLM não conseguiu unir corretamente as tabelas `frpm` e `schools` usando o `CDSCode`. Ele também apresentou nomes de colunas incorretos (`Charter`) e valores de filtro incorretos (`County = 'Fresno'`).
Erros na lógica de junção comprometem fundamentalmente o aspecto relacional da consulta, levando à recuperação incompleta ou incorreta de dados quando várias tabelas estão envolvidas.
Erros de agregação e agrupamento
A aplicação incorreta de funções de agregação (como `MAX`, `AVG`, `COUNT`, `SUM`) ou cláusulas `GROUP BY` foi outro ponto de falha comum, levando a resultados que não correspondiam semanticamente à intenção do usuário.
O LLM identificou corretamente que a frase “ maior pontuação média ” requer o agrupamento dos dados por distrito (GROUP BY dname) e o uso de uma função agregada (AVG(AvgScrRead)). Essa parte da lógica está correta.
No entanto, o LLM não incorporou um filtro crítico da pergunta: a palavra " ativo ". Para atender a esse requisito, a consulta precisava unir a tabela satscores com a tabela schools e, em seguida, filtrar os resultados com uma cláusula WHERE T1.StatusType = 'Active'.
Isso evidencia uma falha comum em LLM: a execução correta de uma instrução primária e óbvia (calcular uma média), enquanto se ignora uma condição secundária, igualmente importante (filtrar por status). Isso demonstra uma fragilidade na síntese de múltiplas restrições em uma única consulta correta.
Filtros ausentes ou incorretos
Por vezes, os modelos não incluíam as cláusulas `WHERE` necessárias ou selecionavam as colunas erradas na instrução `SELECT`, não atendendo completamente às restrições ou às informações explicitamente solicitadas no prompt.
O LLM identificou corretamente a lógica para encontrar a escola (`ORDER BY NumGE1500 DESC LIMIT 1`), mas não conseguiu selecionar o número de telefone solicitado e omitiu a junção necessária com a tabela `schools` para recuperá-lo.
Esses erros geralmente decorrem da análise incompleta da solicitação do usuário ou da falha em mapear todas as partes da solicitação para os componentes finais da consulta SQL.
Erros de sintaxe
Além de erros semânticos, ocorreram erros de sintaxe flagrantes, como o uso de aliases de tabela incorretos ou a produção de instruções SQL incompletas, o que impede a execução da consulta.
O LLM usou aliases incorretos (`accounts` em vez de `account`) e incluiu uma string literal incompleta (`'POPLATEK PO OBRATU…'`), resultando em sintaxe SQL inválida.
Esses problemas de sintaxe destacam os desafios na geração de código que segue rigorosamente a gramática SQL e as convenções específicas do banco de dados.
Por que alguns mestres em Direito são melhores em SQL?
Diversos fatores-chave determinam a eficácia com que um Modelo de Linguagem Amplo (LLM, na sigla em inglês) consegue transformar uma pergunta em linguagem natural em uma consulta correta a um banco de dados SQL.
1. Tamanho do modelo e dados de treinamento
- Tamanho e design: Modelos maiores ou aqueles construídos com estruturas específicas podem lidar com tarefas complexas, como a geração de SQL, de forma mais eficaz.
- O que aprendeu: Os dados usados para treinar o LLM são essenciais. Se ele vir muitos exemplos de perguntas vinculadas a respostas SQL, especialmente aquelas que envolvem operações complexas como junções ou cálculos (SOMA, MÉDIA), provavelmente terá um desempenho melhor.
2. Otimização para tarefas SQL
- Os modelos podem receber treinamento adicional focado especificamente em tarefas de conversão de texto em SQL. Esse "ajuste fino" os ajuda a entender as estruturas do banco de dados e as regras SQL com mais eficácia do que os modelos treinados apenas com texto geral. O treinamento com instruções específicas também é útil.
3. Habilidades de raciocínio e mapeamento de esquemas
- Raciocínio: Quão bem o profissional de LLM consegue determinar os passos exatos necessários a partir de uma pergunta por vezes vaga? A criação de SQL frequentemente requer etapas lógicas .
- Entendendo o mapa do banco de dados (Esquema): Alguns LLMs são melhores em conectar conceitos na pergunta (como "clientes" ou "vendas totais") aos nomes reais de tabelas e colunas no banco de dados, mesmo que os nomes não sejam imediatamente óbvios.
Como os LLMs geram SQL: uma análise passo a passo.
Para ver fatores como "raciocínio" e "mapeamento de esquema" em ação, vamos percorrer o processo passo a passo que um modelo segue para gerar uma consulta. Todo esse fluxo de trabalho é impulsionado por uma técnica chamada Geração Aumentada por Recuperação (RAG).
Etapa 1: Análise inicial e seleção do banco de dados
Ao se deparar com uma pergunta, o LLM primeiro analisa a intenção do usuário para selecionar a ferramenta de banco de dados mais relevante.
- Pergunta: “Quantas contas têm uma disposição do titular e uma solicitação para que um extrato seja gerado após uma transação?”
- Ação da LLM: O modelo identifica palavras-chave como “contas”, “disposição” e “transação”. Conclui que a ferramenta de banco de dados
financialé a escolha correta em relação a outras comocalifornia_schoolsousuperhero.
Etapa 2: Recuperação do esquema via RAG
Assim que o modelo escolhe uma ferramenta, ele precisa que o banco de dados "mapeie" o esquema. Ele não tem essa informação memorizada. Em vez disso, o sistema RAG a recupera em tempo real.
- Recuperação: A pergunta do usuário é usada para pesquisar um banco de dados vetorial que armazena informações de esquema. A pesquisa encontra e recupera os detalhes de esquema mais relevantes, como as definições das tabelas
accountsedisp. - Aumento de escopo: O texto do esquema recuperado é inserido automaticamente no prompt junto com a pergunta original.
- Geração: O LLM agora possui todo o contexto necessário para prosseguir.
Esse processo RAG garante que o modelo receba apenas as informações de esquema necessárias, tornando sua tarefa mais focada e eficiente.
Etapa 3: Raciocínio e construção de consultas
Com a pergunta e o esquema fornecido pelo RAG, o modelo mapeia conceitos da solicitação do usuário para os nomes específicos de tabelas e colunas que acabou de receber.
Monólogo interno de LLM:
- Objetivo: O usuário quer uma contagem, então vou começar com
SELECT COUNT(...). - Condições:
- “…disposição do proprietário…” -> O esquema da tabela
disppossui uma colunatype. Preciso de uma cláusulaWHEREparatype = 'OWNER'. - “…declaração a ser gerada em uma transação…” -> O esquema da tabela
accountspossui uma colunafrequency. O filtro deve serfrequency = 'POPLATEK PO OBRATU'.
- “…disposição do proprietário…” -> O esquema da tabela
- Junções: As informações estão divididas entre as tabelas
accountsedisp. O esquema mostra que elas estão vinculadas poraccount_id, então precisoJOINentre elas.
Etapa 4: Geração do SQL final
Finalmente, o modelo reúne essas peças lógicas em uma consulta SQL sintaticamente correta. A qualidade dessa saída depende de:
- Capacidade de raciocínio: A habilidade do modelo em conectar logicamente a solicitação do usuário ao esquema fornecido.
- Conhecimento de SQL adquirido por meio de treinamento: O entendimento fundamental do modelo sobre a sintaxe e as funções do SQL.
Esse processo explica por que ocorrem erros. Se o esquema recuperado for ambíguo ou se um termo na pergunta não tiver uma correspondência clara, o LLM precisa fazer uma suposição fundamentada, o que pode levar aos erros que analisamos anteriormente.
O que é conversão de texto em SQL?
A tecnologia Text-to-SQL, de processamento de linguagem natural, converte a linguagem cotidiana em uma consulta SQL escrita em linguagem de consulta estruturada. Em vez de escrever manualmente o código SQL, o usuário faz uma pergunta em linguagem natural e o sistema gera uma instrução SQL que pode ser executada em um banco de dados.
O principal objetivo da conversão de texto para SQL é reduzir a lacuna entre a forma como as pessoas pensam sobre os dados e a forma como os bancos de dados exigem que as consultas sejam escritas. Isso é especialmente relevante para usuários não técnicos e analistas de dados que entendem o contexto de negócios, mas podem não se sentir à vontade para escrever sintaxe SQL do zero.
Em um nível básico, quando um usuário faz uma pergunta como:
- “Mostrar todos os clientes de Nova Iorque que fizeram compras no mês passado.”
O sistema traduz essa solicitação em uma consulta SQL gerada que seleciona as colunas corretas, filtra linhas usando restrições de data e localização e une as tabelas necessárias do banco de dados. A qualidade da saída depende da capacidade do sistema de gerar consultas precisas que reflitam tanto a intenção do usuário quanto o esquema do banco de dados.
Onde a conversão de texto em SQL é útil hoje em dia
A conversão de texto para SQL funciona razoavelmente bem para:
- Gere rascunhos de consultas que os analistas de dados possam revisar e ajustar.
- Apoiar a análise exploratória de dados em situações onde a velocidade é mais importante do que a precisão.
- Permitir que usuários sem conhecimento técnico acessem dados simples por meio de esquemas predefinidos.
- Auxilie os usuários de SQL reduzindo a necessidade de escrever consultas repetitivas.
Nesses casos, a função de conversão de texto em SQL atua como uma ferramenta de IA auxiliar, e não como um sistema autônomo. A revisão humana continua fazendo parte do fluxo de trabalho, principalmente quando a precisão é fundamental.
Como funciona a conversão de texto em SQL?
Os modernos sistemas de conversão de texto em SQL dependem de grandes modelos de linguagem treinados com pares de perguntas em linguagem natural e consultas SQL. Esses modelos aprendem padrões que conectam a linguagem cotidiana a estruturas SQL, nomes de tabelas, colunas e relacionamentos. O processo normalmente segue uma sequência de etapas:
Compreensão da linguagem natural
O sistema primeiro analisa a entrada do usuário para determinar a intenção, as restrições e as entidades. Esta etapa envolve:
- Identificar o que o usuário está solicitando (por exemplo, totais, filtros, comparações)
- Extrair condições relevantes, como intervalos de tempo, locais ou categorias.
- Interpretação de frases ambíguas que podem exigir contexto empresarial.
Erros nesta fase frequentemente levam a uma consulta SQL aparentemente correta, mas que responde à pergunta errada.
Mapeamento de esquema
Em seguida, o sistema mapeia os termos da pergunta para o esquema do banco de dados. Isso inclui:
- Associar os conceitos da pergunta aos nomes e colunas das tabelas.
- Entendendo as relações entre as tabelas
- Respeitar os tipos de dados, como datas, campos numéricos ou categorias.
O mapeamento de esquemas torna-se mais desafiador à medida que o número de tabelas aumenta ou quando os nomes das colunas não correspondem exatamente à forma como os usuários descrevem os dados em perguntas em linguagem natural.
Construção de consultas SQL
Uma vez identificados os elementos de intenção e esquema, o sistema constrói a consulta SQL. Isso pode envolver:
- Selecionar as tabelas e colunas corretas.
- Adicionar junções em todas as tabelas necessárias
- Aplicar filtros, agregações e lógica de agrupamento.
- Produzir código SQL sintaticamente válido para sistemas como MySQL ou PostgreSQL.
Nessa fase, o sistema pode facilmente produzir SQL válido, mas logicamente incorreto, por exemplo, usando uma condição de junção ou agregação errada.
Validação e execução
Alguns sistemas incluem camadas de validação que verificam se a consulta SQL gerada pode ser executada e retornar resultados. Ferramentas mais avançadas podem tentar uma otimização limitada ou fazer perguntas adicionais quando a consulta for ambígua.
No entanto, a validação raramente garante uma resposta correta. Uma consulta pode ser executada com sucesso e ainda assim estar incorreta em detalhes sutis.
Limitações e riscos práticos
Apesar dos excelentes resultados nos testes de desempenho, o uso no mundo real expõe diversas limitações que não podem ser ignoradas.
Confiabilidade e exatidão
Mesmo os modelos de melhor desempenho falham em gerar SQL correto para uma parcela significativa de consultas complexas. Uma taxa de erro de 20% ou superior significa:
- Uma em cada cinco consultas geradas pode retornar resultados enganosos.
- Os erros são frequentemente semânticos, e não sintáticos.
- Junções, filtros ou agregações incorretas podem passar despercebidas.
Isso é particularmente arriscado em sistemas de relatórios, previsões ou apoio à decisão, onde os usuários presumem que o resultado está correto.
Dependência da supervisão humana
Considerando o desempenho atual, o SQL gerado deve ser revisado por alguém que entenda de SQL e do banco de dados. Sem essa supervisão:
- Os usuários podem confiar em uma consulta incorreta porque ela é executada com sucesso.
- Os erros podem se propagar para painéis de controle, relatórios ou sistemas subsequentes.
- A responsabilidade torna-se incerta quando as decisões dependem de resultados gerados por IA.
A conversão de texto em SQL não elimina a necessidade de conhecimento especializado em SQL; ela apenas muda o foco de aplicação desse conhecimento.
teto de complexidade
À medida que a complexidade das consultas aumenta, o desempenho cai drasticamente. Os modelos têm dificuldades com:
- Junções múltiplas em várias tabelas
- Lógica aninhada e subconsultas
- Cálculos específicos do domínio
- Consultas que exigem conhecimento profundo do esquema do banco de dados
Benchmarks como o BIRD-SQL destacam que consultas complexas continuam sendo o principal ponto de falha, mesmo para modelos avançados.
Variabilidade do modelo
As diferenças de desempenho entre os modelos são significativas. Alguns modelos de linguagem apresentam um desempenho razoável, enquanto outros falham frequentemente no mesmo conjunto de dados. Isso significa:
- A seleção do modelo tem um impacto direto na precisão.
- O ajuste fino e os dados de treinamento são importantes.
- Modelos de propósito geral podem não funcionar bem sem adaptação ao domínio.
Não existe uma solução universal que funcione igualmente bem em todas as bases de dados e casos de uso.
Governança e privacidade de dados
Sistemas de conversão de texto em SQL introduzem riscos de acesso adicionais:
- Os usuários podem consultar tabelas confidenciais sem compreender as implicações.
- O SQL gerado pode expor metadados sobre o esquema do banco de dados.
- Os controles de privacidade de dados devem ser aplicados fora do modelo de linguagem.
Sem controles de acesso robustos, a conversão de texto em SQL pode enfraquecer as práticas de governança existentes.
Metodologia de avaliação comparativa para conversão de texto em SQL
Este benchmark compartilha sua estrutura de avaliação com nosso benchmark RAG agentivo , que descreve em detalhes a construção do conjunto de dados, a arquitetura do agente, o desafio de ambiguidade semântica e a rubrica de pontuação completa.
Ambos os benchmarks utilizam o mesmo banco de dados BIRD-SQL com 500 questões. 1 subconjunto, pipeline agentivo, recuperação de esquema com suporte do ChromaDB e avaliação do LLM como Juiz com o Sonnet de Claude 4. A métrica aqui apresentada, taxa de geração de comandos SQL corretos, é a porcentagem de questões em que o modelo direcionou para o banco de dados correto e gerou uma consulta SQL semanticamente correta. Todos os modelos foram avaliados sob condições idênticas de zero-shot com temperatura 0 e sem dicas específicas de domínio.
Leitura complementar
Explore outros benchmarks RAG, como:
- Modelos de incorporação: OpenAI vs Gemini vs Cohere
- Principais bases de dados vetoriais para RAG: Qdrant vs Weaviate vs Pinecone
- RAG Híbrido: Aumentando a Precisão do RAG
- Benchmark RAG agenic: roteamento em múltiplos bancos de dados e geração de consultas
- Os 10 principais modelos de incorporação multilíngue para RAG
Registro de alterações
20 de fevereiro de 2026
Adicionados 2 novos modelos ao benchmark:
- Google: Prévia do Gemini 3.1 Pro (google/gemini-3.1-pro-preview)
- Anthropic: Claude Sonnet 4.6 (antrópico/claude-sonnet-4.6)
10 de fevereiro de 2026
Adicionados 2 novos modelos ao benchmark:
- Claude Opus 4.6 (antrópico/claude-opus-4.6)
- Kimi K2.5 (moonshotai/kimi-k2.5)
Perguntas frequentes
Com base em nossas descobertas, você não deve confiar totalmente em consultas complexas geradas pelos modelos de linguagem atuais sem validação. Embora úteis para rascunhos e solicitações simples, mesmo os modelos de melhor desempenho apresentam taxas de erro significativas (até 20% em tarefas complexas). Sempre revise e verifique o SQL gerado, especialmente para aplicações críticas.
Sim, muitas LLMs têm capacidades que vão além da simples geração de SELECT. Elas podem frequentemente auxiliar na compreensão e sugerir modificações em código SQL existente ou até mesmo gerar DDL (Linguagem de Definição de Dados), como instruções CREATE TABLE, com base em descrições, embora a precisão dessas tarefas também exija verificação.
Fornecer um contexto claro é fundamental. Certifique-se de que o analista de software tenha acesso ao esquema do banco de dados (nomes das tabelas, nomes das colunas, relacionamentos). Declarar claramente o resultado desejado e, potencialmente, fornecer alguns exemplos de consultas relevantes (exemplos simples) para que o analista aprenda pode melhorar significativamente sua capacidade de selecionar as tabelas corretas e construir consultas precisas.
Embora as LLMs possam abstrair algumas pequenas diferenças de sintaxe entre dialetos de banco de dados, elas não resolvem completamente os problemas de compatibilidade de versão do banco de dados. Elas ainda podem gerar SQL específico para um dialeto (por exemplo, PostgreSQL vs. MySQL) ou falhar ao usar funções compatíveis com versões mais antigas, a menos que sejam explicitamente orientadas ou treinadas para isso. A validação em relação ao banco de dados de destino continua sendo importante.
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.
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.