Ask an LLM to cite a court case and it might invent one that never existed — complete with a docket number, judge’s name, and a plausible ruling. Ask it to write a function and it might call an API method that was never part of the library. The output reads perfectly. It’s also completely wrong.

This is AI hallucination, and it’s the single biggest trust problem in production AI systems today.

What Is AI Hallucination?

A hallucination is when an AI model generates output that is confident, fluent, and wrong. It isn’t a random error or a garbled sentence. The model presents fabricated information with the same tone and structure it uses for accurate information, making hallucinations difficult to spot without verification.

The term borrows from psychology — the model “perceives” something that isn’t there. But unlike a human hallucination, there’s no subjective experience. The model is simply predicting the next most likely token in a sequence, and sometimes that prediction drifts away from reality.

Why Hallucinations Happen

LLMs are not knowledge databases. They are statistical pattern matchers trained on massive text corpora. When you ask a question, the model doesn’t look up a fact — it generates the sequence of words that is most probable given its training data and your prompt.

This architecture creates several failure modes:

• Knowledge cutoff gaps. The model has no information after its training date. It fills the gap with plausible-sounding guesses.
• Distributional blending. The model blends patterns from different contexts. A real author gets attributed a book written by someone else because both appeared in similar training contexts.
• Prompt pressure. If you ask the model to answer and it doesn’t know, it will often comply anyway rather than say “I don’t know.” Instruction-tuned models are especially prone to this — they’re trained to be helpful.
• Long-context drift. In extended conversations or documents, the model can lose track of earlier constraints and start generating content that contradicts its own prior output.

The core issue: the model optimizes for plausibility, not truth. Those two things overlap most of the time, but when they diverge, you get hallucinations.

Types of Hallucination

Not all hallucinations look the same. Recognizing the type helps you choose the right mitigation.

Factual hallucination — The model states something false as fact. Invented statistics, wrong dates, non-existent people. This is the most commonly discussed type.

Citation hallucination — The model fabricates sources. It generates a URL that 404s, a paper title that doesn’t exist, or a quote that was never said. Particularly dangerous in research and legal contexts.

Code hallucination — The model calls functions, methods, or APIs that don’t exist in the library it’s targeting. It might use the correct naming conventions and argument patterns, making the hallucinated code look completely valid until you try to run it.

Reasoning hallucination — The model produces a chain of logic where one or more steps are invalid, but the overall structure looks sound. The conclusion feels right because the format is right.

How to Detect Hallucinations

You can’t eliminate hallucinations entirely, but you can build detection layers into your pipeline.

Grounding checks. Compare the model’s claims against a known source of truth — a database, a document set, or a verified API. If the model says “the function accepts three arguments,” check the actual signature. This is the foundation of retrieval-augmented generation.

Self-consistency sampling. Ask the model the same question multiple times (with temperature > 0) and compare answers. If the responses contradict each other, at least one is hallucinated. Consistent answers aren’t guaranteed to be correct, but inconsistency is a strong signal of unreliability.

LLM-as-judge. Use a second model (or the same model with a different prompt) to evaluate whether the first model’s output is supported by the provided context. This pattern scales well and catches a surprising number of unsupported claims. See our LLM-as-judge guide for implementation details.

Retrieval verification. When the model cites a source, programmatically verify that the source exists and that the cited content actually appears in it. This is especially important for any application that surfaces references to users.

7 Techniques to Reduce Hallucination

1. Retrieval-Augmented Generation (RAG)

Instead of relying on the model’s parametric memory, retrieve relevant documents and inject them into the prompt as context. The model generates answers grounded in actual source material rather than its training data. RAG doesn’t eliminate hallucination — the model can still ignore or misinterpret the retrieved context — but it dramatically reduces it for factual queries. Our local RAG pipeline tutorial walks through a full implementation.

2. Lower the Temperature

Temperature controls randomness in token selection. At higher temperatures, the model explores less probable tokens, which increases creativity but also increases hallucination risk. For factual tasks, set temperature to 0 or near 0. Reserve higher temperatures for creative writing where strict accuracy isn’t the goal.

3. Ask for Sources Explicitly

Add instructions like “cite your sources” or “only include information from the provided documents” to your prompt. This doesn’t guarantee accuracy, but it shifts the model’s generation pattern toward attribution, making hallucinations easier to catch. When the model names a source, you can verify it.

4. Chain-of-Thought Prompting

Ask the model to show its reasoning step by step before giving a final answer. Chain-of-thought reduces hallucination because each intermediate step is more constrained than a single large leap. It also makes errors visible — you can see exactly where the reasoning breaks down, which is much harder to do with a direct answer.

5. Constrained Output

Use structured outputs — JSON schemas, enums, or predefined formats — to limit what the model can generate. If the model must pick from a list of valid options rather than generating free text, the space for hallucination shrinks. This is especially effective for classification, entity extraction, and any task with a finite answer set.

6. Self-Verification

Have the model check its own work. After generating an answer, prompt it with: “Review your answer. Is every claim supported by the provided context? Correct any unsupported statements.” This two-pass approach catches a meaningful percentage of hallucinations. It’s not foolproof — the model can confidently verify its own mistakes — but it’s a cheap additional layer.

7. Human-in-the-Loop

For high-stakes outputs (medical, legal, financial), route the model’s response through a human reviewer before it reaches the end user. Design your UI to make this easy: highlight claims, surface confidence signals, and link to source documents. The model drafts; the human verifies. This is the most reliable mitigation and the only one appropriate for domains where errors have serious consequences.

Which Models Hallucinate Less?

Hallucination rates vary significantly across models. In general:

• Larger models hallucinate less than smaller ones on factual recall tasks, though the gap has narrowed as training techniques improve.
• Models with built-in retrieval or tool use (like those that can search the web or query databases) hallucinate less on current-events and factual questions because they’re not relying solely on parametric memory.
• Instruction-tuned and RLHF-aligned models are better at saying “I don’t know,” but they can also be more confidently wrong when they do hallucinate.

Check our model comparison for current benchmarks. The landscape shifts with every release, so test against your specific use case rather than relying on general leaderboards.

The Bottom Line

Hallucination isn’t a bug that will be patched in the next release. It’s a structural property of how language models work — they predict probable text, not verified facts. The practical response is to layer defenses: ground the model with retrieved context, constrain its output format, verify its claims, and keep humans in the loop where it matters.

No single technique solves the problem. Stack them, and you get a system that’s reliable enough to ship.