Evals are the test suite your AI feature doesn't have

Nobody ships a payment change without tests. Teams ship prompt changes every day on the strength of "I tried it a few times and it seemed better." That is shipping without tests, and the bill arrives as a slow, confusing regression that nobody can pin to a release.

An eval set is the test suite. Here is how we build a small, honest one in a week, from traffic you already have.

Day one: sample real inputs

Pull two hundred real requests from the last month. Not the clean ones: stratify so the long, the malformed and the off-topic are represented in proportion. Synthetic inputs are fine for coverage later; they are the wrong place to start because they never contain the surprises.

Days two and three: label with the people who know

Have the domain owner, not the engineer, mark what a good answer looks like for each input. Where two people disagree, keep both labels and the disagreement. Those are your hardest cases and your most valuable ones.

Fifty well-labelled examples beat five hundred rushed ones. The point is a set you trust.

Day four: decide how to score

Some outputs can be checked exactly: a classification, an extracted field. Most cannot, and for those we use a rubric and a model-as-judge, calibrated against the human labels until they agree above ninety percent. If the judge and the humans disagree, the judge is wrong.

Day five: wire it into the release

The eval runs on every prompt or model change, in CI, and posts a score next to the diff. A drop blocks the merge the same way a failing test does. From then on "seems better" is a hypothesis, and the set is how you check it.

It will be too small. That is fine. Add every production failure to it, and in three months it will be the most valuable asset the feature has.