RAG 系统架构演进的七个阶段：从单机 PoC 到全球分布式服务的路径

RAG 系统架构演进的七个阶段从单机 PoC 到全球分布式服务的路径RAG 架构的演进不是一次性设计出来的而是在一次次踩坑中被迫升级的。你以为是设计良好的进化路径实际上是每次出问题修一下修着修着就变成了现在这样。我把自己经历的和研究过的 RAG 架构演进总结为七个阶段。每个阶段标注了触发升级的原因通常是某个生产事故以及升级的核心变化。一、深度引言与场景痛点二、底层机制与原理深度剖析特征一个 Python 脚本或 Jupyter Notebook。Chroma 或 FAISS 本地存储。所有组件在一个进程里。代码量200 行 Python。能支撑 1000 篇文档单用户测试。典型问题当文档增加到 5000 篇时FAISS 的索引重建需要 30 秒。每次加新文档都是重新索引全部内容。升级触发第一个内部用户试用后说挺有意思的能不能把全公司的文档都放进去。三、生产级代码实现核心变化检索服务独立部署Redis/Milvus。API 层和检索层分离。支持增量索引。新组件FastAPI Redis Stack PostgreSQL元数据存储。能支撑1 万 - 10 万篇文档 10 并发用户。典型问题用户投诉为什么我搜数据库连接池搜不到《数据库连接池配置指南》。根因向量检索对专有名词的召回率只有 50%。升级触发老板在全体会议上演示搜索搜了三遍都没搜到他想要的结果。四、边界分析与架构权衡核心变化加入 BM25 关键词通道。Query 改写层。RRF 融合。新组件ElasticsearchBM25 或 Redis 的全文搜索。jieba 分词器。召回率从 55% 提升到 82%。典型问题BM25 通道和向量通道的结果不一致。用户问怎么配置超时BM25 返回了 Redis 超时配置向量返回了 HTTP 超时配置——两个都对但用户要的是数据库连接的。升级触发用户反馈准确率上来了但延迟从 2 秒变成了 5 秒。五、总结核心变化建立评测体系RAGAS / 自研。Prompt 版本管理。A/B 实验平台。核心指标Recall5 85%、Faithfulness 85%、Answer Relevance 80%。典型问题评测集不够大只有 50 条人工标注A/B 实验的统计显著性不足。优化方向被噪音误导。升级触发用户量从内部 20 人扩展到全公司 200 人。查询多样性暴增评测集覆盖不足的问题暴露。六、第 5 阶段高可用架构第 11-14 周核心变化多副本部署。降级策略Redis 挂了走 ESES 挂了跳过关键词通道。健康检查 自动重启。P95 延迟告警。新组件KubernetesHPA 自动扩缩容、Prometheus Grafana、PagerDuty。典型问题某个用户上传了一个 50MB 的 PDF。Embedding 服务单次处理超时。设置了 30 秒超时后用户抱怨文件传不上去。升级触发某天下午 Redis 实例挂了 15 分钟。RAG 彻底不可用。CEO 问为什么不接备用方案。七、第 6 阶段平台化第 15-20 周核心变化多租户隔离。知识库管理后台。权限控制RBAC。插件化架构支持不同的 Embedding 模型、LLM、检索策略。技术选型变化从单一 RAG Pipeline 变成RAG 配置引擎——每个租户可以选择自己的 Embedding 模型、检索策略、Prompt 模板。典型问题不同租户的文档量差异巨大。A 租户 100 篇B 租户 10 万篇。共享的检索集群里B 租户的查询延迟影响了 A 租户。升级触发销售团队卖了第 3 个客户。客户要求数据隔离、独立配置、SLA 保障。八、第 7 阶段全球分布式第 21 周核心变化多 Region 部署中国、东南亚、欧洲。就近路由DNS GeoDNS / Anycast。跨 Region 数据同步。边缘推理Cloudflare Workers / Fly.io。新组件全球负载均衡、CDN 加速静态文档、边缘函数执行简单分类。典型问题中国用户和新加坡用户的延迟差异巨大。文档同步延迟导致两个 Region 的检索结果不一致。目前的方案每个 Region 部署完整的 RAG 服务栈文档写入主 Region通过 CDCChange Data Capture同步到从 RegionEmbedding 向量在每个 Region 独立计算因为文档相同、Embedding 模型相同结果一致LLM 推理路由到最近的推理节点九、七阶段的成本与能力对照from dataclasses import dataclass from enum import Enum class RAGStage(Enum): POC 1 SERVICE_SPLIT 2 HYBRID_SEARCH 3 EVAL_LOOP 4 HIGH_AVAILABILITY 5 PLATFORM 6 GLOBAL_DISTRIBUTED 7 dataclass class StageProfile: stage: RAGStage monthly_cost_range: str team_size_range: str p95_latency_range: str recall_range: str typical_timeline: str STAGE_PROFILES { RAGStage.POC: StageProfile( RAGStage.POC, $0-100, 1人 2周, 1-3秒, 40-60%, 2周 ), RAGStage.SERVICE_SPLIT: StageProfile( RAGStage.SERVICE_SPLIT, $100-500, 1-2人 4周, 1-3秒, 50-70%, 4周 ), RAGStage.HYBRID_SEARCH: StageProfile( RAGStage.HYBRID_SEARCH, $200-800, 2人 6周, 2-4秒, 75-85%, 6周 ), RAGStage.EVAL_LOOP: StageProfile( RAGStage.EVAL_LOOP, $300-1000, 2-3人 10周, 2-4秒, 80-90%, 10周 ), RAGStage.HIGH_AVAILABILITY: StageProfile( RAGStage.HIGH_AVAILABILITY, $500-2000, 3-4人 14周, 3-5秒, 85-90%, 14周 ), RAGStage.PLATFORM: StageProfile( RAGStage.PLATFORM, $1000-5000, 4-6人 20周, 3-5秒, 85-92%, 20周 ), RAGStage.GLOBAL_DISTRIBUTED: StageProfile( RAGStage.GLOBAL_DISTRIBUTED, $2000-10000, 6-10人 持续, 2-5秒, 88-95%, 持续 ), } def estimate_stage(doc_count: int, users: int, budget: int) - RAGStage: 根据文档量、用户数、预算估算当前阶段 if doc_count 1000 and users 10: return RAGStage.POC if doc_count 100_000 and users 50: return RAGStage.SERVICE_SPLIT if users 200: return RAGStage.HYBRID_SEARCH if users 1000 and budget 2000: return RAGStage.EVAL_LOOP if budget 5000: return RAGStage.HIGH_AVAILABILITY if users 10000: return RAGStage.PLATFORM return RAGStage.GLOBAL_DISTRIBUTED十、总结RAG 架构的七个阶段核心驱动力不是技术追求而是业务压力。每一次升级都是因为上一个阶段扛不住了。大多数团队不需要超过第 4 阶段评估 优化闭环。如果你的用户不到 200 人、文档不到 10 万篇第 4 阶段就是终点。再往上走是平台化和商业化的需求不是技术需求。选对你的阶段别在 1000 篇文档的规模上做全球分布式架构设计。资料说明本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论不应视为行业事实。可参考 0730 资料来源索引并在发布前将具体来源贴到对应断言之后。