Evals: how you know a change made the product better

Every AI product hits the same wall. A change is made because one output looked wrong, it fixes that case, and something else breaks that nobody notices for two weeks. The fix is an eval set: a fixed collection of inputs with a defined notion of a good output, run against every change. It does not need a framework to start. Fifty real examples in a spreadsheet, with the expected result written next to each, is more than most products have. Three kinds of case belong in it. The ordinary ones, which should always pass. The edge cases that have already broken in production — every incident earns a permanent entry. And the cases that should be refused or escalated, because a model that answers confidently when it should decline is a specific and dangerous failure. Scoring is the part people over-engineer. Where the output is structured, check it programmatically. Where it is prose, a rubric applied by a person on a sample beats an elaborate automatic judge you have not validated. A model grading a model is useful once it has been checked against human grading on the same cases, and not before. Then run it on every change, record the score, and keep the history. The value is the trend, not the number. Two habits that compound: log every production input and output from day one, because that log is where future eval cases come from; and when a customer reports a problem, add it to the set before fixing it, so the fix can be proven. This article is general information, not legal, tax or financial advice. Rules change and every deal is different — check your own case with a licensed professional. Alberto Zaltzberg — Adonait · adonait.com