blog

How to Actually Prevent AI Hallucinations: The Methods, Ranked

August 2, 2026 · #ai #hallucination #rag #reliability #llm #methods

A while back I wrote about why AI hallucinates: it predicts plausible tokens, it was trained on incentives that reward a confident guess over an honest “I don’t know,” and so it will invent a citation, a court case, an API that doesn’t exist, and hand it to you with a straight face.

That post answered why. This one is the other half, and the more practical half: what do you actually do about it?

Because “add some guardrails” is not a plan. There are roughly ten distinct methods to reduce hallucination, and they are wildly different tools. One is nearly free and you should always use it. One multiplies your inference bill by ten. Some fix the problem at the root; others just paper over it so it’s harder to notice. If you reach for the wrong one, you spend a lot and fix little.

So this is the ranked, opinionated tour. For each method: how it works, what it genuinely costs, what it can’t do, and when it’s the right call.

First cut: fix the root, or hide the symptom?

Before the list, one distinction that sorts everything else. Some methods reduce hallucination by giving the model better information to work with. Others let it hallucinate freely and then try to catch the bad output on the way out. Both are useful. They are not the same thing.

Root fixes (upstream)

Change what the model has to work with before it generates. Give it the real document, the calculator, the current fact. It hallucinates less because it's guessing less.

RAG, tool use, fine-tuning, better prompts

Symptom catches (downstream)

Let it generate, then inspect the output and block, flag, or fix what looks wrong. Necessary, but it's cleanup: the model still made the thing up, you just caught it.

Verifier chains, guardrails, abstention, human review

The biggest wins are upstream. You get far more from feeding the model good context than from policing bad output, though in production you do both.

Keep that split in mind. When people say “we added hallucination protection” and mean a single output filter, they’ve done the cheaper, weaker half and skipped the part that actually moves the numbers.

The whole toolkit, at a glance

Here’s every method side by side before we go deep. Read the cost column carefully: it’s the part most guides gloss over.

MethodWhat it doesCost / latencyFixes root?
RAG / groundingRetrieve real docs, answer from them1 retrieval + bigger promptYes
Cite + verifyCheck each claim against the source+1 model passCatch
Prompt techniqueCoT, "say I don't know", decomposenear freePartial
Self-consistencySample N times, majority voteN times inferenceCatch
LLM-as-judgeA second model scores the first+1 (bigger) callCatch
Guardrails / schemaForce valid structure, enforce railscheap to moderateFormat only
Factuality fine-tuningTrain the weights toward truthhigh upfront, free at runYes
Abstention / uncertaintyMeasure doubt, decline when highoften N times samplingCatch
Human-in-the-loopA person signs off risky outputslow, labor costCatch
Tool use / KGOffload facts to calculator, search, graphextra tool callsYes
Green is cheap, teal is moderate, purple is expensive. Notice the pattern: the cheapest methods (prompting, schema) are partial fixes, and the strongest root fixes (RAG, tool use, fine-tuning) cost real money or effort. There's no free lunch, only sensible trades.

Now the deep version. I’ve grouped them root-fixes first, catches second, roughly in the order you’d actually adopt them.

1. RAG: give it the facts instead of asking it to remember

The single biggest lever, and the first thing to reach for. Instead of hoping the answer is buried somewhere in the model’s weights, you retrieve the relevant documents at question time and put them right in the prompt. The model reads facts instead of recalling a fuzzy impression of them.

01RAG / grounding
Pros
Attacks hallucination at the root: less guessing
Updatable without retraining, just change the docs
Gives you citations for free
Cons
Only as good as retrieval: wrong chunk in, wrong answer out
The model can still ignore the context and invent anyway
Struggles on multi-hop questions
Reach for it when: any domain-specific or knowledge-heavy task. Support bots, internal search, anything over your own data. If you do one thing, do this.

The honest caveat, which too many RAG guides skip: retrieved does not mean correct. Feed it the right document and a model can still revert to its own invented version, or the retriever fetches the wrong passage entirely. RAG drives hallucination way down; it does not abolish it. Which is exactly why you layer the next methods on top. (I went deep on doing RAG well in the RAG design post.)

2. Cite, then actually verify the citation

RAG gets the docs in front of the model. This layer makes it accountable to them. You require a source for every claim, then you check that the source actually says what the model claims it says. That check is the important part, a citation nobody verifies is just decoration.

02Citation + groundedness verification
Pros
Catches ungrounded claims plain RAG lets through
Produces auditable, traceable answers
Managed options exist, no training needed
Cons
Adds a second model pass per answer
The checker has its own error rate
Auto-correction can quietly distort meaning
Reach for it when: regulated or high-stakes RAG (health, legal, finance) where every claim must trace to a source. Managed versions: AWS Bedrock contextual grounding check, Azure groundedness detection, Vertex grounding.

The cost here is concrete: one extra classifier or LLM call per response, sometimes per claim. That’s latency and money on every single answer. Worth it when a wrong claim is expensive; overkill for a casual chatbot.

3. Prompt techniques: the nearly-free baseline

Before you spend anything, spend words. Three prompt moves genuinely reduce hallucination at almost zero cost. Chain-of-thought (“think step by step”) makes the model reason before answering. Explicitly permitting “I don’t know” gives it an exit that isn’t fabrication. And decomposition, breaking a hard question into checkable pieces, stops it from bluffing through a leap it can’t make.

03Prompt techniques (CoT, abstain, decompose)
Pros
Nearly free, no infra change
CoT lifts reasoning-heavy accuracy a lot
"You may say you don't know" cuts confident bluffing
Cons
CoT can produce plausible-but-wrong reasoning
Helps big models more than small ones
Prompt-only gains are fragile, they shift with the model
Reach for it when: always. This is your baseline layer, on top of everything else. Especially good for math and multi-step reasoning, and any task where "no answer" is an acceptable answer.

The only real cost is tokens: chain-of-thought makes the model write more, which is a bit more latency and spend. Cheap insurance.

4 and 5. Sample-and-vote, and the second-opinion model

Two catches that both work by not trusting a single generation.

Self-consistency samples the same question several times and takes the majority answer. If the model lands on “42” four times out of five, that’s a stronger signal than one lucky (or unlucky) roll. LLM-as-judge uses a separate, often stronger model to score the first one’s output for factuality before it ships.

Self-consistency on GSM8K mathWang et al., 2022, arXiv:2203.11171
+17.9%
Self-Refine, average gain across tasksMadaan et al., 2023, arXiv:2303.17651
~20%
Strong LLM judge vs human agreementZheng et al., 2023, arXiv:2306.05685
>80%
These are real reported gains, but each is tied to a specific model and benchmark. Read them as "X reported Y% on task Z," not universal constants. A GPT-4-class judge agreeing with humans over 80% of the time is notable: that's about the rate two humans agree with each other.

The catch, literally, is cost. Self-consistency multiplies your inference by however many samples you draw, five, ten, more. A judge adds a full (and usually larger, pricier) model call per answer. These buy real accuracy, and they buy it by the token.

04·05Self-consistency and LLM-as-judge
Pros
Large, reliable accuracy gains, no training
Judge scales up automated quality gates
Both work purely at inference time
Cons
Self-consistency costs N times inference
A judge can share the generator's blind spots
Judges have biases (verbosity, position, self-preference)
Reach for it when: high-value answers where accuracy beats cost. Self-consistency for math and reasoning with a votable answer; a judge for gating candidate answers before users see them.

6. Guardrails and schema-constrained decoding: structure, not truth

This one is widely misunderstood, so let me be blunt about what it does and doesn’t do. Constrained decoding forces the output to match a grammar or JSON schema, so you can’t get an invalid enum or a missing field. Guardrail frameworks add programmable input and output rails: topic boundaries, policy checks, validators.

Here’s the trap: constrained decoding guarantees the output is well-formed, not that it’s true. The model can hand you perfectly valid JSON with a completely invented value inside it. Structure is not fact.

06Guardrails / structured output
Pros
Eliminates format and enum hallucination outright
Rails enforce policy and topic boundaries
Constrained decoding is cheap
Cons
Guarantees structure, NOT semantic truth
Rails can over-block valid output
Adds engineering and per-turn checks
Reach for it when: any structured extraction or tool-calling flow (use schema constraints), and wherever policy plus fact-checks must be enforced in code (use a guardrail framework like NeMo Guardrails or Guardrails AI).

7. Factuality fine-tuning: bake truth into the weights

Everything so far happens at inference. This one changes the model itself. You build preference pairs that reward factual answers over confident-but-wrong ones and train on them (the FactTune work does this with DPO and no human labels). The payoff is unusual: the cost is entirely upfront, and inference stays cheap.

Factual error reduction, factuality fine-tuningFactTune, Tian et al., 2023, arXiv:2311.08401, on a 7B model
58%
A big drop, but note the fine print: it's a specific model on a specific factuality benchmark, and naive fine-tuning can backfire, teaching a model to confidently state things it doesn't actually know. Done wrong, it makes hallucination worse.
07Factuality fine-tuning / RLHF
Pros
Bakes factuality into the model, zero per-query overhead
Durable gains beyond what prompting can reach
Modern methods need no human labels
Cons
Expensive and slow to train, needs a pipeline
Naive tuning can increase hallucination
Risk of over-refusal or lost capability
Reach for it when: you own the model, have real volume, and want lasting factuality gains that prompting and RAG can't give you. Not a first move.

8. Know when it doesn’t know: uncertainty and abstention

A different idea entirely: instead of trying to make every answer right, measure how sure the model is and let it decline when it isn’t. The elegant version is semantic entropy (a 2024 Nature result): sample several answers, cluster the ones that mean the same thing, and measure the spread of meanings. High spread means the model is confabulating, low spread means it’s confident. SelfCheckGPT does a black-box cousin of this by checking whether repeated samples agree.

08Uncertainty estimation / abstention
Pros
Turns a confident wrong answer into a safe "not sure"
Semantic entropy needs no ground-truth labels
Generalizes across tasks and datasets
Cons
Sampling variants cost N times inference
Thresholds need tuning per use case
Abstain too often and the thing becomes useless
Reach for it when: high-stakes settings where a confident wrong answer is worse than no answer. Pairs beautifully with the next method: abstain, then route the uncertain ones to a human.

9 and 10. The human, and the tool

Two last methods that bookend the list.

Human-in-the-loop is the highest-reliability option and the least scalable: route the risky, low-confidence, or flagged outputs to a person before they’re final. It’s slow and it costs labor, and humans have their own failure mode (they wave through fluent, wrong text because it reads well). The trick is not to review everything, but to review only what your uncertainty method (method 8) flagged.

Tool use and knowledge graphs attack the root from a different angle: stop asking the stochastic model to be a database. Let it call a calculator for arithmetic, a search API for current facts, a knowledge graph for structured relations. The exact facts live in deterministic systems; the model just orchestrates. This is why a model that’s hopeless at mental math becomes reliable the moment you give it a code tool.

09·10Human review and tool use / knowledge graphs
Pros
Human review is the highest reliability there is
Tools move exact facts out of the stochastic model
Deterministic tools give verifiable, current answers
Cons
Humans are slow, costly, and miss fluent errors
Tools and graphs must exist, be correct, and stay current
The model can still misuse a tool's output
Reach for it when: human review for regulated sign-off and irreversible actions; tools and KGs for anything numeric, computational, or needing live facts.

So what do you actually build?

You don’t pick one. Every serious production system layers several, cheapest and most-fundamental first, because each catches a different failure.

1Ground it. RAG plus tool use, so it's reading facts, not guessing them. The root fix.
2Prompt it well. Chain-of-thought and explicit permission to say "I don't know." Nearly free.
3Constrain it. Schema and guardrails so the shape is always valid and policy holds.
4Verify it. Check claims against sources, and abstain when uncertainty is high.
5Escalate it. Route the flagged, high-risk answers to a human. Only those.
The layered defense. No single method eliminates hallucination, so you stack them: each layer is cheap relative to the failure it prevents, and together they turn "confidently wrong" into "grounded, cited, and honest about its limits."

The takeaway

Preventing hallucination isn’t one trick, it’s a budget decision. The cheap methods (good prompts, schema constraints) are worth doing always but only get you part way. The strong methods (RAG, tool use, verification, fine-tuning) cost retrieval calls, extra model passes, training runs, or human time, and you spend those where being wrong is expensive.

The mistake I see most is teams bolting a single output filter onto an ungrounded model and calling it solved. That’s the weakest, most downstream layer doing all the work. Start upstream. Give the model the facts, let it admit doubt, and only then spend on catching what slips through. Do that and you don’t eliminate hallucination, nobody does, but you push it from “the reason we can’t ship” to “a managed, measured risk.”

This is the methods companion to Why AI Hallucinates, and How We Actually Stop It. For the grounding layer in depth, see Designing a RAG System That Actually Retrieves.

References

Written from scratch; these are the primary sources behind the methods and numbers above. Nothing here is copied from them.

← Back to blog