“There are three kinds of lies: Lies, Damned Lies, and Statistics”
— has been attributed to Mark Twain, who himself attributed it to British Prime Minister Benjamin Disraeli, who might never have said it in the first place.
LLMs hallucinate because they are probabilistic next-token predictors, not databases. They don’t “look up” facts; they calculate the most likely sequence of characters based on patterns learned during training.
Here are the practical reasons why this fails:
1. Lack of Grounding
An LLM has no internal model of “truth” or “reality.” It only knows the statistical relationship between words. If the most probable next word in a sentence is factually wrong but grammatically and structurally plausible, the model will choose it.
2. Lossy Compression
Training a model is a form of massive data compression. The model cannot store every sentence of the internet verbatim; it stores the weights (patterns) of that data. When it tries to reconstruct a specific detail (like a middle name or a date) that wasn’t a strong enough pattern to be preserved perfectly, it “fills in the gap” with something that looks correct.
3. Training Data Noise
If the training data contains contradictions, errors, or biases, the model learns those as valid patterns. If it sees three versions of a fact and two are wrong, it may prioritize the wrong ones.
4. The “Pressure” to Respond
LLMs are optimized to be helpful and follow instructions. When asked a question, the model’s objective is to produce a response that satisfies the prompt. It is often more “likely” (statistically) to generate a plausible-sounding lie than to admit it doesn’t know the answer, unless it has been specifically fine-tuned (RLHF) to be cautious.
Summary for the pragmatist:
A hallucination is just the model doing exactly what it was built to do—predicting a plausible sequence of tokens—but doing so in a context where “plausibility” and “truth” do not overlap.
Mitigating LLM hallucinations
Mitigating hallucinations requires moving the model from “guessing” to “referencing.” You cannot eliminate hallucinations entirely because they are a feature of how LLMs work, but you can reduce them to a negligible level using these pragmatic strategies:
1. Grounding via RAG (Retrieval-Augmented Generation)
The most effective way to stop hallucinations is to provide the facts in the prompt. Instead of asking the model to remember a fact, you:
- Search a trusted database or document for the relevant text.
- Feed that text into the prompt.
- Command the model: “Use ONLY the provided context to answer. If the answer isn’t there, state that you do not know.”
- Tradeoff: Increases latency and token cost, but drastically increases accuracy.
2. Prompt Constraints & Guardrails
Force the model to be cautious through system instructions:
- Explicit “I don’t know” permission: Tell the model: “It is better to admit ignorance than to guess.”
- Chain-of-Thought (CoT): Ask the model to “think step-by-step” or “extract the facts first, then synthesize the answer.” Forcing the model to layout its reasoning often exposes its own contradictions before it reaches the final answer.
- Few-Shot Prompting: Provide 3–5 examples of a correct answer and, crucially, an example of a prompt where the model should respond with “Information not found.”
3. Deterministic Sampling (Temperature)
Adjust the “creativity” slider:
- Lower Temperature (e.g., 0.0 to 0.2): Makes the model more deterministic and likely to pick the highest-probability token. This is mandatory for factual, technical, or medical tasks.
- Higher Temperature: Useful for brainstorming, but a recipe for hallucinations in factual work.
4. External Verification Loops
Don’t trust the first output. Use a “Verify” or “Critique” step:
- Self-Correction: Pass the output back to the model: “Review your previous answer for factual errors. List any inconsistencies found.”
- Cross-Examination: Use two different models. Model A generates the answer; Model B (or a different version) attempts to find errors in it.
- Tool Use: Give the model access to a calculator, a Python interpreter, or a web search tool to verify numbers and dates in real-time.
Summary of Tradeoffs
| Method | Effort | Impact | Primary Tradeoff |
|---|---|---|---|
| Low Temp | Low | Low/Mid | Loses nuance and “fluidity” |
| Prompting | Low | Mid | Takes trial-and-error to optimize |
| RAG | Mid/High | High | Infrastructure complexity & cost |
| Verification | Mid | High | Doubles/Triples latency and cost |
