做 RAG 检索最怕的不是模型笨而是向量库在关键时刻掉链子——服务起不来、集合是空的、维度对不上检索请求一进来就报错整个问答系统直接瘫了。咱先把结论摆前面RAG 做降级本身不难难的是降级的时候不返回一个“看着像那么回事”、实际上全靠模型现编的回答。我在“AI工厂管家”社区版这类项目里做的就是这件事把检索能力做成一条三级降级链从向量检索一路降到关键词检索、结构化查询、最后带着护栏让模型直出保证服务不中断也不拿幻觉糊弄人。下面把这套链路的设计思路、实现细节和踩坑记录完整盘一遍。1. 三级降级链是什么为什么非得三级1.1 RAG 检索链路的基本模样一个标准的 RAG 查询长这样用户提问 → embedding 向量化 → 向量库召回 TopK 片段 → 把片段拼进提示词 → 大模型生成回答。向量库是中间最关键的一层它决定了模型到底能看到什么业务上下文。这也意味着一旦向量库出问题整条链路就断了。很多人第一反应是“那就不检索了直接问模型”。这在技术演示里没问题在真实业务里就是灾难——因为模型没有业务上下文的约束唯一要做的就是给你编一个听起来合理的回答。尤其像“AI工厂管家”这类面向生产管理场景的工具用户问的是产量、设备状态、排产计划编出来的数据如果被当成真的拿去用后果不是一句“不好意思”能搪塞的。所以必须有降级。但降级不是简单粗暴地换一个检索方式而是要回答一个问题当最核心的向量检索不可用时系统还能不能提供有价值的回答用什么来源提供1.2 降级链解决的真实痛点我一开始在社区版里只做了一级降级向量库挂了就直接返回“系统暂不可用”。结果被用户喷得很惨——白天车间里要查工单系统说不可用就不可用生产节奏全被打乱。另一个常见做法是“向量库不行就让大模型硬答”这个更危险。不是每次硬答都会被识破但只要有一两次编错了数据用户对系统的信任就清零。三级降级链解决的是这两个痛点不能让服务中断用户的问题必须得到回应哪怕响应慢一点、格式朴素一点。不能让回答失去来源依据每一级降级都必须对应一个“数据来源”来源不可用时宁可拒绝回答也不能让模型自由发挥。1.3 三级而不是一级的原因只降级到关键词检索覆盖不了所有问题。比如用户问“一号线今天产量多少”关键词检索很难从技术文档里找到答案必须去查业务数据库。而关键词检索和结构化查询都失效的时候又需要一个最底层的兜底方案。所以三级的设计逻辑是能力梯度从“语义理解最准”一路降到“实现最稳”每一级都在前一级失效时接管第一级关键词检索BM25/倒排索引解决“向量库临时故障但文本索引还在”的情况。第二级结构化数据查询SQL/元数据解决“连文本索引也没有但业务数据还在”的情况。第三级无检索直出受限LLM所有检索通道都断了只能让模型基于通用知识回答但必须加护栏、亮明身份。这三级的核心并不是“检索效果越来越好”而是在可用性和准确性之间取一个工程上的最优解。实际项目里不一定三级全要但理解了这条链的取舍逻辑做一二级也会顺手很多。2. 向量库没装好时故障的实际长相2.1 最常见的“装不好”现场标题里说的“向量库没装好”在真实环境里有各种奇奇怪怪的形态它们都表现为检索失败但背后的原因完全不同。依赖装了但服务没启动pip 把客户端装好了但向量数据库服务端根本没跑起来。代码连接时报 Connection refused这类问题最直接。集合没创建首次部署时忘了初始化集合建了连接但查询时提示 collection not found。维度不匹配本地用的 embedding 模型输出 768 维向量库里建的集合是 1536 维插入或者查询的时候维度校验直接抛异常。数据没灌入程序能跑但写库的定时任务没执行或者数据导入脚本被跳过集合是空的检索返回空结果。持久化没做好容器没挂载数据卷服务一重启索引就全丢了。超时配置太短数据量大了之后查询变慢之前设的 200ms 超时被打爆服务其实没坏但请求经常失败。这些现象里有些是配置错误有些是运行时故障有些只是空结果。它们的处理方式完全不同配置错误应该快速失败并让开发者意识到问题运行时故障才应该走降级链空结果则属于“结果质量”问题不能一股脑当成故障处理。2.2 故障类型与判定的关键区别这是最容易踩坑的地方。想做好降级先要把“向量库状态”和“检索结果状态”分开看。向量库状态指的是服务本身是否可用能不能连上、能不能执行查询、异常是什么类型。对应三个值OK服务正常能执行查询。UNAVAILABLE连接失败、认证失败、超时、服务不存在属于服务层面的故障。CONFIG_ERROR维度不匹配、集合不存在、embedding 模型加载失败属于配置层面的错误。检索结果状态指的是查询执行完之后结果是不是靠谱有结果且分数达标正常使用。有结果但分数很低检索到了内容但语义匹配度不够如果强行组装上下文模型很大概率会答偏。空结果库里没写入相关数据或者阈值设得过高。异常执行过程中抛了错也就是向量库状态里的 UNAVAILABLE 或 CONFIG_ERROR 在查询层的体现。降级链要触发的是UNAVAILABLE。对于 CONFIG_ERROR我的建议是让请求快速失败并打错误日志原因很简单配置错了不是临时故障你连集合名、维度都没配对降级到哪一级都解决不了根本问题。如果在这种情况下还静默降级开发者永远发现不了配置问题系统会长期以一种低质量模式运行用户还以为这是正常表现。2.3 从标题里那句话说开去标题里那句“RAG 做降级本身不难”确实如此。你可以在异常捕获里直接走备选路径代码量不大。但“难的是降级的时候不返回看着像那么回事的结果”才是重点。故障的形态千差万别但目标只有一个在向量库不可用时要么给出有来源的正确答案要么明确告诉用户“我暂时给不了可靠答案”绝不含糊地编一个。3. 三级降级链每一级的实现细节3.1 第一级关键词检索接管BM25向量库故障后的第一个替代方案是关键词检索。关键词检索做的是字面匹配没有语义理解能力但它实现简单、部署稳定、几乎不会像向量库那样出各种环境问题。在社区版项目里我推荐用 SQLite FTS5 或者 PostgreSQL 的全文检索来实现而不是非得引入一套搜索引擎。原因很朴素这类项目通常没有专职运维少一个外部依赖就少一堆故障。SQLite FTS5 是嵌入式方案数据文件跟着项目走不需要单独部署用户环境里只要 Python 能跑它就能跑。检索逻辑核心代码如下def keyword_search(query: str, top_k: int): # FTS5 支持 BM25 排序score 越高相关性越强 sql SELECT chunk_id, chunk_text, bm25(chunks_fts, 0.0, 1.0) AS score FROM chunks_fts WHERE chunks_fts MATCH ? ORDER BY score DESC LIMIT ? rows db.execute(sql, [query, top_k]).fetchall() return [{chunk_id: r[chunk_id], text: r[chunk_text], score: r[score]} for r in rows]注意 FTS5 的 MATCH 语法对特殊字符敏感用户输入里带引号、括号时查询会报错。必须做一步输入清洗把特殊字符过滤掉或者转义否则第一级降级会自己变成第二级故障。这个坑我遇到不止一次。第一级适合回答哪些问题技术手册类、维护计划类、常见FAQ类文本里有明确的关键词能对上。它不适合回答数据统计类问题比如“昨天一共生产了多少件”因为答案在数据库里不在文本里。这种情况就轮到第二级。3.2 第二级结构化数据兜底SQL查询当关键词检索也拿不到结果或者问题本身是一类“查数据”的问题时第二级把自然语言查询转换成结构化查询。这一步听起来很玄但在社区版项目里完全可以做得轻量。不需要上复杂的 NL2SQL 模型用规则解析就够用。以“AI工厂管家”为例常见问题就那几类查产量、查设备状态、查工单进度、查某条线某段时间的数据。解析逻辑可以这样拆def parse_query(query: str): # 规则解析识别产线、日期、指标 line None date None metric None for name in [一号线, 二号线, 涂装线, 总装线]: if name in query: line name break for day in [今天, 昨天, 前天, 本周, 本月]: if day in query: date day break for m in [产量, 开工数, 完成数, 良品率, 停机时长]: if m in query: metric m break return {line: line, date: date, metric: metric}解析之后拼 SQL、查数据库把结果包装成和向量检索完全一致的“片段”结构返回def structured_search(query: str): parsed parse_query(query) if not parsed[metric] or not parsed[line]: return [] # 解析不出来就继续降级 sql SELECT value FROM daily_stats WHERE line? AND dt? row db.execute(sql, [parsed[line], parsed[date]]).fetchone() if not row: return [] return [{chunk_id: structured_result, text: f{parsed[line]} {parsed[date]} {parsed[metric]}: {row[value]}, score: 1.0}]这一级的关键是解析器必须诚实。解析不了就返回空把机会留给下一级不要硬凑一个查询条件。硬凑的结果往往是查出一个错误数据比没有数据更糟。3.3 第三级无检索直出带护栏的纯 LLM 回答前两级都失效时已经没有任何本地数据可作为回答依据了。理论上应该拒绝服务但实际产品里完全拒绝也不行。第三级做一个“受限直出”让 LLM 基于模型自身知识回答问题但通过提示词和输出校验把风险压到最低。提示词层面这样做system: 你是一个生产管理问答助手。当前知识库和业务数据库均不可用你只能基于自身通用知识回答。 规则 1. 如果问题涉及具体生产数据产量、数量、时间、设备编号你必须回答“当前数据源不可用暂时无法获取具体数据”。 2. 如果问题是通用的常识性问题你可以正常回答但回答前加上“注意以下为通用信息未经业务数据验证”。 3. 禁止编造任何数字、统计结果或业务事实。同时在代码层面对输出做二次校验如果用户的输入里包含“产量”“数量”“完成率”等数据指示词而模型输出里没有任何“无法获取”相关的话术就把答案强制替换成标准模板。模型输出是不可控的但工程代码可以把控最终的结果。第三级回答的样子应该是“当前知识库检索暂时不可用我无法获取具体业务数据。建议稍后重试或联系管理员检查数据服务状态。通用资料方面排产通常需要考虑设备产能、物料齐套和交期优先级……”有信息就说信息没信息就承认没信息。不冒充检索结果。4. 降级不难难在不返回“看着像那么回事”的结果4.1 为什么“像样的回答”反而更危险前面几章都在讲降级结构这一章专门讲最核心的那个问题降级时为什么容易返回“看着像那么回事”的结果。因为大模型的生成能力太强了。你给它一个问题它天生就想给一个流畅、自信、有结构的回答。哪怕没有任何检索上下文它也能编出一个带编号、带术语、带“根据系统数据”这种前缀的回答。从文字表面看它和正常回答几乎没区别。危险就在这里。用户不是开发者他不会去分辨这句话是来自向量库检索还是模型瞎编。他只看到系统给了个答案然后拿这个答案去做判断。生产场景中如果一个管理者根据编造出来的“本周良品率 98.7%”去做决策后果是实打实的。更要命的是这种错误很难被发现。系统日志里记录的是“回答成功”没有报错没有异常根本没人知道这次回答是没有数据支撑的。4.2 置信度阈值与组装规则要杜绝这种情况光靠提示词不够必须从工程上做三层约束。第一层是检索分数阈值。不管从向量库还是关键词索引拿到结果都要对分数做判断。低于阈值就不允许组装进上下文。def assemble_context(results, min_score): passed [r for r in results if r[score] min_score] if not passed: return None # 没有合格的上下文走降级或拒答 return \n.join(r[text] for r in passed[:5])阈值怎么定向量检索的相似度分数和 embedding 模型有关有的模型 0.75 才算相关有的 0.3 就够用。我建议项目里跑一个“测试集打点”拿 20 个真实问题手动标注哪些检索结果是有用的然后统计分数的分位数取“有用结果的最低分”再留一点余量作为阈值。不要拍脑袋写 0.5不同模型之间差异很大。第二层是无上下文强制拒答。组装的结果为空时后面的 LLM 调用要换成“拒答模式”的提示词而不是继续按正常流程生成。很多项目死在这一点上上下文为空时没做分支处理模型拿到一个只有问题的 prompt当然自由发挥了。第三层是输出校验。在最终返回给用户之前代码检查回答文本里是否包含了需要拒答的关键词。如果用户问的是数据类问题而回答里没有“无法获取”“不可用”等标识说明模型违规了直接替换成标准拒答模板。这三层约束的本质是把“拒绝编造”从模型的行为要求变成工程上的强制规则。模型永远倾向于给一个流畅回答这是它的训练目标我们不能指望它在缺失上下文时自觉拒答只能在代码层面拦住它。4.3 透明化标记与用户感知还有一个容易被忽视的问题降级时用户根本不知道当前是降级模式。他看到的界面和平时一样输入框还是那个输入框回答还是有模有样他会默认这是完整功能的回答。所以降级回答必须带模式标记。我强烈建议在回答的最前面加一行前缀正常模式不加标记。第一级降级[关键词检索模式]第二级降级[结构化数据模式]第三级降级[离线直出模式数据未验证]不要小看这一行字。它的作用有两个第一用户能看到当前数据来源对回答的可信度有心理预期第二它对运维排查问题极其重要一看到前缀就知道这次回答走了哪条链路不用翻半天日志。有的同事说加前缀“丑”怕影响用户体验。我实际做了之后发现用户不但不反感反而更有安全感——因为他们能明确知道系统当前处于什么状态而不是面对一个真假难辨的回答。5. 实操在社区版里落地这条降级链5.1 健康检查与状态判定落地降级链的第一步是写健康检查。但这里有个关键经验不要每次请求都做全套健康检查成本太高。正确姿势是“快速探针 异常捕获 状态缓存”。class RetrieverState: OK ok KEYWORD_FALLBACK keyword STRUCTURED_FALLBACK structured OFFLINE offline class RAGRetriever: def __init__(self): self.current_state RetrieverState.OK self.fail_count 0 self.last_check 0 def check_vector_store(self): # 快速探针只做轻量请求不执行完整搜索 try: self.vector_store.ping(timeout1) return True except Exception: return False def search(self, query): if self.current_state RetrieverState.OK: try: results self.vector_store.search(query, top_k5) if results is not None: self.fail_count 0 return results, self.current_state except Exception: self.fail_count 1 if self.fail_count 3: self.current_state RetrieverState.KEYWORD_FALLBACK self.last_check time.time() # 前几次失败先返回空让上层走拒答逻辑 return [], self.current_state # 降级状态下周期性尝试恢复 if time.time() - self.last_check 30: if self.check_vector_store(): self.current_state RetrieverState.OK self.fail_count 0 # 按状态走降级链路...注意“连续失败 3 次才切换”的设计。因为偶发的一次超时可能是网络抖动不值得立刻降级但连续失败基本可以确定服务出了问题。30 秒的恢复探测周期让系统在故障恢复后能自动切回来不用人工介入。有一个细节需要提醒降级状态要记录切换时间和触发原因。排障的时候你不知道它是几点切到降级链的那排查效率至少低一半。5.2 切换逻辑与参数配置完整的检索流程是“先健康状态判断再逐级尝试”。具体参数可以做成配置文件方便在不同环境里调整。# retriever_config.yaml vector_store: connect_timeout: 1s query_timeout: 0.5s fail_threshold: 3 recovery_interval: 30s keyword: top_k: 5 min_score: 0.35 structured: timeouts: 1s rag: max_context_chunks: 5这些参数的设置逻辑connect_timeout 设 1s连接不可达时快速失败不要让用户等十几秒才报错。query_timeout 设 0.5s查询本身要快RAG 场景里大模型生成已经占了不少时间检索环节越短越好。fail_threshold 设 3连续 3 次失败才降级过滤偶发抖动。recovery_interval 设 30s降级后每 30 秒探一次平衡恢复速度和资源占用。还有一个容易被忽略的点在降级链前面加一个热点问答缓存。用户问的问题重复率很高把高频问题的答案缓存 10 分钟正常情况下能省掉大量向量库请求降级时缓存命中甚至可以完全绕开降级链直接返回正确结果。这个不算降级链的一级但它是所有降级策略前面的“缓冲垫”实测收益很大。5.3 日志、监控与手动切换降级链不是写完就完事的它需要被看见。每一级触发都要打结构化日志至少包含请求 ID、降级级别、触发原因、耗时、是否恢复。{ request_id: req_12345, event: retriever_fallback, level: keyword, reason: vector_store_connection_timeout, latency_ms: 980, recovered: false }用这种格式打日志之后排查的时候按 request_id 一查就能看到这个请求发生了什么。就算没有完整的链路追踪系统这种日志也足够好用。另外一定要提供一个手动强制切换的管理接口。比如一个简单的命令行工具或者管理后台按钮让运维可以手动把系统切到某一级降级状态。它的价值在于测试和验证——你不能等故障真发生了才去验证降级链好不好用平时就应该手动切到每一级把每一条路径都测通。我就吃过这个亏写完降级链后从没强制测过结果真故障的时候发现第三级的提示词写错了模板返回的是一段乱码。6. 常见问题与排查实录6.1 故障现象速查表下面这些故障是我在实际环境里真实遇到过的整理成速查表排查的时候可以直接对号入座。现象可能原因排查方法请求报 Connection refused向量库服务端未启动或端口配置错误先测试端口连通性再去看服务端日志查询报 collection not found首次部署没初始化集合或初始化脚本没执行检查迁移脚本手动创建集合插入/查询报维度错误embedding 模型换了但向量库里旧数据还是老维度检查模型输出维度与集合配置重建集合并重新灌数据检索返回空结果数据未写入或分数阈值定得太高手动插入一条测试向量跑一次查询确认降级链一直不触发异常被上层代码吞掉了没走到降级分支检查所有 try/except确认异常类型是否被匹配降级链误触发健康检查探针写得过严把慢查询当成故障区分“服务不可用”和“结果质量差”只有前者才该触发降级关键词检索报 MATCH 语法错误用户输入包含 FTS5 特殊字符对输入做清洗和转义过滤掉()等字符6.2 降级链异常排查的三个思路第一个思路是看状态切换点。日志里有状态从一个值切到另一个值的记录先确认它是从哪一级切到哪一级、什么时候切的。如果系统一直停留在降级状态不恢复多半是 recovery_interval 的探针逻辑写错了比如探针执行了但没有重置 fail_count。第二个思路是区分“错误”和“空”。有时候不是降级链坏了而是某级检索返回了空结果。空结果会继续往下一级走如果每一级都返回空最后会走到第三级拒答。这是正常流程不是 Bug。但如果你期望第二级结构化查询能查到数据结果却返回空那问题可能出在解析器上——它没把用户问题里的字段对出来。第三个思路是检查超时情况的累计效应。向量库查询超时、关键词检索超时、结构化查询超时三级叠加加起来可能超过 2 秒用户体感就是“系统变慢了”。排查时要看每一级的耗时分布不要只盯着最终结果。我之前遇到过一次系统响应从 0.5 秒变成 4 秒的案例查了半天才发现是关键词检索那边有一段代码对全表做了模糊匹配数据量大之后特别慢。6.3 实际项目里踩过的坑写这部分的时候我脑子里的第一反应是“空召回当成故障”那次事故。当时系统刚上线数据导入脚本跑完但索引还没建好向量检索的结果一直是空。我没有区分“服务正常但没结果”和“服务不可用”直接触发了降级链。结果所有用户都拿到了关键词检索的结果而关键词匹配专业术语的能力很弱大家收到的回答质量很差。后来我把状态机改成了“服务状态”和“结果状态”两个维度只有服务层面的异常才触发降级结果层面的空召回走“阈值拦截 拒答”彻底分开了这两件事。另一个坑是第三级提示词的输出长度控制。最初没有限制 max_tokens有一次降级到离线直出模式时模型基于通用知识写了一篇 800 字的小作文把“拒绝回答”硬生生写成了“生产管理全面指南”。加了 max_tokens 限制并且要求“优先用一句话表明数据不可用”之后输出才变得可控。最后再说一个技巧每次发布降级链相关代码后强制手动切到每一级各跑一遍。这件事最好加到发布检查清单里。很多问题单看代码发现不了必须实际切换一次看到输出才能暴露。我这个习惯是在一次线上事故之后养成的从那以后降级链相关的改动再没出过大问题。这套三级降级链的思路可能不是最优解但它的核心原则我很确定是对的降级只是一种止损手段而不是一个用来掩盖故障的遮羞布。每一次降级都要让用户知道发生了什么、数据来源是什么、可不可信。把这句话想透你设计任何降级方案的时候都不会跑偏。