10 AI Prompt Patterns That Reduce Hallucinations

Chain-of-Thought Prompting

Instead of asking for a direct answer, instruct the model to reason through the problem step by step. Adding “Let’s think through this step by step” or “Show your reasoning before the final answer” forces the model to externalize intermediate logic. That externalization makes fabrication harder: a wrong conclusion often contradicts an earlier step, which automated checks and reviewers can spot.

Chain-of-thought (CoT) is especially effective on reasoning-heavy tasks — financial calculations, multi-hop Q&A, policy interpretation, and code debugging. Research and our production data both show 15–30% fewer factual errors when CoT is enabled versus direct-answer prompts on the same inputs. The tradeoff is latency and token cost: CoT outputs are longer. For high-volume, low-stakes summarization, use CoT selectively on flagged outputs rather than every request.

Implementation: Separate reasoning from the deliverable. Ask for a “reasoning” section and a “final answer” section. In structured pipelines, parse only the final answer for downstream systems while logging reasoning for audit. Pair CoT with pattern #9 (fact-checking instructions) so the model reviews its own chain before submitting.

• Use explicit step labels: “Step 1: identify relevant facts. Step 2: apply rule. Step 3: conclude.”
• For math and logic, require showing intermediate values — not just narrative reasoning
• Route outputs where reasoning and conclusion disagree to human review automatically

Self-Consistency Checking

Ask the model to generate multiple independent answers to the same question — typically 3–5 runs at a moderate temperature — then compare them. When outputs diverge significantly, you have found a hallucination hotspot: the model is uncertain but individual runs may still sound confident. Agreement across runs correlates with correctness on many factual tasks; disagreement is a strong signal to escalate.

Self-consistency is more expensive than single-shot generation but cheaper than sending every output to human review. Use it as a triage layer: unanimous answers auto-pass (for appropriate risk tiers); split votes route to reviewers. This pattern works especially well combined with consensus review — when three model runs and two human reviewers disagree, you are almost certainly in ambiguous territory.

Implementation: Run parallel completions with the same prompt but different seeds or temperatures. Normalize answers (strip whitespace, canonicalize entities) before comparison. Define a similarity threshold: >90% agreement passes; 70–90% triggers advisory review; <70% blocks or requires full human rewrite. Log disagreement clusters by prompt version so you know which templates need refinement.

Citation Requirement

Explicitly require the model to cite sources for every factual claim. When the model cannot produce a real citation, it is more likely to acknowledge uncertainty rather than fabricate — especially if you pair the requirement with consequences: “If no source exists in the provided context, state ‘unverified’ instead of inventing a reference.”

Citation requirements are standard in RAG pipelines, but most teams stop at “include sources” without defining verifiability. A fabricated DOI passes a regex. A real URL pointing to the wrong paragraph passes a link checker. The prompt must require that each citation supports the specific claim it annotates — quote or page number, not just a document title.

Implementation: Structure prompts with: “For each factual claim, provide a verifiable source from the context below. Format: [claim] → [source_id, page/section]. If no source exists, state ‘unverified.’” Downstream, validate that cited source IDs exist in your retrieval set. Flag outputs where >20% of claims are marked unverified for human review. See our analysis of common hallucination patterns — fabricated citations top the list.

Confidence Calibration

Ask the model to assign a confidence score (0–100) to each claim it makes. This forces an internal evaluation step and surfaces uncertain outputs for routing. Confidence calibration is not perfectly reliable — models are often overconfident — but relative scores still work for triage: the lowest-scored claims in a batch are disproportionately likely to be wrong.

Pair calibration with an explicit threshold aligned to your risk tier. Example policy: any claim below 80% confidence gets routed to a reviewer; below 50% blocks auto-delivery. Tune thresholds using shadow sampling from your verification playbook — measure false positive and false negative rates on real outputs before enforcing in production.

Implementation: Require per-claim scores in structured output: {"claim": "...", "confidence": 72, "source": "..."}. Never accept a single global confidence for the entire response — granular scores enable selective review. Track calibration drift after model upgrades; a new model version may shift score distributions without changing accuracy.

Role-Based Prompting

Assign the model a specific expert role — “You are a forensic accountant reviewing financial statements” or “You are a clinical documentation specialist, not a diagnostician” — to activate domain-appropriate patterns and discourage speculative output. Roles work because they narrow the implicit objective function: an expert witness prioritizes precision; a creative writer prioritizes engagement.

The key is choosing a role that demands precision over creativity. Avoid roles that invite speculation (“thought leader,” “brainstorming partner”) for factual tasks. Include explicit boundaries in the role: what the expert would refuse to answer, what evidence they require, and what phrases they avoid (“studies show” without a study).

Implementation: Combine role assignment with constraint specification (pattern #6). Example: “You are a licensed pharmacist reviewing medication summaries. You only state facts supported by the provided monograph. You never recommend dosages not explicitly listed. You flag interactions even when uncertain.” Domain-specific roles pair naturally with domain-expert human reviewers on Tier 1 workloads.

Constraint Specification

Define explicit boundaries for what the model should and should not do. “Only use information provided in the document below. Do not infer or extrapolate beyond the text.” creates a tighter guardrail than vague instructions like “be accurate.” Constraints turn open-ended generation into a bounded transformation task — and bounded tasks hallucinate less.

Effective constraints are testable. A reviewer or automated check should be able to verify compliance: Did the output cite only provided source IDs? Did it stay under the word limit? Did it avoid forbidden topics? If you cannot test a constraint, the model cannot reliably follow it.

Implementation: Split constraints into must (blocking) and must not (blocking) lists. Example must-not: “Do not name products not mentioned in the source. Do not infer dates. Do not provide medical advice.” Example must: “Quote exact figures from the table. Preserve uncertainty language from the source.” Constraints pair with output format enforcement (pattern #8) so violations are machine-detectable.

Few-Shot with Edge Cases

When providing example inputs and outputs, include edge cases that commonly trigger hallucinations: empty fields, conflicting data, partial information, ambiguous pronouns, and out-of-scope requests. Showing the model how to abstain or ask for clarification prevents it from guessing when it should decline.

Most few-shot prompts only demonstrate the happy path. That teaches the model what success looks like but not what to do when inputs are messy — which is exactly when hallucinations spike. Include at least two edge-case examples for every production prompt: one where data is missing, one where the correct action is refusal.

Implementation: For each few-shot example, add a one-line annotation explaining why the output is correct. Example: “Input: revenue field blank. Output: ‘revenue: not provided in source.’ Reason: never infer financial figures.” Version few-shot sets alongside prompt code. When error rates climb after a model update, edge-case examples are usually the first thing to refresh.

Output Format Enforcement

Structured output formats — JSON schemas, markdown templates, or tabular layouts — constrain the model’s response space. When the model must fill specific fields with specific types, it is less likely to wander into free-form fabrication. Structured outputs also make automated validation dramatically easier: schema validators catch missing fields, type errors, and enum violations before a human ever sees the output.

Use provider-native structured output modes (JSON schema, tool calling) where available — they reduce format drift compared to “respond in JSON” instructions alone. Define required fields for provenance: sources[], confidence, unverified_claims[]. Empty unverified_claims on a complex factual task is itself a suspicious signal.

Implementation: Validate schema server-side before routing. Reject outputs that fail validation and retry with a repair prompt — but cap retries at two to avoid runaway cost. Log schema failure rates by prompt version; sudden spikes often indicate model regression or context overflow.

Fact-Checking Instructions

Add a verification step directly in the prompt: “After generating your response, review each factual claim and flag any that you cannot verify from the provided context.” This meta-cognitive instruction activates the model’s self-evaluation capabilities — a second pass that catches errors the first pass introduced.

Fact-checking instructions work best when the check is structured, not rhetorical. Do not ask “Is this accurate?” — models bias toward yes. Instead: “List each factual claim. For each, quote the supporting sentence from the context or mark UNSUPPORTED.” Unsupported claims should flow to human review or be stripped before delivery.

Implementation: Use a two-phase prompt or a single prompt with distinct sections: GENERATE then VERIFY. In agentic pipelines, a separate verifier step with a fresh context window reduces anchoring on the draft answer. Combine with citation requirements (pattern #3) so verification has concrete evidence to reference.

Uncertainty Acknowledgment

Give the model explicit permission to say “I don’t know.” Many hallucinations occur because models are trained to be helpful and complete — silence and refusal are underrepresented in reward signals. Adding “If you are unsure, say so rather than guessing” reduces fabricated outputs by up to 25% in our benchmarks on open-domain Q&A tasks.

Define what abstention looks like in your product. Users hate empty responses, but they hate confident wrong answers more. Provide a fallback format: “Insufficient data to answer. Missing: [field]. Suggested next step: [action].” That preserves utility while avoiding fabrication.

Implementation: Include abstention examples in few-shot sets (pattern #7). Track abstention rate by prompt version — a sudden drop may mean the model is guessing more, not that it got smarter. For customer-facing products, abstention should trigger a human follow-up path, not a dead end.

Combining patterns into a production prompt stack

No single pattern eliminates hallucinations. Reliable pipelines stack patterns by risk tier and task type, then route residual uncertainty to human review. A practical default for Tier 2 (sampled review) workloads:

1. Role + constraints — bound the task and define refusal conditions
2. Format enforcement — require structured output with provenance fields
3. Chain-of-thought + fact-check pass — generate, then self-audit against context
4. Confidence scores — route low-confidence claims to review queues
5. Self-consistency on flagged outputs — escalate disagreement to humans

Prompt patterns reduce error rates; they do not replace verification. Human reviewers still catch the errors automation and self-checks miss — our analysis of 10,000 reviewed tasks found humans catch 94% of factual errors that automated checks alone miss. Prompt engineering shrinks that pile. Verification ensures what remains does not ship.

Prompt patterns are the first gate, not the last. Structure your prompts to make hallucination difficult, uncertainty visible, and errors machine-detectable — then verify what ships using explicit criteria, shadow sampling, and human review on the outputs that matter most.

Your prompt audit checklist

Before deploying or updating a production prompt, run through this checklist:

• Does the prompt define refusal behavior for missing or ambiguous data?
• Are constraints testable by automated validators or reviewers?
• Does structured output include provenance fields (sources, confidence, unverified claims)?
• Are few-shot examples covering at least two edge cases, not just the happy path?
• Is there a fact-check or verification step before the response is finalized?
• Are low-confidence outputs routed to review per your risk tier policy?
• Is the prompt versioned, with error rates tracked per version after model changes?

Teams that treat this checklist as part of launch readiness — alongside the verification steps in our pre-ship guide — catch regressions before customers do. Prompt quality and verification quality compound: better prompts mean reviewers spend time on genuinely hard cases instead of obvious fabrications.