Hallucinations in LLMs: how do you measure it

The tricky thing about a hallucination is that it rarely looks uncertain. The model doesn't hesitate, it just answers wrong. How do you make that testable?

A language model that makes something up (a non-existent report, a wrong year, a quote that was never said) presents it with exactly the same confidence as a correct answer. There's no error message, no low-confidence warning. Just a confidently wrong answer.

For an experiment, that might still be acceptable. Once an LLM answers customer questions, advises staff, or supports decisions, every unmanaged hallucination becomes a quality and trust risk.

Two types of hallucination

Intrinsic hallucination is the easiest to spot: the model claims something that directly contradicts the source text it was given.

Extrinsic hallucinations are trickier. The model adds information that doesn't come from the source. That information might happen to be correct, but it isn't grounded in the context the answer is supposed to rely on. In domains where correctness matters, both forms are a problem.

How you make it measurable

With RAG systems (retrieval-augmented generation), there's an extra layer on top: a hallucination can arise because the model reasons incorrectly, but just as easily because the retrieved source documents themselves weren't relevant or weren't correct. Testing only the output and not the retrieval step misses half the problem.

What you build in practice

• A test set with known, verified answers that you check every model version against before release.
• A groundedness metric that scores per answer, not just a single global average, so you know in which scenarios it goes wrong.
• Continuous monitoring in production, with sample-based human review of new or unusual questions.
• An escalation path for when the model should be uncertain but doesn't show it, for example by making source references mandatory.

Eliminating hallucination entirely isn't realistic with the current generation of models. Making it measurable and manageable is, and that's exactly the difference between a demo and a production system.

An example from practice

For a customer-support bot that answers based on internal product documentation (a RAG setup), we tested a hundred questions against a fixed knowledge base. The share of answers that were correctly grounded started at 82%.

Most of the hallucinations didn't come from the model itself but from the retrieval step: the search function pulled the wrong product sheet, after which the model dutifully, and incorrectly, built an answer on that wrong source. A test that only judged the output would have missed the cause.

What we measure in this kind of project

• Retrieval precision, separate from answer quality. Does the system pull the right source document, independent of what it does with that information afterward?
• A fixed test set with known answers, re-run on every change to the model, the prompt, or the knowledge base.
• Mandatory source citation in every answer, so a reviewer (and the user) can check exactly what a claim rests on.
• An explicit "I don't know" threshold, so the model defers rather than guesses when grounding is insufficient.