The scorecard to demand five numbers, not one gut feeling

The first two numbers are the foundation, because most business AI systems answer from your documents, not from thin air. If the system cannot find the right document, nothing downstream can save it - and if it can find it but then wanders off and invents details, the retrieval was wasted.

• Retrieval score (hit rate / context recall). Of the times the answer lived in your knowledge base, how often did the system actually pull the right passage? A low value here means the answer was doomed before the model wrote a word. This is a retrieval metric - it grades the search step, not the writing step.
• Faithfulness (groundedness). Given what it retrieved, does every claim in the answer trace back to that source, or did the model embellish? This is the direct measure of hallucination. A bad value here is the most dangerous of all: a confident, fluent, invented answer that looks exactly like a real one.

The next two numbers grade the answer itself. Relevancy asks whether it addressed the question. Correctness asks whether it got the facts right where a right answer genuinely exists.

• Answer relevancy (on-topic). A model can produce something true, well-sourced, and completely beside the point - answering the question it wished you had asked. Relevancy catches the fluent tangent. A bad value means users have to re-ask to get what they actually wanted.
• Correctness (vs ground truth). For the subset of questions that have one defensible answer - a policy figure, a due date, a calculation - does the system match the known-good answer? This is where you compare against a curated set of questions with verified answers. A bad value means it is wrong precisely where being wrong is checkable and costly.

The fifth number is the one technical teams sometimes forget to put in front of leaders, and the one leaders feel first: is it fast enough and affordable enough to be worth using? An answer that is correct, grounded, relevant, and well-retrieved is still a failure if it takes twelve seconds or costs more per query than the task is worth. Anthropic explicitly lists latency and cost among the success criteria a real deployment must weigh, alongside quality. Track at least one operational number - typical response time or cost per answer - so that "it works" always means "it works, at a speed and price we can live with". A bad value here is quiet: the answers are fine, but adoption stalls because using the thing is a chore.

The single most useful instinct you can build is to distrust a single number. Anthropic frames it plainly: most use cases need to be evaluated along several success criteria at once - task fidelity, consistency, relevance, tone, privacy, latency, cost. A blend of these into one figure will always let a serious failure hide inside a healthy average, exactly as in the picture above.

• One number lies by averaging. A great relevancy score can mask a poor retrieval score. Insist on seeing them broken out.
• Good criteria are specific and measurable. "High quality" is not a criterion. "Cites the correct policy at least 95% of the time" is. If you cannot picture the measurement, the criterion is not done.
• Different jobs weight them differently. A drafting assistant may forgive a weak correctness number; an automated payout tool may not forgive anything but a near-perfect one. You decide the weighting on purpose.

The most quietly corrosive move in evaluation is setting the passing threshold after seeing the scores. It always drifts toward whatever the system happened to achieve. The discipline is to decide - before you run the eval - what number counts as good enough to ship for this use case, and to write it down. Then the result either clears the bar you set or it does not.

• Ask when the threshold was set. "We decided 90% correctness was the bar before we tested" is a healthy answer. "It scored 88%, and we think that is fine" set after the fact is a red flag.
• The threshold belongs to the business, not the model. It comes from the cost of a wrong answer you priced in session a1 - not from what the model can conveniently hit.

Every metric is a proxy for something you actually care about, and any proxy can be gamed. This is Goodhart's law: when a measure becomes a target, it stops being a good measure. A team optimizing hard for one number will, without meaning to, teach the system to win that number in ways that hurt the real goal - answers that get longer to please a length-loving judge, or narrower to protect a correctness score. The leader's job is not to compute the metrics but to keep asking what they might be quietly missing, and to insist the scorecard has enough different numbers that gaming one shows up as damage in another. A healthy scorecard is partly a set of mutual checks.