How to read an accuracy claim

A number arrives in a slide. Ninety-four per cent accurate. Ninety-nine, if the deck is ambitious.

The number is probably real. Someone ran something and got it. What the number does not carry is any of the four decisions that produced it, and those decisions determine whether 94% is excellent, mediocre, or literally worse than doing nothing.

You don't need statistics to interrogate this. You need four questions.

1. Accurate at what, exactly?

Accuracy is the share of cases the system got right. That is only meaningful if the cases are evenly distributed between outcomes — and in business problems they almost never are.

The standard example is worth internalising because you will meet it repeatedly. A fraud detection model reports 99.2% accuracy. Fraud occurs in 0.5% of transactions. A system that simply answered "not fraud" every single time, detecting nothing whatsoever, would score 99.5% — better than the model being presented to you.

This is why AWS's foundational AI certification asks candidates to read precision and recall alongside accuracy rather than instead of it. The two questions they answer are ones a manager actually cares about:

• Precision: of the cases it flagged, what share were genuinely flags? Low precision means your team drowns in false alarms and stops trusting the system.
• Recall: of the real cases out there, what share did it catch? Low recall means it is quietly missing things.

These trade against each other, and which one matters is a business decision, not a technical one. A system triaging safety incidents should accept a lot of false alarms to avoid missing a real one. A system auto-approving refunds should not. F1 is the two combined into a single number, useful for comparison and worth unpacking before anyone leans on it.

So: whenever the answer to "accurate at what" is a rare event, accuracy alone is close to meaningless, and its presence on a slide unaccompanied is worth a question.

2. Accurate on whose data?

There are two very different claims that sound identical in a meeting.

It scores 94% on a published benchmark. This tells you the model is broadly competent, and it tells you nothing about your documents, your terminology, or your customers' phrasing. Benchmarks are a floor, not a forecast.

It scores 94% on 200 cases we built from your last quarter. This is a real prediction about your organisation, and it is a different order of evidence.

The follow-up on the second one is where the test set came from. Anthropic's guidance on developing tests is explicit that a test set should mirror the real distribution of the task, and it names the awkward cases that ought to be in there: irrelevant or missing input, input that is far too long, hostile or nonsense user input, and cases genuinely ambiguous enough that two humans would disagree. A test set assembled from clean, well-formed, representative-looking examples will produce a number substantially better than production, and nobody involved will have intended to mislead you.

3. Who decided what counted as correct?

Every accuracy figure rests on a judgment about what "right" means, and this is the step most likely to be skipped in the telling.

For some tasks it is unambiguous — the category matched or it didn't, the extracted date was correct or wasn't. Anthropic's guidance calls this exact-match grading and recommends automating it wherever the task allows, on the reasoning that many cases graded roughly beats a handful graded immaculately. That is sound advice, and the reason it is sound is coverage: a hundred automated cases find failure modes that ten hand-reviewed cases never touch.

For anything involving prose — a summary, a reply, a recommendation — "correct" requires a rubric. The two common approaches:

Overlap metrics such as ROUGE and BLEU measure how much the output resembles a reference answer. Genuinely useful for catching regression between versions. Weak evidence of quality, because a fluent summary that misstates one fact can score well. AWS puts exactly this trap in its evaluation objectives.

Model-graded scoring, where a second model judges the output against stated criteria — a 1-to-5 scale for tone, a yes/no for whether a claim is supported. This scales to volumes humans cannot, and the caveat is that a judge can share the blind spots of the thing it is judging. It needs calibrating against human review on a sample, not treating as ground truth.

So the question is short: who or what decided a given answer was correct, and against what rubric? If the answer is "we read through them and they looked good", you have an impression rather than a measurement. Impressions are not worthless. They are just not 94%.

4. Accurate at what, measured how many times?

A single number is a single dimension, and almost nothing is one-dimensional. Anthropic's own framing of success criteria lists eight distinct axes worth measuring — task fidelity, consistency, relevance, tone, privacy handling, use of the context provided, latency, and price — and notes that most real use cases need several at once.

That gives you a useful move when a single figure is presented as the whole answer: ask which of those the project has a number for. A team that can tell you the accuracy and the p95 latency and the cost per transaction has been running this as an engineering exercise. A team with one number has been running it as a demo.

The version of this you can use on Monday

Four questions, in order:

1. Accurate at what — and if it's a rare event, what are precision and recall?
2. On whose data, and does the test set include the awkward cases?
3. Who decided what counted as correct, against what rubric?
4. What else did you measure — latency, cost, consistency?

And one reframe worth holding in reserve. If the number is high and the questions above go unanswered, the right response is not I don't believe you. It is: what would have had to happen for this number to be wrong? People will often talk you through the weaknesses of their own evaluation quite willingly, once it is clear you are asking about the method rather than doubting their competence.