第 2 章：评估方法论全景
第 2 章：评估方法论全景
本章核心
不存在"万能"的评估方法论。 评估范式的选择取决于三个因素：评估目标（衡量什么）、评估对象（Agent 的哪个层次）、资源约束（成本、时间、标注能力）。
这一章回答三个问题：
- 评估方法论有哪些范式？每种范式的适用边界、信号质量和工程成本是什么？
- 当评估对象从"单轮问答"变成"多轮对话"、从"最终答案"变成"完整轨迹"时，方法论上发生了什么变化？
- 一套评估指标应该怎么分层？哪些坑是"对评估本身的评估"（效度与可靠性）？
2.1 五大评估范式
Beyond the Leaderboard: A Survey of the Science of Evaluation, Benchmarking, and Methodologies for LLMs（IEEE Access, Vol.14, 2026）把评估方法论系统分类为五种范式：
| 范式 | 核心机制 | 信号质量 | 工程成本 |
|---|---|---|---|
| 静态基准 | 固定题目集 + 确定性判分 | 高可比性，但易饱和/污染 | 低 |
| 动态自适应评估 | 题目随模型表现动态调整（如 LiveCodeBench） | 抗污染，跟踪能力上限 | 中 |
| 交互式 Agentic 评估 | 在模拟/真实环境中让 Agent 执行任务 | 贴近真实，但难复现 | 高 |
| 人在回路评估 | 人类标注员/专家参与评分 | 最可信，但慢且贵 | 最高 |
| 模型评估（LLM-as-a-Judge） | 用 LLM 给 LLM 打分 | 可扩展，但有偏差 | 中低 |
没有哪个范式是"最好的"——它们是互补的。
选型逻辑可以这样概括：
- 要横向对比（"我的模型 vs 别人的模型"）→ 用静态基准 + 动态基准
- 要验证 Agent 能力（"我的 Agent 能不能在真实场景干活"）→ 用交互式 Agentic 评估
- 要最终放行（"能不能上线"）→ 人在回路 + 模型评估混合
- 要规模化自动化（"每次 commit 都测"）→ 模型评估（LLM-as-a-Judge）
一个常被忽视的原则：五种范式的信号质量与工程成本大致正相关。 最可信的（人在回路）最贵最慢，最便宜的（静态基准）信号最容易失真。成熟的评估体系一定是多种范式的组合，而不是押注单一范式。
2.2 多轮对话评估的专门方法论
Agent 与用户的交互几乎都是多轮的：用户提出需求 → Agent 调用工具 → 返回结果 → 用户补充 → Agent 继续……评估这种多轮交互，与评估单轮问答有本质区别。
Evaluating LLM-based Agents for Multi-turn Conversations（ACM TIST, 2026）通过 PRISMA 框架系统回顾了近 250 篇文献，建立了两个相互关联的分类系统：
评估什么（评估对象）
| 维度 | 回答的问题 |
|---|---|
| 任务完成 | Agent 是否达成了用户的最终目标？ |
| 响应质量 | 每一轮的回答是否正确、有用、自然？ |
| 用户体验 | 用户是否感到顺畅、被理解、有掌控感？ |
| 记忆与上下文保持 | Agent 是否记住了前几轮的关键信息？ |
| 规划与工具集成 | Agent 是否合理地拆解任务、正确地调用工具？ |
如何评估（评估方式）
| 方式 | 说明 |
|---|---|
| 标注评估 | 人类标注员对每轮/整体评分，最可信但贵 |
| 自动化指标 | 规则、相似度、命中率等确定性指标 |
| 混合策略 | 自动化指标 + 人工抽检 |
| 自评判方法 | Agent/LLM 自己评估自己的对话 |
多轮评估的三个关键难点
难点一：整体 vs 逐轮。 多轮对话里，整体任务成功 ≠ 每一轮都正确。一个 Agent 可能某轮回答错了，但最终通过工具调用弥补；也可能每轮都"看起来对"，但整体目标跑偏。评估设计必须明确：是逐轮打分、整体打分、还是两者都看。
难点二：谁的状态是"真相"。 多轮对话中有一个特殊的信噪比问题——Agent 可能在某一轮"自己编造了一个数字"，而工具实际返回了另一个。评估中间步骤，必须捕获推理轨迹（reasoning trace）来区分"Agent 自己编的"和"工具真实返回的"。这是 2.3 节轨迹评估要解决的核心问题。
难点三：对话是开放的。 用户下一轮说什么，取决于 Agent 上一轮答了什么。硬编码的测试脚本无法覆盖这种开放性。这就是 Google ADK 提出 User Simulation（第 5 章详述）的原因——用 LLM 驱动的模拟用户动态生成对话，而不是预写脚本。
2.3 轨迹评估与中间步骤评分
为什么要评估轨迹
Agent 评估的核心挑战：不仅要评估最终答案，还要评估"通往答案的逻辑"。
一个 Agent 给出了正确答案，但可能是靠碰运气、作弊、或走了错误但偶然成功的路径。一个 Agent 答错了最终答案，但它的工具调用序列是完美的，只是最后一步归纳错了。只看最终答案，这两种情况都无法区分。
轨迹（trajectory） 是 Agent 完成任务过程中的完整动作序列：思考 → 工具调用 → 工具返回 → 再思考……评估轨迹，就是评估"过程质量"而非"结果质量"。
Google Cloud 的实践方案
Google Cloud 的实践方案（见 From "Vibe Checks" to Continuous Evaluation，Google Cloud Blog, 2026）通过 ADK 的 POST /run_sse 端点捕获 Agent 的推理轨迹，包括：
- 工具调用请求与响应
- 中间事件
- 每一步的模型输出
捕获的轨迹被用于工具轨迹评估。ADK 支持的评估指标：
| 指标 | 评估内容 | 是否必需 |
|---|---|---|
| tool_trajectory_avg_score | 工具调用序列的精确匹配 | 是 |
| response_match_score | 最终响应的相似度 | 是 |
| 自定义函数指标 | 业务规则（如"必须调用 Wikipedia 工具"） | 可选 |
自定义函数指标在安全沙箱中对评估数据集的每一行执行，实现严格定义的业务规则校验。它的价值在于：把"是否走了正确的路"编码成确定性规则，而不是依赖 LLM 判断。
轨迹评估的两种做法
做法一：期望轨迹匹配（Golden Path）。 预先定义"正确"的工具调用序列（expected trajectory），然后把 Agent 实际轨迹与期望轨迹对比，计算精确匹配率（tool_trajectory_avg_score）。优点：确定性、可复现。缺点：Agent 可能用不同但同样正确的路径完成任务，导致误判。ADK 的 golden-path 方法属于这一类。
做法二：轨迹级规则校验。 用自定义函数指标检查"是否满足业务约束"——比如"查询前必须调用权限校验工具""财务类任务必须调用计算器工具"。这类规则不要求精确匹配，只要求满足关键约束，容错性更好。
中间步骤评估的经典案例
一个区分"Agent 编造"与"工具真实返回"的经典场景：Agent 回答"当前 GPU 使用率是 87%"。这句话是否可信，取决于 87% 这个数字来自哪里：
- 如果 Agent 调用了
nvidia-smi工具并读取了输出 → 可信 - 如果 Agent 直接凭记忆/编造 → 不可信
只有捕获了推理轨迹，评估器才能区分这两种情况。 这也是第 8 章"轨迹标注"和第 2.5 节"评估效度"共同关注的问题：评估必须建立在"可验证的过程证据"之上，而不是"看起来合理的结果"。
2.4 评估指标的层次化体系
一套工程可用的 Agent 指标，至少分三个层次：
组件级：单个环节的质量
- 检索质量：Context Precision（检索到的相关项是否排前）、Context Recall（相关项是否都被检索到）
- 生成质量：Faithfulness（生成是否基于提供的上下文，抗幻觉）、Answer Relevancy（答案与问题的相关性）
组件级指标的价值：定位问题出在哪一环。RAG Agent 表现差，可能是检索环节（没检索到相关文档）、生成环节（检索到了但答非所问）、或两者都有。分层指标让你不用猜。
轨迹级：整条执行链的质量
- 工具使用正确率：工具调用是否恰当、参数是否正确
- 轨迹效率：完成任务用了多少步、多少 token——同样的任务，5 步完成优于 15 步
- 错误恢复率：首次失败后能否调整策略重试成功
轨迹级指标是 Agent 特有的——单轮问答没有"轨迹"这个概念。
系统级：整体表现
- 任务完成率：端到端成功率
- 用户满意度：人类反馈/偏好
- 安全性：越狱成功率、PII 泄露率、禁止动作触发率
一个工程可用的五维度度量表
Evaluation-First AI Agent Development（本项目博客 2026-08-28）给出一个更贴近生产的五维度体系：
| 维度 | 典型指标 | 为什么要看 |
|---|---|---|
| 正确性 | Pass rate、Partial reward、EM/F1 | 主指标，但不是全部 |
| 成本 | 每任务平均 API cost、每千任务 total cost | 上线不能亏 |
| 速度 | Mean/P95 latency、平均 step 数、token 消耗 | 用户体验天花板 |
| 可靠性 | 成功率/崩溃率/超时率/幻觉率 | 稳定性决定能否进生产 |
| 安全合规 | PII 泄露率、禁止动作触发率、越狱成功率 | 红线越早测越安全 |
一个典型的发布决策不是"正确性涨了"，而是这种综合判断：
正确性从 76.1 → 78.3（+2.2），但每任务平均 cost 从 $0.14 → $0.38（+170%），P95 latency 从 120s → 210s。所以不接受这次改动，除非同时有成本优化方案。
只看正确性会掩盖成本与延迟的退化——这正是 2.5 节要讲的"评估效度"的实践体现。
分桶分析：让分数可操作
一个分数（"我们在 X 上 84.2 分"）几乎没有可操作价值。分桶分析才是迭代的燃料：
- 按难度桶：Easy/Medium/Hard——总分涨了但 Hard 掉了是常见陷阱
- 按任务类型桶：文件编辑/环境配置/模型训练……
- 按失败原因桶：工具调用错误/规划失误/Verifier 误判/环境问题/API 超时
- 按 Prompt 版本桶：v1 vs v2 vs v3 跨版本对比
举一个真实案例（来自 evaluation-first 博客）：团队在 Terminal-Bench 上从 62 涨到 65 分，但分桶一看——Medium 任务从 58 → 64（涨 6 分），Hard 任务从 21 → 18（掉 3 分）。做硬任务的同事反馈"感觉最近变差了"，而总分掩盖了这个信号。总分涨了，但 hardest 子集跌了。
2.5 评估的效度与可靠性：对"评估"本身的评估
这一层是最容易忽略、却是自己搭 Eval 时最先踩坑的元科学（meta-science）。
测量噪声：单次跑分不可信
Agentic 评估因种子与环境的随机性，pass@k 方差可能极大。同一个 (Agent, Model, Dataset) 组合，多次运行的结果可能差 5-10 分。单次跑分不可信，要报告均值 ± 置信区间。
标准做法：
- 对同一组合跑 N 次重复（N≥3，一般取 5），报告 Mean ± 95% CI
- 判断"改动有效"的标准：旧版本最高分 < 新版本最低分（或做 Welch t-test / Mann-Whitney U test，p < 0.05）
- 小规模改动（±1-2 分、CI 重叠）不要急着合并——大概率是噪声而不是提升
统计显著性：差 2 分不等于真差 2 分
两个 Agent 在一个 100 题的评测集上差 2 分，从统计上看几乎一定是噪声。要估计误差棒，用：
- 配对比较：同一批用例上对比两个 Agent
- A-B 测试：分桶对比
- Bootstrap：重采样估计置信区间
不要直接比排行榜上的两个数字——除非你知道每个数字的置信区间。
Test-retest 稳定性与 flaky 用例
同一评估在同配置下重复运行，是否得到相近结果？如果波动过大，说明评估本身不可靠。flaky 用例（时过时不过的用例）要识别并剔除——它们贡献的是噪声而不是信号。
评估协议标准化
prompt、数据集、grader 都要固定版本，否则比较失去意义。LLM Stats 的做法（prompt、数据集、grader 固定到版本，历史分数不变）是标准范本。回到第 1 章的核心论点：元信息决定可比性。
成本与效率指标：评估不仅要"准"，还要"快且便宜"
除正确率外，评估还应纳入：
- $/task、token/task
- 延迟-质量帕累托（ARC-AGI-2 的 efficiency-aware 评分即是范例）
把"多快多贵"和"多准"一起看，才能指导生产选型。一个在评测上又快又便宜的方案，即使正确率略低，也可能在 Pareto 前沿上优于"最准但最贵"的方案（详见第 8 章 8.6 选型决策矩阵）。
一个必须记住的陷阱
用 LLM-as-judge 做主 reward，而判官一致性比被测 Agent 还低——分数是假的。
开放式任务用 LLM judge 做主指标有方差风险。安全做法：LLM judge 只用于失败原因分类 / 开放式内容的辅助检查，主 reward 用代码化、确定性的 verifier。（详见第 3 章 LLM-as-a-Judge 与第 8 章评分器策略。）
本章小结
- 五大评估范式（静态/动态/交互式/人在回路/模型评估）互补，信号质量与工程成本大致正相关
- 多轮对话评估有两个分类轴：评估什么（任务/响应/体验/记忆/规划）× 如何评估（标注/自动化/混合/自评判）
- 轨迹评估关注"过程质量"而非"结果质量"，用期望轨迹匹配 + 轨迹级规则校验
- 指标分组件级/轨迹级/系统级三层，工程上配合五维度度量表 + 分桶分析
- 评估效度与可靠性是"对评估本身的评估"：测量噪声、统计显著性、test-retest、协议标准化、成本效率
参考资料
论文与综述
- Beyond the Leaderboard: A Survey of the Science of Evaluation, Benchmarking, and Methodologies for LLMs（IEEE Access, Vol.14, 2026）— 五范式分类
- Evaluating LLM-based Agents for Multi-turn Conversations: A Survey（ACM TIST, 2026）— 多轮对话评估双分类系统
- Evaluation and Benchmarking of LLM Agents: A Survey（KDD 2025 Tutorial）— 二维分类法：评估目标 × 评估过程
官方文档
- Google ADK Evaluation 文档（adk.dev）— 轨迹评估、golden path、
POST /run_sse - From "Vibe Checks" to Continuous Evaluation（Google Cloud Blog, 2026）— 推理轨迹捕获、运行时 Schema 集成
- Implement LLM-as-Judge Evaluation for Multi-Agent Systems（Microsoft Learn）
博客与文章
- 基于 Evaluation 的 AI Agent 开发实践全景指南（本项目博客 2026-08-28）— 五维度度量表、分桶分析、统计显著性的数据来源