设计一个可维护、可扩展的 RAG 系统，不能把所有逻辑揉在一起。清晰的分层架构既能帮助团队分工，也便于后续优化和替换组件。典型的生产级 RAG 系统通常划分为四层：接入层、应用层、检索层、数据层。每一层都有明确的职责，层与层之间通过标准接口通信，修改任意一层内部逻辑不会影响其他层。
1. 四层架构总览
┌─────────────────────────────────────────┐
│ 接入层 (Gateway) │
│ Web / API / 企业IM / 语音助手 │
└───────────────────┬─────────────────────┘
│
┌───────────────────▼─────────────────────┐
│ 应用层 (Application) │
│ 意图识别 · 对话管理 · 安全过滤 │
│ 提示构建 · 答案后处理 · 溯源组装 │
└───────────────────┬─────────────────────┘
│
┌───────────────────▼─────────────────────┐
│ 检索层 (Retrieval) │
│ 查询重写 · 向量检索 · 混合检索 │
│ 重排序 · 结果融合 │
└───────────────────┬─────────────────────┘
│
┌───────────────────▼─────────────────────┐
│ 数据层 (Data) │
│ 文档处理 · 切片 · 嵌入 · 向量数据库 │
│ 知识图谱 · 结构化数据库 · 文件存储 │
└─────────────────────────────────────────┘各层之间通过定义好的 API 通信（如 REST、gRPC），每层可以独立部署、扩容和升级。
2. 接入层：统一入口与渠道适配
职责：负责接收外部请求，将不同渠道的输入标准化后交给应用层，并将最终答案按渠道要求的格式返回。
真实场景：企业内部智能助手需要支持网页端、企业微信飞书机器人、移动 App 等多种入口。接入层会：
- 接收 HTTP 请求、WebSocket 消息流或来自企业 IM 的回调；
- 统一认证鉴权（如校验 API Key、用户身份）；
- 做基础的请求校验（长度限制、参数格式检查）；
- 将不同渠道的消息格式转为统一的内部结构，将答案渲染成渠道适配的格式（如网页返回 HTML，飞书返回 Markdown 卡片）。
接入层通常由 API 网关（如 Nginx、Kong）配合轻量级 Web 服务（如 FastAPI、Flask）组成。为了支持流式输出（LLM 逐字返回），需要处理 Server-Sent Events 或 WebSocket 长连接，网关需设置较长超时并禁用缓冲。
要点：接入层不应包含任何业务逻辑或检索逻辑，它只是请求的“搬运工”和“翻译官”。
3. 应用层：业务逻辑与生成协调
职责：这是系统的“大脑”，负责编排完整的问题到答案的流程，不直接操作数据库，也不直接处理向量检索细节。
应用层主要包含以下模块：
- 意图识别与路由：判断用户是想闲聊、查询知识库、执行某个操作还是投诉。对于简单问候，可以直接回复而不进入检索流程，节省开销。
- 对话管理：维护多轮对话的上下文。从历史记录中压缩或总结关键信息，与当前问题合并，构造出能让检索更准确的查询。
- 提示构建：将检索层返回的文档片段、对话历史、系统指令和用户问题，按照预设模板组装成最终提示，发给 LLM。
- 安全与合规：对检索到的内容和最终回答进行敏感词扫描、PII 去除或合规策略检查，确保输出的安全性。
- 后处理与溯源：解析模型返回的结果，提取出引用标记，将内部片段 ID 转换为用户可读的出处链接或文档名称。
真实部署形态：应用层通常是一个或多个微服务，用 Python（如 LangChain 编排）、Java 或 Go 实现。它通过调用检索层的查询接口获取 top‑k 文档，再调用模型推理接口（可以是自建的 vLLM、TGI 服务，也可以是 OpenAI API）完成生成。
4. 检索层：多路召回与精排
职责：接收应用层传来的查询（可能经过重写或扩展），在知识库中找到最相关的文档集合，输出排序后的结果。
一个成熟的检索层往往不是单一的向量搜索，而是多步流水线：
- 查询预处理：对原始查询进行同义词替换、拼写纠错、HyDE 式假设文档生成等，提升召回率。
- 多路召回：
- 向量检索：基于语义相似度，从向量数据库中检索出 top‑k 个候选。
- 关键词检索：使用 BM25（如 Elasticsearch）做精确匹配，对专有名词、编号、代码等效果更好。
- 结构化查询：如果问题涉及时间、部门等元数据，在检索时应用过滤条件（如“只查 2024 年内更新的政策”）。
- 融合与重排序：将多路结果合并去重后，使用重排序模型（如 Cohere Rerank 或 bge‑reranker）根据与问题的相关性重新打分，截取最前面的少量片段送入生成阶段。
技术选型：向量数据库常用 Milvus、Pinecone、Weaviate、Qdrant；关键词检索引擎常用 Elasticsearch；重排序模型可以本地部署轻量级交叉编码器。检索层需保证低延迟（通常要求 < 500ms），因此会重点优化索引结构和网络开销。
5. 数据层：知识资产的基座
职责：负责所有原始文档的摄入、处理、向量化与存储，是知识库的“原材料仓库”和“加工车间”。
数据层通常包含两个子部分：
- 离线处理流水线（Ingestion Pipeline）：
- 文档解析：从 PDF、Word、Markdown、网页、数据库导出等格式中提取纯文本，处理表格、图片（多模态场景需用到视觉模型）。
- 文档切分：按语义边界（如标题、段落）将长文档切成合适大小的 chunk，同时保留重叠以防截断关键信息。
- 嵌入生成：调用嵌入模型将每个 chunk 转为固定维度的向量，可批量处理以提升吞吐。
- 元数据提取：同时将 chunk 的出处、页码、时间等结构化信息存入数据库，供过滤和溯源使用。
- 存储层：
- 向量数据库：存储 chunk 向量与原始文本，支撑向量检索。
- 文档存储：保留原始解析后的全文，供用户点击“查看原文”时加载完整文档。
- 结构化数据库（可选）：存储知识图谱实体或用户授权表等。
数据更新：当文档新增或变更时，管道需重新触发处理，并用新版本替换旧 chunk。为保证一致性，通常采用全量索引替换或增量更新配合版本标记。
6. 层间协作示例
一个完整的问答请求穿过四层的典型路径：
- 接入层收到用户在企业微信里问“去年出差报销标准改了多少？”，解析后传给应用层。
- 应用层判断这是一个知识查询，结合对话历史（用户前面问了差旅政策）将查询重写为“2024年出差报销标准变更明细”，发给检索层。
- 检索层对重写后的查询分别进行向量检索和关键词检索（BM25 搜索“报销标准 2024”），两者结果合并，用重排序模型精选出 3 段相关的政策文档片段，返回给应用层。
- 应用层将片段组装进提示，发给 LLM 生成答案，并附上出处：“根据《费用报销管理制度 v3.2》第 4 条，2024 年起住宿标准由 300 元/天调整为 350 元/天。”答案传回接入层。
- 接入层渲染为飞书 Markdown 消息，附带“查看原文”链接，推送给用户。
7. 分层设计的工程价值
- 独立演进：如果想要换嵌入模型，只需要改数据层的嵌入服务，其他层不受影响。
- 按需扩容：接入层和应用层通常是轻量无状态服务，可水平扩展；检索层和数据层则需根据数据量和吞吐增加节点。
- 故障隔离：即使向量库出现短暂故障，应用层可以降级为只基于缓存的近期文档回答或给出友好提示，不至于整个系统不可用。
- 团队协作：业务团队可以直接在数据层上传和管理文档，算法团队在检索层实验不同检索策略，前后端开发专注于接入层和应用层，互不阻塞。
这种分层架构已经被大量生产系统验证，从几个人的创业团队到几千人的企业都在复用，它不是过度设计，而是让 RAG 系统从 Demo 走向可靠产物的必经之路。