为什么不能只看最终回答，必须拆开评测 RAG

1️⃣ 考察意图

面试官想看你是否具备系统化工程思维，而非只会调 API 拼 demo。考察类型是系统设计 + debug。刁钻点在于：很多候选人只背过“RAG 分检索和生成”，但说不出为什么端到端指标（如准确率）无法指导优化方向——回答错了，你不知道是检索召回不够，还是 LLM 没读懂上下文，还是 prompt 指令冲突。答好了能展示：你懂分层评测的设计原则、能落地可复现的评测流水线、并且有实际踩坑经验（比如 recall 高但 answer 差，怎么定位）。

2️⃣ 标准答

核心论点：RAG 是检索 + 生成的串联系统，端到端指标是“黑盒”，无法定位错误来源。必须拆成三层独立评测：检索层 → 生成层 → 端到端层，每层用不同指标，才能指导迭代。

1. 检索层：独立评测，排除“没找到”的锅

指标：Recall@K（核心）、Precision@K、MRR（排序质量）、NDCG@K（带权排序）。
为什么：生成层再强，检索返回垃圾，答案必崩。端到端准确率下降时，先看 Recall@K 是否掉点。
工程取舍：Recall@K 的 K 值怎么选？K 越大 recall 越高但 latency 和 token 成本也高。通用经验：K=5 是平衡点，但长尾 query（如法律条款）需要 K=10-20。实际坑：用 BM25 时默认 k1=1.5,b=0.75 对短 query 效果差，需要调参或换 DPR 混合检索。

2. 生成层：给定“完美上下文”，评测 LLM 的忠实度与有用性

指标：
忠实度（Faithfulness）：用 NLI 模型（如 TrueTeacher、SelfCheckGPT）逐句检查回答是否被上下文支持。
有用性（Helpfulness）：用 GPT-4 作为 judge，打分 1-5，或用 BLEU/ROUGE（但仅限参考答案存在时）。
为什么：检索层没问题，但 LLM 可能“脑补”或“忽略关键片段”。例如检索返回了“2023 年营收 100 亿”，LLM 却回答“2023 年营收 150 亿”，这是生成层问题。
工程取舍：用 GPT-4 做 judge 成本高、有偏见。实际解法：先用轻量 NLI 模型（如 DeBERTa-v3 微调版）做自动化忠实度评分，再抽样 10% 用 GPT-4 做校准。坑：NLI 模型对否定句（“不是 A 导致 B”）容易误判，需要加规则后处理。

3. 端到端层：综合评估，但必须结合分层结果解释

指标：准确率（分类任务）、F1（抽取式）、人工评分（开放生成）。
为什么：最终用户只看回答质量。但端到端指标下降时，必须拆开看：是 Recall 掉点（检索层）还是 Faithfulness 掉点（生成层）。
实际落地的坑：某次迭代后端到端准确率从 85% 降到 80%，团队慌了。拆开一看：Recall@5 从 92% 升到 95%，但 Faithfulness 从 90% 降到 82%。原因是新 embedding 模型（text-embedding-3-large）召回更准但返回了更多“相关但不直接”的片段，LLM 被误导。解法：在 prompt 中加“只基于明确提及的信息回答，不要推断”，并调低温度到 0.1。

4. 建立分层评测流水线

流程：每次迭代 → 跑检索层指标 → 跑生成层指标（固定检索结果） → 跑端到端指标 → 对比基线 → 输出“问题定位报告”。
工具：RAGAS（开源框架，内置 recall/faithfulness/relevance 等指标）、TruLens（支持反馈函数）、LangSmith（trace + 评测）。
取舍：自动化评测不能替代人工，但可以筛出 90% 的明显问题。建议：自动化跑全量，人工抽检 5% 的边界 case（如多跳问题、否定问题）。

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

“这个问题我从三个层面回答。第一，端到端指标是黑盒，无法定位错误来源——回答错了，你分不清是检索没召回还是 LLM 幻觉。第二，必须拆成检索层（用 Recall@K、NDCG）和生成层（用忠实度评分、GPT-4 judge），每层独立评测。第三，建立分层流水线，每次迭代先看检索指标，再看生成指标，最后综合端到端，才能指导优化方向。总结一句：不分层评测的 RAG 系统，优化就是瞎蒙。”

4️⃣ 高频追问 & 应对

追问 1：如果检索层 Recall@5 很高（95%），但生成层忠实度很低（60%），你会怎么排查？

先确认“完美上下文”是否真的完美。我会做两步：第一步，人工检查 20 个忠实度低的 case，看 LLM 是否忽略了上下文中的关键句（比如上下文有“A 导致 B”，但 LLM 回答“B 导致 A”）。第二步，如果 LLM 确实读懂了但编造，则调整 prompt（加“只引用原文”约束）或降低温度到 0.1。如果 LLM 没读懂，则考虑换更强模型（如从 GPT-3.5 升到 GPT-4）或加 CoT 指令。关键：忠实度低不一定是 LLM 问题，也可能是上下文太长导致注意力分散，需要做 chunking 优化（比如 chunk 大小从 512 降到 256 tokens）。

追问 2：你的评测流水线怎么保证可复现性？比如 GPT-4 judge 每次打分不一样。

三个措施：第一，固定 GPT-4 版本（如 gpt-4-0613）和温度（0.0），关闭 top_p。第二，对每个 case 跑 3 次取中位数，并记录标准差。第三，用确定性指标（如 NLI 忠实度评分）作为主指标，GPT-4 judge 作为辅助。取舍：确定性指标（如 BLEU）对开放生成不敏感，所以必须结合 LLM judge，但用统计方法控制方差。

追问 3：你提到用 RAGAS，它有哪些坑？

RAGAS 的坑主要有两个：第一，它的 faithfulness 指标依赖 NLI 模型，对否定句和反事实假设（如“如果…那么…”）误判率高。解法：在 pipeline 中加一个“否定句检测”规则，命中后跳过 NLI 评分，改用人工标注。第二，它的 context_relevance 指标（用 LLM 生成问题再匹配）成本高且不稳定。建议：只用于小规模抽样，全量用 Recall@K 替代。

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

❌ 回答“端到端评测就够了，因为用户只看最终结果” → ✅ 正确切入：用户只看结果，但工程师需要定位问题。端到端指标下降时，没有分层评测你根本不知道是检索还是生成的问题，只能盲目调参。
❌ 回答“用 BLEU/ROUGE 评测生成层就够了” → ✅ 正确切入：BLEU/ROUGE 只适合有标准答案的封闭任务（如 QA），对开放生成（如摘要、对话）不敏感。必须加上忠实度评分（NLI 或 LLM judge）来检测幻觉。
❌ 回答“检索层用准确率评测” → ✅ 正确切入：检索是排序问题，准确率不适用。应该用 Recall@K、MRR、NDCG 等排序指标，因为用户关心的是“正确答案是否在前 K 个结果中”，而非“所有结果是否都正确”。

6️⃣ 简历呼应

如果你有 RAG 项目：从“我在 XX 项目中搭建了分层评测流水线，用 RAGAS + 自定义 NLI 模型，发现 recall 高但 faithfulness 低的问题，通过 prompt 优化和 chunk 大小调整，最终端到端准确率提升 12%”切入。
如果你只做过传统 NLP：用“传统 NLP 评测（如分类准确率）是单层，RAG 是串联系统，必须分层。我理解的分层评测设计原则是：先隔离变量，再定位问题，类似传统 NLP 中的 ablation study”类比迁移。
如果你是校招无项目：聚焦“我复现了 RAGAS 论文中的分层评测方法，在 WikiQA 数据集上跑通，并分析了 recall 和 faithfulness 的相关性，发现两者呈弱负相关（r=-0.3），说明检索越准反而可能增加生成幻觉风险”。
RAGAS: Automated Evaluation of Retrieval Augmented Generation（论文）
TruLens: Feedback Functions for RAG Evaluation（工具文档）
SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection（论文）
“RAG Evaluation: Beyond End-to-End Metrics”（博客，作者：LangChain 团队）
“The Three Layers of RAG Evaluation: Retrieval, Generation, and End-to-End”（博客，作者：Pinecone 团队）

—— 本场面试完 ——