01

60 秒回答模板

RAG 作为 Agent 工具开放后，我会把评估分成四层。第一层是检索本身：query 改写是否正确、相关文档是否被召回、topK 排序是否合理、权限和新鲜度是否正确，可以看 recall@K、precision@K、MRR、nDCG、空召回率和错误召回率。第二层是 Agent 工具选择：该查知识库时有没有调用 RAG，不该调用时有没有乱调用，调用参数和迭代次数是否合理。第三层是最终答案：是否基于证据回答、引用是否支持结论、是否减少幻觉、是否能承认无证据。第四层是端到端任务效果和体验：任务成功率、轮次、延迟、成本、用户采纳、点踩和人工修正。评估时要用标注 query-doc 集合、历史任务回放、人工 review 和线上日志分层分析，避免只优化召回率却让 Agent 更慢、更贵或更容易使用错误证据。

考点 四层评估
难度 真实面经题
回答目标 评估 Agent 化 RAG 效果
02

深入解析

01

先区分 RAG 层和 Agent 层

传统 RAG 评估关注 query 到文档的匹配，但作为 Agent 工具后，还要评估 Agent 是否知道什么时候调用、怎么组织查询、是否需要多轮检索、以及如何把证据用于最终任务。只看向量召回无法说明 Agent 任务是否完成。

02

检索质量要有标注集

检索层可以构建 query-doc 标注集，明确哪些 chunk 是强相关、弱相关和不相关。指标包括 recall@K、precision@K、MRR、nDCG、空召回率、错误召回率、权限过滤正确率和知识新鲜度。还要按事实问答、流程查询、代码文档、长尾实体等类型分层看。

03

工具选择要评估调用时机

Agent 可能出现两类错误：需要证据时不调用 RAG，导致凭空回答；不需要检索时频繁调用，增加延迟和噪声。可以统计工具调用 precision/recall、漏调用率、误调用率、平均调用次数、query 改写成功率和多轮检索是否收敛。

04

最终答案要看证据使用

检索命中文档不代表答案正确。答案层要评估事实正确性、证据覆盖、引用可追溯、结论是否被文档支持、是否把无关证据误用为依据、以及缺少证据时是否拒答或澄清。这里需要人工评审或经过校准的 LLM 评审辅助。

05

端到端指标体现用户体验

RAG 工具的价值最终体现在任务成功率、用户采纳率、追问次数、点踩率、人工修正比例、延迟、成本和失败恢复上。一个方案可能 recall@K 提升，但因为多次检索导致等待变长，或者引入无关证据让答案更啰嗦，所以要把用户体验纳入评估。

06

用 badcase 回流定位问题

线上日志要记录原始问题、Agent 决策、检索 query、候选文档、最终引用、答案和用户反馈。badcase 可以分为未调用工具、query 改写错、召回缺失、排序错误、权限过滤错、证据误用和生成幻觉，再分别改索引、embedding、rerank、工具策略或提示词。

03

易错点

  • 把题目答成普通 RAG 优化清单，没有覆盖 Agent 工具选择。
  • 只看 recall@K，不看误调用、答案证据支持和端到端任务成功。
  • 没有标注 query-doc 集合，检索指标无法校准。
  • 忽略权限、新鲜度和引用可追溯，导致答案可能使用不该用或过期的知识。
  • 不记录工具调用 trace，线上 badcase 无法归因。
  • 为了提高召回盲目加大 topK，带来噪声、延迟和成本上升。
04

面试官追问

召回率高但用户仍然觉得答案差，可能是什么原因？

可能是排序靠后的证据没有被使用，证据与问题只表面相关，Agent 误用证据，答案表达不清，或者端到端延迟过高影响体验。

如何评估 Agent 是否应该调用 RAG？

可以用带标签的任务集标出需要检索和不需要检索的样本，统计漏调用率、误调用率、调用次数和调用后是否提升答案质量。

RAG 工具的线上日志至少要记录什么？

记录用户问题、Agent 决策、检索 query、候选文档、排序分数、最终引用、生成答案、耗时、成本和用户反馈。

如何处理检索结果没有证据的情况？

Agent 应该澄清、说明缺少依据或走其他工具，而不是把低相关文档包装成确定答案。无证据样本也要纳入评估集。

为什么要按任务类型分层评估？

不同任务对检索的依赖不同。事实查询、流程说明、代码定位、政策解释和长尾实体的失败原因不一样，总体平均值容易掩盖问题。