Measuring It

Lesson 4 of 4 in Hallucination.

“Does it hallucinate?” is unanswerable; “what fraction of claims in our answers are unsupported by our evidence?” is a number you can put on a dashboard. The move that makes hallucination measurable is narrowing truth to support: instead of judging answers against the open-ended world, judge them against evidence you provide. That is a groundedness (or faithfulness) eval, and it is the workhorse metric for any grounded system.

The recipe is an application of everything in the eval-harness module: a Golden set of real questions paired with their retrieved evidence, answers generated by your actual pipeline, and a grader that decomposes each answer into atomic claims and checks each claim against the evidence. The grader is usually an LLM-as-judge with a tight Rubric — supported, contradicted, or not-in-evidence, per claim — validated against a sample of human labels before you trust it, because the judge has an error rate of its own. The output is a supported-claim rate you can track per release, per document collection, per language.

A groundedness eval, end to end

  1. Golden set: real questions + evidence

    Sampled from production traffic, with the passages retrieval actually returned. Synthetic questions test the model; real ones test your system.

  2. Generate answers with the real pipeline

    Same prompts, same retrieval, same model and settings as production — otherwise the number describes a system you don’t run.

  3. Decompose answers into atomic claims

    One checkable assertion per claim. Whole-answer verdicts hide the poisoned detail inside a mostly-correct answer.

  4. Judge each claim against the evidence

    Rubric-driven LLM judge (or NLI-style classifier): supported / contradicted / not in evidence. Citation checks run here too: does the cited passage exist, and does it back the claim?

  5. Judge validated against human labels?

    Grade a sample by hand and measure judge–human agreement first. An unvalidated judge is a rumor generator with an API.

  6. Fix rubric or judge; re-validate

    Tighten rubric wording, add adjudication examples, or change judge model until agreement is acceptable for your stakes.

  7. Supported-claim rate, tracked per change

    The meter: compare across model swaps, prompt edits, retrieval changes. Slice by topic and language — averages hide the corners where rates spike.

Factuality probes attack the other half — claims judged against the world rather than provided evidence. Public benchmarks exist: TruthfulQA (Lin et al. 2021) is the classic, built from questions where common human misconceptions make the plausible answer false — a direct probe of the mimicry mechanism from lesson one. Their limits are structural: a static question set measures a narrow, public slice of “truth,” scores drift into meaninglessness as the sets leak into training data (Contamination — the evaluation domain covers why), and none of it describes your domain. Treat public factuality scores as coarse model-comparison signals, never as your system’s hallucination rate.

Production signals close the loop after launch, and most are qualitative rather than precise: the citation-mismatch rate your verification layer already computes (cited passage missing or non-supporting — a free, continuous hallucination proxy for grounded systems), abstention rates by topic (a falling refusal rate can mean growing knowledge or growing recklessness — only your eval can say which), user corrections and thumbs-down clusters, and escalations from downstream reviewers. None of these is a clean metric; all of them tell you where to sample next for the golden set, which is how the meter stays honest as traffic drifts.

In production

Every major cloud treats hallucination as a product decision you configure, not a property the model guarantees: each platform offers a grounded-generation mode and some machine-readable confidence or groundedness surface. The mechanisms below are evergreen; names and tiers shift, and none of them replaces your own eval — your eval set is the meter.

AWS

Amazon Bedrock’s managed grounding path is Knowledge Bases, which retrieves from your connected data to ground responses with citations back to the source. On the checking side, Bedrock Guardrails documents contextual grounding checks aimed at detecting ungrounded or hallucinated content in RAG responses, applied at inference alongside a model call or independently via the ApplyGuardrail API — a managed version of lesson three’s verification layer, with thresholds you set and, as with any checker, an error rate you should validate on your own traffic.

Azure

Azure AI Foundry’s content filtering system documents an optional groundedness detection filter that checks model responses against provided source material, alongside its harm-category filters — verification as a deployment-attached setting rather than code you write. Grounding itself is the retrieve-then-generate pattern over an Azure AI Search index (the platform’s managed data-grounding offerings have been reshaped over time — check current docs for the supported path). Filter verdicts arrive machine-readably, so a groundedness flag can gate what your app renders.

Google Cloud

Vertex AI documents grounding as a first-class generation option — model responses can be grounded in your own corpora via RAG Engine or in sources like Google Search — with grounded responses carrying supporting references. Its safety surface also documents a citation/recitation filter and machine-readable block and finish reasons, so the platform tells you why an output was suppressed. Confidence surfaces at the token level (logprobs) exist across providers in various forms, but verbalized or derived confidence is not calibrated truth — treat it as a signal to route on, and measure it before trusting it.

Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.