RAG 服务部署前先核对数据、连接和降级路径在预发环境成功问到一条资料不代表检索服务已经适合上线。真实运行中文档会更新和撤权索引会延迟或重建模型服务也可能暂时不可用。部署检查若只验证“接口返回了答案”这些关键路径会在流量进入后才暴露。更实用的核对方式是顺着一次请求走用户是否有权访问资料数据何时进入索引检索和重排使用了什么版本模型调用占用了哪些资源任何一环失败后页面会收到什么结果。每一步都要有明确答案。数据与索引不能各自认为已经更新文档新增、修改、删除和权限变更都需要传递到索引。尤其是撤权和删除不能只更新主库而让旧向量、摘要或缓存继续命中。系统需要知道索引使用的数据版本并在版本落后时选择可解释的行为暂时提示资料更新中、退回到可验证的关键词检索或只使用仍确认有效的数据。不要默默把“最近一次可用”当作“当前正确”。对于不同业务允许的滞后不同这个策略应由产品和数据负责人明确而不是藏在检索代码的异常分支中。若返回的是旧结果也要有条件地标注或限制其用途避免用户据此做需要最新信息的决定。索引构建任务本身也要可追踪。它处理了哪些文档版本、失败在哪一步、是否部分成功、回滚后是否会留下孤儿数据都应能从任务记录看出来。重建索引时最好避免让旧索引和新索引无规则混用切换点需要清晰。配置要随着发布物一起管理模型地址、嵌入模型版本、分片策略、检索参数、重排开关和权限规则都会改变输出。它们不应只存在于某台机器的环境变量里。将关键配置版本化并在部署记录中关联提交、镜像和索引快照出现问题时才知道不同副本是否运行了同一套规则。公开给服务调用者的配置与内部凭据要分开。模型和数据库的密钥由受控服务保存日志和部署报告只记录标识或版本不输出敏感值。检查配置时也要确认错误环境不会被带到生产例如测试索引、调试代理和宽松的权限开关。发布前可验证一组固定情形新文档是否可检索改过内容是否替换旧摘要删除与撤权是否不再命中回滚后是否回到一致的索引版本。这些检查比随机问几个问题更能发现数据链路漏洞。连接池和并发要分开设边界RAG 服务往往同时使用数据库、向量库、缓存、HTTP 客户端和模型接口。看到等待就把所有连接池调大通常只是把压力传到下游。每类连接都有自己的吞吐、超时和容量应该分别设置上限并让队列有明确的等待与拒绝行为。模型调用的在途请求尤其需要限制。请求越积越多时继续接受并长时间等待会拖垮工作线程也会让用户拿到很晚才返回的答案。设置合理的并发、deadline 和取消传播比追求“绝不拒绝”更可靠。高优先级交互与可延迟的后台索引任务也不宜抢同一份资源。内存预算也要考虑重建和批量导入。平时查询稳定不代表重建索引时仍有余量。部署演练可以在受控数据上模拟导入、切换和回退观察进程内存、连接等待和尾部延迟而不是等正式数据量到来后猜测。模型不可用时要有诚实的退路检索、重排和生成不是同一种失败。模型生成不可用时系统可以在权限允许的前提下返回检索到的原始资料和来源而不是编造一个完整回答向量检索不可用时是否退回关键词检索要看它能否满足当前任务权限服务异常时宁可拒绝访问也不能放宽过滤。每种降级路径都应经过测试且向用户说明能力变化。不能因为生成失败就把未经核验的旧缓存当作新答案也不能因为检索慢就跳过权限过滤。失败时的正确性要求往往比正常路径更严格。让部署结果可复盘一次部署至少留下服务版本、配置版本、数据或索引版本、依赖服务健康状态和验证结果。发生故障时这些信息可以帮助回放现场没有它们只能依赖“当时应该没改过”的记忆。RAG 上线不是把模型接口接通就结束。数据同步、权限边界、资源上限和降级策略共同决定它在压力和变化中是否仍然可靠。部署前沿着完整请求路径核对一遍往往比上线后追着偶发错误补洞要省得多。
