An LLM "hallucinates" when it generates plausible-sounding content that is false. This happens for structural reasons — the model is optimised for likelihood, not truth — and no prompt or technique eliminates it completely. What you can do is drive the rate from uncomfortable (often 5–15% on factual tasks) to tolerable (< 1%), while exposing residual errors to your users and systems.
Ranked roughly by effort-to-payoff.
For any task where the answer exists in some corpus — documentation, customer records, policies — retrieval-augmented generation cuts hallucination rate by 50–90%. The model cites from the retrieved context instead of confabulating.
Three requirements for RAG to actually reduce hallucination (not just add noise):
[Source: doc-423] per chunk. The model cites using these labels, and you can verify post-hoc that cited sources actually support the claim.This is RagImplementationPatterns territory in depth.
If the output is a JSON schema, a specific DSL, or a closed set of choices, constrain generation to the valid grammar. Tools: outlines, lm-format-enforcer, OpenAI's response_format, Anthropic's tool use, grammar-constrained generation in llama.cpp.
Benefits:
Do this wherever the output is machine-consumed. You save retry logic, you eliminate a whole class of parsing errors, and you force the model to commit to one of the valid answers rather than invent a new one.
Teach the model to say "I don't know" as a first-class output. Three moves:
"insufficient_information" as a valid enum value.Without the eval, the model learns to always answer because that's what the training distribution rewards. Adding unanswerable cases trains the calibration that matters.
Measure calibration: if the model says "I don't know" 5% of the time, of the remaining 95% confident answers, how often is it right? You want both numbers to shift — more abstention, higher confidence-conditional accuracy.
Have the model check its own output against the sources:
Draft answer: {answer}
Sources: {sources}
For each claim in the draft, identify which source supports it.
If any claim is not supported, flag it.
Then either:
Caveat: self-verification has its own hallucination rate. Works better when the verification uses a separate model call (so it's not just continuing its own generation) and when sources are short enough to fully include.
Post-hoc verification of the citations the model produced:
[source: doc-12], fetches that source, and checks that the claim is supported.This is where you catch fabricated citations — the classic "the model cited a paper that doesn't exist" case. For a production system answering user queries, citation verification is a must-have, not a nice-to-have.
Ask the model for confidence and use it:
Use uncertainty to route: high confidence → deliver; low confidence → escalate to human, ask a clarifying question, or abstain.
Fine-tuning on domain data can reduce hallucination by teaching the model the domain's vocabulary, common structures, and admission patterns. But it also teaches the model new "facts" that become memorised-and-potentially-wrong, especially as the real-world facts drift.
Guidance:
See LLMFineTuning for the recipe.
You need a task-specific factuality eval. Generic benchmarks (TruthfulQA, HaluEval) measure the average; your traffic isn't the average.
Build 100–500 questions where you know the right answer (from docs, database, or labelled corpus). For each model output:
RAGAS, TruLens, or a homegrown LLM-judge over these three axes works. Run weekly at minimum. See LlmEvaluationMetrics for the metric catalogue.
Even with everything above, residual hallucination rate won't hit zero. At some point the engineering reaches diminishing returns and the question becomes: how does the product handle wrong outputs?