Consultar banco de dados em linguagem natural (NL to SQL)

Quase todo dado de empresa mora num banco relacional: o banco do ERP, do sistema de folha, do e-commerce. Para tirar uma resposta dele, alguém precisa escrever uma consulta em SQL, a linguagem que esses bancos entendem. Quem sabe SQL vira gargalo, e quem precisa da resposta espera.

NL to SQL (de natural language to SQL, também chamado de text-to-SQL) é a tradução automática da pergunta escrita em linguagem comum para essa consulta. A pessoa escreve "quais clientes compraram menos neste trimestre do que no anterior", o sistema gera o SQL equivalente, executa no banco e devolve um número, uma tabela ou um gráfico.

A ideia é antiga. As primeiras tentativas dependiam de regras escritas à mão e quebravam com qualquer variação de frase. Os modelos de linguagem atuais mudaram o jogo: eles escrevem SQL correto para perguntas bem formuladas sobre esquemas bem nomeados. O difícil hoje é entender o banco real de uma empresa.

Quando essa capacidade vem dentro de uma ferramenta de análise, com gráficos, painéis e controle de acesso, o nome mais comum é BI conversacional.

Toda demonstração de NL to SQL usa um banco de exemplo com tabelas chamadas clientes, pedidos e produtos, colunas com nomes claros e meia dúzia de relacionamentos. Nesse cenário a IA acerta quase sempre.

O banco de uma empresa de verdade é outra coisa:

• Nomes técnicos. Bancos de ERP costumam ter centenas de tabelas com nomes abreviados ou codificados, herdados de versões antigas do sistema. A coluna que guarda o valor da nota pode ter um nome que só quem implantou entende.
• Regras que não estão no esquema. "Faturamento" é bruto ou líquido de devolução? Pedido cancelado entra? Venda entre filiais conta? Essas regras vivem na cabeça das pessoas e nos relatórios antigos, não nas tabelas.
• Perguntas ambíguas. "Quanto vendemos em setembro" pode significar data do pedido, da nota ou do pagamento. Cada escolha dá um número diferente.
• Relacionamentos que enganam. Juntar duas tabelas pela coluna errada duplica linhas e infla o total sem dar erro nenhum.

O risco principal não é a consulta falhar. É ela rodar, devolver um número plausível e ninguém perceber que está errado. Uma IA que só enxerga nomes de tabela escreve SQL convincente sobre colunas que não entende. Por isso, num banco real, o que decide a qualidade da resposta é o contexto de negócio que a IA recebe, mais do que o modelo usado.

Três coisas separam uma resposta em que dá para confiar de uma resposta bonita.

A primeira é a camada semântica: um glossário que liga os termos do negócio às tabelas, colunas e filtros certos. Ela diz o que é "faturamento" naquela empresa, qual tabela guarda o cadastro de clientes, que filtro separa venda efetiva de orçamento e quais metas e indicadores existem. Montar essa camada dá trabalho e pede alguém que conheça o sistema e o negócio. Sem ela, a IA adivinha.

A segunda é a transparência. Se a ferramenta mostra o SQL gerado e o raciocínio que levou até ele, quem conhece o negócio confere como o número foi montado. Uma resposta que não mostra de onde veio não tem como ser conferida.

A terceira é a validação contra números conhecidos. Antes de liberar para a empresa, faça perguntas cujas respostas a equipe já sabe (o faturamento do mês passado, o total de clientes ativos) e compare. Onde houver diferença, ajuste o glossário e repita.

Dar a uma IA acesso ao banco de produção assusta, e com razão. Os cuidados mínimos são estes:

• Somente leitura, em duas camadas. A ferramenta deve bloquear comandos de escrita antes de executar, e o banco deve receber uma credencial criada só com permissão de consulta. A segunda trava é a que vale se a primeira falhar.
• Sem porta aberta. Para bancos dentro da rede da empresa, um agente instalado na rede que abre uma conexão de saída evita expor o banco à internet.
• Registro de tudo. Cada pergunta e cada SQL executado devem ficar gravados, para a empresa rever o que foi consultado e por quem.
• Permissão por pessoa. Folha de pagamento e margem por cliente não devem aparecer para todo mundo.
• LGPD. Defina quais tabelas e colunas com dados pessoais ficam fora do alcance e registre o tratamento na análise de privacidade da empresa.

Os modelos de linguagem atuais entendem português bem. A dificuldade está no vocabulário de cada empresa: "título", "NF", "pedido faturado", "empenho", "cobertura de estoque". São termos que mudam de sentido de um setor para outro e às vezes de uma empresa para outra do mesmo setor.

É mais um motivo para a camada semântica. Quando o glossário registra que, naquela distribuidora, "positivação" quer dizer cliente que comprou ao menos uma vez no período, a pergunta em português cai na consulta certa. Datas, moeda e separador decimal no formato brasileiro também precisam sair certos na resposta, e não só na pergunta.

O Entendo é a plataforma de BI conversacional da Sozo Data. A pessoa pergunta em português (ou inglês) e recebe a resposta em número, tabela ou gráfico, com o SQL gerado e o raciocínio visíveis para conferência.

• Conecta em PostgreSQL, MySQL, SQL Server, Oracle, Firebird e ClickHouse, além de Google Sheets, CSV e Excel. Se o seu banco não está na lista, construímos o conector sob demanda.
• Bloqueia comandos de escrita antes de executar e registra cada pergunta e cada SQL para auditoria. Recomendamos credencial só de leitura no banco.
• Para bancos dentro da rede da empresa, o Entendo Gateway abre uma conexão de saída criptografada. Não exige porta de entrada nem liberação de IP, e a credencial do banco fica na rede da empresa. O resultado da consulta sobe para a plataforma.
• A camada semântica guarda o glossário, as metas e os KPIs. Montá-la com a sua equipe é o centro da implantação assistida, cobrada à parte.
• Cada versão passa por uma bateria de 128 casos de teste de NL to SQL.

Se o banco que você quer consultar é o do ERP, veja BI conversacional no banco do ERP. Para o produto completo, veja a página do Entendo.