Hallucination
A hallucination is fluent, confident output that is wrong or unsupported. It happens because a language model is trained to produce plausible continuations, not to know what it knows; it has no built-in truth check. You reduce it with grounding (RAG), letting the model abstain, low temperature on factual tasks, and verification, and you detect it with faithfulness checks against sources. Applied-AI interviews probe it because hallucination is the number-one reason LLM features fail in production, and because the fix is system design, not a magic prompt.
TL;DR: A hallucination is output that is fluent and confident but factually wrong or unsupported by any source. The root cause is that an LLM is optimized to produce plausible text, not to track truth, and it has no internal "I do not know" signal. You reduce it by grounding answers in retrieved sources, allowing the model to abstain, keeping temperature low on factual tasks, and verifying claims, and you detect it by checking whether each claim is supported by the provided context. It is the top production failure mode, and the fix is system design.
Why models hallucinate
A language model predicts the most plausible next token given the context. It is extraordinarily good at producing text that sounds right, which is exactly the problem: plausibility is not truth. The model has no built-in mechanism to know what it does not know, so when it lacks the fact, it generates a confident, well-formed guess rather than admitting uncertainty. High temperature makes this worse by inviting more invention on factual tasks.
Reducing it: grounding and abstention
There is no prompt that "turns off" hallucination; the fixes are systemic:
- Grounding (RAG). Retrieve relevant sources and instruct the model to answer only from them, with citations so claims are checkable. This is the single biggest lever: the model paraphrases provided facts instead of inventing them (see the RAG pipeline).
- Permission to abstain. Explicitly allow "I do not know / not in the provided context." Models over-answer by default; giving them an out reduces confident fabrication.
- Low temperature on factual/extraction tasks, and verification (run the code, check against a database, use tools) for anything checkable.
- Scope and guardrails. Constrain the task, and validate outputs before they reach the user.
Detecting it
Because prevention is imperfect, you also detect hallucinations at runtime: check whether each claim is supported by the retrieved context (an entailment/NLI or LLM-judge faithfulness check), use self-consistency (disagreement across samples signals unreliability), and surface citations so users (and your evals) can verify. None of these is perfect, so combine them.
The methods sit at different points on the cost/latency/coverage curve, so you stack them rather than pick one:
| Detector | How it works | Cost / latency | Catches |
|---|---|---|---|
| Citation span check | every sentence must quote or point at a retrieved span | near-free, deterministic | unsupported claims, cheaply |
| NLI entailment | small model scores claim vs context as entail/neutral/contradict | tens of ms, one extra call | paraphrased claims that drift from the source |
| LLM-judge faithfulness | a second model rates support per claim | a full extra LLM call, slowest | subtle misuse a span check misses |
| Self-consistency | sample N answers, flag high disagreement | Nx generation cost | model uncertainty even without sources |
Worked example: a RAG support bot. Run the cheap citation check on every response (catches the bluntest fabrications for free), gate the roughly 5% of answers flagged low-support through an NLI entailment model, and reserve the expensive LLM-judge for that flagged slice only. You pay the full judge cost on 5% of traffic instead of 100%, while still covering the dangerous tail. Tune the entailment threshold against a labeled set: pushing recall on caught hallucinations up will block more legitimate answers as false positives, so the threshold is a product decision, not a constant.
Why interviewers probe this
Hallucination is why a slick LLM demo becomes a liability in production (a wrong medical, legal, or financial answer has consequences). A candidate who reaches for "a better prompt" has missed the point; the strong answer is that hallucination is intrinsic to how the model works, so you engineer around it, ground in sources with citations, allow abstention, lower temperature, verify, and detect unsupported claims. That is a systems answer, which is what the role needs.
Common misconceptions
- "A good enough prompt eliminates hallucination." It is intrinsic to next-token prediction; you reduce and detect it with system design, not wording.
- "The model knows when it is unsure." It has no reliable internal truth signal; it produces confident text either way.
- "RAG removes hallucination." It greatly reduces it, but the model can still ignore or misuse the context; you still need citations and checks.
- "Confident equals correct." Fluency and confidence are unrelated to factual accuracy.
Key takeaways
- Hallucination is fluent, confident, unsupported output, caused by optimizing for plausibility without a truth check.
- The biggest reducer is grounding in retrieved sources with citations, plus permission to abstain and low temperature on facts.
- Detect it by checking claims against the context (faithfulness/NLI/judge) and via self-consistency.
- It is the top production failure mode; the fix is system design, not a magic prompt.
Check yourself before an interviewer does. Answer from memory first.
What's the actual root cause of hallucination in an LLM?