Por Que LLMs Brutos Falham em Analytics: A Resposta da Anthropic é Engenharia de Dados

O time interno de data science e engenharia da Anthropic publicou um post-mortem detalhado em junho de 2026 descrevendo como automatizaram 95% de suas consultas de business analytics através do Claude, com 95% de acurácia agregada. O artigo é notável não pelo número em destaque, mas pelo que revela sobre modos de falha — e pela admissão explícita de que um LLM bruto apontado para um data warehouse responde corretamente apenas 21% das perguntas de analytics.

A acurácia de analytics é um problema de contexto e verificação, não de geração de código. O time identificou três modos de falha. Ambiguidade conceitual-entidade: "revenue" sozinho mapeia para 40 tabelas plausíveis em seu warehouse, então o agente escolhe o campo errado mesmo quando a sintaxe da query é limpa. Obsolescência de dados: schemas e definições de métricas mudam diariamente, e documentos que descreviam corretamente o warehouse no lançamento decaíram de 95% de acurácia para 65% em um mês antes do time tratar manutenção como uma disciplina de engenharia. Falha de recuperação: os dados e documentação corretos existem, mas em um warehouse com milhões de campos, o agente passa por eles.

Anthropic construiu o que chamam de uma agentic analytics stack em quatro camadas, rodando em Claude Code. A camada de data foundations impõe um warehouse canonizado e governado — modelagem dimensional, shift-left testing, verificações de freshness e completude. A camada sources-of-truth adiciona uma semantic layer de definições de métricas e dimensões que agentes devem consultar primeiro, um lineage graph, e um company knowledge graph cobrindo docs indexados, roadmaps e decision logs. Skills — pastas de markdown que Claude lê sob demanda — codificam conhecimento procedural: uma knowledge skill roteia o agente para aproximadamente 30 arquivos de referência por domínio descrevendo tabelas, colunas, joins e armadilhas antes de qualquer SQL ser escrito. Uma camada de validação fecha o loop com suites de evals offline conectadas a CI, revisão adversarial de cada resposta, e footers de provenance.

A camada de skills impulsiona o salto de acurácia. Sem ela, Claude ficava abaixo de 21% em evals internos. Com ela, a acurácia agregada supera 95% e alguns domínios atingem 99%. Revisão adversarial dentro do loop de resposta adiciona 6% à acurácia ao custo de 32% mais tokens e 72% de latência maior — um tradeoff que times devem precificar explicitamente.

Dois experimentos que o time rodou e descartou merecem menção. Primeiro, tentaram auto-gerar definições de métricas a partir de tabelas brutas e histórico de queries. As definições geradas codificavam as ambiguidades que estavam tentando eliminar; evals mostraram que era net-negativo. Regra em que chegaram: Claude redige a documentação, um humano possui e aprova a definição. Segundo, deram ao agente acesso bruto de recuperação a milhares de queries SQL históricas — a resposta correta estava presente em aproximadamente 80% delas. A acurácia melhorou em menos de um ponto percentual. Acesso não era o gargalo; estrutura era.

O risco operacional que mais importa é skill decay. A acurácia caiu de 95% para 65% em um único mês quando arquivos de skills ficaram atrás de mudanças de schema. Seu fix: colocar arquivos de skill markdown no mesmo repositório que modelos de transformação dbt para que o pull request que muda um modelo seja o mesmo pull request que atualiza a skill. Um code-review hook sinaliza qualquer mudança de reporting-model que não toque um arquivo de skill. Aproximadamente 90% dos data-model PRs agora incluem uma mudança de skill no mesmo diff. Consistent-surface é uma restrição adicional: a mesma skill deve retornar respostas consistentes em Slack, IDE, ferramenta de dashboard e sessões standalone do Claude Code.

A recepção da comunidade de dados tem sido mista. Críticos apontam que uma taxa de erro de 5% é inaceitável para reporting business-critical e que outputs de analytics devem ser determinísticos e idempotentes. AtScale benchmarkou uma configuração comparable semantic-layer-first em um banco Tier 1 e encontrou que reduziu compute em até 21.000× enquanto elevou acurácia de 70% para 100%. O time da Anthropic não afirma que a abordagem se generaliza out of the box; o post lê-se como um blueprint para times dispostos a investir em data foundations primeiro.

Um LLM frontend em um warehouse mal governado não herda a autoridade do warehouse — herda sua ambiguidade. A stack que o leva a 95% é majoritariamente engenharia de dados.