AI Eval Dataset Lifecycle / Golden Set / Test Data Factory Playbook

定位：面向资深 CBAP / 金融零售 PM / AI Product Architect / Solution Architect / AI Governance / Model Risk，把 eval dataset 从测试附件升级为可治理、可复用、可审计的 AI 质量资产供应链。

使用边界：本文适用于 KYC、AML、credit、payments、contact center、complaints、RAG、agent、copilot、workflow automation 等 AI 产品。它不替代 Legal、Compliance、Privacy、Model Risk、Information Security、Internal Audit 或业务管理层的正式判断。

---

Purpose and when to use

Purpose

这份 playbook 用于建立一套可执行的 AI eval dataset operating model：

dataset inventory
  -> case intake
  -> privacy and retention decision
  -> label governance
  -> coverage matrix
  -> golden / challenge / adversarial / regression promotion
  -> test data factory
  -> release gate
  -> evidence packet
  -> production feedback loop

目标不是“多准备一些测试样本”，而是让团队能回答：

• 哪些 dataset 支撑本次 release decision？
• 哪些高风险场景是 hard gate？
• synthetic case 和真实案例如何组合？
• 标签由谁裁决，依据哪个政策版本？
• 覆盖缺口、覆盖漂移和历史失败如何进入下一版 dataset？
• 一次上线后，审计如何追溯 dataset version、run result、approval 和 exception？

When to use

---

Operating model

1. Roles and decision rights

2. Cadence

3. Dataset lifecycle workflow

1. Discover
   从生产 trace、SME workshop、政策变化、事故、投诉、合成场景发现 case。

2. Classify
   标记 use case、source type、risk tier、customer impact、privacy state 和 failure mode。

3. Govern
   通过 privacy、retention、label authority、coverage 和 promotion gates。

4. Promote
   分配到 golden、challenge、adversarial、regression、synthetic 或 monitor-only 集合。

5. Execute
   绑定 dataset version、component version、evaluator、threshold 和 release decision。

6. Evidence
   归档 manifest、hash、lineage、run result、slice result、exception、approval 和 retention decision。

7. Improve
   从生产失败、漂移、投诉、override 和政策变化中补样、重标、退役或升级 gate。

---

Template: dataset inventory

---

Template: coverage matrix

How to use:

1. Define release scope first.
2. Mark each required slice as covered, thin, missing or not in scope.
3. Convert missing high-risk slices into candidate cases.
4. Do not approve high-impact releases when critical slices are missing without explicit risk acceptance.

---

Template: label quality and authority

Label governance rules:

• High and critical cases require at least one business SME and one risk/compliance reviewer.
• Label changes require versioning and impact analysis on historical runs.
• A case with open label conflict can be used for exploration but not as a release blocker.
• Synthetic cases need both realism review and expected-behavior review.
• A label can expire when policy, product, workflow or customer communication rules change.

---

Template: promotion gate

Promotion decisions:

---

Template: evidence packet

Evidence packet rule:

If a dataset result influences a release decision, its manifest, lineage, labels, run result and approval must be retained together.

---

PM/BA/architecture questions

PM questions

BA / CBAP questions

Architecture questions

---

Release checklist

Use this checklist when an AI release depends on eval dataset evidence.

Release decision language:

---

Executive narrative

One-page storyline

We are not approving this AI release only because model quality improved.
We are approving it because the approved use case was tested against governed datasets:

1. Golden set protected core customer and employee journeys.
2. Challenge set tested complex financial retail edge cases.
3. Adversarial set tested injection, leakage and excessive agency risks.
4. Regression set verified that prior incidents and defects did not return.
5. Synthetic and production-derived cases expanded coverage while respecting privacy and retention.

Each case has lineage, label authority, expected behavior, severity and dataset membership.
The release run is tied to immutable dataset versions and component versions.
Open gaps are documented with owner, expiry and monitoring.
Production complaints, overrides and incidents will feed the next dataset cycle.

Management message

For executives:

The dataset lifecycle is the control system behind AI release quality. It gives us a defensible way to scale AI without relying on anecdotal demos or average scores. We can show which customer journeys and risk scenarios were covered, which failures block release, where gaps remain, and how production evidence improves the next version.

For risk and audit:

The evidence packet links dataset inventory, lineage, labels, privacy decisions, eval runs, exceptions and approvals. This allows reviewers to reconstruct why a release was approved and whether controls operated as designed.

For product and architecture:

The test data factory makes AI delivery faster over time. Once cases, labels and gates are reusable, each model, prompt, RAG, tool or workflow change can be assessed with a consistent decision framework.

---

Interview drills

Drill 1: Explain golden set vs regression set

Strong answer:

Golden set protects stable core behavior and allows comparison across versions. Regression set protects against known failures returning, often sourced from incidents, defects, complaints or production overrides. A case can be important to both, but the governance question is different: golden asks “does the system still perform approved core tasks,” while regression asks “did we reintroduce a failure we already learned from.”

Drill 2: Synthetic vs real cases

Strong answer:

Real cases provide operational realism, but they carry privacy, retention, access and sampling-bias issues. Synthetic cases help cover rare, adversarial and combinatorial scenarios, but they need realism checks and a reliable oracle. I would use both: real and production-derived samples for distribution and noise, synthetic and mutated samples for low-frequency and high-risk coverage.

Drill 3: What would block release?

Strong answer:

I would block release for critical failures such as unauthorized tool action, PII leakage, wrong customer-facing credit or payment advice, under-escalation of high-risk AML or complaint cases, unresolved label conflict in a release blocker, missing privacy approval for real data, or insufficient coverage of a high-impact slice in the approved rollout scope.

Drill 4: How do you make it audit-ready?

Strong answer:

I would retain dataset manifest, version hash, source lineage, privacy decision, label authority log, coverage matrix, eval run report, slice failures, exceptions, approvals and monitoring trigger in one evidence packet. The key is not having documents; it is being able to reconstruct which dataset version supported which release decision and who accepted which residual risk.

Drill 5: How does this apply to an agent?

Strong answer:

For an agent, dataset cases must include tool authority, approval requirement, tool arguments, expected side effects and rollback expectation. The adversarial set should test prompt injection, excessive agency and data leakage. The regression set should include any previous unauthorized action or incorrect workflow update. Agent release should not rely on natural-language answer quality alone.

Drill 6: What would you ask in a CTO interview?

Strong answer:

I would ask whether eval datasets are treated as platform assets: versioned, access-controlled, tied to release gates and connected to production observability. Then I would ask how dataset impact analysis works when model, prompt, RAG, tool or workflow changes. If the answer is “teams keep their own spreadsheets,” the roadmap should include a case registry, lineage graph, promotion gates and automated evidence packet.

---

Source anchors