RAG 检索→召回→增强→生成完整流程

目录

RAG 核心流程

2.1 Ingest：把数据导进来

2.2 Chunk：把长文档切成小块

2.3 Embed：把文字变成向量

2.4 Index：存进向量数据库

2.5 Retrieve：检索相关内容

2.6 Answer：大模型生成回答

2.7 流程小结

优缺点

三、大模型五大致命局限性

四、传统关键词检索的痛点

五、RAG 核心概念

六、RAG 六大核心流程（分两大阶段）

离线准备阶段（一次构建、增量更新）

在线运行阶段（每次用户提问必走）

七、RAG 优缺点

优点

缺点

八、RAG 四大经典落地场景

九、Demo 到企业级 RAG 的核心难点

---

RAG 核心流程

RAG 全链路图：ingest → chunk → embed → index → retrieve → answer。

这六步分成两个阶段：前四步是准备阶段，离线做一次；后两步是运行阶段，每次用户提问都走一遍。

下面一个个拆开讲。

2.1 Ingest：把数据导进来

第一步很简单，把你的数据源接入系统。

数据可能是 PDF 产品手册、Word 内部文档、网页内容、数据库里的结构化数据，格式五花八门。不同格式用不同的解析方式：PDF 要提取文字，Word 要读取内容，网页要爬取并清洗。

这步的目标就一个：拿到干净的纯文本。

2.2 Chunk：把长文档切成小块

文档一般都很长，直接用有两个问题：

1. 1.
2. 大模型的上下文窗口有限，塞不下整篇文档；
3. 2.
4. 检索时希望找到最相关的那一小段，而不是整篇文章。

所以要切块。比如一份 50 页的产品手册，可以按章节切，或者固定每 500 字切一块。

切块有讲究：

• 太大：检索不够精准，还容易超出上下文限制
• 太小：语义不完整，上下文丢失

常见做法是 500-1000 字一块，相邻块之间有一定重叠（比如重叠 100 字），防止重要信息正好被切断。

2.3 Embed：把文字变成向量

这步是整个 RAG 的核心。

前面说过，传统关键词搜索不懂语义。怎么让机器理解"这玩意儿怎么用"和"产品使用方法"是一回事？

答案是把文字转成向量。

向量就是一串数字，比如[0.23, -0.45, 0.67, ...]，可能有几百上千维。这串数字编码了这段文字的语义信息，意思相近的文字，向量在空间中的距离也近。

"打印机怎么用" → [0.23, -0.45, 0.67, ...] "产品使用方法" → [0.25, -0.42, 0.65, ...] ← 很接近 "今天天气不错" → [-0.89, 0.12, 0.03, ...] ← 差很远

这个转换由专门的 Embedding 模型完成，比如 Qwen3 的 Qwen3-Embedding-8B，或者开源的 bge、m3e。

2.4 Index：存进向量数据库

向量算出来了，得找个地方存起来。

普通数据库存结构化数据，做精确匹配。向量数据库专门存向量，做相似度搜索——给一个向量，找出距离最近的 N 个。

常见的向量数据库有Milvus、Pinecone、Weaviate，轻量级的有Faiss、Chroma。

从我目前的调研来看，Milvus 在向量数据库中更新迭代快、社区活跃度高，同时也提供了较完善的可视化界面，上手和管理都比较方便。因此，后续课程我们将以 Milvus 作为示例工具进行讲解与演示。

存的时候，向量和原文要一起存。后面检索出来，得把原文拿给大模型看。同时还要有元数据（简单理解是个 JSON）的概念，方便检索时进行筛选精准数据。

2.5 Retrieve：检索相关内容

用户提问了，比如"打印机墨盒怎么换"。

这时候做两件事：

1. 1.
2. 把用户问题也转成向量；
3. 2.
4. 拿这个向量去向量数据库搜，找出最相似的几个文档块。

因为语义相近的文字向量也相近，所以用户说"墨盒怎么换"，文档里写的是"墨盒更换步骤"，照样能匹配上。

这就是前面说的理解语义——不是比字面，是比意思。

2.6 Answer：大模型生成回答

最后一步，把检索到的内容和用户问题打包发给大模型。

你是一个产品客服，请根据以下参考资料回答用户问题。 参考资料： 【文档1】墨盒更换步骤：1. 打开前盖... 【文档2】墨盒型号说明：本产品适用 XX-100 墨盒... 用户问题：打印机墨盒怎么换？ 请基于参考资料回答，如果资料中没有相关内容，请说明。

大模型看到这些资料，就能给出准确的回答，而不是自己编。

2.7 流程小结

准备阶段跑一次就行，有新文档时增量更新；运行阶段每次用户提问都走一遍。

阶段	步骤	做什么
准备阶段（离线）	Ingest	导入原始文档
	Chunk	切成小块
	Embed	转成向量
	Index	存进向量数据库
运行阶段（在线）	Retrieve	检索相关文档
	Answer	大模型生成回答

上面六步，先有个整体印象就行。

实际落地的时候，每一步都有不少讲究。比如文档怎么切块效果最好？向量模型选哪个？检索结果要不要做重排序？这些选择没有标准答案，得看你的数据特点和业务场景。

后面的章节会把每个环节拆开，聊聊常见的做法和踩坑点。

优缺点

先说好处，RAG 能火起来不是没道理的。

成本低，上手快

想让大模型懂你的业务知识，有两条路：一是拿你的数据去微调模型，二是用 RAG 把知识喂给它。微调要准备训练数据、要算力、要时间，搞一次少说几天。RAG 就简单多了，把文档灌进向量库，当天就能跑起来。

想让大模型懂你的业务知识，有两条路：一是拿你的数据去微调模型（相当于让模型“重新学习”一遍，把知识记进模型参数里），二是用 RAG 把知识喂给它。

知识更新方便

微调完的模型，知识就固化了。要更新？再微调一轮。RAG 不一样，文档有变动，重新处理一下就行，甚至可以做到实时检索最新数据。对于知识频繁变化的场景，这点很关键。

答案可追溯

大模型回答的时候，你能看到它参考了哪些文档。用户觉得答案有问题，可以去查原文验证。这在对准确性要求高的场景（比如金融、医疗、法务）很重要——出了问题能查到底。

---

再说问题，RAG 也不是万能的。

效果看知识库质量

垃圾进，垃圾出。知识库里的文档质量差、组织乱，检索出来的内容也不会好到哪去。RAG 系统的上限，很大程度上取决于你喂给它的数据。

系统复杂度上来了

原本直接调大模型就完事，现在多了文档处理、向量存储、检索排序这些环节，链路变长了。任何一个环节出问题，最终效果都会打折扣。调试起来也比单纯调模型麻烦。

检索耗时不能忽视

多了检索这一步，响应时间必然变长。有研究说检索环节能占整个 RAG 流程耗时的 60% 以上。如果业务对延迟敏感，这块得重点优化。

---

总的来说，RAG 适合知识密集、更新频繁、需要可追溯的场景。但它不是银弹，效果好不好，得看知识库建得怎么样、系统设计得合不合理。

三、大模型五大致命局限性

1. 幻觉问题：不懂事实逻辑，容易一本正经编造虚假内容。
2. 知识时效性差：知识库冻结，无法知晓后续新政策、新产品、新动态。
3. 垂直专业深度不足：通用知识丰富，企业私有业务、小众专业领域知识缺失。
4. 无法访问私有数据：拿不到公司制度、内部文档、客户数据、业务资料。
5. 回答不可追溯：无法给出答案参考出处，医疗 / 法律 / 金融等场景不适用。

四、传统关键词检索的痛点

仅匹配字面关键词，无法理解语义同义表述；用户口语化提问、委婉表述完全匹配不到，解决不了自然语言问答需求。

五、RAG 核心概念

1. 全称：Retrieval-Augmented Generation 检索增强生成，2020 年 Meta 提出。
2. 核心思想：大模型开卷考试，融合两大能力：大模型语义理解 + 私有知识库语义检索。
3. 核心流程逻辑：私有文档入库→用户提问→语义检索相关资料→把问题 + 资料喂给大模型→基于资料合规作答。

六、RAG 六大核心流程（分两大阶段）

离线准备阶段（一次构建、增量更新）

1. Ingest 数据接入：解析 PDF/Word/ 网页 / 数据库等，清洗为纯文本。
2. Chunk 文档切块：长文档拆分小块，兼顾上下文完整性与检索精度；常规 500-1000 字，相邻块做重叠防信息截断。
3. Embed 向量化：通过 Embedding 模型把文字转为多维数字向量，语义相近则向量空间距离近，解决语义匹配问题。
4. Index 向量入库：向量 + 原文 + 元数据存入向量数据库（课程主推 Milvus）。

在线运行阶段（每次用户提问必走）

1. Retrieve 语义检索：用户问题向量化，在向量库相似度匹配，召回相关文档块。
2. Answer 生成回答：拼接用户问题 + 检索资料，交给大模型限定依据资料作答，杜绝编造。

七、RAG 优缺点

优点

1. 落地成本低、上手快，相比微调无需算力和训练数据。
2. 知识更新灵活，修改文档即可增量更新，无需重新训练模型。
3. 答案可溯源，能展示参考文档，满足严谨行业合规要求。

缺点

1. 垃圾进垃圾出：效果上限完全依赖知识库文档质量。
2. 系统链路长、复杂度高，任一环节出问题都会影响最终效果。
3. 额外增加检索环节，响应延迟升高，对高并发低延时业务需专项优化。

八、RAG 四大经典落地场景

1. 企业内部知识库：查制度 / 流程 / 技术文档；对接 OA/HR/BI/ 订单系统，升级为企业智能助手。
2. 智能客服：依托产品手册、FAQ、历史工单，替代传统关键词机器人，覆盖非标提问。
3. 专业领域助手：法律（法条判例）、金融（研报财报）、医疗（文献用药），兼顾准确 + 可溯源。
4. 开发技术助手：接入代码仓库、API 文档、技术手册，辅助开发答疑。

九、Demo 到企业级 RAG 的核心难点

1. 数据层：多格式文档解析、表格 / 扫描件处理、切块策略难统一。
2. 问答层：问题重写（口语转标准问、多轮上下文补全、多意图拆分）。
3. 调度层：意图识别（区分闲聊 / 知识库检索 / 工具调用、多知识库路由、敏感问题拦截）。
4. 检索层：纯向量检索有局限，需向量 + 关键词混合检索、结果重排序、权限过滤、精准编号匹配。
5. 会话层：多轮对话记忆管理、历史摘要压缩、长期记忆持久化与更新。
6. 配套层：问题引导澄清、请求风控、答案溯源、模型负载均衡、效果监控迭代。