Intermediate

The Hallucination Prevention Playbook

The whole course as a decision framework: where your system sits today, which techniques to apply first, and the checklist that tells you when you have done enough.

The Hallucination Prevention Maturity Model

Level	Description	Typical Signs
0 - Unaware	No hallucination measurement or mitigation in place	Users report wrong answers; team attributes it to "the model being weird"
1 - Detected	Hallucination rate measured on a test set; rate is known	Can answer "what is our hallucination rate?" for the primary use cases
2 - Mitigated	Grounding prompts, uncertainty instructions, and RAG deployed on highest-risk paths	Hallucination rate measurably lower than Level 0 baseline; known residual rate
3 - Monitored	Production hallucination monitoring live; anomalies surface automatically	Daily hallucination rate metric in dashboards; LLM-as-judge or consistency sampling running
4 - Governed	Hallucination SLAs defined; circuit breakers for high-stakes paths; review culture established	New features include hallucination review in acceptance criteria; engineers treat hallucination regression as a bug

Technique Selection Framework

Which techniques to apply first depends on your use case's hallucination risk profile. Use this decision framework:

If your primary risk is…	Start with…	Then add…
Factual errors (wrong dates, names, stats)	RAG + grounding prompt	Cross-reference detection; citation forcing
Reasoning errors (wrong conclusions)	Chain-of-thought prompting	Expert review for high-stakes outputs; LLM-as-judge
Invented citations (fake references)	"Do not invent citations" instruction + cite-from-context only	URL/DOI existence check
Code hallucination (wrong APIs)	RAG over current API docs	Sandbox execution; static analysis
Entity hallucination (invented names/orgs)	Format constraints + null handling	Named entity lookup verification
All of the above (general-purpose AI assistant)	Explicit uncertainty instruction + temperature reduction	Consistency sampling; LLM-as-judge on sampled traffic

The 30-Point Prevention Checklist

Run this checklist before shipping any LLM-powered feature where factual accuracy matters:

Prompting (Lessons 3, 5)

• ☐ Temperature is set explicitly (not defaulting to provider default) and is appropriate for the task type
• ☐ System prompt includes an explicit uncertainty instruction ("if you don't know, say so")
• ☐ System prompt includes a scope restriction for closed-domain tasks ("only use the provided document")
• ☐ Null/missing-value handling is specified for structured output ("use null if not present")
• ☐ For reasoning tasks: chain-of-thought is required before the final answer
• ☐ For high-stakes outputs: self-critique step is included in the prompt
• ☐ "Accuracy matters more than completeness" framing is included where appropriate
• ☐ Citation instructions are explicit: cite sources in brackets; do not invent citations

Architecture (Lesson 6)

• ☐ For factual tasks: RAG is in place and retrieval is returning relevant chunks
• ☐ Chunking strategy preserves semantic units (not fixed character counts at arbitrary boundaries)
• ☐ Chunk overlap prevents boundary fact loss
• ☐ Retrieved chunks are placed at beginning or end of context (not buried in the middle)
• ☐ Faithfulness score has been measured on a test set (target: >0.8)
• ☐ "No relevant information found" case is handled explicitly, not handed to the model to fill

Detection (Lesson 4)

• ☐ Primary detection method is identified for each high-risk hallucination type
• ☐ For code outputs: executable verification or static analysis is in the pipeline
• ☐ For citation outputs: URL/DOI existence check is automated
• ☐ For document Q&A: cross-reference checking is implemented (manual or automated)
• ☐ Baseline hallucination rate has been measured before launch

Production Monitoring (Lesson 7)

• ☐ User feedback mechanism ("was this accurate?") is live and routed to a review queue
• ☐ Automated evaluation is sampling a fraction of production traffic
• ☐ Hallucination rate metric is in the operational dashboard
• ☐ Alert is configured for hallucination rate anomalies (spike or sustained upward trend)
• ☐ For high-stakes paths: circuit breaker is in place with a defined faithfulness threshold
• ☐ Human review SLA is defined for circuit breaker activations

Governance (Level 4 maturity)

• ☐ Hallucination acceptance criteria are in the definition of done for new LLM features
• ☐ Hallucination regression is treated as a bug (blocks release if rate exceeds threshold vs. baseline)
• ☐ Documentation of mitigation strategy exists (for compliance purposes)
• ☐ Model update review includes hallucination rate re-evaluation before promotion
• ☐ Responsible disclosure process exists for hallucination incidents affecting users

Anti-Patterns to Avoid

• Assuming the model knows what it does not know. Models do not have reliable self-awareness about their knowledge gaps. You must provide explicit uncertainty permission and verify calibration; you cannot infer it from the model's output.
• Treating RAG as a complete solution. RAG eliminates a class of hallucination (parametric recall failures) but not reasoning hallucinations, synthesis errors, or faithfulness drift. Layer prompting and monitoring on top.
• Using the same model for generation and evaluation. A judge model that shares the same errors as the generator cannot catch those errors. Use diverse models or evaluation methods for verification.
• Measuring once and assuming it stays. Hallucination rate is not static. Model updates, shifts in usage patterns, new query types, and prompt drift all change the rate. Measure continuously, not just at launch.
• Over-relying on user feedback. Users only catch hallucinations they already know are wrong. The most dangerous hallucinations (confident fabrications in domains where users lack independent knowledge) pass through user feedback undetected.

Ten Rules to Remember

1. The model predicts plausible tokens, not accurate facts: supply the facts yourself when accuracy matters.
2. Temperature 0 reduces hallucination on factual tasks; use it unless variation is required.
3. "Accuracy matters more than completeness" is one of the most effective instructions you can add.
4. If the model can invent a value, it will. Give it a sanctioned alternative (null, "not specified," "I don't know").
5. RAG changes the question from "do you know this?" to "are you faithful to what you read?" Both can fail; address both.
6. A circuit breaker that sometimes shows "I can't answer this confidently" protects more user trust than one that never blocks but occasionally lies.
7. Hallucination rate trends matter more than snapshots. A 2% rate rising is worse than a 5% rate stable.
8. The most expensive hallucination is the one that propagates: multi-step pipelines need checks at each step, not just the output.
9. Governing hallucination is like governing security: it degrades without ongoing attention, not in one catastrophic event.
10. The goal is not zero hallucination; it is hallucination below the harm threshold for your use case, consistently measured and controlled.

Where to Go Next