大模型评测集如何构建才可靠？
简化版
可靠评测集首先要代表真实任务，而不是随手收集“看起来困难”的问题。应从线上分布、业务关键路径、历史失败和安全边界中分层抽样，明确输入、期望行为、评分规则和严重度。
数据要去重、脱敏并隔离训练集；主观任务需要多标注员和仲裁，客观任务优先使用可执行判定。最终不仅保存问题与答案，还要保存来源、版本、标签、评分器和变更记录，防止评测集随着产品迭代失真。
评测集不是一批静态题目，而是对“产品应该如何表现”的可执行契约。
详细版
一个完整样本至少包含：
id: support_refund_0042
input: "订单已发货还能退款吗？"
context_version: policy_2026_09
expected_behavior: "说明条件，并引用现行政策"
slice: [refund, post_shipment, zh-CN]
severity: high
scorer: grounded_rubric_v3
source: anonymized_production若线上流量中普通问答占 80%、工具任务占 15%、高风险任务占 5%，不能机械照比例抽样，否则只有 50 条高风险样本的 1000 条评测集难以估计低频严重错误。可同时维护“代表性集”和“压力集”，分别回答总体体验与最坏风险。
| 子集 | 样本来源 | 主要用途 |
|---|---|---|
| 代表性集 | 线上分层随机采样 | 估计总体效果 |
| 能力集 | 产品需求与标准任务 | 衡量核心能力 |
| 挑战集 | 专家构造、对抗生成 | 暴露边界失败 |
| 安全集 | 政策风险与越狱样本 | 验证防线 |
| 回归集 | 历史线上事故 | 防止旧问题复发 |
完整版教学
1. 从决策问题反推评测目标
先明确评测要支持什么决策：选基础模型、验证 Prompt 改动、决定是否发布，还是监控线上漂移。不同决策需要不同样本与统计精度。
若目标是发布客服助手，核心指标应围绕政策正确、引用、工具成功和拒答边界，而不是只使用通用知识 Benchmark。
2. 定义任务边界和评分单位
明确输入中有哪些上下文、模型允许使用哪些工具、输出格式和不可接受行为。评分单位可以是整段回答、原子断言、工具步骤或完整会话。
长答案只给一个总分不利于诊断。可拆成事实正确、完整性、引用、风格与安全，每项有独立 Rubric。
3. 样本应从哪里来
线上真实请求最能代表用户，但会包含隐私和历史系统偏差；专家题能覆盖关键规则，却可能过于理想化；合成数据便宜，但会继承生成模型模式。
最佳实践是混合来源并记录 provenance。任何外部或合成样本都要抽样人工核验，不能把模型生成的答案直接当真值。
4. 为什么需要分层抽样
总体随机样本会被高频简单请求占满。应按语言、任务、用户群、风险、长度、工具类型和难度分层，再为关键稀有层过采样。
| 目标 | 抽样方式 | 汇总方式 |
|---|---|---|
| 线上总体质量 | 按真实流量比例 | 使用流量权重 |
| 高风险可靠性 | 高风险过采样 | 单独报告，不稀释 |
| 版本回归 | 固定历史失败 | 等权或严重度加权 |
过采样后若要估计线上总体值，必须使用原分布权重恢复，而不是直接平均。
5. 样本量如何决定
样本量取决于指标方差和希望检测的最小差异。对二项通过率，标准误近似为：
SE = √(p(1-p)/n)
95% CI ≈ p ± 1.96 × SE当 p=0.8、n=100 时，区间半宽约 7.8 个百分点；n=1000 时约 2.5 个百分点。只有几十条样本很难证明 1% 的提升。
6. 如何编写标注规范
Rubric 要包含正例、反例、边界例和优先级。避免“回答是否良好”这类无法复现的描述，应写清哪些事实必须出现、哪些错误一票否决。
如果两位合格标注员长期无法一致，首先应检查任务定义和 Rubric，而不是简单要求他们“更认真”。
主观任务使用 2～3 人独立标注并仲裁，定期计算一致性；争议样本进入指南更新循环。
7. 真值应该怎样保存
开放式任务不一定有唯一参考答案。可保存必需事实、允许变体、禁止内容和证据来源，而不只是单段 Reference Text。
政策和知识会变化，真值必须关联版本和有效期。过期参考答案会把正确的新模型判错。
8. 如何避免数据泄漏和污染
评测样本不得进入微调、Prompt 示例或检索索引。公开 Benchmark 可能已出现在预训练数据中，应准备私有保留集和新鲜时间切片。
使用语义近重复检测，而不仅是字符串哈希。将同一模板改几个实体后分别放入训练和测试，仍会造成模板泄漏。
9. 多轮和工具任务如何评测
多轮任务要保存初始状态、用户模拟器行为、工具 Mock/沙箱和结束条件。仅比较最终文本，可能漏掉中间越权调用或错误副作用。
initial state -> conversation -> tool trace -> final state理想评分同时验证最终状态、步骤合法性、调用成本和是否需要人工接管。
10. 自动评分器如何校准
规则、单元测试和 Schema 校验优先用于可客观判断的部分。LLM Judge 适合语义和风格，但要与人工黄金集比较，检查位置偏差、长度偏差和自偏好。
评分器版本也是评测协议的一部分。更换 Judge 后应重新跑历史版本，避免把评分器漂移误当模型提升。
11. 数据集版本与维护机制
每个样本要有稳定 ID、来源、创建时间、标签和修改原因。新增线上事故时进入候选池，经去重、标注和审核后再进入正式集。
可维护固定 Core Set 用于长期趋势，Rolling Set 反映近期流量，Challenge Set 捕获新攻击。三者不能混成一个不可解释总分。
12. 发布前如何检查评测集本身
检查重复率、标签分布、敏感数据、答案有效期、标注一致性和评分器覆盖。抽样让领域专家从零复核，确认没有把旧系统输出当黄金答案。
还应对样本做“可行动性”审查：失败后团队是否知道该改数据、Prompt、模型、工具还是策略；无法诊断的集合价值有限。
13. 常见误区与追问
- 误区：题目越难，评测集越好。 脱离真实分布的难题不能代表产品质量。
- 误区：样本越多越可靠。 大量重复、错误标注只会让偏差更稳定。
- 误区：每题必须有唯一标准答案。 开放任务更适合事实清单和 Rubric。
- 误区：线上随机采样足够覆盖安全风险。 低频高危事件必须过采样并单独报告。
- 误区：评测集建完后不应再变化。 知识、产品和攻击都会变化，需要版本化维护。
- 追问：如何兼顾趋势可比与新鲜度？ 固定 Core Set，加独立 Rolling/Challenge Set。
- 追问：合成样本能否使用？ 可以扩大覆盖，但必须记录来源、去重并人工抽检真值。
14. 加强记忆
- 先定决策：评测为选型、发布还是监控服务。
- 四类来源：真实流量、专家设计、合成挑战、历史事故。
- 分层抽样：总体按流量，高风险单独过采样报告。
- 真值可审计：Rubric、证据、版本、有效期缺一不可。
- 持续维护：固定 Core 保趋势，Rolling 保新鲜，Challenge 保边界。