做RAG的都知道检索结果为空这个分支看着简单实际是系统里最容易“翻车”但又最容易被忽略的地方。它不像Rerank、混合检索那些模块可以反复调优也不像Prompt模板能明显影响生成风格——它藏在流程末尾只在一种尴尬时刻出现用户问了个问题你的知识库什么都没捞出来。这个时候到底要不要把问题交给模型如果交模型会乱编吗如果不交用户会不会觉得系统就是个废物这篇内容就从这个问题出发把回退分支的设计思路和检查方法完整拆一遍适合正在做RAG落地、或者准备把RAG从Demo推向生产的开发者参考。我不打算只给结论更想把每个决策背后的逻辑说透。1. 检索为空不等于没结果先搞清楚这个分支什么时候会触发先说一个我在不少团队里见过的误区很多人把“检索为空”想得太简单觉得它就是“向量库里没数据”的同义词。实际上生产环境里检索为空的情况远比你想的多而且很大一部分是“假空”。1.1 检索为空的三类触发场景第一类是真正的空。知识库里确实没有相关内容。比如你做一个企业内部IT支持机器人用户问“怎么给笔记本更换固态硬盘”而你导入的文档全是财务报销流程那检索结果天然就是空的。这种空是合理的也是系统设计时应该预料到的。第二类是索引和切分问题导致的空。文档明明在库里但因为切分方式不合理——比如一个超长PDF被切成了一堆互相没有语义连贯性的碎片——导致用户query和每个分片算相似度时分数都低得可怜。还有一种是元数据过滤过严比如按权限、部门、日期过滤后命中的结果被过滤条件全部拦截。这种空是“系统缺陷空”不是内容上没有而是架构上没捞出来。第三类是假空。也就是向量检索返回了结果但相似度分数低于你设置的阈值被阈值硬生生拦了下来。这种情况在阈值设得过高时特别常见。我自己就踩过这个坑当时为了保证回答质量把余弦相似度阈值定到0.7结果生产环境里大量正常问题被拦截用户看到的反馈是“没有相关信息”但实际知识库里明明有对应文档。这个区分非常关键因为不同触发场景的应对方案完全不一样。真空中可以走模型兜底索引缺陷空要修的是检索链路本身而假空要调的是阈值和召回策略。如果一上来不管三七二十一见到空就触发同一个回退分支那你的回退分支就会变成一个“防御机制”掩盖掉检索链路里的真正问题。1.2 为什么这个分支值得专门设计检索为空这个分支是你RAG系统里唯一一个“用户触发了错误路径”之后的出口。正常情况下用户问题能被检索到相关文档然后进入“参考资料PromptLLM”的生成阶段。但检索为空时你面对的是要么拒绝用户要么绕开知识库直接让模型回答要么用一个精心设计的回退方案缓冲。很多团队在这里选择“直接让模型回答”。理由听起来也合理“反正模型有通用知识用户问什么都能答点东西出来。”但你必须想清楚RAG的核心价值是什么是让模型的回答被知识库约束防止幻觉、保证内容来源可控。一旦检索为空后无条件放行模型那这一条用户请求就退化成纯大模型问答——这意味着幻觉风险、内容不可控、来源缺失全部一起回来了。所以我的建议是回退分支必须是一个被显式设计的系统能力而不是一个顺手写出来的else分支。它要回答的不只是“调不调模型”还包括“调的话怎么约束”“不调的话怎么给用户交代”“这个分支的触发过程怎么被观测到”。2. 调不调模型的两派做法直接拒绝与强行召唤的代价既然标题点到了“还调不调模型”那这个问题就必须正面回答。我在不同的项目里见过多种处理方式也亲身体会过它们的代价。这里把几种主流做法摊开来讲。2.1 做法A检索为空就拒绝回答最保守的方案是检索为空时直接返回“知识库中未找到相关内容”之类的话术不调用模型。这个方案的好处非常明显——零幻觉风险回答内容完全可控不会出现模型凭空编造知识库内容的事情。从工程角度看也简单一个if分支加一句固定返回就完事。但它的坏处同样明显用户体验极差。尤其在真空中用户真的在问一个有价值的问题结果系统只回一句“没找到”等于把这个用户直接推走了。而且这句话本身很冰冷连“建议换一个说法重新提问”或“该问题已转人工处理”都没有。对一个企业级AI助手来说这种体验基本等于产品不合格。2.2 做法B检索为空就放行模型裸答与做法A完全相反很多团队会选择“让模型用通用能力回答”。从体验上看用户至少能得到一个看起来像样的答复不至于被冷冰冰拒绝。但从今天RAG系统的交付标准来看这是风险最高的做法。代价在两个地方。第一是幻觉模型在没有知识库约束的情况下会一本正经地编造内容。我举个真实例子某产品FAQ机器人用户问“这个系统支持自动报表推送吗”知识库没有相关信息模型直接回答“支持您可以在设置中心开启报表推送功能”——而实际上产品根本没这个功能。用户照着操作一脸懵回头还觉得产品是垃圾。第二是责任边界模糊一旦模型裸答内容出错很难追责到底是检索问题还是模型问题这对上线后的可维护性极为不利。2.3 做法C调模型但把“没有检索到”作为事实注入Prompt这是我个人比较推荐的折中方案检索为空时仍然调用模型但在Prompt中明确告诉模型“本次提问未能从知识库检索到相关参考内容”并要求模型基于此背景谨慎作答。同时从技巧上约束如果模型凭自身知识能够回答则如实作答但要避免编造知识库中不存在的细节如果模型也不确定则明确承认“我不确定”。这个方案的核心思路不是放弃约束而是把约束从“知识库内容”换成“事实状态”。知识库检索不到但你告诉模型“你处于无参考状态”模型就会启动一套不同的回答策略——更谨慎、更保守、更善于使用“我不确定”这样的退路。实测下来这种方式生成的回复在流畅度和诚实度之间能有较好的平衡。来看一张对比表三种方案在几个关键维度上的表现方案用户体验幻觉风险实现复杂度适用场景A. 拒绝回答差无低高合规要求、不允许模型越界回答B. 模型裸答好极高低不推荐用于正式RAG生产系统C. 调模型无检索事实注入中上中低中通用场景多数业务的最佳起始点选择哪一档本质上取决于你对“幻觉容忍度”和“用户体验”之间的价值排序。银行、医疗这类行业宁可直接拒绝也不能让模型乱说而电商、客服这类场景用户更在意“能不能有个答案”方案C就更合适。2.4 决策的真正变量谁来承担“不知道”的后果这里我再补一个思考框架。问自己一个问题这次回答如果错了后果有多严重如果后果是用户投诉、订单失败、操作误导那你应当偏向方案A和C的低幻觉端如果后果只是“答得不那么精准”用户自己会二次确认那可以让模型更大胆一点。另一个变量是用户预期。如果你的产品本身就定义成“企业知识问答助手”用户默认答案是来源于知识库的那模型裸答就是在破坏信任。反过来如果你的产品定位是“AI助手”用户允许你给出超出知识库的常识性回答那无参考状态下的作答也是可以接受的。这个定位问题需要产品层面拍板不能只由技术团队决定。3. 回退分支的分级策略从裸答到软兜底再到硬兜底把上一节的讨论再往深推一步。回退分支的设计不需要在“调”和“不调”之间二选一更成熟的方案是做一个分级回退策略——不同严重程度下触发不同级别的兜底路径。3.1 三级回退漏斗软回退、硬回退、人工兜底我习惯把回退设计成三层第一层叫软回退Soft Fallback。对应的就是方案C调用模型但Prompt里注入“本次未检索到参考文档”的事实让模型在无参考状态下生成回答。软回退可以给用户一个有价值的响应同时通过Prompt约束降低幻觉概率。适合“知识库里可能没有、但模型常识可能覆盖”的问题。第二层叫硬回退Hard Fallback。软回退如果因为某种原因不可用比如模型服务超时或者业务规定这类问题不允许模型自行作答则直接返回固定模板话术例如“抱歉我暂时没有在知识库中找到相关信息建议您联系人工客服或尝试换个说法提问。”硬回退的好处是绝对安全、零幻觉代价是体验生硬。第三层叫人工兜底Human Handoff。在客服场景中硬回退之后还给用户一条路转接人工服务。这一层不一定由RAG系统自己实现但可以根据回退事件向客服系统提交一个工单把用户引导到人工坐席。设计成三级最大的好处是你在“体验”和“安全”之间有了渐进的调节空间。轻微问题走软回退留住体验严重问题走硬回退保证安全最差情况还有人兜底。这比单纯一个分支灵活得多。3.2 重试机制先别急着回退再救一次还有一个工程细节容易被忽略在进入回退分支之前值得加一个重试Retry环节。很多检索为空的“假空”不是因为知识库真没有而是因为用户第一次提问的表达方式和知识库里的文档表达方式差距太大。这种情况下直接进入回退分支是可惜的。更合理的做法是当top-K结果全部低于阈值时先对用户query做一次改写——比如用LLM把口语化问题改写为更规范的描述——然后用改写后的query再检索一次。如果第二次检索仍然为空才真正进入回退分支。这个设计的性价比很高。一次query改写二次检索的成本通常只有几十到几百毫秒但很可能把“空”变成“非空”直接把用户从回退路径拉回正常路径。我做过一个项目加了重试机制之后回退触发率下降了接近30%收益相当可观。需要注意一点重试不能无限循环。最多重试一次否则用户等太久体验更差。并且重试条件也要限制在“检索为空”或“检索分数整体过低”的场景正常的低分结果不触发改写重试。3.3 把Prompt写好无参考状态下的模型约束技巧如果走了软回退那你面对的下一个问题就是怎么让模型在“没有参考资料”的情况下既给出有用的回答又不瞎编。这里分享几个我在实践中验证过的Prompt写法要点。第一向模型明确当前状态。不要只是把检索结果字段留空要在Prompt里写清楚“本次查询未能从知识库检索到任何相关文档”。模型对状态的感知是来自文本的你写了它才知道。第二设定回答边界。给模型两类指令一是如果用户问题属于常识或通用领域可以基于自身知识回答二是如果问题涉及具体产品细节、内部流程或任何需要资料支撑的信息且你无法确认必须明确回复“该信息不确定”或“建议核实后告知”。这样一来模型等于有了一个“什么时候可以说、什么时候必须说不知道”的判断标准。第三用句式约束模型行为。我建议在Prompt里直接给出一个回答范式例如“请以如下结构回答先说明是否找到相关资料再给出答案或说明不确定原因”。结构化句式可以显著降低模型胡诌的概率因为它被迫先面对“我到底有没有资料”这个问题。3.4 软回退的另一个分支不让模型硬答而是引导澄清软回退还包含一种更复杂的变体适合检索为空且用户query本身信息不足的情况。比如用户问“怎么充值”但知识库有“充值失败怎么处理”“充值优惠活动”等文档而query过于宽泛导致一个也没命中。这时与其让模型硬答或拒绝不如让它走澄清引导Clarification模型不直接回答充值步骤而是问用户“您是指充值失败、充值优惠还是虚拟卡充值具体场景不同处理方式不同您能描述得更详细一点吗”。这种策略特别适合to B系统的运维客服场景。它把一次“检索失败”转化为一次“交互加深”用户补完信息后系统可以再次检索大概率就能命中。而实现上也不复杂无非是在软回退Prompt里再加一句当用户问题表述不够具体时优先询问补充信息而非直接作答。4. 让回退在关键时刻被看见埋点、测试用例与回归检查设计完回退分支接下来是更重要的部分检查。很多系统上线后回退分支就像黑洞一样触发没触发、给用户返回了什么、模型是不是在裸答——一概不清楚。没有可观测性和检查机制你再精妙的设计也是纸上谈兵。4.1 埋点每次回退触发都必须留下证据回退分支的埋点至少要记录以下信息触发阶段是检索返回空数组还是分数全部低于阈值还是检索服务异常触发类型真空气、假空气、还是索引缺陷导致的空回退级别走了软回退、硬回退还是人工兜底重试信息是否执行了query改写重试改写前和改写后的query分别是什么模型调用信息如果调用了模型记录了Prompt和最终输出吗这些数据是你事后分析回退逻辑合理性的唯一依据。我自己习惯在回退事件里加一个fallback_reason字段用枚举值标明触发原因比如NO_DOCUMENTS、LOW_SCORE、RETRIEVAL_ERROR。这样后面聚合分析时一眼就能看到每种原因各占多少比例。如果发现LOW_SCORE比例特别高说明阈值或embedding质量有问题该调就调。4.2 测试用例设计把回退当成一等公民来测回退分支是最容易被测试覆盖遗漏的地方。团队通常会把测试精力集中在“正常检索→生成回答”这条主链路上而对回退场景只是随手写一两个用例。但回退分支恰恰是生产环境中出错率最高的地方所以我建议专门建一组回退测试集至少覆盖下面几类知识库为空场景清空向量库看系统是否走硬回退全低分场景query明显无关所有分片分数都低于阈值部分低分场景有少量分片刚刚踩线看是否触发Rerank或软回退检索服务异常场景模拟向量数据库连接超时确认系统不崩溃、不做模型裸答混合场景query有一部分能命中、一部分不能看最终答案是否正确使用了命中的部分比较有效的做法是引入回退烟火测试Fallback Smoke Tests把上面这些场景做成自动化用例集成到CI流水线里每次改动代码后自动跑一遍。这样就能防止有人后续改动检索逻辑时不小心把回退分支弄坏。4.3 回归检查用Golden Set守住回答质量的底线如果你的RAG系统已经有一些评测集建议把回退相关的问题也整理进Golden Set里。比如准备20~50条“知识库中不存在对应答案”的问题以及20条“知识库中存在但检索难度较大”的问题每次版本更新后都跑一遍对比回答结果。回退场景下的Golden Set评估关注的指标和主链路不太一样。主链路看重的是召回率、命中率、忠实度回退链路更看重拒答准确率和不幻觉率。也就是说你要确保模型在“无参考资料”状态下不乱编这比什么都重要。我在实践中还会额外检查一条模型输出中是否出现了“根据知识库资料”这样的表述。一旦出现就说明Prompt约束失效了模型在没有任何依据的情况下假装有依据这是最危险的信号。4.4 线上监控回退率是一个必须盯住的指标设计检查机制的另一半是线上指标。我建议把“回退触发率”定义为关键监控指标公式很简单回退触发率 触发回退分支的用户请求数 / 用户请求总数这个指标的环比异常能说明很多问题。比如某天回退率突然从5%飙到25%可能的原因包括向量库数据未同步、embedding模型被误替换、阈值配置被改动、某批新导入文档的切分格式不兼容等。如果连指标都没有这些问题要等到用户投诉才暴露那损失就大了。在监控看板上我会把回退率按触发原因拆成不同曲线NO_DOCUMENTS率、LOW_SCORE率、RETRIEVAL_ERROR率。三条曲线合在一起能帮你快速定位是数据问题、召回问题还是底层服务问题。这一步表面看只是加个指标配置实际上是把“回退分支”从一个被动else变成了一个可观测、可分析、可优化的一等功能模块。5. 实际项目中的两个典型翻车现场与检查清单讲完设计方法再来两个真实翻车案例收尾。这些坑我都在项目里踩过希望你能绕开。5.1 翻车案例一阈值调太高知识库直接“变成”空的当时我们在做一个文档问答助手QA团队反馈回答质量不稳定建议把相似度阈值从0.6提到0.75。改完之后离线评测指标看起来好看了不少top-5命中率上升了因为保留下来的都是高分结果。但上线当天用户投诉就炸了大量正常问题返回“未找到相关信息”。复盘后发现问题很清晰阈值设太高导致大量中低分但内容正确的文档被拦截系统回退率从7%飙到29%。而这些被拦掉的问题其实知识库里有答案纯粹是embedding相似度没达到0.75。这类问题的根因不在回退分支设计而是“阈值调参只看了离线指标没看线上回退率”。从那以后我养成了一个习惯每次动阈值、换embedding模型、改切分参数都要同步看回退率指标的变化不能只看命中率和回答质量。5.2 翻车案例二检索服务异常时模型裸答帮了大倒忙另一个项目里向量数据库偶发连接超时。最初代码是这样写的检索失败时抛异常异常被上层捕获后直接走了“调用模型回答”的兜底逻辑。结果就是每次向量库抖动用户问产品问题模型都凭通用知识自由发挥回答内容经常和真实产品功能对不上。后来我们把回退逻辑改成了“异常兜底不走模型裸答而是走硬回退模板人工引导”同时增加了重试机制和熔断开关。向量库抖动时用户的体验从“被模型乱编误导”变成了“收到明确提示请稍后重试”反馈改善非常明显。这个案例也说明回退分支不能只处理“检索为空”还要处理“检索挂了”。前者是业务问题后者是系统稳定性问题两者的处理方式完全不同。5.3 回退分支上线前的检查清单最后把前面所有内容浓缩成一张检查清单照着走一遍基本能把回退分支的坑踩完了确认“为空”的判定条件是无结果数组、全低分还是检索异常三种情况有各自的处理路径确认是否加了query改写重试机制重试最多一次且只在检索为空时触发确认软回退Prompt里明确写入了“未检索到参考文档”的状态以及“不确定就承认”的指令确认硬回退模板不包含内部信息不会向用户暴露知识库内部细节确认检索服务异常不会触发模型裸答而是走独立异常兜底确认回退事件完成了埋点记录了触发原因、重试信息、模型调用信息确认回退场景测试用例已纳入CI流水线并包含知识库为空、全低分、检索异常等场景确认线上监控已加入回退率指标并按触发原因拆分曲线我个人在实际操作中的体会是回退分支的设计本质上是在给RAG系统画一条“安全底线”。检索命中的时候大家比拼的是召回率、忠实度、生成质量而检索落空的时候考验的才是架构设计者对边界、风险、用户体验的综合把控。不要把这个分支当成一个简单的else来写花点时间把分级策略、重试机制、Prompt约束和可观测性一起考虑进去你的RAG系统才真正称得上能扛生产环境。