What to measure and with which data, success criteria and mixed methods

The committee is about to approve the launch on one number: 94% accuracy on 300 historical cases. In the same meeting someone mentions that users abandon any tool that takes more than a few seconds, finance asks how much each case costs and legal points out that the documents contain third parties’ personal data. The 94% says nothing about any of those three things.

Success criteria: several at once

Good success criteria are specific, measurable, achievable and relevant. “Answers well” isn’t; “an F1 of at least 0.85 on a representative test set” is. And almost no system is decided on a single dimension:

Dimension	Example target
Task accuracy	correct fields on the labelled set
Latency	p95 below the threshold users tolerate
Cost	cost per transaction within budget
Safety and privacy	personal data leakage rate, harmful content

Safety is measured on both sides: how much harmful content gets through with adversarial inputs, and how many legitimate requests are refused for no reason (over-refusal). A rising refusal rate isn’t good news on its own: the assistant may have stopped explaining ordinary things.

The dataset: make it look like production

A set of 400 clean, single-topic questions, written by the same people who wrote the prompt, can score 97% and predict nothing. The dataset has to reflect the real-world task distribution:

• take it from production, anonymized, and stratify it by request type;
• include edge cases: combined, ambiguous, out-of-scope and malicious questions, scanned inputs or unusual layouts;
• label the expected behavior, not just the answer: sometimes the right thing is to ask for clarification or hand off.

Volume beats perfection: many automatically graded questions are worth more than a few hand-picked ones read one by one.

Mixed grading methods

With mixed methods, each part of the output is graded with the tool that fits it:

• Code-based grading: for anything with an exact answer (dates, amounts, parties, a label, valid JSON). Deterministic, cheap, scalable.
• LLM-as-judge: for free text, with an explicit rubric that defines each point on the scale and an output that is easy to parse. It’s best to grade with a different model from the one that generated the answer.
• People: a sample graded by experts to calibrate the judge model and review the cases where there is disagreement.

The usual traps

• Measuring only accuracy and discovering latency or cost after launch.
• Raising the accuracy target to 99% on a set that doesn’t represent reality.
• Growing the set with generated paraphrases of the same clean questions.
• Having the production model grade itself in the same request.
• Adding human graders on the same 25 cases picked because they were “interesting”.
• Keeping only the hard cases: the set stops looking like the real distribution.
• Surveying users a month later instead of setting targets beforehand.

In the exam

If the scenario mentions requirements in passing (speed, budget, sensitive data), the answer adds a measurable criterion for each one alongside accuracy. If it shows a very high score and complaints in production, look for the option that rebuilds the dataset from real cases with their edge cases. And if the output mixes exact fields and free text, look for the combination: code for the exact parts and an LLM judge with a rubric, calibrated by people, for the free text.