Day 21 - Agent Evaluation Basics

今日目标

能设计任务集与评分标准，说清人工评估与自动评估如何结合。

学习安排

时间	模块	做什么
0-10 分钟	核心概念	通读当天术语表，圈出 3 个你最想在工作里用上的概念。
10-25 分钟	阅读输入	精读当天章节重点，只抓问题、思路、结论。
25-45 分钟	实践任务	动手完成输出模板，必须产出一份可复用产物。
45-55 分钟	追问与反思	回答追问练习，标记卡住的概念。
55-60 分钟	复盘与作业	整理自检清单，定下明天要复习的一点。

核心概念

术语	中文解释	应用场景
eval	评估：用一组任务样例和评分标准，量化衡量 Agent 表现的做法	每次改动 prompt、工具或模型后，跑同一批样例对比分数
task set	任务集：一组有代表性的输入任务，同时覆盖正常与失败场景	从真实使用中收集任务，如接口 P95 分析、日报生成
rubric	评分标准：事先写明的打分规则，说明什么算好、什么算差	给每条样例定义 1-5 分或 0/1 的判定依据，保证可复核
success rate	任务成功率：按 rubric 判定为完成的任务数占总任务数的比例	衡量 Agent 端到端完成任务的能力
tool call accuracy	工具调用正确率：工具、参数、时机都正确的调用占比	发现「答案对但过程乱调工具」的隐藏问题
human eval	人工评估：由人对照 rubric 逐条打分	样本少、涉及可读性与专业判断时
auto eval	自动评估：用程序或 LLM judge 批量打分	eval set 较大、需要反复回归时
statistical significance	统计显著性：区分「真实改进」与「随机波动」的统计判断	样本量不足时判断 A/B 版本哪个真的更好
eval environment	评估环境：与真实环境隔离、可重复运行的场地，如 mock 工具与固定数据	防止评估污染生产数据，保证结果可复现
LLM judge	模型评委：用另一个模型按 rubric 给输出打分	auto eval 的主要实现方式之一，速度快但可能带偏好

阅读重点

围绕三个问题读第 6 章：评估什么、怎么评分、结果怎么用。

对应章节：第 6 章「Agent 的评估」，重点读评估环境、指标、统计显著性、评估驱动选型。
关注点 1：Agent 评估为什么比普通文本评估难——行为空间大、一次回答代表不了全过程、环境有随机性。
关注点 2：评估对象分两层——最终答案（对不对）与全过程（工具选得对不对、参数对不对、出错会不会恢复）。
关注点 3：人工与自动评估的分工——自动评分跑量大、回归快；人工评分管可读性、专业判断等主观维度。
关注点 4：统计显著性——样例太少时，几个点的成功率差可能只是噪声，不能据此下结论。
补充材料：OpenAI Evals 官方仓库（github.com/openai/evals）里的任务集格式与打分示例。
补充材料：Anthropic 的 agent 评估实践博文，介绍「评估驱动迭代」的完整流程。

理解检查

先不看笔记回答下面 4 个问题，卡住的写下来。

为什么 Agent 评估比普通文本评估更难？如果只对比「生成答案和标准答案」，会漏掉哪些问题？
应该评估最终答案还是全过程？举一个「最终答案正确但过程有问题」的例子。
什么是任务成功率？假设一个 Agent 只在 2 个简单任务上成功率高，能说明它可靠吗？
什么是工具调用正确率？它和任务成功率是什么关系，为什么需要分开统计？

实践任务

背景：你手上有一个「接口性能分析 Agent」，负责分析 P95 升高、生成测试日报等任务。今天给它建立第一批评估样例，为 Day 23 的 20 条 eval set 打底。

步骤：

步骤 1：从真实使用中收集 10 个任务，覆盖「正常任务」与「失败过的任务」两类，不要只挑容易的。
步骤 2：每个任务写三列——输入任务、期望行为、评分标准。期望行为写成可观察的动作，例如「先查部署历史再下结论」。
步骤 3：评分标准用 1-5 分，明确写出 5 分、3 分、1 分分别是什么样子，保证两个人打分接近。
步骤 4：至少 2 条样例来自真实失败案例，并在评分标准里体现当时的失败点。
步骤 5：先写「分析接口 P95 升高」和「生成日报」两条，再补齐其余 8 条。
步骤 6：把样例表保存为独立文件，作为以后每次改动的对比基线，不要随手删改。

产出：一份 10 条的 eval 样例表（Markdown 表格）。

验收提示：隔天再读一遍，看每条期望行为是否可观察、评分标准是否可判定，不合格的当场改掉。

输出模板

先按模板填空，再替换成你的真实任务。表头固定，行可以自由增加。

| # | 输入任务 | 期望行为 | 评分标准（1-5 分） |
|---|---|---|---|
| 1 | [任务描述] | [行为 1]；[行为 2]；[行为 3] | 5 分：[满分样子]；3 分：[及格样子]；1 分：[失败样子] |
| 2 | [任务描述] | [行为 1]；[行为 2] | 5 分：[满分样子]；3 分：[及格样子]；1 分：[失败样子] |
| 3 | [任务描述] | [行为 1] | 5 分：[满分样子]；3 分：[及格样子]；1 分：[失败样子] |
| 4 | [任务描述] | [行为 1]；[行为 2]；[行为 3] | 5 分：[满分样子]；3 分：[及格样子]；1 分：[失败样子] |

单条 rubric 细则模板（给一条样例写详细打分依据，比表格里的简写更严）：

任务：[任务描述]
- 5 分：[条件 A 且 条件 B]，例如「窗口准确且引用了具体数据」
- 4 分：[条件 A 但 条件 B 不完整]
- 3 分：[只满足最基础的条件]
- 1 分：[出现明显错误]，例如「编造数据或复述问题」
- 0 分：[完全偏离任务]

示范输出

以下是一条已填好的样例表，场景贴合测试/QA 工作，可以直接借鉴结构。

| # | 输入任务 | 期望行为 | 评分标准（1-5 分） |
|---|---|---|---|
| 1 | 分析接口 P95 升高 | 定位时间窗口；关联日志与指标；给出假设并标注证据 | 5 分：窗口准确、引用具体数据、假设标注已验证或待验证；3 分：窗口模糊、有假设但缺引用；1 分：只复述问题或编造数据 |
| 2 | 生成每日测试日报 | 包含必报指标；不编造缺失数据；输出 Markdown | 5 分：指标齐全、缺失数据明确标注、格式正确；3 分：缺 1-2 个指标但数据忠实；1 分：编造数据或结构混乱 |
| 3 | 分析某接口延迟突增 | 对比前后时段；检查工具调用顺序；给出下一步验证动作 | 5 分：对比完整、过程可复现；3 分：结论对但过程跳步；1 分：未对比直接下结论 |
| 4 | 汇总一周缺陷趋势 | 按模块统计缺陷；指出恶化模块；标注数据口径 | 5 分：口径清晰、恶化模块有数据支撑；3 分：统计对但口径没说清；1 分：数字与原始数据对不上 |

打分过程示例（第 1 条样例）：

观察到的行为：窗口定位 14:30-15:00，引用 query_metrics 返回数据，假设标注「待验证」
- 命中 5 分条件：窗口准确 + 引用数据 + 假设标注
- 如果假设没有引用任何数据，最多只能给 3 分
- 如果编造了不存在的日志内容，直接给 1 分

追问练习

下面的问题比理解检查深一层，建议边想边写。

人工评估和自动评估如何结合？用你的样例表试排：哪几条适合自动打分，哪几条必须人看？
如果 10 条样例跑下来成功率 90%，你能说这个 Agent 可靠吗？还缺什么信息？
评分标准怎么防止「不同打分人分数差很多」？在 rubric 里加什么能减少分歧？
一条样例的期望行为写得太细或太粗，分别会带来什么问题？你打算控制在什么粒度？

常见误区

没有评估就无法稳定改进：凭感觉改 prompt，改完不知道是变好还是变坏，等于随机调试。
只评最终答案不评过程：工具乱调但答案碰巧正确，这类问题会被评估放过去。
评分标准写得太模糊：「回答得不错」不能当 rubric，两个人打分必然不一致。
用模型自己的输出来证明自己：没有独立 judge 或 ground truth，评估结果没有说服力。

进阶扩展

评估集过拟合：反复对着同一批样例调 prompt，样例外的真实任务可能悄悄变差，需要定期补充新样例。
统计显著性：样例少、成功率差几个点时不一定是真实改进，要用多次运行与置信度判断。
持续回归评估：把 eval 接入每次改动流程，让「变好」与「变坏」成为可追溯的记录。

今日作业

完成 10 条评估样例表，其中至少 2 条来自真实失败案例。
给「分析接口 P95 升高」这条样例写一份完整的 rubric 打分细则。
用今天学的概念，把「我想让 Agent 更好」改写成「我可以评估的三件事」。
标记一个今天没想通的概念，明天复习时先看它。

自检清单

我能说清为什么没有评估就无法稳定改进。
我能设计一条包含输入任务、期望行为、评分标准的 eval 样例。
我能区分任务成功率和工具调用正确率。
我能说清人工评估和自动评估各自的适用场景。
我能说清统计显著性为什么影响评估结论。