RAG 的可靠性工程：从超时到降级的容错设计

RAG 的故障面：每个环节都可能失败

RAG 的管线有多个环节，每个环节都有独立的故障模式。嵌入服务的故障：嵌入 API 限流或超时——新文档无法索引、查询无法嵌入。向量库的故障：Qdrant/Milvus 不可达——检索完全失败。重排序服务的故障：Rerank 模型不可用——检索质量下降但不至于完全失败。LLM 的故障：生成模型超时或限流——最终回答无法生成。知识库的故障：文档源不可达——增量更新失败。每个故障的影响面不同：向量库故障是「致命」（检索完全失败），重排序故障是「降级」（检索质量下降），LLM 故障是「致命」（无法回答）——不同故障的应对策略不同。

降级策略：从全功能到降级模式的设计

降级策略的分级设计——每个环节的故障对应一个降级模式。向量库故障 → 降级为纯 LLM 回答（无检索上下文，模型用参数知识回答——质量下降但不至于无法回答，同时标注「当前无法检索知识库」）。重排序故障 → 跳过重排序（直接用向量检索的原始排序——检索质量略降但管线继续）。嵌入故障 → 使用缓存的嵌入（如果文档的嵌入有缓存）或延迟索引（新文档暂不入索引，查询仍可用已有索引）。LLM 故障 → 切换备用模型（本库 LiteLLM 篇的 fallback 链）或返回检索结果原文（不生成、只返回找到的文档——「帮你找到了这些相关文档」）。降级策略的设计原则：每个降级模式都要有「明确的用户告知」（「当前知识库检索不可用，以下为通用回答」——不欺骗用户）、降级不是静默的（监控与告警要感知降级的发生——降级率的突增是故障信号）。

超时与重试：RAG 各环节的超时策略

各环节的超时设置。嵌入调用：3–5 秒（嵌入计算快，超长意味着服务有问题）。向量检索：2–3 秒（向量检索快，超长意味着索引问题）。重排序：3–5 秒（Rerank 模型推理较重）。LLM 生成：30–60 秒（长回答的流式生成需要更久）。重试的策略：幂等操作可重试（嵌入调用、检索——重试无害）、非幂等操作不可盲重试（文档入库——重复入库导致数据重复——需要幂等键，本库幂等性篇）。重试的退避：指数退避 + 抖动（避免重试风暴）。超时的全局设计：RAG 的总响应时间 = 检索 + 重排 + 生成的总和——每个环节的超时预算要从「总 SLA」倒推（本库 SLA 篇）。

熔断与健康检查：防止故障级联

熔断器在 RAG 中的应用：当某个环节连续失败（如 Rerank 服务连续 5 次超时），熔断器打开——后续请求跳过该环节（直接降级），避免每个请求都等待超时——熔断把「每请求等待超时」变成「一次性降级」（本库 Agent 工程安全篇的熔断原则）。健康检查：各环节的定期健康探测（向量库 ping、嵌入 API 试调用、LLM 健康检查）——健康状态的路由（健康的用完整管线、不健康的用降级管线——路由是动态的）。恢复机制：熔断后的半开状态（定期尝试恢复——服务恢复后自动关闭熔断器）。

可靠性的测试：故障注入验证

可靠性的设计需要验证——故障注入的测试。注入的场景：向量库超时（模拟——延迟注入或服务下线）、嵌入 API 限流（模拟——返回 429）、Rerank 故障（模拟——服务不可达）。验证的目标：降级策略是否正确触发（降级的模式是否符合设计）、降级的用户体验（降级模式下的回答质量是否可接受）、恢复的自动化（故障恢复后是否自动回到完整管线）。故障注入的工具（本库混沌工程的原则）：在测试环境中手动注入（kill 容器、iptables 阻断）或用混沌平台自动注入。可靠性的收束：RAG 的可靠性不是「不出故障」，是「每个故障都有预设的应对」——降级策略是「预案」，故障注入是「演练」——预案 + 演练 = 可靠。

## RAG 可靠性的监控：从故障检测到自动降级

RAG 可靠性（正文降级）的监控实现：故障检测与自动降级的实现。故障检测的指标。检索延迟（向量检索的 P99——突增 = 向量库故障或网络问题）、检索空结果率（空结果的比例——突增 = 知识库问题或嵌入模型漂移）、生成错误率（LLM 调用的错误率——突增 = 模型服务故障）、端到端延迟（RAG 全链路的 P99——全链路的延迟分解定位瓶颈）。自动降级的实现。熔断器的集成（每个环节的熔断器——连续失败时自动打开——本库可靠性篇的熔断原则）、降级的自动切换（熔断打开时自动切换到降级模式——降级不需要人工介入——自动化是降级的灵魂）、以及恢复的自动检测（熔断的半开状态——服务恢复时自动关闭熔断器——恢复的自动化让运维不需要手动干预）。监控的收束：RAG 可靠性的监控，是「检测-降级-恢复」三步的自动化闭环——每一步的自动化减少了人工介入的延迟；监控的指标覆盖了每个环节的故障模式，降级的自动化确保了故障时的用户体验。

RAG 可靠性的进阶：降级模式的质量保证

RAG 可靠性（正文降级）的进阶：降级模式的质量保证——降级时的回答质量不能太差。降级模式的质量问题：纯 LLM 回答（无检索上下文）的质量显著低于有检索的回答——降级模式的质量管理需要设计。降级的质量策略：降级时的提示词调整（降级模式的提示词标注「当前无法检索知识库，以下基于通用知识回答」——诚实的降级标注）、降级模式的回答范围限制（降级模式不回答需要具体数据的问题——通用知识可以答、具体数据不编）、以及降级的质量监控（降级模式的回答质量单独监控——降级率与降级质量的联动监控）。降级的收束：降级不是「随便答答」，是「有质量的降级」——降级模式的用户体验也需要设计——降级模式的质量下限，决定了 RAG 系统的可靠性下限。

RAG 可靠性的实战案例：一次向量库故障的降级实录

RAG 可靠性的实战案例：向量库故障的降级实录。故障：向量库集群故障（Qdrant 不可达）——检索完全失败。降级的自动触发：健康检查检测到向量库不可达 → 熔断器自动打开 → 请求切换到降级模式（纯 LLM 回答，标注「当前无法检索知识库」）。降级期间的体验：用户仍然能得到回答（LLM 用参数知识）但回答没有引用、质量下降——用户被告知「检索不可用」而非被欺骗。恢复与验证：向量库修复后 → 健康检查恢复 → 熔断器关闭 → 自动回到完整管线 → 降级期间的用户反馈收集（降级模式的满意度评估）。案例的收束：这次故障的零投诉（用户被告知并接受了降级模式）验证了降级策略的有效性——降级的预案 + 自动的切换 + 诚实的告知 = 可靠性的完整闭环。

RAG 可靠性的进阶：全链路的超时预算管理

RAG 可靠性（正文超时）的进阶：全链路的超时预算管理——RAG 每个环节的超时要从总 SLA 倒推。超时预算的倒推方法：总响应时间 SLA（如 P99 < 10 秒）→ 分配到各环节：检索 2 秒 + 重排 1 秒 + 上下文组装 0.5 秒 + LLM 首 token 2 秒 + 流式输出 4.5 秒 = 10 秒——每个环节的超时预算从总 SLA 倒推。超时的策略：软超时（超过预算后继续等待——不中断但记录超时事件）、硬超时（超过硬上限后强制中断并降级——硬超时防止无限等待）。超时的动态调整：根据流量调整（高峰期放宽超时——高峰期的延迟本来就高）、根据 SLA 等级调整（企业客户的超时更短——SLA 等级决定超时的严格程度）。超时预算的收束：超时预算管理是「SLA 到工程」的翻译层——SLA 定义了「多快」，超时预算定义了「每步多快」——没有超时预算的 RAG 系统，遇到慢环节会无限等待，最终导致整体的 SLO 崩溃。

RAG 可靠性的进阶：故障检测与自动恢复闭环

RAG 可靠性的监控实现：故障检测与自动降级的闭环。故障检测的指标：检索延迟（向量检索的 P99——突增等于向量库故障或网络问题）、检索空结果率（空结果的比例——突增等于知识库问题或嵌入模型漂移）、生成错误率（LLM 调用的错误率——突增等于模型服务故障）、端到端延迟（RAG 全链路的 P99——全链路的延迟分解定位瓶颈）。自动降级的实现：熔断器的集成（每个环节的熔断器——连续失败时自动打开）、降级的自动切换（熔断打开时自动切换到降级模式——降级不需要人工介入——自动化是降级的灵魂）、恢复的自动检测（熔断的半开状态——服务恢复时自动关闭熔断器——恢复的自动化让运维不需要手动干预）。监控的收束：RAG 可靠性的监控是「检测、降级、恢复」三步的自动化闭环——每一步的自动化减少了人工介入的延迟。

小结

RAG 的可靠性工程：每个环节（嵌入、向量库、重排序、LLM）都有独立的故障模式，降级策略按「故障影响面」分级设计（致命故障切备用、降级故障跳环节）。超时与重试按幂等性区分，熔断防止故障级联，故障注入验证降级的有效性。RAG 可靠性的核心心法：部分失败不等于系统失败——每个环节都要有「失败时的 Plan B」，Plan B 的质量决定降级时的用户体验。