How debugging RAG failures cuts unsupported answers from 34% to 9%

When a RAG system confidently reports an incorrect deadline, price, or rule, the first reaction is usually to edit the prompt. Teams add a phrase such as “answer only from the documents,” tighten the wording, and rerun the test. Sometimes that helps. But if the required fact never entered the context, no instruction can enable the model to use it.

The article's central point is simple: the same incorrect answer can result from different failures. Retrieval may have failed to find the document. Chunking may have split an important statement. The reranker may have promoted a similar but irrelevant fragment. Finally, the model may have received the correct context, ignored it, and answered from memory. Each case requires a different fix.

One answer, three possible failures

Consider an assistant for a cloud service's documentation. A user asks whether a deleted Kafka topic can be restored. The documentation says that deletion is irreversible, although the data remains physically stored for another seven days. The system answers: “The topic can be restored through the console within seven days, free of charge.”

This answer contains three unsupported claims: that restoration is possible, how it can be done, and its price. However, the phrase “seven days” really does appear in the source. A superficial word-overlap check may therefore accept the answer as grounded.

The first step is to inspect the fragments returned by retrieval. If the paragraph about irreversibility was not found, the problem lies in retrieval: investigate chunking, embeddings, filters, hybrid search, and reranking. If the correct fragment was present but the model still invented a restoration procedure, the failure is in generation or in a conflict between the context and the model's internal knowledge.

Ablation reveals what actually influenced the answer

A useful technique is to repeat the query while removing individual fragments from the prompt. If the model stops mentioning restoration after the chunk about seven-day storage is removed, it likely inferred an incorrect causal link, turning the physical retention period into the period during which a user operation remains available.

The answer is then divided into separate, verifiable claims. Every number, time frame, price, and action requires a specific supporting fragment. Merely mentioning an entity is not enough: a document containing the word “Berlin” does not prove that it identifies Berlin as Germany's capital.

Finally, remove all relevant context. If the answer barely changes, the model probably generated it from memory and used the retrieved document only as a decorative citation. A conventional logical-entailment check between the text and the source may miss this substitution because it answers whether the claims are compatible, not whether the source actually influenced generation.

What to implement in a production RAG system

The minimum observability stack should log the query, the top-k retrieved fragments, their scores, and the final prompt. For labeled queries, it is useful to calculate Recall@k: whether the required fragment appeared among the retrieval results. This metric is best measured on real traffic, not only on tidy synthetic examples.

For critical answers, require a supporting fragment for every material claim. If there is no direct support, the honest answer “not specified in the documentation” is safer than a confident guess. Numbers, deadlines, and prices can automatically be routed for additional verification.

The method has limitations. Ablations require extra model calls, increasing latency and cost, while a changed answer does not always prove causality unambiguously. It therefore makes sense to run them selectively: on a small share of traffic, on answers containing citations, and in high-risk scenarios.

The practical result is that the team stops treating every failure with the same prompt. If the source was not found, they fix retrieval and chunking. If the context was found but ignored, they work on the instructions and generation architecture. If a citation was attached after the fact, they strengthen attribution checks. In the example described by the author, these measures together reduced the share of unsupported claims from 34% to 9%.