Topic 8
Check the evaluation itself, and wrap-up
An evaluation is a system too, and it can be wrong. AI Engineering (Ch. 4, "Step 3. Define Evaluation Methods and Data", "Evaluate your evaluation pipeline") lists questions to ask of it:
Scroll sideways to see the whole diagram
First: does the evaluation reward the outputs you'd actually prefer?
Text version
- First: does the evaluation reward the outputs you'd actually prefer?
- Then: would the same evaluation, run again or on another sample, give the same answer?
- Look at how your metrics move together: duplicates waste effort, and total disagreement is a warning.
- Evaluation isn't free. Count its cost and latency too.
- As the plan changes, log every part of it, so old and new results stay comparable.
- Is it giving the right signal? Do better outputs get higher scores? Do better scores go with better business results?
- Is it reliable? Run it twice, or on another sample of the same size: do you get the same result? Keep its settings fixed; if a model does the judging, the book suggests temperature 0.
- Are the metrics correlated? Two that always agree are really one metric. Two that never agree point either to something interesting about the model or to a metric you can't trust.
- What does it cost? Evaluation adds cost and latency of its own. Skipping it to save them is, in the book's words, "a risky bet".
Methods can be mixed to control that cost. The book's example is a cheap classifier that gives a rough signal on all the traffic, plus an expensive model judge that gives a better one on 1% of it. People stay in the loop too: it reports that LinkedIn set up a process to review up to 500 conversations a day by hand.
Predict first
Criteria and rubrics will change as the product and its users do; that's expected. What you need is enough consistency that results from one week still mean something the next.
How big each test set must be is a statistics question, and a later lesson in this module takes it up.
Wrap-up. You can now:
- decide how you'll evaluate an application before building it;
- sort criteria into domain, generation, instruction following, and cost and latency;
- write a rubric with examples, and check it by having two people use it;
- tie a score to a business outcome and set a usefulness threshold;
- score each step and each task, not just the final output;
- slice your results, and spot when an overall number points the wrong way.
Quick check