Evaluation Pipeline：Agent 效果怎么评估
这篇文章解决什么问题
很多 AI 应用上线前只靠人工试几个问题判断效果，但 Agent / RAG 项目一旦变复杂，就必须回答：
- 版本升级后效果有没有变好？
- RAG 召回是否稳定？
- 工具调用是否正确？
- Agent 是否完成任务？
- 成本是否可控？
- 失败样本是否减少？
- 哪些场景需要人工兜底？
"看起来不错"不能作为工程判断。测试问题太少、容易只看成功样例、模型输出不稳定、Prompt 改动可能引入回归、RAG 文档更新可能影响召回、工具调用成功不代表任务完成——这些都让主观感觉不可靠。
核心观点：Evaluation 的目标不是给模型打一个分，而是持续发现问题、比较版本、指导迭代。
为什么不能只靠主观感觉
"我试了几个问题，感觉还行"——这是很多 AI 项目上线前的评测方式。但它有几个致命问题：
测试问题太少。人工试 5 个问题不能代表真实场景的多样性。用户会问出你想不到的问题，边界情况不会在 demo 中出现。
容易只看成功样例。人天然倾向于挑效果好的案例展示，忽略了失败的 case。但真正影响用户体验的是那些失败的 case。
模型输出不稳定。同一个问题问两次，可能得到不同的答案。人工试一次"通过"不代表每次都能通过。
Prompt 改动可能引入回归。优化了 A 场景的 Prompt，可能导致 B 场景退化。没有回归测试，退化悄悄发生。
RAG 文档更新可能影响召回。知识库更新后，原来能召回的文档可能被新文档"挤掉"。没有评测就不知道召回质量是否下降。
工具调用成功不代表任务完成。工具返回了结果，但结果可能不对。Agent 调用了正确的工具，但参数可能有问题。
工程判断需要量化指标和系统化评测，而不是主观感觉。
Evaluation Pipeline 总览
测试集准备 → 执行评测 → 记录输出 → 计算指标 → 人工抽检 → 生成报告 → 版本对比 → 失败样本入库 → 迭代优化每一步的作用：
| 阶段 | 作用 |
|---|---|
| 测试集准备 | 构建覆盖常见场景、边界情况和已知失败案例的测试用例 |
| 执行评测 | 批量运行测试集，收集 Agent 的实际输出 |
| 记录输出 | 保存每次评测的输入、输出、Trace、指标，支持后续分析 |
| 计算指标 | 根据预期输出和实际输出计算各项评测指标 |
| 人工抽检 | 对自动评测结果进行人工验证，发现自动评测遗漏的问题 |
| 生成报告 | 汇总评测结果，对比历史版本，标注退化项 |
| 版本对比 | 对比不同版本的指标变化，量化改进幅度 |
| 失败样本入库 | 把失败案例收集到失败样本库，分析失败模式 |
| 迭代优化 | 根据失败分析调整 Chunk、Prompt、工具、检索策略 |
这九步形成一个闭环：优化后重新执行评测，验证改进效果，发现新的失败，继续迭代。
测试集怎么设计
测试集不是一次性写完，而是随着失败样本持续增长。
| 测试集类型 | 覆盖内容 | 来源 |
|---|---|---|
| RAG QA 测试集 | 常见问答、边界查询、多文档关联 | 人工编写、线上收集 |
| 工具调用测试集 | 工具选择、参数正确性、错误处理 | 人工编写、Trace 提取 |
| 多轮任务测试集 | 上下文理解、多步推理、状态维护 | 人工编写、用户对话 |
| 多 Agent 协作测试集 | 任务分派、结果聚合、错误传播 | 人工编写、场景设计 |
| 安全边界测试集 | 越权访问、高风险操作、敏感信息泄露 | 安全团队设计 |
| 回归测试集 | 历史正常 case、历史修复 case | 持续积累 |
| 线上失败样本集 | 线上发现的失败案例 | 用户反馈、自动收集 |
每条测试用例包含：
id：唯一标识input：输入expected_output：预期输出tags：场景标签、难度等级expected_tools：期望调用的工具（Agent 评测用）expected_citations：期望引用的来源（RAG 评测用）
测试集应该版本化管理。每次更新测试集都记录变更原因——新增了什么 case、淘汰了什么 case、为什么。
RAG 评测指标
| 指标 | 关注点 |
|---|---|
| Recall@K | 正确文档或 Chunk 是否出现在前 K 个检索结果中 |
| Context Precision | 进入上下文的内容中有多少是相关的 |
| Context Recall | 答案所需信息是否被上下文覆盖 |
| Faithfulness | 答案是否忠实于给定上下文 |
| Answer Relevance | 答案是否真正回答了用户问题 |
| Citation Accuracy | 引用是否指向支持答案的正确来源 |
| Human Review | 人工从业务正确性和可用性角度复核 |
RAG 要分开评估召回质量、上下文质量、答案质量和引用准确性。不能只看最终答案对不对——答案对但引用错、答案对但召回差、召回好但上下文组织混乱，都是不同类型的问题，需要不同的优化策略。
Recall@K 评估召回阶段。正确文档没进候选集，后面的 Rerank 和生成再强也补不回来。
Faithfulness 评估生成阶段。上下文里没有的信息，答案不应该包含。Faithfulness 低说明模型在编造。
Citation Accuracy 评估引用阶段。答案正确但引用错误，会降低可信度，也会影响问题排查。
Human Review 是最后的兜底。自动评测能覆盖大部分场景，但边界案例、业务正确性、用户体验还需要人工判断。
Agent 任务评测指标
| 指标 | 关注点 |
|---|---|
| Task Success Rate | Agent 是否成功完成了用户任务 |
| Tool Call Accuracy | 是否选择了正确的工具、参数是否正确 |
| Step Completion | 每个步骤是否按预期完成 |
| Error Recovery | 遇到错误时是否能正确重试或降级 |
| Latency | 完成任务的总耗时 |
| Cost | 完成任务的 token 消耗和成本 |
| Human Intervention Rate | 需要人工介入的比例 |
| Safety Violation Rate | 触发安全规则的比例 |
Agent 评测不能只看最终文本，还要看任务是否真正完成、工具是否正确调用、失败是否能恢复。
Task Success Rate 是最核心的指标，但不能只看它——成功率高但耗时过长、成本过高、频繁触发安全规则，都不是好的 Agent。
Tool Call Accuracy 帮助发现工具选择和参数生成的问题。如果 Agent 经常选错工具，说明工具描述不够清晰或模型能力不足。
Error Recovery 评估 Agent 的鲁棒性。真实环境中工具会失败、网络会超时、权限会不足。Agent 能不能从错误中恢复，决定了它是否能在生产环境稳定运行。
Human Intervention Rate 反映 Agent 的自主能力。需要频繁人工介入的 Agent 还不够成熟，但也不能完全不给人工介入的入口。
自动评测与人工抽检
自动评测适合大规模、高频的评测场景：
- 格式检查：输出格式是否符合预期，引用格式是否正确
- 引用检查：引用是否指向真实存在的来源，是否支持答案
- 工具调用参数检查：参数类型、范围、格式是否正确
- 指标统计：Recall@K、Faithfulness、Task Success Rate 等可量化指标
- 回归测试：每次修改后自动运行，确保没有引入退化
人工抽检适合小规模、深度评测场景：
- 业务正确性：答案在业务语境下是否正确，不能只看字面匹配
- 用户体验：回答是否自然、是否有用、是否让人信任
- 复杂推理：需要多步推理或领域知识才能判断的场景
- 边界场景：自动评测难以覆盖的边界情况
- 安全风险判断：是否存在隐含的安全风险
两者互补：自动评测做覆盖面，人工抽检做深度。
版本对比
每次修改 Prompt、模型、Embedding、Chunk、Rerank、工具 Schema 后，都应该能对比：
| 对比维度 | 关注点 |
|---|---|
| 指标变化 | 新版本是否提升，提升了多少 |
| Case 变好 | 哪些 case 从失败变成成功 |
| Case 退化 | 哪些 case 从成功变成失败 |
| 成本变化 | token 消耗是否增加 |
| 延迟变化 | 响应时间是否增加 |
版本对比的关键是"可归因"。指标下降时，要能定位到具体是哪些 case 退化了，退化的原因是什么——是检索变差了、工具选错了、还是 Prompt 改坏了。
没有版本对比，就无法量化改进幅度。"感觉变好了"不是工程标准，"Recall@5 从 0.72 提升到 0.81，Task Success Rate 从 0.65 提升到 0.73"才是。
版本对比需要保存历史评测结果。每次评测的指标、输出、Trace 都应该持久化存储，支持随时回溯和对比。
失败样本库
失败样本库是 Evaluation Pipeline 最有价值的产出。
失败样本来源：
- 用户反馈：用户标记"答案无用"或"回答错误"
- 线上错误：Agent 执行失败、超时、异常
- Trace 中的失败 run：status 为 failed 的所有 run
- 人工抽检：人工评审发现的隐含错误
- 自动评测失败 case：指标不达标的测试用例
失败样本字段建议：
| 字段 | 作用 |
|---|---|
case_id | 唯一标识 |
input | 用户输入 |
expected_behavior | 期望行为 |
actual_output | 实际输出 |
failure_type | 失败类型（检索失败/工具失败/生成错误/权限拦截等） |
related_run_id | 关联的 Trace run_id |
related_trace | 关联的完整 Trace |
severity | 严重程度（critical / major / minor） |
fixed_version | 修复版本号（修复后标记） |
失败样本驱动迭代的路径：
- 收集失败样本
- 按 failure_type 分类
- 分析每类失败的根因
- 针对性优化（调 Chunk、调 Prompt、修工具、加权限）
- 把失败样本加入回归测试集
- 重新评测，验证修复
最小 Evaluation Pipeline 伪代码
def run_evaluation(eval_cases, agent_version):
eval_run_id = create_eval_run(agent_version)
for case in eval_cases:
# 执行 Agent
result = run_agent(case.input)
# 计算指标
metrics = calculate_metrics(
expected=case.expected,
actual=result.output,
trace=result.trace,
)
# 保存评测结果
save_eval_result(
eval_run_id=eval_run_id,
case_id=case.id,
output=result.output,
metrics=metrics,
run_id=result.run_id, # 关联 Trace
)
# 生成评测报告
report = build_eval_report(eval_run_id)
return report这个伪代码的核心思路：每个测试用例都执行 Agent 并记录输出和指标。评测结果通过 run_id 关联到 Trace，失败后可以通过 Trace 定位原因。最后生成评测报告，包含整体指标和失败 case 列表。
与 Trace 的关系
Evaluation 判断结果质量，Trace 提供原因解释。
两者联动的完整流程：
- 运行评测，发现某个 case 失败
- 通过
run_id找到对应的 Trace - 查看 Trace 中每个 Step 的输入输出
- 定位失败原因：检索失败？工具失败？模型输出错误？权限拦截？
- 把失败原因记录到失败样本库
- 针对性优化
- 重新评测，验证修复
- 失败样本加入回归测试集
没有 Trace，评测失败后只能看到"答案不对"，不知道为什么不对。没有 Evaluation，Trace 只能告诉你"做了什么"，不知道"做得好不好"。两者结合才能形成完整的质量闭环。
常见误区
误区一：只看人工感觉
"我试了几个问题感觉还行"不能作为工程判断。需要量化指标和系统化评测。
误区二：只看最终答案，不看工具调用
Agent 的任务完成可能依赖多个工具调用。只看最终答案，忽略了中间步骤的错误。
误区三：只测成功样例
只测"能跑通"的 case，不测边界情况和已知失败案例。评测结果虚高，上线后问题频发。
误区四：Prompt 改了不做回归测试
优化了 A 场景，可能导致 B 场景退化。没有回归测试，退化悄悄发生。
误区五：RAG 改了 Chunk 不重新评测
Chunk 策略变化可能影响召回质量。不重新评测就不知道改动是变好了还是变差了。
误区六：没有版本对比
无法量化改进幅度，无法判断优化是否有效。"感觉变好了"不是工程标准。
误区七：没有失败样本库
失败样本是最宝贵的优化资源。不收集、不分析、不迭代，优化就是盲目的。
误区八：评测指标和业务目标脱节
评测指标应该反映业务价值。Recall@K 很高但用户满意度低，说明指标设计有问题。
对个人项目的启发
通用迁移思路：不管做什么类型的 AI Agent 项目，评测 Pipeline 都应该从第一天就设计进去。先建测试集，再做优化。每次修改后运行回归测试。失败样本持续收集和分析。这些是 Agent 工程的通用骨架，不绑定具体业务。
项目 A RAG 工单系统：
- 构建 RAG QA 测试集，覆盖常见工单查询、边界查询和多文档关联。
- 评估 Recall@K（召回质量）、Faithfulness（答案忠实度）、Citation Accuracy（引用准确性）。
- 用户反馈（标记"答案无用"）自动进入失败样本库，定期分析后更新测试集和优化策略。
项目 B 多 Agent Copilot：
- 评估任务完成率（Task Success Rate）、工具调用准确率（Tool Call Accuracy）、错误恢复能力（Error Recovery）。
- 多 Agent 输出要做结果聚合质量评估——每个 Agent 的结果是否正确，聚合后的最终结果是否正确。
- 高风险工具调用（删除、发送、修改）要纳入安全评测，评估 Safety Violation Rate。
面试表达
我会把 Agent / RAG 效果评估做成 Pipeline，而不是靠人工试几个问题。评测 Pipeline 包含测试集准备、执行评测、计算指标、人工抽检、生成报告、版本对比、失败样本入库、迭代优化九个阶段，形成持续改进的闭环。
RAG 要分别评估召回质量（Recall@K）、上下文质量（Context Precision / Recall）、答案质量（Faithfulness / Answer Relevance）和引用准确性（Citation Accuracy）。不能只看最终答案对不对——答案对但引用错、答案对但召回差，都是不同类型的问题。Agent 要评估任务完成率、工具调用准确率、错误恢复能力、成本和安全风险。不能只看最终文本，还要看任务是否真正完成。
评测结果要和 Trace 关联——评测失败后通过 run_id 找到 Trace，逐层定位失败原因。失败样本要进入后续迭代——每次发现的新失败模式都应该被加入回归测试集。版本对比要能量化改进幅度——Recall@5 从 0.72 提升到 0.81，Task Success Rate 从 0.65 提升到 0.73。
后续 TODO
- 补充 RAG 评测样例，包括测试用例标注和评测脚本。
- 补充 Agent 任务评测样例，包括多步任务的评测方法。
- 补充 Evaluation Report 模板，展示评测报告的结构和内容。
- 补充与 Agent Trace 的联动设计，展示失败 Trace 如何自动生成评测用例。
相关链接
- Evaluation Pipeline 工程化笔记 — 更详细的工程化知识点
- Trace 与 Evaluation — 评测方法论
- Agent Trace 执行轨迹 — Trace 记录方案
- RAG 工程化笔记 — RAG 评测指标
- 从 RAG 到生产级 Agent Harness 的工程化学习路线 — 完整学习路线