RAG 查不到文档怎么降级?
常见 fallback 策略优缺点对比,如生成式回答与提示工程
原题：当用户查询在知识库中无法找到相关文档时，RAG系统应如何优雅地降级处理？请描述常见的fallback策略及其优缺点。
RAG基础 · 字节真题
30 秒回答
- 透明性：明确告知用户"未找到相关资料，以下为大模型生成"
- 可观测：埋点记录fallback触发频率、用户满意度
- 渐进式：优先尝试低成本策略（追问→推荐→大模型→人工）
回答与解析
核心思路
RAG的降级处理要区分两个层次：检索层无结果 vs 检索结果相关性不足。不同场景需要不同的fallback策略。
常见Fallback策略
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 大模型直接回答 | 通用知识类问题 | 用户体验连贯 | 幻觉风险，需明确告知用户 |
| 缩小范围追问 | 问题过于宽泛 | 引导用户明确需求 | 增加交互成本 |
| 转人工/工单 | 专业/敏感场景 | 兜底可靠 | 人力成本高，时效差 |
| 推荐热门/相关文档 | 有相似主题内容 | 保持RAG链路 | 可能偏离用户意图 |
| 网络搜索补充 | 时效性要求高 | 扩展知识边界 | 结果不可控，延迟增加 |
决策逻辑设计
相关性分数 > 阈值 → 正常RAG回答
阈值1 < 分数 < 阈值 → 低置信度警告 + 大模型补充回答
分数 < 阈值1 → 触发追问/推荐/转人工
关键：阈值不是固定的，可按问题类型（技术/业务/闲聊）、用户身份（VIP/普通）动态调整。
工程实践要点
- 透明性：明确告知用户"未找到相关资料，以下为大模型生成"
- 可观测：埋点记录fallback触发频率、用户满意度
- 渐进式：优先尝试低成本策略（追问→推荐→大模型→人工）
实际中常采用策略组合，如先尝试追问一次，仍无效则用大模型回答并标注来源。
学习建议
建议系统学习该知识点
口语版讲法(约4分钟)
- 本质是处理检索失败，而非模型不会答
- 先划清场景：知识库无结果 vs 结果不相关
- 具体策略：追问、大模型兜底、转人工，以及组合打法
- 落地风险与工程要点：透明性、可观测、阈值动态调整
- 收尾选型偏好，给出可延伸点追问
这道题我觉得本质不是在问模型不会答怎么办，而是在问检索链路失效后，怎么让系统体面地收场，同时尽量不牺牲用户体验。
首先得把边界划清楚。检索失败其实分两层：一层是知识库里压根没找到相关文档，比如用户问了个很冷门的问题；另一层是找到了但相关性不够，分数低到没法用。这两层应对策略不一样。
先说具体怎么降级。我通常会按成本从小到大来排。最轻量的策略是追问。比如用户问了个模糊的问题，像客服场景里用户说「我要退款」，但没给订单号，那系统可以反问一句「请问是哪个订单呢？」这样引导用户把需求说清楚。缺点也很明显，交互回合多了，用户容易烦。所以追问一般只试一次，不行就换别的。
再一个策略是让大模型自己兜底。比如用户问「端午节放假安排」，知识库里没收录，那大模型可以直接用自己的知识回答，但必须明确告诉用户「这是模型生成的，仅供参考」。这个策略的好处是体验流畅，用户感觉不到断档。但风险是 Hallucination，如果用户问的是企业内部的合规政策，模型胡编一个答案，那后果很严重。所以这个策略适合通用知识类问题，不适合专业或敏感场景。
最后就是转人工或者提单。在金融、医疗这些场景里，宁可让用户等，也不能给错答案。这是最兜底的方案，但人力成本高，时效也差。
实际落地上，我不会只用一种策略，而是组合起来。我一般会设两个阈值：一个低阈值，一个中阈值。检索分数高于中阈值，正常回答；低于低阈值，直接转人工或追问；介于中间，就用大模型兜底并带上置信度警告。而且阈值不是死的，我会根据问题类型和用户身份动态调。比如技术类问题阈值设高一点，闲聊类可以低一点；VIP用户优先转人工，普通用户先走追问。
举个例子，电商客服场景。用户问「我买的手机降价了能退差价吗」，系统去知识库里找「退差价政策」，如果找到了但分数不高，比如0.6，那我会让大模型结合政策原文和自己的理解回答，同时标注「以下内容基于知识库生成，如有疑问请咨询人工」。如果完全没找到，就追问「请问是哪个订单？」，用户给了订单号后，系统带着订单号再查一次订单状态，如果还是查不到，直接转人工。
这里有个坑，就是透明性。不管用哪种降级策略，一定要让用户知道当前回答的来源。如果用户没意识到是模型胡编的，后续出了问题就是事故。所以我会在系统里埋点，记录每次降级触发的频率、用户后续是否满意、有没有投诉，然后用这些数据反过来调阈值。
另外，我上线前会特别关注一件事：降级策略本身不能引入新的风险。比如大模型兜底时，如果模型对某些词有偏见，可能会生成不当内容。所以我会在 System Prompt 里加安全约束，同时做一轮离线评测，确保降级后的回答不会比不回答更差。
还有一个点我没细说，就是有些场景下可以引入网络搜索做补充，比如时效性强的新闻类查询。但网络搜索的结果质量不可控，延迟也高，我一般只把它当成最后一道防线，而且会加一个独立的审核模型过滤一遍。
所以整体上，我更倾向把降级策略当成一个 渐进式漏斗：先低成本试，不行再升级，同时保持对用户的透明。如果面试官感兴趣，我们还可以聊聊怎么用 Corrective RAG 的思路让模型自己判断什么时候该降级。
关键一句:网络搜索作为补充降级策略，但结果质量不可控，需要额外审核模型过滤。
面试官还可能这样问
- 问法 1 · 场景切入
假设你做一个客服知识库RAG，用户问了一个很冷门的问题，检索不到任何相关文档。这时候你不能直接说“不知道”，你会怎么设计降级策略？
- 问法 2 · 层层追问
RAG系统检索不到文档时你怎么处理？……除了直接让大模型硬答还有哪些办法？……这些策略各有什么优缺点，什么时候用哪个？
- 问法 3 · 直球架构
设计RAG的fallback机制，当检索为空或相关性不够时，需要一套降级策略。请列举常见策略，分析优缺点，并说明如何决策选择哪种策略。