RAG 服务拆分检索、重排和生成不要揉成一团很多 RAG 项目最初是一个接口传问题进来查向量库拼 Prompt调用模型返回答案。Demo 阶段没问题上线后就会遇到调试困难、缓存困难、扩容困难。检索慢了还是生成慢了召回差还是 Prompt 差没有拆分问题很难定位。RAG 不一定要拆成很多微服务但逻辑边界要清楚。检索、重排、上下文构造、生成和引用校验最好有独立模块和指标。一、RAG 链路先分阶段一个生产 RAG 请求至少包含查询改写、向量检索、关键词检索、重排、上下文构造、模型生成、证据校验。flowchart LR A[用户问题] -- B[查询改写] B -- C[向量/关键词检索] C -- D[重排] D -- E[上下文构造] E -- F[模型生成] F -- G[引用校验]每个阶段都要有耗时和命中指标。否则只知道 RAG 慢不知道慢在哪里。二、阶段输出要可检查不要只保存最终答案。至少在调试环境记录检索到的文档、重排分数、进入 Prompt 的片段和最终引用。type RagTrace struct { Query string RewrittenQuery string RetrievedIDs []string RerankScores map[string]float64 ContextIDs []string Answer string Citations []string }有了 trace才能判断是召回没找对还是模型没用证据。RAG 质量问题不能只靠改 Prompt 解决。三、缓存要按阶段设计查询改写、检索、重排和生成的缓存粒度不同。检索缓存适合高频相同问题生成缓存要考虑权限和上下文版本不能随便复用。rag_cache: retrieval: key: tenant normalized_query index_version ttl: 10m generation: key: tenant query context_hash prompt_version ttl: 1h缓存键里一定要有索引版本和权限信息。知识库更新后还用旧缓存会让用户看到过期答案。四、扩容也按瓶颈来如果检索 CPU 高就扩检索服务如果重排模型慢就单独扩重排如果生成排队就扩模型服务。所有阶段揉在一个服务里扩容只能整体加机器成本会变高。拆分不是为了架构好看而是为了定位和扩容有抓手。RAG 上线后最常见的问题就是质量和成本边界不清这两个都很难管。我还会给每个阶段设置最小验收指标。检索看召回命中率和空结果率重排看 top 文档是否被提升上下文构造看 token 是否超预算生成看引用覆盖率和无证据断言比例。指标不一定一开始很精确但必须能让团队知道哪一段在退化。stage | metric | alert retrieval | empty_result_rate | 5% rerank | top1_changed_rate | sudden_drop context_build | context_tokens_p95 | budget generation | citation_missing_rate | 3%这些指标比“用户说不好用”更早暴露问题。RAG 系统一旦进入生产质量治理就不能只靠人工感觉。五、总结RAG 服务不要把检索、重排和生成揉成一团。阶段边界清楚、trace 可检查、缓存按阶段设计、扩容按瓶颈进行系统才可维护。生产 RAG 的核心不是“能回答”而是回答不好时知道该修哪里。