A Taxonomy of Hallucinations: Intrinsic, Extrinsic, and the Systemic Kind

You cannot mitigate a failure mode you cannot name. That sentence sounds obvious until you sit through a post-incident review for a hallucinated answer, and watch four engineers describe the same defect in four mutually incompatible ways. One calls it a “factual error”, another calls it a “retrieval miss”, a third calls it a “prompt issue”, and the fourth, the one with the actual fix in mind, gives up halfway through and goes to write code. The conversation could not converge because the vocabulary did not exist.

The field had to agree on a taxonomy before the mitigation discussion could be serious. The canonical reference is still Ji et al.’s 2022 “Survey of Hallucination in Natural Language Generation”, which split the failure mode into two classes: intrinsic (the output contradicts the input it was given) and extrinsic (the output adds claims the input does not support). Those two labels carried the literature for the next two years. The practitioner literature has been adding a third label, systemic, for the failures that look like model hallucinations but actually originate in the pipeline around the model. Two of those labels are canonical Ji. The third is a working term, and I am going to flag it as such.

What Ji et al. actually said

Ji et al. were writing about natural-language generation broadly: summarisation, dialogue, translation, data-to-text. The two-class split came from looking at where the wrongness lived relative to the source the model was conditioned on.

An intrinsic hallucination is an output that contradicts the source. A summariser is given a contract that expires in 2025 and produces a summary saying it expires in 2027. A translator flips a negation. A data-to-text system is given a table where the company’s revenue grew 12% and writes a paragraph saying it shrank. The ground truth lives inside the prompt, and the output disagrees with it. This is the cleaner of the two failure modes to detect, because the truth source is right there, and you can compare token by token if you have to. Most “faithfulness” metrics in the literature were designed to catch intrinsic hallucinations.

An extrinsic hallucination is an output that adds claims the source does not support. The model is given a press release about a company appointing a new CFO and the generated bio adds a board seat that exists nowhere in the source documents. A medical summary adds a side effect not mentioned in the input. A legal brief invents a case citation (the now-famous 2023 incident that put the word “hallucination” on a courtroom docket). The model is not contradicting the source; it is extrapolating past it with full grammatical confidence. Extrinsic hallucinations are harder to detect in the moment because they read as coherent additions, and confirming them requires an external truth source, not just an internal consistency pass. “Factuality” metrics, which compare claims against a world model rather than a source document, were designed to catch extrinsic hallucinations.

The two-class split is load-bearing. It tells you immediately where to look for the fix. Intrinsic hallucinations point you at the model’s faithfulness to its input (decoding strategy, context length, attention behaviour). Extrinsic hallucinations point you at grounding (retrieval quality, external knowledge integration, claim verification).

Why the practitioner literature added a third class

If you have ever debugged a “hallucination” in a production RAG system, you have probably noticed that a lot of them are not really model failures at all. The retrieval layer surfaces an outdated document, and the model dutifully answers from what it was handed. The context window fills up and the eviction policy drops the document the answer depended on, but the model keeps answering as if the document were still there. The system prompt is ambiguous about whether to refuse low-confidence claims, and the model interpolates. The post-processing layer fails to gate an unverifiable output and a wrong answer reaches the user.

In every one of those cases, the model behaved exactly as a probabilistic generator should. It produced the most likely continuation given the context it was actually given. The wrongness was real, the user saw a hallucinated answer, but the originator of the error was somewhere else in the pipeline. Ji et al.’s two-class split, which assumes the model is the thing under analysis, does not have a slot for that.

The practitioner literature has been filling the slot with the working term systemic hallucination. Huang et al.’s 2023 “Survey on Hallucination in Large Language Models” moves in this direction, broadening the framing to include retrieval, context, and pipeline factors that Ji et al. treated as upstream concerns. Several engineering blogs and vendor whitepapers now use the term explicitly. I want to be honest about the status: intrinsic and extrinsic are canonical Ji labels with two and a half years of citation behind them; systemic is a practitioner-mint label that the academic literature has not yet locked down. The parent guide on hallucination taxonomies and mitigations flags this same boundary.

The reason the term earns its place anyway is operational. In production, the majority of what users report as “hallucinations” turns out, on root-cause analysis, to be systemic. The model gets blamed; the harness was the failure. Without a name for that class, teams keep reaching for model-side fixes (fine-tuning, prompt-tweaking) for pipeline-side problems, and the bug returns under a different disguise three weeks later.

The three classes, by origin

The diagram is the whole point of the taxonomy in one image. Intrinsic and extrinsic both originate inside the model, given the input it was handed. The difference between them is whether the wrong output contradicts the input (intrinsic) or extrapolates past it (extrinsic). Systemic originates outside the model, in the harness that decides what input the model gets, what constraints it operates under, and what happens to the output afterwards.

Reading a failure through the diagram is the first useful question after any production incident. Did the model contradict the source it was given (intrinsic, look at the decoding and the prompt). Did the model invent a claim the source did not contain (extrinsic, look at grounding and external verification). Did the model behave correctly on bad inputs (systemic, look at retrieval, context management, prompt construction, post-processing). The mitigation lives where the originator lives. Confusing the three is how teams spend six months tuning a model for a problem the retrieval layer was causing.

Where this leaves you

The three-class taxonomy is the entry door. It does not tell you how to fix anything yet, but it tells you which door to walk through. Intrinsic and extrinsic point you at the model and its grounding; systemic points you at the system. Most production incidents I have helped diagnose since the practitioner literature converged on the third class have turned out to be systemic, and naming that out loud is what stops the same defect from coming back wearing different clothes.

The next two pieces under this section go a level deeper. The first walks the response-layer mitigation stack (the prevent-vs-catch axis that determines whether you stop a hallucination at generation time or after). The second names the design question that sits on top of all this: when hallucination is acceptable and when it is not, per workload.

Resources

• Parent: Hallucination Taxonomies and Mitigations
• Reducing hallucinations: the response layer as a stack
• When hallucination is a design constraint, not a bug
• Wikidata and knowledge-graph grounding for output checks
• LLM-as-judge: where it works, where the verdict fails
• Primary source: Ji et al., “Survey of Hallucination in Natural Language Generation” (2022)
• Companion survey: Huang et al., “A Survey on Hallucination in Large Language Models” (2023)