Building Test Sets & Golden Data

A test set is the most valuable thing an evaluation engineer builds. A weak test set gives false comfort. A strong one catches problems before customers do. This lesson shows where cases come from, how many you need, how to label them and how to avoid the common traps.

Where cases come from

• Real usage: logs of real questions, with privacy rules applied. This is the best source.
• Domain experts: ask them for typical, tricky and rare cases.
• Past failures: every bug and complaint becomes a case.
• Written scenarios: cases you design to test a rule, such as a refund above the limit.
• Synthetic cases: examples made by a model, then reviewed by a person. Useful to widen coverage, but check them.

Cover the whole range

A test set must look like real use, including the hard parts. If it holds only easy cases, the score will mislead you. Aim for a mix.

TYPICAL CASES      The everyday questions that make up most of the traffic
HARD CASES         Ambiguous, multi-part, or needing several documents
EDGE CASES         Very short, very long, typos, other languages, odd formats
RISK CASES         Should refuse, should escalate, private data, hostile input
NEGATIVE CASES     The answer is not in the documents, so the right reply is "I don't know"
RECENT CASES       New products, new rules, new wording

For each group, note how many cases and why that many.

How many cases

There is no magic number. A small set of 30 to 50 carefully chosen cases is enough to start, and much better than nothing. Aim for 100 to 300 for the main tasks as the product grows. What matters more is that the cases are real and varied. A small set gives noisy scores, so look at the differences case by case, not only at the total.

Labeling: the right answers

• Ask domain experts to write or approve the right answer, or to mark the key facts that must appear.
• For open answers, write a short list of must-have points instead of one exact text.
• Use two reviewers on hard cases, and settle disagreements by discussion.
• Record who labeled each case and when, so you can trace and update it.

Keep a hidden set

Split your cases into two groups. Use the development set while you tune prompts and settings. Keep the final set untouched, and use it only to confirm a release. If you tune on every case, your score will look better than the real quality.

Beware of leaks

• Do not put test cases into prompts as examples. The model will look good because it has seen the answers.
• Check that test cases are not in any training or fine-tuning data you control.
• Keep private data out of the set, or mask it, following your privacy rules.

Keep it alive

A test set goes stale. Products change, rules change and users change. Review it every quarter. Remove cases that no longer apply. Add new ones from live traffic. Version the set, so you can compare scores over time.