第 10 讲 | RAG 全链路架构：从检索到生成的生产实践
本节我们将掌握：
- RAG 全链路：数据预处理 → 分块 → 索引 → 检索 → 重排 → 生成 → 后处理
- 分块策略的选择：固定分块、语义分块、父子分块的适用场景
- 检索优化：混合检索、查询改写、多路召回
- 2026 年进阶模式：Adaptive RAG、Agentic RAG、Self-RAG、GraphRAG
- 向量数据库选型和 RAG 评测指标
RAG 为什么是 LLM 应用的基石
给大模型一本"课外书"，每次回答前先翻书，再作答。这就是 RAG。
LLM 有两个硬伤：
- 知识截止日期：模型训练完就不再更新，不知道昨天发生的事
- 没有我们的私有数据：公司的产品文档、客户信息、内部流程，模型从来没见过
RAG 就是那本"课外书"——在回答之前，先从我们的知识库里找到相关资料，一起喂给模型。
这听起来简单。但生产环境的 RAG 和 demo 里的 RAG 差距巨大：
Demo：上传 10 篇 PDF → 分块 → 向量化 → 问一个问题 → 回答得不错
生产：10 万篇文档，10种格式，图文/公式混排，每天更新 500 篇，用户问的问题千奇百怪，回答必须准确且带引用来源2026 年的行业共识：RAG 不是"分块 + 向量化"两步走，而是一个七层管道。每一层都有优化空间，每一层的选择都直接影响最终质量。
RAG 全链路七层管道
原始数据 → ①预处理 → ②分块 → ③索引 → ④检索 → ⑤重排 → ⑥生成 → ⑦后处理我们自下而上逐层拆解。
① 数据预处理
拿到原始文档后的第一步不是分块，而是清洗：
| 操作 | 说明 |
|---|---|
| 格式归一化 | PDF/Word/HTML/Markdown 统一转为纯文本，图转语义（如有） |
| 去重 | 同一篇文章多个版本，只保留最新的 |
| 元数据提取 | 标题、作者、日期、标签、来源 URL |
| 噪声清洗 | 删除页眉页脚、广告、导航栏、乱码 |
| 结构化识别 | 识别标题层级、表格、代码块、公式、列表；识别有特征的内容，如客服/题目的QA对 |
坑：跳过这一步直接分块，我们会把页眉页脚当成正文、把同一篇文章的 v1 和 v2 都存进去、把表格拆得支离破碎。预处理的质量决定了 RAG 系统的上限。
实际难点：数据源杂，文档类型多，PDF纯图版本需要OCR，OCR需要去水印，HTML动态数据拿不到，表格单元格格式混杂（尤其是会计等领域）...甚至需要补作业，如数据孤岛、三方数据对接、多源数据冲突等等。
② 分块策略
这是 RAG 系统最关键的设计决策之一。2026 年主流有几种方式：
| 策略 | 做法 | 适合场景 | 局限 |
|---|---|---|---|
| 固定大小分块 | 按 token 数切分（如 500 token/块） | 快速验证、文档结构不重要的场景 | 切在句子中间、语义断裂 |
| 语义分块 | 按语义边界切分（段落、主题切换点） | 产品手册、行业报告等 | 实现复杂度高，没有同一标准，不直观 |
| 标题层级分块 | 按照标题层级切分 | markdown等层级清晰的文档，如AI生成文档、公众号/知乎文章等 | 语义不能兼顾，长文本不能兼顾 |
| 父子分块 | 大块（2000 token）存原文，小块（200 token）做检索匹配 | 长文档、手册、规范文档 | 存储翻倍，索引构建慢 |
其他还有段落、句子、行、以及图文、代码、公式等单独分块等。——Russell经验⭐：鉴于实际场景的复杂，实际上除了语义分块，只要代码可以做到的分块（如检测行、检测标题、检测表格等具体的内容块），可以发挥想象力。
最佳实践：
- 结构化文档（有标题层级）→ 按标题层级切分，一个章节一块 （也要有上下文，因为可能标题名相同）
- 非结构化文档（纯文本流）→ 语义分块 + 滑动窗口重叠（overlap 10%-20%）
- 需要精确引用的场景（合同、法规）→ 父子分块，小块检索、大块生成
父子分块示例：
父块（2000 token）：完整的"用户认证"章节
├── 子块1（200 token）："JWT Token 的生成方法"
├── 子块2（200 token）："Token 刷新流程"
└── 子块3（200 token）："Token 过期处理"
检索时匹配子块（精度高），生成时用父块（上下文全）③ 索引
分块之后，建立两套索引：
| 索引类型 | 作用 | 技术 |
|---|---|---|
| 关键词索引 | 精确匹配检索 | BM25 / 倒排索引 |
| 向量索引 | 语义相似度检索 | embedding 模型 + 向量数据库 |
为什么需要两套？ 向量检索擅长"意思相近"（"退款流程"能匹配"退钱步骤"），但对专有名词、精确术语容易漏。关键词检索正好互补。现在的标准做法是混合检索——两套索引都查，结果合并。
④ 检索
用户提问后，从索引中找到最相关的文档片段：
用户问："怎么重置密码？"
── 向量检索 ───────────────────────────────────
"password reset procedure" → 相似度 0.87
"如何修改登录密码" → 相似度 0.85
"忘记密码怎么办" → 相似度 0.82
── 关键词检索 ─────────────────────────────────
"密码 重置" → BM25 score 4.2
"重置 登录 凭证" → BM25 score 3.1
── 混合排序 ───────────────────────────────────
RRF（Reciprocal Rank Fusion）合并两套结果
→ 选择Top 3 进入下一轮检索层的优化手段：
- 查询改写：用户说"那个怎么登陆来着"→ 由LLM改写为"如何登录系统"。
- 查询内容补充：补充相关、相似关键词，比如“微信登录、密码找回、OAuth"等。
- 多查询并行：针对同一个问题生成 3-5 个意思相近的不同表达，并行检索后取并集。 用户问"怎么退货"→ 系统同时查： "退货流程是什么？" + "退款政策有哪些规定？" + "换货和退货有什么区别？" 三个问题分别检索，找到的内容更全面，召回率自然更高。
- 查询分解：用户问"A 和 B 的区别是什么"→ 拆成"A 是什么"+"B 是什么"分别检索，再合并
- 多路召回：向量 + 关键词 + 元数据过滤（如只搜"技术文档"分类），多路结果合并
⑤ 重排（Rerank）
从框里拿出30-100个桃子（初次检索），挑出3-8个最好的（重排序）递给大模型。
检索层召回 30-100 条（Hybrid：向量+关键词+时间衰减，速度快、精度一般）
↓
Rerank 模型精排（Cross-Encoder：query+doc 拼一起过 Transformer，50 个 doc = 50 次前向，所以慢；但相关性判断比 Bi-Encoder 准）
↓
取 Top 3-8 作为上下文。这是 RAG 系统投入产出比最高的优化之一。在纯向量检索基线上加 Rerank，回答准确率通常能提 10-20%（多跳/推理类任务提升较小），成本侧 Rerank 调用费约 +5%，但若 Rerank 后能把 final_top_k 从 10 压到 5，LLM 输入token 省的部分可能反赚，尤其对于比较贵的大模型。
⑥ 生成
把检索到的上下文和用户问题一起喂给 LLM：
Prompt:
"""
根据以下参考资料回答问题：
【参考资料】
1. [来自用户手册第3章] 重置密码步骤：登录 → 设置 → 安全 → 重置密码
2. [来自 FAQ] 忘记密码时点击登录页的"忘记密码"链接
3. [来自更新日志 v2.1] 新增了手机验证码重置密码功能
【问题】怎么重置密码？
要求：
- 仅基于参考资料回答
- 如果资料中没有答案，明确告知用户
- 引用来源标注编号
"""生成层的关键约束：
- 要求模型仅基于参考资料回答，减少幻觉
- 资料中没有答案时明确说"我不知道"，而不是编一个
- 引用来源编号，方便用户核对（也方便后续做幻觉检测）
⑦ 后处理
LLM 输出后不是直接返回给用户，再过一层校验：
- 引用溯源：答案里的每个 claim 能不能链回某个检索结果，链不回就是幻觉嫌疑
- 格式清洗：确保输出结构符合预期（如 JSON、Markdown）
- 安全合规：敏感词过滤、隐私信息脱敏
进阶模式：RAG 进化方向
朴素 RAG（分块→检索→生成）在简单场景够用，但碰到复杂问题就力不从心。现在年出现了多种进阶模式：
Adaptive RAG（自适应 RAG）
根据查询复杂度动态选择检索策略：
用户提问 → Query Classifier
│
├── 简单（"什么是 RAG？"）→ 单次向量检索，快速返回
├── 中等（"RAG 和微调有什么区别？"）→ 混合检索 + Rerank
└── 复杂（"我们的系统里 RAG 和 Agent 是怎么协作的？"）→ 多步检索 + Agentic 检索核心优势：简单问题不浪费，复杂问题不降质。
Agentic RAG
让 Agent 自主决定检索策略——不只是"检索一次就生成"，而是像人一样边想边查：
用户问："我们 2025 年和 2026 年的产品架构有什么变化？"
── Agent 思考 ──────────────────────────────────
Step 1: 先搜"2025 产品架构" → 找到 v1.0 文档
Step 2: 再搜"2026 产品架构" → 找到 v2.0 文档
Step 3: 发现 v2.0 文档提到新增了 RAG 引擎 → 再搜"RAG 引擎技术细节"
Step 4: 信息够了 → 综合对比，生成回答和朴素 RAG 的区别：朴素 RAG 检索一次就结束；Agentic RAG 会判断"我查到的够不够？不够再查"。代价是更多 LLM 调用、更高延迟。
Self-RAG（自反思 RAG）
模型自己决定什么时候需要检索，而不是每次都检索：
- 用户问"你好"→ 不需要检索，直接回答
- 用户问"我们的产品支持哪些部署方式？"→ 需要检索，查完再答
- 生成过程中发现自己不确定 → 主动触发额外检索
适合检索成本高、大部分问题不需要检索的场景。
GraphRAG
把知识以知识图谱的形式组织，检索时不仅匹配文本，还遍历实体关系：
用户问："张总负责的项目用了哪些技术栈？"
朴素 RAG：搜"张总 项目 技术栈" → 可能找不到完整答案
GraphRAG：
张总 --[负责]--> 项目A --[使用]--> React
项目A --[使用]--> Python
项目B --[使用]--> Go
→ 综合输出：React + Python + Go适合高度关联的企业数据（组织架构、产品依赖、供应链）。代价是图谱构建和维护成本高。如果不用图数据库作为底子，查询跳数有限。引入图又有很多别的问题。
向量数据库选型
2026 年的向量数据库格局：
| 方案 | 定位 | 选型信号 | 问题 |
|---|---|---|---|
| PGVector | 中小项目最常用（"已有 PG 就顺手加"是最大卖点） | 万级以下 + 已有 PG → 对 | 大规模性能一般 |
| Milvus | 专业向量库头部 | 百万级+ / 高性能/ 分布式 → 对 | 运维复杂度高 |
| Pinecone | SaaS 向量库头牌 | SaaS 托管、免运维、快速起步→ 对 | 成本高、数据出域 |
| Chroma | 轻量档头牌（LangChain 生态原生） | 开发调试、本地测试、小规模→ 对 | 不适合生产大规模 |
| Qdrant | Rust 写的专业向量库，payload filtering 强（filter 后再算距离，比 Milvus 的 filter 后置省） | 欧盟（GDPR 友好，Rust 内存安全）、filter-heavy 场景（"用户 123 的笔记里找相似的"这种带 meta 过滤的） | 生态比Milvus薄，社区弱 |
| 阿里云 Tair / 腾讯云 Vector等 | 云厂托管向量（国内） | 国内业务、高性能、数据不出域 | 跨云难 |
RAG 怎么评测
详见第 08 讲（Agent 评测与护栏）讲了 Agent 的评测。RAG 的评测有自己的一套指标：
| 指标 | 测什么 | 怎么算 |
|---|---|---|
| 上下文精确率（Context Precision） | 检索回来的内容是否都相关 | 相关段落数 / 检索回来的总段落数 |
| 上下文召回率（Context Recall） | 该检索的段落是否都找回来了 | 找到的相关段落数 / 所有相关段落数 |
| 答案忠实度（Faithfulness） | 答案是否忠实于检索到的上下文 | 答案中每个 claim 能否链回上下文 |
| 答案相关性（Answer Relevance） | 答案是否回答了用户的问题 | 人工评分或裁判模型评分 |
评测工具链：Ragas（开源 RAG 评测框架）、DeepEval、Phoenix（Arize）。
2026 年的关键发现：公开 RAG 基准（如 RGB、CRAG）的分数越来越高，但生产故障反而在增加。自定义评测集必须和生产场景一致——用我们自己的真实用户问题跑评测，比跑公共基准有用 10 倍。
RAG 和微调的关系
经常有人问：RAG 和微调选哪个？——Russell经验⭐：在大模型快速更新、能力快速增强的背景下，除非团队很懂、场景很必要、测评很完善，否则没事别乱微调。
| 维度 | RAG | 微调 |
|---|---|---|
| 更新频率 | 随时更新（改文档就行） | 需要重新训练 |
| 事实准确性 | 高（基于真实文档） | 可能遗忘或幻觉 |
| 风格/能力 | 不能改变模型风格 | 可以固化领域风格 |
| 成本 | 每次检索有开销 | 训练贵但推理不变 |
| 适合 | 知识密集型、频繁更新 | 风格固化、领域术语深 |
RAG 管知识（动态更新），微调管风格（术语、语气、格式）。 生产系统可以 RAG 为主 + 轻量微调配（如需）。
选型决策
架构师决策清单：
- 七层管道：预处理 → 分块 → 索引 → 检索 → 重排 → 生成 → 后处理，每一层都不能省
- 分块选择：结构化文档按标题切，非结构用语义分块+重叠，需要引用用父子分块
- 混合检索：向量 + 关键词双路召回 + Rerank 精排，这是 2026 年的基线配置
- 评测四指标：上下文精确率、召回率、答案忠实度、答案相关性
- RAG + 微调：RAG 管知识更新，微调管风格固化，如有需要组合使用。
- 拍板点：预处理和分块的质量 > embedding 模型的选择 > 检索策略的优化。顺序不能反。
面试回答要点
Q：讲一下你做过的 RAG 系统全链路优化，从分块到检索到生成，分别做了哪些优化？
答（抓管道 + 讲分层）：
全链路七层——预处理（格式归一、去重、结构化识别）→ 分块（语义分块 + 重叠）→ 索引（向量 + 关键词双路）→ 检索（混合检索 + 查询改写）→ 重排（Cross-Encoder Rerank）→ 生成（约束 prompt + 引用溯源）→ 后处理（幻觉检测 + 格式清洗）。
关键优化点——分块策略影响最大（父子分块兼顾精度和上下文完整）；加 Rerank 是投入产出比最高的优化（准确率 +10%-20%）；混合检索是基线配置，不能只有向量检索。
评测体系——用 Ragas 跑四指标（精确率、召回率、忠实度、相关性）。但最重要的是用真实用户问题做自定义评测集，公共基准刷再高也不能代表生产质量。
深度追问：
- "分块大小怎么选？" → 没有统一答案。看文档类型和模型上下文窗口。经验值：技术文档 500-800 token，文章 300-500 token，关键是有语义边界，不要硬切。
- "检索回来太多噪音怎么办？" → 先加 Rerank 精排；再加元数据过滤（如只搜特定分类）；最后调整 top_k。
- "RAG 和微调怎么选？" → 不冲突。RAG 解决知识更新，微调解决风格固化。组合用是最佳实践。
- "向量数据库怎么选？" → 万级以下用 PGVector（零额外组件），百万级以上用 Milvus，不想管运维用 Pinecone。
小结
- RAG 是七层管道：预处理 → 分块 → 索引 → 检索 → 重排 → 生成 → 后处理，每一层都有优化空间，不能只做"分块 + 向量化"两步
- 分块质量决定上限：语义分块 + 父子分块大概率优于固定大小分块；预处理不做好，后续全白费
- 混合检索 + Rerank 是 2026 年基线：向量 + 关键词双路召回，Cross-Encoder 精排，这是生产系统的标配
- RAG选型天梯：Vector-only + topK （基线）——》Hybrid + topK （几乎必做）——》+ Rerank（几乎必做）——》+ Adaptive 分流）+ 自适应 K + query 改写 （声量正高，逐步落地）——》+ Self-Correction / F1 eval loop / CRAG（Corrective RAG）（几乎不做，高端局、高 SLA 场景）
思考题
我们的团队搭建了一个"产品知识库问答"RAG 系统，用户上传 5000 篇产品文档。用户反馈"回答经常遗漏关键信息"。从 RAG 全链路的角度，我们会按什么顺序排查？每一步可能的问题和优化手段是什么？（提示：从预处理→分块→检索→重排→生成逐层定位）
我们的 RAG 系统目前只有向量检索（Milvus + text-embedding-3-large），top_k=5。上线后发现专有名词（如产品型号"X-3000"）经常检索不到。从架构层面我们会怎么优化？（提示：混合检索、查询改写、分块策略各是一种思路）
参考资料
- Neo4j: Advanced RAG Techniques for High-Performance LLM Applications
- Atlan: 12 Advanced RAG Techniques — Beyond Naive Retrieval
- Google Codelabs: Advanced RAG Methods
- Turing Post: 20 Advanced RAG Types to Know in 2026
- Towards AI: Advanced RAG — GraphRAG, Corrective RAG, Self-RAG
- arXiv: QA-GraphRAG — Query-Adaptive Plug-and-Play Module for Graph RAG