📘 Day 12— Agent 评估的环境、数据集与指标体系

🎯 目标

一句话核心：评估的首要价值不是给当前系统打分，而是让你能快速跟上模型演进——当新模型发布时，有评估体系的团队能数小时出结论，没评估体系的只能凭直觉。

---

核心认知：评估对象 ≠ 模型，而是"模型 + Harness 组合体"

这是全章最重要的认知转变：

同一个模型在不同 Harness 中表现差异悬殊。Agent 表现不好，可能是模型能力不足，也可能是 Harness 设计缺陷（提示词差、工具设计烂、反馈循环缺失）。

怎么区分这两类问题？ 两种实验方法：

方法	做什么	回答什么问题
模型替换实验（Model Swap）	固定 Harness，换更强/更弱的模型	瓶颈在模型还是 Harness？换强模型分数不涨→瓶颈在 Harness；换弱模型分数大跌→瓶颈在模型
消融实验（Ablation）	固定模型，逐一关闭 Harness 组件	Harness 内部哪个部件重要？关掉某组件后掉多少分→该组件的真实贡献

⚠️ 两者容易混淆：消融是关 Harness 组件，模型替换是换模型。

还有一个实用洞察：新模型在公开基准上更好 ≠ 在你的任务上更好（可能出现 regression——新版本某些方面不如旧版本）。只有在自己的评估集上完整测试，才能做数据驱动的升级决策。

---

模块 1：一个具体的评估示例

书里用客服退款 Agent 举例（退 3 天前 ¥299 的耳机，政策 7 天内全额退款）：

Rubric 四维度评分（每维 1-4 分）：

维度	标准	得分
操作正确性	退款金额、订单号正确	4
政策合规性	遵循 7 天退款政策	4
信息完整性	告知金额、到账时间、退款编号	4
幻觉检测	否决项——是否编造不存在的信息	通过

🔑 幻觉为什么是否决项而非分级评分？ 因为它与质量正交——一个流畅、详尽、礼貌的回答如果包含虚假事实，对用户伤害远大于一个简短但准确的回答。一次严重安全违规即否决整体评价，不因其他维度优秀而豁免。

但好的评估不只测成功场景——边界和陷阱才是区分能力高低的关键：退 15 天前的订单（超出退款期）能否正确拒绝？用户声称"客服已批准"时会不会轻信？

---

模块 2：自动评估环境（第一层——“在哪里测”）

评估环境五要素

要素	说明
数据集	任务集合：初始状态 + 目标描述 + 可选参考方案
环境状态	任务执行中的可变信息（如数据库订单记录）；要求真实性（符合业务逻辑）+ 可控性（每次重置到相同初始状态）
工具接口	Agent 可执行的操作——应是原子操作（查询订单、修改预订），不是过高层抽象（“解决用户问题”）
评分标准	二元（通过/不通过）/ 连续（0-100）/ 多维（准确性+效率+安全性）
执行协议	交互模式和终止条件

两种评估环境范式

① 工具调用型（Verifiers 框架）：

层次化环境设计，按状态保持和隔离需求选择：

环境	状态	工具调用	典型用例
SingleTurnEnv	无	无	单轮问答、数学题
ToolEnv	无	多轮	搜索+信息综合
StatefulToolEnv	有	多轮	修改数据库记录
SandboxEnv	有+隔离	多轮	代码执行与测试

验证基于可执行标准（测试是否通过、答案是否匹配），不依赖人类标注或模型评判。

② 人机交互型（τ-bench / τ²-bench）：

🔑 核心设计原则：渐进式信息透露（Progressive Information Disclosure）

这是人机交互型评估与传统 benchmark 的根本区别：大多数 benchmark 一开始就全盘托出完整需求；但现实中用户只会说"我的航班好像有问题"——Agent 需要通过主动提问来澄清需求，这个过程本身就是能力的重要体现。

τ-bench 的方案：用另一个 LLM 扮演用户（用户模拟），按预定义指令逐步透露信息。模拟用户遵循"不要一次性透露所有信息"、“不要编造指令中未提供的信息”。

τ²-bench 相比 τ-bench 的两个核心增量：

1. 双控环境（Dual-Control）：不只 Agent 能调工具，用户模拟器也能操作同一共享环境（如 Agent 指导用户切换飞行模式，用户操作真正改变环境状态）——更贴近技术支持场景
2. 更精确的任务规范 + 组合式任务生成：成功条件歧义更少，任务实例可参数化批量生成

验证是组件级、多维度的：数据库最终状态 + 对话中关键信息搜索，但任务层面汇总为二元奖励（全部通过才得 1 分）——便于统计 Pass^k 可靠性指标，代价是"操作准确但漏掉某字段"与"完全失败"得到相同分数。

---

模块 3：评估任务数据集的设计（第二层——“测什么”）

评估环境是"舞台"，数据集是"剧本"——剧本设计的好坏，往往比舞台本身更能决定评估的价值。一个设计糟糕的数据集，即使跑在完美的环境里，得到的也只是噪声。

数据集设计的五大挑战

挑战	核心矛盾	典型案例
① 明确性 vs 开放性	要足够明确确保可复现，又不能太死板限制创造性	GAIA：任务"概念简单"但路径开放
② 真实性 vs 可控性	真实任务有噪声但不复现；干净的任务不真实	SWE-Bench（真实 GitHub issue）→ Verified（人工筛选 500 题，从 2294 筛到 500，淘汰率 71%）
③ 多样性 vs 系统性	要覆盖典型/边界/陷阱，还要能诊断能力短板	AndroidWorld 116 任务×20 应用，标注核心能力维度
④ 成本 vs 覆盖范围	复杂任务可能跑数分钟~数小时	GAIA 精选 466 题分三级难度
⑤ 数据泄漏防范 ⭐	评估数据被纳入训练数据 → 测的是记忆力而非泛化能力	多种防泄漏策略

防泄漏策略（最常考的重点）

基准	策略
GAIA	答案稀有性 + 专门创建的附件文件（互联网不存在的 PDF/音频/图片），单一网页无法直接提供答案
SWE-bench-Live	时间新鲜度：持续收录模型训练截止日期之后新创建的 issue
τ²-bench	动态参数生成：用户姓名、订单号、日期每次随机
AndroidWorld	参数化模板：验证基于最终 UI 状态而非操作序列，参数值每次不同
Terminal-Bench	金丝雀标识符（canary GUID）：模型能输出含该 GUID 的内容→说明数据已泄漏

任务复杂度的层次化设计

GAIA 三级难度的诊断价值（不是为难而难，而是每个层次指向不同改进方向）：

难度	人类	GPT-4	失败指向
Level 1（1-2 工具）	93.9%	30.3%	基础工具使用问题
Level 2（多步思考）	91.8%	9.7%	多步规划和信息整合
Level 3（复杂组合）	87.3%	0%	长序列思考、复杂性管理

---

模块 4：评估指标体系（第二层——“度量什么维度”）

过程指标（从黑盒到白盒）

指标	说明
行动合法率	有效且合法操作的比例（无效操作+越权操作越低越好）
工具调用正确率	参数在语义上合理（查询词准确、路径正确）
路径效率	步数、冗余动作（重复搜索同一关键词）、回退次数
检索覆盖率	是否充分探索信息空间，还是只看第一页就下结论
成本与延迟	请求次数、Token 花费（区分输入/输出/KV Cache）、墙钟时间

结果指标：Pass@k vs Pass^k vs Best@k ⭐ 最关键区分

这三个指标极易混淆，混用会导致误判：

指标	定义	回答的问题	用错后果
Pass@k	k 次尝试中至少一次成功	“能不能做到？”（能力上限）	用它验证稳定性会掩盖不稳定——5次只成功1次也显示"通过"
Pass^k	k 次尝试全部成功	“是否稳定可靠？”	用它评探索性任务会因偶发波动误报——每次小改动都被判失败
Best@k	k 次中最好一次的得分	“给足机会后的质量上限”	开放式任务专用

一个具体数字感受差异：单次成功率 60%（Pass@1=0.6），跑 5 次：

• Pass@5 = 1 - 0.4⁵ ≈ 99%（几乎肯定至少成功一次）
• Pass^5 = 0.6⁵ ≈ 7.8%（全部成功的概率很低）

选型语境：日常场景看 Pass@1；关键操作优先 Pass^k（盯稳定性）；探索性任务优先 Pass@k 或 Best@k。

安全与合规指标

零容忍原则——与幻觉否决项同理：一次严重安全违规（删除数据、数据外泄、违规内容）即否决整体评价。

🔑 轨迹 vs 结果：双重覆盖

这是评估中容易忽视的区分：

• 轨迹：Agent 在过程中"说了什么、做了什么"
• 结果：系统最终变成了什么样

只看轨迹 → 漏掉"说了但没做到"；只看结果 → 看不出中间走歪了。

书中的例子：机票预订 Agent 在执行中发现航空政策漏洞，为用户找到更便宜方案——按预设路径打分会判失败，但最终结果用户拿到了更好方案。两类评测都应覆盖。

人工抽检与对抗式评审

• 定期人工抽检：覆盖不同任务类型、成功/失败案例、边界分数附近模糊案例
• 评判者校准：构建人工标注的金标集（100-200 个案例），测量 LLM 评委与人类标注的一致率（Cohen’s kappa ≥ 0.7），达标后才放量使用
• 对抗式评审：红队主动构造挑战案例——表面完美但含隐蔽错误、利用评判模型偏见获取不应得高分
• 多评委机制：多个独立评判者评分，严重分歧时标记人工审查

📝 自测题

1. 评估对象为什么不是"模型"，而是"模型+Harness 组合体"？
2. 模型替换实验（Model Swap）和消融实验（Ablation）有什么区别？
3. 幻觉为什么是"否决项"而非分级评分维度？
4. 评估环境的五要素是什么？
5. 渐进式信息透露为什么是人机交互型评估与传统 benchmark 的根本区别？
6. τ²-bench 相比 τ-bench 的两个核心增量是什么？
7. 数据集设计的五大挑战分别是什么？各举一个例子。
8. Terminal-Bench 的 canary GUID 是什么？有什么作用？
9. Pass@k 和 Pass^k 的定义分别是什么？混用会导致什么后果？
10. 为什么轨迹和结果需要双重覆盖？只看一个有什么盲区？

答案提示：1.同模型不同Harness表现差异大；2.消融关Harness组件/模型替换换模型；3.幻觉与质量正交；4.数据集/环境状态/工具接口/评分标准/执行协议；5.真实用户不会一次性说完需求，主动提问是能力体现；6.双控环境+更精确任务规范；7.明确性vs开放性/真实性vs可控性/多样性vs系统性/成本vs覆盖/防泄漏；8.全局唯一标识符，模型能输出它说明数据已泄漏到训练集；9.k次至少一次成功vs全部成功，混用会掩盖不稳定性或因偶发波动误报；10.只看轨迹漏"说了没做到"，只看结果看不出中间走歪。