Hallucination Mitigation: RAG Grounding, Constrained Decoding, and Trustworthiness Checks Working Together

RAG grounding retrieves passages relevant to a query and places them in a model's context before generation happens, so the model has real, citable material to draw its answer from rather than relying only on whatever it memorized during training. [GROUND TRUTH] (Sources/ncp-genl/domain-10-safety-ethics-compliance.md) names this specifically as answering "from retrieved, citable context," and the operative word is from — grounding makes correct information available to generation, and that availability is a real, measurable reduction in one specific failure mode: a model asked about something outside its training knowledge, or something that has changed since training, has a chance to answer correctly because the correct answer is now sitting in its context, rather than having to be guessed from parametric memory alone.

This is a genuine and substantial improvement, and nothing in this lesson argues otherwise. What it is not is a guarantee about what the model does with that context once it is there. Retrieval is a search-and-placement operation; it decides what text goes into the context window. Generation is a separate operation, governed by the same autoregressive, next-token mechanism a model uses whether or not RAG is involved, and nothing about placing correct text into a context window forces the generation process to use that text faithfully. The gap between those two operations — what was retrieved, and what the model actually said — is where residual hallucination lives even in a well-built RAG system, and it is precisely the gap the source material's stated trap is naming.

L1 — Intuition: being handed the answer is not the same as reading it

Imagine handing someone an open reference book, correct page already found, and asking them a question the book directly answers. Most of the time, they read the page and answer correctly. But sometimes — distracted, or more confident in what they already believe than what the page says, or simply skimming past the relevant sentence — they answer from memory instead, and the memory is wrong. The book being open to the right page did not force them to read it, and it certainly did not force them to prefer it over what they already thought they knew. A model conditioned on retrieved context is in exactly this position: the correct material is present, but the model's own learned tendencies — what it was trained to say when asked a question shaped like this one — are still a competing influence on what it actually generates.

L2 — Mechanism: three distinct ways a model can misuse or ignore context that is genuinely correct

Ignoring context in favor of parametric memory. A model's training gave it a strong prior about what a plausible-sounding answer to a given question shape looks like, and that prior does not switch off just because retrieved context is also present in the same input. If the retrieved passage's phrasing is unusual, if the model's training saw the wrong answer to a similar-sounding question far more often than it saw exposure to the correct, retrieved one, or if the correct answer is simply less fluent-sounding than the model's default completion, the model's generation process can produce the memorized answer instead of the context-supported one, with no signal to a user that anything went wrong — the output still reads fluently and confidently.

Misreading or misattributing context that is present but not used correctly. A retrieved passage can contain the correct fact alongside other, adjacent facts — dates, names, figures for a related but different entity — and a model can genuinely attend to the passage, use it, and still combine the wrong pieces of it, attributing a fact from one part of the passage to a different subject the passage also mentions. This is not the model ignoring context; it is the model using context and still producing an ungrounded claim, because "the context was retrieved" and "the context was correctly parsed and attributed" are two different achievements.

Extending beyond what the context actually supports. A retrieved passage can support part of an answer directly and leave a related but distinct detail entirely unaddressed, and a model asked a multi-part question can answer the supported part correctly and then extend, unprompted, into the unsupported part using its own parametric guess — producing a response that is partially grounded and partially fabricated, with no boundary marked between the two for a reader to notice. This partial-grounding failure is arguably the hardest of the three to catch, because a spot-check against the retrieved passage for the supported half of the answer will pass, and the fabricated half can be phrased with exactly the same confident tone as the grounded half.

L3 — The exam-relevant edge case: grounding failure and retrieval failure are two different failure modes, and only one of them is RAG's job to fix

A scenario question in this domain sometimes describes a RAG system producing a wrong answer and expects you to identify which stage failed, because the fix is different depending on the answer. If retrieval itself failed — the wrong passage was fetched, or no relevant passage existed in the index at all — the model never had a chance, and the fix belongs to the retrieval pipeline: better chunking, better embeddings, better index coverage. If retrieval succeeded — the correct passage was fetched and placed in context — and the model still produced a wrong or ungrounded answer, the fix belongs to generation-side mitigation: this is squarely the "model can misuse or ignore context" case this lesson is about, and it needs constrained decoding or a trustworthiness check, not a better retriever. Confusing these two is a specific, testable trap: a question describing a correctly-retrieved passage and a wrong answer, with "improve the retrieval pipeline" offered as the fix, is offering a real fix to the wrong stage of the problem.

M2-04 already establishes constrained decoding as a decoding-time control — enforcing valid, checkable output structures at generation time, without retraining the model or touching its weights — and this lesson does not restate that mechanism. What this lesson adds is the specific role constrained decoding plays inside a hallucination-mitigation strategy rather than as a standalone output-formatting tool: constrained decoding can force a generated response into a structure that makes grounding checkable at the moment of generation, rather than only after the fact. A schema that requires every factual claim in a generated answer to be paired with a citation field pointing at a specific retrieved passage, enforced through the decoding-time constraint mechanism M2-04 covers, does not by itself guarantee the cited passage actually supports the claim — but it converts an unstructured, unverifiable answer into a structured one where verification, whether automated or human, has something concrete to check against.

This is the precise sense in which constrained decoding complements RAG grounding rather than substituting for it: RAG grounding decides what correct material is available; constrained decoding decides what shape the model's use of that material has to take. Neither one, alone, closes the gap this lesson opened with — a model can still be constrained into a citation-shaped answer that cites the wrong passage, or misattributes within the correct one — but together they narrow the space of undetectable failure considerably, because a malformed or missing citation is now a structural violation a downstream check can catch mechanically, rather than a subtle factual error buried in unstructured prose.

A trustworthiness check is the third named layer, and its job is explicitly to validate factuality before a response is returned to a user — a step that happens after generation, checking the output against the source material it was supposed to be grounded in, rather than shaping generation itself the way RAG and constrained decoding do. [GROUND TRUTH] (Sources/ncp-genl/domain-10-safety-ethics-compliance.md) names "trustworthiness checks — validate factuality before returning a response" as the third layer specifically because RAG and constrained decoding, even combined, still leave open every failure mode section 2 described: a model can be grounded, constrained into citing a passage, and still misattribute or partially fabricate within that structure.

A trustworthiness check closes that residual gap by comparing the model's specific claims against the specific passages they cite, after generation has already happened and before the response ships — extracting each factual assertion the response makes, checking whether the cited (or, absent an explicit citation, the retrieved) context actually supports that specific assertion, and blocking, flagging, or rewriting the response if it does not. This is the same general shape as an output-side guardrail from M10-01's safety/content family, and the overlap is real: a factuality check is frequently implemented as exactly that kind of rail. What earns it separate treatment here is the specific question it is built to answer — not "is this content unsafe or off-topic," but "is this specific factual claim actually supported by the specific context it was supposed to come from" — a narrower and more mechanical question than either of M10-01's other two rail families ask.

The row that matters most for this lesson's central claim is the fourth one. Layering all three defenses is a substantially stronger position than any one alone, and it is the closest a real system gets to eliminating hallucination — but "substantially stronger" and "eliminated" are different claims, and the source material's own framing keeps them separate on purpose. A retrieval index that never contained the correct fact defeats grounding before generation even starts, and no amount of downstream constraint or checking can supply a fact that was never available to retrieve.

A constructed scenario, invented for teaching, with illustrative details. A legal-research assistant is asked: "What is the filing deadline for a motion under Rule 12(b) in the jurisdiction described in the attached case file, and does the same deadline apply to the co-defendant named in the file?" The system has RAG grounding, constrained decoding (a claim-plus-citation schema), and a trustworthiness check all configured.

Constructed scenario, invented for teaching — not a measured result from any real system.

Retrieval stage:
  Correct passage retrieved: YES — the case file's relevant section, stating the
  filing deadline for the named defendant, is fetched and placed in context.

Generation stage, WITHOUT any of the three defenses applied:
  Model's answer: "The filing deadline is 21 days from service, and the same
  deadline applies to the co-defendant." (fabricated: the retrieved passage
  says nothing about the co-defendant at all — that clause is a confident
  extension beyond what was retrieved, exactly the third failure mode from
  section 2's L2 mechanism list)

Generation stage, WITH constrained decoding's claim-plus-citation schema enforced:
  Model's answer is now forced into structured form:
    Claim 1: "Filing deadline is 21 days from service." [cite: retrieved passage, para 3]
    Claim 2: "The same deadline applies to the co-defendant." [cite: retrieved passage, para 3]
  Structural check: PASSES. Both claims have a citation field populated.
  This is exactly the gap section 3 described — structure without factuality
  still passes structurally, because nothing about the citation FIELD being
  present checks whether paragraph 3 actually supports Claim 2.

Trustworthiness check, applied after generation:
  Claim 1 checked against paragraph 3: SUPPORTED. Paragraph 3 states the
  21-day deadline for the named defendant explicitly.
  Claim 2 checked against paragraph 3: NOT SUPPORTED. Paragraph 3 makes no
  mention of the co-defendant or any shared deadline; this claim is flagged.
  Action: response is held; Claim 2 is stripped or replaced with an explicit
  "the retrieved material does not address whether this deadline applies to
  the co-defendant" statement before the response ships.

Reading what each layer actually contributed. Retrieval succeeded completely — the correct passage was fetched, so this was never a retrieval-pipeline failure. Without any generation-side defense, the model still fabricated a plausible-sounding, confidently-stated extension beyond what the passage supported — precisely the "model can misuse or ignore context" failure the source material names, occurring even though grounding worked perfectly. Constrained decoding forced the answer into a checkable shape, but a checkable shape is not the same as a checked shape, and the malformed claim passed the structural check cleanly. Only the trustworthiness check, operating specifically on whether each claim's content matched its cited source's content, caught the fabrication — and it could only do that because constrained decoding had already made each claim individually addressable, rather than buried in an unstructured paragraph where "which sentence corresponds to which citation" would itself have been ambiguous. Each layer did something the others could not; none of them, alone, would have caught this specific failure.

⭐ THE EARNED INSIGHT

Every layer in this stack fixes a failure that lives at a different point in the pipeline — availability of the fact, shape of the claim, and truth of the claim against its source — and none of the three questions is answerable by a technique built to answer one of the other two. That is why "we use RAG" is not a hallucination-mitigation strategy on its own, however often it gets treated as one: it answers only the first of three separate questions, and a system that stops there has built one-third of a defense while believing it built the whole thing.

A second constructed scenario, invented for teaching, illustrating the boundary section 5's table names but does not fully demonstrate on its own: the case where every downstream layer is working exactly as designed, and hallucination still ships, because the failure sits upstream of all three.

Constructed scenario, invented for teaching — not a measured result from any real system.

Query: "What is this product's current refund policy for orders placed after
        the March pricing change?"

Retrieval stage:
  The knowledge base was last re-indexed six weeks before the March pricing
  change took effect. No document describing the POST-change refund policy
  exists anywhere in the index — the only refund-policy document present
  describes the OLD policy, from before the change.
  Retrieved passage: the old policy document (the closest match retrieval
  could find, since it is the only refund-policy document that exists).

Generation stage, WITH constrained decoding's claim-plus-citation schema:
  Claim: "The refund policy for orders after the March change is 30 days,
  no restocking fee." [cite: retrieved passage, the OLD policy document]
  Structural check: PASSES. The claim has a citation field, correctly
  populated with an actual retrieved passage.

Trustworthiness check, applied after generation:
  Claim checked against its cited source: SUPPORTED. The old policy
  document does say "30 days, no restocking fee" — the claim accurately
  reflects what the cited passage states.
  Verdict: PASS. The trustworthiness check has no way to know the cited
  document describes a policy that a change six weeks later superseded,
  because nothing in the cited passage itself signals that it is stale.

Result: a confidently stated, structurally valid, source-supported claim
that is nonetheless WRONG, because the actual current policy differs from
what the only available document says. Every layer performed its job
correctly. The failure is upstream of all three.

Why this is a different failure from the legal-research example. In section 6's example, the correct passage existed and was retrieved, and the model's generation process was the point of failure — exactly the "misuses or ignores context" mechanism this lesson opened with. Here, generation did nothing wrong at all: it grounded its claim in the passage it was given, cited that passage accurately, and the trustworthiness check confirmed the citation was accurate. The failure is that the retrieval index itself never contained a document describing the current policy, so "grounded, cited, and verified against its source" was achievable while "actually correct" was not. Section 5's table names this exact limit — a retrieval-index gap defeats the whole stack before generation even starts — and this worked example is what that limit looks like when it actually happens, rather than as an abstract caveat.

What actually fixes this failure, and what does not. No amount of tightening the trustworthiness check's verification threshold helps here, because the check is correctly reporting that the claim matches its source; the source itself is the problem. No constrained-decoding schema change helps either, for the same reason. The fix belongs entirely to retrieval-pipeline maintenance: re-indexing on a schedule tied to when source material actually changes, and — as a second layer of defense specifically for this failure mode — a document-freshness check that flags when a cited passage is older than a threshold relevant to the domain (a pricing or policy document six weeks stale is a very different risk than a historical reference document six weeks stale), so that even a technically-accurate citation of stale material gets flagged for human review rather than shipping with full confidence.

Because retrieval and generation are two separate operations, and retrieval succeeding only guarantees that correct material is available in the context window — it does not force the model's generation process to use that material faithfully. A model's training gave it strong tendencies about what a plausible answer to a given question shape looks like, and those tendencies remain a competing influence even when correct context is present. The model can ignore the context in favor of a memorized pattern, misattribute a fact within a passage that mentions multiple related facts, or extend confidently beyond what the passage actually supports — three distinct mechanisms, all consistent with "the correct passage was retrieved" and all producing a hallucinated final answer regardless.

Constrained decoding, covered in full in M2-04, forces generation into a valid, checkable structure — for hallucination mitigation specifically, a structure that pairs each factual claim with a citation to the context it is supposed to be grounded in. RAG grounding decides what correct material is available to draw from; constrained decoding decides what shape the model's use of that material has to take, converting an unstructured answer where no individual claim is separately verifiable into a structured one where a downstream check has something concrete to check each claim against. It does not, by itself, verify that a cited passage actually supports the claim attached to it — that verification is the trustworthiness check's job, applied on top of the structure constrained decoding provides.

• RAG grounding reduces hallucination; it does not eliminate it. The correct material being available in context does not force the model's generation process to use it faithfully.
• A model can misuse correct context in at least three distinct ways: ignoring it for a memorized pattern, misattributing within it, or extending beyond what it actually supports.
• Retrieval failure and grounding-misuse failure are different problems with different fixes. Confirm whether the correct passage was retrieved at all before deciding which stage to repair.
• Constrained decoding, covered fully in M2-04, contributes checkable structure, not verified content — a citation field can be present and still point at a claim the cited passage does not support.
• A trustworthiness check validates factuality after generation, checking each specific claim against its specific source, closing the gap RAG and constrained decoding leave open between them.
• Three layers together substantially reduce hallucination; none of them, alone or combined, eliminate it. Retrieval-index gaps defeat the whole stack before generation even starts.

Hallucination and bias look like related trust problems from a distance, but they are mechanistically distinct, and this module has now built the full case for both: bias is a population-level property of what a model learned, invisible to any single request and unfixable by any runtime check, while hallucination is a per-response failure that grounding, structure, and validation can substantially reduce even though none of them fully close the gap. Next: M10-05 takes up what happens once a system carrying both kinds of risk — and the coverage, latency, and false-positive tradeoffs M10-02 measured — is actually running in production: responsible-AI monitoring and compliance, extending ordinary production monitoring to ethical and regulatory signals across the model's whole operating lifecycle, not as a launch checkbox but as a standing, ongoing practice.