RAG Patterns & Hallucination Mitigation Checklist
A practical, actionable playbook for designing retrieval-augmented systems that are auditable, current, and resistant to hallucination. Includes chunking guidance, source-quality scoring, retriever tuning loops, citation templates, freshness strategies, prompt templates, monitoring metrics, and an operational checklist with acceptance criteria.
Purpose
This playbook helps teams design and operate Retrieval-Augmented Generation (RAG) systems that produce verifiable, up-to-date, and auditable outputs. It translates design patterns into concrete checks, templates, and monitoring signals you can apply during development, deployment, and operation.
Core design principles (why these items matter)
- Prefer evidence over synthesis: Make it easy to show which source(s) support each claim.
- Limit the LLM's imagination: Instruct the model to use only retrieved context for factual assertions and to admit uncertainty where evidence is lacking.
- Measure and iterate: Treat retrieval and generation as an operating system—instrument, test, tune, and repeat.
- Fail safely: Provide clear fallback behaviors whenever confidence or verification fails.
Quick checklist (operational items)
- Define source-quality rubric and apply it to each source in the index.
- Set chunking rules and validate average chunk size against model context window.
- Establish retriever and re-ranker configuration (top-k, hybrid scoring) and automated tuning loop.
- Implement citation templates and require citations for all factual claims above a low-confidence threshold.
- Set freshness policies (TTL, priority re-indexing) for dynamic sources and monitor staleness metrics.
- Choose verification strategies (model-based verifier, cross-check, human-in-the-loop) and acceptance criteria.
- Instrument production: citation rate, unverified-response rate, user corrections, and other KPIs.
- Define and implement safe fallback behaviors when confidence or verification fails.
Detailed patterns and practical guidance
1. Chunking and context window
Chunking breaks documents into contextual pieces the retriever and generator can use. Good chunking balances semantic completeness with retrieval precision.
- Target chunk size: aim for coherent text spans that fit easily in the model's prompt window. A common practical range is roughly 500–2,000 tokens (or about 1–4 KB of text), depending on your model's max context. Prefer semantic boundaries (paragraphs, sections) over arbitrary byte counts.
- Chunk overlap: use small overlaps (e.g., 10–20%) to preserve context across boundaries when paragraphs split important statements.
- Store chunk metadata: source id, document id, position, last-modified, author, and a digest (summary) useful for display and citation.
2. Source quality scoring (rubric)
Score sources so the system can prefer higher-quality evidence during retrieval and signal confidence to users.
- Suggested dimensions (0–5 each): authority, recency, traceability (primary vs secondary), format/completeness (structured vs unstructured), and relevance history (past retrieval performance).
- Combine into a composite score and surface it with citations. Keep the rubric explicit and reviewable by stakeholders.
3. Retriever & re-ranker tuning loop
Make the retriever a continuously-improving component, not a one-time configuration.
- Instrument relevance labels (human judgments or implicit signals like click/selection).
- Periodically evaluate recall and precision on a representative test set.
- Use re-rankers (cross-encoders) when high precision matters; use lightweight vector search when latency matters.
- Automate retriever tuning schedules and rollback criteria.
4. Prompt and system design to reduce hallucination
Design prompts so the LLM treats retrieved context as authoritative and signals uncertainty instead of inventing facts.
Example system prompt pattern:
Use only the content in the Retrieved Context to answer factual questions. If the retrieved context does not support a clear answer, say "I don't have enough information to answer that" and list the sources you used. For each factual claim, include a citation in square brackets that references the source id(s).
Example answer format instruction (enforceable via templates):
Answer: <concise answer> Citations: [1] SourceID — short title — URL — confidence: 0.92 [2] ... Confidence: <high|medium|low>
5. Citation templates and display
Make citations: machine-readable for audit, and human-readable for trust.
Suggested citation structure stored per chunk:
{
"sourceId": "site:doc:123",
"title": "Document Title",
"url": "https://...",
"published": "2025-01-01",
"lastModified": "2025-06-01",
"score": 4.2
}
When returning an answer, include a concise citation list and link to the underlying chunk(s). Require the model to reference the sourceId next to each claim.
6. Verification & hallucination mitigation strategies
- Verifier step: run a secondary model to check that each claim is supported by the cited chunk(s). If mismatch, mark as unverified and trigger fallback.
- Source cross-check: for high-risk claims, require corroboration from two independent high-quality sources before asserting as fact.
- Human-in-the-loop: route unverified or low-confidence answers to subject-matter reviewers with clear evidence and an easy approval UI.
- Constrain reasoning: avoid or limit chain-of-thought outputs that can produce confident but unsupported conclusions.
7. Freshness and update cadence
- Classify sources by volatility (static, periodic, real-time). Assign TTLs: e.g., static docs (quarterly), policies (monthly), dynamic feeds (minutes–hours).
- Priority re-indexing: update high-risk sources on-demand or after detected changes (webhooks, change logs, or polling).
- Staleness alerting: monitor average age of top-k retrieved chunks and alert when it exceeds threshold for the use case.
Monitoring, metrics and acceptance criteria
Instrument these signals in production and define acceptable thresholds for your context:
- Citation rate: % of answers that include at least one citation (target: high for factual systems).
- Unverified-answer rate: % of answers flagged by verifier as unsupported (target: as low as feasible; set a threshold such as <2% for high-stakes domains).
- User correction rate: proportion of responses with subsequent user edits or disagreement.
- Freshness lag: median time between source update and index refresh for top-k returned items.
- Mean time to human review: for routed items needing SME verification.
Acceptance criteria example for a launch: citation rate > 90% for factual queries, unverified-answer rate < 3% on a holdout test set, and median freshness lag < 24 hours for prioritized sources.
Fallback policies and safe responses
- If verifier fails or no supporting sources found: respond with "I don't have enough information to answer that" and offer to: (a) search broader sources, (b) ask a human, or (c) collect more context from the user.
- For opinion or ambiguous prompts, label the answer clearly as opinion or hypothesis and include source-based reasoning where relevant.
- For high-risk domains (legal, clinical, financial), default to human escalation when evidence is insufficient or when the cost of error is high.
Operational checklist with owners and acceptance criteria
- Source inventory completed — Owner: Content Lead — Acceptance: every indexed source has metadata and a quality score.
- Chunking implemented and validated — Owner: Data Engineer — Acceptance: median chunk size within target range and manual spot-checks show semantic completeness.
- Retriever + re-ranker test suite — Owner: ML Engineer — Acceptance: pass predefined relevance benchmarks and automated regression tests.
- Citation & verifier in pipeline — Owner: Platform Engineer — Acceptance: every response contains citation metadata and verifier flags unverified claims.
- Monitoring dashboards — Owner: SRE/Product — Acceptance: real-time KPIs for citation rate, unverified-answer rate, freshness lag, and user feedback are displayed and alerting configured.
Templates & examples
Prompt template to constrain the generator:
System: You are an assistant that must use only the provided retrieved context. Cite the sourceId(s) after each factual sentence. If the context does not support a claim, say "Insufficient information". User: <user question> Retrieved Context: <chunked passages with sourceId metadata>
Citation display example (human-facing):
Answer: X is true because ... Sources: [site:doc:123] Company Policy — Company Intranet — last modified 2026-06-01 [site:web:456] Research Article — Example Journal — 2025-11-12 Confidence: medium
Testing checklist (pre-release)
- Run a holdout query suite with known ground-truth; measure unverified-answer rate and citation coverage.
- Simulate adversarial prompts and hallucination-prone queries; verify fallback triggers.
- Perform human-A/B tests comparing trust and usefulness with/without enforced citations and verifier.
Notes on governance and continuous improvement
Document who can change indexing rules, source scoring, verifier thresholds, and fallback policies. Maintain a change log for audits and periodically review metrics with content owners.
Next steps (practical short list)
- Run a quick audit of your indexed sources and apply the source-quality rubric.
- Pick one high-value use case and implement the citation+verifier pipeline for it.
- Define KPIs and instrument dashboards for citation rate and unverified-answer rate.
- Run a 2–4 week retriever tuning sprint using labeled relevance data and iterate.
References & further reading
Keep a short bibliographic list here linking to internal architecture docs, verifier model design notes, and relevant external papers on RAG, retrieval evaluation, and LLM verification strategies.
Discussion
Comments and conversation will live here.