评估集的质量控制与来源
为什么高质量评估集需要逐轮修补？
- 事实: 现行基准的多数形态，是在初版投入使用、暴露问题之后逐轮修补的结果;
- 成本压力: 复杂 Agent 任务动辄需要数分钟至数小时，用前沿模型完整跑完一个评估数据集往往需要数千美元的 token 成本;
τ-bench 到 τ²-bench 做了哪五处重新设计？
| 暴露的问题 | 重新设计 |
|---|---|
| 任务指令过于笼统，答案可被猜测 | 剧本拆为 known_info 与 task_instructions：前者界定用户知悉的范围，后者规定透露方式 |
| 成功条件不够精确，导致验证误判 | “网络已恢复” 改为 “测速 excellent 才算解决，poor/fair/good 均不接受”，针对敷衍性修复 |
| 用户模拟器行为过于机械 | 补充情绪（首次失败后不满）、耐心上限（沟通效率过低即终止）、事实锚定要求 |
| 只有 Agent 能改变环境 | 引入双控环境，用户拥有独立工具集，验证覆盖 “Agent 是否读到用户侧操作结果” |
| 任务实例静态 | 具体实例（姓名、号码、故障组合）可参数化批量生成，同时改善覆盖率与抗泄漏能力 |
- 结构细节: 见 评估任务解剖与真实轨迹;
SWE-bench Verified 为什么淘汰 71% 的原始任务？
- 流程: OpenAI 从原始 2294 个任务中随机抽取 1699 个，招募 93 名精通 Python 的开发者逐条检查;
- 检查项: 问题描述是否清晰、测试用例是否覆盖边界条件、测试是否稳定、参考 patch 是否引入新错误、难度是否合理;
- 结果: 最终仅 500 个通过;
- 收益: 更高的信噪比，评估成本也下降约 80%;
OSWorld 发布后暴露并修复了哪些问题？
- 规模: 2024 年 4 月发布，随后 15 个月中暴露出 300 余个问题;
- 四类问题: 环境问题（网站反爬、CAPTCHA、动态内容变化）、任务描述问题（表述存在歧义）、验证逻辑问题（过严或过松）、初始状态问题（配置不完整）;
- 组织: 香港大学团队组建约 10 人小组，与 MoonShot AI、OpenAI、ByteDance Seed TARS、Anthropic、Simular 等深度合作两个月进行系统性修复;
- 手段: 环境问题锁定版本与离线备份、描述问题改写歧义表述、验证问题人工建立正确基线并调整条件、初始状态问题增加完整性校验;
自建评估集的任务有哪三个来源？
- 来源一 公开基准: 用于粗筛模型与借鉴设计手法，任务分布与实际业务不一致（GAIA 上提升两个百分点与退款成功率之间不存在必然关系），一般不用于产品决策;
- 来源二 自建业务集: 覆盖真实任务分布，作为模型选型与 Harness 设计决策的依据；可以 τ²-bench 为骨架，替换领域数据与工具集;
- 来源三 生产轨迹回流: 来自线上真实失败用例——用户明确纠正、用户点踩，以及事后通过状态检查、规则验证器或 LLM 评审发现的问题案例，经失败归因后沉淀为回归用例;
- 成本与准确性: 生产轨迹回流成本最高、准确性也最高，因为它直接来自用户实际遇到的问题;
- 演化: 起步阶段通常只有公开基准与少量手写的自建业务集，系统上线运行一段时间后，生产轨迹回流用例会成为主体;
- 相关: 回流的具体做法见 失败归因、端到端与轨迹前缀回归;