Your RAG Cited a Real Source and Still Lied to You

Retrieval Failed vs Grounding Failed — Not the Same Bug

When a RAG answer is wrong, there are two distinct root causes and teams routinely confuse them. Retrieval failure: the right passage never made it into the context, so the model answered from parametric memory or from an irrelevant chunk. Grounding failure is the other one. The right passage was retrieved, sat there in context, and the model still produced a claim the passage doesn't back.

These need opposite fixes. Retrieval failure is a chunking, indexing, or ranking problem — start with a retrieval-only eval before you touch answer quality, because grading the final answer tells you nothing about whether the right text was even present. Grounding failure is a generation problem: the passage was there and the model overreached anyway. Fixing the retriever does nothing for it.

Grounding failures dominate the incidents that reach production, and the reason is selection. Retrieval misses tend to produce hedged answers that reviewers catch. Grounding misses produce something fluent and confident, with citations attached — the exact shape that survives a spot-check. If your only defence is human review, you're filtering out the easy failures and shipping the hard ones.

A citation proves a passage was retrieved. It says nothing about whether the answer follows from it.

• →Retrieval failure: right passage absent → fix chunking, indexing, ranking.
• →Grounding failure: right passage present, claim unsupported → fix generation and add faithfulness gates.
• →Confusing the two means you keep tuning the retriever while the real leaks stay open.

Overreach Is the Default, Not the Exception

Models are trained to be helpful and complete. Give one a passage that answers 80% of a question and it will confidently synthesize the remaining 20% from priors, then attach the citation to the whole thing. The footnote is honest about where the retrieved text came from. It says nothing about which sentences in the answer that text actually supports.

The most common patterns we tag in audits: a qualified statement in the source rendered as unconditional in the answer; a number carried over correctly but attached to the wrong entity; a temporal or jurisdictional caveat dropped; and outright interpolation, where the passage implies a direction and the model states a specific value the text never contains.

None of these look like hallucination in the cartoon sense. There's no invented citation, no obviously made-up fact. The answer starts anchored to something real and then drifts a few degrees past it, and that drift is what causes the incident, because everything around it still reads as trustworthy.

A Confident, Cited, Fabricated Answer

Anonymised from an audit of an internal policy assistant. A user asked whether a particular expense category required pre-approval above a threshold. The agent answered: yes, pre-approval is required for that category above the stated amount — and cited the correct policy chunk. Confidence high, citation valid, tone authoritative.

The retrieved chunk actually said pre-approval was required for a different category, and was silent on the one asked about. The policy simply didn't address it. The model saw a pre-approval rule in a nearby paragraph, saw the category in the question, and stitched them into a rule that didn't exist. Every surface signal — retrieval hit, citation, fluency, self-reported confidence — pointed at a correct answer.

This is why self-reported confidence and logprobs can't carry your human gate. Confidence was maximal on the fabricated span. The failure wasn't in the retriever and wasn't visible in the model's own uncertainty. It was in the join between a real passage and a plausible-sounding extension of it — and only a check that compares the claim against the passage could have caught it.

The Faithfulness Checks We Wire In

The fix is to stop treating the answer as one atomic thing. Decompose it into claims, and require each claim to be supported by retrieved text before it ships. Three layers, cheapest first.

Claim-level attribution: split the generated answer into atomic factual claims and map each to the specific span it's supposed to come from. A claim with no candidate span is unsupported by definition — no entailment model needed to flag it. This alone catches interpolation, the case where the model added a fact that isn't anywhere in context.

NLI-style entailment gates: for each claim that does have a candidate span, run a natural-language-inference check — does the span entail the claim, contradict it, or neither. "Neither" is the quiet killer. That's where the pre-approval example lived. We gate on entailment because lexical overlap isn't enough — the fabricated answer shared most of its words with the source, and it still wasn't saying the same thing. Span verification: for quoted values, numbers, and named entities, verify the exact token appears in the cited span rather than trusting a paraphrase. Numbers attached to the wrong entity fail here even when the sentence entails loosely.

• →Claim decomposition → any claim with no candidate span is flagged unsupported.
• →Entailment gate → span must entail the claim; "neither" and "contradiction" both fail.
• →Span verification → exact numbers, dates, entities must appear in the cited text.
• →On failure: suppress the claim, degrade to "the source doesn't address this," or escalate — never ship the unsupported sentence.

The Detection Pattern We Now Apply by Default

Every RAG answer gets decomposed into claims, and every claim must clear one of two states: entailed by a retrieved span or verified token-for-token. Anything else we mark unsupported. When a claim can't reach one of those states, the answer doesn't go out unmodified — we suppress the claim, swap it for an honest "not covered by the source," or route it to a human. This runs as an offline eval on every prompt or model change. It also runs inline, as a gate on high-stakes answers.

It composes with the rest of the harness. The claim-level results become attributes on the span trace, so when an answer is challenged you can see exactly which sentence failed which check — the kind of trace you want before an agent hits production, not a day of reconstruction after. And because it's an eval, it's part of the regression gates that catch slow drift when a vendor model update quietly starts overreaching more.

This is honest about its limits. Entailment models have their own error rate and cost, so you tune the gate strictness per blast radius — a support FAQ tolerates more slack than a compliance answer. Claim decomposition on long, multi-hop answers is still imperfect; splitting nuanced reasoning into atomic claims sometimes over- or under-segments. And nothing here validates whether the retrieved passage itself is correct — garbage in the corpus produces faithfully-grounded wrong answers. What the pattern does buy you is the specific failure that fluent, cited, confident answers are engineered to hide: the model asserting more than its source allows.