Texto-para-SQL: Comparação da Precisão de LLMs
Eu dependo do SQL para análise de dados há 18 anos, desde os meus tempos de consultor. Traduzir perguntas em linguagem natural para SQL torna os dados mais acessíveis, permitindo que qualquer pessoa, mesmo aquelas sem habilidades técnicas, trabalhe diretamente com bancos de dados.
Utilizámos a nossa metodologia de benchmark de texto-para-SQL em mais de 35 grandes modelos de linguagem (LLMs) para avaliar o seu desempenho na geração de comandos SQL:
Erros comuns em SQL gerado por LLMs
Os LLMs frequentemente cometem quatro tipos de erros: junções incorretas, erros de agregação, filtros ausentes e erros de sintaxe.
Lógica de junção incorreta
Os modelos muitas vezes tiveram dificuldades em identificar e implementar corretamente as operações `JOIN` necessárias entre tabelas, por vezes omitindo-as completamente ou utilizando incorretamente subconsultas menos otimizadas.
O LLM falhou ao juntar 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 junção quebram fundamentalmente o aspeto relacional da consulta, levando a uma recuperação de dados incompleta ou incorreta quando várias tabelas estão envolvidas.
Erros de agregação e agrupamento
Aplicar funções agregadas (como `MAX`, `AVG`, `COUNT`, `SUM`) ou cláusulas `GROUP BY` incorretamente foi outro ponto comum de falha, levando a resultados que não correspondiam semanticamente à intenção do utilizador.
O LLM identificou corretamente que a frase “pontuação média mais alta” requer agrupar os dados por distrito (GROUP BY dname) e usar uma função agregada (AVG(AvgScrRead)). Esta parte da lógica está correta.
No entanto, o LLM falhou ao incorporar um filtro crítico da pergunta: a palavra “ativo“. Para cumprir este requisito, a consulta precisava de fazer uma JUNÇÃO da tabela satscores com a tabela schools e depois filtrar os resultados com uma cláusula WHERE T1.StatusType = ‘Active’.
Isto destaca uma falha comum dos LLMs: executar corretamente uma instrução primária e óbvia (calcular uma média) enquanto falha numa condição secundária mas igualmente importante (filtrar por status). Isto mostra uma fraqueza em sintetizar múltiplas restrições numa única consulta correta.
Filtros ausentes ou errados
Os modelos por vezes falharam ao incluir cláusulas `WHERE` necessárias ou selecionaram as colunas erradas na instrução `SELECT`, não abordando totalmente as restrições ou a informação explicitamente solicitada no prompt.
O LLM identificou corretamente a lógica para encontrar a escola (`ORDER BY NumGE1500 DESC LIMIT 1`), mas falhou ao selecionar o número de `Telefone` solicitado e omitiu a junção necessária à tabela `schools` para o recuperar.
Estes erros resultam frequentemente duma análise incompleta do pedido do utilizador ou da incapacidade de mapear todas as partes do pedido para os componentes finais da consulta SQL.
Erros de sintaxe
Além dos erros semânticos, ocorreram erros de sintaxe puros, 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 numa sintaxe SQL inválida.
Estes problemas de sintaxe destacam os desafios em gerar 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ários fatores-chave determinam quão bem um Grande Modelo de Linguagem (LLM) pode transformar uma pergunta em inglês simples numa consulta de banco de dados SQL correta.
1. Tamanho do modelo e dados de treino
- 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 vir muitos exemplos de perguntas ligadas a respostas SQL, especialmente aquelas envolvendo operações complexas como junções ou cálculos (SUM, AVG), provavelmente terá um melhor desempenho.
2. Ajuste fino para tarefas de SQL
- Os modelos podem receber treino extra focado especificamente em tarefas de texto-para-SQL. Este "ajuste fino" ajuda-os a entender estruturas de banco de dados e regras de SQL de forma mais eficaz do que modelos treinados em texto geral. O treino com instruções específicas também ajuda.
3. Capacidades de raciocínio e mapeamento de esquema
- Raciocínio: Quão bem pode o LLM descobrir os passos exatos necessários a partir de uma pergunta por vezes vaga? Criar SQL frequentemente requer passos lógicos.
- Compreender o mapa do banco de dados (Esquema): Alguns LLMs são melhores a conectar conceitos na pergunta (como "clientes" ou "vendas totais") aos nomes reais das tabelas e colunas no banco de dados, mesmo que os nomes não sejam imediatamente óbvios.
Como os LLMs geram SQL: Um olhar 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 é alimentado por uma técnica chamada Geração Aumentada por Recuperação (RAG).
Fase 1: Análise inicial e seleção do banco de dados
Quando lhe é apresentada uma pergunta, o LLM primeiro analisa a intenção do utilizador para selecionar a ferramenta de banco de dados mais relevante.
- Pergunta: “Quantas contas têm uma disposição do titular e pedido para que seja gerado um extrato após uma transação?”
- Ação do 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 detrimento de outras comocalifornia_schoolsousuperhero.
Fase 2: Recuperando o esquema via RAG
Uma vez que o modelo escolhe uma ferramenta, precisa do “mapa” do banco de dados, o esquema. Ele não tem esta informação memorizada. Em vez disso, o sistema de RAG recupera-a em tempo real.
- Recuperação: A pergunta do utilizador é usada para pesquisar uma base 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. - Aumentação: Este texto de esquema recuperado é automaticamente inserido no prompt juntamente com a pergunta original.
- Geração: O LLM agora tem todo o contexto necessário para prosseguir.
Este processo de RAG garante que o modelo recebe a informação de esquema necessária, tornando a sua tarefa mais focada e eficiente.
Fase 3: Raciocínio e construção da consulta
Com a pergunta e o esquema fornecido pelo RAG, o modelo mapeia os conceitos do pedido do utilizador para os nomes específicos de tabelas e colunas que acabou de receber.
Monólogo interno do LLM:
- Objetivo: O utilizador quer uma contagem, então vou começar com
SELECT COUNT(...). - Condições:
- “…disposição do titular…” -> O esquema da tabela
disptem uma colunatype. Preciso de uma cláusulaWHEREparatype = 'OWNER'. - “…que seja gerado um extrato após uma transação…” -> O esquema da tabela
accountstem uma colunafrequency. O filtro deve serfrequency = 'POPLATEK PO OBRATU'.
- “…disposição do titular…” -> O esquema da tabela
- Junções: A informação está dividida entre as tabelas
accountsedisp. O esquema mostra que estão ligadas poraccount_id, então preciso de asJOIN.
Fase 4: Gerando o SQL final
Finalmente, o modelo monta estas peças lógicas numa consulta SQL sintaticamente correta. A qualidade deste resultado depende de:
- Capacidade de raciocínio: A capacidade do modelo de conectar logicamente o pedido do utilizador ao esquema fornecido.
- Conhecimento de SQL do treino: A compreensão central do modelo sobre a 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 claramente, o LLM deve fazer uma suposição fundamentada, o que pode levar aos erros que analisámos anteriormente.
O que é texto-para-SQL?
Texto-para-SQL é uma tecnologia de processamento de linguagem natural que converte a linguagem do dia a dia numa consulta SQL escrita em linguagem de consulta estruturada. Em vez de escrever código SQL manualmente, um utilizador faz uma pergunta em linguagem natural, e o sistema gera uma instrução SQL que pode ser executada num banco de dados.
O principal propósito do texto-para-SQL é reduzir a lacuna entre como as pessoas pensam sobre os dados e como os bancos de dados exigem que as consultas sejam escritas. Isto é especialmente relevante para utilizadores não técnicos e analistas de dados que entendem o contexto de negócio mas podem não se sentir confortáveis a escrever sintaxe SQL de raiz.
A um nível básico, quando um utilizador faz uma pergunta como:
- “Mostra todos os clientes de Nova Iorque que fizeram compras no mês passado.”
O sistema traduz esse pedido numa 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 do resultado depende se o sistema consegue gerar consultas precisas que reflitam tanto a intenção do utilizador como o esquema do banco de dados.
Onde o texto-para-SQL é útil hoje
O texto-para-SQL funciona razoavelmente bem para:
- Gerar rascunhos de consultas que os analistas de dados podem rever e ajustar.
- Apoiar a análise exploratória de dados onde a velocidade importa mais do que a precisão.
- Permitir que utilizadores não técnicos acedam a dados simples através de esquemas predefinidos.
- Auxiliar utilizadores de SQL reduzindo a necessidade de escrever consultas repetitivas.
Nestes casos, o texto-para-SQL funciona como uma ferramenta de IA assistiva em vez de um sistema autónomo. A revisão humana permanece parte do fluxo de trabalho, especialmente quando a correção é importante.
Como funciona o texto-para-SQL?
Os sistemas modernos de texto-para-SQL dependem de grandes modelos de linguagem treinados em pares de perguntas em linguagem natural e consultas SQL. Estes modelos aprendem padrões que conectam a linguagem do dia a dia a estruturas SQL, nomes de tabelas, colunas e relacionamentos. O processo tipicamente segue uma sequência de passos:
Compreensão de linguagem natural
O sistema primeiro analisa a entrada do utilizador para determinar a intenção, restrições e entidades. Este passo envolve:
- Identificar o que o utilizador está a pedir (por exemplo, totais, filtros, comparações)
- Extrair condições relevantes como intervalos de tempo, localizações ou categorias
- Interpretar frases ambíguas que podem exigir contexto de negócio
Erros nesta fase levam frequentemente a uma consulta SQL com aparência correta que responde à pergunta errada.
Mapeamento de esquema
De seguida, o sistema mapeia os termos da pergunta para o esquema do banco de dados. Isto inclui:
- Fazer corresponder conceitos na pergunta a nomes de tabelas e colunas
- Compreender os relacionamentos entre tabelas
- Respeitar os tipos de dados, como datas, campos numéricos ou categorias
O mapeamento de esquema torna-se mais desafiante à medida que o número de tabelas aumenta ou quando os nomes das colunas não correspondem exatamente à forma como os utilizadores descrevem os dados em perguntas de linguagem natural.
Construção da consulta SQL
Uma vez identificados a intenção e os elementos do esquema, o sistema constrói a consulta SQL. Isto 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
Nesta fase, o sistema pode facilmente produzir SQL válido mas logicamente incorreto, por exemplo, usando a 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 otimização limitada ou fazer perguntas de seguimento quando a consulta é ambígua.
No entanto, a validação raramente garante uma resposta correta. Uma consulta pode executar com sucesso e ainda estar incorreta de formas subtis.
Limitações e riscos práticos
Apesar das fortes pontuações em benchmarks, o uso no mundo real expõe várias limitações que não podem ser ignoradas.
Fiabilidade e correção
Mesmo os modelos de melhor desempenho falham em produzir SQL correto para uma parte 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 em vez de sintáticos
- Junções, filtros ou agregações incorretas podem passar despercebidas
Isto é particularmente arriscado em sistemas de relatórios, previsões ou apoio à decisão, onde os utilizadores assumem que o resultado está correto.
Dependência da supervisão humana
Dado o desempenho atual, o SQL gerado deve ser revisto por alguém que entenda SQL e o banco de dados. Sem esta supervisão:
- Os utilizadores podem confiar numa consulta incorreta porque esta executa com sucesso
- Os erros podem propagar-se para painéis de controlo, relatórios ou sistemas a jusante
- A responsabilização torna-se pouco clara quando as decisões dependem de resultados gerados por IA
O texto-para-SQL não remove a necessidade de especialização em SQL; muda onde essa especialização é aplicada.
Teto de complexidade
À medida que a complexidade da consulta aumenta, o desempenho cai drasticamente. Os modelos têm dificuldades com:
- Múltiplas junções entre 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 o BIRD-SQL destacam que as consultas complexas continuam a ser o principal ponto de falha, mesmo para modelos avançados.
Variabilidade do modelo
As diferenças de desempenho entre modelos são significativas. Alguns modelos de linguagem têm um desempenho razoavelmente bom, enquanto outros falham frequentemente no mesmo conjunto de dados. Isto significa:
- A seleção do modelo tem um impacto direto na precisão
- O ajuste fino e os dados de treino 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 todos os bancos de dados e casos de uso.
Governança de dados e privacidade
Os sistemas de texto-para-SQL introduzem riscos de acesso adicionais:
- Os utilizadores podem consultar tabelas sensíveis sem compreender as implicações
- O SQL gerado pode expor metadados sobre o esquema do banco de dados
- Os controlos de privacidade de dados devem ser aplicados fora do modelo de linguagem
Sem controlos de acesso fortes, o texto-para-SQL pode enfraquecer as práticas de governança existentes.
Adicionar como fonte preferencialMetodologia de benchmark para texto-para-SQL
Este benchmark partilha a sua estrutura de avaliação com o nosso benchmark de RAG agêntico, que descreve a construção do conjunto de dados, a arquitetura do agente, o desafio de ambiguidade semântica e a rubrica de pontuação completa em detalhe.
Ambos os benchmarks usam o mesmo subconjunto de 500 perguntas do BIRD-SQL1 , pipeline agêntico, recuperação de esquema apoiada por ChromaDB e avaliação de LLM-como-Juiz com o Claude 4 Sonnet. A métrica reportada aqui, taxa de geração de comandos SQL corretos, é a percentagem de perguntas em que o modelo tanto encaminhou para o banco de dados correto como 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 adicional
Explore outros benchmarks de RAG, tais como:
- Modelos de Embedding: OpenAI vs Gemini vs Cohere
- Melhor Base de Dados Vetorial para RAG: Qdrant vs Weaviate vs Pinecone
- RAG Híbrido: Aumentando a Precisão do RAG
- Benchmark de RAG Agêntico: encaminhamento multi-banco de dados e geração de consultas
- Top 10 modelos de embedding multilíngues para RAG
Perguntas frequentes
Com base nas nossas descobertas, não deve confiar totalmente em consultas complexas geradas pelos atuais LLMs sem validação. Embora sejam úteis para rascunhos e pedidos simples, mesmo os modelos de melhor desempenho têm taxas de erro significativas (até 20% em tarefas complexas). Reveja e verifique sempre o SQL gerado, especialmente para aplicações críticas.
Sim, muitos LLMs têm capacidades além da simples geração de SELECT. Frequentemente, podem auxiliar na compreensão e sugerir modificações ao código SQL existente ou até gerar DDL (Linguagem de Definição de Dados) como instruções CREATE TABLE com base em descrições, embora a precisão para estas tarefas também exija verificação.
Fornecer um contexto claro é fundamental. Garanta que o LLM tem acesso ao esquema do banco de dados (nomes de tabelas, nomes de colunas, relacionamentos). Declarar claramente o resultado desejado e potencialmente fornecer alguns exemplos de consultas relevantes (prompting few-shot) para o LLM aprender pode melhorar significativamente a sua capacidade de selecionar as tabelas corretas e construir consultas precisas.
Embora os LLMs possam abstrair algumas pequenas diferenças de sintaxe entre dialetos de banco de dados, eles não resolvem totalmente os problemas de compatibilidade de tipo/versão de banco de dados. Podem ainda gerar SQL específico para um dialeto (ex., PostgreSQL vs. MySQL) ou falhar ao usar funções compatíveis com versões mais antigas, a menos que sejam explicitamente guiados ou treinados para tal. A validação contra o banco de dados alvo 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 LLMs}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Acessado em 17 Julho 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.