大模型 Golden Set 应该如何维护？

简化版

Golden Set 是经过严格审核、用于发布门禁和长期比较的高可信评测集。它不能无限追加，也不能随意修改；每个样本都应有稳定 ID、来源、Rubric、证据、适用版本和变更记录。

维护上应把固定 Core Set 与滚动更新集分开：Core Set 保证历史趋势可比，Rolling Set 反映最新流量和事故。政策或事实过期时要更新真值并保留旧版本，线上失败进入候选池，经脱敏、去重、标注和复核后再晋级。

Golden Set 的“金”来自可审计的真值和治理流程，不是因为题目长期不变。

详细版

推荐生命周期：

线上失败/专家题/新政策
  -> 候选池
  -> 脱敏与授权检查
  -> 去重、分层与难度审核
  -> 双人标注 + 仲裁
  -> Shadow Set 试运行
  -> Golden Set 正式版本
  -> 定期过期审计与退役

子集	是否稳定	作用	更新频率
Core Golden	高	长期版本趋势	谨慎、低频
Rolling Golden	中	近期真实分布	月/季度
Incident Set	逐步增长	防历史事故复发	事故后
Challenge Set	动态	新攻击与能力边界	持续

若 1000 条 Core Set 每月替换 20%，半年后已不是同一基准，趋势图会失去解释力。应保留固定锚点，并把新增集合单独报告。

完整版教学

一、Golden Set 与普通评测集的区别

普通评测集可以快速迭代和探索；Golden Set 用于关键决策，要求更高的真值可靠性、覆盖说明和版本稳定性。

它通常规模不必最大，但每条错误都可能影响发布决策，因此需要明确责任人和审计记录。

普通集合可以接受临时自动标签，Golden Set 则应能回答“谁在何时依据哪份证据确认了真值”。发布门禁引用它时，还要预先规定失败后的阻断、豁免和复核流程。

二、样本晋级需要哪些条件

候选样本应满足来源合法、已脱敏、不与训练数据重叠、任务定义明确、评分可执行、领域专家认可。只有“这个问题很难”不足以晋级。

对于开放回答，要保存必要事实、禁止错误和证据，而不是仅保存一段参考文本。

三、为什么要保留稳定 ID

稳定 ID 用于追踪同一题在不同模型版本上的表现。修改输入或 Rubric 后应创建新 Revision，而不是静默覆盖。

sample_id: refund_042
revision: 3
valid_from: 2026-09-01
supersedes: refund_042@2
change_reason: policy updated

这样历史报告仍能重现当时使用的真值。

四、Core 与 Rolling 为什么必须分离

Core Set 提供固定坐标系，Rolling Set 捕捉用户分布和知识变化。把二者混在一个总分中，无法判断分数变化来自模型还是题集更新。

报告	回答的问题
Core trend	模型在稳定标准上是否进步
Rolling score	对近期用户请求是否有效
Incident pass	历史严重问题是否复发
Challenge score	新边界和攻击能否防御

五、真值为什么会过期

政策、价格、组织关系和软件接口都会变化。样本要有 valid_until 或定期复核周期，并关联权威来源版本。

过期 Golden Answer 会把新模型的正确回答判错，比没有评测更危险，因为它制造了虚假的确定性。

到期样本可更新 Revision、冻结为历史集或退役，不能直接删除审计痕迹。

六、如何把线上失败回流

线上事故先进入候选池，去掉用户身份和敏感数据，再做语义去重与根因分类。一个事故可生成主样本、边界变体和反事实样本。

但不能每个失败都直接加入 Golden Set，否则集合会偏向当前模型的弱点，失去代表性。应按风险、频率和覆盖缺口评审。

七、如何防止评测污染训练

Golden Set 应与微调数据、Prompt few-shot、RAG 索引和合成数据管道隔离。访问权限与下载日志要可审计。

对外展示时只发布独立示例或模糊统计；若全部题目进入开发人员日常调参，团队会对集合过拟合。

八、去重为什么要做语义级检查

字符串不同不代表任务不同。“订单已发货能否退款”换实体、数字和措辞，仍可能共享同一模板。大量模板重复会让总分看似稳定，实际有效样本量很低。

可结合 MinHash、Embedding 相似度和人工聚类，并在切分 Train/Eval 前以模板簇为单位隔离。

九、标注质量如何持续监控

定期抽取 5%～10% 样本由专家盲复核，统计真值错误率、Rubric 歧义率和标注一致性。争议集中出现时要更新指南。

重要样本应记录仲裁理由。若只保留最终标签，后来无法理解为什么某答案当时被判失败。

十、分数如何应对集合更新

每份报告必须绑定数据集版本。更新前后可在重叠锚点上同时评测，给出 Bridge Report，而不是把两个版本分数直接连接成连续曲线。

如果新增 100 条更难题导致通过率下降，应明确拆分“模型变化”和“集合组成变化”。

十一、何时应该退役样本

样本可能因业务功能下线、政策失效、已公开泄漏、无法可靠评分或与大量题重复而退役。退役不代表从历史仓库删除。

保留状态、原因和最后有效版本，确保旧模型报告仍能被复现和审计。

十二、如何设置维护职责

产品负责人定义业务重要性，领域专家维护真值，评测工程师管理版本与评分器，安全与隐私人员审核高风险样本。任何一方都不应单独静默修改门禁集。

可用变更请求要求评审人、影响分析和回滚方案，并在发布说明中列出样本增删统计。

十三、常见误区与追问

误区：Golden Set 一旦建立就不能变化。 它需要更新，但必须版本化并保留稳定 Core。
误区：线上所有失败都应直接加入。 无筛选回流会导致分布严重偏斜和重复。
误区：只要输入没变，就能覆盖原标签。 真值变化也需要新 Revision 和来源证据。
误区：集合越大越“金”。 可靠性、覆盖和可审计性比数量更重要。
误区：开发团队知道题目不影响评测。 反复针对固定题调参会造成评测过拟合。
追问：怎样兼顾长期趋势和业务变化？ Core 固定，Rolling 独立滚动，并做版本桥接报告。
追问：如何处理政策更新？ 创建新真值版本、设置生效时间，旧版本冻结供历史复现。

十四、加强记忆

四个属性：高可信、可审计、有版本、可复现；四个集合：Core、Rolling、Incident、Challenge 分开报告；准入流程：脱敏、去重、双标、仲裁、试运行。维护重点：真值有效期、污染隔离、线上失败回流；变更原则：稳定 ID，新建 Revision，永不静默覆盖。

项目实战落地

项目里怎么做的

《AI Agentic RAG高级企业知识库平台》的评测集在教程里被称作「尺子」：尺子本身错了，量出来的一切都是错的。项目在三个地方守住这把尺子：

自动生成的标准答案要人工核对。 从文档生成的问答对，标准答案是模型写的，可能看错段落、把相邻的条款张冠李戴。例如文档里「备件保修 6 个月」「随整机更换的备件跟随剩余质保期」「有偿维修保修 3 个月」三条挨在一起，模型很容易串，而且这种错看着特别合理。用例列表上的「看原文」按 reference_chunk_ids 取出来源片段，把问题、标准答案、片段原文摆在一起核对。
点踩来的用例，答案只能人补。 从用户点踩沉淀出来的用例，标准答案留空、默认不参与评测，页面标一个橙色「待补充」。这里刻意不让模型补答案：系统刚刚答错了这个问题，再让同一个模型生成「正确答案」，多半还是错的。
按来源筛出问题。 用例表上的来源字段可以回答三件事：

筛「反馈沉淀」   还有多少条标准答案没补
筛「手工录入」   业务方最关心的那些问题现在跑分怎么样
筛「文档生成」   铺量的那批，分数普遍偏高说明用例太简单

三种来源怎么进评测集，见「RAG 评测集怎么构建？为什么每条用例要标到来源片段？」。

为什么这样取舍

核对放在「看原文」上。 模型写错标准答案的方式是张冠李戴，不对照原文根本发现不了；没有来源片段的用例（手工录入、反馈沉淀）这个按钮是灰的，它们本来就没有来源片段。
正确答案只有懂业务的人知道。 点踩说明系统在这个问题上不可靠，用它来补标准答案，等于让出错的一方给自己出答案。
来源决定用法。 三种来源的用例难度和可信度不一样，混在一起只看总分，会被铺量的简单用例拉高。

面试官还会追问

同一条点踩会不会被重复沉淀成两条用例？项目怎么防止？
选了一个所有用例都处于停用状态的评测集，点「开始评测」会怎样？

学完《AI Agentic RAG高级企业知识库平台》，上面这些追问你都会迎刃而解。

简化版

详细版