14｜如何评估 Agent+RAG 系统的效果？有哪些指标
1️⃣ 考察意图
面试官想看你是否具备系统级评估思维，而非只背指标。考察类型是系统设计 + 工程取舍。刁钻点在于：Agent 的链式调用（如多步推理、工具调用）让传统 RAG 的单轮指标失效，你必须能拆解出检索、生成、规划、执行四个维度的独立与联合评估。答好了能展示你对评估成本、自动化与人工权衡的实战理解，以及用 LLM-as-Judge 等前沿方法解决评估瓶颈的硬实力。
2️⃣ 标准答
评估 Agent+RAG 系统，不能只盯着一个指标，必须分层拆解。我按检索层、生成层、Agent 行为层、系统层四个维度来答，每个维度给出具体指标和落地坑。
- 检索层：召回率与排序质量
- 指标：Hit Rate@k（命中率）、MRR（平均倒数排名）、NDCG@k（归一化折损累计增益）。Hit Rate 看是否召回正确答案，MRR 看第一个正确答案的位置，NDCG 看排序质量。
- 为什么用 NDCG 而非 Precision：因为 RAG 中正确答案可能多个，且排序靠前更重要，NDCG 能惩罚排序错误。
- 落地坑：检索评估依赖人工标注的“相关文档集”，但实际数据往往只有最终答案，没有中间文档标注。解法：用 LLM 自动标注相关性（如 GPT-4 对 query-doc 对打 0/1 标签），再计算指标，但需抽样人工校验，避免 LLM 偏见。
- 生成层：忠实度与有用性
- 指标：Faithfulness（忠实度，基于 NLI 模型如 TrueTeacher 或 DeBERTa）、Answer Relevance（答案相关性，用 BERTScore 或 LLM-as-Judge）、Context Recall（上下文召回，看生成是否覆盖检索文档关键信息）。
- 为什么用 Faithfulness 而非 BLEU/ROUGE：BLEU/ROUGE 只测字面重叠，但 Agent 可能用不同措辞表达正确事实，忠实度测的是“生成是否与检索文档事实一致”，更鲁棒。
- 落地坑：NLI 模型对长文本推理不准，且对否定句（如“没有证据表明”）误判率高。解法：改用 LLM-as-Judge，设计 prompt 要求模型逐句检查事实，并输出引用来源（如“第 3 段第 2 句”），同时加入否定句检测规则。
- Agent 行为层：任务成功率与规划效率
- 指标：Task Success Rate（任务成功率，如 QA 准确率）、Tool Call Accuracy（工具调用准确率，看是否调对了 API/数据库）、Planning Efficiency（规划效率，用平均步数或冗余工具调用次数衡量）。
- 为什么需要单独评估：Agent 可能检索正确但规划错误（如多步推理中跳步），或工具调用失败（如 API 返回空结果），这些无法被检索/生成指标捕获。
- 落地坑：任务成功率依赖人工标注的“正确答案”，但 Agent 可能用不同路径达成相同结果。解法：用“等价性评估”，让 LLM 判断 Agent 输出是否与标准答案语义等价，而非字面匹配。例如，ReAct 框架中，Agent 可能先查数据库再推理，与标准答案的“直接回答”等价。
- 系统层：延迟、吞吐量与成本
- 指标：P95 延迟（端到端，含检索+生成+工具调用）、QPS（每秒查询数）、Token 消耗（输入+输出，按模型定价计算成本）。
- 为什么关注成本：Agent 多步推理可能消耗 10 倍于单轮 RAG 的 token，若用 GPT-4，单次成本可达 $0.1+，必须优化。
- 落地坑：延迟优化时，检索和生成是瓶颈。解法：用 HNSW 索引加速检索（延迟 <50ms），对生成用 FlashAttention 和 KV-cache 优化，对 Agent 规划用“缓存常见子任务”减少重复推理。
总结：推荐使用 RAGAS 框架（含 Faithfulness、Answer Relevance、Context Precision 等指标）作为基线，再补充 Agent 行为层指标。评估 pipeline 应自动化（LLM-as-Judge + 规则校验），但定期抽样人工校验，避免评估模型漂移。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从检索、生成、Agent 行为、系统四个层面回答。检索层用 Hit Rate 和 NDCG 评估召回与排序；生成层用 Faithfulness 和 Answer Relevance 测忠实度与相关性；Agent 行为层用 Task Success Rate 和 Tool Call Accuracy 测规划与执行；系统层用 P95 延迟和 Token 成本衡量效率。总结一句：评估必须分层，用 RAGAS 框架做基线，LLM-as-Judge 自动化，但人工校验不能省。”
4️⃣ 高频追问 & 应对
追问 1：LLM-as-Judge 评估 Faithfulness 时，如何避免 LLM 本身产生幻觉？
应对策略：核心是“引用约束”。设计 prompt 要求 LLM 只基于检索文档判断，并输出具体引用（如“第 2 段第 3 句”）。同时，用“反向验证”：让 LLM 先提取生成中的事实声明，再在检索文档中查找对应证据，若找不到则标记为不忠实。此外，定期用人工标注的 golden set 校准 LLM-as-Judge 的准确率，若低于 90%，则切换评估模型（如从 GPT-4 换到 Claude 3.5 或微调一个小模型）。
追问 2：Agent 多步推理中，如何评估“规划质量”而不只看最终结果？
应对策略：用“子任务完成率”和“冗余步数”。将 Agent 的规划拆解为子任务（如“检索 A”、“查询 B”、“推理 C”），人工标注每个子任务是否必要且正确。指标：子任务完成率（正确完成的子任务数 / 总子任务数）、冗余步数（Agent 执行了但非必要的步骤数）。例如，若 Agent 在检索后重复查询同一 API，则冗余步数+1。落地时，用日志记录每个步骤的输入输出，再用 LLM 自动判断子任务必要性。
追问 3：评估成本很高，如何平衡评估精度与成本？
应对策略：分层抽样。对高价值场景（如金融、医疗），用 GPT-4 做 LLM-as-Judge，但只抽 10% 的样本；对低风险场景，用微调的小模型（如 DeBERTa-v3 或 BERTScore）做全量评估。另外，用“主动学习”：先让低成本模型评估，对置信度低的样本（如 Faithfulness 分数在 0.4-0.6 之间）再调用高成本模型。这样能节省 70% 成本，同时保持 95% 的评估精度。
5️⃣ 避坑 · 常见错误答法
- ❌ 只提 BLEU/ROUGE 作为生成指标 → ✅ 必须区分忠实度（Faithfulness）和字面重叠，因为 Agent 可能用不同措辞表达正确事实，BLEU 会误判为低分。
- ❌ 用单一指标（如准确率）评估整个系统 → ✅ 必须分层评估，因为检索错误、生成幻觉、Agent 规划错误是不同问题，单一指标无法定位根因。
- ❌ 忽略人工评估，只依赖自动化指标 → ✅ 自动化指标（如 LLM-as-Judge）有偏见，必须定期抽样人工校验，并计算自动化与人工评估的相关性（如 Spearman 相关系数）。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在 XX 项目中用 RAGAS 框架评估了检索和生成质量，发现 Faithfulness 分数低是因为检索文档噪声大，于是加了 reranker（如 Cohere rerank-v3），最终提升 15%”切入，展示实战优化。
- 如果你只做过传统 NLP：用“传统 QA 评估用 F1 和 Exact Match，但 RAG 需要额外测忠实度，我复现了 TrueTeacher 模型做 NLI 评估”类比迁移，强调评估维度的扩展。
- 如果你是校招无项目：聚焦“我复现了 RAGAS 论文中的评估 pipeline，在 Natural Questions 数据集上计算了 MRR 和 Faithfulness，并对比了 LLM-as-Judge 与人工评估的相关性”展示动手能力。
- RAGAS: Automated Evaluation of Retrieval Augmented Generation (Shahul et al., 2023)
- TrueTeacher: Learning Factual Consistency Evaluation with Large Language Models (Zhu et al., 2023)
- CRAG: Comprehensive RAG Benchmark (Yan et al., 2024)
- LLM-as-Judge: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023)
- HNSW: Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs (Malkov & Yashunin, 2016)