Natural Language to SQL em 2026: o que realmente funciona
Olhar opinativo sobre o estado atual de NL-to-SQL: o que introspecção de schema, consciência de dialeto e loop de execução precisam entregar em produção.
Dois anos atrás, toda demo de natural-language-to-SQL era igual: schema limpo, três tabelas, pergunta 'mostre receita por mês', gráfico saindo. Em 2026 a conversa mudou. Dado de produção real é bagunçado — centenas de tabelas, nomes vagos de colunas, campos JSONB, warehouses particionados, e analistas que aprenderam a desconfiar de qualquer coisa que não mostre o trabalho. Então quais abordagens NL-to-SQL aguentam, e quais ainda não?
Introspecção de schema é inegociável
O maior preditor isolado de acurácia é o quão bem o sistema lê seu schema. Foreign keys, materialized views, formato dos JSONB, colunas de partição — tudo. Sistemas que dependem só do pretraining do LLM falham em produção. Sistemas que pré-indexam cada coluna, cada relação, cada amostra de valores distintos, funcionam.
Na prática, um bom agente NL-to-SQL em 2026 precisa rodar um crawl de schema na conexão, guardar estatísticas de coluna e re-crawlear sob demanda. Não um prompt único com o schema jogado no contexto.
Consciência de dialeto é onde a maioria silenciosamente falha
DATE_TRUNC do Postgres não é DATE_TRUNC do BigQuery. STRING_AGG do SQL Server não é GROUP_CONCAT do MySQL. A grande maioria das implementações 'abre o LLM e reza' gera SQL ANSI que quebra em runtime. A solução é mecânica: diga o dialeto explicitamente ao modelo, valide o SQL com o parser do próprio banco antes de executar e re-prompte se falhar.
O loop de retry importa mais que o modelo
Modelos GPT-class em 2026 são bons o bastante para que o gargalo não seja 'o modelo sabe escrever SQL' — é 'o que acontece quando o SQL falha'. Os sistemas que funcionam em produção pegam o erro, devolvem para o modelo com a query problemática e tentam de novo. Os que não funcionam jogam o erro na cara do usuário.
Um bom loop tem três paradas: (1) check de sintaxe via banco, (2) check de sanidade da amostra (o resultado parece o que foi pedido?), (3) confirmação humana opcional para operações de escrita.
Onde ainda não funciona
- Schemas vagos: uma coluna chamada 'amount' sem comentário, sem foreign key, sem formato consistente. O modelo chuta.
- Window functions sobre partições irregulares. Ainda é propenso a erro.
- Perguntas de negócio multi-step que humanos modelam como uma cadeia de CTEs. O modelo costuma pular agregações intermediárias.
- Qualquer coisa que dependa de conhecimento tribal ('exclua contas internas' — quais são internas?). Sem semantic layer, o modelo não tem como saber.
O que entregamos no Data Talks
Tratamos cada connector como consumidor first-class das regras do dialeto. O agente lê schema na conexão, estatísticas sob demanda, e roda um loop de validação de sintaxe contra o banco real antes de retornar. Cada resposta vem com o SQL bruto para analistas auditarem. Onde ainda não batemos o Wren AI é na semantic layer — está no roadmap.
O recado honesto em 2026: NL-to-SQL está pronto para produção em perguntas analíticas sobre dados bem modelados, com o scaffolding certo em volta do LLM. Não substitui analistas em dados mal modelados. A diferença diminui a cada trimestre, mas ainda não é zero.