Lesson 7 of 30
An LLM doesn't have a fact database it checks against — it generates the statistically plausible next token. Hallucination isn't a bug in that process, it's what that process looks like when there's no grounding to lean on.
11 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 3
Why is hallucination described as an inherent property of how LLMs work, rather than a bug that a future model version will simply fix?
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
A language model generates text one token at a time by predicting what's statistically likely to come next, given everything before it. It has no separate "is this true" step — there's no internal fact-checker running alongside generation, and no built-in mechanism for the model to know what it doesn't know. When you ask it something it has strong, well-represented patterns for, the plausible continuation and the correct answer usually line up. When you ask it something obscure, ask it to cite a specific detail it never actually saw, or push it past what it's confident about, it keeps generating the next plausible token anyway — confidently, fluently, and sometimes completely wrong. That's a hallucination: fluent, plausible-sounding output that isn't grounded in anything true.
This is why hallucination isn't a "bug to be patched away" in some future model version — it's an inherent property of how generation works. A model with no fact-checking mechanism can't be patched into having one just by making it bigger or newer; it can get better at recognizing when it's on shaky ground (so it hedges or declines more often), but "never generates a plausible-sounding falsehood" isn't a property this kind of system can guarantee. Treat it as a property to design around, not a defect to wait out.
// lib/ai/prompts/tutor.ts — the system prompt constrains the model to
// only the lesson content it was actually given, not its general training.
const systemPrompt = `
Answer the learner's question using ONLY the lesson context provided
below. If the answer isn't in this context, say so explicitly instead
of guessing.
Lesson context:
${lessonContext}
`;
This is grounding in practice: instead of letting the tutor answer from whatever it generally "knows" about a topic (and risk generating a fluent-sounding but wrong explanation), the prompt hands it the actual lesson content and instructs it to answer only from that — and to say "not in this context" rather than fill the gap with a plausible guess. This is the same idea lib/ai/chat/handler.ts and the interview grader lean on: giving the model real, provided material to answer from (this is the core idea behind RAG — retrieval-augmented generation — covered later in this track) is worth far more than asking it to just try harder to be accurate.
Beyond grounding, three more mitigations actually move the needle:
"How would you reduce hallucinations in an AI feature?" is a common question, and the strong answer names concrete mechanisms — grounding, citation, temperature, verification steps — instead of the vague, non-answer of "use a better model."