Metrics and Interpretation
So far, applying your judges to a single test case produces one judgement about the system's performance. But a single judgement tells you little about how the system performs more broadly.
To assess the system as a whole, you apply the same process across an evaluation set, producing a collection of individual judgements and no obvious answer.
A metric turns that collection into something you can interpret: a quantitative measure that aggregates judgements into a single number, which you can then compare against your acceptance criteria to determine whether the system is "good" enough.
Constructing and choosing metrics
You construct a metric by choosing an aggregation for your judgements. For example, if a judge labels each sample correct or wrong, aggregating those labels into the proportion of correct across all samples gives you the familiar metric accuracy. Different judgement types suit different aggregation methods:
| Judgement type | Example aggregation methods |
|---|---|
| Categorical | Rate / proportion |
| Ordinal categorical | Median, or a rate at a threshold |
| Numerical | Mean, median, or percentiles |
| Comparative | Win rate |
We only cover the aggregation that completes a metric's definition here. How you apply it across the evaluation set, such as overall versus slices, weighting, repeated runs, and missing cases, is covered later, under 4. Improve.
Understanding the different sources of metrics
Underneath, every metric comprises a collection of judgements and an aggregation.
However, the pairing might be already previously established by practitioners in the field, but other times, it is more appropriate to define your own metric.
This gives you two sources of metrics:
Established, industry-standard measures with known behaviour and ready tooling.
- Cheap to adopt
- Make comparison easier when a common evaluation setup exists
- Accuracy
- Precision / recall
- Faithfulness
- BLEU / ROUGE
Measures you define for your own task and users.
- Capture task-specific behaviour established measures miss
- Target an evaluation objective standard metrics don’t cover
- % of support replies that resolve the issue without a follow-up
- % of drafts accepted without edits
How many metrics should you have?
More metrics are not automatically better. Every metric costs resources to build, maintain, and interpret, and each new one eventually adds less than the last.
Metrics are only worth adding until every specification you defined earlier is covered by at least one (the ideal point); beyond it, extra metrics only catch rarer failure modes at the expense of more resources, as seen in the payoff curve below.
Make sure every specification is covered by at least one metric. Beyond that, additional metrics are optional: they may capture extra failure modes or provide more diagnostic detail, but each one also costs time, effort, and attention to build, maintain, and interpret.
Constructing your basket of metrics
Apart from the number of metrics, you also have to consider the composition of your basket of metrics.
Explore by sliding and adjusting the mix to see how differing composition works for differing evaluation objectives.
How should your basket of metrics be composed?
How to interpret metrics
Acceptance criteria
A metric value alone does not tell you whether you have achieved "good". The number needs to be read in the context of your evaluation objectives.
Acceptance criteria bridge that gap: they set respective benchmark(s) for what counts as "good" enough. They are typically expressed as gates.
Each gate pairs a threshold value with a consequence, and that consequence is what separates the two kinds of gate:
Minimally, you have one hard gate for each specification you defined earlier. Any additional soft gates are optional, and only worth adding if they capture a meaningful distinction in what counts as "good" in your context.
How to set gates
Each gate has two factors to set: the threshold value and the consequence when it is not met.
Both factors should account for any false positives and negatives should the gate be triggered. Consider these two questions to guide your choice:
- What does it cost when a real failure gets through? The gate passes a system whose performance is unacceptable, allowing failures such as incorrect eligibility advice to reach users. This is a false negative.
- What does it cost when a false alarm goes off? The gate flags or blocks a system whose performance is actually acceptable, causing unnecessary reviews, delays, or lost opportunities. This is a false positive.
Weigh these costs against each other to guide how strict your thresholds should be and whether to enforce them as hard or soft gates.
| If the costlier error is… | Lean towards… |
|---|---|
| Failures reaching users (vulnerable users, irreversible actions, regulatory exposure) | A stricter threshold, enforced as a hard gate |
| False alarms (scarce reviewer time, blocked releases, chasing marginal gains) | A more forgiving threshold, or a soft gate that flags rather than blocks |
To choose the actual threshold values, start with established requirements or relevant baselines, such as the current human process or previous system version. Use representative evaluation results to assess how different thresholds affect missed failures and false alarms.
You can always revise your threshold values later when more evidence becomes available, while ensuring they continue to reflect your specifications.
Worked example: Setting acceptance criteria for the appeals assistant
An appeals assistant reviews benefit appeals and recommends approve or decline with a rationale. A human reviewer makes the final call.
One specification is correct recommendations: the assistant should recommend what a qualified human reviewer would decide.
1. Define the metrics
A judge labels each recommendation correct or wrong against a reference set of previously decided appeals. Aggregating the labels gives recommendation accuracy, the proportion of correct recommendations.
The team also measures rule citation accuracy, the proportion of rationales that cite the correct policy rule.
2. Weigh the two errors
Weigh the cost of each wrong evaluation decision:
- Missed failure: Eligible applicants are denied benefits, or ineligible applicants are approved. The harm is serious.
- False alarm: The cost is unnecessary reviews and delayed deployment.
Missed failures cost far more, so a hard gate enforces recommendation accuracy.
Rule citations matter too, but human reviewers check every rationale before deciding, so a soft gate flags weak citations without blocking release.
3. Set the gates
The current manual process agrees with senior reviewers on about 96% of comparable appeals, so the team sets the hard gate at that bar: the assistant should be at least as accurate as the process it replaces.
The soft gate can be looser, because reviewers catch bad citations before any decision. The team sets it at 90%, flagging only when more than about one rationale in ten cites the wrong rule.
A summary of the gates is shown below:
| Gate | Metric | Threshold | Consequence if unmet |
|---|---|---|---|
| Hard | Recommendation accuracy | ≥ 96% | Block release |
| Soft | Rule citation accuracy | ≥ 90% | Flag for review |
Note that these gates are subject to further calibration against real evaluation results, weighing the severity of missed failures against the cost of unnecessary flags.
4. Interpret the results
An evaluation run produces:
- Recommendation accuracy: 94%. Fails the hard gate.
- Rule citation accuracy: 92%. Meets the soft gate.
The soft gate passes, but the hard gate does not, so the system is not ready for release.
Investigate the wrong recommendations, find the recurring failure patterns, and fix them before evaluating again.
Communicating to stakeholders
Read on only when your main evaluation objectives involve communicating results to various stakeholders.
The same evaluation result can be interpreted differently by different audiences, depending on their technical depth, decision-making needs, and familiarity with the evaluation design.
The core objective stays the same across all of them: to communicate your findings, and how you intend them to be interpreted, clearly and accurately.
Whatever your audience, a few general practices help:
- Lead with the takeaway. State the key finding first, then show the evidence that backs it up.
- Explain what the number means. Define the metric, show the numerical result, then say in words what it implies for your product.
- Use visuals where they help. Graphs and tables often communicate a result and its implications more clearly than text alone.
Beyond these, communication should be tailored to respective audiences. We cannot cover every audience type, so we use two common archetypes to show how the same result, a summarisation feature evaluated for faithfulness, can be framed differently for different stakeholders.
- By technical depth
- By decision authority
For this archetype, presentation typically differs in the level of technical detail provided for both methodology and conclusions.
Technical stakeholder
- Faithfulness (LLM-judge, 0–1 scale, n = 500): mean 0.90 (±0.01, 95% CI) on GPT 5.6 Sol; up from 0.85 on GPT 5.5
- Pass rate at the ≥ 0.90 hard gate: 90%
- Failures cluster in the sub-0.90 tail: 63% are multi-document inputs, vs 12% for single-document
- Cost of the upgrade is high, token costs are up 5% and latency is up 5%, but the improvement in faithfulness is worth it
- Dominant error mode is unsupported claims (details not grounded in any source); cross-source attribution errors are second
- Fix scoped for the next feature (source-attribution constraints in the prompt plus retrieval de-duplication); single-document inputs already pass with an average faithfulness of 0.95
Recommendation: upgrade model version.
Emphasis: Exact figures with statistical context and more detailed error analysis; enough to verify conclusions and make a technical decision.
Non-technical stakeholder
- Across 500 test examples, about 9 in 10 claims in the summaries stayed faithful to the source on average, up from roughly 8.5 in 10 before
- While cost of the upgrade is high, the improvement in faithfulness is worth it
- The remaining gap is mainly long documents that draw on several sources, which we're fixing next
Recommendation: upgrade to the new model version; summaries are now more trustworthy.
Emphasis: The headline outcome, the decision, and one plain-language caveat; no metric internals.
For this archetype, presentation typically differs in the insights derived from the evaluation, as well as the actionables that follow.
Decision-maker
- Faithfulness clears our acceptance criteria: about 9 in 10 claims in a summary are faithful to the source, up from roughly 8.5 in 10 on the previous version
- Cost of the upgrade is high, token costs are up 5% and latency is up 5%, but the improvement in faithfulness is worth it to prevent hallucinations in summaries
- The one residual risk, long multi-source documents, is low-frequency; a ticket is already open to address it next release
Recommendation: ship with the new model version (GPT 5.6 Sol).
Emphasis: The recommendation, any trade-off it rests on, and where any residual risk sits; key decision-making information, not mere metric internals.
User
- About 9 in 10 claims in a summary are now faithful to the source on average, up from the previous version
- Take extra care with long or multi-source documents, where a summary is most likely to miss something
What to do: our summaries are even more trustworthy than before, but for multi-source summaries, check the summary against the sources before relying on it.
Emphasis: How far to trust it and the specific cases to double-check; practical guidance, not a decision or metrics.
Check that your judgement design is complete:
- You have outlined the artefacts you will put in front of which judges, and the judgements you expect to get back.
- You have defined a basket of metrics that covers every specification you defined earlier, and set acceptance criteria for each.
If so, you are ready to move on to the next chapter, Evaluation Set Design.
Was this page helpful?