Como a analise de falhas em RAG reduz respostas sem respaldo de 34% para 9%

Quando um sistema RAG informa com conviccao um prazo, preco ou regra incorretos, a primeira reacao costuma ser alterar o prompt. A equipe acrescenta uma frase como “responda apenas com base nos documentos”, torna a formulacao mais rigorosa e executa o teste novamente. As vezes isso ajuda. Mas, se o fato necessario nem sequer entrou no contexto, nenhuma instrucao permitira que o modelo o utilize.

A ideia central do artigo e simples: a mesma resposta incorreta pode ser consequencia de falhas diferentes. A recuperacao pode nao ter encontrado o documento. O chunking pode ter dividido uma afirmacao importante. O reranker pode ter colocado no topo um fragmento semelhante, mas inadequado. Por fim, o modelo pode ter recebido o contexto correto, ignorado esse contexto e respondido de memoria. Cada caso exige uma correcao diferente.

Uma resposta, tres falhas possiveis

Imagine um assistente para a documentacao de um servico em nuvem. O usuario pergunta se e possivel restaurar um topico do Kafka que foi excluido. A documentacao diz que a exclusao e irreversivel, embora os dados ainda permaneçam fisicamente armazenados por mais sete dias. O sistema responde: “O topico pode ser restaurado pelo console no prazo de sete dias, sem custo”.

Ha tres afirmacoes sem confirmacao nessa resposta: a possibilidade de restauracao, o metodo e o preco. No entanto, a expressao “sete dias” realmente aparece na fonte. Por isso, uma verificacao superficial por correspondencia de palavras pode considerar a resposta fundamentada.

Primeiro, e preciso examinar quais fragmentos a recuperacao retornou. Se o paragrafo sobre a irreversibilidade nao foi encontrado, o problema esta no retrieval: devem ser verificados o chunking, os embeddings, os filtros, a busca hibrida e o reranking. Se o fragmento correto estava presente, mas o modelo ainda assim inventou a restauracao, a falha ja esta na geracao ou em um conflito entre o contexto e o conhecimento interno do modelo.

A ablacao mostra o que realmente influenciou a resposta

Uma tecnica util e repetir a consulta removendo fragmentos individuais do prompt. Se o modelo parar de falar em restauracao depois que o chunk sobre o armazenamento por sete dias for removido, isso significa que ele provavelmente construiu uma relacao causal incorreta: transformou o periodo de armazenamento fisico no prazo durante o qual uma operacao estaria disponivel ao usuario.

Em seguida, a resposta e dividida em afirmacoes verificaveis separadas. Cada numero, prazo, preco e acao exige um fragmento especifico de respaldo. A simples mencao de uma entidade nao basta: um documento que contenha a palavra “Berlim” ainda nao prova que Berlim seja identificada nele como a capital da Alemanha.

Por fim, vale remover todo o contexto relevante. Se a resposta quase nao mudar, o modelo provavelmente a gerou de memoria e usou o documento recuperado apenas como uma citacao decorativa. Uma verificacao convencional de implicacao logica entre o texto e a fonte pode nao detectar essa substituicao, pois ela responde se as afirmacoes sao compativeis, mas nao mostra se a fonte influenciou a geracao.

O que implementar em um sistema RAG de producao

O conjunto minimo de observabilidade deve registrar a consulta, os fragmentos top-k recuperados, suas pontuacoes e o prompt final. Para consultas rotuladas, e util calcular Recall@k: se o fragmento necessario apareceu entre os resultados da busca. Essa metrica deve ser medida preferencialmente em trafego real, e nao apenas em exemplos sinteticos cuidadosamente preparados.

Para respostas criticas, deve-se exigir um fragmento de respaldo para cada afirmacao relevante. Quando nao houver suporte direto, a resposta honesta “nao consta na documentacao” e mais segura do que um palpite confiante. Numeros, prazos e precos podem ser encaminhados automaticamente para uma verificacao adicional.

O metodo tem limitacoes. As ablacoes exigem chamadas adicionais ao modelo, aumentam a latencia e o custo, e uma mudanca na resposta nem sempre comprova causalidade de maneira inequivoca. Por isso, faz sentido executa-las de forma seletiva: em uma pequena parcela do trafego, em respostas com citacoes e em cenarios de alto risco.

O resultado pratico e que a equipe deixa de tratar todos os erros com o mesmo prompt. Se a fonte nao foi encontrada, corrige a recuperacao e o chunking. Se o contexto foi encontrado, mas ignorado, trabalha nas instrucoes e na arquitetura de geracao. Se uma citacao foi associada posteriormente, reforca a verificacao de atribuicao. No exemplo descrito pelo autor, a combinacao dessas medidas reduziu a proporcao de afirmacoes sem respaldo de 34% para 9%.