Measuring hallucination rate (2026)

TL;DR

Measure hallucination rate as unsupported verifiable claims divided by all verifiable claims under a declared evidence contract. Pair that micro rate with case exposure, severity, abstention, completeness, confidence intervals, and calibrated review.

Key Takeaways

• Use atomic verifiable claims as the denominator and declare the permitted evidence boundary.
• Publish claim-level and case-level hallucination rates because they answer different risk questions.
• Separate contradicted, unsupported, unverifiable, nonfactual, and abstained output with a calibrated rubric.
• Validate LLM judges against hidden human labels and focus on false supported decisions.
• Report counts, confidence intervals, severity, abstention, completeness, and actionable slices.
• Cross retrieval quality with generation grounding before assigning a RAG root cause.

Measuring hallucination rate means counting answer claims that are not supported by the allowed evidence or verified truth, using a repeatable claim-level rubric. A credible rate needs a declared denominator, an evaluation dataset, evidence available at the time of the answer, and a policy for abstentions. Without those choices, a percentage has no stable meaning.

This guide shows QA and SDET teams how to design that measurement from the ground up. It covers claim decomposition, reference construction, deterministic scoring, LLM-assisted judging, confidence intervals, RAG attribution, production sampling, and release thresholds.

TL;DR

Do not label every wrong answer a hallucination. Retrieval failure, stale source data, calculation error, instruction failure, and fabricated evidence have different causes. The overall rate is useful, but the taxonomy tells engineers what to fix.

1. What Measuring Hallucination Rate Really Measures

An LLM hallucination is a generated factual claim presented as supported or true when it is not justified by the evaluation's permitted evidence or reference truth. That operational definition is intentionally narrower than "an answer I dislike." It creates labels that two trained reviewers can apply.

The basic claim-level formula is:

hallucination_rate = unsupported_verifiable_claims / all_verifiable_claims

The denominator excludes purely stylistic statements, greetings, and explicit uncertainty that makes no factual assertion. It includes factual claims even when they sound plausible. If an answer says a policy allows refunds for 45 days, that is one verifiable claim. If it adds that all refunds return to the original payment method, that is another.

Also publish a case-level rate:

case_hallucination_rate = cases_with_at_least_one_unsupported_claim / answered_cases

Claim-level micro averaging describes the share of generated claims that are unsupported. Case-level macro reporting describes the chance a user sees at least one problem. A verbose answer can dominate the micro metric, while a one-error-per-answer system can look mild at claim level and severe at case level. Both views are needed.

For high-risk domains, add severity. A wrong decorative date and an invented medication dose should not trigger the same response even if both count as one unsupported claim. Keep the unweighted rate for transparency, then layer a reviewed severity distribution and critical-claim count on top.

2. Define a Hallucination Taxonomy and Labeling Policy

A good rubric separates observability from root-cause diagnosis. The scorer labels what is in the answer. Engineers later use traces to identify why it happened. Start with mutually understandable claim labels:

For a closed-book benchmark, "not in evidence" may be evaluated against a curated truth source. For a RAG assistant with a strict context-only contract, any factual claim absent from retrieved context is unsupported even if it happens to be true in the outside world. State this boundary in the test because the same sentence can receive different labels under different product contracts.

Add error subtypes after the core label: fabricated entity, fabricated citation, incorrect attribute, wrong number, wrong relationship, temporal mismatch, and overgeneralization. Do not make the initial label set so elaborate that reviewers cannot agree.

Write positive and negative examples for every label. Run a calibration batch with at least two reviewers, discuss disagreements, and revise ambiguous language before labeling the full dataset. Agreement is evidence that the rubric is usable, not proof that the underlying answer is correct.

3. Build an Evaluation Dataset With Checkable Evidence

Measurement quality cannot exceed reference quality. Each case should contain a stable ID, user input, allowed evidence, expected supported facts, expected abstention behavior, risk tag, temporal validity, and dataset version. Preserve source identifiers and exact passages so a later reviewer can reconstruct the decision.

Use a balanced mix of case types:

• answerable questions with one clear fact
• multi-fact questions that require synthesis
• unanswerable questions where abstention is correct
• evidence containing distractors or near matches
• conflicting sources with an explicit precedence rule
• outdated facts that should lose to newer evidence
• adversarial requests to ignore evidence or invent citations
• long-context cases where relevant text is easy to miss

Avoid building only from historical happy-path questions. Production hallucinations often appear at the edges: sparse evidence, ambiguous entity names, stale documents, or requests with false premises. Slice tags let the same overall metric reveal these weaknesses.

Freeze evidence for regression testing. A live web page or mutable knowledge base makes yesterday's label impossible to reproduce. Store an approved snapshot or immutable content hash and its effective date. For current-fact tests, define a controlled refresh workflow and cut a new dataset version.

Keep generated synthetic cases separate from human-authored and production-derived cases. Synthetic data is useful for coverage, but a generator can reproduce its own assumptions or produce unanswerable references. Sample it for human validation. Privacy-review production questions before retention, and replace personal data with stable surrogates without changing the reasoning challenge.

The end-to-end RAG chatbot testing guide shows how to version documents, queries, retrieved chunks, and answers as one test fixture.

4. Decompose Answers Into Atomic Claims

The denominator depends on claim segmentation, so define atomicity. An atomic claim should be independently verifiable and express one subject, relationship, and value or condition. Split conjunctions when either half could be true alone.

Example answer: "Premium customers receive refunds within five days, and shipping fees are always reimbursed."

Two claims result:

1. Premium customers receive refunds within five days.
2. Shipping fees are always reimbursed.

Do not split a necessary qualifier away from its claim. "Refunds are allowed within 30 days for unopened items" is one conditional policy claim, not three isolated fragments. Dates, quantities, units, negation, and modal words such as "may" or "must" are part of meaning.

Claim extraction can be manual, rule-based, model-assisted, or hybrid. For a small release set in a regulated workflow, trained humans may be appropriate. For large suites, use a model to propose claims, then validate extractor quality against a human-labeled sample. Pin the extractor prompt and model because a segmentation change alters both numerator and denominator.

Track extractor failures independently. Missing an unsupported sentence falsely improves the metric. Over-splitting one statement into many near-duplicates can overweight it. Useful extractor checks include claim coverage, duplicate rate, preservation of negation and numbers, and reviewer agreement on a calibration sample.

For concise application outputs with a required citation per sentence, the sentence may serve as the unit. Do not assume sentence equals claim for general prose. A sentence can contain several facts, while a two-sentence explanation may express one inseparable conditional claim.

5. Implement Measuring Hallucination Rate With Deterministic Code

The scorer below consumes a JSONL file of already reviewed claims. It validates labels, calculates micro claim rate, case rate, severity counts, and abstention totals. This layer is deterministic and runnable with the Python standard library. Keeping adjudication separate from aggregation makes calculation bugs easy to test.

Example input line:

{"case_id":"policy-001","answered":true,"claims":[{"text":"Refunds are allowed for 45 days.","label":"contradicted","severity":"high"},{"text":"The request is submitted online.","label":"supported","severity":"low"}],"abstention":"none"}

Save this as score_hallucinations.py:

import json
import sys
from collections import Counter


COUNTED = {"supported", "contradicted", "not_in_evidence"}
UNSUPPORTED = {"contradicted", "not_in_evidence"}
VALID = COUNTED | {"unverifiable", "nonfactual"}


def score(rows: list[dict]) -> dict:
    verifiable = 0
    unsupported = 0
    cases_with_hallucination = 0
    answered_cases = 0
    severity = Counter()
    abstentions = Counter()

    for row in rows:
        case_has_hallucination = False
        abstentions[row.get("abstention", "none")] += 1
        if row.get("answered", False):
            answered_cases += 1

        for claim in row.get("claims", []):
            label = claim["label"]
            if label not in VALID:
                raise ValueError(f"Unknown label {label!r} in {row['case_id']}")
            if label in COUNTED:
                verifiable += 1
            if label in UNSUPPORTED:
                unsupported += 1
                case_has_hallucination = True
                severity[claim.get("severity", "unrated")] += 1

        if row.get("answered", False) and case_has_hallucination:
            cases_with_hallucination += 1

    return {
        "verifiable_claims": verifiable,
        "unsupported_claims": unsupported,
        "claim_hallucination_rate": unsupported / verifiable if verifiable else None,
        "answered_cases": answered_cases,
        "cases_with_hallucination": cases_with_hallucination,
        "case_hallucination_rate": (
            cases_with_hallucination / answered_cases if answered_cases else None
        ),
        "unsupported_by_severity": dict(severity),
        "abstentions": dict(abstentions),
    }


rows = [json.loads(line) for line in sys.stdin if line.strip()]
print(json.dumps(score(rows), indent=2, sort_keys=True))

Run python score_hallucinations.py < reviewed_claims.jsonl. Add unit tests for an empty file, answers with no factual claims, excluded labels, multiple claims in one case, and invalid labels. Decide before implementation whether unanswered cases belong in the case-level denominator. The sample uses answered cases and reports abstentions separately.

6. Use LLM Judges Without Outsourcing the Truth

An LLM judge can scale claim extraction and evidence comparison, but it is another fallible component. Treat it like test code that requires validation, version control, and monitoring. It should receive the atomic claim, exact evidence, task policy, and a narrow label schema. It should not browse outside the evidence unless the evaluation explicitly requires open-world verification.

A current OpenAI Responses API call can request a compact JSON judgment. The example parses the response defensively and validates every field rather than trusting free-form text:

import json
import os
from openai import OpenAI


client = OpenAI()
model = os.environ.get("OPENAI_JUDGE_MODEL", "gpt-5.6-terra")


def judge_claim(claim: str, evidence: str) -> dict:
    response = client.responses.create(
        model=model,
        instructions=(
            "Classify one claim using only the evidence. Return JSON only with "
            "keys label and rationale. label must be supported, contradicted, "
            "or not_in_evidence. Rationale must quote no more than one short passage."
        ),
        input=f"EVIDENCE:\n{evidence}\n\nCLAIM:\n{claim}",
    )
    raw = response.output_text.strip()
    if raw.startswith("```"):
        raise ValueError("Judge returned a Markdown fence instead of JSON")
    result = json.loads(raw)
    allowed = {"supported", "contradicted", "not_in_evidence"}
    if set(result) != {"label", "rationale"} or result["label"] not in allowed:
        raise ValueError(f"Invalid judge result: {result}")
    return result

For production-scale grading, use the provider's documented structured-output facility when your chosen model supports it. The validation principle remains the same: reject unknown labels, missing fields, and evidence-free rationales.

Calibrate the judge on a hidden human-labeled set. Report per-label precision and recall, critical-error recall, and confusion pairs. A judge that calls unsupported claims "supported" is especially dangerous because it lowers the measured rate. Use blinded human adjudication for disagreements and periodically sample agreements too, since two automated components can share a bias.

Avoid using the same model and prompt family as generator and sole judge. Independence is imperfect, but a different judge configuration plus deterministic citation checks and human audits reduces correlated error. Pin judge changes and rescore the baseline before comparing trends.

7. Calculate Confidence Intervals and Slice the Results

A point estimate without sample context creates false precision. Report the numerator, denominator, dataset version, and an interval. For a claim rate, a Wilson interval is often more informative than a normal approximation at small counts or near-zero rates. For complex clustered data, bootstrap by case, not by individual claim, so claims from one answer remain together.

Do not treat all claims as independent. A single prompt failure can make five claims wrong, and verbose cases contribute more claims. That is another reason to publish both micro claim rate and macro case rate. For model comparisons, use matched cases and bootstrap the paired difference.

Slice results by factors that can lead to action:

• answerable versus unanswerable
• retrieval hit versus retrieval miss
• source age and document type
• single-hop versus multi-hop
• prompt language and locale
• entity popularity or rarity
• response length bucket
• model, prompt, index, and application version
• severity and business workflow

Require a minimum denominator before ranking slices. A slice with one unsupported claim out of one claim is a useful incident, not a stable 100 percent estimate. Show counts and suppress trend claims until the sample policy is met.

Watch for metric gaming. A model can reduce claim-level hallucination rate by saying less or abstaining from everything. Pair the rate with answer rate, unnecessary abstention rate, completeness, task success, and user usefulness. The aim is supported assistance, not silence.

For suite economics, connect these results to measuring cost per test with LLMs. A verification pass may lower unsupported claims while raising spend, and the tradeoff should be visible.

8. Diagnose Hallucinations in RAG and Agent Workflows

When a grounded answer contains an unsupported claim, inspect the pipeline in order. First ask whether the necessary document existed in the indexed corpus. Then verify parsing, chunking, metadata filters, query rewriting, retrieval ranking, reranking, context assembly, generation, citation mapping, and post-processing. The final answer alone cannot distinguish these causes.

Use a two-axis attribution table:

Agent systems add tool state. A claim can be unsupported because the tool returned no data, the model misread valid data, a later tool response invalidated an earlier fact, or memory carried stale information. Retain ordered tool inputs and outputs with sensitive fields redacted. Judge the final claim against the authoritative tool state that existed at response time.

Fabricated citations deserve a separate hard gate. Validate that every cited ID exists in the supplied context, every cited span supports the associated claim, and no citation points to a document the user could not access. Citation presence alone is not grounding.

Adversarial cases should include false-premise questions, instructions to "make your best guess," source text containing prompt injection, conflicting tool results, and requests for unavailable private facts. These cases test whether the system maintains the evidence boundary under pressure.

9. Apply Measuring Hallucination Rate in Production

Offline datasets provide repeatability, while production sampling reveals real language and changing traffic. Use both. Sample traces by risk, workflow, novelty, and observed signals rather than only uniform random selection. Always include safety incidents, user corrections, unsupported-citation reports, new document classes, and major prompt or model changes.

Production labels require an evidence snapshot. Retain identifiers for retrieved chunks, tool outputs, model and prompt versions, and the time of answer. If policy allows content retention, store the minimum redacted evidence needed for adjudication. If it does not, run online deterministic checks and short-retention secure review rather than copying data into an analytics lake.

Do not use thumbs-down feedback as the hallucination numerator. Users dislike answers for many reasons and may not notice convincing falsehoods. Feedback is a sampling signal and a product metric, not ground truth. Similarly, self-reported model confidence is not a verifier.

Monitor leading indicators such as missing citations, invalid citation IDs, empty retrieval, unusually high retrieval distance, answer length shifts, and abstention changes. These can alert quickly, but the audited hallucination rate remains a labeled lagging metric. See monitoring LLM apps in production for trace design and alert routing.

Publish the label delay and coverage. A weekly rate based on reviewed high-risk samples should say so. Avoid presenting it as the exact rate for all traffic. Weighting can estimate a population value if sampling probabilities are known, but keep the raw sampled counts accessible.

10. Set Release Gates and Improvement Loops

Set thresholds from risk, baseline capability, and label reliability. A consumer writing assistant and a system that summarizes compliance obligations cannot share one universal acceptable rate. Critical fabricated claims may have a zero-tolerance release gate even when the overall rate allows a small noncritical budget.

A release policy can combine:

1. no critical unsupported claims in the fixed critical suite;
2. claim and case rate must stay within agreed limits;
3. no statistically credible regression against the current baseline;
4. answer rate and completeness must not fall below floors;
5. judge agreement and dataset health must meet minimums;
6. every major slice must have enough coverage or an explicit risk acceptance.

When a gate fails, cluster examples by subtype and pipeline state. Fix the most common controllable cause, then rerun the same dataset and a challenge set designed for that fix. Prompt changes may improve evidence discipline, retrieval changes may improve recall, and response templates may make citations testable. The prompt engineering cheat sheet for QA provides patterns for explicit evidence boundaries and abstention contracts.

Do not tune indefinitely on the release set. Maintain a development set for iteration, a regression set for CI, and a hidden audit set for unbiased checks. Add confirmed production failures as sanitized regression cases, but avoid making every incident one brittle literal assertion. Capture the underlying failure class.

Version every link in the chain: dataset, evidence, claim extractor, judge, rubric, generator, prompt, retriever, and scorer. A trend is trustworthy only when the team can explain what changed.

Interview Questions and Answers

Q: How do you define hallucination rate for an LLM application?

I define an atomic factual claim as hallucinated when it is contradicted by or unsupported by the permitted evidence. The claim-level rate is unsupported verifiable claims divided by all verifiable claims. I also report the share of answered cases containing at least one unsupported claim, severity, and confidence intervals. The evidence boundary and abstention policy are part of the metric definition.

Q: Why not score the whole answer as correct or incorrect?

Whole-answer scoring loses diagnostic detail. One answer may contain four supported facts and one fabricated number, while another may be entirely unsupported. Claim-level labels show density and subtype, and case-level scoring still captures user exposure. I publish both rather than choosing one.

Q: How do you validate an LLM-as-judge?

I compare it with a hidden, human-adjudicated calibration set and measure per-label precision, recall, and confusion. I focus on false supported labels because they hide hallucinations. I version the judge prompt and model, sample agreements as well as disagreements, and rescore baselines after judge changes. High-risk cases retain human review.

Q: How should abstentions be handled?

I exclude genuine abstentions from the factual-claim denominator and report them separately. Each is labeled correct when evidence is insufficient, unnecessary when evidence was sufficient, or failed when the answer still asserts unsupported facts. I pair hallucination rate with answer rate and completeness so the system cannot improve by refusing everything.

Q: How do you distinguish retrieval failure from hallucination?

Hallucination describes unsupported output, while retrieval failure describes missing relevant evidence. I evaluate retrieval independently, then cross it with the generation label. If evidence was retrieved but ignored, the generator is the likely fault. If it was not retrieved and the model guessed, both retrieval and evidence-discipline controls failed.

Q: What denominator would you use?

For the micro metric, I use verifiable atomic claims. For user exposure, I use answered cases with at least one claim. I show counts, excluded unverifiable claims, and the abstention policy. A denominator is never presented without the task contract and dataset version.

Q: How do you set an acceptable hallucination threshold?

I derive it from business risk, current baseline, label quality, and severity. Critical unsupported claims can have a hard zero-tolerance gate in a fixed critical set, while lower-risk claims use a rate and non-regression policy. I also require answer usefulness and adequate slice coverage. There is no responsible universal percentage.

Common Mistakes

• Calling every wrong answer a hallucination. Separate unsupported claims from retrieval misses, stale truth, calculation errors, and instruction failures.
• Using sentences as claims without validation. Sentences can contain multiple facts or incomplete qualifiers. Define atomicity and test extraction.
• Changing the evidence during scoring. Freeze evidence snapshots for regression cases and version current-fact refreshes.
• Treating citations as proof. Validate citation existence, access, and entailment for each associated claim.
• Trusting one LLM judge. Calibrate against human labels, monitor confusion, and audit both agreements and disagreements.
• Ignoring abstention. A system can look safe by refusing all questions. Report correct and unnecessary abstention plus completeness.
• Publishing a percentage without counts. Include numerator, denominator, intervals, dataset, rubric, and coverage.
• Averaging away critical harm. Keep severity and critical-claim gates beside the overall rate.
• Using user feedback as truth. Feedback guides sampling but does not reliably identify convincing falsehoods.

Conclusion

Measuring hallucination rate is a disciplined labeling and sampling practice, not a keyword match or a model confidence score. Define atomic claims, freeze the evidence boundary, separate unsupported claims from other failure modes, validate the judge, and report claim and case rates with uncertainty and severity.

Begin with a small human-calibrated set and the deterministic scorer in this guide. Once the rubric is stable, scale extraction and judging carefully, add RAG attribution, and monitor production samples without losing the evidence needed to reproduce every label.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Measuring answer faithfulness in RAG (2026)
• API rate limiting testing: A Practical Guide (2026)
• Evaluating chatbot answer relevancy (2026)
• Measuring context precision and recall (2026)
• Measuring cost per test with LLMs (2026)
• Measuring LLM latency and cost in tests (2026)