O que muda nos LLMs para análise de dados em 2026

A virada silenciosa: de «perguntar ao modelo» a «orquestrar agentes sobre o dado»

Durante 2024 e boa parte de 2025, a conversa sobre modelos de linguagem aplicados à análise de dados girava em torno do chat: colar um CSV, pedir um gráfico, obter uma tabela. Esse padrão está se esgotando. O que domina as novidades recentes é outra coisa: modelos que não respondem com texto, mas que executam código, consultam catálogos, validam suposições e devolvem resultados auditáveis.

A diferença prática é enorme. Um chat que «interpreta» um CSV alucina linhas e médias com uma facilidade preocupante. Um agente que executa SQL ou Python contra um armazém real não pode inventar um número sem que o motor de banco de dados proteste. Esse é o eixo da mudança: o modelo deixa de ser o analista e passa a ser o planejador que escreve consultas e verifica resultados.

Text-to-SQL maduro: onde funciona e onde continua quebrando

A geração de consultas SQL a partir de linguagem natural é a aplicação mais difundida, e também a mais supervalorizada em demos. Segundo documentação oficial dos principais provedores de bancos de dados analíticos, os benchmarks públicos de text-to-SQL melhoraram de forma sustentada, mas esses números são obtidos sobre esquemas limpos, com nomes de colunas autoexplicativos e sem ambiguidade semântica.

Em um armazém real, a coisa muda. Um caso que se repete: a tabela se chama fact_ventas_v3, existe uma fact_ventas_v2 que já não é atualizada mas continua viva, e há uma coluna importe que na verdade está em centavos nas linhas anteriores a uma migração específica. Nenhum modelo adivinha isso. Quem resolve é um catálogo de dados com descrições, linhagem e regras de negócio documentadas.

O que está funcionando

• Consultas de exploração sobre um domínio delimitado (um departamento, um conjunto fechado de tabelas).
• Tradução de perguntas frequentes em consultas parametrizadas previamente revisadas por um humano.
• Geração de rascunhos de SQL que um analista corrige em segundos em vez de escrevê-los do zero.

O que não funciona (e convém admitir)

• Perguntas que exigem conhecer definições de negócio não escritas («clientes ativos» pode significar cinco coisas diferentes).
• Esquemas com centenas de tabelas sem descrições: a taxa de erro dispara.
• Cálculos em que um JOIN mal escolhido duplica linhas e ninguém detecta até que o relatório chegue à diretoria.

Agentes com execução de código: o padrão que se impõe

A abordagem que mais cresceu consiste em dar ao modelo um interpretador de código isolado. O modelo escreve pandas, DuckDB ou R, executa, lê a saída e, se houver um erro, itera. Isso tem uma vantagem decisiva para a análise: o resultado é reproduzível. Você pode guardar o script, versioná-lo e executá-lo novamente no mês seguinte.

Aqui há um detalhe que só se aprende usando essas ferramentas diariamente: a maioria das falhas não vem do raciocínio estatístico, mas da gestão de tipos e valores nulos. Datas em formatos misturados, categorias com espaços finais, valores com vírgula decimal herdados de uma exportação antiga. Um modelo potente escreve um groupby impecável e depois agrupa mal porque «Madrid» e «Madrid » são dois valores distintos. A solução não é um modelo melhor: é uma camada de limpeza prévia e validações explícitas.

Integração com o stack: MCP e catálogos semânticos

A novidade arquitetônica mais relevante dos últimos meses é a padronização de conectores. O protocolo aberto promovido para conectar assistentes a fontes de dados (conhecido como MCP) está permitindo que um mesmo modelo consulte um armazém, um CRM e uma planilha sem que cada integração seja um desenvolvimento sob medida.

Isso tem uma consequência que as organizações estão começando a assumir: o valor já não está no modelo, está na camada semântica. Definir métricas uma única vez (receita líquida, churn, margem) e expô-las como ferramentas que o modelo pode invocar é o que separa um piloto vistoso de um sistema que sobrevive ao terceiro mês.

Um padrão que aparece em equipes que já passaram da fase de teste: menos prompts longos, mais funções registradas com nome e descrição precisa. O modelo escolhe entre dez ferramentas bem documentadas em vez de improvisar SQL sobre cinquenta tabelas.

Avaliação: o problema que quase ninguém resolve bem

Medir se um LLM analisa bem é mais difícil do que fazê-lo funcionar. Os benchmarks públicos não refletem o seu dado. A prática que está se consolidando entre equipes maduras é construir um conjunto de perguntas com resposta verificada manualmente sobre o próprio armazém, e executá-lo a cada mudança de modelo ou de prompt.

Sem esse conjunto de avaliação, qualquer migração para um modelo novo é uma aposta às cegas. E aqui há um detalhe que convém ter presente: melhorar em um benchmark genérico não garante melhorar no seu domínio. Vimos modelos que pioram o desempenho em tarefas de agregação com hierarquias de datas porque mudam o estilo de raciocínio, não porque sejam piores.

Custo e latência: o fator que decide a arquitetura

Uma análise interativa tolera dois segundos de espera; um relatório programado que é executado sobre milhares de linhas toda noite não tolera o custo de um modelo grande por cada consulta. Daí a tendência a arquiteturas híbridas:

• Modelos pequenos ou regras determinísticas para as perguntas frequentes e bem tipificadas.
• Modelos grandes apenas para a exploração aberta e a depuração de erros.
• Cache de resultados para consultas repetidas, que na prática são a maioria.

O gasto em tokens se converte em uma linha de custo operacional real quando o sistema é usado por vinte pessoas diariamente. Projetar sem levar isso em conta é o caminho rápido para que o projeto seja cancelado.

Governança e privacidade: a conversa que chega tarde, mas chega

Enviar dados de clientes a um provedor externo exige revisar contratos, retenção e residência do dado. As opções de implantação privada e os modelos executados em infraestrutura própria amadureceram o suficiente para serem viáveis em setores regulados, embora com um custo de manutenção que muitas empresas subestimam.

Um erro habitual: assumir que «o provedor não treina com meus dados» resolve o problema. Não resolve se o dado sai do seu perímetro. A decisão real é arquitetônica, não contratual.

O que observar nos próximos meses

1. Verificação de resultados: mecanismos que contrastam a saída do modelo com uma fonte de verdade antes de mostrá-la.
2. Linhagem automática: saber de qual tabela e de qual transformação sai cada número que o sistema apresenta.
3. Interfaces híbridas: o chat não desaparece, mas convive com dashboards em que o LLM apenas redige a explicação do gráfico.
4. Avaliação contínua: suítes próprias que são executadas a cada atualização do modelo.

A conclusão honesta é que os LLMs já trazem valor claro em exploração, documentação de dados e geração assistida de consultas, e continuam frágeis em qualquer tarefa em que um número errado tenha consequências. Projetar com essa assimetria em mente, colocando o dado e a validação no centro e o modelo na periferia, é hoje a diferença entre um experimento e um sistema em produção.