Erros de RAG: 6 motivos para a memória do agente de IA travar, e como diagnosticar o retrieval

O RAG (Retrieval-Augmented Generation) conecta uma base de conhecimento externa às respostas do LLM, com a promessa de livrar o modelo das alucinações. Na prática, 73% das falhas em sistemas RAG decorrem de busca ruim, e 40% dos pipelines simplesmente não conseguem recuperar os dados necessários. Os engenheiros costumam tentar tratar os sintomas — trocar o modelo de embedding, aumentar o top-k, atualizar o LLM. Mas se, desde o início, um contexto inadequado entrou no prompt, a camada de retrieval é que está quebrada, e a alucinação é apenas consequência desse erro.

O estudo RAGGED revelou que LLaMA e Claude atingem o pico com apenas 5 chunks, e a partir daí a qualidade despenca rapidamente. A Claude teve o melhor resultado com um único fragmento altamente preciso. Inflar o contexto ao máximo se mostra prejudicial.

Seis pontos de falha

1. O chunking destrói o contexto — a divisão fixa em blocos de 512 tokens separa uma entidade da frase que a qualifica, um chunk sem seu título perde o sentido, e uma tabela de 200 linhas se transforma em ruído. Solução: dividir conforme a estrutura do documento, levar os títulos para cada chunk e usar embeddings contextuais. Segundo a Anthropic, isso reduz os erros em 35%, em 49% combinado com BM25 contextual, e em 67% com reranking.

2. Brecha semântica — os embeddings não captam a intenção. O usuário pergunta "Como cancelo minha assinatura?", enquanto o documento se chama "Política de Encerramento de Conta". Solução: busca híbrida (embeddings + BM25 via Reciprocal Rank Fusion com k=60), reformulação da consulta e HyDE (busca a partir de uma resposta hipotética).

3. Desalinhamento entre retrieval e geração — aumentar o top-k melhora o Hit@k, mas a qualidade da resposta cai depois disso. O estudo de Liu et al., "Lost in the Middle", mostrou que o modelo aproveita melhor as informações no início e no fim do contexto. O valor ideal de top-k é ajustado experimentalmente; o RAGGED mostrou que o ótimo varia de k ≤ 1 a k ≥ 10. O limiar de recall é de 85% — abaixo disso, é preciso corrigir o retrieval.

4. Multi-hop — o RAG não sabe raciocinar em cadeia. A pergunta "Quem é o CEO da empresa adquirida pelo fornecedor de um concorrente?" exige quatro etapas de busca. Solução: RAG iterativo (agêntico) ou memória baseada em grafos (Neo4j, Cognee, Microsoft GraphRAG). O custo é mais latência e gasto.

5. Nenhuma noção de tempo — o índice não sabe que um documento está desatualizado. Solução: filtragem por metadados, versionamento, reindexação automática e monitoramento de deriva de qualidade.

6. Resolução de entidades — "Apple" (a empresa ou a fruta?), "Ivanov A.V." e "A. Ivanov" parecem entidades diferentes. Solução: extrair entidades durante a indexação, construir um índice vinculado e buscar por meio de um grafo.

Quando o RAG não é necessário

Uma consulta como "mostre todos os clientes com risco de churn acima de 0,7" é SQL, não busca. O RAG não sabe fazer agregações, ordenações nem filtros numéricos. Para isso é preciso Text-to-SQL ou uma camada semântica sobre o repositório de dados. Detectores genéricos deixam passar 43% dos erros de cálculo.

Diagnóstico: três métricas

Context Relevance detecta erros de chunking e retrieval (os fragmentos errados foram retornados). Context Recall detecta omissões (o chunk com a resposta não foi retornado). Groundedness detecta alucinações mesmo com o contexto correto. A pergunta-chave é: o que está quebrado, o retrieval ou a geração? São problemas de engenharia diferentes, com soluções diferentes.