NL2SQL em 2026: da tradução de perguntas para SQL aos agentes de dados

Imagine um diretor comercial perguntando:

“Quais clientes reduziram suas compras em mais de 20% nos últimos seis meses em comparação com o mesmo período do ano passado?”

Para responder diretamente em um banco de dados, alguém precisa identificar o que significa “compras”, descobrir as tabelas corretas, relacioná-las, aplicar períodos, excluir cancelamentos e finalmente produzir uma consulta SQL.

É esse problema que os sistemas NL2SQL — Natural Language to SQL procuram resolver: transformar perguntas feitas em linguagem humana em consultas sobre bancos de dados.

Apesar da popularização recente provocada pelos Large Language Models (LLMs), NL2SQL não nasceu com eles. O problema é estudado há décadas e passou por várias gerações tecnológicas.

Antes dos LLMs: regras, modelos semânticos e redes especializadas

Os primeiros sistemas utilizavam regras, gramáticas, templates e representações semânticas.

Uma pergunta como:

“Faturamento por vendedor no mês passado.”

poderia ser transformada em:

text INTENT: ranking ENTITY: salesperson METRIC: revenue PERIOD: previous_month

Um componente determinístico produziria então o SQL correspondente.

Posteriormente surgiram abordagens baseadas em machine learning, redes neurais, Seq2Seq, Transformers e modelos especializados. Benchmarks como WikiSQL e Spider foram fundamentais para essa evolução.

Essas abordagens tinham uma vantagem: dentro de um domínio bem definido, podiam oferecer comportamento relativamente previsível.

O problema era a flexibilidade. Perguntas como:

“Quem vendeu mais que no mesmo período do ano passado, mas desconsidere clientes novos e devoluções?”

exigem interpretação, decomposição e conhecimento do negócio difíceis de antecipar através de regras.

A chegada dos LLMs

Os LLMs mudaram radicalmente a capacidade de interpretar perguntas.

A primeira geração moderna de sistemas NL2SQL adotou uma arquitetura bastante simples:

Abordagem NL2SQL simples com LLM, schema e documentação

Essa abordagem funciona surpreendentemente bem em demonstrações, bancos pequenos e consultas relativamente diretas.

Mas existe uma diferença enorme entre produzir SQL plausível e produzir SQL semanticamente correto.

Os benchmarks modernos deixam isso claro. O Spider 2.0 foi criado justamente para aproximar a avaliação de ambientes empresariais reais: possui problemas com bancos que frequentemente ultrapassam mil colunas, diferentes dialetos e workflows SQL que podem envolver dezenas ou mais de cem linhas.

O LiveSQLBench também separa explicitamente modelos que geram SQL diretamente de agentes, capazes de explorar bancos, utilizar ferramentas e executar processos em múltiplas etapas. Mesmo em 2026, seu melhor resultado geral publicado está em 48% de sucesso, demonstrando que o problema está longe de estar resolvido.

O estado da arte: NL2SQL está ficando agêntico

A arquitetura mais avançada deixou de ser simplesmente:

text pergunta → SQL

e passou a se parecer mais com:

Pipeline NL2SQL agêntico com exploração, execução, verificação e correção

O sistema pode inspecionar tabelas, analisar valores, testar consultas, observar erros e tentar novamente.

O BIRD-Interact leva essa ideia ainda mais longe ao avaliar interações conversacionais e agênticas com bancos. O benchmark inclui inclusive situações em que o sistema precisa esclarecer ambiguidades com o usuário. Os resultados mostram que esse continua sendo um problema bastante difícil mesmo para modelos de fronteira.

Também existe outra linha importante: modelos especializados em SQL. O projeto open source XiYan-SQL utiliza filtragem de schema, múltiplos geradores de consultas, refinamento e seleção entre candidatos.

Mais recentemente, o ReViSQL explora treinamento com dados verificados e reinforcement learning with verifiable rewards, mostrando que especializar o próprio modelo continua sendo uma alternativa à construção de pipelines agênticos cada vez maiores.

Portanto, não existe hoje uma única arquitetura vencedora.

O verdadeiro problema empresarial: semântica

Considere um ERP contendo:

text tb_mov tp_mov = 3 st_reg = 'A' cod_nat = 17

O modelo pode conhecer perfeitamente SQL e ainda não saber que determinada combinação representa uma “venda faturada válida”.

O conhecimento relevante pertence à empresa, não ao SQL.

Termos aparentemente simples como:

receita;
cliente ativo;
churn;
margem;
venda líquida;
cliente novo;

podem possuir definições específicas.

É por isso que camadas semânticas ganharam importância.

Arquitetura NL2SQL com plano semântico, validação e geração determinística

Um exemplo open source particularmente interessante atualmente é o WrenAI. Seu núcleo utiliza uma Model Definition Language (MDL) para modelar entidades, relacionamentos e regras de negócio. O agente consulta esse modelo semântico em vez de precisar raciocinar diretamente sobre todas as tabelas físicas.

Outro projeto relevante é o DB-GPT, que evoluiu de uma ferramenta Text-to-SQL para uma plataforma de agentes de dados capazes de combinar SQL, código, ferramentas, arquivos, bases de conhecimento e execução em sandbox.

O Vanna também foi uma referência importante nessa área, especialmente na combinação de recuperação de contexto e Text-to-SQL, mas seu repositório público foi arquivado em 29 de março de 2026 e hoje deve ser tratado mais como referência arquitetural do que como primeira escolha para um novo projeto open source.

Uma arquitetura melhor: semântica primeiro, agente depois

Para sistemas empresariais, eu não recomendaria nem o extremo:

text LLM → SQL livre

nem obrigatoriamente:

text LLM → DSL rígida → SQL

A arquitetura que considero mais interessante hoje é híbrida:

Arquitetura híbrida com camada semântica primeiro e agente SQL como fallback controlado

Para faturamento, churn, margem, MRR ou outros indicadores oficiais, a definição deve estar em uma camada semântica governada. O LLM interpreta a intenção, mas não reinventa a regra de negócio a cada pergunta.

Já para perguntas exploratórias que não cabem nesse modelo, um agente pode gerar SQL dinamicamente, desde que opere com permissões, limites de custo, execução read-only, validação e possibilidade de correção.

A recomendação, portanto, pode ser resumida assim:

Semantic layer first, agentic SQL as controlled fallback.

Nesse desenho, SQL continua extremamente importante, mas deixa de ser a interface conceitual do usuário. O usuário conversa com o modelo de negócio da organização.

O próximo estágio de NL2SQL, portanto, talvez nem deva mais ser chamado apenas de NL2SQL.

Estamos caminhando para algo mais amplo:

Natural Language to Data com um plano semântico reutilizado por diferentes bancos e APIs

Natural Language to Data.

TLDR;

Responder essa pergunta diretamente exige identificar o que a empresa define por "compras", mapear e relacionar as tabelas corretas, excluir cancelamentos, aplicar os períodos e idealmente usar um agente que gere, execute e valide o SQL. A arquitetura recomendada em 2026 é híbrida: camada semântica governada para definições de negócio e um agente SQL controlado como fallback para consultas exploratórias. A garantia de semântica passa por modelar conceitos na camada semântica (por exemplo MDL/WrenAI), validar consultas de forma determinística e limitar agentes com permissões, execução somente leitura e verificação de resultados.

Resumo

NL2SQL transforma perguntas em linguagem natural em consultas SQL, um problema estudado há décadas que evoluiu de sistemas determinísticos (regras, gramáticas, templates) para redes neurais e Transformers, e mais recentemente para Large Language Models (LLMs). Antes dos LLMs, abordagens ML e benchmarks como WikiSQL e Spider trouxeram progresso, mas tinham limitação de flexibilidade frente a ambiguidades e regras de negócio. LLMs melhoraram a interpretação, mas gerar SQL plausível não garante correção semântica; benchmarks empresariais (Spider 2.0, LiveSQLBench) mostram dificuldades reais, com agentes chegando a resultados parciais. A arquitetura moderna é “agêntica”: inspeciona esquemas, executa consultas, verifica erros e corrige iterações. Há também modelos especializados (XiYan-SQL, ReViSQL) e projetos semânticos como WrenAI e DB-GPT que usam uma camada semântica para definir receita, cliente ativo, churn etc. Em sistemas corporativos, recomenda-se uma arquitetura híbrida: camada semântica governada primeiro para métricas oficiais e, como fallback controlado, agentes que geram SQL com limites e validação. Assim, o futuro vai além do NL2SQL tradicional rumo a “Natural Language to Data”, onde o usuário interage com o modelo de negócio da organização. Isso reduz riscos de interpretação errada, aumenta governança dos indicadores e permite consultas exploratórias seguras quando bem monitoradas por equipes de dados responsáveis internas.