Choose AI evaluation metrics and write a usable rubric

A metric compresses many outcomes into a number. A rubric tells a reviewer what those outcomes mean. Both are useful only when they correspond to the decision at hand. A model can produce valid JSON for every request and still put a fabricated answer inside it; a fluent answer can be wrong even when it reads well.

Imagine a fictional assistant that answers questions from policy excerpts. The team wants an answer supported by the supplied text, a useful citation and an explicit acknowledgement when evidence is missing. This article's examples and thresholds are illustrative, not measurements.

Start with the failure that matters

List outcomes users care about, then identify the harmful failure modes. For the assistant, an unsupported approval may matter more than a slightly awkward sentence. A useful scorecard might include supported-answer rate, unsupported-claim rate, citation support, appropriate abstention, latency and cost. These measures answer different questions. Keep critical failure rates visible alongside any overall score.

Define a denominator for every rate. “Supported answers / attempted cases” counts timeouts and empty responses against completion if you specify them as failures. “Supported answers / responses graded” excludes ungradable cases and can look better when many requests fail. Neither denominator is automatically wrong, but report the numerator, denominator and exclusions so readers know what happened. Report infrastructure failures separately and apply a consistent, predeclared rule.

For classification tasks, distinguish precision from recall. In an illustrative screening workflow, precision asks what fraction of flagged cases truly need review; recall asks what fraction of all cases needing review were flagged. A system that flags everything can have high recall but impose a large review burden. Choose the operating point based on the consequences of missed cases and false alarms, not on the convenience of a single accuracy figure.

Use deterministic checks where they fit

A parser can check JSON syntax and required fields. A lookup can verify that a cited document ID exists. Executable tests can check whether a proposed patch passes specified cases. These checks are repeatable and often cheap. They do not automatically check meaning: a real citation can fail to support the sentence, and a passing test suite can miss an untested bug.

Use deterministic checks as gates or diagnostic signals, and combine them with a judgement of substance where necessary. OpenAI's evaluation guide describes metric-based, human and model-based evaluators and warns against generic measures that fail to match the task. The right combination depends on the outcome being measured.

Make a rubric operational

Replace “good answer” with observable decisions. A compact rubric for the policy assistant could ask a reviewer to assess each response against the supplied excerpts:

1. Support: Are all material claims supported by the provided evidence? Mark unsupported or contradicted claims separately.
2. Completeness: Does the answer include a material exception needed to act safely?
3. Citation: Does each citation identify a passage that actually supports the nearby claim?
4. Uncertainty: If the evidence is insufficient, does the answer say so without inventing a rule?
5. Usability: Is the next step understandable without changing the substantive meaning?

Define the final pass rule. For example, an answer could pass only if it has no unsupported material claim, includes the relevant exception and cites supporting text. Usability can be reported separately, so elegant prose does not compensate for an unsafe assertion. Specify how to handle partial answers, conflicting evidence, multiple valid responses and cases where no answer is possible.

Add labelled examples at the boundaries: a supported but incomplete answer, a correct conclusion with the wrong citation, and a cautious answer that refuses despite sufficient evidence. Explain why each receives its label. Reviewers should use the same case evidence and rubric version. If they disagree, preserve their independent labels before adjudication; disagreement can expose a vague rule or an ambiguous case.

Be careful with composite scores

A weighted score can help compare acceptable alternatives once minimum requirements are met. But weights encode a value judgement. If a critical error is unacceptable, use an explicit gate rather than allowing good style or speed to offset it. Report the individual components and sensitivity to reasonable weight changes. A composite without components is hard to audit and easy to game.

Slice metrics by task type and relevant conditions. A high overall score may conceal poor performance on conflicting documents or on a language used by a minority of users. Small slices are noisy, so show counts and uncertainty rather than turning a handful of examples into a confident ranking. If a slice was deliberately oversampled, do not report its raw share as a production prevalence.

Validate the measurement itself

Pilot the rubric on a varied set of outputs. Ask two reviewers to label independently, discuss disagreements and revise unclear instructions. Keep a record of rubric changes; labels under different versions may not be directly comparable. Check false positives and false negatives, not just overall reviewer agreement. A model judge can scale a calibrated rubric, but its errors need to be compared with human labels and monitored over time; see human and model judges.

For each run, publish a small scorecard: case count, numerator and denominator, score by slice, critical failures, exclusions, rubric version and examples of failure patterns. If a metric has an uncertain reference answer, say so. A clear scorecard makes it possible to dispute an assumption without disputing the entire experiment.

A metric is a tool for a decision, not the decision itself. Combine it with the workload coverage in task design, and use uncertainty analysis before interpreting a small difference between candidates.

Walk through one judgement

Suppose the fictional policy says employees may approve expenses up to a specified limit, with a separate approval required above it. The assistant correctly states the ordinary limit, cites that passage and omits the exception when asked about a higher amount. A syntax check may pass and the citation may exist, but the completeness criterion fails. If the missing exception could lead to an unauthorised approval, the overall result should fail under the example gate.

Now suppose the assistant states that the supplied excerpt does not cover contractors when asked about a contractor. If the excerpt really is silent, that can pass the uncertainty criterion even though it does not provide a definitive yes or no. If the relevant contractor rule was present and overlooked, the same wording may be an unnecessary refusal. The reviewer must see the exact evidence available to the system to distinguish those outcomes. Such boundary examples make a rubric more consistent than an unexplained one-to-five rating and reveal where an apparently simple metric depends on human interpretation.

A rubric result that can be audited

Keep this criterion-level record alongside the response. It prevents an attractive aggregate from hiding the omission.

Return to the Terra cluster guide · Inspect the four-way results and evidence.