AI Hallucination
debt(d8/e7/b7/t7)
Closest to 'silent in production until users hit it' (d9), -1 because with careful testing or domain-expert review some hallucinations can be caught before production, but the detection_hints explicitly state automated detection is 'no' — there is no static analysis tool, linter, or SAST scanner that can flag hallucinated content. Most hallucinations surface only when end-users encounter confidently wrong information in production.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix mentions RAG, citation grounding, and human review layers — none of these are one-line fixes. Implementing RAG requires a retrieval pipeline, vector store, prompt engineering changes, and validation layers across every AI-powered feature. This is a cross-cutting architectural concern that touches data pipelines, prompt construction, output validation, and UI (displaying confidence/sources).
Closest to 'strong gravitational pull' (b7). Once AI-generated content is part of the system, every feature that consumes or displays LLM output must account for potential hallucination — adding grounding, validation, and review workflows. This shapes how every AI-adjacent feature is designed and maintained. It applies across web and CLI contexts per applies_to, and the reliability concern is load-bearing: every new AI feature inherits the obligation to mitigate hallucination.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field is explicit: developers believe hallucination is a bug that future model versions will fix, when it is actually a fundamental property of probabilistic generation. This contradicts the mental model from traditional software where bugs get patched. Developers who treat LLM output like a deterministic API call (the 'obvious' mental model) will be consistently surprised by fabricated facts, fake citations, and invented data — especially since the output is delivered with high confidence.
Also Known As
TL;DR
Explanation
LLMs predict the most probable next token given context — they do not retrieve facts from a database. When the model has insufficient training data for a query, it generates plausible-sounding completions that may be fabricated. Hallucinations are more common with: obscure topics, recent events after the training cutoff, precise numerical data, citations and URLs, and code for niche APIs. Mitigations: RAG (provide source documents), constrained output (JSON schema), chain-of-thought, and output validation.
Diagram
flowchart TD
PROMPT[User prompt] --> LLM[LLM generates response]
LLM -->|confident but wrong| HALL[Hallucination<br/>plausible-sounding falsehood]
subgraph Causes
TRAIN[Not in training data]
AMBIG[Ambiguous prompt]
LIMIT[Knowledge cutoff]
end
HALL --> TRAIN & AMBIG & LIMIT
subgraph Mitigations
RAG[RAG: ground in real documents]
CITE[Require citations]
TEMP[Lower temperature<br/>less creative = more factual]
VERIFY[Human verification<br/>for critical outputs]
end
HALL -.->|reduce with| RAG & CITE & TEMP & VERIFY
style HALL fill:#f85149,color:#fff
style RAG fill:#238636,color:#fff
style VERIFY fill:#238636,color:#fff
Watch Out
Common Misconception
Why It Matters
Common Mistakes
- Treating LLM output as ground truth without validation — always verify factual claims from external sources.
- Using LLMs for real-time data without RAG — the model's training cutoff means recent facts are fabricated.
- No output validation for structured data — a hallucinated JSON field name causes a production crash.
- Prompting for citations without providing source documents — the model fabricates plausible-looking but fake references.
Avoid When
- Trusting LLM output for factual, legal, medical, or financial claims without verification.
- Using a model without retrieval augmentation for domain-specific or time-sensitive facts.
- Presenting LLM output directly to users without human review in high-stakes contexts.
- Relying on a model to accurately cite sources — citation hallucination is common even in capable models.
When To Use
- Always implement retrieval-augmented generation (RAG) when facts matter — ground the model in verified sources.
- Use structured output and validation to catch impossible or malformed responses.
- Add a verification step that checks generated claims against a trusted knowledge base.
- Set system prompts that instruct the model to say 'I don't know' rather than fabricate.
Code Examples
// Trusting LLM output without validation:
$answer = $llm->complete('What is the current PHP 8.4 memory_limit default?');
echo $answer; // May be completely fabricated — training data may be outdated
// Worse: generating code with fabricated function names that don't exist
// RAG with source citation — grounded, verifiable:
$docs = $vectorDb->search('PHP 8.4 memory_limit default', topK: 3);
$context = implode("\n", array_column($docs, 'content'));
$prompt = "Answer using ONLY the provided documentation. If unsure, say so.\n\nDocs:\n$context\n\nQ: {$query}";
$answer = $llm->complete($prompt);
// Also validate structured outputs with JSON Schema