The Hallucination Taxonomy: 7 Types of LLM Lies
LLMs don’t just “make things up.” They make things up in specific, predictable patterns.
Understanding these patterns is the first step to building defenses. Here are the seven types of hallucinations we see in production, ranked by how often they cause real damage.
1. Fabricated Citations
Section titled “1. Fabricated Citations”What it looks like:
“According to Smith v. Jones (2019), the Supreme Court ruled that…” “A 2023 study by Harvard Medical School found that 73% of patients…”
Why it happens: LLMs are trained on text that includes citations. They learn the pattern of citation without learning to verify citations. The model generates something citation-shaped because citations make text look authoritative.
Detection approach:
- Cross-reference all citations against authoritative databases
- Flag any citation that can’t be verified
- Consider removing citation capability entirely for high-stakes use cases
Damage level: 🔴 High — Legal, medical, and academic applications have been embarrassed by fake citations that made it into public documents.
2. Confident Extrapolation
Section titled “2. Confident Extrapolation”What it looks like:
“The API accepts three parameters:
id,name, andtimestamp.”
(The API actually accepts two parameters. The model invented a plausible third.)
Why it happens: LLMs fill gaps with statistically likely completions. If most APIs have timestamps, the model assumes yours does too.
Detection approach:
- Validate all technical claims against source documentation
- Implement structured output with schema validation
- Use retrieval-augmented generation with verified sources
Damage level: 🔴 High — Wrong API documentation leads to wasted developer hours and production bugs.
3. Temporal Confusion
Section titled “3. Temporal Confusion”What it looks like:
“The latest version of React (v17) includes…” “As of 2023, the company is headquartered in…”
(React is now on v18. The company moved in 2024. Training data cutoff strikes again.)
Why it happens: LLMs have knowledge cutoff dates. They don’t know what they don’t know, so they state outdated information with full confidence.
Detection approach:
- Track knowledge cutoff dates for your models
- Flag time-sensitive claims for verification
- Use RAG to inject current information
Damage level: 🟡 Medium — Usually caught before damage, but embarrassing when it isn’t.
4. Entity Confusion
Section titled “4. Entity Confusion”What it looks like:
“Tesla, the company founded by Elon Musk…” “The Washington Nationals won the 2019 World Series under manager Dave Roberts.”
(Tesla wasn’t founded by Musk, he joined later. Dave Roberts manages the Dodgers, not the Nationals.)
Why it happens: LLMs learn associations, not facts. When entities share context (tech billionaires, baseball managers), wires cross.
Detection approach:
- Cross-reference entity facts against knowledge bases
- Use entity linking to verify relationships
- Implement fact-checking pipelines for named entities
Damage level: 🟡 Medium — Factual errors about people and organizations damage credibility.
5. Plausible Inventions
Section titled “5. Plausible Inventions”What it looks like:
“The town of Millbrook, established in 1842, is known for its annual Harvest Festival.”
(Millbrook exists. It wasn’t established in 1842. There’s no annual Harvest Festival. But it all sounds right.)
Why it happens: The model generates coherent narratives that fit patterns. Small towns often have founding dates in that range and festivals like that. The fabrication is invisible because it’s plausible.
Detection approach:
- Verify specific claims, even plausible ones
- Flag content that contains unverifiable specifics
- Consider using retrieval-only for factual queries
Damage level: 🟡 Medium — Hard to catch, often not verified until it’s too late.
6. Capability Overclaiming
Section titled “6. Capability Overclaiming”What it looks like:
“I can analyze this image and tell you…” “Let me search the web for the latest information…”
(The model can’t actually do these things in this context.)
Why it happens: Models trained on diverse data include text where someone could do these things. The model pattern-matches the capability claim without having the capability.
Detection approach:
- Explicitly define and communicate model capabilities
- Filter out capability claims that don’t match reality
- Test for overclaiming in your eval suite
Damage level: 🟢 Low to Medium — Usually caught quickly, but erodes trust.
7. Self-Referential Fabrication
Section titled “7. Self-Referential Fabrication”What it looks like:
“As I mentioned earlier in our conversation…” “Based on the data you uploaded…”
(The model didn’t mention this earlier. No data was uploaded.)
Why it happens: The model hallucinates its own context. It generates patterns that imply shared history or information that doesn’t exist.
Detection approach:
- Track conversation state explicitly
- Validate references to previous context
- Flag claims about user-provided information
Damage level: 🟢 Low — Usually obvious to users, but confusing when it happens.
The Detection Stack
Section titled “The Detection Stack”A production hallucination detection system needs multiple layers:
Layer 1: Structural Validation
Section titled “Layer 1: Structural Validation”- JSON schema validation
- Expected format checking
- Length constraints
Layer 2: Claim Extraction
Section titled “Layer 2: Claim Extraction”- Identify factual claims in output
- Extract entities and relationships
- Parse citations and references
Layer 3: Verification
Section titled “Layer 3: Verification”- Cross-reference against knowledge bases
- Check citations against authoritative sources
- Validate technical claims against documentation
Layer 4: Confidence Scoring
Section titled “Layer 4: Confidence Scoring”- Estimate uncertainty in claims
- Flag low-confidence statements
- Consider hedging language
Layer 5: Human Review (for high-stakes)
Section titled “Layer 5: Human Review (for high-stakes)”- Route uncertain outputs to human reviewers
- Build feedback loops for improvement
- Track false positive/negative rates
The Uncomfortable Truth
Section titled “The Uncomfortable Truth”You cannot fully prevent hallucinations. They’re intrinsic to how LLMs work—they generate plausible continuations, not verified facts.
Your job isn’t to eliminate hallucinations. It’s to:
- Minimize them through prompt engineering and retrieval
- Detect them through eval pipelines
- Mitigate their impact through human-in-the-loop design
Any claim that an LLM “doesn’t hallucinate” is itself a hallucination.
Building Your Defense
Section titled “Building Your Defense”Start with the highest-damage categories for your use case:
| Use Case | Primary Risks | Focus Areas |
|---|---|---|
| Legal research | Fabricated citations | Citation verification |
| Technical docs | Confident extrapolation | Schema validation |
| News/content | Temporal confusion | Freshness checking |
| Customer support | Entity confusion | Knowledge base grounding |
Then build outward. Every hallucination type needs a defense eventually.
Up next: Building Your First Eval — A practical guide from zero to automated quality testing.