A hallucination is a confident, well-formed answer that happens to be false. The model is not lying — it is doing exactly what it was built to do: produce the most plausible-sounding continuation. Plausibility and truth usually overlap, and hallucinations are what happens when they don't.
Why it matters in production
The danger is not that the model is wrong; it is that it is wrong fluently. A hallucination reads exactly like a correct answer, so users trust it and act on it. This is why hallucination is a system-design problem, not a prompt you can write your way out of. You reduce the blast radius by grounding answers in real data and by making unsupported claims detectable.
The common mistake
Believing a bigger or newer model "fixes" hallucination. It reduces the rate; it does not remove the property. Any system that treats hallucination as solved will eventually ship a confident falsehood to a user. The other mistake is not distinguishing a retrieval failure from a generation one — often the model hallucinated because RAG never handed it the fact it needed.
How we actually use it
We contain hallucination rather than pretend it is gone: ground answers in retrieved sources so the model quotes data instead of inventing it, add guardrails that flag or reject unsupported claims, and measure the rate with evals so a regression is visible before users find it. Grounding, checking, and measuring — not a magic prompt — is what keeps hallucination from reaching a customer.