How to measure your AI's hallucination rate

August 10, 2026 · by Kate Sai Kishore

Ask a team what their AI assistant's hallucination rate is and you will usually get one of two answers: a shrug, or a number nobody can trace back to a run. Neither survives contact with a procurement review, an auditor, or a bad week in production. If the system sits between your documents and your decisions, the rate at which it makes things up is a property you should measure the way you measure latency: with an instrument, on a schedule, against a definition written down in advance.

There is no off-the-shelf gauge for this. If you go looking for how to measure AI hallucination rate, most of what you will find is leaderboard scores for foundation models on public trivia, which say almost nothing about your model, on your corpus, inside your pipeline. The good news is that a credible measurement does not require a research lab. It requires five disciplined steps, a corpus you control, and a willingness to distrust your own harness. Here is the procedure we use, in the order we run it.

Step 1: Decide what counts before you measure anything

Before you write a single test question, write down what will count as a hallucination, because the definition you choose determines everything downstream. Ours is deliberately narrow: a hallucination is an answer whose claim is not supported by the system's own retrieved evidence.

Notice what that definition does not say. It does not say "an answer that is wrong in the world." Wrong-in-the-world sounds like the thing you care about, but you cannot audit the world: for any corpus worth deploying against, there is no oracle that settles what is true, and chasing one turns your benchmark into a debate. What you can audit, mechanically and repeatably, is entailment: does the evidence the system itself retrieved actually support the sentence it wrote? An answer can be true in the world and still unsupported by its evidence, and it should still fail, because the process that produced it was guessing. We walked through the failure modes this definition catches, including cited answers that are still wrong, in why a citation is not proof.

Write the definition down, date it, and freeze it before the first run. A definition adopted after you have seen the outputs will bend, one sympathetic judgement at a time, toward the result you were hoping for.

Step 2: Build trap questions your system cannot answer honestly

A hallucination rate measured only on answerable questions is a vanity metric, because the system never faces pressure to invent. The instrument that applies that pressure is the trap question: a question engineered so that the corpus verifiably cannot support an answer. We build two kinds.

Invented entities. Ask about a plausible project, person, or policy that does not exist in the corpus. "What is the current status of Project Meridian?" is a trap when nothing called Project Meridian appears anywhere in the documents. The name should sound native to the corpus: match its naming conventions, its vocabulary, its era. A trap that sounds foreign is easy to refuse; a trap that sounds like it belongs measures what the system does under realistic pressure.

False premises. Ask about a real entity, but presuppose something the corpus contradicts: "Who approved the merger of the two support teams?" when the corpus records that the teams were never merged. A system eager to please will answer inside your frame; a grounded one will push back on the frame itself.

The critical discipline is that traps are validated mechanically, never by vibes. A trap that merely feels unanswerable is a liability: if the "invented" entity secretly exists in some appendix, every verdict scored against that trap is wrong, in whichever direction embarrasses you more. So before an invented-entity trap is admitted to the suite, code must confirm the invented name appears nowhere in the corpus text: not in a chunk, not in a filename, not in metadata. Before a false-premise trap is admitted, code must confirm the entity is present and the presupposed fact is absent or contradicted. We described the validity checks behind our own suite, including a generated trap they rejected, in our trap-question method post.

Finally, add answerable control questions alongside the traps: real questions whose answers verifiably live in the corpus, validated the same mechanical way. Without them, you cannot measure the other half of the story, which is coming in step 3.

Step 3: Score against a rubric you wrote in advance

Run the full suite against the live pipeline: the same retrieval, the same prompts, the same model your users get, because a benchmark against a lab configuration measures the lab. Then score every transcript against a rubric written before the run, with exactly four outcomes.

Report all four buckets, always separately. The moment you blend them into a single accuracy number, the result stops meaning anything: a system tuned to refuse everything and a system tuned to answer everything can land on the same blended score for opposite reasons. Your hallucination rate is the false accepts as a share of the traps. Your abstention cost is the false refusals as a share of the answerable questions. Publish both, side by side, or neither is honest.

The rubric also needs its edge-case policy in advance. Ours is: classify an answer by what it asserts, not by what it mentions. An answer that repeats a false premise in order to deny it, and cites the correction, is honest behaviour, not a false accept. Decide rules like that before you see a single output, and write down every case the rules did not anticipate.

Step 4: Audit the auditor

This is the step most teams skip, and it is the one that decides whether the other four were worth doing. Your scorer and your ground truth will have bugs. That is not pessimism; scoring scripts and answer keys are software, written quickly, tested rarely. And these particular bugs are not random noise. The harness is usually written by the same people who built the system under test, with the same mental model and the same blind spots, so the mistakes nobody anticipated in the pipeline are the same mistakes nobody anticipated in the scorer. The errors correlate, and they systematically flatter whichever system you built.

So audit the auditor. Take a random sample of verdicts and re-derive them by hand from the raw transcript and the raw corpus text, without looking at the scorer's output first, then compare. Have a second person score a slice independently and reconcile the disagreements. Every disagreement is a harness bug or a rubric ambiguity, and both kinds must be fixed and the affected questions re-scored before the aggregate number is worth repeating.

And treat a suspiciously clean result as a smell, not a triumph. When a run comes back at 100% of anything, the most likely explanation is not that the system became perfect; it is that the harness stopped being able to see failure. Feed the scorer a deliberately wrong answer and confirm it gets flagged. Check that the failure buckets are reachable at all. Celebrate only after the harness has survived the same scepticism you aimed at the system.

Step 5: Report the number honestly

A hallucination rate detached from its run is marketing, not measurement. Every number you report should carry four facts: the suite size, the corpus it ran against, the model and pipeline version, and the run date. "This many false accepts on this suite, against this corpus, on this build, on this date" is a measurement. A bare percentage with none of that attached is a slogan, and you should treat it as one whether it comes from a vendor or from your own team.

Publish the abstention cost next to the hallucination rate, every time. A system that refuses everything scores zero hallucinations and is useless; hiding the false-refusal column is how that system gets marketed as safe. The pair of numbers is the honest unit of reporting, because the pair is what your users actually experience.

And let every number expire with its run. When the corpus changes, the model updates, or the prompts move, the old figure describes a system that no longer exists. Re-run the suite instead of re-quoting it; a suite you built once is cheap to run forever, and that is the point of building one.

The same test works on any vendor, including us

This is the method behind our own published result: zero invented answers across our 120-trap-question suite, a number we quote only with its scope attached, because that is what step 5 demands of everyone, us included.

It is also the fastest evaluation you can run on any system you are considering. Build a handful of traps from your own documents: an entity you know does not exist, a premise you know your corpus contradicts, each one validated mechanically before it counts. Then ask them in the demo, and watch what comes back. How a system behaves on a question it cannot answer honestly tells you more than any deck will. Read how we build for that test at qbrin.com, or bring your traps to a live workspace: Try qbrin on a live workspace →