先给结论RAG只要做降级就必然会面对一个灵魂拷问——“降级下去检索结果还能不能信”这个问题我是在“AI工厂管家社区版”这个项目上被真实锤过的。当时线上反馈说知识库问答时好时坏排查到最后发现不是模型不行而是向量库组件在高峰期连接超时系统直接跪了用户只看到一句“服务暂时不可用”。从那天起我意识到RAG的可用性不是“模型好不好”的问题而是“链路扛不扛得住”的问题。后来我们才设计并落地了这套三级降级链原则很简单向量库挂了业务不能挂降级可以但绝不能给用户返回一批“看着像那么回事、实际牛头不对马嘴”的检索结果。这篇东西不聊概念就讲我们在AI工厂管家社区版里怎么设计三级降级链、每一级怎么落、踩过哪些坑以及最关键的怎么避免降级之后返回“假检索结果”。如果你也在做RAG应用、知识库问答或者正在被向量库不稳定折磨这篇应该能给你一些直接能抄作业的参考。1. 为什么RAG必须做降级——向量库不是永远可靠的“超级英雄”1.1 一次让人冷汗直流的线上故障AI工厂管家社区版是个面向工厂车间场景的知识库问答工具知识库里装了设备手册、操作规程、维修工单、备件清单这一类的文档。工人师傅在生产现场用手机一问系统先把问题转成向量去向量库里召回相关文档片段再丢给大模型生成回答。正常路径跑得挺顺直到那天向量库组件在高峰时段连接数打满查询超时率飙升。那天的处理过程我现在还记得很清楚先是监控告警弹出一堆红线然后群里开始有人反馈“问啥都没反应”。当时我们几个人第一反应是去看模型服务结果模型服务负载正常日志干净得像刚格式化过。排查到后面才发现所有请求都阻塞在向量检索这一环向量库连不上整个RAG链路干脆直接返回失败。用户不关心你的向量库是挂了还是升了。他们只知道一件事这个AI问答工具坏了。生产车间的师傅不会写工单说“疑似向量检索组件异常”他们只会说“它答不上来”。所以从那之后我们把“RAG链路必须有降级方案”列成了硬性要求。1.2 降级的本质用“平庸但正确”换“优雅但不可用”很多人一听降级第一反应是“降级就是降低体验”天然抵触。但降级的本质不是“变差”而是“换一种方式完成目标”。还是拿AI工厂管家举例子。正常路径是语义检索用户问“离心泵密封泄露怎么处理”系统理解“密封泄露”这个语义去召回相关的维修SOP片段。如果向量库挂了呢降级路径可以退而求其次用关键词去匹配“离心泵”“密封”“泄露”这些词再从文档库全文索引里找到包含这些词的内容。虽然召回质量没那么准但至少用户能得到一个“和问题沾边、且来自真实文档”的答案而不是对着一个冰冷的报错。三级降级链的设计目标就是守住三条底线不挂任何一级检索组件不可用时系统仍然能给出结果不胡说降级后只信任有依据的结果宁可答得保守也不能编不漏检每一级降级都要有明确的观测标记让用户和运维都清楚当前是“降级态”1.3 设计原则可观测、可追踪、可评分降级链不是“写个if else就完事”的东西。每一级降级的触发、切换、恢复都要能被观测到否则就是给自己埋雷。我们在AI工厂管家社区版里定了一条规矩任何一个检索请求响应里必须带上本次请求走的检索路径、命中结果数和相关性得分。路径用枚举表示比如VECTOR_SEARCH、FULLTEXT_SEARCH、SQL_FALLBACK。这样一旦线上出现“某类问题回答质量下降”打开日志一看就知道是不是走了降级路径而不是靠猜。2. 三级降级链的整体设计——从语义到关键词再到结构化查询2.1 为什么是三级而不是两级或五级最初的方案只做了两级向量检索挂了就降级到全文关键词检索。但后来仔细评估发现两级不够稳。全文索引服务本身也是独立组件它也有可能挂或者索引数据落后导致明明库里有一条精确匹配的文档片段就是搜不到。于是加上了第三级直接查后端关系型数据库里的文档元数据表用结构化条件过滤加上模糊匹配。至于为什么不做到五级、六级核心原因是每一级降级都有维护成本。多一级降级就意味着多一套打分规则、多一组日志字段、多一份压测报告。三级是目前性价比最合适的向量语义级保质量关键词全文级保召回结构化SQL级保底线。三级降级链的整体形态级别检索方式目标适合场景第一级向量语义检索召回最相关的内容正常状态追求回答质量第二级全文关键词检索BM25召回包含关键词的内容向量库异常或超时第三级结构化SQL检索按元数据条件兜底全文索引也异常或用SQL救急2.2 每一级降级的触发条件与切换阈值降级触发条件不能拍脑袋写得根据线上数据来定。我们一开始把超时阈值设成500ms结果高峰期正常请求也超时导致频繁降级切换。后来把阈值调成1000ms再配合连续失败次数统计才稳定下来。这是我们在AI工厂管家社区版里实际使用的触发与恢复配置降级级别触发条件恢复条件响应时间预算第一级→第二级向量检索连续3次超时1s以上或健康检查连续2次失败向量检索健康检查恢复且试运行10个请求成功率90%3s第二级→第三级全文索引连续3次查询报错或超时2s全文索引健康检查恢复且试运行5个请求成功5s第三级→兜底SQL查询结果为空或数据库连接失败数据库连接恢复8s注意切换频率必须做“冷却”。我们加了一个熔断器状态机两次降级切换之间至少间隔30秒避免服务刚恢复就又在下一波压力下被打回去形成“震荡切换”。2.3 请求串联与并行探测配合降级切换不能等请求到了现场临时探测那样延迟根本无法接受。正确做法是“后台健康检查 请求级熔断状态”。我们起了一个定时任务每10秒探测一次向量库、全文索引、数据库三个组件的连通性和响应时间把结果写进一个内存状态表。请求进来时直接读这张状态表判断当前走哪条路径不需要每个请求都自己去连一遍组件探活。当某个组件被判定为不健康时熔断器从关闭状态切换到打开状态所有请求自动走下一级降级路径。同时后台健康检查继续跑一旦组件恢复熔断器进入半开状态放少量请求过去验证成功了就关闭熔断回到正常路径。这个机制说起来简单但落地的时候细节非常多后面我会展开讲。3. 每一级降级的实现细节与实操要点3.1 第一级向量语义检索的“黄金路径”正常状态下AI工厂管家社区版走的是标准RAG流程。用户提问进来先调用嵌入模型把问题编码成向量再去向量库做近似检索取topK个相关片段拼装上下文最后交给大模型生成回答。这一级有几个参数直接影响检索质量值得认真调topK我们取5到8个片段取太少容易漏召回取太多模型容易被不相关内容干扰相似度阈值cosine相似度低于0.45的分片直接丢弃宁可少召回也不污染上下文metadata过滤前置先按设备型号、文档类型、车间的标签把候选集缩小再去做向量检索效率和准确率都会好很多超时控制连接超时设置500ms读取超时设置3000ms超过就标记为异常走降级逻辑之前踩过一个坑嵌入模型是本地部署的没有做过并发限制结果高峰期请求把嵌入服务CPU打到100%向量检索服务虽然健康但没有向量可用。所以后来我们在第一级路径里也加了对嵌入服务的健康检查嵌入服务挂了一样会触发降级。3.2 第二级全文关键词检索BM25第二级降级的核心是全文索引。向量库挂了但全文索引还在那就可以把用户的query拆成关键词去文档里做BM25检索。为什么不直接用数据库的LIKE查询呢这一点有讲究。中文场景下LIKE要自己处理分词“离心泵密封泄露”这个句子如果用%密封泄露%去匹配只要文档里没有原样的句子就匹配不到更别说各种同义词表达。BM25配合分词器至少能把“离心泵”“密封”“泄露”拆出来单独匹配再按照词频和逆文档频率算相关度结果排序合理性比LIKE高一个量级。展开说一下BM25在落地时要注意什么检索字段设计上我们对标题、正文、标签分别建了加权字段。标题命中权重高正文命中权重中等标签命中权重高——因为工厂文档里标签通常就是运维人员手动维护的分类词准确率很高。这个调整直接让第二级降级的召回准确率提升了将近一倍。中文分词是这级最大的坑。工厂场景里满天飞的都是“往复压缩机”“螺杆空压机”“PID调节阀”这种词汇通用分词器很容易把它们拆得七零八落。我们做了两件事一是维护了一个领域词典把常见的设备名和专业术语做成自定义词条加入分词器二是设置最小匹配词数如果一个查询切分出来的关键词只有一个词就直接将结果集扩大用前缀匹配来兜底。评分归一化也必须重点说明。向量检索返回的相似度是0到1的浮点数全文检索返回的BM25分却是几十分到几百分不等的数值两者直接比较没有意义。我们做了归一化映射把BM25分按照线上历史数据的百分位映射回0到1区间并在结果里标记来源。这个映射表不是写死的而是每个月根据实际检索日志重新计算一次保证分布漂移之后映射还能可信。第二级的触发条件很明确向量检索连续超时或者健康检查失败。但触发后不能“一根筋”地直接切换我们加了一个校验逻辑——如果当前请求的query长度小于两个字符或者query全由助词虚词构成就不走全文索引直接进第三级SQL框架因为这种query全文索引也召不回什么结果。3.3 第三级SQL结构化查询兜底第三级是底线中的底线。当全文索引也挂了或者索引数据因为某些原因明显落后时我们直接降级到后端数据库用结构化SQL来兜底。这个场景在工厂知识库里其实很典型文档表有设备类型、文档类型、关联的维护工单号、生效日期这些字段。SQL降级的具体策略是从query中抽取设备名、型号、文档类别等实体用这些实体作为WHERE条件去过滤文档元数据表对标题字段做LIKE模糊匹配加上有效期过滤条件避免给用户返回已废止的操作规程这一步看起来“原始”但效果却意外地好。因为工厂文档有非常强的结构化属性很多情况下“某个型号的设备对应的安全操作规程”这种请求不需要语义理解只要把设备型号匹配对了文档自然就对了。SQL降级有一个必须警惕的点它只能覆盖“查询条件能拆成实体”的场景。如果用户的query是“今天师傅说检修后泵的振动还是大怎么办”这种口语化描述根本拆不出实体来SQL查不到任何东西。所以第三级降级的输出结果必须带一个“低置信度”标记。如果SQL结果集为空就直接进入最后的兜底策略。兜底策略是给用户返回一个固定提示类似“当前知识库检索服务繁忙建议尝试更具体的关键词或稍后重试”同时附上几个最近高频问题的列表。别小看这个兜底它在降级链里兜住了最后一道本质——“用提示换时间”而不是让用户面对一个静默死的接口。3.4 每一级切换时如何保持结果连续降级切换最尴尬的时刻是同一台手机上午问同一个问题走的是向量检索答案质量很高用户觉得很智能下午再问向量库挂了系统走了全文索引答案虽然还行但明显不如上午。这个体验落差会让人得出“AI不稳定”的结论。我们的做法是降级路径的响应里带上检索路径标记同时在生成的答案里加一句温和的说明比如“该回答是基于关键词匹配的近似结果仅供参考”。表面上看是“降低预期”实际上却是在保护信任用户知道了当前答案是降级状态就不会用正常路径的标准来评判它也就不会把“质量下降”简单归因成“AI变笨了”。这种“透明机制”非常值得做你想清楚这一点后面做降级就不会太拧巴——我们不是为了跟用户交代是为了给系统质量评估留证据。4. 降级链最怕的坑——如何避免返回“看着像那么回事”的假结果4.1 相关性评分校准不要让降级结果“伪装”成正常结果标题里那句话其实是整个降级方案的核心痛点。降级的时候有两种典型烂结果一种是什么都召不回另一种是召回了看起来很像但实际不相关的内容。第二种更阴险因为LLM有极强的“圆谎”能力。假设全文索引召回了一段关于“离心泵拆卸”的文档但用户问的是“离心泵安装”如果模型直接把这段文档当成参考来生成回答结果会是“一本正经地讲着偏题的话”。对不懂技术的用户来说这种回答的杀伤力比直接报错更大——他们没法判断这是假的。我们在AI工厂管家社区版里做了一套“降级结果可信度校验”机制核心是三点最小结果数校验如果降级路径召回的文档片段少于3个直接判定为检索失败不把结果交给模型关键词命中率校验把用户query分词后计算降级结果里实际命中了多少关键词命中率低于40%直接丢弃低置信度强制标记降级路径的检索得分统一乘以一个0.8的系数作为提示模型“这些依据不够硬”的信号这几个校验规则跑通之后“假结果”的比例明显下降。我们不追求降级时能跟正常路径一样准但至少要保证给出去的结果是有依据的而不是因为“碰巧长得像”就拿来用。4.2 让模型知道“自己在降级”而不是“假装一切正常”这里多说一句prompt设计。我们发现同样的检索结果如果模型知道自身处在降级模式生成质量和表达姿态都不太一样。在AI工厂管家社区版里我们把检索路径作为一个变量注入了system prompt当前请求处于{retrieval_mode}模式。 如果检索模式为FALLBACK或SQL_FALLBACK回答时 1. 语气更保守避免绝对化表达 2. 优先从检索依据中摘取原文关键句减少推理总结 3. 在回答末尾追加一句“该回答基于有限检索信息建议核对原件”。这个动作很小但效果立竿见影。让模型“承认降级”本质上是把不确定性和风险显式表达出来避免模型在降级模式下强行自信生成一堆“看起来权威、其实站不住脚”的内容。4.3 熔断器与缓存策略避免震荡切换雪崩降级切换最怕的坑就是“一会儿好用一会儿不好用”的震荡状态。这个问题我们在接入初期吃过亏。当时熔断器设置得太敏感向量库一次超时就直接打开结果正常流量带着大部分请求切到了全文索引全文索引扛不住压力也跟着超时又切到了SQL整个链路的响应时间被拉长到不可接受。后来复盘做了三个关键调整熔断器打开的前几秒直接拒绝一定比例的请求而不是全部降级。我们设了一个“熔断系数”从0.3开始逐步提高到1.0给下游组件留出喘息时间。半开状态的验证请求量设成总流量的5%如果这5%里成功率超过90%才把熔断器关闭。要是直接恢复全部流量很可能会造成新一轮打挂来回抖动。降级过程中的检索结果会写到本地缓存TTL设成5分钟。同一个问题在降级期间被反复提问时只有首次请求真实查询后续都走缓存这样能减少降级组件压力也保证了用户体验的一致性。4.4 可观测性降级不应该是“黑盒”降级如果做得不可观测那它就是一个潜在的大事故温床。我们在社区版里为三级降级链专门加了一套观测面板核心指标如下降级率当前请求中走降级路径的比例正常情况应趋近于0各级检索召回率每级实际召回的文档片段数与理论应有数量之间的比例各级响应时间p50、p95、p99降级发生时的query样本自动截取原始文本存到专门的日志主题方便事后分析为什么触发降级这套观测体系不是给运维自嗨用的。有一次我们靠它在早上就发现了异常——降级率从0.2%飙到8%打开query样本一看某台设备的维修工单在持续涌入大量并发查询再查下去发现是系统上线新接口时把并发数没限制好把向量库连接池打满了。如果没有降级观测这个问题到业务报警的时候才会被发现那会儿用户早就开始骂了。5. 常见问题与排查技巧实录5.1 为什么向量库“看起来好好的”请求却降级了有一次我们排查过一类诡异现象向量库健康检查正常但请求却一直在走降级路径。检查之后发现健康检查是模拟查询一个固定的测试向量这个向量命中率很高速度自然快但实际业务查询的向量维度高某些批次的文档向量还没有完成索引构建导致查询时被标记为超时。排查思路分享如果健康检查正常但请求频繁降级优先看业务向量查询的慢日志而不是看组件健康状态。另外把健康检查的查询改成“从业务库随机抽一条热点文档向量”来探测比固定测试向量真实得多。5.2 降级后结果相关性断崖式下跌通常问题出在分词上。工厂文档里“压缩机”“空压机”“压风机”三个词表达的是同一个东西但通用分词器不会把它们当成一个概念结果用户问“空压机振动大”全文索引只匹配到“空压机”的字面词“压缩机”和“压风机”的文档全被漏掉。我们的对策是把场景同义词表直接做进分词器。维护了一份几百条术语的同义词映射关系分完词之后统一做一次同义词扩展再发给全文检索引擎。这是一个低成本但效果极好的优化强烈建议所有做中文知识库检索的同学都试试。5.3 降级切换时的“毛刺延迟”系统刚开始接入三级降级链时每次发生切换第一个降级请求的响应时间会高得离谱明明全文索引就在那边跑着但第一次查询却要几秒钟才出结果。后来查明白了全文索引的索引段在空闲时会自动合并压缩当降级发生时大量请求同时打过来索引段加载和缓存预热完全来不及。解决办法是在系统空闲的时候做一轮索引预加载把热点文档的索引段常驻内存。另外降级切换的前几个请求可以适当放大超时容忍度给组件留出预热时间。5.4 兜底策略完全没有结果时怎么办当三级降级全走完都没结果很多人会把错误直接抛给前端显示“检索失败”。这是最糟糕的处理方式。用户会在心里认定“这个知识库没有我的问题”哪怕下一次路径恢复也回不来。我们的兜底策略是模板化“无结果”页面给出几个操作建议方向同时把高频问题列表放在旁边。GPT帮不上的时候知识库的运营者就是最后的兜底人工服务和问题列表才是用户真正能抓住的救命稻草。6. 写在最后的实践经验这套三级降级链从设计、落地到线上跑稳前后经历了不少次折腾。就我个人最大的感受是降级方案不能等系统挂了再去想必须在系统还健康的时候就把降级设计成一个完整的、可测试的、能模拟故障演练的子系统。我们在社区版里定期做混沌演练把向量库服务人为停掉观察系统会不会正确走降级路径、每秒能扛住多少降级请求演练完成之后再恢复服务。第一次演练就发现了SQL降级路径里有个资源没有正常释放当时要是没演练就直接上生产遇到真故障大概率会二次故障。最后分享一个小技巧降级状态要“低调标记”而不是“声张降级”。我们上线初期在界面上打了一条“系统降级中响应质量可能下降”的黄色提示结果业务方非常紧张。后来我们把它改成了不提示而是把降级标记放在API响应的meta信息里由上层业务根据需要决定要不要展示。运维能看到用户不被打扰产品体验也能保持干净。如果你也在做RAG项目的可用性保障我的建议是从今天起就梳理一遍你的检索链路去掉向量库、去掉全文索引、去掉数据库逐级问一次“系统会变成什么样子”。能回答清楚这三个问题比写多完美的检索逻辑都重要。