Module 24 / Designing AI systems

Module 24 · lesson 9 of 12 · Read 9 min

Evals

Testing something that answers differently every time.

What you'll learn

  1. What "good" means for your feature
  2. The golden set
  3. Check with code first
  4. LLM as judge
  5. Regression evals on every change
  6. Online metrics: what happens in production
  7. Closing the loop

You change one line in the support assistant's prompt to make answers friendlier. It looks great on the five questions you try by hand. A week later, someone notices refund answers have started saying "within 24 hours" when the policy says 1 hour. Nothing crashed. No test failed. Quality just quietly slid.

That's the normal way LLM features break. The prompt changes, the model version changes, the retrieval settings change, the documents change, and any of them can make answers worse without a single error. You can't catch this with assertEquals, because the right answer can be phrased a hundred ways, and the same input gives different outputs.

Evals are how you test it anyway. This lesson covers what to measure, how to build a test set, how to grade answers automatically, and how to keep watching once you ship. It applies to everything earlier in this module: RAG, tool calling, agents and routing all need evals before you can change them safely.

What "good" means for your feature

Start by writing down what a good answer is, as separate checkable properties. For Tiffin's support assistant:

Property Question it answers How to check
Format Is the JSON valid, are citations present? Code
Retrieval Did the right policy chunk reach the prompt? Code, against labelled sources
Correctness Does it state the right refund window and amount? Code for exact facts, otherwise a judge model
Groundedness Is every claim supported by the sources it was given? Judge model
Behaviour Does it say "I don't know" and offer a human when sources don't cover it? Judge model
Safety Does it avoid leaking other customers' data or promising refunds it can't give? Code and judge model
Latency and cost p95 time and tokens per answer Code

Splitting quality up like this matters. "The answers got worse" is not actionable. "Groundedness is fine but retrieval recall dropped from 92% to 81% after the chunking change" tells you exactly what to fix.

An eval is a repeatable test that scores a model-powered feature on a fixed set of examples, so you can compare one version against another.