RAG 与 Agent 评测指标

Q：你会怎么给 Agent 建立评测体系？只看最终成功率为什么不够？

来源：Agent 开发面试 30 题

新手答：“设计一批测试用例，看通过率。”

高手答：

只看最终成功率有两个致命问题：① 成功率 80% 告诉你“有 20% 失败了”，但不告诉你为什么失败；② 两个 Agent 都是 80% 成功率，但一个平均 3 步完成、另一个平均 15 步完成——体验天差地别。

完整的评测体系要覆盖四个维度：

维度	核心指标	衡量的是什么
效果	任务成功率、答案准确率、用户满意度	Agent 能不能做对
效率	平均步数、token 消耗、端到端延迟	Agent 做对的成本
鲁棒性	异常恢复率、对抗输入通过率、长任务完成率	Agent 在边界条件下的表现
过程质量	工具选择正确率、无效步数占比、重复动作率	Agent 的决策过程是否合理

过程质量是最容易被忽视但最有价值的维度——即使最终成功了，如果中间绕了一大圈、调了三次错误工具才蒙对，说明系统有隐患。

评测集设计：

基础用例（60%）：覆盖核心功能的标准场景
边界用例（20%）：缺参数、矛盾输入、超长上下文
对抗用例（10%）：prompt injection、故意误导
回归用例（10%）：历史 bug 对应的测试用例

评测频率：每次模型/Prompt/工具变更后必须跑全量评测，日常用核心用例做冒烟测试。

调优实战：怎么从评测结果驱动改进？

评测不是跑个分就完了，关键是从评测结果中定位瓶颈、制定优化方案、验证改进效果的闭环。面试官经常追问”讲一个调优 case”，回答结构应该是：

发现问题 → 归因分析 → 优化方案 → 效果验证

例：工具选择准确率从评测中发现只有 65%
  → 归因：工具描述太相似，模型无法区分”搜索文档”和”搜索知识库”
  → 优化：重写工具描述，加入使用场景和输入输出示例
  → 验证：工具选择准确率提升到 88%，端到端成功率从 72% 提升到 85%

评测集的构建同样重要——好的评测集不是越大越好，而是要覆盖核心场景、边界条件、已知失败模式。每次修复一个线上问题，都应该把对应的 case 加入回归评测集。

差距在哪：新手只看成功率。高手建立了四维评测体系（效果/效率/鲁棒性/过程质量），且指出过程质量是最容易被忽视的维度。面试官考的是你有没有”评测驱动优化”的工程方法论。

---

Q：RAG 系统（如 oncall 机器人）的回答准确率怎么计算？用知识问答对比还是文档相似度？

来源：蚂蚁集团智能体与大模型应用二面

新手答：“人工看看对不对，算个比例。”

高手答：

oncall 机器人或 RAG 问答系统的准确率评估比“人工看”复杂得多，因为要区分检索准确率和回答准确率——检索对了但回答可能错，检索错了但回答可能蒙对。

评估框架分两层：

1. 检索层评估（文档相似度方向）——衡量“找的资料对不对”：

• Recall@K：正确文档是否在 top-K 召回结果中
• Precision@K：top-K 结果中有多少是真正相关的
• MRR：正确文档排在第几位

评估方式：构建标注集——(query, ground_truth_docs) 对，用标注文档和实际召回文档做匹配。

2. 回答层评估（知识问答对比方向）——衡量“最终回答对不对”：

• Exact Match / F1：回答和标准答案的文本匹配度
• LLM-as-Judge：用另一个大模型评分（1-5 分），判断回答的准确性、完整性、相关性
• Faithfulness：回答是否忠实于检索到的文档（有没有编造文档里没有的内容）

用哪种方法，取决于评估目标：

评估目标	方法	适用场景
优化检索管线	文档相似度 / Recall / MRR	调 Embedding、ReRank、chunk 策略时
评估端到端效果	知识问答对比 / LLM-as-Judge	上线前验收、A/B 测试
监控线上质量	用户反馈率 + 抽样人工评估	日常运营

实际生产中的组合策略：

1. 离线评估：用标注集同时跑检索指标和回答指标，定位问题出在检索还是生成
2. 在线评估：埋点用户行为（点赞/点踩/追问率）作为隐式反馈，辅以每日抽样人工评估
3. 归因分析：回答错误时，先查检索结果——如果检索到了正确文档但回答仍然错，说明是生成环节的问题；如果根本没检索到正确文档，说明是检索环节的问题

差距在哪：新手用“人工看”一刀切。高手把评估拆成检索层和回答层两个维度，且说清了不同评估目标对应不同方法，最后给出了离线 + 在线 + 归因的组合策略。面试官考的是你有没有系统性评估 RAG 系统的方法论——“对不对”是表象，“哪里不对、为什么不对”才是核心。

---

Q：如果线上反馈“这个 Agent 有时候很好，有时候很差”，你第一步会看什么指标和日志？

来源：Agent 开发面试 30 题

新手答：“看看是不是模型不稳定。”

高手答：

“有时好有时差”说明不是系统性问题，而是特定条件下触发的问题。排查思路是缩小范围 → 找到分界线 → 定位根因。

第一步：看分布，不看平均

把最近 N 天的请求按成功/失败分两组，对比以下维度的分布差异：

对比维度	怎么看	可能发现
输入长度	失败组的 query 是不是更长/更短	上下文截断导致信息丢失
任务类型	失败集中在哪类任务	某类工具或 Prompt 有缺陷
执行步数	失败组是不是步数更多	长链路累积错误
使用的工具	失败组集中调用了哪个工具	某个工具不稳定
时间段	失败集中在某个时间段	外部依赖在该时段不稳定

第二步：看执行链路日志

从失败案例中抽 5-10 个典型 case，逐步看执行链路：

用户输入 → 意图识别结果 → 规划的步骤 → 每步的工具调用和返回 → 最终输出

找到第一个出错的环节——是意图理解错了？规划有遗漏？工具返回异常？还是最终生成时忽略了关键信息？

第三步：看“成功但低质量”的灰色地带

不只看失败，还要看用户评价低但系统判定成功的请求——这些是“表面成功但体验差”的隐藏问题。

差距在哪：新手直觉是“模型不稳定”——这等于没排查。高手有系统性的排查方法论：先看分布找分界线、再看链路定位环节、最后查灰色地带。面试官考的是你排查线上问题时有没有数据驱动的方法。