RAG 系统架构设计模式

原创灵阙教研团队

S 精选提升 | 约 6 分钟阅读更新于 2026-02-27

AI 导读

RAG 系统架构设计模式从 Naive RAG 到 Modular RAG 的演进路径与生产级实践 Maurice | 灵阙学院一、RAG 三代演进 RAG (Retrieval-Augmented Generation) 并非一成不变的技术方案，而是一个持续演进的架构范式。理解其演进脉络，才能在实际项目中做出正确的架构选择。...

RAG 系统架构设计模式

从 Naive RAG 到 Modular RAG 的演进路径与生产级实践

Maurice | 灵阙学院

一、RAG 三代演进

RAG (Retrieval-Augmented Generation) 并非一成不变的技术方案，而是一个持续演进的架构范式。理解其演进脉络，才能在实际项目中做出正确的架构选择。

┌─────────────────────────────────────────────────────────────────┐
│                      RAG 架构演进路线                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Naive RAG (2023)          Advanced RAG (2024)                  │
│  ┌──────────────┐          ┌──────────────────┐                 │
│  │ 文档 → 切片   │          │ 文档 → 多策略切片  │                │
│  │ → 向量化      │    ──→   │ → 混合索引        │                │
│  │ → 检索 Top-K  │          │ → 查询改写+检索   │                │
│  │ → 拼接生成    │          │ → 重排+压缩+生成  │                │
│  └──────────────┘          └──────────────────┘                 │
│                                     │                           │
│                                     ▼                           │
│                            Modular RAG (2025)                   │
│                            ┌──────────────────┐                 │
│                            │ 可插拔模块化管线   │                │
│                            │ 路由 → 判断 → 检索 │                │
│                            │ → 评估 → 生成 → 验证│               │
│                            │ (带反馈回路)       │                │
│                            └──────────────────┘                 │
└─────────────────────────────────────────────────────────────────┘

代际	核心特征	典型问题	适用场景
Naive RAG	固定切片 + 单次检索 + 直接拼接	召回噪声大、上下文碎片化	原型验证、简单 QA
Advanced RAG	预检索优化 + 后检索优化	管线复杂度高、调试困难	企业知识库、客服系统
Modular RAG	可编排模块 + 自适应路由 + 反馈回路	工程复杂度最高	多领域混合、高精度要求

二、四种架构模式

2.1 简单架构 (Simple RAG)

最基础的"检索-拼接-生成"模式，适合快速验证。

用户查询 → Embedding → 向量检索(Top-K) → Prompt拼接 → LLM生成 → 返回

核心代码示例:

from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import FAISS

# 索引构建
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = FAISS.from_documents(documents, embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

# 检索 + 生成
prompt = ChatPromptTemplate.from_template(
    "Based on the following context, answer the question.\n"
    "Context: {context}\n"
    "Question: {question}"
)
chain = prompt | ChatOpenAI(model="gpt-4o") | StrOutputParser()

2.2 Agentic RAG

引入 Agent 决策层，根据查询意图动态选择检索策略。

                    ┌──── 向量检索 ────┐
用户查询 → Agent ───┼──── 关键词检索 ──┼──→ 结果融合 → 生成
                    ├──── SQL 查询 ────┤
                    └──── Web 搜索 ────┘

Agent 在此扮演"路由器"角色，判断查询应走向哪条检索通道，甚至可以组合多条通道的结果。

2.3 Graph-Enhanced RAG

利用知识图谱增强检索的结构化推理能力，特别适合实体关系密集的领域。

文档 → 实体抽取 → 知识图谱构建
                      │
用户查询 → 实体识别 → 图遍历(多跳) ─┐
         → 向量检索 ─────────────────┼→ 融合排序 → 生成

适用场景：法规关联查询、医疗诊断辅助、供应链溯源。

2.4 Multi-Modal RAG

处理文本、图表、PDF 扫描件等混合内容。

PDF/图片 → 视觉模型提取 → 文本+表格+图表描述
                                │
音频 → ASR转写 ─────────────────┤
                                ▼
                         统一向量索引 → 多模态检索 → 生成

关键挑战在于不同模态的对齐：图表需要结构化描述，表格需要保留行列关系，代码需要保留语法结构。

三、索引管线设计

索引质量直接决定 RAG 系统的上限。

3.1 文档处理管线

原始文档 → 格式解析 → 清洗/去噪 → 切片策略 → Embedding → 向量存储
              │           │            │
              ▼           ▼            ▼
         PDF/Docx     去页眉页脚    递归切片/语义切片
         Markdown     去重复段落    父子切片/滑动窗口
         HTML/CSV     标准化格式    表格保持完整性

3.2 切片策略对比

策略	原理	优势	劣势
固定长度切片	按字符/Token 数切分	简单、可预测	语义被截断
递归字符切片	按段落/句子/字符逐级尝试	保留段落结构	长段落可能过大
语义切片	按 Embedding 相似度断句	语义完整性最好	计算成本高
父子切片	小块检索、大块送入上下文	精确检索+完整上下文	索引体积翻倍

生产建议：父子切片（子块 256 tokens 检索，父块 1024 tokens 送入上下文）在大多数场景下是性价比最高的选择。

四、查询转换策略

原始查询往往不够精确，查询转换是 Advanced RAG 的核心优化点。

4.1 HyDE (Hypothetical Document Embeddings)

用户查询 → LLM 生成假设性回答 → 对假设回答做 Embedding → 检索

原理：假设回答与真实文档在向量空间中更接近（比问题本身更接近答案）。

4.2 Step-Back Prompting

用户查询: "Python 3.12 中 asyncio.TaskGroup 的异常处理机制是什么？"
       ↓ Step-Back
抽象查询: "Python asyncio 的异常传播机制是什么？"
       ↓ 同时检索两个查询
融合结果 → 生成

4.3 Multi-Query

用户查询 → LLM 生成 3-5 个语义等价但措辞不同的查询
       → 分别检索
       → 去重合并 → 排序 → 生成

五、检索策略

5.1 混合检索 (Hybrid Search)

# 稀疏检索 (BM25) + 稠密检索 (向量) 加权融合
from langchain.retrievers import EnsembleRetriever

sparse_retriever = BM25Retriever.from_documents(docs, k=10)
dense_retriever = vectorstore.as_retriever(search_kwargs={"k": 10})

hybrid = EnsembleRetriever(
    retrievers=[sparse_retriever, dense_retriever],
    weights=[0.3, 0.7]  # 根据领域调整权重
)

5.2 多阶段检索

第一阶段: 粗召回 (Top-100, 低精度高召回)
    ↓
第二阶段: 重排序 (Cross-Encoder / Cohere Rerank, Top-10)
    ↓
第三阶段: 上下文压缩 (去除冗余信息, 保留关键段落)
    ↓
送入 LLM 生成

重排序是投入产出比最高的优化手段。一个简单的 Cross-Encoder 可以将检索准确率提升 15-30%。

六、生成优化

6.1 Prompt 压缩

当检索到过多上下文时，需要压缩以适配 LLM 的上下文窗口和注意力分配：

from langchain.retrievers import ContextualCompressionRetriever
from langchain_cohere import CohereRerank

compressor = CohereRerank(model="rerank-v3.5", top_n=5)
compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=retriever
)

6.2 引用溯源

生产级 RAG 必须支持引用溯源，让用户可以验证生成内容的依据：

生成回答时要求 LLM 标注 [1][2] 引用编号
每个引用对应具体的文档片段 + 来源文件 + 页码/章节

七、生产部署清单

维度	检查项	标准
索引	增量更新机制	支持新增/修改/删除文档的增量索引
索引	切片质量抽检	人工抽样 50+ 切片确认语义完整性
检索	召回率基线	在标注数据集上 Recall@10 >= 0.85
检索	延迟 P99	检索延迟 < 500ms
生成	幻觉率	人工评估幻觉率 < 5%
生成	引用准确率	引用可追溯且内容匹配 > 90%
运维	监控告警	检索空结果率、生成延迟、Token 消耗
运维	回滚方案	索引版本化，支持一键回滚
安全	数据隔离	多租户场景下的检索结果隔离
评估	自动评估	RAGAS / DeepEval 集成到 CI

八、选型决策树

你的场景是什么？
│
├─ 简单 FAQ / 文档问答
│  └─ Simple RAG + 混合检索 + 重排序 (够用)
│
├─ 企业知识库 (多部门/多文档类型)
│  └─ Advanced RAG + 父子切片 + Multi-Query + 权限隔离
│
├─ 实体关系密集 (法规/医疗/金融)
│  └─ Graph-Enhanced RAG + 知识图谱 + 多跳推理
│
├─ 含图表/扫描件/音视频
│  └─ Multi-Modal RAG + 视觉模型 + 统一索引
│
└─ 复杂任务 (需要规划/工具调用/多步骤)
   └─ Agentic RAG + 工具路由 + 反馈回路

Maurice | maurice_wen@proton.me