Hallucination and limits interview questions
11 questions with model answers
- junior 2
- mid 5
- senior 4
11 hallucination and limits questions asked in AI engineer, ML engineer and applied AI engineer interviews, each with a model answer you can say out loud in a minute or two: 2 junior, 5 mid-level and 4 senior. The lesson Hallucination and the Limits of Next-Token Prediction teaches the ideas behind them.Updated
Model answer
It's fluent, confident output that is false or not grounded in any source. The model was trained to predict the token that actually came next in real text, not the true one, and nothing checks truth. So a wrong answer reads as smoothly as a right one.
Model answer
Because likely text isn't true text. In our run, " Sydney" was the top token at 0.216 and " Canberra" only fifth at 0.0436, and greedy stated Sydney with no hedge.
There's no lookup: knowledge is spread through the weights, and a plausible wrong answer, the best-known city, can outweigh the right one. We didn't measure why Sydney wins; one plausible reason is that it appears near "Australia" in far more web text.
Model answer
Every generated token becomes context for the next, and nothing marks it as the model's own guess, so each step is another chance to go wrong. AI Engineering describes snowballing: the model keeps justifying an early wrong assumption.
A right start doesn't protect the rest: GPT-2's greedy Everest answer began correctly, then put the summit at about 1,000 feet. That's one reason concise answers seem to help.
Model answer
Treat probability as a signal to validate, not a verdict. On our 14 prompts, four right answers, including " Tokyo" at 0.1186, were less probable than the wrong " Sydney" at 0.216, and the GPT-4 report found post-training weakened calibration.
So log the probabilities, flag low ones for review, and measure on labelled traffic how many real errors the flag catches and how many good answers it wrongly flags. Recheck after any model or prompt change. For free-form answers, Kadavath et al. ask the model whether its answer is true and use that probability.
Model answer
Ground answers in retrieved policy text. Context steers strongly: in our toy, one true sentence moved " Canberra" from 0.0436 to 0.8248, though that mostly measures copying, and retrieval can find the wrong text.
So: retrieve, require a cited passage for each answer and check it supports the claim, keep answers short and restricted to the given context, and let the bot say it doesn't know. Evaluate local factual consistency: is each answer supported by the documents it was given? That's far easier to check than truth against world knowledge.
Model answer
Make abstaining a valid output. Questions needing fresh or private facts go to retrieval or a tool; if nothing clears a relevance threshold, say so rather than guess. Then check answers: require citations to retrieved passages, and treat disagreement across several samples as an uncertainty signal. Low confidence falls back to a clarifying question or a human. Evaluate on unanswerable questions as well as answerable ones.
Model answer
Quality is task-specific: reference answers where they exist, a rubric judge, human spot checks. Hallucination against supplied context is faithfulness: split the answer into claims and check each is supported by the context.
import re
from dataclasses import dataclass, field
@dataclass
class Result:
score: float
unsupported: list = field(default_factory=list)
def claims(answer):
parts = re.split(r"(?<=[.!?])\s+", answer)
return [p.strip() for p in parts if p.strip()]
def faithfulness(answer, context, supports):
# supports(context, claim) -> bool: an NLI
# model or a judge prompt
cs = claims(answer)
if not cs:
return Result(1.0)
bad = [c for c in cs if not supports(context, c)]
return Result(1 - len(bad) / len(cs), bad)
Interviewers look for claim-level scoring, a pluggable judge validated against human labels, and the empty case handled.
Model answer
Voice adds two problems: errors start at speech recognition, and the user can't see sources. So use the recogniser's confidence, and confirm an uncertain name or number before acting on it.
Then answer from tools and retrieval, like calendar, contacts and search, not model memory, telling the model to answer only from those results. Check the draft against them before speaking, and confirm before any action. Keep replies short, name the source aloud, and say when it doesn't know. Evaluate on recorded, noisy, accented queries, scoring faithfulness and task success.
Model answer
The model doesn't know today's date, so tell it: put the date and the training cutoff in the system prompt.
Then train the behaviour. Fine-tune on questions about things that change, like recent events or latest versions, with answers that give what held at the cutoff and flag it may be stale, or call search. Include stable questions so it doesn't over-refuse. Evaluate on dated questions either side of the cutoff.
Model answer
Not in the control loop. Control runs many times a second and must be verifiable; an LLM's latency varies, and a hallucinated object or rule has no safe failure mode.
Use them off the hot path: auto-labelling and mining rare scenarios from fleet logs, generating simulation scenarios, explaining decisions, and as a slow planner suggesting high-level intent that a fast, verified planner accepts or rejects, as DriveVLM proposes. Anything a VLM contributes online sits behind a deterministic safety layer and is validated in simulation first.
Model answer
Use vetted clinical guidelines and de-identified, consented conversations, split by patient so nothing leaks into the test set. Start with RAG over trusted guidelines for current, cited facts; fine-tune only for tone or format. Clinicians check each claim against sources, and a test set of unsafe-advice cases, like emergencies, must trigger referral.