Topic 7
Slice your results
One overall score can hide as much as it shows. AI Engineering (Ch. 4, "Step 3. Define Evaluation Methods and Data", "Annotate evaluation data") recommends slicing: splitting the data into subsets and scoring each on its own. The book gives four reasons:
- to catch bias, such as worse results for a minority group of users;
- to debug: is the system weak on long inputs, a topic or a format?
- to find what to improve next;
- to avoid Simpson's paradox, where one system wins on every subset and still loses overall.
It also recommends several evaluation sets rather than one: one that looks like production traffic, one of cases the system often gets wrong, one with the mistakes users make (such as typos), and one of inputs that are out of scope. A fixed test set in Module 03 builds those sets for a prompt. Slicing is how you read the results.
Predict first
Which prompt version is better?
Illustrative counts · each version judged on the traffic it served
Overall
In these illustrative logs, version A wins on easy tickets (95% against 90%) and on hard ones (60% against 55%). Yet B leads overall, 78.3% against 71.7%. B was rolled out to the self-serve flow, which sees mostly easy tickets, so two thirds of its traffic was easy and two thirds of A's was hard.
On one fixed test set, where both versions see the same 100 easy and 100 hard cases, A comes out ahead, 77.5% against 72.5%. A fixed set with the same mix for every version can't produce this paradox. Live traffic can, so slice it before you compare.
Quick check