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