Evals: proving it works

What this lesson shows

Build an eval set of inputs paired with expected answers, then score every change.

The question it opens with

You tweak the prompt and it 'feels' better. Is it, or did you just break three other cases?

The walkthrough, in the lesson's own words

• Predict: will the edit break anything? Then apply it and watch every row react.
• Evals turn 'vibes' into a number you can defend, and a gate you can automate.
• A toy suite of 5 invented cases; real eval sets run hundreds of them.
• Two cases fail under prompt A, and the edit (B) is meant to fix them. Will B break anything that passes today?
• This is an eval set (a golden dataset): a taste-test panel every new recipe must pass before it goes on the menu, real inputs paired with the right answers. Engineers call this pattern unit tests. Lock in your prediction, then apply the edit and let the table answer.
• Two reds turned green, but one green turned red: the feature-request case now mis-classifies. The number went up, so you'd have shipped the regression on vibes alone. The eval set caught it.
• Ship improvements, not regressions, proven, not felt.
• A CI gate is an automatic check that refuses the change, no human has to catch it. It runs before code is merged: point it at your golden dataset so every prompt change is scored, and the merge is blocked the moment any case regresses, even if the net pass-rate went up.
• Next: exact match works for a single right word, but how do you score a long, open-ended answer where many wordings are correct?
• The eval set you score before shipping is an offline eval: a fixed set you run in the lab. It can go stale or get contaminated, the answers leak into training, so it stops measuring real skill. Online evals watch the live system instead: real traffic, sampled and scored continuously, catching drift an offline set misses. And a red-team set is built on purpose from adversarial and failure cases, prompt injections, edge inputs, known traps, to test the things normal data won't. Strong teams run all three: offline to gate changes, online to watch production, red-team to probe for the worst case.
• Your offline eval has scored 98% for months and the team trusts it, but users keep reporting failures. What's likely wrong, and what would you add?
• The offline set has probably gone stale or leaked into training, so it no longer reflects real use. Add an online eval that samples and scores live traffic, and a red-team set of the failure cases users are hitting. A frozen 98% can hide drift; production and adversarial signals catch what a fixed set can't.
• In plain terms: no human has to catch the regression, the gate refuses the change on its own.

Key takeaway

Evals turn 'vibes' into a number you can defend and a gate you can put in CI.

What you can do after this lesson

You can explain eval-driven development: test sets, scoring, and catching regressions.

Prefer reading first? This lesson has a companion explainer: LLM evals

Where it leads: But who grades thousands of open-ended answers? Often, another model.

This is the written summary. The lesson itself is interactive: you predict, drag and operate the mechanism above, and the reveal answers you.