评测集应该怎么构建？

详细解析#

一条样本包含什么#

{
  "id": "order-cancel-023",
  "input": {
    "messages": [{ "role": "user", "content": "昨天买的耳机还没发货，能取消吗？" }],
    "context": { "order_status": "待发货" }
  },
  "expected": {
    "must_include": ["可以取消"],
    "must_call_tools": ["get_order"],
    "must_not_call_tools": ["cancel_order"],
    "rubric": "查询订单状态后告知可以取消，并询问用户是否确认；用户确认之前不能调用取消接口"
  },
  "tags": ["订单", "取消", "需要工具"],
  "source": "线上抽样（已脱敏）"
}

• id：稳定不变，新旧版本才能逐条对比
• input：完整的输入。多轮对话要带上历史，依赖外部数据的要带上当时的上下文
• expected：按任务类型选形式。分类、抽取这类有唯一答案的任务写标准答案；开放生成的任务写评分要点（rubric）和必须包含、不能出现的内容，不要只写一个"标准回答"让输出逐字比对
• tags：场景、难度、来源，用来分组统计

数据从哪来#

上线前没有真实数据时，先用专家编写加合成数据起步；上线后逐步用真实数据补充和替换。

覆盖哪些情况#

• 常见问题：按线上的占比覆盖主要场景
• 边界情况：信息不全需要追问、知识库里没有答案应该拒答、超长输入、多个意图混在一起、中英混杂
• 对抗输入：提示注入、诱导泄露系统提示、诱导越权操作，按类别各准备几条（防御思路见 Prompt 注入）
• 回归样本：修过的每一个 bug 都留一条，防止再次出现

标注和维护#

• 写一份标注指南：什么算正确、什么算部分正确，边界例子怎么判
• 多人标注同一批样本，计算一致率；分歧大的样本讨论后统一，确实有歧义的样本改写或删除
• 业务规则变化时（比如退款政策调整），相关样本的期望输出要同步更新，评测集本身也要做版本管理
• 几十条就能发现明显的问题，人工也看得过来；之后逐步扩充，让每个标签下都有足够的样本
• 线上失败案例 → 脱敏 → 写期望输出 → 加入评测集，形成闭环
• 留出一部分样本作为测试集：平时调 Prompt 只看开发集，定期用测试集验证，防止对评测集过拟合
• 评测样本不能出现在 Prompt 的 few-shot 示例里，也不能放进 RAG 知识库的示例问答里，否则测的是"背答案"

面试官可能追问#

易错点#

• 只收集"正常"的问题，没有边界情况和对抗样本
• 评测样本混进 few-shot 示例或知识库，分数虚高
• 只看总分，不按标签分组，某一类问题的退化被掩盖
• 评测集建好后不再更新，和线上的真实分布越差越远