Golden Set

AI 产品评估的真值数据集，由 PM 主导构建的高质量标注样本集合，用于持续验证模型表现与业务目标的对齐度。

简介

Golden Set（黄金数据集）是 AI 产品评估体系的基石，是一组经过精心设计和人工标注的高质量测试样本集合。与传统软件的单元测试类似，Golden Set 为 AI 产品提供了可重复、可量化的评估标准。它不仅包含理想化的正常案例，更重要的是涵盖了边缘案例、对抗样本和业务红线场景，确保模型在真实业务环境中的稳定性和可靠性。

Golden Set 的核心价值在于：它是技术团队、业务团队、产品团队统一评估标准的桥梁。当算法团队说”准确率提升了 3%“，而业务团队抱怨”客诉反而增加了”，问题往往出在评估体系——算法用的是理想化测试集，业务面对的是真实噪音数据。Golden Set 通过引入真实场景的复杂性，让所有团队基于同一份”真相”对话。

关键信息

构建主体：必须由产品经理（PM）主导，不可外包给算法团队或测试团队。PM 最了解业务红线、用户体验边界和商业目标，只有 PM 能确保 Golden Set 真正反映产品成功的定义。

样本配比：

• 60% 常规样本：覆盖日常高频场景，验证模型基础能力
• 40% 边缘/对抗样本：覆盖异常情况、边界条件、恶意输入、业务红线触发场景

样本来源：必须来自线上真实数据的噪音，而不是工程师想象的”理想问答”。包括：

• 用户实际输入的拼写错误、语法混乱、多义词歧义
• 跨语言混杂、方言俚语、网络热梗
• 恶意诱导、越权请求、隐私探测
• 业务规则冲突、合规红线触碰

标注规则：PM 需要明确定义什么是”好”和”坏”：

• 事实性错误（幻觉、编造数据）
• 过度承诺（超出系统能力范围的保证）
• 机械回复（模板化输出、缺乏针对性）
• 风险越权（触碰业务红线、合规问题）
• 体验缺陷（没有边界提示、缺少置信度标注、无法溯源）

核心特性

1. 业务对齐而非算法对齐

传统算法评估追求”模型准确率”，但业务成功的定义往往不是准确率最高。例如：

• 客服场景：过度承诺的”100% 满意”回复会导致后续投诉，不如谨慎的”我帮您确认一下”
• 风控场景：一个漏检的高风险交易可能造成百万损失，准确率 99% 但召回率 80% 是不可接受的
• 推荐场景：推荐准确但触碰合规红线（如向未成年人推荐成人内容），业务价值为零

Golden Set 的标注规则必须直接映射到业务目标：一次通过率、赔付率、转化率、留存率、合规通过率等北极星指标。

2. 红线一票否决机制

在 Golden Set 中，业务红线样本（如合规违规、隐私泄露、过度承诺）应设置为”一票否决”：无论模型在其他样本上表现多好，只要触发任何一个红线样本，整体评分记为不合格。

这种机制倒逼团队优先解决”不能犯的错误”，而不是盲目追求平均准确率。某跨境物流助手案例：模型推荐准确率 95%，但因为没把”禁限运规则冲突”设为红线，导致大量扣关投诉。改进方法是在 Golden Set 中加入 50 个禁限运冲突样本，任何一个触发即判定为失败，两周后投诉率明显下降。

3. 持续演进的活数据集

Golden Set 不是一次性构建完成的静态数据集，而是随着业务发展持续演进的活数据集：

• 每次线上事故后，将触发问题的真实输入加入 Golden Set
• 每个季度根据用户反馈热点，补充新的边缘样本
• 业务规则变更时，更新对应的标注标准

Golden Set 的版本管理和变更记录，本身就是产品演进的知识沉淀。

4. 跨部门协作的共同语言

Golden Set 让技术、业务、产品团队基于同一套标准对话：

• 算法团队：在 Golden Set 上跑评估，用数据说话而非主观判断
• 业务团队：参与标注规则制定，确保评估标准反映真实痛点
• 产品团队：通过 Golden Set 量化产品改进的效果，对比版本间差异

当所有团队都在同一份 Golden Set 上跑分时，“效果好不好”从争论变成了可验证的事实。

不同素材中的观点

2026-03-30-ai-pm-core-knowledge：PM 必须主导，60/40 配比，对抗样本来自真实噪音

这篇素材强调三个关键点：

1. PM 主导不可外包：Golden Set 的构建必须由产品经理主导，因为只有 PM 最清楚什么是业务红线、什么是可接受的风险边界。算法团队关注模型指标，测试团队关注功能覆盖，只有 PM 关注业务结果。
2. 60% 常规 + 40% 边缘对抗：这个配比不是随意定的。60% 常规样本确保基础能力稳定，40% 边缘/对抗样本防止模型在异常情况下崩溃。很多团队的错误是 Golden Set 里 90% 都是”完美问答”，导致模型在实验室里表现完美，一上线就翻车。
3. 样本来自线上真实噪音：不是工程师坐在会议室里脑暴出来的”用户可能会这么问”，而是从线上日志、客诉记录、异常报警中提取的真实输入。真实数据里充满了拼写错误、语法混乱、多义词歧义、恶意诱导，这些才是模型上线后要面对的真实挑战。

素材还提到了一个反面案例：某跨境物流助手项目，模型”推荐准确率”看上去很高，但仍有大量扣关投诉。原因是评估只看了价格和时效，没把”禁限运规则冲突”设成红线。改法很简单：把”禁限运冲突率”纳入 R 维度一票否决，同时在 U 维度要求系统必须给出边界提示（如”包含电池请走特货通道”）。这个案例说明：Golden Set 的标注规则必须直接映射到业务红线。

实用信息

如何构建第一版 Golden Set

第一步：定义业务红线（1-2 小时 PM 独立完成）

• 列出所有”绝对不能犯的错误”：合规违规、隐私泄露、过度承诺、误导性建议等
• 为每个红线定义判定标准（什么情况算触发）
• 这些红线样本将占 Golden Set 的 10-15%

第二步：采集真实输入（1 周，协同业务/客服/测试团队）

• 从线上日志中随机抽取 1000 条真实用户输入
• 从客诉记录中提取所有导致投诉的输入
• 从压测/渗透测试中提取对抗样本（恶意输入、边界条件）
• 从业务规则文档中提取规则冲突场景

第三步：分层标注（2-3 天，PM 主导 + 业务专家参与）

• 将采集的输入按业务场景分类（常规/边缘/对抗）
• 为每条输入标注”理想输出”或”可接受输出范围”
• 标注判定规则：什么情况算正确、什么情况算错误、什么情况算红线触发
• 确保 60% 常规 + 30% 边缘 + 10% 红线的配比

第四步：版本管理（持续维护）

• 将 Golden Set 纳入版本控制（Git）
• 每次线上事故后，将触发问题的输入加入 Golden Set
• 每季度 review 一次，剔除过时样本、补充新场景
• 记录每个样本的来源、添加原因、标注依据

常见错误

❌ 错误 1：算法团队自己构建 Golden Set 算法团队倾向于构建”能让模型得高分”的测试集，而不是”能反映业务成功”的测试集。结果是模型在 Golden Set 上 95 分，但业务指标不升反降。

✅ 正确做法：PM 主导标注规则，算法团队负责跑评估。PM 不需要懂算法细节，但必须清楚”什么样的输出是业务可接受的”。

❌ 错误 2：只包含正常样本，缺少边缘/对抗样本 很多团队的 Golden Set 看起来像教科书里的”完美问答”，用户永远用标准普通话提问、输入格式完美、意图清晰明确。这种 Golden Set 对提升真实场景的鲁棒性毫无帮助。

✅ 正确做法：至少 40% 边缘/对抗样本。包括拼写错误、语法混乱、多义词歧义、恶意诱导、跨语言混杂、业务规则冲突等。

❌ 错误 3：一次性构建后不再更新 业务在变化、用户行为在变化、产品规则在变化，Golden Set 如果不更新就会逐渐失去代表性。

✅ 正确做法：将 Golden Set 维护纳入产品迭代流程。每次 Sprint 结束时 review 一次，每次线上事故后立即补充对应样本。

与 R-U-B 计分板的配合

Golden Set 是”测什么”，R-U-B 计分板 是”怎么评分”。两者配合使用：

• Golden Set 中的每个样本，在 R-U-B 三个维度上都有明确的评分标准
• R 维度（业务红线）：Golden Set 中标记为”红线样本”的，任何一个触发即判定为 0 分
• U 维度（用户体验）：Golden Set 中标注了是否需要边界提示、置信度标注、溯源依据
• B 维度（商业指标）：Golden Set 的整体通过率直接映射到业务北极星指标

工具推荐

• 标注工具：Label Studio、Prodigy（支持自定义标注规则和多人协作）
• 版本管理：Git + DVC（Data Version Control，专门用于数据集版本管理）
• 评估自动化：结合 LLM-as-a-Judge，用更强模型按 Golden Set 的标注规则自动评分
• 监控看板：将 Golden Set 通过率作为关键指标，纳入产品监控面板

相关页面

• R-U-B 计分板：Golden Set 是”测什么”，R-U-B 是”怎么评分”
• LLM-as-a-Judge：用 AI 自动化 Golden Set 评估，从周级提速到小时级
• AI产品经理工作流：Golden Set 构建是 AI PM 核心工作流的一部分
• HITL：Golden Set 的标注过程本身就是 Human-in-the-Loop