Habr: 6 motivos pelos quais a memória de um agente RAG falha e como verificar o retrieval

Quando um agente baseado em RAG responde fora do ponto, a primeira suspeita costuma recair sobre o modelo de linguagem. Na prática, o problema está com mais frequência na busca: se o trecho necessário não entrou no contexto, até uma LLM forte vai inventar a resposta ou dizer que não há dados. A análise publicada no Habr trata de seis causas desse tipo de falha e de uma forma de diagnosticar o retrieval. O anúncio da publicação traz apenas a definição da tecnologia, e a lista de causas fica escondida sob o corte ("под катом"). Por isso, abaixo segue um mapa das falhas típicas, que os engenheiros costumam verificar nesta ordem.

O RAG (Retrieval-Augmented Generation) conecta o modelo a uma base de conhecimento externa. O agente não se apoia só no que aprendeu no treinamento: primeiro ele busca informações em documentos corporativos, manuais ou na internet e escreve a resposta com base nelas. O pipeline tem no mínimo cinco etapas: fatiamento dos documentos, vetorização, indexação, busca e montagem do contexto. Um erro em qualquer uma delas tem o mesmo sintoma: o agente "esqueceu".

Onde a busca costuma quebrar

A primeira zona de risco é o fatiamento em chunks. Pedaços pequenos demais perdem contexto, e pedaços grandes demais diluem o sentido do vetor. Uma tabela cortada ao meio ou uma definição separada do seu termo não serão encontradas por nenhuma consulta.

A segunda é o modelo de embeddings. Se ele trabalha mal com russo, com terminologia especializada ou com código, textos semanticamente próximos acabam distantes um do outro no espaço vetorial.

A terceira é a atualização do índice. O documento foi atualizado, mas a reindexação não foi executada, e o agente cita com toda a confiança a versão do ano passado de um regulamento. Para a memória do agente, essa é a fonte mais frequente de respostas "desatualizadas".

A quarta é a formulação da consulta. O usuário escreve "como tirar férias?", mas na base o documento se chama "Procedimento para concessão de férias anuais remuneradas". Ajudam a reescrita da consulta e a divisão de uma pergunta complexa em subconsultas.

A quinta é o ranqueamento. A busca vetorial pura encontra mal códigos de produto, nomes e siglas. Um esquema híbrido com BM25 e um reranker aplicado aos melhores candidatos costumam trazer um ganho de precisão perceptível.

A sexta é a montagem do contexto. Os modelos aproveitam pior os fatos que ficam no meio de um prompt longo. Duplicatas, trechos desnecessários e uma ordem ruim reduzem a qualidade, mesmo que a busca tenha funcionado corretamente.

Como diagnosticar o retrieval

O princípio central é verificar a busca separadamente da geração. Para isso, monta-se um conjunto de referência com perguntas, cada uma delas associada de antemão a um trecho-fonte. Algumas dezenas ou um par de centenas de exemplos bastam, mas eles devem refletir as consultas reais dos usuários, não as inventadas pelos desenvolvedores.

Depois, calculam-se as métricas:

• recall@k: proporção de perguntas para as quais o trecho necessário apareceu entre os k primeiros resultados. Se aqui há uma falha grave, não é preciso olhar o resto;
• precision@k: quanto do que foi encontrado é de fato útil, ou seja, quanto ruído vai para o prompt;
• MRR: em que posição, em média, aparece o primeiro resultado correto;
• nDCG: qualidade da ordem dos resultados quando há vários trechos relevantes;
• latência da busca e do reranking, porque uma precisão comprada com segundos de espera costuma ser inaceitável para um agente.

Se o recall é alto, mas as respostas são ruins, o problema está mais adiante no pipeline: na montagem do contexto ou no próprio modelo. Se o recall é baixo, comece pelos chunks e pelos embeddings.

Ordem prática de ação

Primeiro, monte o conjunto de referência e registre os números de base. Depois, altere um parâmetro por vez: tamanho do chunk, modelo de embeddings, adição de BM25, reranker, número de trechos enviados ao modelo. Confira cada mudança com as métricas, não com a impressão deixada por algumas conversas bem-sucedidas.

Configure também um monitoramento à parte: registre em log a consulta, os trechos encontrados e as suas pontuações. Quando um usuário reclamar de uma resposta errada, veja antes de tudo se o documento necessário estava nos resultados. Programe uma reindexação periódica e verifique se os documentos atualizados realmente entraram no índice. E não tente corrigir o retrieval com prompt: pedir "responda com mais precisão" não traz de volta um fato que não está no contexto.