Agent 评测体系与评测集构建——美团《评测漫谈》+《评测白皮书 01》笔记

来源

• 《Agent 评测漫谈——由浅入深讲解 Agent 评测》（2026-08-06）：方法论篇，回答”评测是什么、为什么这么做” → 微信原文
• 《Agent 评测白皮书》系列 01：Agent 评测全览（2026-09-10）：落地指南篇，回答”先做什么后做什么、产出物长什么样” → 美团技术博客

本文是研读笔记，重点落在评测集（Eval Set）到底怎么建这件事上。

TL;DR

1. 搭 Agent 的门槛在快速降低，但把 Agent 做好的评测认知仍然稀缺——绝大多数 Agent 项目死于”停在 Demo / 卡在扩量 / 说不清业务价值”，共性是缺少可靠的判断机制。
2. 完备的评测体系 = 四个模块 + 三种能力 + 两条 Loop + 一套资产，其中”一套资产”就是评测集，它是体系真正的长期价值。
3. 评测集的每一行是一个 Task 三元组（问题、参考答案/预期行为、评价标准）。长程 Agent 时代，参考答案从”可逐字比对的字符串”迁移为”对执行过程和最终环境状态的描述”——评测从答案评测走向行为评测。
4. 主观标准靠 Rubric 二元化 + 人人一致/人机一致 对齐：把”好不好”下钻成一组是/否检查项，一致率到达阈值（85%~90%）后才算”机评”，否则只是机器标注。
5. 评测集不是一次设计出来的，是被 Good Case / Bad Case 喂出来的：先小种子集冷启动，上线后靠 Case 挖掘四类来源持续扩充，靠归因分流到”改 Agent”或”改评测标准”两条 Loop。

一、为什么评测认知稀缺

过去三年两条趋势同时发生：基座模型能力进化（长上下文、原生工具调用、多步推理）+ Agent 框架功能丰富（规划、记忆、工具注册都成标准组件），搭 Agent 的门槛逐年降低。但真走过冷启动、完成灰度扩量、推到全量的项目屈指可数，三种典型死法：

共同点：团队缺少一套可靠的判断机制——不知道当前版本行不行、问题出在哪层、改完是真变好还是换了个地方出错。做决策靠感觉和个别案例，而感觉在复杂系统面前不可靠。

二、完备评测体系的全景图

美团把评测体系概括为 四个模块、三种能力、两条 Loop、一套资产：

2.1 四个模块

一句话区分在线评测与在线监控：在线评测回答”系统工作得好不好“（质量视角），在线监控回答”系统有没有在正常工作“（运维视角）。Skill 调用成功率 100% 但每次返回错误数据——监控是绿的，评测是红的。

2.2 两条相互咬合的 Loop

线上真实样本 ──Case挖掘──> Case池 ──归因──┬─> 评测集没覆盖 → 补进评测集 ──┐
                                          │                                │ 评测集
                                          ├─> 评测标准判错 → 迭代Metrics/Rubric   │ (共享资产)
                                          │                                │
                                          └─> Agent本身的问题 → 修复→回测→上线AB ┘

• 评测体系迭代 Loop：评测集从冷启动人工搭建逐步逼近真实用户反馈，消除”独裁者偏差”（评测标准制定者的个人口味 ≠ 真实需求）。
• Agent 迭代 Loop：变更后用评测集回测确认无退化，再上线 AB。保证每次提升不以牺牲已有能力为代价。

2.3 三种能力 + 一套资产

发现问题（离线+在线）、定位问题（观测+归因）、驱动演进（两条 Loop）——缺一项，体系就在对应环节卡住。三种能力运转后沉淀下评测资产：

• 黄金集：定义”好的下限”——”我们要做到这个水平”变成可以指着看的具体样本。价值容易被低估：Bad Case 告诉你哪里不行，但不能告诉你”到什么程度才算行”。
• 错题集：每一个曾经犯过的错，不应该再犯第二次，可回归。
• 挑战集：标定”能力的边界”。

三、评测集构建（核心）

3.1 基本单元：Task 三元组

评测集由 （问题、参考答案、评价标准）三元组构成，问题+参考答案合称评测样本。借用 Anthropic《Demystifying evals for AI agents》的定义，每一行是一个 Task——”具有明确输入和成功标准的单个测试”：

Task {
  input:    prompt / query            # 固定输入
  expected: expected behavior / answer # 参考答案
  grading:  metrics + rubric          # 评价标准，rubric 是最小粒度
}

关键迁移：Agent 从 ChatBot 演进到长程 Agent 后，参考答案的含义变了——

实践含义：评测长程 Agent 时要同时看轨迹（trace：步骤、工具调用、中间结果）和结果（outcome：环境最终状态，如数据库里是否真的有那条预订记录）——Agent 在记录末尾说”已为您预订”不代表预订真的存在。

3.2 评测标准的写法：Rubric 二元化

“这个 PPT 做得好不好”是无法对齐的模糊判断。美团的做法（与 Arize AI 对齐的术语）：

1. 指标下钻：把大而模糊的概念拆成多个清晰维度；
2. Rubric 二元化：把打分规则收敛成 是/否/未知（0/1/unknown） 的具体检查项；
3. 持续迭代：用 unknown 占比反查 Rubric 定义是否合理，直到单条 Rubric 的人人一致率、人机一致率达到可信阈值（如 85%、90%）。

经典例子——”模型回复是否口语化”：

• ❌ 错误示范：请判断是否口语化并按 0~10 分打分；
• ✅ 二元化：① 是否以”您”指代骑手；② 是否使用”甭客气”“明儿见”等非官方文书词汇；③ 是否包含”吧”“呢”“那个”等语气词。

效果：数字站长业务人机一致率达 99%；Beam 用二元化改造评测体系后，人机一致率从 62% → 92%。

两个对齐概念：

• 人人一致：1 个”独裁者”好过 10 个”民主者”——需要一位强角色拉齐产品/运营/研发/QA 的标准，评测员背靠背标注对齐。独裁者的价值是拉齐和拍板，评测目标本身由真实业务中的 Good/Bad Case 修正驱动（所以不会永远偏）。
• 人机一致：机器评测与人工评测结果一致才置信。人机一致率不达标时，那不叫自动化评测，只是机器标注。

3.3 端到端评测集 vs 过程评测集

两类都要建，且可以各自再分黄金集/必过集：

• 端到端评测集：站在用户视角，看”事有没有办成”。Agent 每增加一个功能模块（如门店经营、门店百科），就按模块分别建端到端集。回答“要不要拉响警报”。
• 过程评测集：看执行过程，”中间哪一步出了问题”。回答“警报响了该找谁”。

经验法则：只有端到端会陷入”知道坏了但不知道哪坏了”；只有过程会陷入”每个模块都达标但用户就是不满意”。过程集还可以继续往下拆（知识库评测集、Skill 评测集……），且与组织分工对齐后分数下降直接找到负责人。但注意：分层拆解是演进的结果，不是设计的起点——先跑起来，遇到”知道坏了不知道哪坏了”再拆，让拆解被真实问题驱动，而不是被完备性焦虑驱动。

3.4 冷启动：种子评测集怎么建

冷启动是否必须设种子集，本质是风险与成本的 trade-off：

• 建议设：大模型有随机性，Corner Case 会让体验剧烈偏移，需要回测守住基线能力；
• 可以不上种子集直接小流量灰度：业务容错率高，或构建高质量种子集的成本远超线上试错的负面反馈；
• 推荐落地：人工生产少量评测集 → AI 辅助生成/扩写 → 低成本完成冷启动种子集。

起步阶段的最小闭环水位：观测 L1（最小可归因：至少能拿到完整模型调用输入输出和 Skill 调用记录，凭 Trace 复现一个 Bad Case）+ 评测集 L1 + 回测门禁 L1。“让数据飞轮高效运转起来”的意义，远大于”设计一个复杂精妙的评测体系”——履约数字站长项目启动时只有 20 多个评测指标，推全一年后扩展到近 200 个。

3.5 回测执行：把评测集用起来

• 固定环境：回测的本质是控制变量。最容易破坏的是执行环境（测试环境下游接口数据与生产不一致、沙箱缺用户历史文件）。检验方法：同一批样本分别在离线环境和线上影子流量跑一遍，结论差异过大说明环境保真度不够。
• 多次 Trial 取稳定结论：用 Pass@k / 通过率，而非单次通过与否。
• 分层门禁：安全类、数据准确性类检查项一票否决；体验类、加分项设阈值。
• 接入 CI/CD：没有接入流程的门禁，本质上只是一个建议。

固有局限：离线评测只能发现已知问题——评测集里没有的场景永远测不出来。所以体系必须含在线部分：离线守已知，在线发现未知。

四、评测集从哪来：Case 挖掘与归因飞轮

评测集不是一次建成的，上线后靠四类来源持续喂养（盲区各不相同，必须搭配）：

样本进 Case 池后分化为 Good Case（→ 黄金集，定义”什么叫好”）和 Bad Case（→ 错题集 + 修复任务）。Bad Case 价值更直接（暴露能力边界），Good Case 定义高质量完成的范式——没有黄金集，讨论质量只能各说各话。

归因是枢纽：把 Agent 执行过程全链路铺开，靠 Trace 逐一定位问题发生在哪个环节（规划/工具调用/上下文管理/模型能力……）。归因明确后，负向 Case 有两条出口，很多团队只走了第一条：

1. Agent 真有问题 → 修复、回测、上线（Agent 迭代 Loop）；
2. 评测判错了 → 校验并迭代 Rubric，Case 流入错题集（评测体系迭代 Loop）。

只走第一条有个隐蔽陷阱：Agent 会被优化成”迎合评测标准”而不是”解决用户问题”。评测标准本身有偏差时，优化得越努力，偏离真实需求越远。定期检查”是不是评测判错了”是体系自我校准的必要动作。

五、成熟度自查与合理水位

各业务评测体系三种最常见的”部分完备”形态：

1. 只有离线评测集 + 监控看板，缺中间的 Case 挖掘与归因枢纽——两套体系割裂：线上发现的问题回不到评测集，评测集的结论解释不了线上现象。看起来最完备，实际投入不少收效有限，最值得警惕；
2. 只有在线监控，没有评测标准；
3. 只有离线评测集，没有在线反馈。

美团给了一张 L0–L3 自查表，结论：不要追求所有维度 L3。体系的能力上限由最短的那块板决定——如果评测标准已到 L3（机评规模化）而 Case 挖掘还在 L0（靠用户投诉），再精密的机评也只是重复评测已知样本，投入应转向补齐挖掘能力。

六、长程 Agent 时代：评测基建的清单

面向大规模 Agent/Skill 生态，评测基础设施至少应具备：全链路回放、Case 管理（统一维护样本/上下文/约束/Rubric）、分层执行沙箱（只读/可写/高风险）、AI 评测引擎（Rubric 驱动、简单易用到 Skill 生产者能自助接入）、报告与归因（指出问题在规划/工具/环境/Skill 哪层）、回归机制（版本升级自动触发历史 Case 回归）、准入准出门禁（嵌入开发发布流程）。

评测范式也随之变化：ChatAgent 时代”核心评测员对齐 → 外包对齐 → 机评对齐”的链路，在长程场景可缩短为”核心评测员对齐 → 机评对齐 → 规模化扩展”——不是人工不重要，而是人工做高价值标准设计和 Rubric 对齐，AI 做规模化运行/初筛/回归，平台做沉淀/回放/告警/归因。AI 评测真正要放大的，是核心评测员的判断标准。

七、小结

评测的本质，是把团队对业务质量的隐性认知，转化为可量化、可复用、可传递、可自动执行的显性资产。落到”如何构建评测集”的具体动作上：

1. 从高频核心场景起步，人工造少量种子 Task，AI 辅助扩写；
2. 每个 Task = 固定输入 + 预期行为 + Rubric，Rubric 下钻并二元化，对齐到人人一致/人机一致达标；
3. 端到端 + 过程两类评测集并行，先粗后细、被真实问题驱动地分层；
4. 回测用 Pass@k + 分层门禁 + CI 接入，固定环境做控制变量；
5. 上线后用四类来源做 Case 挖掘，归因后分流：改 Agent 或改评测标准；
6. 评测集分黄金集/错题集/挑战集沉淀，它是回测门禁的锚点，也是未来 Agent 自进化的地基。