What is a golden set?
A prompt edit fixes the case someone complained about. Three months later, nobody can say whether it also broke twelve others, because nothing checked them.
Golden set
golden dataseteval set
A golden set is a fixed collection of inputs, each with a human-agreed correct answer. It checks that a model, prompt or retrieval change has not broken behaviour that used to work. It only changes when a person deliberately adds or edits a case.
"Fixed" is the operative word. A golden set is not sampled fresh for each test run. The same fifty or two hundred cases get checked every time. A score of 94% today means the same thing as a score of 94% last month.
That is what makes it a contract rather than a snapshot. The system's past correct behaviour is written down as cases, and any change has to keep passing them before it ships. A model swap, a new prompt, a different retrieval setting: all of them run against the same set before anyone trusts the result.
Cases come from real failures, not imagined ones
A team writing golden examples from imagination tests what they think the system will see. Production sends the inputs nobody thought of. The sourcing rule fixes that: every golden example either comes from a real production failure or a real edge case a user actually hit.
That means the set grows every time something breaks. A support agent misreads a cancelled order as a refund request. That transcript becomes a case, with the correct handling attached, before the fix even ships. The bug is now permanent protection instead of a one-time patch.
Size matters less than most teams assume. A hundred well-chosen failures beat a thousand easy cases the system was never going to get wrong. What decides the count is coverage of the ways the system actually fails, not a round number picked in advance.
- 01Source every case from a real failure or a real edge case, never an imagined one.
- 02Add the case before the fix ships, so the bug cannot silently come back.
- 03A human, not the model, decides the correct answer for each case.
- FailsProduction or a review catches it.
- CapturesThe exact input, kept as-is.
- LabelsA person sets the correct answer.
- FreezesAdded to the set. It does not drift.
- GuardsEvery future change must still pass it.
The set only grows through this path. Nobody invents a case to round out a number.
Common questions
01How many examples does a golden set need?
Enough to cover the real ways the system fails, not a fixed number. A narrow task might need fifty cases; a document-heavy pipeline with many input formats can need several hundred. Start with every known failure and every edge case a user has hit, then add to it as new ones turn up.
02How is a golden set different from a regular eval set?
Every golden set is an eval set, but not every eval set is golden. A golden set specifically stays fixed and human-verified, so a score from it is comparable over time. A team that resamples its test cases each run has an eval, but not a contract it can trust week to week.
03Who should write the correct answer for each case?
The person who already does the task by hand, not the engineering team. They know which of two defensible answers the business actually stands behind. Engineers build the grader that checks the model's output against that answer; they should not be inventing the answer itself.
04Does a golden set ever need to change?
Yes, but only by deliberate human edit, never by drift. Add a case when a new failure surfaces. Remove one only when the business rule behind it has genuinely changed. Anything else and the set stops meaning what it meant last week.
