Texto-para-SQL: Comparação da Precisão de LLM
Confio em SQL para análise de dados há 18 anos, começando nos meus dias como consultor. Traduzir perguntas em linguagem natural para SQL torna os dados mais acessíveis, permitindo que qualquer pessoa, mesmo aqueles sem habilidades técnicas, trabalhe diretamente com bancos de dados.
Utilizamos nossa metodologia de benchmark de texto-para-SQL em 34 modelos de linguagem grandes (LLMs) para avaliar seu desempenho na geração de comandos SQL:
Erros comuns em LLM-gerados SQL
LLMs frequentemente cometem quatro tipos de erro: joins defeituosos, erros de agregação, filtros ausentes e erros de sintaxe.
Lógica de join incorreta
Os modelos muitas vezes lutaram para identificar e implementar corretamente as operações `JOIN` necessárias entre tabelas, às vezes omitindo-as completamente ou usando subconsultas menos ótimas de forma inadequada.
O LLM falhou em unir corretamente as tabelas `frpm` e `schools` usando o `CDSCode`. Também alucinou nomes de colunas (`Charter`) e valores de filtro (`County = ‘Fresno’`).
Erros na lógica de join quebram fundamentalmente o aspecto relacional da consulta, levando à recuperação de dados incompleta ou incorreta quando múltiplas tabelas estão envolvidas.
Erros de agregação e agrupamento
Aplicar funções de agregação (como `MAX`, `AVG`, `COUNT`, `SUM`) ou cláusulas `GROUP BY` incorretamente 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 agrupar os dados por distrito (GROUP BY dname) e usar uma função de agregação (AVG(AvgScrRead)). Esta parte da lógica está correta.
No entanto, o LLM falhou em incorporar um filtro crítico da pergunta: a palavra “ativo“. Para atender a este requisito, a consulta precisava fazer JOIN da tabela satscores com a tabela schools e depois filtrar os resultados com uma cláusula WHERE T1.StatusType = ‘Active’.
Isso destaca uma falha comum de LLM: executar corretamente uma instrução primária e óbvia (calcular uma média) enquanto perde uma condição secundária, mas igualmente importante (filtrar por status). Isso mostra uma fraqueza em sintetizar múltiplas restrições em uma única consulta correta.
Filtros ausentes ou errados
Os modelos às vezes falharam em incluir cláusulas `WHERE` necessárias ou selecionar as colunas erradas na instrução `SELECT`, não abordando completamente as restrições ou as informações explicitamente solicitadas no prompt.
O LLM identificou corretamente a lógica para encontrar a escola (`ORDER BY NumGE1500 DESC LIMIT 1`), mas falhou em selecionar o número de `Phone` solicitado e omitiu o join necessário com a tabela `schools` para recuperá-lo.
Esses erros muitas vezes decorrem de uma 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 diretos, como o uso de aliases de tabela incorretos ou a produção de instruções SQL incompletas, que impedem a execução da consulta.
O LLM usou aliases incorretos (`accounts` em vez de `account`) e incluiu um literal de string incompleto (`’POPLATEK PO OBRATU…’`), resultando em sintaxe SQL inválida.
Esses problemas de sintaxe destacam desafios na geração de código que adere estritamente à gramática SQL e às convenções específicas do banco de dados.
Por que alguns LLMs são melhores em SQL
Várias coisas-chave determinam o quão bem um Modelo de Linguagem Grande (LLM) pode transformar uma pergunta simples em inglês em uma consulta de banco de dados SQL correta.
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 envolvendo operações complexas como joins ou cálculos (SUM, AVG), provavelmente terá um desempenho melhor.
2. Ajuste fino para tarefas de SQL
- Os modelos podem receber treinamento extra focado especificamente em tarefas de texto-para-SQL. Este “ajuste fino” ajuda-os a entender estruturas de banco de dados e regras SQL de forma mais eficaz do que modelos treinados apenas em texto geral. Treinamento em instruções específicas também ajuda.
3. Capacidades de raciocínio e mapeamento de esquema
- Raciocínio: Quão bem o LLM consegue descobrir os passos exatos necessários a partir de uma pergunta às vezes vaga? Criar SQL frequentemente requer passos lógicos.
- 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 LLMs geram SQL: Uma visão 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 este fluxo de trabalho é impulsionado por uma técnica chamada Geração Aumentada por Recuperação (RAG).
Etapa 1: Análise inicial e seleção de banco de dados
Quando apresentada 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 de proprietário e solicitação para que um extrato seja gerado após uma transação?”
- Ação do LLM: O modelo identifica palavras-chave como “contas”, “disposição” e “transação”. Ele conclui que a ferramenta de banco de dados
financialé a escolha correta em vez de outras comocalifornia_schoolsousuperhero.
Etapa 2: Recuperação do esquema via RAG
Uma vez que o modelo escolhe uma ferramenta, ele precisa do “mapa” do banco de dados, o esquema. Ele não tem essa informação memorizada. Em vez disso, o sistema RAG o 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 para as tabelas
accountsedisp. - Aumento: Este texto de esquema recuperado é inserido automaticamente no prompt junto com a pergunta original.
- Geração: O LLM agora tem todo o contexto de que precisa para prosseguir.
Este 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 consulta
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 do LLM:
- Objetivo: O usuário quer uma contagem, então começarei com
SELECT COUNT(...). - Condições:
- “…disposição de proprietário…” -> O esquema da tabela
disptem uma colunatype. Preciso de uma cláusulaWHEREparatype = 'OWNER'. - “…extrato a ser gerado após uma transação…” -> O esquema da tabela
accountstem uma colunafrequency. O filtro deve serfrequency = 'POPLATEK PO OBRATU'.
- “…disposição de proprietário…” -> O esquema da tabela
- Joins: A informação está dividida entre as tabelas
accountsedisp. O esquema mostra que elas estão vinculadas poraccount_id, então precisoJOINelas.
Etapa 4: Gerando o SQL final
Finalmente, o modelo monta essas peças lógicas em uma consulta SQL sintaticamente correta. A qualidade desta saída depende de:
- Capacidade de raciocínio: A capacidade do modelo de conectar logicamente a solicitação do usuário ao esquema fornecido.
- Conhecimento de SQL do treinamento: A compreensão central do modelo sobre sintaxe e funções SQL.
Este processo explica por que ocorrem erros. Se o esquema recuperado for ambíguo ou um termo na pergunta não mapear limpa, o LLM deve fazer uma suposição educada, o que pode levar aos erros que analisamos anteriormente.
O que é texto-para-SQL?
Texto-para-SQL é uma tecnologia de processamento de linguagem natural que converte linguagem cotidiana em uma consulta SQL escrita em linguagem de consulta estruturada. Em vez de escrever manualmente código SQL, um 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 objetivo principal do texto-para-SQL é reduzir a lacuna entre como as pessoas pensam sobre dados e 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 confortáveis escrevendo sintaxe SQL do zero.
Em um nível básico, quando um usuário faz uma pergunta como:
- “Mostre todos os clientes de Nova York 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 junta as tabelas de banco de dados necessárias. A qualidade da saída depende se o sistema pode gerar consultas precisas que reflitam tanto a intenção do usuário quanto o esquema do banco de dados.
Onde o texto-para-SQL é útil hoje
Texto-para-SQL funciona razoavelmente bem para:
- Gerar consultas de rascunho que analistas de dados podem revisar e ajustar.
- Suportar análise de dados exploratória onde a velocidade importa mais do que a precisão.
- Permitir que usuários não técnicos acessem dados simples através de esquemas predefinidos.
- Auxiliar usuários de SQL reduzindo a necessidade de escrever consultas repetitivas.
Nesses casos, o texto-para-SQL funciona como uma ferramenta de IA assistiva, em vez de um sistema autônomo. Revisão humana permanece parte do fluxo de trabalho, especialmente quando a correção importa.
Como funciona o texto-para-SQL?
Os sistemas modernos de texto-para-SQL dependem de modelos de linguagem grandes treinados em pares de perguntas em linguagem natural e consultas SQL. Esses modelos aprendem padrões que conectam linguagem cotidiana a estruturas SQL, nomes de tabelas, colunas e relacionamentos. O processo geralmente segue uma sequência de etapas:
Compreensão de linguagem natural
O sistema primeiro analisa a entrada do usuário para determinar intenção, restrições e entidades. Esta etapa envolve:
- Identificar o que o usuário está pedindo (por exemplo, totais, filtros, comparações)
- Extrair condições relevantes, como intervalos de tempo, locais ou categorias
- Interpretar frases ambíguas que podem exigir contexto de negócios
Erros nesta etapa frequentemente levam a uma consulta SQL que parece correta, mas responde à pergunta errada.
Mapeamento de esquema
Em seguida, o sistema mapeia termos da pergunta para o esquema do banco de dados. Isso inclui:
- Coincidir conceitos na pergunta com nomes de tabelas e colunas
- Entender relacionamentos entre tabelas
- Respeitar tipos de dados, como datas, campos numéricos ou categorias
O mapeamento de esquema torna-se mais desafiador à medida que o número de tabelas cresce ou quando os nomes das colunas não correspondem de perto à forma como os usuários descrevem dados em perguntas de linguagem natural.
Construção de consulta SQL
Uma vez que a intenção e os elementos do esquema são identificados, o sistema constrói a consulta SQL. Isso pode envolver:
- Selecionar as tabelas e colunas corretas
- Adicionar joins 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
Nesta etapa, o sistema pode facilmente produzir SQL válido, mas logicamente incorreto, por exemplo, usando a condição de join errada ou agregação.
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 otimização limitada ou fazer perguntas de acompanhamento quando a consulta é ambígua.
No entanto, a validação raramente garante uma resposta correta. Uma consulta pode ser executada com sucesso e ainda estar incorreta de maneiras sutis.
Limitações e riscos práticos
Apesar de fortes pontuações de benchmark, o uso no mundo real expõe várias limitações que não podem ser ignoradas.
Confiabilidade e correção
Mesmo os modelos de melhor desempenho falham em produzir SQL correto para uma parcela significativa de consultas complexas. Uma taxa de erro de 20% ou mais significa:
- Uma em cada cinco consultas geradas pode retornar resultados enganosos
- Erros são frequentemente semânticos, não sintáticos
- Joins, filtros ou agregações incorretos podem passar despercebidos
Isso é particularmente arriscado em relatórios, previsões ou sistemas de suporte à decisão, onde os usuários assumem que a saída está correta.
Dependência de supervisão humana
Dado o desempenho atual, o SQL gerado deve ser revisado por alguém que entende SQL e o banco de dados. Sem essa supervisão:
- Os usuários podem confiar em uma consulta incorreta porque ela é executada com sucesso
- Erros podem se propagar para dashboards, relatórios ou sistemas downstream
- A responsabilidade torna-se obscura quando decisões dependem de saídas geradas por IA
Texto-para-SQL não remove a necessidade de expertise em SQL; ele muda onde essa expertise é aplicada.
Teto de complexidade
À medida que a complexidade da consulta aumenta, o desempenho cai drasticamente. Os modelos lutam com:
- Múltiplos joins em muitas tabelas
- Lógica aninhada e subconsultas
- Cálculos específicos de domínio
- Consultas que exigem conhecimento profundo do esquema do banco de dados
Benchmarks como BIRD-SQL destacam que consultas complexas permanecem o principal ponto de falha, mesmo para modelos avançados.
Variabilidade do modelo
Diferenças de desempenho entre modelos são significativas. Alguns modelos de linguagem funcionam razoavelmente bem, enquanto outros falham frequentemente no mesmo conjunto de dados. Isso significa:
- A seleção do modelo tem um impacto direto na precisão
- Ajuste fino e dados de treinamento importam
- Modelos de propósito geral podem não funcionar bem sem adaptação de domínio
Não há uma solução universal que funcione igualmente bem em bancos de dados e casos de uso.
Governança de dados e privacidade
Sistemas de texto-para-SQL introduzem riscos adicionais de acesso:
- Os usuários podem consultar tabelas sensíveis sem entender as implicações
- SQL gerado pode expor metadados sobre o esquema do banco de dados
- Controles de privacidade de dados devem ser aplicados fora do modelo de linguagem
Sem controles de acesso fortes, o texto-para-SQL pode enfraquecer práticas de governança existentes.
Adicionar como fonte preferencialMetodologia de benchmark para texto-para-SQL
Este benchmark compartilha seu framework de avaliação com nosso benchmark de RAG agêntico, que descreve a construção do conjunto de dados, arquitetura de agente, desafio de ambiguidade semântica e rubrica de pontuação completa em detalhes.
Ambos os benchmarks usam o mesmo subconjunto de 500 perguntas BIRD-SQL1 , pipeline agêntico, recuperação de esquema apoiada por ChromaDB e avaliação LLM-como-Juiz com Claude 4 Sonnet. A métrica relatada aqui, taxa de geração de comando SQL correto, é a porcentagem de perguntas em que o modelo roteou para o banco de dados correto e gerou uma consulta SQL semanticamente correta. Todos os modelos foram avaliados sob condições zero-shot idênticas com temperatura 0 e sem dicas específicas de domínio.
Leitura adicional
Explore outros benchmarks de RAG, como:
- Modelos de Embedding: OpenAI vs Gemini vs Cohere
- Top Banco de Dados Vetorial para RAG: Qdrant vs Weaviate vs Pinecone
- RAG Híbrido: Aumentando a Precisão do RAG
- Benchmark de RAG Agêntico: roteamento multi-banco de dados e geração de consulta
- Top 10 modelos de embedding multilíngues para RAG
Log de alterações
20 de abril de 2026
Adicionado 1 novo modelo ao benchmark:
- Anthropic: Claude Opus 4.7 (anthropic/claude-opus-4.7)
20 de fevereiro de 2026
Adicionados 2 novos modelos ao benchmark:
- Google: Gemini 3.1 Pro Preview (google/gemini-3.1-pro-preview)
- Anthropic: Claude Sonnet 4.6 (anthropic/claude-sonnet-4.6)
10 de fevereiro de 2026
Adicionados 2 novos modelos ao benchmark:
- Claude Opus 4.6 (anthropic/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 por LLMs atuais sem validação. Embora úteis para rascunhos e solicitações simples, mesmo os modelos de melhor desempenho têm taxas de erro significativas (até 20% em tarefas complexas). Sempre revise e verifique o SQL gerado, especialmente para aplicações críticas.
Sim, muitos LLMs têm capacidades além da geração simples de SELECT. Eles podem frequentemente ajudar a entender 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 para essas tarefas também exija verificação.
Fornece contexto claro é fundamental. Garanta que o LLM tenha acesso ao esquema do banco de dados (nomes de tabelas, nomes de colunas, relacionamentos). Declarar claramente o resultado desejado e potencialmente fornecer algumas consultas de exemplo relevantes (prompting few-shot) para o LLM aprender pode melhorar significativamente sua capacidade de selecionar as tabelas corretas e construir consultas precisas.
Embora LLMs possam abstrair algumas diferenças de sintaxe menores entre dialetos de banco de dados, eles não resolvem totalmente problemas de compatibilidade de versão de tipo de banco de dados. Eles 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 explicitamente guiados ou treinados para isso. A validação contra o banco de dados de destino permanece importante.
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{dilmegani2026,
author = {Dilmegani, Cem and Sarı, Ekrem},
title = {{Texto-para-SQL: Comparação da Precisão de LLM}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Acessado em 30 Junho 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.