Build a Golden Set That Can Explain a Regression

A golden set is a versioned collection of inputs, fixtures, and expected behavior that lets QA compare an AI system before and after a change. Its value comes from stable, reviewable expectations. A folder of prompts and attractive sample answers is only a starting point.

For a QA engineer, the useful analogy is a regression fixture. You control the setup, execute the system, and inspect the result. The extra work is deciding which variations are acceptable and preserving enough context to explain a changed result. The workflow below is a proposed synthetic exercise, not a report of production performance.

Put the fixture around the whole request

Imagine an assistant that answers questions about a fictional software product. Its request path includes a prompt, document retrieval, model generation, and a response formatter. If retrieval returns different documents tomorrow, the same question is no longer the same test input.

For each golden case, I would record a case ID, user question, document snapshot, expected facts, forbidden claims, and scoring rule. Record the prompt revision, model identifier, retrieval configuration, and grader revision alongside the run. If the provider exposes only a moving model alias, preserve that limitation in the record rather than claiming exact reproducibility.

The expected answer should describe the contract. For a question about a fictional export feature, require the supported formats and a citation to the supplied manual. Allow different sentence structures. Reject an invented format even if the response sounds polished.

Anthropic's agent evaluation guide distinguishes a task from an individual trial and separates the transcript from the resulting environment state. That distinction matters here: a fixture defines the task; each execution produces new evidence. For tools that modify state, inspect the resulting state as well as the answer.

Start with twelve deliberately different cases

Build a tiny synthetic manual and twelve questions. These counts are exercise inputs, not a recommended industry minimum or evidence of broad coverage.

• Four questions whose answers appear explicitly in the manual.
• Three questions where the required fact is absent.
• Three questions that require combining two sections.
• Two questions whose answer changes between manual revisions.

For the absent facts, define a successful response as acknowledging the missing information without inventing a product capability. For the revision cases, give each version a separate fixture ID. Do not silently replace the old document while retaining its expected answer.

One concrete case might ask whether the fictional product exports XML. Manual v1 lists CSV and JSON only. The assertion is that the assistant must not claim XML support from that evidence. Manual v2 explicitly adds XML. The second case should accept XML and require the v2 citation. These are two contracts, even though the question text is identical.

Keeping both cases makes stale retrieval observable. A system that answers every question using yesterday's documents can now fail on a named requirement.

Preserve the comparison when the suite grows

Suppose an invented baseline passes nine of twelve cases. A candidate passes ten. The aggregate rises from 75% to approximately 83%, but that does not tell you which behavior changed.

Construct the example so that the candidate fixes two missing-information cases and breaks one previously correct revision case. That produces the one-case net gain. A case-level comparison reveals the tradeoff immediately; a single percentage hides it. These numbers are arithmetic for this example, not measured model results.

Before running the candidate, mark any requirements that block release independently of the total score. For this exercise, I would make unsupported capability claims blocking failures. A higher aggregate cannot compensate for violating that contract.

When adding cases next week, run both baseline and candidate on the expanded suite. Preserve the original twelve-case comparison separately. Otherwise, a changed denominator can look like a changed system. Give each suite revision an immutable manifest listing case IDs and fixture hashes.

Keep debugging examples separate from fresh checks

A regression suite is supposed to become familiar. Engineers inspect failures and fix them. That makes it valuable for preventing recurrence, but it limits what the suite can establish about unfamiliar tasks.

The scikit-learn guide to data leakage explains why using test information during model construction can make evaluation optimistic. Applying that principle to prompt development, I would separate frequently inspected regression cases from fresh acceptance cases. This is a workflow recommendation, not a claim that prompt tuning and statistical model fitting are identical.

If a fresh case informs a prompt change, record that exposure and move it into the development history. Keep it as a regression test if useful. Stop describing it as unseen evidence. Split related document families together so that a paraphrase of a debugging example does not masquerade as an independent check.

Make the grader earn its place

Before trusting the suite, feed its grader a known-good answer and several deliberately broken answers. Remove the citation. Add XML to the v1 answer. Replace the correct document reference with the wrong revision. Require the relevant assertion to fail for each mutation.

If a broken answer passes, repair the grading rule before interpreting candidate scores. For subjective judgments, document the rubric and review disagreements. For nondeterministic outputs, predeclare repeated trials and report all results; do not rerun until a convenient pass appears.

The practical review checklist is short: frozen fixtures, explicit expectations, versioned graders, case-level changes, declared blocking failures, and recorded exposure to test cases. Keep the traces needed to investigate each failure.

Yesterday's latency exercise measured when an answer arrived. A golden set establishes what that answer was required to do. Which case in your current suite would catch a correct-looking answer built from the wrong document revision?