Types of Hallucination: A Taxonomy That Routes to a Fix

If your bug tracker has a label called “hallucination”, it is collecting at least six unrelated defects with six unrelated fixes. The taxonomy below is organised by the only thing that matters operationally: what evidence would let a program detect it.

Why splitting the word matters

The core distinction in the literature is older than chat models. Maynez et al. (2020), working on abstractive summarisation, separated intrinsic from extrinsic hallucination: a claim that contradicts the source versus a claim that is simply not in it. Ji et al.’s Survey of Hallucination in Natural Language Generation (ACM Computing Surveys, 2023) carried that split into the general case and added the second axis everyone now uses — faithfulness to a provided source versus factuality with respect to the world.

Those two axes give you four quadrants, and three more failures that people file under the same word do not fit in any of them. Hence six. The reason to bother: an intrinsic failure is detectable with an entailment model and no internet connection, while a factuality failure in open domain needs a knowledge source you have to go and build. Same label, entirely different engineering budget.

There is a second reason, which shows up the first time someone asks you to reduce “the hallucination rate”. Four of the six categories below respond to changes in retrieval and output schema, one responds only to a change of model or a fine-tune, and one is not about knowledge at all. Averaging them into a single percentage produces a number that cannot go down for any reason you control, which is how a quality programme stalls in its second month.

The two grounded failures

These occur when you supplied a source — retrieved documents, a transcript, a ticket — and asked the model to work from it.

1. Intrinsic: the output contradicts the source

The document says the invoice was raised on the 4th; the summary says the 14th. The document lists three exclusions; the answer lists two and inverts one. This is the cheapest failure to detect, because both halves are in front of you: run a natural-language-inference model over (source sentence, output claim) pairs and flag contradiction. No external knowledge is required.

2. Extrinsic: the output adds claims the source does not support

The addition may even be true — the model is filling from parametric memory — which is what makes this one insidious. It passes a spot check by a reader who knows the domain and fails an audit that asks “where does this come from?”. Detection is the same NLI machinery, but the target label is neutral rather than contradiction, and you have to decide as a product question whether unsupported-but-true is acceptable. In a regulated summary it is not.

The two open-domain failures

3. Fabricated entity: a thing that does not exist

A case citation, a paper, a person, an API method, a CLI flag, a configuration key. The model produces a well-formed instance of a well-learned format, populated with plausible parts. Detection is a lookup: the entity either resolves in an authority — Crossref, arXiv, your own API schema, the package registry — or it does not. This is the one failure mode with a genuinely mechanical detector, which is why citation verification is worth automating before anything else.

4. Attribute error: real entity, wrong facts about it

The library exists; the method signature is wrong. The person exists; the affiliation is from a decade ago. Harder than fabrication, because the lookup succeeds and only the details are wrong, so you need claim-level verification rather than existence-checking. Min et al.’s FActScore (2023) is the standard shape here: decompose a generation into atomic facts and verify each one independently against a source.

The two process failures

5. Unfaithful reasoning: the stated reason is not the cause

Turpin et al. (2023) demonstrated this cleanly. Bias the input — for instance by making the correct answer always appear in the same position in a set of few-shot examples — and models change their answers accordingly while their written chain of thought never mentions the bias and instead constructs a plausible-sounding justification. The prose is a post-hoc rationalisation of an answer arrived at otherwise. This matters enormously if you are using the chain of thought as an audit trail, because it is not one.

6. Instruction drift: a confident answer to a different question

The constraint was “only from the last 12 months” and the answer covers five years; the schema said three fields and four came back. People call this hallucination because the output contains material that should not be there, but the cause is context handling, not knowledge — and it worsens predictably with conversation length, which is the subject of the long-conversation degradation page.

Four things that are not hallucination

Triaging a bad output

A short decision procedure, in the order that costs least to run:

• Did the response terminate normally? Check finish_reason first — a truncation masquerading as a wrong answer wastes hours.
• Was a source provided? If yes, the failure is intrinsic or extrinsic and an entailment check localises it without any external lookup.
• If no source: does every named entity resolve? Run the lookups. If one does not, you have a fabrication and the fix is a verifier, not a prompt.
• If every entity resolves and the claims are still wrong, you have an attribute error, and you need claim-level verification — which in practice means moving the task into a grounded setting.
• If the answer is right but the reasoning is unrelated to it, you have an unfaithful chain of thought, and you should stop showing that chain to users as an explanation.

Categories, not adjectives. A ticket that says “hallucinated” goes nowhere; a ticket that says “extrinsic, retrieval returned the right document, model added an unsupported clause” names its own fix.