How to Reduce AI Hallucinations: A Practical Playbook

You cannot make a language model stop hallucinating. What you can do is change the odds and the aftermath: make confabulation rare, make it shallow instead of load-bearing, and make it catchable before anyone acts on it. That is the whole game. Treat hallucination the way a bank treats fraud — not a bug to patch and forget, but a standing risk you drive down with layered controls.

This is the playbook. It assumes you already know why models make things up — the short version is that a model predicts plausible text, and plausible is not the same as true. Here we skip the diagnosis and go straight to treatment: ground the model in real sources, force it to show its work, constrain what it's allowed to say, and verify before you trust. None of these are magic. Stacked together, they turn a system that's wrong 8% of the time into one that's wrong 0.5% of the time and tells you which half-percent to double-check.

Key takeaways

Hallucination is a risk to manage, not a defect to wait out. No model release will "fix" it. Design for it.
Grounding beats prompting. Putting the right source text in the context window does more than any clever instruction. Retrieval is your single highest-leverage control.
Force citations and make them checkable. A claim tied to a quotable span is a claim you can verify — and the requirement itself suppresses invention.
Give the model permission to say "I don't know." Most confabulation is the model refusing to leave a blank. Reward abstention.
Constrain the output space. Structured formats, closed vocabularies, and "answer only from the provided text" narrow the room to invent.
Verify with a second pass. A separate check — another model, a rule, a lookup — catches what the first pass asserts confidently and wrongly.
Measure it. If you don't have a hallucination rate on your own tasks, you're guessing.

Key takeaways
Start by naming your failure mode
A taxonomy of hallucination types
The layered mitigation stack, ordered by leverage
Ground the model: retrieval is the biggest lever
Retrieval quality is a hallucination control
Force citations you can actually check
Give the model an exit: reward "I don't know"
Constrain the output space
Verify with a second pass
Prompt patterns that suppress confabulation
System-level guardrails
The limited role of fine-tuning
Why you can reduce but not eliminate hallucination
Measuring your hallucination rate
A decision framework by risk level
Common mistakes
FAQ
The bottom line

Start by naming your failure mode

"Reduce hallucinations" is too vague to act on. There are at least three different failures hiding under the word, and they need different fixes:

Open-domain confabulation. You ask a bare model a factual question and it invents a plausible answer — a fake citation, a wrong date, a nonexistent API method. Fix: grounding.
Grounded drift. You gave the model source documents, but it still adds claims not supported by them, or misreads them. Fix: citation-forcing and faithfulness checks.
Reasoning slips. The facts are right but the model chains them into a wrong conclusion — bad arithmetic, an invalid inference, a confident non-sequitur. Fix: decomposition and verification.

Most real systems suffer from all three, but in different proportions. A customer-support bot over your own docs lives and dies on grounded drift. A research assistant answering from the open web fights open-domain confabulation. Name yours before you spend effort, because the controls below have wildly different payoffs depending on which one is killing you.

A taxonomy of hallucination types

The three failure modes above are a triage sort — good enough to point your effort in the right direction. But if you want to build controls that actually target the mechanism, you need a sharper vocabulary. The research literature and the practitioners who ship these systems have converged on a handful of distinctions that matter. The why-they-happen explainer covers the underlying causes; here is the taxonomy you'll actually reach for when triaging incidents.

Factuality vs. faithfulness. This is the master distinction, and getting it wrong wastes weeks. A factuality error is a claim that contradicts the real world: the model says a drug's half-life is six hours when it's twelve. A faithfulness error is a claim that contradicts the source you gave it: your document says twelve hours, and the model — reading that document — still writes six. These are different failures with different fixes. Factuality is about what the model knows; faithfulness is about whether it stayed inside the evidence. A summary can be perfectly faithful to a wrong source (garbage in, faithful garbage out) or unfaithful to a correct one. In a grounded system, faithfulness is the property you can actually enforce, because you control the source and can check the output against it. Factuality against the open world is much harder to verify and often not your job — your job is to be faithful to a source you trust.

Intrinsic vs. extrinsic. Within faithfulness failures, intrinsic hallucinations contradict the source (the source says A, the model says not-A), while extrinsic hallucinations add information the source neither states nor implies (the model volunteers a detail that simply isn't there — possibly true, possibly not, but unsupported). Intrinsic errors are easier to catch because a contradiction is detectable by comparison. Extrinsic errors are more insidious: the added claim might be correct, which makes reviewers wave it through, right up until the one time it isn't. A citation-forcing regime targets extrinsic hallucination directly — every claim must point at a span, so unsupported additions have nowhere to hide.

Citation fabrication. A special, high-embarrassment case worth naming on its own. The model invents a source: a plausible-looking case citation, a DOI that resolves to nothing, an API method that doesn't exist, a study with a real-sounding author and journal that was never written. This is what got lawyers sanctioned for filing briefs full of imaginary precedents. It happens because a citation is just more text to predict, and the model has seen millions of well-formed citations — the format is easy to reproduce, the referent is not. The fix is mechanical, not persuasive: never let the model mint a citation from its weights. Citations must come from a retrieval layer that returns real documents, and every cited identifier should be resolvable — you check that the DOI resolves, the case exists in the reporter, the method appears in the API surface. If a citation can't be resolved, it's fabricated until proven otherwise.

Reasoning hallucination. The facts are individually correct but the chain connecting them is invalid — a plausible-sounding deduction that doesn't follow, arithmetic that's confidently wrong, a comparison that mixes up which number is bigger. This is distinct from the factual failures because grounding won't touch it: the sources are right and the model read them correctly, but the inference is broken. Decomposition and step-level verification are the levers here, not retrieval.

Why bother with four categories instead of "it made stuff up"? Because each one implicates a different control, and controls are expensive. If your incidents are mostly extrinsic faithfulness failures, pouring effort into a better open-web fact-checker is wasted — you needed citation-forcing. If they're citation fabrications, you needed a resolvable-source check, not a stronger model. The taxonomy is how you avoid buying the wrong medicine.

The layered mitigation stack, ordered by leverage

Before the section-by-section detail, here is the whole stack in one view, ordered by leverage — the amount of hallucination each layer removes per unit of engineering effort. Spend from the top down. It is a common and expensive mistake to start at the bottom (fine-tuning, model swaps) when the top (grounding, prompting) is where the cheap wins live.

Grounding / retrieval — the biggest lever by a wide margin. Move the task from recall to reading comprehension by putting real source text in context. This is retrieval-augmented generation, built on good embeddings and hybrid search. Everything below assumes you've done this; nothing below compensates for skipping it.
Prompting techniques — nearly free, meaningful effect. Ask for sources, grant explicit permission to say "I don't know," decompose multi-step questions. Can't fix missing grounding, but sharpens everything above it.
Structured outputs and constraints — cut the invention surface by narrowing what the model is allowed to emit. Closed vocabularies, required fields, "answer only from the text." Enforced at the decoder by function calling and structured outputs.
Retrieval quality and context engineering — the difference between grounding that works and grounding that produces confident, cited, wrong answers. Reranking, chunking, freshness, and the discipline of context engineering sit here.
Verification and self-check — treat the first pass as a hypothesis. Deterministic checks first, then a separate LLM-as-a-judge verifier pass scoped to one claim at a time.
Guardrails and post-hoc fact-checking — architectural safety nets: production safety guardrails, fail-closed policies on irreversible actions, claim logging, and surfacing sources to the user.
Fine-tuning — the smallest and most misunderstood lever for hallucination specifically (more below). Fine-tuning shapes style and format reliably; it does not reliably install facts or teach abstention.
Human-in-the-loop — the backstop for the tail. Not on every output — on the ones the layers above flag as unsupported, low-confidence, or high-stakes.

The ordering isn't arbitrary and it isn't a menu to pick one from. Each layer catches a different slice of failure, and the slices overlap only partly. But the sequence matters: an hour spent on grounding removes more hallucination than a week spent on fine-tuning, so if your budget is finite — it always is — you work the list top-first and stop when the residual error rate is acceptable for your risk level. The rest of this playbook walks each layer in that order.

Ground the model: retrieval is the biggest lever

The single most effective thing you can do is stop asking the model to recall and start asking it to read. A model answering from its weights is reciting a lossy compression of its training data. A model answering from documents you placed in its context window is doing reading comprehension — a task it's far better at and one you can audit.

This is what retrieval-augmented generation is for. Fetch the relevant passages, put them in the prompt, and instruct the model to answer from those passages only. Done well, this collapses open-domain confabulation because the model no longer has to guess — the answer is sitting in front of it.

But grounding is only as good as the retrieval. Garbage passages produce grounded-but-wrong answers, which are more dangerous than obvious guesses because they come with a citation. The failure modes worth engineering against:

Missing evidence. The right passage wasn't retrieved, so the model answers from weights anyway (or should abstain). Fix with better embeddings and hybrid search, and by instructing the model to say "not found in the sources" when coverage is thin.
Distractor passages. Retrieved text is topically close but wrong. Rerankers and tighter chunking help.
Stale index. The source of truth changed; your index didn't. Freshness is a hallucination vector people forget.

The engineering discipline around all of this — chunking, reranking, freshness, evaluation — is its own craft; the production RAG architecture guide covers it end to end. The one-line version for this playbook: most "the AI hallucinated" incidents in grounded systems are actually retrieval failures wearing a hallucination costume. Fix retrieval first.

There's a mechanism worth understanding here, because it explains why grounding works at all. A model's weights encode a smooth, lossy interpolation over its training data — ask for a specific fact and it reconstructs the most probable completion, which for common facts is right and for rare or precise facts (a specific date, a version number, a proper name) drifts toward the plausible average. Placing the exact text in context short-circuits this: the model's attention can copy from a concrete token span instead of reconstructing from a blurry prior. That's why grounding disproportionately helps on exactly the facts models are worst at — the long-tail specifics where the interpolation is thinnest. It's also why grounding does nothing for reasoning slips: the tokens are right there, but the inference that combines them is still a generation, not a lookup.

Retrieval quality is a hallucination control

Grounding is only the first half. The second half is that what you put in the context window, and how you arrange it, is itself a hallucination control — not a preprocessing detail you can hand-wave. A grounded system fed sloppy context produces confident, cited, wrong answers, which are the worst kind because they've laundered a guess through the appearance of evidence.

The failure surface that context engineering addresses head-on:

Precision over recall at the top. Retrieval that returns twenty marginally-relevant chunks to be safe is worse than one that returns the four that matter. Models exhibit a "lost in the middle" tendency — evidence buried in a long context gets underweighted relative to material at the start and end. A wall of loosely-relevant passages doesn't just waste tokens; it dilutes the signal and invites the model to synthesize across chunks that shouldn't be combined. Rerank hard, and put the strongest evidence where the model attends most.
Contradiction in the context. When retrieval surfaces two passages that disagree — an old policy and its replacement, two docs with different numbers — the model has to pick, and it often picks wrong or silently blends them. Deduplicate, prefer freshness, and when contradiction is genuine, make the model surface it rather than resolve it invisibly.
Chunk boundaries that sever meaning. A chunk that cuts off mid-clause, or strips the heading that scoped a figure, hands the model context it will misread. "The rate increased to 4%" is a landmine when the chunk dropped the sentence saying which rate. Chunk on semantic boundaries and carry enough surrounding context to keep claims interpretable.
Instruction vs. evidence bleed. If your retrieved documents contain text that looks like instructions ("ignore previous directions and…"), a naive prompt lets that text steer the model. Keep a clear structural boundary between "these are your instructions" and "this is untrusted source material to read."

The through-line: retrieval quality and hallucination rate are the same dial viewed from two angles. Every improvement in what reaches the context window — better ranking, cleaner chunks, fresher index, resolved contradictions — shows up downstream as fewer fabricated and drifted claims. This is why teams that treat retrieval as "solved" the moment vectors come back are the ones still fighting hallucinations they've misdiagnosed as a model problem.

Force citations you can actually check

Grounding gets the right text into context. Citations make the model prove it used that text. The instruction is simple: every factual claim must be attributed to a specific source span, and if a claim has no supporting span, the model must either drop it or flag it as unsupported.

Two things happen when you do this. First, you get an audit trail — a human or a downstream check can verify each claim against its cited span in seconds instead of re-researching from scratch. Second, and less obviously, the requirement itself reduces invention. A model that knows it has to point at a source is measurably less willing to assert things no source supports. It's the difference between "tell me what you know" and "show me where it says that."

Make citations checkable, not decorative. A citation to a document title is nearly useless — you can't tell if the claim is actually in there. A citation to a quotable span ("as stated in section 4.2: '…'") is verifiable by exact match. If your system can pull the quoted span back out of the source and confirm it exists, you've turned a trust problem into a string-matching problem. That last step — programmatically confirming quoted spans appear verbatim in sources — is one of the cheapest high-value checks you can build.

Give the model an exit: reward "I don't know"

Most confabulation is a refusal to leave a blank. The model has been trained on text where questions get answered, so faced with a question it can't ground, it produces the shape of an answer. The cure is to make abstention a first-class, rewarded outcome rather than a failure.

Concretely:

Say it explicitly in the prompt: "If the sources do not contain the answer, respond exactly: 'Not supported by the provided sources.' Do not guess." Vague permission ("it's okay to be unsure") underperforms a hard, named output.
Ask for a confidence signal. Have the model tag claims as stated in source / inferred / uncertain. You won't get calibrated probabilities — treat the labels as a triage sort, not a truth meter — but the relative ordering is useful, and the act of labeling makes the model more conservative.
Separate "what I know" from "what I'm inferring." A model that's forced to split direct evidence from inference will pad the inference section instead of smuggling guesses into the facts.

Skeptic's caveat: a model's self-reported confidence is generated text, not a readout of an internal truth gauge. It can be confidently wrong about being confident. Use these signals to decide what to verify, never as the verification itself.

Constrain the output space

Every degree of freedom you leave in the output is room to invent. Narrowing the output space narrows the hallucination surface:

Closed-world instructions. "Answer only using the provided text" beats "answer accurately." The first defines a boundary; the second is a wish.
Structured outputs. Ask for JSON with named fields, or a table with fixed columns. A model filling {"effective_date": ...} from a contract is more constrained than one writing a paragraph, and the empty field is an honest signal when the value isn't found. Enforcing that shape at the decoder level is the job of function calling and structured outputs.
Closed vocabularies. If the answer must be one of a known set (a product SKU, a category, an enum), say so and reject anything outside the set. This alone eliminates a whole class of invented specifics.
Scope limits. "List only the risks mentioned in section 3" prevents the model from helpfully adding risks it imagines are relevant.

A table helps here — different tasks want different constraints:

If your task is…	The high-leverage constraint is…	What it prevents
Extraction from a document	Structured fields; empty = "not found"	Invented values filling required slots
Q&A over a knowledge base	"Answer only from sources" + citations	Weight-recall drift past the sources
Classification / routing	Closed label set, reject out-of-set	Plausible-but-invented categories
Summarization	"Only claims present in the input"	Added conclusions and false emphasis
Open reasoning	Decompose into checkable steps	Confident non-sequiturs

Verify with a second pass

The single biggest mindset shift: do not trust a first-pass generation. A model's first output is a draft asserted with the same confidence whether it's right or wrong. Verification is a separate step that treats the draft as a hypothesis.

Options, roughly in order of cost and rigor:

Deterministic checks. The cheapest and most reliable. Does the cited quote appear in the source? Does the extracted date parse? Do the numbers in the summary match numbers in the input? Does the SKU exist in the catalog? Wherever a claim maps to something you can look up or compute, do that — don't ask a model to re-judge what code can settle.
A separate verifier pass. Give a fresh model call the draft plus the sources and ask a narrow question: "For each claim, is it supported by the sources? Answer supported / unsupported / contradicted." A verifier scoped to judging one claim at a time is far more reliable than one asked to both write and self-police in a single breath. This is the LLM-as-a-judge pattern, and its strengths and blind spots carry over directly. Fresh context matters — a model asked to critique its own reasoning in the same thread tends to defend it.
Self-consistency. Sample the answer several times; if the model gives the same grounded answer across runs, it's more likely stable, and wild disagreement flags a guess. This costs tokens and won't catch consistently-wrong answers, but it's a cheap smoke alarm for shaky ones.
Human-in-the-loop for the tail. You don't need humans on every output — you need them on the ones the automated checks flag as unsupported, low-confidence, or high-stakes. Route by risk.

There's a cost dimension here that's easy to ignore: verification passes and multi-sample checks multiply your token spend. That's a real trade-off, and worth modeling against the cost of a wrong answer — the inference cost economics guide is the right frame for deciding how much verification a given task can afford. For a legal or medical output, heavy verification is cheap insurance. For a "suggest a blog title" feature, it's overkill.

Prompt patterns that suppress confabulation

Prompting is the smallest lever in this list — it can't fix missing grounding — but the right patterns still measurably cut invention, and they're free. The ones that earn their place:

"Cite or abstain." "For every claim, quote the supporting source span. If you can't, say the claim is unsupported." Combines two controls above into one instruction.
Decompose before answering. For anything with reasoning steps, ask the model to lay out the steps first, then answer. This exposes the slip in step 3 instead of burying it in a confident conclusion. (Verify the steps, though — a plausible chain can still be wrong.)
Negative instructions with teeth. "Do not use any information not present in the sources. Do not fill gaps with general knowledge." Blunt, but effective when paired with grounding.
Ask for what's missing. "List any parts of the question the sources do not answer." This flips the model's default from padding to gap-finding.

What doesn't reliably work: begging ("please be accurate, this is very important"), threats, and long lists of "don't hallucinate" pleas. These are folklore. The how to write better prompts guide has the broader discipline; for hallucination specifically, structure and grounding beat exhortation every time.

System-level guardrails

Everything above is per-request. The last layer is architectural — decisions that make the whole system safer regardless of any single prompt:

Match the model to the risk. Stronger models confabulate less, but "stronger" isn't free and isn't always available. Choosing the right model per task — including when a smaller or open-weights model is fine — is a real design decision; the how to choose an LLM for your app guide walks it.
Fail closed on high stakes. If a claim can't be verified and the action is irreversible (sending money, filing a document, changing a record), block it and escalate. Don't let unverified output touch anything you can't undo.
Log claims and their sources. When something goes wrong, you want to know whether it was a retrieval miss, a grounding failure, or a reasoning slip. You can't improve a rate you don't record.
Show sources to the end user. Surfacing the citations isn't just transparency — it moves the last verification step to the human who has the most context to catch an error. A visible source is a hallucination speed bump.
Measure the rate. Build a small evaluation set from your own real queries, label the answers, and track a hallucination rate over time. Every change above should move that number, and without it you're tuning blind. This is the same discipline the answer-engine and GEO/AEO world applies to being cited accurately — turned inward on your own outputs.

The limited role of fine-tuning

There is a persistent hope that hallucination is a training problem — that if you just fine-tune the model on your domain, it will stop making things up. Mostly, it won't, and understanding why saves an expensive detour.

Fine-tuning reliably changes behavior and form: tone, format, how the model structures an answer, whether it follows your output schema, which of several valid styles it prefers. It's excellent at "always respond in this JSON shape" or "adopt this house voice." What it does not reliably do is install new facts or make the model abstain when it should. Teaching facts by fine-tuning is fighting the mechanism — you're nudging a giant interpolation with a few thousand examples, and the model will happily pattern-match your examples' style while still reconstructing facts from its original blurry prior. Worse, there's a documented failure mode: fine-tuning a model on facts it didn't already "know" can increase hallucination, because you're training it to produce confident assertions in a domain where its knowledge is thin — you've taught the shape of expertise without the substance.

The one place fine-tuning genuinely helps hallucination is teaching the abstention and citation behavior you want — training the model to reliably say "not in the sources" and to attribute claims — so that grounding does more work with less prompting. That's real value. But notice it's still grounding doing the factual heavy lifting; fine-tuning is just making the model a more disciplined reader. If you find yourself reaching for a fine-tune to fix factual errors, that's almost always a sign you should be fixing retrieval instead. Fine-tuning sits near the bottom of the leverage stack for a reason: high cost, narrow benefit, and a real chance of making the problem worse if you aim it at facts.

Why you can reduce but not eliminate hallucination

It's worth being precise about why zero is off the table, because the reason dictates the strategy. This isn't pessimism or a temporary limitation waiting on the next model — it's structural.

A language model is a probability distribution over next tokens. It is trained to make plausible text likely, and it has no separate, queryable representation of "true." Truth and plausibility are correlated in the training data — true statements are common, so they're plausible — but they are not the same variable, and nothing in the objective forces them to align on any specific output. When the two diverge, which happens most on rare facts, precise specifics, and novel combinations, the model optimizes for plausibility because that's the only thing it was ever optimizing for. The confident, well-formed, wrong answer isn't a malfunction; it's the system working exactly as designed, producing the most probable continuation regardless of whether that continuation is true.

This has three consequences that shape the whole playbook:

There is no internal truth gauge to read. The model doesn't secretly know it's wrong. Its "confidence" is a property of the token distribution, not a fact-check. That's why you verify externally rather than asking the model to police itself — the information you need to catch the error isn't inside the model.
Better models raise the floor but don't reach it. A stronger model has a smoother, better-calibrated distribution, so plausibility and truth diverge less often. That genuinely lowers the rate. But the divergence is never zero, and a stronger model's errors are more dangerous per incident because they're more fluent and more likely to slip past a reviewer. Scale changes the numbers, not the nature.
The controls in this playbook attack the gap, not the mechanism. Grounding narrows the gap by making the plausible answer and the true answer the same span of text. Verification catches cases where they still diverged. Neither removes the underlying property. You're building a system whose composite error rate is low even though its central component's error rate never hits zero — the same way aviation is safe despite no single part being perfect.

So the honest target is not "no hallucinations." It's a known, measured, acceptable hallucination rate for your risk level, with the residual errors made shallow (they don't cascade) and catchable (something downstream flags them). A team that internalizes this stops waiting for the model that fixes everything and starts engineering the system that manages it.

Measuring your hallucination rate

Everything above is unfalsifiable until you measure. "It feels more accurate now" is how teams ship regressions. If you take one operational habit from this playbook, make it this: build an evaluation set from your own real queries and track a hallucination rate on it.

The minimum viable version is not fancy:

Collect real queries. Pull fifty to a few hundred actual questions your system gets — real ones, with their messiness, not the clean examples you'd write yourself. The distribution of real queries is where the real failures live.
Capture answers and their sources. For each query, log the model's answer and the retrieved context it was given. You can't diagnose a failure without knowing what the model saw — a wrong answer over the right sources (drift) and a wrong answer over the wrong sources (retrieval miss) need opposite fixes.
Label against a rubric, not a vibe. For each claim in each answer, mark it supported (a source span backs it), unsupported (no span, possibly-true addition — extrinsic), or contradicted (a span says otherwise — intrinsic). Your hallucination rate is the fraction of claims that are unsupported or contradicted. Labeling per-claim rather than per-answer gives you a finer signal and maps directly onto the taxonomy above.
Separate retrieval failures from generation failures. For each bad answer, ask: was the needed evidence even in the context? If not, it's a retrieval problem, and no amount of prompt tuning fixes it. This split tells you which layer of the stack to spend on next.
Track it over time and gate changes on it. Re-run the set on every meaningful change — new prompt, new model, new retriever. Every control in this playbook should move the number; if a change doesn't, you've learned something cheap. Treat a regression as a blocker, not a footnote.

You can automate a chunk of the labeling with an LLM-as-a-judge verifier — a separate model call that scores each claim against the sources — but calibrate the judge against human labels on a sample first, because a judge with its own blind spots will happily report a great score while missing the failures it shares with the generator. The judge is a labor multiplier, not a replacement for having looked at your own outputs. And there's a discipline analogy worth borrowing: the answer-engine and GEO/AEO world obsesses over being cited accurately by other people's models; here you turn the same rigor inward, auditing whether your own system's claims survive a source check.

A decision framework by risk level

Not every task deserves the full stack. Verification passes cost tokens and latency; guardrails add complexity; human review doesn't scale. The right amount of hallucination control is a function of what a wrong answer costs, and the honest move is to size the controls to the stakes rather than applying maximum rigor everywhere (which just means you'll cut corners inconsistently) or minimum rigor everywhere (which means the one high-stakes path is unprotected). Model the cost against the inference economics of each verification layer, then decide per tier.

Risk tier	Example	Cost of a wrong answer	Controls to apply
Low	Draft a blog title, brainstorm ideas, casual summary	Trivial; a human edits it anyway	Grounding if convenient; basic prompting. Skip heavy verification.
Medium	Internal knowledge-base Q&A, first-draft research, support suggestions	Wasted time, mild embarrassment, a human is in the loop	Grounding + citations + abstention + structured output. Spot-check with a verifier pass.
High	Customer-facing answers, financial or contractual figures, anything published unedited	Real money, reputation, a public retraction	Full stack: grounding, citations, deterministic checks, separate verifier pass, fail-closed on unverifiable claims.
Critical	Medical, legal, safety, irreversible actions (payments, filings, record changes)	Harm, liability, actions you can't undo	Everything above plus mandatory human-in-the-loop. The model drafts and cites; a qualified human decides. Never auto-execute.

Two rules make the framework work in practice. First, classify the action, not the feature. One product can span tiers: a legal assistant that brainstorms argument angles (low) and also drafts citations for a filing (critical) needs different controls on the two paths, not one average setting. Second, fail closed as stakes rise. In low tiers, an unverifiable claim can pass with a soft flag. In critical tiers, an unverifiable claim blocks the action and escalates — the default when in doubt is stop, not proceed. Choosing the model per tier is part of this too; the how to choose an LLM for your app guide covers when a stronger model earns its cost and when a smaller or open-weights model with good grounding is enough.

Common mistakes

The failures below aren't exotic. They're the default mistakes competent teams make, and each one comes from a plausible-but-wrong intuition.

Trusting the model's confidence. The single most common error. A fluent, assertive answer reads as a reliable one, and it simply isn't — fluency is what the model optimizes for, independent of truth. Self-reported confidence ("I'm certain that…") is generated text, not a gauge. Use it to decide what to double-check; never as the check.
Believing a bigger model fixes it. Stronger models hallucinate less, so the reasoning goes, upgrade and you're done. But scale lowers the rate without changing the nature, and it makes the surviving errors more convincing and harder to catch. A bigger model with no grounding still confabulates on your private data, which it never saw in training. Grounding beats scale on exactly the facts you care about.
Confusing faithfulness with factuality. Teams build a great source-check, watch the "supported by sources" rate hit 99%, and declare victory — while the sources themselves are stale or wrong. Faithful to bad evidence is still wrong to the user. Faithfulness is your job; the quality of the source of truth is a separate job you also can't skip.
Treating retrieval as solved. Vectors come back, so grounding is "done." Then the confident-cited-wrong answers roll in and get misdiagnosed as a model problem. Most grounded-system hallucinations are retrieval failures; measure the split before you tune the generator.
Fine-tuning to fix facts. The expensive detour from the section above — reaching for a fine-tune when the fix is retrieval, and sometimes making hallucination worse by teaching confident assertion in a thin-knowledge domain.
Prompt-begging. Stacking "please be accurate, this is very important, do not hallucinate" and expecting results. It's folklore with marginal effect. Structure and grounding beat exhortation every time.
No measurement, so no idea. Shipping changes on vibes. Without a hallucination rate on your own queries, every "improvement" is a guess and every regression is invisible until a user finds it.
One rigor setting for the whole product. Either maximum verification everywhere (slow, expensive, so corners get cut) or minimum everywhere (the one critical path is exposed). Size controls to the stakes, per action.

FAQ

Can you eliminate AI hallucinations completely? No. A language model generates plausible text, and plausibility is not truth — some fraction of confident, wrong output is inherent to the technology. The realistic goal is to make hallucinations rare, shallow, and catchable through grounding, citations, constraints, and verification, not to reach zero.

What is the single most effective way to reduce hallucinations? Grounding the model in retrieved source text and instructing it to answer only from that text. Moving the task from recall (reciting from weights) to reading comprehension (answering from documents in the context window) does more than any prompt trick. In grounded systems, most "hallucinations" are actually retrieval failures — fix retrieval first.

Does asking the model to "be accurate" or "not hallucinate" work? Barely. Pleas, threats, and "this is very important" framing are folklore that produce marginal effects at best. What works is structural: putting the right sources in context, forcing checkable citations, constraining the output format, giving the model an explicit way to abstain, and verifying the answer with a separate pass.

How do I catch hallucinations automatically? Layer cheap deterministic checks (does the cited quote appear verbatim in the source? do the numbers match? does the ID exist?) under a separate verifier model call that judges each claim as supported, unsupported, or contradicted against the sources. Use a fresh context for the verifier — a model reviewing its own reasoning in the same thread tends to defend it.

Can I trust a model's confidence score? Not as a source of truth. Self-reported confidence is generated text, not a calibrated readout, and models can be confidently wrong about being confident. Use confidence and "uncertain" tags to decide what to verify, never as the verification itself.

Do reasoning models hallucinate less? They tend to make fewer reasoning slips because they decompose problems into steps, and stronger models generally confabulate less on facts. But they still invent when ungrounded, and a longer chain of reasoning can produce a more elaborate wrong answer. Grounding and verification remain necessary regardless of model class.

Will fine-tuning on my data stop the hallucinations? Usually not, and it can backfire. Fine-tuning reliably changes style, format, and behavior — it's great for teaching a consistent output shape or house voice — but it does not reliably install facts. Training a model on facts it didn't already know can even increase hallucination, because you're teaching it to assert confidently in a domain where its knowledge is thin. The durable fix for factual errors is grounding in retrieved sources, not baking facts into weights. Fine-tuning's real hallucination value is teaching abstention and citation behavior so grounding works with less prompting.

What's the difference between faithfulness and factuality, and which should I optimize? Factuality is agreement with the real world; faithfulness is agreement with the source you provided. In a grounded system, optimize faithfulness first — it's the property you can enforce and check, because you control the source. But don't stop there: a perfectly faithful answer built on a stale or wrong source is still wrong to the user. Faithfulness is your model's job; keeping the source of truth accurate and current is a separate job you also can't skip.

How do I know if my problem is the model or my retrieval? Log the context the model was given alongside each answer, then for every wrong answer ask whether the needed evidence was even in that context. If it wasn't, it's a retrieval failure and no prompt or model change will fix it. If it was there and the model still got it wrong, that's genuine generation drift. In most grounded systems the majority of "hallucinations" turn out to be retrieval misses in disguise, so measure the split before you spend on either side.

The bottom line

Hallucination isn't a phase the technology is about to grow out of. It's a standing property of predictive text models, which means the right response is engineering, not patience. Ground the model so it reads instead of guesses. Force citations you can check. Give it permission to say "I don't know." Constrain what it's allowed to output. Verify before you trust, with the rigor scaled to the stakes. And measure the rate so you know whether any of it is working.

Do those things and you won't get to zero — nobody does. But you'll turn an unpredictable liability into a managed risk with a known error rate and a paper trail. That's the difference between a demo and a system you can put in front of users. If you want the underlying mechanics of why the model does this in the first place, the why-they-happen explainer is the companion piece; this one was about what to do about it.