Golden Dataset：把“感觉不错”变成可回归样例

在开发企业级 AI 应用、Agent 或 RAG 知识库系统时，开发者常常陷入一种“推测性开发”的怪圈：修改了一个提示词，测试了三个自己能想到的问题，感觉回答“比昨天好多了”，于是直接发布上线；然而，线上用户很快反馈，之前回答正确的问题现在全部报错，系统产生严重的 regression（退化）。

要打破这种“感觉不错”的研发困境，核心是建立一套能够量化、可自动回归的黄金数据集（Golden Dataset）。本指南将带你从零开始，为一个企业级知识库问答及工具调用系统设计一个包含 40 条高质量样例的 Golden Dataset 架构、标注规则与更新机制。

为什么你的评测集总是在给模型“发好人卡”？

许多团队在开始做模型评测时，最容易犯的错误就是“堆砌简单样例”。他们从客服记录或 QA 文档中直接复制几十个用户最常问的、结构简单的标准问题。这些问题通常只涉及单一事实检索，例如“公司年假有几天？”、“研发部经理是谁？”。

这种缺乏噪声和干扰的“送分题”评测集，会导致评估结果产生严重的虚高偏置。OpenAI 在其关于 Evaluation best practices 的官方指南中明确提出，设计高质量评测集时必须从清晰的目标定义开始，并在构建数据集时逐步增加测试样例的复杂度，引入多样化的边缘场景。如果评测集无法模拟真实生产环境中脏数据、多文档冲突、提问含糊不清的现状，那么这个评测集就沦为了模型安全区里的“好人卡生成器”。一旦模型升级或提示词调整，哪怕评测分数依然是 100 分，线上真实表现也会一落千丈。

要让评测集具备真正的“退化拦截能力”，你必须把目光投向那些模型容易犯错、容易混淆的边界地带。

黄金数据集的架构设计：从 Schema 开始

一个合格的 Golden Dataset 不仅仅是“Query-Answer”的简单对齐，它必须包含用于辅助定位故障（检索失败还是生成失败）、评估安全合规性、以及规范工具调用的多维字段。以下是我们为企业级 RAG 与 Agent 系统设计的评测 Schema，采用标准的 JSON Schema 进行规范。

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "GoldenDatasetSchema",
  "type": "object",
  "properties": {
    "version": {
      "type": "string",
      "description": "语义化版本号，例如 v1.1.0"
    },
    "updated_at": {
      "type": "string",
      "format": "date-time"
    },
    "test_cases": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["id", "category", "query", "expected_output", "grading_criteria"],
        "properties": {
          "id": {
            "type": "string",
            "description": "唯一标识符，格式如 CASE-001"
          },
          "category": {
            "type": "string",
            "enum": ["factual_direct", "multi_doc_synthesis", "ambiguous_query", "negative_unanswerable", "security_jailbreak", "tool_calling"]
          },
          "query": {
            "type": "string",
            "description": "用户的原始输入问题"
          },
          "golden_contexts": {
            "type": "array",
            "items": {
              "type": "object",
              "required": ["doc_id", "content"],
              "properties": {
                "doc_id": {"type": "string"},
                "content": {"type": "string"}
              }
            },
            "description": "标准的、被标注人员确认过的参考文档片段。若为空则表示此题无可参考上下文。"
          },
          "expected_output": {
            "type": "string",
            "description": "预期的黄金标准回复内容（Ground Truth）"
          },
          "expected_tool_calls": {
            "type": "array",
            "items": {
              "type": "object",
              "required": ["tool_name", "parameters"],
              "properties": {
                "tool_name": {"type": "string"},
                "parameters": {"type": "object"}
              }
            },
            "description": "如果是工具调用场景，模型应该调用的工具名称及核心参数"
          },
          "grading_criteria": {
            "type": "object",
            "required": ["method"],
            "properties": {
              "method": {
                "type": "string",
                "enum":["exact_match", "substring", "llm_judge", "mcp_state_check"]
              },
              "rubric": {
                "type": "string",
                "description": "针对 llm_judge 的细分评分准则，或 substring 的关键字列表"
              }
            }
          },
          "metadata": {
            "type": "object",
            "properties": {
              "difficulty": {"type": "string", "enum": ["easy", "medium", "hard"]},
              "owner": {"type": "string"},
              "source_log_id": {"type": "string", "description": "如果是线上真实报错提取，记录原始日志 ID"}
            }
          }
        }
      }
    }
  },
  "required": ["version", "updated_at", "test_cases"]
}

在落地此 Schema 时，有一条核心工程取舍法则：如果你的问答系统包含敏感信息或动态工具调用，应该在 Schema 中显式设计 golden_contexts 与 expected_tool_calls 字段而不要仅依赖静态 ground truth，因为只有显式校验上下文来源与中间工具调用行为，才能在模型产生幻觉或调用链出错时，精准定位是检索阶段失效、工具路由失效还是推理生成阶段失效。

拒绝“简单好答”：如何采集和构造能暴露失败的 40 条核心样例

为了构建一个真正能够拦截线上故障的 40 条核心评测集，我们不能依赖人工随意拍脑袋编写，而是需要按照业务场景的漏洞特征，将这 40 条样例划分到不同的测试维度（建议配比：10 条直接事实、10 条多文档合成、8 条边界/含糊查询、6 条负样例、3 条安全防护、3 条工具调用）。

以下是三类最容易暴露 AI 系统缺陷的样例构造方法：

1. 跨文档合成与冲突解决样例（Multi-doc Synthesis）

真实业务环境中，一个问题的答案往往分散在不同的文档甚至是互相冲突的文档中。例如，员工提问：“2026年研发部的差旅标准是什么？”。而在知识库中存在两份文档：

• DOC-001：《公司通用差旅管理规定 v2.0》（2025年发布），写着“研发部国内出差标准为 400 元/天”。
• DOC-002：《研发部差旅细则修正案》（2026年1月发布），写着“自2026年起，研发部出差标准调整为 500 元/天”。

模型需要自动识别出时效性，合并两份文档的信息，并采信最新的标准。如果模型直接输出了 400 元/天，就说明它不具备处理文档冲突与时效排序的能力。这种样例在 40 条数据中必须占到 20% 以上。

2. 负样例与“可回答性”边界（Negative/Unanswerable Cases）

优秀的知识库系统不仅要“懂得多”，更要学会“优雅地拒绝”。我们需要设计一部分在当前检索知识库中完全找不到答案的问题，测试系统是否会瞎编。例如，用户提问：“我们公司支持太空旅行意外险的报销吗？”。 如果输入包含不相关的干扰文档，模型必须能够在输出中明确拒绝回答或仅依赖可靠文档，除非这些干扰文档经过了安全沙箱的严格过滤，否则直接采用模型默认输出会导致严重的安全外泄或幻觉传播。我们在评测集里要明确要求，对于无匹配上下文的问题，模型的 expected_output 必须符合统一的拒绝句式（例如：“抱歉，在现有公司文档中未找到关于……的内容”）。

3. 用户表达含糊与指代消解（Ambiguous Queries）

用户不会像机器一样规范地提问。他们会输入：“那个关于报销的表格在哪里下载？”。这里的“那个”指代什么？如果系统没有结合对话历史或进行用户澄清，直接丢出一个通用的报销流程，就会造成极差的用户体验。我们在设计这类评测时，应当模拟两轮以上的对话：

• Round 1:
  • User: “那个关于报销的表格在哪里下载？”
  • System: “请问您指的是‘差旅报销单’还是‘通用日常报销单’？”
• Round 2:
  • User: “差旅的那个。”
  • Expected Output: 提供差旅报销单的准确下载链接，且 expected_tool_calls 指向正确的知识库查询工具。

注入外部上下文：在 MCP 与多工具协同下的 Golden Set 设计

当 AI 应用进化到 Agent 阶段时，它不再仅仅进行 RAG 检索，而是通过诸如 Model Context Protocol (MCP) 等协议与外部数据库、Slack、GitHub 或内部系统进行实时交互。

Model Context Protocol 官方文档在介绍其架构时明确指出，MCP 作为连接外部工具、数据和 workflow 的协议边界，其下游的 MCP server 和工具返回结果是不默认可信的。这意味着，在 Agent 的评测设计中，我们不能只看最终的文字输出，必须对工具调用的中间状态和入参规范进行双重拦截。

案例分析：通过 MCP 查询数据库的 Agent 评测设计

假设我们有一个 MCP 客户端，支持模型调用一个名为 get_employee_salary 的 MCP 工具来查询员工薪资。如果用户提问：“帮我查一下张三和李四的薪水，并对比一下。”

在 Golden Dataset 中，我们必须这样定义这个样例的预期执行流：

{
  "id": "CASE-038",
  "category": "tool_calling",
  "query": "帮我查一下张三和李四的薪水，并对比一下。",
  "expected_tool_calls": [
    {
      "tool_name": "get_employee_salary",
      "parameters": { "employee_name": "张三" }
    },
    {
      "tool_name": "get_employee_salary",
      "parameters": { "employee_name": "李四" }
    }
  ],
  "grading_criteria": {
    "method": "mcp_state_check",
    "rubric": "必须依次调用 get_employee_salary 工具两次，且入参必须精准提取出 '张三' 和 '李四'。禁止在单次调用中合并两个名字，因为底层 API 仅支持单人查询。"
  }
}

在 Harness 执行此测试时，Harness 会 mock 掉实际的数据库 MCP 接口，返回设定好的 mock 数据，并验证模型的 Tool Call 序列是否与 expected_tool_calls 完全匹配。这能有效防止模型在升级后产生“直接编造一个对比结果”或“错误合并工具参数”的退化行为。

黄金数据集的版本化控制与动态更新策略

一个静态不变的 Golden Dataset 会像过期的软件一样迅速失去价值。随着业务文档的更新、新功能的上线，评测集必须进入版本控制系统（Git），与应用代码、提示词工程同等对待。下面是推荐的版本与更新规范：

[ 生产/灰度运行发现报错 ]
         │
         ▼
[ 判定是否为新边界场景? ] ──( 否 )──> [ 忽略或作为普通日志归档 ]
         │
        (是)
         ▼
[ 提交 Merge Request ] ──> [ 标注人员修订：添加 ground truth & schema 校验 ]
                                              │
                                              ▼
                                [ 运行回归测试，验证未对旧样例造成 regression ]
                                              │
                                              ▼
                                [ 合并至主分支，递增 Golden Set 版本号 ]

语义化版本规范（Semantic Versioning for Dataset）

• PATCH 版本变更（如 v1.0.1）：修正了现有样例中的错别字、微调了 expected_output 的表述、或者细化了 rubric，但不改变原有的测试逻辑。
• MINOR 版本变更（如 v1.1.0）：在原分类下新增了测试样例（例如从 40 条扩充到 45 条），或者为现有样例增加了新的测试维度（如补充了 expected_tool_calls）。
• MAJOR 版本变更（如 v2.0.0）：业务逻辑发生颠覆性改变。例如，公司整体下线了某项业务，导致原有的 10 条问答全部变为“负样例”（需要模型回答拒绝）。此时需要大版本重构。

在团队实操中，如果需要引入新的模型进行评测，应该首先使用基线数据集跑出一条 benchmark，不要直接修改现有的测试样例，因为只有保持黄金数据集在版本迭代中的静态不变性，才能在多模型横向对比中获得公平且可复现的量化指标。

标注质量的守护：减少 Judge 偏差与人工干预规范

有了评测集后，如何判断模型的输出是否合格？Anthropic 的 Define success criteria and build evaluations 强调了针对测试用例建立清晰成功标准的重要性，指出建立这些标准是迭代提示词和模型的基础。

在实践中，我们通常采用 LLM-as-a-judge（大模型作为裁判）来评估复杂的生成式回答。为了防止作为 Judge 的大模型产生偏置（如偏向于更长的回答、偏向于自己生成的格式），我们必须在 grading_criteria.rubric 中定义极其精确的、无歧义的评分细则。

Rubric 编写范例：

对于跨文档合成样例，不要让 Judge 宽泛地判断“回答是否准确”，而应当给出硬性事实检查点：

[评分准则 (Rubric)]
请充当严格的质量审计员。检查待评测的模型输出是否完全满足以下三个条件：
1. 必须明确指出 2026 年最新的研发部差旅标准是 500 元/天。
2. 必须提及该标准来自于《研发部差旅细则修正案》。
3. 如果回答中提及了旧的标准（400 元/天），必须明确说明该标准已失效。
若三个条件全部满足，给 1 分；若缺少任意一条，给 0 分。

通过将模糊的“语义相似度”转化为“关键事实检查清单”（Fact Checklist），可以使自动化 Harness 跑出的结果与人工专业标注的一致性提升到极高水平。

动手实践：构建你的第一个 40 条企业级问答评测集并进行自测验收

现在，你需要亲自动手为你当前的 AI 知识库系统，定制一份包含至少 40 条样例的 Golden Dataset，并建立基本的回归测试。以下是你的具体交付物要求与自测验收步骤：

本课交付物清单

1. dataset_schema.json：符合本指南定义的 JSON Schema，包含完整的 category、golden_contexts、expected_tool_calls 等关键字段。
2. golden_dataset_v1.0.0.json：一个包含实际 40 条测试样例 的数据集文件，严格按照 Schema 编写。其中必须包含：
   • 不少于 10 条的多文档合成与冲突解决样例；
   • 不少于 6 条的负样例（模型必须拒绝回答）；
   • 不少于 3 条模拟 MCP 外部工具调用的结构化校验样例。
3. grading_rules.md：针对这 40 条样例中，所有标注为 llm_judge 的用例，编写出其对应的、包含 Fact Checklist 的细化 Rubric。

自测验收 checklist

• 你的评测集是否包含了至少 3 条明确要求拒绝回答的负样例？
• 所有的 id 字段是否保持了唯一性且格式统一（如 CASE-001 到 CASE-040）？
• 是否有至少 2 个样例模拟了用户输入含糊、需要结合 context 才能消除歧义的真实场景？
• 你的 JSON 文件是否能通过你编写的 JSON Schema 的本地格式校验？（推荐使用 python 的 jsonschema 库或 VS Code 插件进行校验）

来源、复核与时效说明

本指南的技术方案与设计原则基于以下权威来源：

1. OpenAI - Evaluation best practices (访问于 2026-05-28)：指导了我们如何从定义目标开始，系统化地设计复杂度递增的数据集，避免评测集陷入“简单样例过拟合”的误区。
2. Anthropic - Define success criteria and build evaluations (访问于 2026-05-28)：指导了如何建立客观的成功标准（Grading Criteria）以支撑提示词与模型的持续回归迭代。
3. Model Context Protocol (MCP) 官方指南 (访问于 2026-05-28)：规范了模型与外部工具、上下文服务器交互的信任边界，支撑了我们在 Golden Set 中引入 expected_tool_calls 和 mock 校验的设计判断。

未来复核触发条件：

• 当 Model Context Protocol 发布破坏性协议变更、改变 Tool Call 握手格式时，需更新 expected_tool_calls 的 schema 设计。
• 当 OpenAI 或 Anthropic 推出全新的官方自动化 Evals 框架、或提供标准化的 SDK 时，需复核本指南中的 JSON Schema 是否需要进行格式兼容性升级。

GoldenDataset：把“感觉不错”变成可回归样例：把判断写进 Harness 证据链

如果 harness 没有数据、阈值、失败样例和审计轨迹，它就不能支撑发布决策。本课交付物是 一个 40 条样例的 dataset schema、标注规则和版本策略，它必须能被复跑、复核、追踪和复盘。

如果 GoldenDataset：把“ 还没有对应的输入样例，先不要讨论自动化覆盖率，因为没有样例就无法判断 harness 是否真的抓住问题。 如果一次评测失败会影响发布，应该保留失败输入、模型输出、工具轨迹和判分理由，否则团队只能凭记忆争论。 如果你准备把某个结果自动放行，必须先写清人工复核的例外条件，只有例外条件明确时，门禁才不会变成新的风险源。

如果 judge 给出高分但用户仍然不满意，要检查 rubric 是否漏了业务目标。围绕 GoldenDataset：把“感觉 做排查时，记录步骤、样例、指标、风险、修复动作和复测结果。

Anthropic 的《Define success criteria and build evaluations》说明：支撑成功标准、测试样例、评测开发和提示词/模型迭代。；这意味着 GoldenDataset：把“ 要把来源转成可执行断言。Model Context Protocol 的《What is MCP?》提醒：支撑 AI 应用连接外部工具、数据和 workflow 的协议边界，以及 MCP server 不默认可信的判断。；因此本课必须写清自动判断和人工判断的边界。OpenAI 的《Evaluation best practices》提供的证据是：支撑目标定义、数据集、指标、连续评测、人审、judge 偏差和 eval harness 设计。；所以当前结论按 2026-05-28 的来源状态使用。

复核触发条件要具体：如果模型 API/SDK、评测工具版本、Agent 框架、RAG 指标、安全规范、合规政策、平台 release/changelog 或关键来源页面变化，需要重新运行本课样例并更新 harness。

练习验收：把 GoldenDataset：把“感觉 接入一个最小 AI 应用，提交包含输入样例、评测结果、失败诊断、来源证据、人工复核结论和下一步修复动作的记录。缺少任何一项，都标记为 needs_review。