What metrics are used to evaluate LLM hallucinations?

What gets measured when teams assess hallucinations?

Hallucination metrics usually split into a few families. Factual accuracy checks whether outputs match verifiable ground truth. Faithfulness measures whether the model stayed aligned to the provided source material. Citation correctness checks whether references are real, relevant, and support the claim they are attached to. Human review rates are often used for unsupported or fabricated claims when automated scoring is not enough.

These metrics are not interchangeable. A model can sound fluent yet still invent facts, misread a source, or attach a real citation to an unsupported claim. The practical question is not just whether the answer looks plausible, but whether it can be defended against the task definition, the evidence available to the model, and the level of risk in the use case.

For teams building evaluation sets, the key choice is what counts as a hallucination in context. In some workflows, any unsupported statement is a failure. In others, a small amount of speculative wording may be acceptable if the system clearly labels uncertainty and the downstream reviewer can catch it. That definition should be fixed before measurement starts, otherwise different reviewers will score the same output very differently.

Which metrics are most useful for different evaluation setups?

Open-ended generation often needs a blend of automatic and human-based metrics. Automatic checks are useful for scale, but they usually need a reference set, retrieval evidence, or a rubric to be meaningful. Human review is better at judging nuance, partial support, and whether the model overstates confidence. In practice, teams often track both the rate of unsupported claims and the rate of outputs judged acceptable by experts.

Task design matters as much as the metric. Question answering, summarization, grounded retrieval, and code generation all require different scoring rules. A summarizer may be penalized for adding details not present in the source, while a creative assistant may be evaluated more on whether it avoids confident falsehoods than on literal overlap with a reference answer. The same model can therefore look strong in one benchmark and weak in another.

A useful evaluation also separates error types. Unsupported claims, fabricated citations, source misattribution, and subtle source distortion are different failure modes, and they do not always move together. When a team can break them apart, it is easier to decide whether the problem is retrieval quality, prompt design, source grounding, or the model’s tendency to overgeneralize.

How should practitioners turn hallucination metrics into a usable control?

Use metrics that fit the decision being made. If the output is low risk, a sample-based review process may be enough. If the content can influence legal, financial, medical, or customer-facing decisions, the bar should be higher and the evaluation should emphasize faithfulness, citation integrity, and explicit confidence handling. For grounded systems, pair automated scoring with spot checks on the exact source passages the model was supposed to use.

For governance, the most important decision is consistency. If different reviewers apply different standards for what is “unsupported,” the metric will drift and stop being comparable over time. Teams get better results when they publish a short rubric, define acceptable evidence for each content type, and keep a stable test set that reflects real production prompts rather than only clean benchmark questions.

If the model is used in a retrieval workflow, the evaluation should also include the upstream knowledge base and retrieval stage. A poor result may come from missing source material, weak chunking, or irrelevant retrieval rather than pure model hallucination. Treating everything as an LLM problem usually hides the real failure point.

Risk and Threat Considerations

Hallucination risk becomes material when people treat fluent output as evidence. The main danger is not just a wrong answer, but a wrong answer that is confident enough to pass review, enter a report, or shape a decision. In high-stakes settings, fabricated support can be more damaging than a simple omission because it creates false confidence.

Failure mechanism: The model generalises beyond its evidence, misstates a source, or invents a citation, and reviewers fail to catch the unsupported claim before it is reused downstream.

Impact: Teams can propagate falsehoods into customer communications, internal analysis, or operational decisions, which undermines trust and can create compliance or safety exposure.

Practitioner Guidance

What to verify: Verify that the metric matches the task. A factuality score is not enough if the system must stay anchored to source text, and a citation score is not enough if the real failure is unsupported synthesis. Use a rubric that distinguishes wrong, unsupported, and partially supported outputs.

Common mistake: Do not rely on a single aggregate score to decide readiness. One model can improve on average while still producing rare but severe hallucinations on sensitive prompts, so sample design and edge-case testing matter as much as the headline number.

Practitioner takeaway: The best hallucination program measures support, not just similarity, and it treats confidence, citation quality, and human review as complementary controls rather than substitutes.

Related resources from NHI Mgmt Group

• Guide: LLM Security Guide
• Why do hallucinations persist even when LLM metrics look healthy?
• How should security teams evaluate open-source cryptographic libraries used in identity flows?
• Which frameworks help teams evaluate Zero Trust metrics and access governance?
• What breaks when an LLM is used to judge its own safety?