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

[RAG 核心流程](#RAG 核心流程)

[2.1 Ingest：把数据导进来](#2.1 Ingest：把数据导进来)

[2.2 Chunk：把长文档切成小块](#2.2 Chunk：把长文档切成小块)

[2.3 Embed：把文字变成向量](#2.3 Embed：把文字变成向量)

[2.4 Index：存进向量数据库](#2.4 Index：存进向量数据库)

[2.5 Retrieve：检索相关内容](#2.5 Retrieve：检索相关内容)

[2.6 Answer：大模型生成回答](#2.6 Answer：大模型生成回答)

[2.7 流程小结](#2.7 流程小结)

优缺点

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

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

[五、RAG 核心概念](#五、RAG 核心概念)

[六、RAG 六大核心流程（分两大阶段）](#六、RAG 六大核心流程（分两大阶段）)

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

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

[七、RAG 优缺点](#七、RAG 优缺点)

优点

缺点

[八、RAG 四大经典落地场景](#八、RAG 四大经典落地场景)

[九、Demo 到企业级 RAG 的核心难点](#九、Demo 到企业级 RAG 的核心难点)

RAG 核心流程

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

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

下面一个个拆开讲。

2.1 Ingest：把数据导进来

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

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

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

2.2 Chunk：把长文档切成小块

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

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

所以要切块。比如一份 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：检索相关内容

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

这时候做两件事：

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

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

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

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 适合知识密集、更新频繁、需要可追溯的场景。但它不是银弹，效果好不好，得看知识库建得怎么样、系统设计得合不合理。

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

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

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

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

五、RAG 核心概念

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

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

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

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

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

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

七、RAG 优缺点

优点

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

缺点

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

八、RAG 四大经典落地场景

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

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

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