LLM Hallucination Rate: What It Measures and How to Get Yours

Ask what the hallucination rate of a given model is and you will get a number — several, in fact, and they will not agree. That is not because anyone is lying. It is because a hallucination rate is not a property of a model. It is a property of a model, on a task, on a set of inputs, against a definition of correct — and every published figure fixes all four of those to things that are not your product.

This post is about what those figures actually measure, why the rate for your feature is a different number, and how to get that number. If you want the definition and the well-known cases first, start with what an AI hallucination is.

What a hallucination rate is actually counting

Before any number means anything, four decisions have to be made, and most published figures make them silently.

• The unit. Per response, or per claim? A two-hundred-word answer containing one invented sentence is a 100% hallucination rate by the first count and about 5% by the second. Both are defensible. Neither is comparable to the other.
• Grounded against what. A statement can contradict the source the model was given (intrinsic hallucination) or be unverifiable against any source at all (extrinsic). Summarisation benchmarks measure the first; open-domain question sets measure the second; your feature probably suffers from both.
• What abstention counts as. When the model says it does not know, is that a pass, a fail, or excluded from the denominator? Score it as a fail and you have built a metric that rewards guessing — the exact incentive OpenAI’s own analysis identifies as a cause of hallucination in the first place.
• The denominator. All responses, or only those that make a factual claim? A feature that mostly asks clarifying questions will look excellent on the first and ordinary on the second.

Two competent teams can measure the same feature and report rates an order of magnitude apart without either being wrong. A rate without its unit, denominator and abstention rule attached is decoration.

What the public leaderboards measure — and don’t

The published figures come from a handful of benchmark shapes, each answering a real question that is not yours.

• Summarisation-faithfulness leaderboards (Vectara’s is the best known) give a model a document and score whether its summary stays faithful to it. This measures intrinsic hallucination on one task, and it is a fair way to compare models at that task.
• Short-answer factuality sets such as SimpleQA pose questions with a single verifiable answer and score each response as correct, incorrect or not attempted. The third category is the valuable one: it measures whether a model knows when to decline, which is the calibration property that predicts hallucination elsewhere.
• Misconception sets such as TruthfulQA test whether a model repeats common falsehoods a human might also believe.

What every one of them shares: a bare model. No retrieval, no system prompt of yours, no tools, no output schema, no fallback. A task that is not your task, on inputs that are not your users’, against a rubric that is not your definition of correct. They answer “which model hallucinates less on this benchmark?” — useful for shortlisting a model, and silent on how your feature will behave.

Why the rate for your feature is a different number

You do not ship a model. You ship a system: a model plus retrieval, a prompt, tools, output constraints and fallbacks. Every one of those moves the rate. Grounding the answer in retrieved source material pushes it down, hard. A retrieval step that returns the wrong document pushes it up, and adds the authority of a citation to the error. A schema that constrains the output to one of six values makes a seventh impossible. The four places hallucinations enter a production feature are all system-level, and a model benchmark sees none of them.

Then there are your inputs. Benchmarks sample the middle of a distribution; your users live in its tail — the ambiguous request, the document in the wrong format, the question about last week. And your definition of correct is domain-specific in ways no general rubric captures: the answer that is technically true and commercially wrong, the reference that exists but does not apply in this jurisdiction.

For an AI agent the gap is wider still. An agent has a rate per step and a rate per trajectory, and they are not the same: it can call the wrong tool, recover, and produce a correct final answer that no response-level metric would flag. So the honest answer to “what is our hallucination rate?” is that nobody knows until someone measures it on your traffic — which is good news, because it means you can.

How to measure hallucination in an LLM feature

The method is not complicated. It is unglamorous, which is why it gets deferred, and it is the part no evaluation framework can do for you.

1. Decide the unit and the denominator, and write them down. Claim-level or response-level; all responses or only factual ones; abstention scored as correct when it is correct. Every later number inherits these decisions.
2. Sample real cases from production. Not synthetic ones. Stratify so the tail is represented, not just the common path. The right sample size is the one in which the failure modes you care about actually appear — it is a property of your traffic, not a rule.
3. Define “correct” before you look at results. A written rubric, agreed by the people who own the feature. What counts as grounded, what counts as a hallucination, what counts as a good refusal. Deciding this after seeing the outputs is how a rate gets quietly flattered.
4. Label, then scale the labelling. Human judgement first. A model can then be used as a judge to score at volume — but only once its verdicts have been calibrated against the human labels on the same cases. LLM-as-a-judge is a metric, not a methodology.
5. Score the baseline and report it with its terms. The rate, the unit, the denominator, the sample size, the date. A number that travels without those is the decoration from earlier.
6. Segment by cause. Of the failures, how many had no grounding, how many were retrieval misses, how many had the source in context and ignored it, how many were an agent misusing a tool? The rate tells you how much; the segmentation tells you what to fix first.
7. Re-run on every change, and make it a gate. A prompt edit, a model version, a retrieval corpus update, a new tool. The same cases, the same rubric, before release. This is what turns a one-off audit into a number with a trend line.

What counts as a good hallucination rate?

There is no universal figure, and anyone who gives you one has not asked what your feature does. The acceptable rate is set by two costs: what a wrong answer costs when it reaches a user, and what an unhelpful answer costs when the model declines instead. An assistant that abstains on four questions in ten has an excellent hallucination rate and no users. A rate has to be read alongside coverage.

The useful comparisons are your own baseline over time, and the standard you would hold a person to: what error rate would you accept from a competent junior member of staff doing this job, checked at the same frequency you are checking the model? That question usually has a clear answer, and it is the one the number should be judged against.

The number is the beginning, not the result

Once a measured baseline exists, the questions that were previously arguments become experiments. Did the new prompt help? Did the cheaper model clear the bar? Did expanding the retrieval corpus raise the rate because the new documents contradict the old ones? Each is a re-run of the same cases against the same rubric, and each has an answer within the hour.

That is what we mean by LLM evaluation: defining what correct means for one feature, decomposing it into things that can actually be measured, building the cases and the scoring, and running it as a gate. Hallucination is one failure class inside that metric set — usually the one that prompted the question — but the same suite catches the wrong tool call, the discarded intermediate result and the answer that was right for a reason that will not hold next week.

Frequently asked questions

What is the hallucination rate of ChatGPT?

There is no single number, and any figure quoted without its benchmark attached is not meaningful. Published rates for any model come from specific benchmarks with specific units, denominators and abstention rules, and they differ by task: a summarisation-faithfulness score and a short-answer factuality score for the same model are not comparable. A chat assistant used with web search or with your own documents pasted in is also a different system from the bare model a benchmark tested. For any feature you build on any model, the hallucination rate is a property of your system on your traffic, and it has to be measured there.

How do you measure the hallucination rate of an LLM?

Decide the unit (per claim or per response) and the denominator (all responses or only factual ones), and decide up front that a correct refusal counts as correct. Sample real cases from production traffic, including the tail. Write a rubric defining what counts as grounded, hallucinated and a good refusal before looking at any results. Label the cases by hand, and only then use a model as a judge to scale, calibrated against those human labels. Score the baseline and report it with its unit, denominator, sample size and date. Segment the failures by cause so the rate becomes actionable, and re-run the same cases on every change as a release gate.

What is a good hallucination rate?

It depends on what a wrong answer costs when it reaches a user and what an unhelpful refusal costs instead, so there is no universal figure. A feature that declines often will show an excellent hallucination rate and poor coverage; the two have to be read together. The useful comparisons are your own measured baseline over time, and the error rate you would accept from a competent person doing the same job, checked as often as you are checking the model.

Do hallucination leaderboards tell you how your product will perform?

No. They compare bare models at one task on inputs that are not your users' and against a rubric that is not your definition of correct, with no retrieval, prompt, tools or output constraints in the loop. They are a reasonable way to shortlist a model and no way at all to predict a feature's behaviour. The rate for your feature is a system property and has to be measured on your own traffic.

Is a lower hallucination rate always better?

Not on its own. The cheapest way to lower a hallucination rate is to make the model decline more, and a feature that refuses four questions in ten has a very low rate and very few users. A hallucination rate should always be reported alongside coverage or helpfulness, and the acceptable trade-off between the two is a product decision that depends on what a wrong answer costs in that context.

How often should a hallucination rate be re-measured?

On every material change to the system, meaning a prompt edit, a model version change, a retrieval corpus update or a new tool, and periodically regardless, because the models underneath a feature change under you. The practical form is to run the same cases against the same rubric as a gate in the deployment pipeline, so that re-measurement happens before release rather than after a customer notices.