Um LLM que lê uma tabela chamada « txn » com uma coluna « amt » não vai entender nada. Ele vai alucinar. Você pode culpá-lo, mas é você quem deve ser culpado - a modelagem é catastrófica.
Eis o problema em produção atualmente. Implantam-se ferramentas de text-to-SQL sem fazer o trabalho básico: explicar claramente aos dados o que eles são. É como dar uma query SQL a um analista usando nomes de variáveis aleatórios. Péssima ideia.
Na Bomzai, vimos os números: quando a modelagem é boa, a precisão passa de 50% para 90% em 6-12 meses. Não por mágica. Por clareza.
Os nomes são 60% da batalha
Primeira regra, estupidamente simples mas ignorada em todo lugar: as colunas devem ter nomes explícitos. Sem abreviações. Sem códigos crípticos.
« order_date » em vez de « order_dt ». « customer_id » em vez de « cust_id ». « order_revenue_usd » em vez de « revenue ». Os números são claros: com nomes explícitos, os LLM cometem 45% menos erros.
Por quê? Porque uma coluna chamada « amount » gera dúvidas: são todos os valores ou apenas as vendas? Com « order_sales_amount », não há dúvida.
Os prefixos ajudam. « is_ » para booleanos (is_active, is_premium). « cnt_ » para contagens. « amt_ » para valores monetários. É uma convenção simples. Ninguém a segue. Quase todos sofrem.
Cada coluna deve vir com um manual de instruções
Uma tabela no dbt não é apenas colunas. É uma descrição, uma granularidade, uma fonte, uma frequência de atualização. Cada coluna: seu tipo, sua lógica de negócio, seus valores possíveis, seus casos limites.
Exemplo concreto: « customer_region » não é apenas uma string. É uma dimensão com os valores (EMEA, APAC, AMERICAS). « order_date » tem um formato (YYYY-MM-DD) e uma granularidade (dia). « total_revenue » deve ter regras explícitas: incluir ou excluir o quê, filtrar como.
As relações entre tabelas devem ser explícitas. Um pedido tem UM cliente, UM produto. Sem ambiguidade.
Quando um LLM tem acesso a esses metadados enriquecidos, ele consegue raciocinar corretamente. É exatamente como dar a um analista humano o contexto necessário para responder sem erros.
O Semantic Layer: a camada de interface
Em produção, o Semantic Layer (dbt Semantic Layer, Cube.dev, AtScale) se torna a verdadeira interface. Não tabelas brutas expostas. Métricas e dimensões com definições rígidas.
Um LLM que constrói sobre um Semantic Layer gera automaticamente SQL correto. Por quê? Porque o perímetro é claro. Sem ambiguidade sobre « revenue » - existe apenas uma definição oficial.
É também a principal alavanca para a governança. Quando a lógica muda (nova definição de churn), atualiza-se uma vez, usa-se em todo lugar. Não 47 queries ad hoc para corrigir.
Melhoria contínua baseada nos erros
Em produção, coletam-se as alucinações. Quando o LLM gera uma query falsa, é um sinal: o que está faltando na modelagem?
Coluna mal nomeada? Renomeie-a. Metadado confuso? Esclareça-o. Join complicado? Esconda-o sob uma intermediária mais clara.
É engenharia de software aplicada à modelagem. Testes automatizados: « para essa pergunta, o LLM deve gerar esse SQL exato ». Se o teste falha, é um sinal para remodelar.
As melhores equipes que vi usam um loop: pergunta → LLM → SQL gerado → validação → feedback → remodelagem. Leva 12 meses para chegar a 90% de precisão, mas chega.
Não é técnica, é clareza
A modelagem para o text-to-insight não é um assunto técnico esotérico. É extremamente pragmático.
Nomes explícitos. Documentação completa. Metadados enriquecidos. Semântica cristalina. Quando uma IA consegue ler e entender os dados diretamente, ela gera SQL correto. 80% do sucesso do text-to-insight vem daí. Os 20% restantes? É a escolha das ferramentas.
Muitos fazem o inverso: investem nos melhores LLM (Claude, GPT-4) e negligenciam a modelagem. Resultado: um bom LLM que alucina sobre dados mal documentados. Desperdício.
Comece pela base. Os nomes. A documentação. O Semantic Layer. Depois, o LLM brilha.
Não é rápido. Não é sexy. Mas é onde os resultados mensuráveis chegam.
