09 · 从执行轨迹到评测与反馈闭环¶
新版本助手多查了两次资料，演示时答得更完整，账单也更长。到底是检索策略改善了，还是只给它多试了几次？如果评分器又偏爱长答案，分数上涨可能只是尺子跟着变长。
本章把这几件事拆开：先找真正值得修的错误，再比较多次尝试，最后检验评分器。建议先读基础评测与多 Agent 协作。
先读失败轨迹，再决定优化对象¶
研究助手需要检索两地政策、比较适用条件并形成申请草稿。一次任务失败可能来自旧索引、工具选错、权限拒绝、错误汇总或用户根本不需要这份报告。把这些情况都算成“模型答错”，下一次更换模型就无法针对问题。
可以先逐条记录观察：“第二次检索仍只查旧版本”“引用存在但金额不适用于该员工”“工具失败后仍输出成功”。再将相似问题归成失效类别，检查首次错误出现的位置，以及其他独立错误。Hamel Husain 的评测实践强调从真实轨迹的错误分析形成评价标准，而不是先选一批通用指标再寻找用途。AI Evals FAQ
这里要同时保留两类规则：事先明确的业务不变量，例如未经授权不得写入；通过观察逐渐细化的质量标准，例如比较结果应解释两地政策为何适用。后者会演化，评分器、标注和数据集也应一起版本化。
一个任务，需要四份能关联的记录¶
| 对象 | 研究助手的记录 | 用途 |
|---|---|---|
| Task | 用户目标、初始资料、允许动作、成功规则 | 固定本次要解决的问题 |
| Trial | 模型/工具/提示版本、随机配置、环境快照 | 区分同题的不同尝试 |
| Trace | 检索、路由、交接、审批、重试和费用事件 | 找到错误发生的阶段 |
| Outcome | 草稿内容、有效引用、实际后端对象 | 判断用户目标是否完成 |
工具事件显示“成功”，可能只是查到了资料，并未说明最终答案正确。把关键主张接到证据 ID，把写入意图接到操作 ID，再关联 Task 与 Trial，才能从用户看到的错误一路追到发生错误的步骤。
这样做也便于比较版本：同一题、同一资料范围，究竟哪一步变了？OpenAI 官方评测路径同样连接轨迹诊断与可重复的数据集评测；实际字段和采集方式应按所选运行时配置。Evaluate agent workflows
不要把“多试几次”混成一个成功率¶
设同一道题每次独立尝试、成功概率固定为 p。至少一次成功的概率为 1-(1-p)^k，k 次都成功为 p^k。p=0.6、k=3 时，前者是 0.936，后者是 0.216。前者适合讨论允许候选筛选的能力，后者强调重复交付的一致性；真实系统的相关错误会破坏独立假设。
还有一个容易算错的平均顺序。两题的 p 分别是 0.9 与 0.1，k=2：
先把两题的 p 平均成 0.5，再计算至少一次成功，会得到 0.75。这个数字对应“每题都像一枚成功率 0.5 的硬币”，已经丢掉一题容易、一题困难的结构。先逐题计算，再按声明的权重汇总，才能回答原来的问题。
在有 n 个已评分样本、其中 c 个成功时，常用 pass@k 估计量为 1-C(n-c,k)/C(n,k)，要求 n≥k。它计算从样本中选择 k 个时至少一个成功的比例；5 次中成功 1 次，pass@2 为 0.4。HumanEval 原论文 这仍不解决“如何识别正确候选”：若真实用户拿不到可靠验证器，报告至少一次成功时应同时说明筛选成本与交付方式。
Judge 也需要一套评测集¶
给评分器提供任务、必要证据、最终产物和明确规则，让它判断“是否正确使用有效政策”，比只问“报告好吗”更可操作。校准时保留人工判断和分歧原因，分别观察误放过和误拦截，而不只看总体一致率。
例如人工认为 5 个答案通过、5 个不通过；Judge 正确放行 4 个、误拦 1 个，正确拦截 2 个、误放 3 个。它的真阳性率是 4/5，真阴性率是 2/5；总体准确率 6/10，却把 60% 的坏答案放过。若高风险类别更少，整体分数还可能掩盖更大的问题。位置、冗长和自我偏好等偏差需要通过任务内校准检查。MT-Bench 原研究
让不同检查各做擅长的部分：对象数量、必需字段和禁止调用交给确定性规则；证据支持、完整性和语气可由经过校准的 Judge 辅助，争议样本再交人工。Judge 是一把也需要校准的尺子，不是换上模型名称就自动成为标准答案。
汇成总分前，先单独查看关键失败。一份未经批准却写入成功的报告，不能靠文风优美把分数补回来。
设计一次能解释的改进实验¶
假设要比较“固定检索两次”与“证据不足时追加检索”。先冻结任务集合、允许的证据范围与成功标准，再分别记录逐题终态、错误类别、调用量、耗时和总费用。以同一题为配对单位比较，而不是让两种策略各挑容易的题。
开发集用于设计策略，保留集用于检查迁移；同一模板、同一文档的近重复改写应按组切分。任务内重复采样不能当作更多独立用户需求，统计汇总应保留题目这一层。若策略改变了最大尝试次数、模型或工具预算，比较表需要同时展示这些变化。
错误修复后，把具有稳定验收条件的案例加入回归集合；新任务、新资料与新交互仍用于发现新问题。线上观察可以从无副作用的影子运行开始，再小范围发布，保留可回退的模型、提示、工具及索引版本。
动手练习¶
为 8 条研究任务建立逐题表：2 条单文档、2 条跨文档冲突、2 条工具失败、2 条权限/写入请求。先人工标注终态和首个失效阶段，再给其中 4 条做多次尝试。计算至少一次成功、重复一致性、误放过率和每个成功任务成本。用一张差异表解释新增检索到底修复了什么，也记录它增加的费用。
运行概率算例：
自检¶
1. pass@5 提高，单次交付就更可靠了吗？
不一定；它允许更多尝试，还需要看 pass@1、候选识别和总成本。
2. Judge 与人工总体一致 95% 就够了吗？
仍应按错误类别检查混淆矩阵，尤其关注关键失败被放过的比例。
3. 一次路由改进应该先改模型还是加测试？
先读失败证据、明确修复对象，再设计可重复比较；改动可能在数据、工具或交互层。
参考资料¶
Hamel：AI Evals FAQ · OpenAI：Agent evals · HumanEval · MT-Bench