How to Reduce AI Hallucinations: What Actually Works

Why models invent things — the mechanism, not the metaphor

A language model predicts what text plausibly comes next. That is the entire operation. It has no separate store of facts it consults and no internal flag distinguishing "I know this" from "this pattern looks right".

When you ask for a citation, the model has seen thousands of citations. It knows exactly what one looks like: an author, a plausible year, a title in the right register, a journal that publishes that kind of work. Generating a well-formed citation is easy. Generating a *true* one requires having the specific paper represented, and the model cannot tell the difference between those two situations from the inside.

This reframes the problem usefully. Hallucination is not a malfunction that better engineering will remove; it is the same capability that makes the model useful, applied where it has nothing to draw on. The model that can write a convincing paragraph about a topic it knows is the same model that writes a convincing paragraph about one it does not.

Why "do not hallucinate" does nothing

This instruction appears in an enormous number of prompts and it is close to useless, for a reason worth understanding.

The model is not withholding accuracy out of laziness. At the moment it generates a fabricated fact, it has no signal that the fact is fabricated — it is producing the most plausible continuation, which is exactly what it does when producing a true one. There is no internal switch labelled "be accurate" for your instruction to flip.

What does work is changing the situation rather than issuing an instruction: giving it material to draw on, giving it an acceptable alternative to guessing, and asking it to mark the difference between what it was given and what it inferred. Those are structural, and they measurably change output.

The single most effective fix: supply the source

Nothing else comes close. A model asked to summarise a document you provided is operating in a completely different regime from one asked to recall facts about a topic.

In the first case the information is in front of it and the task is transformation. In the second, the task is retrieval from a lossy statistical representation, which is where invention lives. Moving a question from the second category to the first is the highest-leverage change available.

This is the entire principle behind retrieval-based systems, and you can apply it manually without any infrastructure: paste the actual policy rather than asking what the policy says, paste the actual code rather than describing it, paste the article rather than asking what it argued.

• Instead of "what does GDPR say about consent" → paste the relevant articles and ask for a summary.
• Instead of "what are our refund terms" → paste the terms and ask it to answer from them.
• Instead of "what did this study find" → paste the abstract and results.
• Add the constraint that closes the loop: "Answer only from the text above. If the text does not address something, say so rather than filling it in from general knowledge."

Give it a way out

A model with no acceptable alternative to answering will answer. Explicitly permitting "I do not know" changes the behaviour, because it makes admission a valid completion rather than an apparent failure.

This is one line and it belongs in every prompt where accuracy matters. The phrasing that works is specific about what to do instead, not merely permissive.

The same principle covers partial knowledge, which is the more common and more dangerous case: the model knows the general shape of an answer but not the specific detail, and fills the detail in. Asking it to name the boundary — what it is confident about versus what it is extrapolating — surfaces exactly the part you need to check.

• "If you do not know, say so plainly. An admission is more useful to me than a guess."
• "Do not invent names, numbers, dates, citations or URLs. Leave a marked blank instead."
• "State which parts of your answer you are confident about and which you are extrapolating."
• "If the question contains a false premise, address the premise before answering."

Separate what was given from what was inferred

Most dangerous outputs are not wholly fabricated. They are a mix: several accurate statements drawn from what you supplied, plus one plausible inference presented in exactly the same register.

That uniform register is the problem. When everything is stated with equal confidence, you cannot tell by reading which sentence needs checking, so either you check all of them or you check none.

Asking for the separation solves this cheaply. Requiring quotes for anything drawn from the source, and a label for anything inferred, turns an undifferentiated wall of claims into a document where the risky parts are visible.

• "Quote the exact sentence you are basing each claim on."
• "Mark anything you are inferring rather than reading directly with Inference:."
• "List separately: what the document states, what it implies, and what it does not address."
• "If two parts of the source conflict, say so rather than reconciling them yourself."

Where hallucination concentrates

Fabrication is not evenly distributed. Knowing where it clusters tells you where to spend your checking effort.

• Citations and references. The highest-risk category by a distance. A well-formed citation is trivially easy to generate and requires specific knowledge to get right.
• Precise numbers. Statistics, percentages, dates, version numbers, prices. The shape of a number is easy; the value is not.
• Named entities in specific combinations. A real person paired with a real company they never worked for, or a real feature attributed to the wrong product.
• Anything recent. Beyond a model's training data it is extrapolating, and it rarely signals the boundary unaided.
• Niche technical detail. The more specialised the domain, the thinner the representation, and the more the output resembles plausible-sounding domain vocabulary.
• API and library specifics. Method names that follow the naming conventions of a library perfectly while not existing.
• Legal, medical and regulatory specifics. Where the cost of a confident error is highest and the surface detail is easiest to imitate.

Techniques that reduce it, ranked by effect

Roughly in order of how much difference they make in practice.

• Supply the source material and restrict the answer to it. By far the largest effect. Converts recall into transformation.
• Permit and specify the "I do not know" behaviour. One line, disproportionate effect.
• Require quotes for factual claims. Makes fabrication visibly harder, because a made-up quote from a document you can see is much easier to catch than a made-up fact.
• Ask twice, in separate conversations. Genuine knowledge is stable; fabrication varies. Contradiction between runs is a strong signal.
• Have a second model check the first. Different training, different failure modes — a checker often catches what the writer invented.
• Narrow the question. Broad questions invite synthesis, and synthesis is where invention enters.
• Ask for uncertainty at the point it arises, not summarised at the end. Confidence flagged inline is actionable; a general caveat is decoration.
• Lower the temperature where the interface allows it. Modest effect, and it reduces variety rather than increasing truthfulness — worth doing, not worth relying on.

The re-ask test

This is the cheapest verification available and almost nobody does it: ask the same factual question again, in a fresh conversation, phrased differently.

Information the model genuinely represents comes back consistently. Fabricated detail is generated fresh each time and tends to vary — a different year, a different author, a slightly different figure.

It is not a proof of truth: a model can be consistently wrong about something it has seen stated incorrectly many times. But inconsistency is a reliable signal of fabrication, and it costs one extra query. For any specific number, name or citation you are about to rely on, it is the highest return-on-effort check there is.

Using a second model as a checker

Two models trained differently do not fabricate identically. That makes a second model a useful, if imperfect, check on the first.

The way to use it is not "is this correct" — that invites the checker to generate its own confident opinion. Frame it as an extraction task instead: ask the second model to list every specific factual claim in the text, and to flag each one it cannot verify from the source provided.

Two honest caveats. Models can agree on the same plausible error, particularly where a misconception is widespread. And a checker with no source material is guessing as much as the writer was. It is a filter, not an oracle — but it is a filter that catches a meaningful share of invented specifics before they reach a person.

What prompting cannot fix

Being clear about the ceiling is what separates useful advice from reassurance.

No prompt makes a model reliable on facts it does not have. You can reduce the rate at which it invents, make invention easier to spot, and shift its default toward admitting ignorance. You cannot install a truth-checker that was never there.

This means verification stays your job wherever the cost of being wrong is real. The practical line is worth stating plainly: for anything that goes to a customer, into a legal or medical context, into code that runs unattended, or into a document with your name on it, every specific claim needs a source you have actually opened. Not the source the model cited — the source you checked.

A workflow for work that has to be right

Combining the above into something you can actually follow.

• Supply the source material rather than relying on recall, wherever the source exists.
• Restrict the answer to that material explicitly, and require quotes for factual claims.
• Include the permission to not know, with the specific alternative behaviour spelled out.
• Ask for claims and inferences to be separated so the risky parts are visible.
• Re-ask any specific number, name, date or citation in a fresh conversation and compare.
• Open every citation. A cited link that exists does not mean the link supports the sentence attached to it — this is a distinct and common failure.
• Have a second model list the unverifiable claims before a human reviews it.
• Keep a human decision on anything consequential. Not a skim — a check of the specific claims.

The failure mode to watch for in yourself

The genuine risk is not that models invent things. It is that they invent things fluently, and fluent text lowers a reader's guard.

A hedged, awkward, partially-wrong answer gets scrutinised. A polished, confident, partially-wrong answer gets accepted. The better the writing, the less carefully it is read — which means improving output quality can increase the rate at which errors get through.

The habit that protects you is simple and slightly tedious: read for specifics rather than for coherence. Coherence is what the model is best at and tells you nothing about accuracy. Every number, name, date, citation and quantified claim is a thing to check, regardless of how well the paragraph around it reads.

Retrieval is the real fix, and prompting is the patch

Every technique above works on the assumption that the model has to answer from what it already absorbed. The structural solution is to stop making it do that: put the authoritative text in front of it, and reduce the task from recall to reading.

That is what retrieval-augmented generation is, stripped of the acronym. Search your own documents, paste the relevant passages into the prompt, and ask the question against them. The model is now doing comprehension rather than memory, and comprehension is the thing it is genuinely reliable at.

It does not eliminate the problem. Retrieval introduces its own failure — the model given six passages, none of which contain the answer, will often synthesise one anyway from the general shape of what it read, and it will sound exactly as confident as a grounded answer. The prompt has to close that door explicitly.

• Instruct scope plainly: "Answer only from the passages below. If the passages do not contain the answer, reply exactly: NOT IN SOURCES."
• Require attribution per claim: "After each sentence, cite the passage number it came from. Any sentence without a citation must be removed."
• Ask it to name what is missing: "List any part of the question the passages do not address." This turns a silent gap into a visible one.
• Watch for the passage that is topically close but factually irrelevant — the most common cause of a confidently wrong grounded answer. Ask the model to state why each cited passage is relevant.
• Check retrieval separately from generation. When a grounded answer is wrong, the fault is usually in what was retrieved, not in how it was read, and rewriting the prompt will not touch it.

Domains where the stakes change the rules

The general advice — supply sources, allow "I do not know", verify — applies everywhere. In a few domains the consequences of a confident fabrication are severe enough that the workflow itself has to change, not just the prompt.

The pattern in all of them is the same: the model is used to draft, organise or find, never to be the authority. Where a wrong answer produces harm that cannot be reversed by an edit, a human with the relevant qualification checks the output against a primary source before it leaves the room.

• Law — invented case citations that look entirely plausible are a well-documented failure with real professional consequences. Every citation gets checked in the actual reporter, without exception.
• Medicine and health — dosages, interactions and contraindications are exactly the kind of specific numeric detail models produce fluently and wrongly. Verify against a clinical reference, and never let a model be the last check.
• Finance and accounting — arithmetic over supplied figures is unreliable enough that the calculation should happen outside the model. Use it to explain and structure, not to compute.
• Academic writing — fabricated references with real-sounding authors, journals and years are common. Check every one against the source database before it appears in a bibliography.
• Code — invented library functions and parameters that do not exist. This one is cheap to catch, because running it tells you immediately, which is why code is the safest domain of the five.
• The rule that covers all of them: if the output would be believed without checking, and being wrong would be costly or hard to undo, it does not ship without a human who could have written it themselves reading it first.

Settings and mechanics that move the needle

Prompt wording gets most of the attention, but a handful of mechanical choices affect fabrication rate independently of anything you write, and they are easy to get wrong without noticing.

Temperature is the obvious one and the most misunderstood. It controls how much the model samples away from its highest-probability continuation. For creative work that variety is the point; for factual extraction it is pure downside, because the alternative continuations are where the invented details live. If your interface exposes temperature and the task is factual, take it near zero.

The others are less obvious and matter just as much in long sessions, where the most common cause of a fabricated answer is not the prompt at all — it is that the relevant information scrolled out of the model's attention several thousand tokens ago.

• Temperature near zero for extraction, classification, summarisation and anything factual. Higher only when you want variety and are prepared to check the result.
• Put the source material near the end of the prompt, closest to the question. Material buried in the middle of a long context is the material most likely to be missed.
• Start a fresh conversation for a new task rather than continuing a long one. Accumulated context from an unrelated discussion is a rich source of details that leak into the answer.
• Re-paste the source when a conversation has run long. It costs tokens and is far cheaper than an answer built on a half-remembered document.
• Be wary of very long documents. Comprehension of any single detail degrades as the surrounding text grows, so ask about one section at a time rather than dropping in two hundred pages and asking a narrow question.
• Ask for quotes rather than paraphrase when accuracy matters. A model asked to quote verbatim either finds the text or fails visibly; a model asked to summarise can smooth a gap without either of you noticing.

What to take from this

Hallucination is a property of how these systems work, not a bug awaiting a patch. That is not a counsel of despair — the rate is very substantially reducible, and the techniques are cheap.

Supply sources instead of relying on recall. Give the model an acceptable way to say it does not know. Ask it to separate what it read from what it inferred. Re-ask anything specific. And check every citation yourself, because a fabricated reference is the single most common and most damaging failure.

Do those things and you move from an assistant you cannot trust to one you can use for real work — provided you keep doing the verification that prompting will never do for you.

Related articles