Agentic RAG em produção: o agente decide 4 vezes na mesma pergunta - alucinação cai 3x, custo dobra

Passei os últimos três anos empilhando vector search e chamando aquilo de RAG. Em quase todo cliente. Funcionava até o momento em que o produto ia pra frente do usuário real e devolvia resposta segura, autoritária, e completamente errada.

Aí li Anthropic e Boris Cherny dizendo que dentro do Claude Code eles abandonaram RAG e voltaram pra grep. Achei que era hype. Coloquei Agentic RAG em produção por 30 dias, com 4 iterações do agente por pergunta, e medi tudo.

O resultado é chato de contar em call de cliente: alucinação caiu 3x, custo dobrou. Ninguém publica isso porque não vende curso, mas é o trade-off real. Vou mostrar os números.

O que estou chamando de Agentic RAG (versão curta)

RAG normal: vetoriza pergunta, busca top-k, joga no prompt, gera resposta. Uma decisão de busca. Estática.

Agentic RAG: o agente decide como buscar, olha o resultado parcial, decide se busca de novo com outra estratégia (semântica, palavra-chave, grep, web), até ter confiança suficiente. É o mesmo laço que Claude Code usa quando você pede pra explicar um bug: grep, cat, grep de novo com padrão refinado, ler o teste, responder.

O ponto do “agentic” é que a estratégia de busca não é fixa. E cada decisão custa uma chamada de LLM extra.

Meu setup de teste (30 dias, 1200 perguntas)

Dois sistemas, mesma base de conhecimento (docs técnicos internos, ~40k arquivos), mesmo modelo (Sonnet 4.6):

Aspecto	RAG estático	Agentic RAG (4 iter)
Estratégia de busca	vector top-10, fixo	agente escolhe entre vector / bm25 / grep / web
Chamadas de LLM por pergunta	1	1 planejador + até 4 buscas + 1 síntese = até 6
Iterações permitidas	0	4 (parada antecipada se confiança > 0.85)
Ferramenta	LangChain + Chroma	LangGraph + toolset custom

Foram 1200 perguntas de usuários reais em 30 dias, mesma população, load balanceado 50/50.

Números que mudei de opinião

Alucinação: 3.2x menos

Rotulei alucinação como “resposta com afirmação factual não presente em nenhum dos documentos recuperados nem verdade externa checável”. Amostrei 200 respostas de cada lado à cega.

• RAG estático: 41 respostas alucinadas em 200 → 20.5%
• Agentic RAG (4 iter): 13 respostas alucinadas em 200 → 6.5%

3.15x melhor. Não é 10x mágico de LinkedIn post, mas em produção a diferença entre 1 em 5 e 1 em 15 respostas erradas é a diferença entre o produto sair da beta ou não.

Custo: 2.1x mais

Contei tokens de entrada + saída de todas as chamadas de LLM por pergunta.

• RAG estático: ~4.800 tokens por pergunta média
• Agentic RAG (4 iter): ~10.100 tokens por pergunta média

2.1x. Vindo de $0.014 por pergunta pra $0.029 por pergunta em Sonnet 4.6. Em 1200 perguntas/dia isso é uma diferença de $18/dia, ou $540/mês. Não é o fim do mundo, mas também não é zero.

Latência: 2.7x mais lenta

O que ninguém fala no LinkedIn de Agentic RAG:

• RAG estático: mediana 1.8s, p95 3.2s
• Agentic RAG (4 iter): mediana 4.9s, p95 11.4s

p95 de 11 segundos é onde o usuário fecha a aba. Precisei colocar streaming da síntese pra coisa parecer viva. E colocar um cap de “no máximo 4 iterações”, porque quando eu deixei 8, teve pergunta que rodou 22 segundos.

O trade-off honesto: quando compensa, quando não compensa

Depois de 30 dias, minha regra de decisão ficou assim:

Compensa Agentic RAG quando:

• A pergunta ambígua é a norma, não a exceção. Se o usuário digita “erro do login” e você tem 400 arquivos com a palavra “login”, o agente precisa refinar. RAG estático joga os 10 primeiros e reza.
• O custo de uma resposta errada é maior que $0.015 (o extra por pergunta). Suporte técnico, área médica, análise jurídica. Não vale a pena pra “qual foi o gol do Neymar em 2015”.
• Você tem streaming e o usuário tolera 5 segundos.

Não compensa quando:

• A base é pequena (< 500 docs) e bem estruturada. RAG estático + top-5 já cobre.
• Volume é altíssimo (> 100k/dia) e alucinação de 20% é aceitável. O extra de custo vira dinheiro grande rápido.
• Latência tem que ser < 2s. Chatbot de e-commerce típico não sobrevive ao Agentic RAG.

O que eu mudaria da próxima vez

Três coisas.

Primeiro, parada antecipada mais agressiva. Confiança > 0.85 depois da segunda iteração já é bom o suficiente na maioria dos casos. Quatro iterações ganha ~0.5 ponto percentual de qualidade e custa mais 40% de tokens. Ficou over-engineered.

Segundo, cache do plano de busca. Perguntas parecidas repetem o mesmo padrão de estratégia (grep primeiro, depois semântica). Cachear o plano por hash de intenção corta 30% do custo de planejamento e mantém a qualidade.

Terceiro, híbrido explícito. Rotear “perguntas fáceis” (detectadas por classificador leve, tipo Haiku) pro RAG estático, e “perguntas difíceis” pro Agentic. Testei isso na semana passada: 65% das perguntas caem no fácil, custo médio cai 40%, qualidade quase igual à Agentic pura.

Se eu tivesse começado por aqui, teria economizado três semanas.

O que quase ninguém publica sobre Agentic RAG

Duas coisas que ficam de fora nos posts otimistas:

A qualidade não escala linear com iterações. De 1 pra 2 iterações, alucinação cai 40%. De 2 pra 3, cai mais 15%. De 3 pra 4, cai mais 5%. De 4 pra 8, cai mais 2%. Depois disso vira ruído. Quatro é onde o joelho da curva mora, pelo menos na minha base.

O agente aprende a ser preguiçoso quando o prompt permite. Deixei o planejador escolher “nenhuma busca adicional” como ação válida na iteração 2. Ele escolheu isso em 34% das perguntas. Alucinação subiu de volta pra 12%. Removi a opção e voltou pra 6.5%. Modelo grande economiza esforço se você não força.

Fechando

Vector search + top-k + prompt é um padrão que funciona pra demo e quebra em produção quando a pergunta do usuário não bate exatamente com o corpus. Agentic RAG resolve isso, mas cobra 2x em custo e 2.7x em latência. Não existe almoço grátis. Existe almoço melhor por $0.015 a mais por pergunta, se o teu produto puder pagar.

Se estiver pensando em migrar, faça o híbrido primeiro. Rotear por dificuldade da pergunta é o move de maior retorno pelo menor esforço.

Os experimentos, o setup do LangGraph e a matemática de custo iteração-a-iteração estão detalhados no livro Context Engineering em Português (capítulos 11a e 11b). Deixo aqui pra quem quiser reproduzir o teste na própria base.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews