FDE W6D1 学习手册 · Agent 评测体系
W6 Day1 · A 级(必须掌握,面试核心)· 4h · 学完能讲透"Agent 评测与 RAG 评测的本质区别,以及 Agent Eval 的核心指标怎么设计"
本日定位:W3 已建立 RAG Eval 体系,W6 进入"Agent 上线前的工程化评测"。Day1 回答一个核心问题:当模型从"一问一答"变成"多步调工具完成任务",怎么衡量它做对了没有。这是 FDE 面试高频考点。
学完能回答:① Agent Eval 与 RAG Eval 的区别(任务级 vs 检索级);② 任务完成率/工具成功率/Human Approval 准确率/错误恢复率/单任务成本怎么定义和测算;③ OCR/Rule/Database 等单 Tool 怎么单独评测;④ 拒答与高风险漏判怎么测。
使用方法:通读原理 → 重点看「面试话术」「易错点」→ 做自测清单 → 配合《FDE-W6D1-评测题.md》。选中不熟的词可标注(左下★重要 / 右下📌待查)。
一、评测体系总览:从 RAG Eval 到 Agent Eval
评测对象决定评测方法。RAG 是"检索+生成"的单轮管道,Agent 是"目标拆解→调工具→观察→再决策"的多步闭环。两者评测粒度不同:
| 维度 | RAG Eval | Agent Eval |
| 评测对象 | 单次问答(检索+回答质量) | 一次完整任务(多步轨迹) |
| 核心问题 | 答案对不对、有没有幻觉、引用准不准 | 任务有没有完成、工具调对没有、风险有没有漏 |
| 指标层级 | 检索级(召回/精度)+ 生成级(忠实性/相关性) | 任务级(完成率)+ 工具级(成功率)+ 风险级(漏判率) |
| 失败表现 | 答错、漏引用 | 跑偏、乱调工具、漏判高危、成本爆炸 |
关键认知:Agent 评测是 RAG 评测的上层。Agent 在"调知识库工具"这一步内部仍然跑 RAG,所以 W3 的 RAG Eval 被继承为 Agent 内部子环节的评测,但 Agent Eval 额外覆盖"任务编排层"和"工具执行层"。
工程上要把 Agent Eval 拆成三层看:① 任务层(最终目标达成没);② 轨迹/工具层(每一步工具调得对不对、参数对不对);③ 风险层(该转人工的有没有转、高危 case 有没有漏)。只测最终答案会漏掉"碰巧答对但过程全错"的假阳性。
一句话:RAG 评的是"一次回答好不好",Agent 评的是"一个任务办没办成"。Agent 评测要同时看任务结果、工具调用过程、风险漏判三件事,而 RAG Eval 是它内部"查知识库"那一步的子评测。
① 别把"最终答案对"当成"Agent 评测通过"——模型可能乱调工具、调错库、碰巧编出正确答案,过程全错但结果蒙对(假阳性),这种在上线后极危险。② 评测集规模不要盲目求大:Agent 评测贵(每 case 跑多步、多 token),30 个高质量任务 case + 50 个 RAG case 远胜 300 个注水 case。③ 不要把 RAG 的指标(如 faithfulness)直接当 Agent 指标用,维度不对。
二、继承 W3:RAG Eval 50 Cases 设计与指标
W3 已沉淀 50 个 RAG 问答 case,作为 Agent 内部"查保险知识库/特药目录"的底层评测。Agent 场景下这 50 case 仍要保留并定期回归,因为 Agent 幻觉往往源于知识库这一步出问题。
2.1 RAG Eval 核心指标
| 指标 | 含义 | 怎么算 | 保险场景示例 |
| Faithfulness(忠实性) | 答案是否完全基于检索内容 | 抽答案中每个claim,判是否能在参考资料中找到 | "奥希替尼限二线"必须有条款出处,否则判不忠实 |
| Answer Relevancy(相关性) | 答案是否切题 | 用答案反推问题,看相关性 | 问报销比例,答用药禁忌=不相关 |
| Context Recall(上下文召回) | 该检索的文段有没有召回到 | 标准答案所需证据是否在召回 top-k | 特药适应症条款是否在召回里 |
| Context Precision(上下文精度) | 召回里相关的排得靠前没 | 相关文段在 top-k 中的排序质量 | 正确条款排第 1 而非第 8 |
| 拒答准确率 | 无答案时应拒答 | should_refuse case 中正确拒答比例 | 知识库无此药→答"未查询到",不硬编 |
2.2 用 RAGAS 落地
官方文档 docs.ragas.io 提供这些指标的无参考/有参考实现。典型用法:把每次 RAG 的 question / contexts / answer / reference 喂给 RAGAS 算分。
在特药理赔 Agent 里,一次"用户问某药能不能报"会触发知识库检索。这个子环节必须用 W3 的 50 case 持续回归:如果某次 Prompt 改动让 Context Recall 掉 5 个点,Agent 整体就会开始乱答,但任务层指标可能看不出来——必须分层监控。
RAG Eval 看"检索到的内容对不对、答案是否忠于检索"。用 RAGAS 的 Faithfulness/Answer Relevancy/Context Recall/Precision 五指标。这 50 case 在 Agent 时代仍要保留,作为"查知识库"那一步的回归基线。
① RAG Eval 分数高 ≠ Agent 评测通过,它只覆盖 Agent 内部一步。② 引用(citation)质量要单独评:模型说"依据条款 X"但实际检索里没有 X,是典型幻觉,必须查引用可追溯性。③ 拒答 case 容易被漏测——要专门留 should_refuse 样本。
三、Agent Eval 核心:任务完成率
任务完成率是 Agent Eval 的"总开关"指标,衡量给定目标是否被完整、正确地达成。
任务完成率 = 任务结果被正确达成数 / 任务总数 × 100%
3.1 "完成"的判定
- 目标达成:最终产物满足业务预期(如生成了合规的理赔初审意见书)。
- 过程正确:路径没走偏、没调错工具、没违反约束(不只要结果对,过程也要对)。
- 不破坏约束:没越权、没泄露、没产生危险动作。
3.2 判定方式
| 方式 | 做法 | 优劣 |
| LLM-as-Judge | 用强模型对照标准答案/评分细则给完成度打分 | 快、可规模化,但有评委偏差,要校准 |
| 规则/确定性校验 | 对最终产物做结构化断言(字段齐全、金额在区间、状态正确) | 客观可靠,覆盖不了"语义质量" |
| 人工标注 | 专家逐条判完成与否 | 金标准,慢、贵,用于抽检验证 |
特药理赔 Agent 的"任务完成"不能只看"有没有出意见书",还要校验:金额计算正确、引用条款真实、风险等级字段存在、高风险已触发人工。否则"生成了一份看起来对的文书但金额算错"也该算未完成。
任务完成率 = 正确完成的任务数 / 任务总数。判定要兼顾"结果对 + 过程对 + 不违规",不能只看最终产物。落地用 LLM-Judge + 确定性规则校验 + 人工抽检验证三层。
① 只靠 LLM-Judge 判完成率会有系统性偏差(评委模型偏好长答案、爱给高分),必须和确定性校验/人工抽检交叉验证。② "结果对但过程错"仍是失败——要防止碰巧蒙对。③ 任务定义要写清"什么叫完成",否则评分不可复现。
四、工具调用正确率(工具成功率)
Agent 的核心能力是调工具。这一指标衡量"该调的工具调了、参数对了、时机对了"。
工具调用正确率 = 工具调用正确的步数 / 总工具调用步数 × 100%
4.1 三个子维度
- 工具选择正确:该查 OCR 没去查数据库,该调 Rule 引擎没去瞎编。
- 参数正确:传给工具的参数对(如 OCR 的图片 id、SQL 的过滤条件、金额单位)。
- 时机/顺序正确:先查身份再查权益,而不是反过来导致越权查。
4.2 评分
可逐条标注每个 tool_call 是否为"理想轨迹"中的一步(可用 W3 沉淀的标准轨迹做对照),或让 LLM-Judge 对照"标准工具序列"打分。
保险场景里工具错用危害极大:把"调 OCR 识别发票"错成"调规则引擎直接拒赔",或把金额单位传错(元/分),都会直接造成错赔。工具级评测能在任务层还没暴露前抓到这类问题。
工具调用正确率看"选对工具、参数对、顺序对"。它比任务完成率更细,能在"结果碰巧对"时抓出过程错误。评测可对照标准工具轨迹,或 LLM-Judge 判每步。
① 工具"调成功"(HTTP 200)≠"调正确"(语义对),要区分执行成功率和语义正确率。② 多轮里工具顺序错也很常见(先查权益后验证身份→可能越权),顺序也要评。③ 不要只看最终有没有调某个工具,要看整条轨迹。
五、人工审批触发准确率(Human Approval 准确率)
企业 Agent 常设"高风险动作需人工审批"闸门。该指标衡量闸门是否"该拦的拦住、不该拦的别误伤"。
| 指标 | 公式 | 说明 |
| 审批触发精确率 | 真正需审批且被触发 / 所有被触发审批 | 误触发越高,人工越烦(误报) |
| 审批触发召回率 | 真正需审批且被触发 / 所有真正需审批 | 漏触发越危险(漏报) |
| 误触发率 | 不需审批却被触发 / 全部 | 影响效率,要压低但不宜压到 0 |
5.1 哪些算"需审批"
- 金额超过阈值的理赔(如 > 5 万)。
- 命中高风险关键词(疑似欺诈、罕见病超适应症用药)。
- 知识库无把握、模型 should_refuse 但业务要求人工兜底的情形。
审批闸门是"安全网"。评测目标是:召回率优先(宁可误拦不可漏放),但误触发率要控制在一个人工能承受的范围。FDE 面试常问"召回和精确怎么取舍"——安全场景一律召回优先。
Human Approval 准确率看闸门对不对:分触发精确率、召回率、误触发率。高风险场景"召回优先"——宁可误拦不可漏放。这跟推荐系统的精确率优先正好相反。
① 不要把审批触发准确率简单当成"准确率"一个数——必须拆精确率/召回率,否则掩盖漏报。② 漏触发(高危没转人工)比误触发严重得多,面试要强调这点。③ 审批阈值要可配置、可回归,改 Prompt 后必须重测闸门。
六、高风险漏判率(最致命指标)
高风险漏判率 = 应识别为高风险却漏判的比例。这是 Agent 上线最不能出问题的指标,直接对应资损与合规风险。
高风险漏判率 = 应判高风险却判为正常的 case 数 / 应判高风险的 case 总数 × 100%
6.1 为什么单列
- 它和"任务完成率"正交:任务可能"完成得很好"但把一笔欺诈理赔判成了正常通过。
- 它和"审批触发召回率"互补:前者看"有没有标高风险",后者看"标了之后有没有转人工"。
- 它的失败成本极高(一笔骗赔可能数十万),所以必须单独盯、单独设达标线(通常要求 0 漏判或极低)。
6.2 怎么测
在评测集里专门构造"看起来正常但暗藏高风险信号"的 case(对抗样本):如发票 OCR 结果被轻微 PS、用药与诊断不符但措辞专业。看 Agent 是否命中风险规则或触发人工。
保险场景的高风险漏判 = 真骗赔被放行、超适应症用药被批准、冒用身份通过。这类 case 在真实流量里稀有但破坏力极大,评测集必须人为过采样、构造对抗样本,不能只靠自然分布(自然分布下你永远测不到漏判)。
高风险漏判率 = 该判高风险却判正常的比例,是最致命指标,和任务完成率正交(任务办成≠风险判对)。必须用对抗样本专门构造稀有高危 case 来测,达标线通常要求接近 0 漏判。
① 自然分布下高危 case 极少,直接跑全量评测会"看起来 100% 没问题"实则根本没测到——必须主动构造对抗样本过采样。② 漏判率达标线要设得比完成率严得多(如 ≤0.5%)。③ 漏判和"误触发"是两件事,别混。
七、OCR / Rule / Database Tool 各 10-20 Cases
单 Tool 也要有自己的迷你评测集,因为 Agent 整体评测掩盖不了"某个 Tool 接口本身不稳"。
| Tool | 评测重点 | 典型 case 设计(各 10-20) |
| OCR Tool | 发票/单据识别准确率、字段抽取、模糊/倾斜/PS 图 | 正常发票、手写单、低清图、被涂改发票、非发票图片 |
| Rule Tool(规则引擎) | 理赔规则判定正确性、边界条件 | 恰好达门槛、超适应症、等待期内、材料不全 |
| Database Tool | SQL 正确性、越权查询、空结果处理 | 正常查询、无记录、越权字段、大结果分页 |
分 Tool 评测的价值:当 Agent 整体完成率下降时,能快速定位是 OCR 识别掉了、还是 Rule 引擎规则改错、还是 Database 查询越权被拦。这是"可观测性"在评测侧的体现。每个 Tool 的 case 要随 Tool 版本一起版本化。
OCR/Rule/Database 各建 10-20 条迷你 case,分别测识别准确率、规则判定、查询正确性。目的是在 Agent 整体掉分时能定位到具体哪个 Tool 出问题,而不是只知道"整体不行"。
① 单 Tool case 不要和 Agent case 重复——Tool case 是"给定输入看输出",绕过 Agent 编排,直接测 Tool 本身。② OCR case 要覆盖对抗样本(涂改/PS),否则上线就被骗。③ 这些 case 也要版本化,Tool 一升级就要回归。
八、错误恢复率与单任务成本
8.1 错误恢复率
Agent 中途某步失败时,能否自我纠正继续完成任务。
错误恢复率 = 发生错误但最终仍成功完成的任务数 / 发生过错误的任务数 × 100%
常见错误:工具返回空、参数被拒、LLM 输出格式错。好的 Agent 应重试/换路而非直接崩。
8.2 单任务成本
| 成本项 | 说明 |
| Token 成本 | 每任务平均输入/输出 token(多步累加惊人) |
| 工具调用成本 | OCR/数据库查询次数 × 单价 |
| 重试成本 | 失败重试多花的 token 与调用 |
| 人工成本 | 触发审批占用的人工时长 |
单任务成本必须作为上线准入指标——一个"答得对但烧了 3 块钱 token、调了 20 次工具"的 Agent 在保险高并发场景下不可接受。评测报告要给出 P50/P95 成本,而不是平均值(平均会掩盖长尾贵 case)。
错误恢复率 = 出错但最终成功的任务 / 出过错的任务,测 Agent 的"鲁棒性"。单任务成本看 token+工具+重试+人工,要报 P95 而非均值,避免长尾贵 case 被平均掩盖。
① 只报平均成本会掩盖"1% 的任务烧了 10 倍 token"的长尾,必须看 P95/P99。② 错误恢复率高不代表好——如果靠疯狂重试堆出来,成本会爆,要和恢复率+成本一起看。③ 重试次数要上限,否则可能死循环。
九、评测集构建方法论:用例分层
高质量评测集不是随机收集,而是按"能力维度 × 难度"分层设计。
| 层 | 目的 | 占比建议 | 示例 |
| Smoke(冒烟) | 主流程不崩 | 10% | 标准理赔材料、常规特药 |
| 功能 | 覆盖各分支 | 40% | 各种拒赔规则、各种工具组合 |
| 边界 | 边界/异常 | 25% | 金额临界、材料不全、超时 |
| 对抗/高风险 | 安全与漏判 | 25% | PS发票、超适应症、欺诈话术 |
构建流程:① 从真实工单/日志抽样;② 由保险业务专家标注"标准答案 + 风险标签 + 是否需审批";③ 注入对抗样本;④ 双人校验标签;⑤ 版本化入库,每次 Prompt/模型/Tool 改动都全量回归。
评测集是"资产"不是"一次性的"。它要像代码一样版本化、评审、随业务演进。尤其保险条款常变,评测集要有人定期更新,否则测的是旧规则。
评测集按 Smoke/功能/边界/对抗四层设计,对抗样本占 ~25%。来源是真工单抽样 + 专家标注 + 对抗注入,双人校验,版本化。核心思想:测的不是"常见情况",而是"会出事的情况"。
① 评测集分布要和真实分布解耦——真实分布里高危 case 极少,全靠真实抽样永远测不到漏判。② 标签要双人校验,单人来标注会有主观偏差。③ 评测集不更新 = 测旧业务,条款一变全失效。
十、评测执行流程与离线回归
Agent 评测要自动化、可重复,核心是"跑一批 case → 收集轨迹 → 算各层指标 → 出对比报告"。
# 离线评测伪代码骨架
for case in eval_set: # 30 任务 + 50 RAG + 各 Tool case
trace = run_agent(case.input, version=PROMPT_V, model=MODEL_V)
metrics = score(case, trace) # LLM-Judge + 规则校验 + 人工抽检
save_trace(case.id, trace, metrics) # 落库,供复盘
aggregate(metrics) -> report(before_vs_after)
10.1 关键工程点
- 轨迹落库:每 case 的完整 tool_call 序列、中间状态、最终产物都要存,便于失败复盘。
- 可复现:固定 model/temperature/评测集版本,否则两次结果不可比。
- 回归对比:改一版 Prompt 跑全量,和上一版本指标 diff(见 W6D2 一键回归)。
- 看板:任务完成率、工具正确率、漏判率、P95 成本随版本趋势图。
用 Langfuse(langfuse.com)这类 LLMOps 平台可以天然记录每次运行的 trace、token、成本,并做多版本对比。这部分和 W6D2 的版本管理强耦合——评测跑出来的轨迹就是版本回归的输入。
评测执行 = 跑 case → 存轨迹 → 算分层指标 → 出前后版本对比报告。关键是轨迹落库(便于复盘)+ 可复现(固定版本)+ 回归 diff。Langfuse 可记录 trace/成本并做版本对比。
① 没存轨迹的评测 = 不可复盘,出问题只能重跑。② 版本没固定(model/temperature 漂移)会导致"这次好下次差"无法解释。③ 只看总分不看分层,定位不到根因。
十一、面试达标线①:Agent 评测 vs RAG 评测(任务级 vs 检索级)
| 对比项 | RAG 评测 | Agent 评测 |
| 粒度 | 检索级 + 单轮生成级 | 任务级 + 工具级 + 风险级 |
| 关注 | 答案忠实/相关、检索召回精度 | 任务完成、工具正确、风险漏判 |
| 失败模式 | 幻觉、漏引用 | 跑偏、乱调工具、漏判高危、成本爆炸 |
| 评测对象 | 一次问答 | 多步闭环轨迹 |
| 关系 | Agent 内部"查知识库"那步的子评测 | 上层,包含并依赖 RAG 评测 |
核心区分:RAG 评测是"检索级",关心一次回答忠不忠实、检索准不准;Agent 评测是"任务级",关心一个多步任务办没办成、工具调对没、风险漏没漏。RAG Eval 是 Agent Eval 内部子环节的评测,被继承而非替代。
十二、面试达标线②:Agent Eval 核心指标设计 + 拒答/高风险漏判怎么测
Agent Eval 指标 = 任务完成率 + 工具成功率 + Human Approval 准确率 + 错误恢复率 + 单任务成本(P95) + 高风险漏判率(独立盯)
- 任务完成率:结果对+过程对+不违规,三层判定(LLM-Judge+规则+人工抽检)。
- 工具成功率:工具选择/参数/顺序三子维度,对照标准轨迹或 LLM-Judge。
- Human Approval 准确率:拆精确率/召回率/误触发率,高风险场景召回优先。
- 错误恢复率:出错后仍成功的比例,配合成本看。
- 单任务成本:token+工具+重试+人工,报 P95。
- 高风险漏判率:单独设极严达标线(≈0),用对抗样本过采样测。
拒答怎么测
在评测集放 should_refuse=true 的 case(知识库无此药、超出业务范围),判 Agent 是否输出拒答信号(固定 should_refuse 字段或拒答文案),统计拒答准确率;同时放 should_refuse=false 的 case 防"过度拒答"。
高风险漏判怎么测
专门构造"表面正常暗藏风险"的对抗样本(PS 发票、超适应症、欺诈话术),过采样到占评测集 25%,逐条标"应判高风险",统计漏判率。漏判比误触发严重,达标线要严。
Agent Eval 六大指标如上,其中高风险漏判率要独立盯、达标线最严。拒答测法是放 should_refuse 正负样本测拒答准确率+防过度拒答;高风险漏判测法是主动构造对抗样本过采样,因为它自然分布极稀有,不构造就测不到。
十三、W6D1 自测清单
- 能讲清 Agent 评测与 RAG 评测的本质区别(任务级 vs 检索级),说清 RAG Eval 如何被 Agent Eval 继承。
- 能说出 Agent Eval 的 5-6 个核心指标及其公式(任务完成率/工具成功率/审批准确率/错误恢复率/单任务成本/高风险漏判率)。
- 能解释"任务结果对但过程错"为何仍算失败(假阳性),以及为什么只看最终答案不够。
- 能区分工具"执行成功"与"语义正确",说出工具调用的三个子维度(选择/参数/顺序)。
- 能解释 Human Approval 准确率为什么要拆精确率/召回率,且高风险场景"召回优先"。
- 能说明高风险漏判率为何是最致命指标,为什么必须用对抗样本过采样来测。
- 能设计 OCR/Rule/Database 各 10-20 条单 Tool case,说清单 Tool 评测的定位价值。
- 能解释单任务成本为什么要看 P95 而非均值,错误恢复率为什么要结合成本看。
- 能描述评测集的四层构建法(Smoke/功能/边界/对抗)和版本化思路。
- 能讲清拒答怎么测(should_refuse 正负样本)和风险漏判怎么测(对抗样本过采样)。
- 能说清评测执行流程:跑 case → 存轨迹 → 算分层指标 → 版本回归 diff。
- 能说出 RAGAS、Langfuse 在评测中的角色(指标计算 / trace 与版本对比)。
十四、高频面试题速记卡
Q:Agent 评测和 RAG 评测到底差在哪?
RAG 是检索级(一次回答忠不忠实、检索准不准),Agent 是任务级(多步任务办没办成、工具调对没、风险漏没漏)。RAG Eval 是 Agent 内部查知识库那步的子评测,被继承。
Q:为什么不能只看任务完成率?
模型可能乱调工具、过程全错却碰巧结果对(假阳性)。必须分层看任务层+工具层+风险层,过程也要对。
Q:Human Approval 准确率为什么召回优先?
高风险场景漏触发(高危没转人工)危害远大于误触发(误拦)。安全网宁可误拦不可漏放,和推荐系统精确率优先相反。
Q:高风险漏判率怎么测才有效?
自然分布下高危 case 极稀有,直接跑全量会"看起来 100% 没问题"实则没测到。必须主动构造对抗样本过采样到 ~25% 专门测。
Q:单任务成本为什么要看 P95 而不是平均值?
平均值会掩盖"1% 任务烧 10 倍 token"的长尾贵 case,高并发下长尾决定总成本。要看 P50/P95/P99。
Q:工具调用"成功"等于"正确"吗?
不等。HTTP 200 只代表执行成功,语义可能错(选错工具/参数错/顺序错)。要区分执行成功率与语义正确率。
Q:OCR/Rule/Database 为什么要单独建 case?
Agent 整体掉分时能定位到具体哪个 Tool 出问题(可观测性),而不是只知道"整体不行"。每个 Tool case 随 Tool 版本回归。
Q:拒答准确率怎么测才不被骗?
放 should_refuse=true 正样本测拒答率,同时放 false 样本防过度拒答;检测别只靠关键词,要结合 should_refuse 字段。
Q:错误恢复率高的 Agent 一定好?
不一定。若靠疯狂重试堆出来,成本会爆。要和恢复率+单任务成本一起看,且重试必须有上限防死循环。
Q:评测集为什么要分层、还要版本化?
分层(Smoke/功能/边界/对抗)保证覆盖"会出事的情况";版本化因保险条款常变,不更新就测旧业务。
FDE W6D1 学习手册 · Agent 评测体系(面试级)· 配合《FDE-W6D1-评测题.md》自测
📌 待查★ 重要