1 什么是纠错型 RAG（Corrective RAG / CRAG）
P1 · rag
🏷 标签：rag, corrective-rag, crag, retrieval-quality, hallucination
1️⃣ 考察意图
面试官想考察你是否理解RAG系统在真实落地中的“脆弱性”——检索结果质量不可控时，系统如何自救。这属于系统设计+工程取舍类型。刁钻点在于：很多人只会背“检索-生成”流水线，但CRAG要求你跳出流水线，思考评估-纠错-回退的完整流程设计。答好了能展示你对RAG鲁棒性的深度认知，以及处理检索噪声、幻觉的实战能力，而非停留在Demo层面。
2️⃣ 标准答
CRAG（Corrective RAG）是标准RAG的增强版，核心思想是：不信任检索结果，先评估再决策。标准RAG直接拿检索到的文档喂给LLM，如果文档不相关或包含噪声，LLM会“被迫”生成幻觉。CRAG在中间插了一个“质量门控”，流程分三步：
- 检索与评估：用检索器（如BM25或DPR）拿到Top-K文档后，不直接送生成器，而是过一个相关性评估器。这个评估器可以是：轻量级分类器：基于BERT微调的二分类模型（相关/不相关），速度快，延迟低（约5-10ms）。
- LLM-as-Judge：用GPT-4或Claude对文档打分（1-5分），更灵活但成本高（单次调用约0.1-0.5元）。
- 工程取舍：分类器适合高吞吐场景（如客服系统），但泛化性差；LLM Judge适合长尾查询，但延迟和成本是瓶颈。实际落地常混合使用：分类器做初筛，低置信度样本走LLM复审。 纠错策略：根据评估结果分三档处理：
- 高置信度（>0.8）：直接走标准RAG，生成答案。
- 低置信度（0.3-0.8）：触发纠错。常见方法：查询改写：用LLM重写原始查询（如“苹果公司2023年营收”改为“Apple Inc. 2023 annual revenue”），再重新检索。
- 知识图谱补全：如果检索结果缺失实体关系（如“苹果”指公司还是水果），用KG（如Wikidata）补充上下文。
- 多源融合：结合Web搜索（如SerpAPI）和内部知识库，做加权融合。 无置信度（<0.3）：放弃检索，直接让LLM基于自身知识生成，或返回“无法回答”的兜底响应。实际落地的坑：低置信度场景下，查询改写可能引入新噪声（如改写后语义漂移），需要加一个“改写质量校验”步骤——用余弦相似度对比改写前后embedding，差异过大则回退。生成与验证：生成答案后，再加一层事实性校验（如用SelfCheckGPT或Dense Passage Retrieval做答案-文档对齐），确保输出不偏离检索结果。为什么这么做：标准RAG的幻觉常来自“检索结果正确但LLM自由发挥”，CRAG通过“评估-纠错-验证”三重门控，把幻觉率从15-20%降到5%以下（【通用知识】基于NQ数据集实验）。
核心优势：鲁棒性提升，尤其对抗检索噪声（如索引更新滞后、查询歧义）。代价：延迟增加30-50%（评估+纠错），成本翻倍（多一次LLM调用）。适合对准确性要求高的场景（如金融合规、医疗诊断），不适合实时聊天（如客服机器人）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，CRAG的核心是‘评估-纠错-回退’完整流程，在检索后加一个相关性分类器（如BERT微调）判断文档质量；第二，低置信度时触发纠错，比如查询改写或Web搜索融合，高置信度直接生成；第三，生成后加事实性校验减少幻觉。总结一句：CRAG不是新模型，而是一种系统设计哲学——不信任任何单一环节，用门控机制兜底。”
4️⃣ 高频追问 & 应对
追问 1：评估器的准确率不够高怎么办？比如分类器把相关文档误判为不相关。
这是CRAG的经典问题。解法分三层：第一，阈值动态调整——不设固定阈值，而是根据查询类型自适应（如事实性查询用0.7，开放性查询用0.5），通过历史日志学习最优阈值。第二，多评估器投票——用3个轻量分类器（如DistilBERT、RoBERTa、MiniLM）做集成，多数投票决定，准确率提升5-8%。第三，回退机制——如果评估器误判导致答案质量差，用户反馈后触发“重新评估+纠错”的离线重跑，用强化学习（如GRPO）优化评估器。注意：不要追求100%准确率，工程上接受90%+，用回退兜底。
追问 2：纠错阶段的查询改写，怎么避免改写后语义漂移？
核心是加“改写质量校验”。具体做法：用Sentence-BERT计算改写前后查询的余弦相似度，低于0.7则回退到原始查询。另外，改写时用约束生成——给LLM一个模板（如“将以下查询改为英文关键词形式：{原始查询}”），限制自由发挥。实际落地中，我们还在改写后加一个“检索结果一致性检查”：对比改写前后检索到的Top-3文档的Jaccard相似度，如果低于0.5，说明改写失败，直接丢弃。成本上，每次改写+校验增加约20ms延迟，但能避免80%的语义漂移问题。
追问 3：CRAG和Self-RAG有什么区别？哪个更好？
两者目标一致（减少幻觉），但实现路径不同。CRAG是系统级方案，在检索后加外部评估器，可插拔、易调试；Self-RAG是模型级方案，在LLM训练时注入“反思令牌”（如<检索>、<相关>、<支持>），让模型自己判断是否需要检索和生成。优劣对比：CRAG适合已有RAG系统的快速升级（不改模型），但延迟高；Self-RAG更优雅（端到端），但需要微调模型（如Llama-2-7B），成本高。实际选择：如果团队有LLM微调能力，用Self-RAG；如果只是做系统集成，用CRAG。两者可以混合——CRAG做粗粒度过滤，Self-RAG做细粒度生成控制。
5️⃣ 避坑 · 常见错误答法
- ❌ 把CRAG说成“一种新的检索算法”或“LLM的变体”。 → ✅ CRAG是系统设计模式，不是单一算法，核心是“评估-纠错-回退”的流程架构。
- ❌ 只提“用LLM评估文档相关性”，不提具体实现和trade-off。 → ✅ 必须给出评估器的具体选型（如BERT分类器 vs LLM Judge），并说明延迟/成本的取舍。
- ❌ 忽略纠错阶段的失败场景，只说“查询改写就能解决”。 → ✅ 要主动指出改写可能引入噪声，并给出校验机制（如余弦相似度阈值）。
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索质量不稳定”的问题切入，描述你如何用CRAG的评估器（如BERT分类器）过滤低相关文档，并给出在NQ数据集上幻觉率从18%降到6%的量化结果。强调你处理过“改写后语义漂移”的坑。
- 如果你只做过传统NLP：用“文本分类+规则系统”类比——CRAG的评估器就像文本分类中的置信度阈值，纠错就像规则回退。展示你理解“系统鲁棒性”的通用设计思路，而非局限于RAG。
- 如果你是校招无项目：聚焦CRAG论文（Yan et al., 2024）的复现思路，描述你如何用HuggingFace的BERT分类器+LangChain的查询改写实现一个最小原型，并对比标准RAG的准确率差异。强调你对“评估-纠错”完整流程的抽象理解。
- Yan et al., "Corrective Retrieval Augmented Generation" (2024) - CRAG原始论文，定义评估-纠错框架。
- Asai et al., "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection" (2023) - Self-RAG论文，对比CRAG的模型级方案。
- Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020) - 标准RAG奠基论文，理解CRAG的改进起点。
- LangChain官方文档：CRAG实现指南（含评估器、查询改写、Web搜索融合的代码示例）。
- 博客《CRAG实战：如何用BERT分类器+LLM改写把RAG幻觉率砍半》 - 工程落地细节，含阈值调优和成本分析。