How to evaluate RAG-based systems

1️⃣ 考察意图

面试官想考察你是否具备系统级评估思维，而非仅背指标。RAG 评估的刁钻点在于：它不是一个单一任务，而是检索 + 生成的耦合系统，组件缺陷会互相放大。答好了能展示你理解离线指标（Recall、Faithfulness）与在线指标（用户满意度、任务完成率）的权衡，以及如何用工具（RAGAS、TruLens）构建可复现的评估流水线，这是大厂做 RAG 落地时的硬门槛。

2️⃣ 标准答

评估 RAG 系统需分三层：组件级、端到端级、系统级。每层有不同指标和工具。

组件级评估：定位瓶颈

检索质量：核心指标是 Recall@k（真实相关文档是否在前 k 个）和 MRR（首个相关文档的排名倒数）。实战中，用 BM25（默认 k1=1.5, b=0.75）作为基线，对比 DPR 或 ColBERT 的 Recall@5。坑：BM25 对长文档分块敏感，若 chunk 大小 > 512 tokens，Recall 会骤降 15-20%。解法：固定 chunk 大小为 256 tokens，重叠 32 tokens。
生成质量：用 Faithfulness（生成内容是否忠实于检索上下文）和 Answer Relevance（答案是否匹配问题）。RAGAS 框架提供这两个指标，但 Faithfulness 的 NLI 模型（如 DeBERTa-v3）在领域术语上会误判。解法：构建 50 条领域特定测试用例，人工标注后微调 NLI 模型。

端到端评估：衡量任务完成度

任务准确率：对 QA 任务，用 Exact Match 和 F1 Score。但 RAG 答案常是长文本，F1 会低估。改用 Answer Correctness（RAGAS 指标），它结合语义相似度（如 Sentence-BERT）和事实一致性。
用户满意度：用 A/B 测试，指标包括首次响应时间（< 2 秒为佳）和任务完成率（用户是否在 3 轮内得到答案）。坑：离线指标（如 Recall）提升 10%，在线满意度可能只提升 2%，因为用户更关心答案的简洁性而非召回率。解法：在生成阶段加入长度惩罚（如 Top-p 采样时限制 max_tokens=150）。

系统级评估：关注成本与延迟

延迟：检索阶段用 HNSW（ef_search=128）比暴力搜索快 100 倍，但 Recall 下降 5%。权衡：对高并发场景（如客服），牺牲 5% Recall 换取 50ms 延迟是可接受的。
成本：Embedding 模型（如 text-embedding-3-small）每次调用约 $0.0001，若日请求 10 万次，月成本 $300。解法：用量化（int8）或蒸馏（如 MiniLM）降低 50% 成本。

工具与流程

RAGAS：提供 Context Precision、Answer Correctness 等指标，但依赖 GPT-4 作为评判者，成本高。替代方案：用 TruLens 的 Feedback Functions，基于 BERTScore 计算 Faithfulness，无需 API 调用。
构建测试集：从 Wikipedia 或领域文档中抽取 200 条 QA 对，确保覆盖简单事实（如“巴黎是哪个国家的首都？”）和多跳推理（如“谁写了《百年孤独》，他来自哪个国家？”）。坑：测试集若只包含单跳问题，会高估检索能力。解法：用 HotpotQA 风格的多跳问题，要求检索器返回 2 个不同文档。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：组件级评估用 Recall@k 和 Faithfulness 定位检索和生成瓶颈；端到端评估用 Answer Correctness 和任务完成率衡量用户满意度；系统级评估关注延迟和成本。总结一句：RAG 评估必须分层，离线指标只告诉你哪里坏了，在线指标才告诉你修好了没有。”

4️⃣ 高频追问 & 应对

追问 1：如果离线指标（如 Recall）很好，但用户反馈差，你怎么排查？

先检查生成阶段：用 Faithfulness 指标看答案是否忠实于检索上下文。若 Faithfulness 低，说明 LLM 在“幻觉”，解法是调整 prompt（如“只基于以下文档回答”）或降低温度（从 0.7 降到 0.3）。若 Faithfulness 高，则问题在检索质量：Recall 可能高，但Precision 低（返回了无关文档），导致 LLM 被噪声干扰。解法：增加 reranker（如 Cohere Rerank 3），将 Top-5 重排为 Top-3，Precision 可提升 20%。

追问 2：你如何评估 RAG 系统的鲁棒性？比如对抗性输入？

构建对抗性测试集：包括拼写错误（“巴梨” vs “巴黎”）、同义词替换（“首都” vs “首府”）、否定问题（“不是法国的首都是哪里？”）。用 BM25 对拼写错误敏感（Recall 下降 30%），而 DPR 对同义词鲁棒。解法：在检索前加拼写纠正（如 SymSpell）或查询扩展（用 LLM 生成 3 个同义查询）。坑：对抗性测试集若只包含 10 条，无法暴露问题。至少需要 100 条，并覆盖 5 种攻击类型。

追问 3：你如何选择评估指标？有没有一个“万能指标”？

没有万能指标。离线指标（如 Recall）适合开发阶段快速迭代，在线指标（如任务完成率）适合上线后监控。一个实用框架是 ROUGE-L 用于摘要任务，BLEU 用于翻译，但 RAG 更推荐 RAGAS 的 Answer Correctness，因为它结合了语义和事实。权衡：Answer Correctness 依赖 GPT-4 评判，成本高。替代方案：用 BERTScore（基于 BERT 的语义相似度）作为廉价代理，与 GPT-4 评判的相关性达 0.85。

5️⃣ 避坑 · 常见错误答法

❌ 只提“用 RAGAS 框架评估”，不解释指标含义和取舍 → ✅ 具体说明 Recall@k 和 Faithfulness 的 trade-off，以及何时用 Precision 替代 Recall（如用户对噪声敏感的场景）。
❌ 说“离线指标好，系统就一定好” → ✅ 强调离线指标是必要条件，但非充分条件，必须结合 A/B 测试验证在线满意度。
❌ 忽略成本评估，只谈性能 → ✅ 在系统级评估中明确给出 Embedding 调用成本和量化方案，展示工程落地思维。

6️⃣ 简历呼应

如果你有 RAG 项目：从“构建测试集”切入，说明你如何用 HotpotQA 风格的多跳问题暴露检索瓶颈，并用 RAGAS 的 Faithfulness 指标定位生成幻觉。
如果你只做过传统 NLP：用“机器翻译评估”类比，BLEU 对应 RAG 的 Exact Match，但 RAG 需要额外关注 Faithfulness（类似翻译的忠实度）。强调你理解指标迁移的局限性。
如果你是校招无项目：聚焦“论文复现”，说明你读过《RAGAS: Automated Evaluation of Retrieval Augmented Generation》并复现了其指标，用 Wikipedia 构建了 100 条测试集，对比了 BM25 和 DPR 的 Recall@5。
《RAGAS: Automated Evaluation of Retrieval Augmented Generation》（论文）
《Evaluating RAG Systems: A Practical Guide》（博客，作者：LangChain）
《TruLens: A Framework for Evaluating LLM Applications》（工具文档）
《HotpotQA: A Dataset for Diverse, Explainable Multi-hop Question Answering》（论文）
《BERTScore: Evaluating Text Generation with BERT》（论文）

—— 本场面试完 ——