A Wrong RAG Answer Is Not Yet a Retrieval Bug

The answer is visible. The failure path is not.

When a customer says an assistant used the wrong cancellation policy, the report tells you what hurt. It does not tell you whether grounding was stale. It does not show whether answer generation ignored good evidence. It does not reveal whether the product displayed something different from the model output.

Yet teams often jump straight to chunk size or the prompt. The RAG system gets changed before the failure path is known.

That is a guess with a deployment behind it. Before changing the system, find the execution that produced the answer and follow the evidence through it. The investigation begins with the customer-visible symptom. It ends when engineering has a Failure Hypothesis specific enough to disprove.

One wrong answer, several possible histories

Imagine the customer expected the current cancellation policy, but the assistant showed an older version. Support preserves the answer they saw and the policy they expected. It also records an approximate time. The details here are fictional; the investigation sequence is the point.

From the customer's side, this is one failure. Inside the system, it has several possible histories.

The reported interaction may differ from the execution under review. Retrieval may have returned an old policy. A current policy could have reached the model and been ignored. The raw response could have been correct before display or post-processing changed it.

Those histories converge on the same screen. That is why the visible answer is not enough to classify the defect.

It is also why calling retrieval broken, or treating a prompt change as the fix, skips the investigation.

The first artifact should therefore be a Source Report, not a retrieval diagnosis. Preserve the original account with its time window and safe intake identifiers. That record gives engineering a path back into the system.

Build the record before choosing the culprit

Keep the report in its original wording. Record the expected and actual behavior. Add the product surface, then its approximate timestamp and timezone. Include any safe request, session, or account identifier.

Remove credentials and unnecessary customer content before the report moves beyond the people who need it. Then collect only the evidence the system actually exposes:

Evidence area	What to keep	Why it matters
Report match	Time window, safe identifiers, match confidence	A report written after the event may match several executions.
Grounding	Query, document or chunk IDs, freshness signal, ranking settings	It shows what grounding material was available to the model.
Answer generation	Effective prompt, model, output, latency, errors	It separates a bad input from a bad use of a good input.
Display and post-processing	Tool calls or transformations after generation	The customer-visible answer may differ from the raw model response.

RAG retrieves grounding documents before an LLM generates an answer. Microsoft also treats retrieval quality and final-answer quality as separate things to evaluate. RAG overview and RAG evaluators describe that distinction.

Keeping those evidence areas together prevents the final response from swallowing the rest of the incident. The record still does not name the culprit. What it gives you is an order for checking retrieval and everything that follows it.

The first question is identity: are you looking at the execution that produced the reported answer?

Follow the evidence through three gates

1. Does the execution match the Source Report?

Start with the report timestamp and any available trace. A close time is useful, but it is not proof. A retry or background operation sometimes produces another plausible execution.

Return to the fictional policy case. If three executions occurred near the reported time, selecting the nearest one without checking its identifiers could send the entire investigation down the wrong path. Record why one execution is the best match. Record the missing correlation data as well.

If the match is weak, stop there. The retrieved chunks and model output may be real, but they may belong to a different interaction.

Only after the execution identity holds does its content become meaningful. Then the investigation moves to the grounding the model received.

2. Was relevant, current grounding available?

Inspect the retrieved documents or chunks. The question is concrete: did this execution include the current cancellation policy, or only older or irrelevant material?

If the current policy is missing, follow the path that should have made it available. Check the query and access filters first. Then establish whether the document was available and how the indexing path turned it into retrieved chunks. These are retrieval-side investigation targets, not a confirmed cause.

The fictional case now has a real fork. A result set containing only the superseded policy supports a retrieval-side Failure Hypothesis. A result set containing the current policy pushes the investigation downstream.

That second path matters. Good grounding does not guarantee a good answer. It changes the next question.

3. Did the answer stay within the available evidence?

If a current, relevant chunk was returned, changing retrieval first is hard to justify. Inspect the effective prompt and model behavior instead. Then compare the raw output with any tool result, transformation, or displayed response that followed it.

This is where the same customer symptom splits again:

• If the model never received the current policy, the break remains upstream.
• If the model received it but contradicted it, answer generation becomes the leading investigation target.
• If the raw response was correct but the customer saw something else, the path continues into post-processing or display.

Microsoft makes the same practical split in its RAG evaluation guidance: missing viable chunks point the investigation at retrieval, while relevant returned chunks make prompt and answer behavior worth checking. Evaluation guidance

The third gate often leaves the team without a Confirmed Root Cause. It still has something more useful than the original hunch: a leading explanation that includes contrary evidence and a clear next check.

That is enough to build the engineering handoff.

Give engineering a hypothesis it can challenge

Write the result as a Failure Hypothesis. A useful handoff makes four things clear:

• what the Source Report records;
• which execution is the best match and how confident that match is;
• what the retrieval and answer evidence supports;
• what evidence would disprove the leading explanation.

For the fictional policy case, the handoff might say that the matched execution returned only a superseded policy chunk while the current document was absent from the retrieval set. That supports a retrieval-side hypothesis. It does not yet prove whether indexing, filtering, chunking, or document availability caused the absence.

The disproof condition matters. Finding the current policy in the actual retrieved set would overturn that explanation and move the investigation back toward answer generation or later output handling.

When expected behavior is clear, preserve an anonymised request with its expected answer or authoritative source. Add the relevant evidence links and an acceptance rule. A request that completed successfully can still be a quality failure.

The AI Bug Report Template gives engineering a place to record that handoff. The fictional sample Repro Pack shows what the finished evidence trail looks like.

Now the investigation has reached an endpoint: the customer symptom has become a reviewable engineering artifact.

The whole path is the trail

The customer saw the last step. Engineering needed the path that came before it.

That path runs from the Source Report to the matched execution, through the evidence, into a bounded Failure Hypothesis, and finally into a handoff someone can test. It preserves uncertainty without leaving the team with a vague ticket.

That complete path is the trail in FaultTrail.

FaultTrail is building automated support-to-evidence triage around this workflow. The proposed output is a human-reviewed Repro Pack that keeps the Source Report with its Evidence, then carries the hypothesis into the next verification step. The product does not yet accept reports, retrieve traces, or connect to third-party systems.

For now, teams can run the sequence with the systems they already have. If this resembles a recurring handoff problem in your product, explore the early pilot and describe the workflow and systems involved. Do not send tickets, traces, credentials, personal information, or confidential customer content.