Hallucination and the first mitigations

Why it matters

A model will invent a clause number in a contract summary, a function that does not exist in an API, a statistic with two decimal places, and a citation with a real-sounding author and a fake title. Each is written with the same fluency as a correct answer. Users cannot tell them apart, and neither can an engineer's quick glance. Hallucination is why an LLM system needs grounding, evaluation and a human somewhere in the loop, and it is the first failure an interviewer will ask you to defend against.

The idea

What it is

Hallucination is output that is fluent, confident and unsupported: not backed by the input, by the training data or by any source. It is not a defect of one model; it follows from how every model is trained.

Why it happens

The objective is next-token prediction. The model is rewarded for the most plausible continuation, and plausibility is measured against text, not against the world: there is no truth signal in the loss. When the model reaches a gap, a fact it was never trained on, a document it cannot see, a number it would need to compute, the most plausible continuation is still a fluent one, so it fills the gap with plausible text. Fine-tuning for helpfulness adds pressure to answer: a model trained on conversations where the assistant always answers learns that silence is wrong.

The categories

Fabricated facts: dates, events, properties of things that are nearly real. Fabricated citations: papers, URLs, case law and section numbers shaped like real ones. Fabricated APIs: functions, parameters and flags that would make sense and do not exist. Fabricated numbers: statistics and totals, often with precise decimals. False confidence: an assured tone on an answer the model would, if asked, rate as uncertain.

The first mitigations

Grounding with retrieval. Put the facts the answer should rest on into the context, and instruct the model to answer from them. The gap is closed by supplying the material rather than asking the model to remember it. It is the single most effective fix; the Retrieval module covers the system.

Citations tied to provided sources. Ask for every claim to point at a passage in the supplied context by identifier, then verify in code that the identifier exists and that the passage supports the claim. A citation to something not in the context is itself a detectable hallucination.

Permission to not know. Give an explicit path: if the sources do not contain the answer, say so. Without it, the pressure to answer wins. With it, abstention becomes a measurable output rather than a failure.

Structured output with enums. Where answers come from a fixed set, make the schema say so. A model cannot invent a seventh queue if the field is an enum of six, and a required source_ids array or a confidence field turns tone into data a program can act on.

Verification by a second call or a tool. A separate call checks each claim in the first answer against the sources; a tool recomputes any number; a compiler or test confirms an API exists.

Evals that measure faithfulness. Faithfulness is the fraction of claims in an answer supported by the context; track it per release. Without the measure, every mitigation above is a hope.

Temperature zero is not a fix. It makes the output deterministic, not true. The most likely continuation of a gap is still a fabrication, now reproduced on every run.

	Retrieval grounding	Citations + abstain	Verifier call or tool	Faithfulness evals
What it catches	Gaps the model would otherwise fill from memory	Claims with no passage behind them; questions the sources cannot answer	Invented numbers, APIs and claims that slipped past grounding	Regressions across releases, prompts and models
Cost	A retrieval system plus more input tokens	A few hundred output tokens and a validation step in code	A second model call or tool run per answer	A labelled set and a judge; offline, per release
Where it fails	Wrong passage retrieved: a grounded, cited, wrong answer	Abstains too often; cites a real passage that does not support the claim	The judge hallucinates too, less often but not never	Measures the set you wrote, not the questions users ask next week

Trade-offs

Grounding only helps if retrieval returns the right passages; a wrong passage produces a grounded, cited, wrong answer, and the citation makes it look safer. Abstention trades recall for precision: a model that says it does not know often enough looks unhelpful, and the threshold is a product decision. Verification doubles cost and latency and relies on a judge that hallucinates too. Enums fix what can be enumerated and nothing else. After all of it, a residue remains: fluent output that passes retrieval, citation and verification and is still wrong, because the source was wrong, the question was ill-posed, or the claim is not the kind a passage can support. Design for the residue with human review where the cost of an error is high.

In an interview

Say: "Hallucination is unsupported output from a model with no truth signal, so I ground factual answers in retrieved sources, require citations I can check in code, allow abstention, and measure faithfulness on every release." At junior depth, define it, name the categories and state that temperature does not fix it. At mid depth, explain the mechanism and the mitigation stack with its costs. At senior depth, discuss the residue, how a verifier can be wrong, and where human review sits in the product. Expect: "If the model cites a source, is the answer correct?" No: check that the passage supports the claim.