10 Common LLM Hallucination Patterns and How to Catch Them

Fabricated Citations

The model references a study, paper, court case, or report that does not exist. The citation looks real — proper APA formatting, plausible journal name, realistic author names, a DOI-shaped string — but the source is entirely fictional. This is the most common hallucination pattern we see, appearing in roughly 12% of research-oriented outputs.

Why it happens: models learn the form of citations from training data without retaining a reliable index of which papers actually exist. When asked to support a claim, they generate a citation that statistically resembles real ones. RAG pipelines make this worse when retrieval returns thin context — the model fills the evidence gap with invented references rather than saying “unverified.”

What it looks like: “According to Martinez et al. (2023), published in the Journal of Applied Machine Learning, fine-tuning reduces hallucinations by 34%.” Every element is plausible. The journal may not exist. The authors may never have collaborated. The 34% figure may be invented alongside the citation.

How to catch it: Require reviewers to verify at least one citation per output against the original source — not just that the DOI resolves, but that the paper says what the model claims. Automated checks help: validate DOI existence via Crossref, confirm author names match metadata, check that cited URLs return 200 and contain the quoted claim. Human judgment is still essential for paraphrase drift — the source exists but does not support the conclusion.

• Block delivery when any citation fails automated existence checks
• Flag outputs where cited text cannot be found in the retrieved source chunk
• Train reviewers on the “three-click rule”: open source, find claim, confirm wording

Numeric Inaccuracy

The model states that a company had $2.3 billion in revenue when the actual figure was $2.8 billion. Or it claims a study found a 47% improvement when the real number was 42%. The numbers are close enough to feel right but wrong enough to matter in financial reports, medical dosing, engineering tolerances, or competitive analysis.

Why it happens: models compress numerical facts into approximate representations. They reproduce magnitude and units correctly more often than exact values. Rounding, transposition, and confabulation from similar figures in training data all contribute. Multi-step calculations are especially vulnerable — the model may show correct methodology with a wrong intermediate value.

What it looks like: A quarterly earnings summary with three correct figures and one off by 8%. A dosage conversion that uses the right formula but the wrong input weight. A benchmark table where rankings are correct but scores are shuffled.

How to catch it: Flag any output containing specific numbers for automated fact-checking against known databases — SEC filings, FDA labels, internal data warehouses, published datasets. For numbers not in databases, human verification is essential. Require provenance: every material figure should trace to a source field, table cell, or calculation step a reviewer can audit.

• Cross-reference financial figures against authoritative filings, not news summaries
• Re-run calculations independently when outputs include derived numbers
• Treat “close enough” as failure for Tier 1 outputs — near-misses erode trust fastest

Attribute Misassignment

The model correctly identifies a fact but attributes it to the wrong entity. “Google acquired Slack” instead of “Salesforce acquired Slack.” “Dr. Chen led the trial” when Dr. Chen was a co-author, not principal investigator. The fact pattern is real; the attribution is wrong — and wrong attribution is often more damaging than a fully invented fact because it passes plausibility checks.

Why it happens: language models store relational knowledge as soft associations. Entities that co-occur frequently in training text — Slack and Google both appear in business coverage — get incorrectly linked. The model optimizes for a coherent narrative, not a knowledge graph.

What it looks like: Correct product features attributed to the wrong SKU. A regulatory action credited to the wrong agency. A quote assigned to a CEO who never said it, while the underlying sentiment reflects a different executive’s public statement.

How to catch it: Reviewers should spot-check entity-relationship pairs, especially for well-known companies, people, and events. These errors are often fast to catch because the correct information is widely known — but only if the reviewer actually questions the pairing instead of reading for fluency. Automated entity linking against a curated knowledge base catches high-profile errors; niche domain misattributions need domain experts.

• Build a list of high-risk entity pairs in your domain (competitors, subsidiaries, aliases)
• Require subject–verb–object verification for any claim involving acquisition, authorship, or causation
• Use structured extraction with separate fields for entity and action to make mismatches visible

Temporal Confusion

The model states that something happened in 2024 when it actually happened in 2023, or claims an event is upcoming when it already occurred. Dates, sequencing, and timeframes are particularly error-prone because they require precise knowledge the model may have only partially encoded — especially for events near the knowledge cutoff or after a model version ages out.

Why it happens: training data mixes reporting dates with event dates. Models conflate announcement with effect, confuse fiscal year with calendar year, and apply outdated timelines when products ship on new schedules. In long conversations, temporal ordering degrades — the model treats earlier context as current.

What it looks like: “The regulation takes effect next quarter” when it took effect last month. A product roadmap listing features as planned when they already shipped. A legal summary citing repealed law as active because the repeal post-dates training data.

How to catch it: Any output referencing specific dates or timeframes should be verified. Build a list of key dates for your domain — regulatory effective dates, product launches, contract milestones — and cross-reference automatically where possible. For time-sensitive customer communications, compare model output against a maintained “current state” document refreshed weekly.

• Validate tense against a trusted timeline: past events in past tense, future only if scheduled
• Flag outputs that reference “upcoming” events without a source date after today
• After model migrations, re-audit temporal claims — cutoffs shift silently

Plausible but False Technical Claims

The model generates technically sophisticated statements that are subtly wrong. “PostgreSQL uses MVCC with snapshot isolation” is true. “PostgreSQL uses MVCC with serializable isolation by default” is false — it defaults to read committed. These are the hardest hallucinations to catch because they sound expert, use correct terminology, and fail only under scrutiny from someone who actually operates the system.

Why it happens: models learn technical language from documentation, Stack Overflow, and tutorials of varying accuracy. They compose correct-sounding combinations of real concepts that were never true together. Confidence scales with jargon density — the more specialized the vocabulary, the more reviewers without domain depth defer to the model.

What it looks like: Wrong default configuration values. Incorrect API behavior described with accurate parameter names. Valid-sounding security advice that contradicts current best practice. Code that compiles in isolation but violates framework conventions.

How to catch it: Domain experts are essential. Automated checks catch surface-level errors — syntax, type mismatches, known-deprecated API calls — but subtle technical inaccuracies require someone who has run the system in production. Route technical outputs to reviewers with demonstrated domain credentials, not just seniority. Pair expert review with executable validation where possible: run the code, call the API, reproduce the config.

• Maintain a “known good” reference per technical domain your product touches
• Flag outputs that cite version-specific behavior without a version number
• Treat confident technical claims in unfamiliar subdomains as automatic escalation

Invented Statistics

The model generates a specific statistic — “73% of enterprises” or “4.2× improvement” — that sounds authoritative but has no source. Unlike numeric inaccuracy, where a real number is distorted, invented statistics are created from whole cloth. They often appear in thought-leadership tone: rounded percentages, multipliers, and market-size figures that fill gaps where the model lacks data.

Why it happens: training text rewards authoritative assertions. Marketing copy, analyst reports, and blog posts frequently state statistics without rigorous sourcing — models learn that a number makes a claim more persuasive. When no figure exists in context, the model invents one that fits the narrative arc.

What it looks like: “Studies show 68% of teams struggle with AI governance.” No study cited. “Organizations see 3.5× ROI within six months.” No baseline, no cohort, no methodology. Precision implies measurement; measurement was never performed.

How to catch it: Any output containing a specific percentage, multiplier, or market-size figure needs a source. If no source is provided, flag it. If a source is provided, verify it — including whether the source actually contains that statistic or a range the model narrowed into a false point estimate. Reviewers should treat unsourced statistics as blocking errors in Tier 1 content.

• Reject marketing and executive-summary outputs with unattributed quantified claims
• Require confidence intervals or sample descriptions when statistics are material
• Search internal research libraries before accepting external-sounding figures

Overgeneralization

The model takes a specific finding and applies it too broadly. A study about GPT-4’s performance on medical licensing exams becomes “LLMs outperform doctors on medical diagnostics.” A pilot with twelve customers becomes “enterprises universally adopt this approach.” The initial fact is often real; the conclusion is unsupported — and the leap is rhetorically persuasive because it follows a familiar argument shape.

Why it happens: models optimize for coherent narratives. Generalization is a natural compression strategy in human writing too — but in AI outputs, the compression drops qualifiers, sample sizes, and boundary conditions without signaling that anything was lost. The model states conclusions in the same confident register as premises.

What it looks like: Lab results extrapolated to clinical practice without caveats. Single-vendor benchmarks presented as industry truth. Correlation described as causation. Qualitative feedback summarized as unanimous sentiment.

How to catch it: Reviewers should check that conclusions are proportionate to the evidence cited. This requires reading comprehension more than fact-checking — a different skill set. Ask: Does the cited source actually claim this scope? Are qualifiers preserved? Would the original authors agree with this summary? Automated tools struggle here; LLM-as-judge often overgeneralizes in the same way. Human reviewers trained on “scope matching” outperform generic quality rubrics.

• Require explicit sample size, population, and limitation fields in research summaries
• Flag superlatives: “always,” “never,” “all,” “proven,” “universally”
• Compare conclusion sentences against source abstracts line by line for Tier 1 outputs

Confident Hedging

The model says “it is well established that” or “research clearly shows” about claims that are actually contested, preliminary, or unverified. The confidence language masks genuine uncertainty. This pattern is especially dangerous in regulated or medical contexts where epistemic humility is legally and ethically required.

Why it happens: fluent prose defaults to authoritative tone. Training data pairs confident rhetoric with persuasive writing. Models learn that hedging sounds weak — so they upgrade “might” to “does,” “suggests” to “proves,” and “in some cases” to “in all cases” unless prompts explicitly reward calibrated uncertainty.

What it looks like: Preliminary preprints described as settled science. Minority viewpoints presented as consensus. Conditional regulatory guidance stated as mandatory requirement. “Emerging evidence” rewritten as “definitive proof.”

How to catch it: Train reviewers to flag certainty language. Any claim described as “well established,” “proven,” or “without doubt” should be verifiable through multiple independent sources. Build a lexicon of confidence phrases and route outputs that exceed the evidence tier. Pair with uncertainty acknowledgment prompts upstream to reduce incidence — but never trust prompt engineering alone.

• Map certainty phrases to required evidence levels: one source vs. meta-analysis vs. regulatory text
• Downgrade or block outputs where certainty exceeds source confidence
• Track confident hedging rate by model version — it spikes after upgrades optimized for fluency

Outline Hallucination

The model generates a structure — table of contents, numbered list, section headers, promise of appendices — that implies comprehensive coverage the body does not deliver. The outline looks thorough; the actual content is thin, repetitive, or missing entire sections. Users skim headers, assume completeness, and make decisions on absent material.

Why it happens: models front-load planning tokens because outlines are easy to generate from task templates. Content generation is harder and hits length limits. When constrained, the model preserves the ambitious structure and compresses sections — or silently skips them. In agentic workflows, a planner agent may promise work an executor agent never performs.

What it looks like: A ten-section report where sections 4–7 are two sentences each. A FAQ that lists questions but answers only half. A “detailed analysis” with headers and no supporting data under each. A multi-step tutorial that jumps from step 2 to step 5.

How to catch it: Compare the outline to the content. Does each section deliver on its promise? This is a quick human check — reviewers can scan headers in under a minute — but automated tools struggle without semantic understanding of “adequate depth.” Checklist validation works: for each header, confirm minimum word count, required data elements, and presence of cited sources.

• Reject outputs where any H2 section is shorter than a defined threshold for the task type
• Require section-level completion markers in structured outputs
• For agentic pipelines, validate executor output against planner commitments before merge

Context Window Overflow

When inputs are long, models quietly drop details from earlier in the context. A summary of a 50-page contract omits indemnification clauses on page 31. A meeting transcript analysis ignores objections raised in the first ten minutes. The output reads fluently and confidently but is materially incomplete — the most insidious failure mode because absence is harder to spot than presence of wrong text.

Why it happens: attention budgets degrade over long contexts. Middle sections suffer “lost in the middle” effects. Summarization prompts encourage compression that treats all omissions equally — the model does not know which dropped detail was load-bearing. Multi-document inputs compound the problem: the model merges themes and drops outliers that matter.

What it looks like: Legal summaries missing minority clauses. Medical chart reviews omitting allergy notes buried mid-record. Due-diligence reports that cover financials but skip litigation sections. Code reviews that analyze changed files but miss imports added in an earlier commit message.

How to catch it: For long inputs, require reviewers to verify that all key points are represented in the output. Checklists work well — list expected topics, entities, and risk flags from the source, then confirm each appears in the output. Chunk-and-merge pipelines should include overlap verification: summarize sections independently, then audit the synthesis against a master checklist. Never trust single-pass summarization for Tier 1 long documents without coverage validation.

• Build domain-specific coverage checklists (e.g., every material contract clause type)
• Compare entity extraction from full input vs. summary — missing entities signal drops
• Log input token count; error rates correlate with length past model-specific inflection points

Building detection into your workflow

You do not need to catch all ten patterns on every output. That approach paralyzes throughput. Instead, build a risk-tiered detection program that maps patterns to task types and automates what is cheap while reserving human attention for what is hard.

1. Categorize your outputs — which patterns are most likely for each use case? Research summaries skew toward fabricated citations and invented statistics. Support macros skew toward temporal confusion and attribute misassignment. Code assistants skew toward plausible-but-false technical claims.
2. Train reviewers on your top 3 — specialization beats generalization for review quality. A reviewer who knows citation fraud cold will catch it in thirty seconds; a generalist may admire the formatting.
3. Automate what you can — citation existence checks, numeric cross-referencing, date validation, schema enforcement, and entity linking catch a meaningful fraction before human review. Our analysis of 10,000 reviewed tasks found automation catches the obvious failures; humans catch the subtle ones.
4. Track patterns over time — tag every rejection with a pattern ID. If fabricated citations spike after a model update, you want to know within hours, not after a customer complaint. Pattern dashboards turn hallucinations from mysteries into metrics.

Publish a pattern checklist inside your reviewer UI — not a separate training doc. Reviewers should see the ten patterns, example snippets, and pass/fail criteria inline with each task. Calibration sessions using real outputs, as described in our verification guide, align reviewers on borderline cases and cut inter-rater disputes.

Hallucination patterns are not model quirks — they are product risks with names. Teams that classify errors by pattern ship faster over the long run because they stop debating whether AI is “good enough” and start measuring whether each pattern is trending down. Detection is how you turn probabilistic generation into something you can stand behind.

Your pattern detection checklist

Before closing any review sprint, confirm your pipeline addresses these essentials:

• Every rejection is tagged with at least one pattern from this taxonomy
• Tier 1 outputs have explicit checks for citations, material numbers, and temporal claims
• Domain experts review technical claims — not just senior generalists
• Long-input tasks use coverage checklists, not single-pass summarization trust
• Pattern frequency is reported weekly; spikes trigger model or prompt investigation
• Reviewers completed calibration on your top 3 patterns in the last quarter

Understanding hallucination patterns turns vague anxiety about AI quality into a concrete, actionable review process. The model will keep generating errors — your job is to make sure the same error never reaches a customer twice without teaching the system something.