评测用的 Golden Set 怎么建？

先这样答

建 Golden Set 的第一原则：从真实分布来，不从想象来。最好的来源有三处：线上真实用户任务（脱敏后采样）、客服工单和用户反馈里的问题、面试官式的内部专家随手考的题。自己编的用例只能当补充，因为编的时候会不自觉偏向系统已经做得好的场景。

第二步：场景分桶，保证覆盖。按任务类型（查询、生成、纠错、拒绝）和难度（单步、多步、需澄清）交叉分桶，每桶至少几条。三桶特别容易漏但要刻意补：边界桶（超长输入、混合意图、格式奇葩）、失败桶（知识库没有答案的问题，系统要会说「不知道」而不是硬答）、对抗桶（诱导越权、提示注入；安全要求要进评测集，不是评测集之外的事）。

第三步：标注。每条用例写三样东西：输入（用户问题加必要上下文）、标准答案或答案要点（开放题写「必须覆盖的要点 + 明显不能犯的错」）、评分方式（可自动断言的写断言，开放题写 LLM 裁判的评分细则）。「评分方式」是标注里最有价值也最常被省略的部分：它决定了这条用例能不能被自动化评测消费。

第四步：滚动维护。线上出事故，修完把场景加进集合（事故用例库）；每季度审一次分布，业务变了补新桶；集合本身做版本管理，跨版本的分数对比要注明用的哪个版本。

规模上给个参照：起步 50 到 100 条，覆盖主要桶，就能支撑日常迭代；要区分细微改动，几百条更稳。小而准的集合比大而杂的集合有用，标错的「金标准」会把整个迭代方向带偏。

面试官会怎么追问

• 开放生成类任务怎么定「标准答案」？ 不定唯一答案，定「要点集 + 扣分项」：必须覆盖的要点、事实性红线（哪些说法错了就是错）、格式要求。裁判按这三样打分。
• 标注员之间不一致怎么办？ 先定标注规范、几个人独立标一小批、算一致率、分歧的条目讨论仲裁后更新规范，规范就是这样迭代出来的；跳过这一步直接大规模标注，只会返工。
• Golden Set 会不会过拟合？ 会，长期只对着同一批用例优化，系统就只会应对这批固定用例。缓解：保留一部分不常跑的封存用例定期盲测；核心集合和滚动集合分开。

回答的坑

• 只讲「人工标注一批问答」。分桶策略、评分方式标注、事故回流这三点才是深度所在。
• 忽略失败桶和安全桶。「答不出来的题要答不出」也是被测能力，这点忘了说明评测观不全。