AAI Agentic Handbook
Evaluation & Metrics

Golden set

Budding levelReviewed Oct 2026In 37 interview questionsIn 18 posts

A fixed, versioned set of realistic inputs with known-good answers or relevant documents, used to score every change the same way.

In plain English

A golden set is your answer key. It is a list of real-looking questions, each paired with what a correct result looks like: the documents that should be found, the facts the answer must contain, or a rubric. Every time you change a prompt, a model or the retrieval, you rerun the same set and compare scores, so you know whether you improved things or broke them.

Analogy

A chef's tasting menu that never changes, cooked after every kitchen change, so you can taste whether the new oven made things better or worse.

Common pitfall

Writing the golden set yourself from the documents. Author-written questions reuse the documents' wording, so lexical retrieval looks great and real user phrasing fails.

How it actually works

Build from real traffic first (sampled logs, support tickets, search queries), then add synthetic items only to fill gaps you can name. Each item carries: input, expected relevant chunk ids (for retrieval metrics like Recall@k and nDCG), expected answer facts or a Rubric, and tags (intent, difficulty, language, answerable/unanswerable, facts-needed). Size it from the confidence interval you need: at accuracy p ≈ 0.8, the 95% CI half-width is 1.96·√(p(1−p)/n): ±5.5 points at n = 200, ±3.5 at n = 500, ±2.5 at n = 1,000. Version it in git, freeze a held-out split nobody tunes on, and refresh quarterly from new failure clusters found in Error analysis. Leakage is the silent killer: if items are also in few-shot examples or fine-tuning data, scores inflate (Benchmark contamination).

What I'd ship on day one

200–500 items sampled from production logs, stratified by intent, 10–15% unanswerable; two labellers on 20%+ of items with κ reported; JSONL in git with a schema and a version tag; 70/30 dev/holdout split; quarterly refresh from error-analysis clusters.

Worked example

Code-search assistant for a 3M-line monorepo. v1 golden set: 320 items from six weeks of search logs, stratified across 'where is X defined' (90), 'how do I call Y' (110), 'why does Z fail' (70), cross-repo (30) and unanswerable (20). Each lists 1–4 relevant file paths plus required answer facts. Two engineers labelled independently; disagreements on 11% were adjudicated. A dev split of 220 is used for tuning; 100 are held out and only run before releases.

In the interview

Say: I start from 200–300 items sampled from real logs, stratified by intent, with 10–15% unanswerable, labelled by two people, and I size it by the CI I need to detect the change I care about. Expect: 'how do you keep it from going stale?' Quarterly refresh from production failure clusters, plus a frozen holdout to catch overfitting to the dev split.

Query (from logs)Relevant filesMust mentionTags
where is retry backoff setnet/retry.gomaxDelay 30swhere-defined
call billing svc from pysdk/billing.pyidempotency keyhow-to-call
why does make test hangci/README.mddocker socketwhy-fails
deploy to mars region—abstainunanswerable
Each item scores retrieval (files) and generation (facts) separately
1002005001,0002,0002468±3.5 at n = 500Golden-set size (n) (log scale) →95% CI half-width (points) →
Halving the error bar needs 4× the items

Numbers worth knowing

95% CI half-width
±5.5 / ±3.5 / ±2.5 pointsn = 200 / 500 / 1,000 at p ≈ 0.8
Labelling time
3–6 min per itemretrieval ids + answer facts, domain-literate labeller
Refresh cadence
quarterly, 10–20% new itemsproducts with changing corpus or users

How to decide

WhenDo this
No production traffic yetWrite 100 items with domain experts, mark them provisional, replace with log samples within a month
Need to detect a 2-point changen ≈ 1,500+ or a paired test on the same items
Multiple tenants or languagesStratify and report per slice; a global mean hides regressions

Cost maths

Labelling cost = n × minutes per item × hourly rate. 400 items × 5 min × $60/h = $2,000, plus 20% double-labelling = $2,400. Quarterly refresh of 15% ≈ $360. Compare with one bad release that a 3.5-point CI would have caught.

Operating it

Time to scale up when…
  • Release decisions hinge on differences inside the CI: grow n
  • A new intent or tenant > 10% of traffic is not represented
  • Dev-split score rising while holdout is flat: overfitting, refresh dev
What to monitor
  • Dev vs holdout score gap; alert > 3 points
  • Age of newest item; alert if > 120 days
  • Share of production intents with < 20 golden items; review monthly

When it goes wrong

What users saw

Golden-set accuracy rose from 81% to 89% over three months; user thumbs-down rate did not move

How it was caught

Quarterly holdout run: 80%, unchanged from the start

Root cause

Prompt tweaks and few-shot examples had been tuned on the dev split for 40 iterations; several golden items had been copied into few-shot examples

Fix

Removed leaked items, rotated a fresh dev split from recent logs, and added a CI check that fails if any golden input appears in prompts or training data

Where it shows up

Sources

  1. Your AI Product Needs Evals — Husain, 2024blog
  2. BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models — Thakur et al., 2021paper
  3. Introduction to Information Retrieval (ch. 8, Evaluation) — Manning, Raghavan & Schütze, 2008book

Check yourself

Three questions. Every option is explained once you answer.

1ConceptWhy should golden-set questions come from production logs rather than being written from the documents?
2ScenarioYou must tell whether a new prompt is 2 points better than the old one. Your golden set has 400 items. What do you do?
3CalculationAccuracy p ≈ 0.8 on a 500-item golden set. What is the 95% CI half-width?