——给从 0 开始学 AI 的人，一个完整的 RAG 流程图解

目录

• 引子：RAG 是一条流水线
• 01 文档解析：先把”原材料”读进来
• 02 文档分块：把大文章切成合适的”答题卡”
• 03 向量化：给每段文字贴上”语义坐标”
• 04 索引：建好”书架”，才能快速找书
• 05 意图识别与意图微调：先搞清楚用户”真正想要什么”
• 06 Query 改写：把问题”翻译”得更好检索
• 07 Query 路由：把问题”导航”到正确的数据源
• 08 语义检索：找到”意思相近”的内容
• 09 重排序：把搜出来的结果”重新打分”
• 10 生成：Prompt 应该包含哪些东西
• 11 后处理：答案出来了，还需要再加工吗
• 小结：流水线全景图

引子：RAG 是一条流水线

很多人第一次听到 RAG，会以为它是某个单一技术点。

其实不是。

RAG 是一条流水线。

就像一条汽车生产线：原材料进来，经过一个个工位的处理，最后出来一辆整车。

中间某个环节出了问题，整辆车就不对。

这条流水线大概长这样：

原始文档   ↓文档解析（把数据读进来）   ↓文档分块（切成合适大小）   ↓向量化（变成数字坐标）   ↓索引存储（建好书架）   ↓用户提问   ↓意图识别（真正想要什么）   ↓Query 改写（把问题说得更精准）   ↓Query 路由（去哪里找答案）   ↓语义检索（找到相关内容）   ↓重排序（重新打分排名）   ↓生成（组 Prompt，交给 AI 回答）   ↓后处理（格式、安全、过滤）   ↓最终答案

下面，我们一个工位一个工位地讲清楚。

01 文档解析：先把”原材料”读进来

什么是文档解析？

文档解析，就是把各种格式的文件，转化成 AI 能读懂的纯文本。

听起来简单，实际上是整条流水线里最容易被忽视、也最容易出问题的环节。

为什么？

因为现实世界里的文档，格式千奇百怪：

• PDF 里有表格、图片、页眉页脚
• Word 文档里有加粗、标题层级、嵌套列表
• 网页里有 HTML 标签
• 扫描件里全是图片，根本没有文字层
• PPT 里每一页都是独立的内容块

如果解析不好，后续所有环节都是在”垃圾数据”上工作。

常见的解析方式

一个常见的坑

很多人做 RAG 时，把一个 PDF 直接丢进去，发现效果很差。

一查才知道：那个 PDF 是扫描件，根本没有文字层，直接提取出来的是乱码。

解析这步的目标是：

提取出干净的、结构清晰的文本——不多（不要把页眉页脚、广告噪音带进来），不少（关键内容不能漏）。

02 文档分块：把大文章切成合适的”答题卡”

为什么文档要分块？

一个好问题。

原因一：AI 有上下文长度限制

哪怕是最新的大模型，一次能处理的文本长度也是有限的。一本完整的员工手册，不可能全部塞进去。

原因二：大段内容检索效率低，噪音大

你问”年假是几天”，系统如果返回整本员工手册，AI 要自己去找，不仅慢，还容易被无关内容干扰。

原因三：向量相似度在短文本上更准

一段话的”语义向量”，比整篇文章的向量精准得多。检索时更容易命中真正相关的内容。

常见的分块策略

① 按固定长度切分（Fixed-size Chunking）

最简单粗暴：每 N 个字符切一刀，设置 20% 的重叠区避免切断句子。

• 优点：简单、快速
• 缺点：可能把一个完整的意思切断
• 适用场景：格式规整的文档，如法规条文

② 按句子/段落切分（Sentence/Paragraph Splitting）

按自然语言的边界切分，一个句子或一段话为一块。

• 优点：语义完整性好
• 缺点：每块大小不均匀，有些段落很长有些很短
• 适用场景：新闻文章、博客内容

③ 按语义切分（Semantic Chunking）

用 Embedding 计算相邻句子的语义距离，在”语义转折点”切分。

• 优点：保证每块内部语义高度一致
• 缺点：计算成本高，速度慢
• 适用场景：技术文档、学术论文

④ 按文档结构切分（Structure-aware Chunking）

根据标题层级（H1/H2/H3）、章节、表格等结构信息切分。

• 优点：保留文档逻辑结构，一块 = 一个知识单元
• 缺点：需要文档有明确的结构标记
• 适用场景：有标题层级的手册、报告

⑤ 父子块（Parent-Child Chunking）

每个大块（父块）下面切成若干小块（子块）。检索时用小块，返回时附上父块的上下文。

• 优点：检索精准 + 上下文完整
• 缺点：存储成本翻倍
• 适用场景：需要精准检索 + 完整答案的场景

分块效果更好的几个技巧

1. 切分有重叠（Overlap）：相邻块之间共享 10-20% 的内容，防止关键信息被切断
2. 块大小要适中：太小（几十字）语义不完整，太大（几千字）噪音多，通常 200-800 字效果最佳
3. 保留元数据：每块记录来自哪个文件、第几页、属于哪个章节——检索后可以溯源
4. 表格单独处理：表格不要按行切，要整张表格作为一块

03 向量化：给每段文字贴上”语义坐标”

什么是向量化？

向量化，就是把一段文字变成一串数字。

为什么要这么做？

因为计算机不能直接比较两段话”意思像不像”，但可以计算两组数字之间的距离。

一个类比：

想象你有一张二维地图，每个城市都有一个坐标（x, y）。

• 北京：(116, 40)
• 天津：(117, 39)
• 上海：(121, 31)

你想知道”北京附近的城市”，只需要找坐标距离北京最近的点。

向量化做的事情类似，但不是二维，而是几百到几千维。

“年假政策是什么？”和”员工休假天数规定”这两句话，虽然字面不同，但语义相似，它们的向量坐标就会很”近”。

向量化的核心：Embedding 模型

产生这个”语义坐标”的工具，叫 Embedding 模型。

常见的 Embedding 模型：

中文内容，推荐优先考虑 bge-m3。

一句话总结

向量化 = 把语言意思转化成数学坐标，让计算机能用”距离”来衡量语义相似度。

04 索引：建好”书架”，才能快速找书

向量化之后，这些数字坐标要存在哪里？怎么存才能快速检索？

这就是索引的问题。

索引类型大致分为两大类：向量索引（存向量）和结构化索引（存原始数据）。

向量索引（用于语义检索）

这类索引存储的是向量（数字坐标），用于”找意思相近的内容”。

常见的向量数据库（存向量的”书架”）：

• Chroma：轻量级，本地跑，开发调试首选
• Pinecone：云托管，开箱即用，收费
• Weaviate：开源，支持混合检索（向量+关键词）
• Qdrant：开源，Rust 编写，性能极高
• Milvus：开源，大规模场景主流选择
• pgvector：PostgreSQL 插件，在已有 PG 数据库上加向量能力

结构化索引（用于精确检索）

这类索引存的是结构化数据（表格、数值、日期、状态等），用于”找精确匹配的内容”。

常见的结构化数据库：

• Elasticsearch：全文检索王者，BM25 关键词检索
• PostgreSQL / MySQL：关系型数据库，B-Tree 索引
• Redis：内存数据库，适合实时高频查询

举例：哪类问题用哪类索引？

场景：公司内部知识库系统

• 问”年假政策怎么规定的？” → 向量索引，语义搜索员工手册
• 问”2024年1月销售额是多少？” → 结构化索引，查数据库里的销售表
• 问”有没有关于’请假流程’的文档？” → 全文索引，关键词精确匹配

好的 RAG 系统通常两类索引都有，根据问题类型选择走哪条路。

05 意图识别与意图微调：先搞清楚用户”真正想要什么”

什么是意图识别？

用户的问题，表面看是一句话，背后其实有它”真正的目的”。

意图识别，就是分析用户问题背后的真实意图，并将其分类。

常见的意图类型：

识别出意图后，系统就能做出更准确的下一步决策：是去向量库检索、还是去数据库查、还是直接让 AI 回答、还是拒绝回答。

什么是意图微调？

普通的意图识别，是用通用模型分类。

意图微调，是在特定业务场景上，用自己的数据专门训练一个意图识别模型，让它更了解你的用户。

举个例子：

一家银行的客服系统，用户可能问：

• “我的卡被冻结了怎么办？”——意图：账户问题
• “最近有什么理财产品？”——意图：产品咨询
• “我想投诉上次的服务”——意图：投诉建议
• “转账限额是多少？”——意图：业务规则查询

通用模型可能把这些全归为”金融问题”，识别不够细。

用微调过的模型，能识别出具体的子意图，系统就能把”账户问题”路由到专门的账户知识库，把”产品咨询”路由到产品数据库——答案更准，响应更快。

06 Query 改写：把问题”翻译”得更好检索

问题在哪？

用户输入的问题，经常和知识库里的表达”对不上”。

比如：

• 用户问：”我想多休几天” → 知识库里写的是”年假申请流程”
• 用户问：”这个功能咋用” → 文档标题是”用户操作手册”
• 用户问：”为啥一直报错” → 文档里说的是”错误代码排查指南”

字面不同，意思相似，但向量检索可能就找不到。

Query 改写，就是在用户问题进入检索之前，先帮它”翻译”成更容易找到答案的形式。

常见的 Query 改写策略

① HyDE（假设性文档嵌入）

思路：先让 AI 假装已经知道答案，写一段”假答案”，再用这段假答案去检索。

为什么有效？因为”假答案”的语言风格更接近知识库文档，向量相似度更高。

用户问："年假是几天？"  ↓ AI 生成假答案"根据公司规定，员工年假天数按工龄计算，1-5年工龄为5天，5年以上为10天..."  ↓ 用假答案去检索检索结果：精准命中员工手册第3章

② 问题分解（Query Decomposition）

把一个复杂问题，拆成多个简单子问题，分别检索，再合并答案。

原始问题："A 产品和 B 产品哪个更划算，分别有什么优缺点？"  ↓ 拆解子问题1："A 产品的价格和特点是什么？"子问题2："B 产品的价格和特点是什么？"  ↓ 分别检索，汇总对比

③ 同义词/关键词扩展

自动扩展查询词，覆盖同义表达。

"请假" → 扩展为 ["请假", "休假", "年假", "病假", "事假", "缺勤"]

④ 上下文融合（Context-aware Rewriting）

多轮对话中，用对话历史补全当前问题。

用户第一句："公司的年假政策是什么？"用户第二句："那病假呢？"（省略了"公司的"）  ↓ 融合上下文改写为："公司的病假政策是什么？"

07 Query 路由：把问题”导航”到正确的数据源

什么是 Query 路由？

一个复杂的 RAG 系统，可能同时拥有多个数据源：

• 员工手册（向量库）
• 产品数据库（SQL 数据库）
• 实时新闻（网络搜索）
• 本地 Excel 报表（文件检索）

Query 路由，就是根据用户问题的类型，自动判断”应该去哪里找答案”。

一个具体例子

假设你搭建了一个公司内部助手，有以下数据源：

问题："年假怎么申请？"  → 路由到：员工手册知识库（向量检索）问题："上季度的销售额是多少？"  → 路由到：销售数据库（SQL 查询）问题："今天有没有关于我们行业的新闻？"  → 路由到：联网搜索问题："帮我看看这份 Excel 报表里第3列的异常"  → 路由到：文件分析工具

路由的实现方式

08 语义检索：找到”意思相近”的内容

语义检索 vs 关键词检索

关键词检索（BM25）：找的是”包含相同词”的文档。

• 问”年假多少天”，只找含有”年假”和”多少”和”天”这些词的文档
• 如果文档写的是”员工带薪休假天数”，就找不到

语义检索：找的是”意思相近”的文档。

• 问”年假多少天”，能找到”带薪休假天数规定”——因为它们向量距离近

语义检索的数据来源，本质上是向量数据库里存储的 Embedding 向量。

语义检索和结构化数据冲突时怎么办？

这是一个很现实的问题。

典型冲突场景：

用户问：”2024年3月销售额超过100万的订单有哪些？”

这个问题有精确的数值条件（>100万、2024年3月），语义检索处理不了——向量搜索不懂”大于100万”。

正确的做法是混合检索（Hybrid Retrieval）：

1. 语义检索处理模糊的语义部分（”找销售相关的内容”）
2. 结构化检索处理精确的数值/日期条件（”金额>100万 AND 时间=2024年3月”）
3. 合并两部分结果，交给 AI 综合回答

实际架构示意：

用户问题  ↓ Query 路由  ├→ 向量检索（找相关文档）  └→ SQL 查询（找精确数据）       ↓    结果合并       ↓    Reranker 重排序       ↓    AI 生成答案

原则：语义检索 + 结构化检索不是竞争关系，而是互补关系。选哪条路，由问题类型决定。

09 重排序：把搜出来的结果”重新打分”

为什么要重排序？

检索阶段返回了一批文档（比如 Top 10），但它们的顺序不一定是最优的。

向量检索只看”语义距离”，但”语义距离近”不完全等于”最能回答这个问题”。

Reranker（重排序模型）做的事情，是对每一个”问题-文档”对，重新打一个相关性分数，按分数重新排列。

类比

• 向量检索像图书馆的搜索引擎，快速找出一批可能相关的书
• Reranker 像一位专家评审，把这批书一本本翻开，看哪本最符合你的问题

一个具体例子

问题： “员工如何申请年假？”

Reranker 识别出”文档 B”才是最直接回答”怎么申请”的，把它提到第一位。

常用 Reranker 模型

• bge-reranker-large（BAAI）：中英文双语，开源，效果好
• Cohere Rerank：商业 API，效果强，收费
• cross-encoder/ms-marco-MiniLM-L-6-v2：轻量级，速度快

实践建议： Top 20 → Reranker → 取 Top 5 送进生成环节，是常见配置。

10 生成：Prompt 应该包含哪些东西

检索到了相关内容，送进 AI 生成答案。这里最关键的是：Prompt 怎么写？

一个完整的 RAG 生成 Prompt，通常包含以下几个部分：

① 系统角色定义

告诉 AI 它是谁，它的职责边界是什么。

你是 XX 公司的内部知识库助手，只根据提供的参考资料回答问题。如果参考资料中没有相关信息，明确告诉用户"暂无相关信息"，不要自行猜测。

重要：这里要明确说”只根据参考资料回答”，防止 AI 自由发挥产生幻觉。

② 参考资料（检索到的内容）

把检索出来的文档片段，有结构地组织进 Prompt。

以下是与用户问题相关的参考资料：【资料1】来源：员工手册第3章，第12页"员工年假申请需提前3个工作日，通过OA系统提交，需部门经理审批。"【资料2】来源：HR 常见问题 FAQ"年假未使用完的部分，可在次年3月底前补休，不支持现金兑换。"

注意：

• 标注来源，方便溯源
• 相关性高的放前面
• 控制总长度，不要超出上下文窗口

③ 用户问题（原始 or 改写后）

用户问题：年假申请的具体流程是什么？

④ 回答格式要求

告诉 AI 你希望答案的样子。

请按以下格式回答：1. 直接回答问题（1-3句话）2. 详细说明具体步骤（如有）3. 注明信息来源

⑤ 不确定性处理指令

如果上述参考资料不足以回答问题，请直接说明"根据现有资料无法确认"，不要自行推断，不要捏造信息。

一个完整 Prompt 示例

## 角色你是 XX 公司的内部助手，严格根据以下参考资料回答员工问题。## 参考资料【来源1 - 员工手册 P12】年假申请需提前3个工作日，通过OA系统提交，经部门经理审批后生效。【来源2 - HR FAQ】年假未使用可在次年3月底前补休，不支持现金兑换。## 用户问题我想申请年假，具体怎么操作？## 回答要求- 直接回答操作步骤- 如有注意事项请一并说明- 信息来自参考资料，请标注来源- 参考资料不足以回答时，明确说明

11 后处理：答案出来了，还需要再加工吗

答案生成之后，就可以直接发给用户了吗？

不一定。 很多场景下，还需要一道”后处理”环节。

什么情况需要后处理？

后处理一般需要做什么？

① 幻觉检测（Hallucination Detection）

自动对比 AI 的回答和检索来源，判断有没有”凭空编造”的内容。

常见做法：用另一个 LLM 来判断——”这句话在参考资料里有没有依据？”

② 内容安全过滤

检测回答中的敏感词、违规内容、竞品名称等，必要时屏蔽或替换。

③ 格式化输出

把自然语言答案转为结构化格式（JSON、Markdown、HTML 等），方便下游系统处理。

④ 引用标注与溯源

在答案里自动插入引用标记，告诉用户”这条信息来自哪个文档的第几页”。

⑤ 答案质量评分

自动给每次回答打一个置信度分数——如果分数低，触发降级策略（如转人工、返回”无法回答”）。

⑥ 语言翻译

如果知识库是英文但用户用中文提问，最后要把答案翻译回中文。

小结：流水线全景图

走完这 11 个环节，RAG 的全貌就清楚了。

原始文档├── 文档解析（转文本：PDF/Word/HTML/扫描件）├── 文档分块（切块：固定/语义/结构/父子）├── 向量化（Embedding：变成坐标）└── 索引存储（向量数据库 + 结构化数据库）用户提问├── 意图识别（理解"真正想要什么"）├── Query 改写（HyDE/分解/扩展/上下文融合）├── Query 路由（去哪个数据源找）├── 语义检索（向量相似度搜索）│   └── 混合检索（+ 关键词/SQL）├── 重排序（Reranker 精准打分）├── 生成（Prompt = 角色 + 资料 + 问题 + 格式要求）└── 后处理（过滤/格式化/溯源/幻觉检测）最终答案

每个环节都有它存在的价值。一个 RAG 系统效果差，通常只是某一个环节没有做好。

从这条流水线去诊断，你才能找到真正的问题所在。

本篇是 RAG 系列第二篇，配合以下文章阅读效果更佳：

• （上篇）：RAG 是什么？为什么 AI 需要它？
• （下篇）：如何评估一个 RAG 系统好不好？

如果觉得有帮助，欢迎转发给想了解 AI 的朋友。