评估数据集设计

何时使用

• 从零设计评估集，或评审现有任务定义是否站得住
• 为 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 是聚合规则。二元奖励（只看终态）以过程颗粒度换取跨模型可比的单一数字：满分轨迹里违反"一次只做一个工具调用"的政策也不会被捕获。生产评估系统需要更多：不仅判对错，还要指出问题出在哪。