AI Hallucinations

What a hallucination is

A hallucination is when a language model produces information that is wrong or made up — with full confidence. It will invent a fact, a quote, a number, a link or a name, and phrase it in a completely convincing way. It's dangerous precisely because it sounds credible.

Examples: inventing a law that doesn't exist, citing a study that was never written, giving a wrong product price, or "remembering" a company policy that never existed.

Why it happens

This isn't a "bug" — it's built-in behavior. A language model doesn't retrieve facts from a database; it predicts the statistically likely next word based on the patterns it saw in training. When it has accurate information — it's accurate. When it doesn't — it still produces something that sounds right, because that's what it does. It "prefers" a fluent answer over "I don't know."

So the solution isn't just a "smarter model," but proper engineering: give it a real source, and let it say it doesn't have an answer.

Types of hallucination

• Factual: a wrong fact about the world (a date, a number, a name).
• Faithfulness: contradicting the source provided — e.g. in RAG, the model says something not written in the retrieved passage.
• Fabricated citations: sources, links or studies that don't exist.
• Wrong instructions: "inventing" a step in a process or an API parameter that doesn't exist.

9 proven techniques to reduce them

1. Grounding / RAG. The most effective. Give the model the relevant information via RAG and instruct it to answer only from it.
2. Allow "I don't know." Add to the prompt: "If the answer isn't in the context, say you don't know and offer to hand off to a human." This changes everything.
3. Require citations. Ask that every claim point to a source passage. No source — no claim. It also makes verification easier.
4. Low temperature (0–0.3). For factual tasks. Less "creativity" = fewer fabrications.
5. Structured output + validation. A JSON schema limits the output space, and validation on your side catches invalid values.
6. Self-consistency. For critical tasks — run several times and compare. If the answers contradict, that's a red flag.
7. A verification step. A second model (or code) checks the answer against the source before showing it to the user.
8. Clear, narrow instructions. A vague prompt invites guessing. Define the scope, format and constraints.
9. Hallucination evals. Measure the hallucination rate with evals (e.g. an LLM-judge that checks faithfulness to the source), so you know whether you improved.

Defense layers in a real system

In a critical product you don't rely on a single technique — you build several layers:

1. Prevention: RAG + instructions + low temperature.
2. Control: output validation and verification against the source.
3. Boundaries: Guardrails that block answers on sensitive topics without a source.
4. Measurement: Evals and monitoring in production to catch hallucinations that slip through.
5. Human in the loop: for high-risk decisions — human approval before acting.