# FDE W6D1 评测题 · Agent 评测体系

> 配套《FDE-W6D1-Agent评测体系-学习手册.html》使用。共 13 题，分 L1 基础 / L2 进阶 / L3 深度 / L4 场景。
> 候选人背景：36 岁，Java + 大数据 + 医疗保险方向；示例围绕特药理赔 Agent / 保险知识库。
> 建议：先独立完成，再展开参考答案；用"评分维度"自检是否答到面试级深度。

---

## L1 基础（概念识别，4 题）

### Q1. Agent 评测与 RAG 评测的核心区别是什么？
- **考察点**：能否界定评测粒度差异（任务级 vs 检索级）。
- **评分维度**：① 是否点出"RAG 是单轮检索+生成、Agent 是多步任务闭环"；② 是否说明 RAG Eval 被 Agent Eval 继承为内部子评测；③ 是否列举各自关注的指标层。
<details>
<summary>参考答案</summary>

RAG 评测是"检索级 + 单轮生成级"，关心一次回答是否忠实于检索、检索召回/精度如何；Agent 评测是"任务级 + 工具级 + 风险级"，关心一个多步任务是否办成、工具调对没、风险漏没漏。RAG Eval 是 Agent 内部"查知识库"那一步的子评测，被继承而非替代——Agent 评测多覆盖"编排层"和"工具执行层"。
</details>

### Q2. Agent Eval 至少包含哪几个核心指标？
- **考察点**：能否列举核心指标，而非只会说"看结果对不对"。
- **评分维度**：① 是否覆盖任务完成率、工具成功率；② 是否提到 Human Approval 准确率、错误恢复率、单任务成本；③ 是否单独强调高风险漏判率。
<details>
<summary>参考答案</summary>

六大指标：任务完成率、工具调用正确率（成功率）、Human Approval 准确率、错误恢复率、单任务成本（看 P95）、高风险漏判率（独立盯、达标线最严）。其中任务完成率看"结果+过程+不违规"，高风险漏判率对应资损与合规，必须单列。
</details>

### Q3. 什么是"任务完成率"？怎么算？
- **考察点**：核心指标定义与判定口径。
- **评分维度**：① 公式正确；② 是否强调判定要"结果对+过程对+不违规"三者兼顾；③ 是否提到多层判定（LLM-Judge+规则+人工）。
<details>
<summary>参考答案</summary>

任务完成率 = 正确完成的任务数 / 任务总数。判定不能只看最终产物，要兼顾：目标达成、过程正确（没调错工具/没走偏）、不破坏约束（没越权/没泄露）。落地用 LLM-Judge + 确定性规则校验 + 人工抽检验证三层，避免"结果对但过程错"的假阳性。
</details>

### Q4. 为什么单 Tool（OCR / Rule / Database）也要单独建评测集？
- **考察点**：评测的可观测性视角。
- **评分维度**：① 是否说清单 Tool case 直接测 Tool 本身（绕过 Agent 编排）；② 是否点出"整体掉分时能定位到具体 Tool"；③ 是否提到随 Tool 版本回归。
<details>
<summary>参考答案</summary>

单 Tool case（各 10-20 条）绕过 Agent 编排，直接给输入看输出，测 Tool 自身稳定性。价值在于 Agent 整体完成率下降时能快速定位是 OCR 识别掉了、Rule 引擎规则改错、还是 Database 查询越权被拦——这是评测侧的可观测性。每个 Tool case 要随 Tool 版本一起版本化回归。
</details>

---

## L2 进阶（机制理解，4 题）

### Q5. 工具调用"执行成功"和"语义正确"是一回事吗？工具调用正确率怎么拆？
- **考察点**：区分执行层与语义层，细化指标。
- **评分维度**：① 是否明确"HTTP 200 ≠ 语义对"；② 是否拆出选择/参数/顺序三子维度；③ 是否给出评分方式（对照标准轨迹 / LLM-Judge）。
<details>
<summary>参考答案</summary>

不是一回事。执行成功只代表工具跑通（HTTP 200），语义正确指"选对工具、参数对、顺序对"。工具调用正确率 = 正确的步数 / 总步数，三个子维度：① 工具选择正确；② 参数正确（如金额单位元/分）；③ 顺序/时机正确（先验证身份再查权益，防越权）。评分可对照标准工具轨迹，或 LLM-Judge 逐步判。
</details>

### Q6. Human Approval（人工审批）准确率为什么要拆精确率/召回率，且高风险场景"召回优先"？
- **考察点**：安全闸门的指标取舍逻辑。
- **评分维度**：① 是否定义精确率/召回率/误触发率；② 是否正确指出漏触发比误触发危险；③ 能否类比"安全网宁可误拦不可漏放"。
<details>
<summary>参考答案</summary>

拆三数：触发精确率（真需审批/被触发）、触发召回率（真需审批被触发/真需审批）、误触发率。高风险场景召回优先——漏触发（高危没转人工）直接造成资损/合规事故，误触发只是增加人工负担。这跟推荐系统"精确率优先"相反。阈值要可配置、可回归。
</details>

### Q7. 单任务成本为什么要看 P95/P99 而不是平均值？错误恢复率为什么要结合成本看？
- **考察点**：成本指标的统计口径与权衡。
- **评分维度**：① 是否说明平均值掩盖长尾贵 case；② 是否列举成本项（token/工具/重试/人工）；③ 是否指出"高恢复率可能靠疯狂重试堆出来、成本爆炸"。
<details>
<summary>参考答案</summary>

平均值会掩盖"1% 任务烧 10 倍 token"的长尾，高并发下长尾决定总成本，所以报 P50/P95/P99。成本项含 token + 工具调用 + 重试 + 人工。错误恢复率高不一定好：若靠无上限重试堆出来，成本会爆，且可能死循环。恢复率要和单任务成本一起看，重试必须有上限。
</details>

### Q8. 评测集为什么要"分层构建"并"版本化"？
- **考察点**：评测集工程方法论。
- **评分维度**：① 是否说出 Smoke/功能/边界/对抗四层及占比；② 是否解释对抗样本过采样的原因；③ 是否提到保险条款常变、评测集需随业务更新。
<details>
<summary>参考答案</summary>

四层：Smoke(10%) 主流程不崩、功能(40%) 覆盖分支、边界(25%) 异常、对抗/高风险(25%) 安全漏判。对抗样本过采样是因为自然分布下高危 case 极稀有，不构造就测不到漏判。版本化因保险条款常变，不更新就测旧业务；评测集应像代码一样版本化、双人校验、随业务演进。
</details>

---

## L3 深度（设计/辨析，3 题）

### Q9. 为什么"任务结果对"不能等同于"Agent 评测通过"？请结合特药理赔场景说明。
- **考察点**：假阳性与过程正确性，面试高频辨析。
- **评分维度**：① 是否讲清"结果对过程错"的假阳性；② 特药场景举例是否贴切（如乱调工具/调错库却蒙对）；③ 是否给出"分层评测 + 轨迹落库"的解法。
<details>
<summary>参考答案</summary>

模型可能乱调工具、调错知识库、过程全错却碰巧编出正确答案（如金额算对但引用条款是错的、或先查权益后验证身份导致越权查询）。这种假阳性上线后极危险。解法是分层评测（任务层+工具层+风险层都要过）+ 轨迹落库（每 case 存完整 tool_call 序列便于复盘），不只看最终产物。
</details>

### Q10. 高风险漏判率为何是"最致命指标"？怎么设计才能测到它？
- **考察点**：最严达标线的设计与对抗样本构造。
- **评分维度**：① 是否说明与任务完成率正交（任务办成≠风险判对）；② 是否点出自然分布测不到、必须对抗样本过采样；③ 是否给出达标线（≈0）与构造示例（PS 发票/超适应症/欺诈话术）。
<details>
<summary>参考答案</summary>

它和任务完成率正交：任务可能"完成得很好"却把一笔欺诈理赔判成正常通过。失败成本极高（一笔骗赔数十万），所以必须单独盯、达标线极严（如 ≤0.5% 或 0 漏判）。自然分布下高危 case 极少，直接跑全量会"看起来 100% 没问题"实则没测到——必须主动构造"表面正常暗藏风险"的对抗样本（PS 发票、用药与诊断不符、欺诈话术）过采样到 ~25%，逐条标"应判高风险"统计漏判率。
</details>

### Q11. 拒答（should_refuse）怎么测才不会被"骗过"？
- **考察点**：拒答评测的完整性。
- **评分维度**：① 是否放 should_refuse=true 正样本测拒答率；② 是否放 false 样本防过度拒答；③ 是否指出检测别只靠关键词、要结合结构化字段。
<details>
<summary>参考答案</summary>

在评测集放 should_refuse=true 的 case（知识库无此药、超出业务范围），判 Agent 是否输出拒答信号（固定 should_refuse 字段或拒答文案），统计拒答准确率；同时放 should_refuse=false 的样本防"过度拒答"。检测别只靠关键词匹配（"我不知道"），模型会换说法（"未查询到相关条款"），要结合结构化 should_refuse 字段判。
</details>

---

## L4 场景（综合实战，2 题）

### Q12. 场景题：你负责特药理赔 Agent 上线评审。评测显示"任务完成率 96%、工具成功率 94%、但高风险漏判率 3%（30 个对抗样本中漏了 1 个 PS 发票骗赔）"。你作为 FDE 会怎么决策？
- **考察点**：用指标做上线决策与风险权衡。
- **评分维度**：① 是否把漏判率作为一票否决项（安全优先于效率）；② 是否要求定位根因（OCR 没识别 PS / 规则没覆盖）；③ 是否提出"补对抗 case + 加固 OCR/规则 + 回归到 0 漏判再上线"；④ 是否提审批闸门兜底。
<details>
<summary>参考答案</summary>

**决策：不通过，打回。** 理由：高风险漏判率 3% 在保险场景不可接受，一笔骗赔资损远超 96% 完成率带来的收益，安全指标优先于效率指标。下一步：① 定位根因——是 OCR 没识别 PS 痕迹，还是规则引擎没覆盖"发票金额与用药不匹配"；② 针对根因加固（OCR 加篡改检测 / 规则加交叉校验）；③ 把该对抗样本补进评测集，回归到 0 漏判再评审；④ 同时确认 Human Approval 闸门对该类 case 的召回是否 100%，作为最后兜底。完成率/工具率达标只是入场券，漏判率不归零不放行。
</details>

### Q13. 场景题：你的 Agent 改了一版 Prompt 后"任务完成率从 92% 升到 95%"，但 DBA 发现 Database Tool 的越权查询次数翻倍。请设计一次完整评测闭环来验证这次改动该不该发。
- **考察点**：指标联动 + 版本回归 + 跨职能协作。
- **评分维度**：① 是否提出固定版本做可复现回归；② 是否把"越权查询次数"作为独立安全指标纳入；③ 是否用前后版本 diff 报告（完成率↑但安全↓）；④ 是否结论"不许发，先修权限最小化/查询白名单"。
<details>
<summary>参考答案</summary>

设计闭环：① 固定 model/temperature/评测集版本，跑改动前后两版全量（30 任务 + 50 RAG + 各 Tool case），保证可复现；② 在 Agent Eval 指标里补一个"Database 越权查询次数"安全指标（或并入工具成功率/高风险漏判率）；③ 出前后版本 diff 报告：完成率 92%→95%（好），但越权查询翻倍（坏），且可能推高风险漏判；④ 结论：不许发。完成率提升不能以越权为代价，先修 Tool 权限最小化 + 查询白名单（见 W6D4），再回归到越权=0 才发版。这体现 FDE 用评测数据驱动发布决策，而非只看单一指标。
</details>

---

## 评分汇总表

| 层级 | 题号 | 主题 | 满分建议 | 达标要求 |
|------|------|------|----------|----------|
| L1 基础 | Q1-Q4 | 概念识别 | 各 10 分 | 能准确界定 Agent vs RAG、列举核心指标 |
| L2 进阶 | Q5-Q8 | 机制理解 | 各 15 分 | 能区分执行/语义、拆指标、讲统计口径 |
| L3 深度 | Q9-Q11 | 设计/辨析 | 各 20 分 | 能讲清假阳性、漏判率设计、拒答测法 |
| L4 场景 | Q12-Q13 | 综合实战 | 各 25 分 | 能用指标做上线决策、设计评测闭环 |

**总分 160 分。** 评分建议：
- **≥130（≈81%）**：面试达标，具备 FDE 评测体系设计能力。
- **100-129**：基本达标，需补"风险漏判/成本长尾"等深度点。
- **<100**：未达标，重读手册 s3-s12。

## 双达标线（来自手册）
- **达标线①**：能讲清 Agent 评测 vs RAG 评测的区别（任务级 vs 检索级），说清 RAG Eval 如何被继承。
- **达标线②**：能讲清 Agent Eval 核心指标设计（任务完成率/工具成功率/审批准确率/错误恢复率/单任务成本），以及拒答与高风险漏判怎么测（对抗样本过采样、should_refuse 正负样本）。