[TOC]
评测指标的定义设计
结果指标
- Pass@1: 衡量单次即时表现(只给一次机会能做对的概率)
- Pass@K: 反映能力上限(k次尝试至少成功一次)
- Pass^k: 则关注业务可靠性(k次必须全部成功)
- Best@k: 捕捉最优变现(k次中取最高分)
实际使用中，模型选型看能Pass@k摸底能力边界，Prompt调优看Best@k最优表现，生产部署前必须验证Pass^k确保稳定性，日常运营监控则依赖Pass@1追踪即时表现
过程指标
即需要从整个会话过程中进行评测的指标，包为合法性，工具调用正确率，路径效率
- 行为合法性检测整个任务执行过程是否存在无效操作&越权操作，
- 工具调研正确率进一步检测搜索工具的查询词是否准确表达需求，文件操作的路径是否指向正确目标
- 路径效率的分别检测步数（思考-行动-观察循环次数）
- 冗余动作（重复搜索相同关键词，反复读取同一文件）
- 回退次数（意识到错误并且纠正的频率）
- 检索覆盖率检测信息收集的全面情况
其他类型指标
- 成本与延迟，检测请求次数，token花费等等
- 鲁棒性，衡量面对不确定性时的稳定性，不同初始化下表现差异大小，页面变化适应性（网站UI更新不应导致完全失效），API抖动容忍度（能否处理临时故障，超时，格式变化），长期记忆干扰
- 安全问题&幻觉，拥有决定性的指标，严禁出现任何敏感操作，数据外泄，违规内容和编造不存在的信息
总结
- 一定要实现轨迹与结果的双重覆盖
- 安全性指标可有一票否决性质
- 除此之外，一定要进行人工抽检与对抗式评审（即主动构造利用评判模型已知偏见骗高分的回答）
评测环境的设置
包含五要素：
数据集：定义任务集合，包含初始状态，目标描述和可选的参考解决方案
环境状态：任务执行中的可变信息
工具接口：Agent可执行的操作集合
评分标准和执行协议：规定交互模式和终止条件
其中需要注意：环境状态要在真实性（状态变化符合业务逻辑）与可控性（每次测试可重置到相同初始状态）间平衡；工具接口不应提供过高层抽象（如 “解决用户问题”），而应给原子操作（查订单、改预订、发邮件），迫使 Agent 通过规划去组合；评分标准可以是二元、连续或多维的
具体来说，可以分为：
- 工具调用型环境（通过调用预定义工具完成任务，验证基于可执行标准，不依赖人类标注或模型评判）
- 人机交互型环境（在自动化环境中模拟真实用户）两类。
前者可以参考 Verifiers 框架，不适用于复杂 agent，仅适用于输入目标单一的 agent；我们来聊聊后者。
首先是模拟人的渐进式信息透露，普通用户不会在一开始就能想到一个任务的全部要点，经常需要 agent 通过主动提问的方式引导澄清需求。要使用 τ-bench 的做法，即用另一个 LLM 扮演用户，按预定义指令逐步透露信息、回应询问、完成后发终止信号。提示词明确要求 “不要一次性透露所有信息”，且常需设置有限耐心，Agent 沟通效率太低就直接终止、任务失败；验证是结果和过程双重的，但任务层面仍汇总为二元奖励，全部通过才得 1 分，便于统计 Pass^k。
同时，从总体评测角度来看，前者考察 Agent 的行动正确性，后者考察其沟通策略的合理性。
评测任务集的设计
精确性设计
- 用答案的唯一性反推描述：通过信息源约束、时间范围、主题、查询目标四重限定锁死唯一答案。
- 用信息分层承载真实语境：每个任务含四层：表面问题（”移动数据无法工作”）、性能期望（”绝对想要出色速度”）、约束条件（”不接受其他速度”）、隐含情绪。
- 用结构化字段 + 机械可验证元素：前者用问题描述、复现步骤、预期 / 实际行为等结构化字段，并由标注者验证描述与测试用例是否匹配。后者要求描述里每个元素都能机械化验证（路径是否存在、权限数值、证书参数、日期格式）。
- 用参数化模板替代静态文本：任务是可动态实例化的模板，每次随机生成参数。
- 从中间状态启动并显式消歧：任务常从精心配置的中间状态而非 “干净” 状态开始，更贴近真实使用。
层次化设计
- 技术难度分级：如 level1 需要多个工具，level2 需要多步思考，level3 需要复杂组合。
- 业务难度分级：如 level1 为简单信息查询，level2 需要诊断故障，level3 是整个策略判断。
通常，1、2 两种应该综合来设计。
自动化评测方案（LLM-as-a-Judge）
适用场景
无标准答案（无法构造工具调用型环境）、人工评估难以规模化。
已知局限
- 长度偏见：可能更倾向于更长的回答；
- 波动性：多次相同输入评测结果不同；
- 同源模型问题：Agent 与评判模型同家族时，Agent 会学会利用评判者的偏好和盲点，避开评判模型不擅长检测的错误类型；
- 配对比较的位置偏差：评判模型系统性偏向先出现的候选。
Rubric 四准则
01 基于专家指导—— 反映领域知识，缺乏专业基础的 Rubric 只能捕捉语言流畅度等表面特征； 02 全面覆盖—— 事实准确性 / 逻辑连贯性 / 完整性 / 安全性，且不只定义正面标准，还要明确陷阱； 03 标准重要性权重—— 必要项 / 重要项 / 可选项 / 陷阱项，支持一票否决； 04 自包含评估—— 每项独立可操作。
失败归因
- bad case 三类来源：用户明确纠正、用户点踩 / 负面反馈、事后通过状态检查 / 规则验证器 / LLM 评审发现。
- 归因记录必须结构化：引用具体步骤号、工具名、观察证据；区分根因与后果；判断是否可恢复；给出置信度。多类别同时出现时按 “最早且能解释后续失败” 选主因，其余留作次因。
- 可借助 LLM 规模化，但不能完全依赖 —— 失败归因往往反映的是产品问题，不只是技术问题。
- 保存时要连同任务目标、环境状态、Agent 与工具集版本、完整轨迹一起存档以便回归测试。
两层回归任务
- 端到端回归任务：从初始状态和用户请求跑完整流程，检查最终状态、必要输出与安全条件。最接近生产结果，但难定位失败在哪一步。
- 轨迹前缀回归任务：冻结首个错误之前的上下文、对话、工具返回和环境状态，只要求 Agent 执行下一步或几步可观察动作。成本低、能隔离单个策略或工具问题。对生产级高可靠 Agent，这一层往往比端到端更重要。
Guduyili
我心匪石，不可轉也。我心匪席，不可卷也