by Vishal Kannankara

Evals / 01

The golden set

A small, versioned collection of real cases with checkable expected outcomes. It is the difference between "the new prompt feels better" and "the new prompt fixed 4 cases and broke 2."

What it is

A golden set is 20 to 50 input cases for one task your system performs, each paired with an assertion about what a correct output must contain, do, or avoid. It lives in your repo, versioned like code, and you run every change against it. It is not a benchmark and it is not a test suite in the classical sense. It is the recorded memory of how your system fails, turned into a measuring stick.

Why it exists now

LLM systems are stochastic and every change is global. A prompt edit that fixes the case in front of you silently changes behavior on cases you are not looking at. Traditional tests cannot hold this, because correct outputs are plural. So teams ship on vibes, and vibes do not survive the third engineer touching the prompt.

Hiring has caught up to this. Job descriptions at AI-product companies now ask candidates to "define the metrics and evals that prove a system works." In interviews, the golden set is the first thing a serious team asks about, because it is the smallest artifact that separates engineers who have operated LLM systems from engineers who have watched demos.

The 20-minute kata

  1. Pick one real task your LLM system performs. One. Not the whole product.
  2. Collect 10 real inputs: 5 typical, 3 edge cases, 2 that have actually failed before. Pull them from logs or support tickets, not from your imagination.
  3. For each input, write the expected outcome as a checkable assertion. "Response cites the refund policy" is checkable. "Response is helpful" is not.
  4. Run your current system against all 10. Record pass or fail per case, by hand if needed.
  5. Save it as eval-v1.jsonl in the repo, next to the prompt it measures.

You now have a baseline. The next change anyone makes to that prompt has a number attached to it.

What good looks like

  • Cases come from production failures and support escalations, not from brainstorming. A golden set nobody has ever failed is decoration.
  • Every assertion is checkable by code or by a calibrated judge. No "seems right."
  • The set is versioned with the prompt it measures, and both change in the same pull request.
  • It is small enough to run on every change. Fifty cases you run beats five hundred you do not.
  • New failures found in production get added to the set the same week. The set grows the way a scar forms: where the damage happened.

How it's tested

"Walk me through the last eval set you built. Where did the cases come from? What did it catch that you would have shipped?"

The red flag they are screening for: "we tested it manually before releases." That answer says the team measures nothing and hopes.

← Evals branch Next: LLM-as-judge →