Kubernetes 上的 RAG 链路：何时值得拆成独立服务

检索增强链路先要确认文档入库、召回、上下文拼装和模型调用由谁维护、何时算完成。服务边界都没稳定时，先增加编排组件只会多出一层排障成本。

拆服务前先确认四个前提

把调用方、输入、输出、依赖和失败动作写在同一份说明里。配置、清单与接口定义应能相互对应；未验证的推断标为待确认。

适用条件和更简单的替代方案

召回有独立扩缩容需求、上下文拼装有明确协议、模型调用也能单独降级时，拆分才有可维护的边界。若三步仍共用一套数据结构并频繁联动修改，先留在同一服务中，用模块和接口隔开即可。异步队列也只在调用方能接受延迟并处理重复消息时引入。

上线前怎么验证边界

• 入库、召回、拼装和模型调用是否各有明确的输入输出与维护者。
• 召回超时或模型不可用时，调用方会收到什么结果，状态由谁清理。
• 拆分后的配置、服务发现和关联日志能否支持跨工作负载排查。

复杂度必须有明确归属

把可执行动作和验证依据留下来，比给检索增强链路添加更多概念更有用。下一次变更也能从这些边界继续推进。

服务拆分后怎么交接

文档要指出入库、召回、拼装和模型调用分别由哪个工作负载负责，并给出配置位置和失败时的降级结果。