当 RAG 系统从实验阶段走向生产环境，一个绕不开的问题就是：如何保证服务始终可用、响应稳定，并在部分组件故障时不至于全面崩溃？ 高可用不仅是“加几台机器”那么简单，而是需要从架构层面设计容错能力，确保在流量高峰、节点宕机甚至部分依赖失效时，用户依然能获得符合预期的回答。
下面从 RAG 系统的两个核心链路——检索与生成——以及整体服务层面，介绍实用的高可用设计思路。
1. 多副本部署：消除单点故障
RAG 系统的关键组件包括向量数据库、嵌入模型服务和大语言模型服务。其中任何一环成为单点，都可能导致整体不可用。因此，每个组件都应至少部署双副本，对无状态服务甚至可以做到水平自动伸缩。
- 向量数据库副本
主流向量数据库（如 Milvus、Weaviate、Qdrant）都支持多节点集群部署，数据分片并存在多个副本上。如果某个节点宕机，查询会自动路由到其他副本。
实际做法：部署时至少设置 2 个副本，对于读多写少的 RAG 场景，读请求可以由任意副本承担，既提升可用性也分担负载。
- 嵌入模型服务副本
嵌入服务通常是无状态的 HTTP 或 gRPC 微服务（例如用 FastAPI 封装的 Sentence-Transformer 模型）。可以部署多个实例，前面挂载负载均衡器。当某一实例因显存溢出或进程异常挂掉时，流量自动转移到健康实例，对调用方透明。
- 大模型推理服务副本
类似地，大模型推理（无论是自部署的 LLM 还是通过 API 调用）也应具备冗余。对于自部署模型，可使用如 vLLM、TensorRT-LLM 等框架开启多 GPU 多节点推理，并通过 API 网关统一接入；对于第三方 API，应配置多条可用通道（如备用 API Key、不同区域节点），防止单一依赖不可用。
所有副本的指标（请求延迟、错误率、资源占用）都应接入监控，并配合自动告警，以便在副本失效时快速响应。
2. 负载均衡：合理分配流量，避免倾斜
多副本部署后，需要通过负载均衡将请求均匀或智能地分发到各实例。RAG 场景中的负载均衡需注意两点：一是流量特性（检索轻量、生成长时），二是状态考虑（向量查询有时需要会话保持）。
- 无状态服务的均衡
嵌入模型服务和生成服务都是无状态的，可以使用轮询（Round Robin）或最小连接数（Least Connections）策略。最小连接数策略更适合生成服务，因为不同请求的生成长度差异很大，能避免把多个长文本生成请求堆到同一个实例上导致排队超时。
- 向量数据库的均衡
多数向量数据库客户端 SDK 内置了连接池和路由策略，可以自动感知集群拓扑，将查询分发到健康节点。如果使用客户端直连，需确保配置了合理的重试和退避逻辑。
- API 网关统一入口
建议在 RAG 系统的前端部署一个 API 网关（如 Nginx、Kong 或云厂商的 API Gateway），它负责接收用户请求，并向后端的检索和生成服务进行反向代理。网关层可以实现：
- 健康检查：定期探测后端实例的 /health 端点，自动摘除异常节点。
- 限流与熔断：控制每秒并发量，保护后端不被突发流量冲垮。
- 请求路由：根据请求参数（如意图分类）将不同场景的请求路由到不同的模型服务或知识库集群。
3. 降级策略：失败时依然“兜得住”
即使多副本和负载均衡做得再好，极端情况下仍可能出现检索超时、生成服务过载或第三方 API 不可达等问题。这时候，系统需要有能力优雅降级，而不是直接报错或返回混乱内容，让用户感到困惑。
3.1 检索环节降级
- 超时 fallback：给向量检索设置明确的时间阈值（比如 200 ms），超时时改为更轻量的检索方式——例如回退到基于关键词的全文检索（Elasticsearch），或者使用预置的静态高频问答列表匹配。
- 片段不足时拒绝作答：当检索得分整体偏低，找不到足够相关的文档时，不要强行把无关片段送给 LLM 生成。应当直接回复预设话术，如“我暂时没有在知识库中找到与您问题匹配的信息，建议联系人工客服”。这既避免了幻觉，也维护了用户信任。
- 本地缓存常用知识：对于访问频率极高的少量知识点（如公司地址、客服电话），可以将答案直接缓存在 Redis 或网关层，完全跳过检索步骤，即使后端检索服务全挂，这些核心问题仍能秒回。
3.2 生成环节降级
- 备用模型切换：当主力生成模型（例如自部署的大参数模型）由于资源耗尽无法响应时，自动切换到备用的轻量模型（如量化后的 7B 模型）或云端的 GPT-3.5 级 API。虽然回答质量可能略有下降，但保证了系统的持续可用。
- 缩短输出长度：在高负载时，可以通过改写提示词限制最大生成长度（如“请用一句话简要回答”），减少每个请求的 token 消耗和处理时间，提升吞吐，避免排队雪崩。
- 兜底规则回复：如果所有生成通道都不可用，则返回检索到的原文摘要或预设的标准化回复，并附上“系统繁忙，以下为直接检索到的相关信息”的说明。用户至少能看到原始资料片段，而不是空白页。
3.3 整体流控与熔断
在网关层配置熔断器：当某一服务（如生成 API）的错误率超过阈值（例如 5%）且持续一段时间，网关会暂时熔断这个服务，直接走降级逻辑，快速失败并返回，避免级联延迟拖垮整个请求链路。同时，限制全局并发请求数，超过时进入队列等待或直接拒绝，保护系统不被突发流量打垮。
4. 实战建议清单
- 所有服务必然多副本，且支持自动重启和健康检查，无状态服务做到随时可重建。
- 区分常态化负载与峰值负载，日常保持最小副本数，利用弹性伸缩在高峰前自动扩容，节省成本。
- 降级策略提前写到配置中并经常演练，确保运维人员熟悉切换流程，而非线上出问题时才临时想方案。
- 监控一切：每个组件的 QPS、延迟百分位数、错误码分布、缓存命中率、降级触发次数，并针对降级设置专门的告警，因为降级是“暂时掩盖问题”，需要及时排查根源。
高可用不是一蹴而就的，而是通过逐步叠加多副本、完善降级措施、持续观察优化来达成。当用户在任何时间点都能获得稳定、可靠的回答时，技术层面的这些保障才能真正转化为业务上的信任。