bojieli/ai-agent-book/eval-dataset-design

评估数据集设计

何时使用

• 从零设计评估集，或评审现有任务定义是否站得住
• 为 Agent 编写单条评估任务：工单、用户模拟规范、初始状态、验收标准
• 设计验证器：该断言终态、断言动作，还是检查必须告知用户的信息
• 评估任务被模型"猜答案"蒙过，需要提高信噪比
• 怀疑评估集已被污染/泄漏进训练数据，需要防泄漏与检测手段
• 决定自建评估集的任务从哪来：公开基准、业务集、还是生产失败回流
• 评估集上线后需要长期维护：修补环境、描述、验证逻辑与初始状态问题

核心原则

• 一条评估任务 = 四个部分：给 Agent 的工单、给模拟器的行为规范、两侧状态的初始重置、成功判定标准。缺任何一部分，任务都无法重复运行。
• 把用户的认知边界建模为独立字段，而非靠提示词约束。 用户不知晓的信息 Agent 无从推测，只能通过提问与引导获得——渐进式信息透露不是一句"不要一次说完"，而是 known_info 与 task_instructions 的拆分。
• 没有事实锚定的用户模拟器会让评估退化为两个模型相互确认。 模拟用户关于环境状态的任何回答都必须以工具返回为依据，不许编造工具结果；否则 Agent 稍加引导，用户就确认"问题已解决"。
• 验证器必须核实机器可独立复核的事实，不能采信 Agent 的自我陈述。 Agent 很容易写一篇"任务已全部完成"的报告而实际什么都没做。
• 训练集与评估集严格隔离。 答案不可从互联网直接检索、任务实例参数化生成、嵌入 canary 使泄漏可检测——三招至少用一招。
• 验收口径要有可核实的边界，防"敷衍性修复"。 "网络已恢复"不可核实；"测速评级 excellent 才算解决，poor/fair/good 均不接受"才堵得住压制症状、不除根因的糊弄。
• 高质量的评估集是修出来的，不是写出来的。 主流基准的现行形态都是初版暴露问题后逐轮修补的结果；发布前人工淘汰、发布后持续修两类问题都要预算。
• 每道题亲手做一遍。 做完问两个问题：描述是否有多种合理解释，验证器认可哪一种？蒙混过关的最低成本路径是什么，验证器拦得住吗？
• 难度分层让评估集不过时，且每层失败指向不同改进方向：基础层失败指向工具使用，中间层指向多步规划，最高层指向长序列思考。

实践模式

1. 任务解剖：四件套字段清单

以 τ²-bench telecom 一条真实任务为范本，逐项对照自建任务：

• ticket（给 Agent 的工单）：只含用户会主动说出的部分。真实用户的初始表述往往只是"我上不了网"，把需求澄清到可执行的程度本身就是 Agent 必须具备的能力。
• user_scenario（给模拟器的行为规范）：known_info 界定用户知悉范围（姓名、号码、所在国），故障原因不在其中；task_instructions 规定透露方式，并包含三类约束——情绪设定（首次修复失败后表现不满）、验收口径（仅 excellent 算解决）、事实锚定（设备状态回答必须基于工具结果）。
• initial_state（初始重置）：initialization_actions 把两侧状态重置到同一起点，包括用户侧（飞行模式、漫游开关）与 Agent 侧（运营商侧配置）。
• evaluation_criteria（成功判定）：四个可检查维度按需组合，外加聚合规则。

2. 四维校验与聚合规则

• env_assertions 验终态：移动数据可用、测速达 200 Mbps 且评级 excellent。
• actions 验关键动作是否发生（哪些工具被哪一侧调用）。
• communicate_info / nl_assertions 验必要信息是否已告知用户——别只查环境状态。
• reward_basis 是聚合规则。二元奖励（只看终态）以过程颗粒度换取跨模型可比的单一数字：满分轨迹里违反"一次只做一个工具调用"的政策也不会被捕获。生产评估系统需要更多：不仅判对错，还要指出问题出在哪。

3. 验证器设计的三种模式

• 双命题验证（SWE-bench Verified）：FAIL_TO_PASS（修复前失败、修复后通过，证明问题确已解决）+ PASS_TO_PASS（修复前后均通过，证明未引入新缺陷）。只验前者，Agent 可以删改妨碍通过的断言蒙混；只验后者等于未检验。另需排除自身不稳定的 flaky test。
• 深状态核查（OSWorld 式）：134 个独立评估函数，拥有完整系统访问权限，查文件系统结构、进程状态、网络连接与应用内部状态；数据库任务连库核实 SQL 是否真执行，浏览器任务分析 DOM、cookie 与 localStorage 并向后端发验证请求——能抓住"表面完成、实质错误"。
• 不可伪造执行（Terminal-Bench 式）：成功标准是真实构建并运行（如从源码构建内核并在 QEMU 启动日志出现自定义 printk），Agent 无法伪造输出，只能真做完全流程。

4. 难度划分与陷阱任务

• 分层标注并用于诊断：GAIA 466 题分三级——Level 1 只需一至两个工具（人类 93.9%，早期模型 30.3%），Level 2 多步思考，Level 3 复杂组合。Level 1 失败指向基础工具使用，Level 2 指向多步规划与信息整合，Level 3 指向长序列思考与复杂性管理，改进方向各不相同。
• 陷阱任务检验压力与误导下的判断力：用户声称"客服已批准取消"，实际并不符合政策，看 Agent 是否维持正确判断。
• 任务集覆盖从易到难的全谱，模型能力提升时评估集不会快速过时。

5. 数据泄漏防范

• 组合多源 + 专有附件 + 精确匹配（GAIA 式）：答案必须组合多个信息源才能得出，单一网页无法直接给出；部分任务配互联网上不存在的 PDF/音频/图片附件；用精确字符串匹配判定。
• 参数化模板实例化（AndroidWorld 式）：任务是"将联系人 X 的电话改为 Y"这类模板，每次评估随机生成参数。三收益：回放固定操作序列失效；单模板可生成近乎无限实例；固定部分参数、只改其余，可精确测量特定因素的影响。
• 金丝雀标识符（Terminal-Bench 式）：题面嵌入 canary GUID，模型能输出含该 GUID 的内容即说明基准已进训练集。它不阻止泄漏，但使泄漏可被检测。

6. 质量控制与长期维护

• 发布前人工淘汰：SWE-bench Verified 从 2294 个原始任务抽 1699 个，93 名精通 Python 的开发者逐条检查（描述是否清晰、测试是否覆盖边界、是否稳定、参考 patch 是否引入新错误、难度是否合理），仅 500 个通过——淘汰 71% 换来更高信噪比，评估成本下降约 80%。复杂 Agent 任务动辄数分钟至数小时，前沿模型跑完一个评估集往往需要数千美元 token，控本就是控迭代速度。
• 发布后持续修补：OSWorld 发布 15 个月暴露出 300 余个问题，分四类——环境问题（反爬、CAPTCHA、动态内容，靠锁定版本与离线备份）、任务描述歧义（改写消除）、验证逻辑过严或过松（人工建立正确基线再调条件）、初始状态不完整（增加完整性校验）。修补方式可整体借鉴。
• 从初版到成熟版的五处典型重设计（τ-bench → τ²-bench）：任务指令过于笼统导致可猜 → 拆分 known_info/task_instructions；成功条件不精确 → 改为可核实边界；模拟用户过于机械 → 补情绪、耐心上限与事实锚定；只有 Agent 能改变环境 → 引入用户侧工具的双控机制；静态任务 → 参数化批量生成实例（同时改善覆盖率与抗泄漏）。

7. 评估集的三个来源与演进

• 公开基准：用于粗筛模型与借鉴设计手法（验证深度、参数化生成、防泄漏、质量维护），一般不用于产品决策——其任务分布与业务分布不一致。
• 自建业务集：覆盖真实任务分布，作为模型选型与 Harness 设计决策的依据。可拿成熟基准当骨架，替换领域数据与工具集。
• 生产轨迹回流：用户明确纠正、点踩、事后规则/LLM 审计发现的失败案例，经失败归因后沉淀为回归用例。成本最高、准确性最高，直接来自用户实际遇到的问题。
• 演进节奏：起步只有公开基准 + 少量手写业务集；上线运行一段时间后，回流用例成为主体。今天线上暴露的失败模式，明天就是守住底线的回归用例。

常见陷阱

• 任务指令写得宽泛，模型无需澄清需求、凭常识猜一套流程也能通过。
• 成功条件是"网络已恢复"这类无边界描述，被压制症状的敷衍性修复蒙过。
• 只验 FAIL_TO_PASS 不验 PASS_TO_PASS，Agent 靠删断言作弊；或不排除 flaky test，结果不可复现。
• 用户模拟器没有事实锚定，评估退化为 Agent 与模拟用户相互确认；没有耐心上限，沟通效率低下不被计失败。
• 静态题面被模型记忆，且无 canary，泄漏发生了都不知道。
• 验证器过严（把正确答案判失败）或过松（放走表面完成实质错误）；初始状态配置不完整，每次运行起点不同。
• reward_basis 只看终态，过程违规（策略违背、信息未告知）不被捕获，且不另建过程检查。
• 任务描述存在多种合理解释而验证器只认一种，开发者与人肉执行者的判断不一致。
• 评估集建成后不再维护，上线后仍是手写那几十条，与真实用户分布脱节。

配套代码

• chapter7/tau2-bench-eval/ — τ²-bench telecom 任务定义四部分（ticket / user_scenario / initial_state / evaluation_criteria）的完整解剖与双控环境运行记录
• chapter7/public-health-reporting-eval/ — 五个确定性任务的六点结构化评分示范验证器设计：工具选择、参数、答案（含数值容差）、证据行精确集合、无依据声明处罚
• chapter7/android-world/ — T3A 失败轨迹与归因笔记，演示参数化任务实例、验证器终态判定，以及从失败轨迹回流生成轨迹前缀回归任务

深度阅读

• book/chapter7.md「一条评估任务的解剖：τ²-bench 的 telecom 领域」
• book/chapter7.md「评估数据集的设计」