RAG 的整体流程：本质上就是“先找资料，再组织答案”

这两年，大模型越来越火，RAG 这个词也跟着频繁出现。很多人第一次看到这个概念，会觉得它听起来有点“高大上”，像是什么特别复杂的技术方案。可如果把它拆开来看，你会发现，RAG 的核心思路其实一点都不绕，甚至可以说很符合常识。

说白了，RAG 做的事情就是：用户提问之后，系统先去知识库里找相关内容，再基于这些内容生成答案。

这不就是人在回答问题时经常会做的事吗？碰到不确定的问题，先查资料、找依据、抓重点，最后再把答案组织出来。既然人都知道不能张口就来，那大模型为什么不能先查再答？

也正因为这样，RAG 在企业知识库、智能问答、文档助手、客服机器人这些场景里特别常见。它不是让模型变成“什么都知道”，而是让模型在回答之前，先接触到和问题相关的真实资料。这样做，答案自然会更稳，也更贴近业务实际。

一、RAG 到底是什么？

RAG，全称是 Retrieval-Augmented Generation，中文一般翻译成检索增强生成。

这个名字看起来有点学术，但其实可以拆开理解：

前半部分是 Retrieval，也就是检索；
后半部分是 Generation，也就是生成。

合起来的意思其实很简单：不是直接生成，而是先检索，再生成。

这里面最关键的区别就在于，传统的大模型回答问题，更多是依赖训练阶段学到的知识；而 RAG 则会在回答之前，额外去知识库里找相关资料，再把这些资料连同问题一起交给模型，让模型基于上下文来生成答案。

看起来只多了一步“查资料”，但这一步的意义其实非常大。因为在很多真实场景里，用户问的根本不是公开通用知识，而是企业内部的文档、产品手册、FAQ、制度说明，甚至是最新更新过的内容。模型本身可能没见过这些资料，那它靠什么答？靠猜吗？这显然不靠谱。

所以从本质上说，RAG 不是为了让模型“更能说”，而是为了让模型“说得更有依据”。

二、为什么大模型需要 RAG？

如果没有 RAG，大模型回答问题，主要依赖的是预训练学到的内容。这样做当然也能回答很多通用问题，但只要一进入业务场景，问题很快就会暴露出来。

第一个问题，就是模型不知道你的私有知识。
比如公司内部的产品文档、项目手册、操作流程、常见问题说明，这些内容通常都不在模型原本的训练语料里。模型不知道这些信息，却还要回答相关问题，那很多时候就只能“凭感觉”去补。

第二个问题，就是知识会过时。
模型训练完之后，它脑子里的知识不会自动更新。文档改版了，字段变了，流程变了，如果没有额外的知识接入机制，模型很可能还在按照旧内容回答。表面看它答得挺流畅，实际上可能早就不对了。

第三个问题，也是大家最熟悉的：幻觉。
模型有时候并不是不知道，而是“不确定但照样回答”。这在闲聊场景里可能问题不大，但一旦进入企业场景、知识库问答或者专业问答，错了就是错了，流畅并不能掩盖问题。

所以 RAG 的出现，其实就是在解决一个很现实的问题：让模型在回答之前，先有机会参考真实资料。

这就像考试一样。闭卷作答当然考记忆，但很多业务场景更像开卷考试。既然资料就在旁边，为什么不先翻一眼再答呢？

三、RAG 的整体流程，可以分成两大部分

如果从完整链路来看，RAG 通常可以分成两部分：

第一部分是准备阶段（提问前）
第二部分是回答阶段（提问后）

这个划分很好理解。用户发起提问的时候，系统不可能临时再去把整份文档从头到尾处理一遍，那样不仅慢，而且根本不现实。所以很多工作必须提前做好。

换句话说，准备阶段更像是在“提前整理知识”，回答阶段才是真正开始“根据问题查资料并回答”。

这两部分看起来是前后衔接的，但实际上，前面的准备做得好不好，直接决定了后面的回答质量。后面答得准不准，很多时候不只是模型的问题，而是前面的知识整理有没有做好。

四、准备阶段：先把原始文档变成可检索的知识

RAG 在真正回答问题之前，首先要把原始资料准备好。这个阶段虽然发生在用户提问之前，但重要性一点都不低。很多系统最后效果不好，问题往往不是出在“生成”这一步，而是前面的文档处理没做好。

1. 原始文档接入

准备阶段的起点，通常就是各种知识来源，比如产品手册、FAQ、帮助文档、制度文档、知识库文章，甚至还可能包括 PDF、网页、数据库记录等。

这些内容对人来说当然有用，但对系统来说还不能直接拿来做检索。原因很简单，原始文档通常比较长，内容结构也不一定规整。用户可能只问一个很小的问题，如果每次都把整份文档塞给模型，不仅浪费资源，也很难让模型快速抓住重点。

所以第一步并不是“直接用文档回答”，而是先把文档处理成更适合机器使用的形式。

2. 分片：把长文档拆成小段

这一步通常叫 Chunking，也就是分片。

为什么一定要分片？因为检索系统更擅长在很多小段内容里找相似项，而不是直接在一整本长文档里硬查。把文档拆成一个个相对独立、语义比较完整的小片段之后，后续检索时才能更准确地定位到真正有用的内容。

但分片也不是随便一切就完事了。切得太大，信息太杂，检索结果可能不够精准；切得太小，上下文又容易断掉，导致片段虽然短，但意义不完整。那怎么切才合适？这其实很考验经验。很多 RAG 系统效果不理想，不是因为模型不够强，而是一开始分片就没分好。

所以这一步看起来像文档预处理，实际上它会直接影响后面的召回质量。说到底，分片的目标只有一个：让系统后面更容易找到“刚好有用”的那段内容。

3. 向量化：把文本转成机器更容易比较的形式

文档分完片之后，还不能直接拿去做语义检索，因为机器并不像人一样能直接理解文字的意思。它更擅长处理的是数字形式的数据。

所以这时候就需要用到 Embedding 模型，把每个文本片段转成向量。你可以把这个过程理解成：把一段文字映射到向量空间里，让机器可以通过“距离”去判断语义是否接近。

比如两段文字虽然措辞不同，但如果表达的是相近的意思，它们在向量空间里的位置通常也会比较接近；反过来，如果内容差得很远，向量距离一般也会更远。

这一步非常关键，因为后面用户提问时，问题也会被转成向量，然后再和这些文档片段做相似度匹配。换句话说，RAG 能不能把相关资料找准，很大程度上就取决于这里的向量表示做得好不好。

4. 建索引，写入向量数据库

当片段有了，对应的向量也有了，下一步就是把这些内容存起来，并建立好索引结构，方便后续快速检索。

这时候一般会用到向量数据库，或者类似的向量检索系统。因为等用户真正开始提问之后，系统需要在大量文档片段中迅速找到和问题最相近的那几段内容。如果没有索引，每次都从头全量比较，效率显然撑不住。

做到这里，准备阶段基本就完成了。你会发现，它本质上是在做一件事：
把原始文档从“人能看懂的资料”，变成“机器可以快速检索的知识结构”。

五、回答阶段：用户提问之后，系统到底在做什么？

当前面的准备都做完后，RAG 才真正进入“回答问题”的阶段。

这一部分看起来更像是智能问答的核心，但如果拆开来看，逻辑其实并不复杂。说白了，还是那几个动作：先理解问题，再找资料，最后组织答案。

1. 用户提问，先不要急着生成

很多人一看到“生成式 AI”，就会本能地觉得：用户提问，大模型直接回答，不就结束了吗？

但 RAG 恰恰不是这么干的。它的思路是：先别急着回答，先把问题变成适合检索的形式。

比如用户问了一个问题，系统第一步通常不是立刻生成答案，而是先把这个问题送进 Embedding 模型，同样转成一个向量。因为只有这样，它才能和知识库里已经存好的文档片段做语义匹配。

换句话说，这一步是在做一件很重要的事：把用户的问题也放进同一个语义坐标系里。

2. 召回：先捞出一批可能相关的资料

问题转成向量之后，系统就会去向量数据库里做相似度检索，找出一批和这个问题最接近的文档片段。这一步一般叫 召回。

为什么叫召回？因为它更像是先“把可能有用的东西都捞出来”。注意，是“可能有用”，不一定每一段都完全精准，但至少大概率相关。

这一步其实很像人查资料。别人问你一个问题，你通常也不会第一秒就精准翻到唯一正确的段落，而是先找到一批相关内容，然后再慢慢筛。所以召回的作用，就是先把范围缩小，把“可能有答案的材料”找出来。

3. 重排：不是所有召回结果都一样有价值

召回出来的片段虽然相关，但相关程度并不完全相同。有些内容非常贴题，有些只是稍微沾边。如果不做进一步处理，直接把一堆召回结果全部交给模型，模型有时候反而容易抓错重点。

所以这时候通常还会做一步 重排。

重排的作用，说白了就是：对召回结果再进行一次更细的排序，把最贴近当前问题、最值得参考的内容排到前面。

如果说召回更像是在“先捞一批出来”，那重排就更像是在“从里面挑重点”。这一步的意义其实很大。因为对于最终答案来说，模型说得好不好固然重要，但前提是给它的参考材料得靠谱。如果材料本身就偏了，那后面生成得再顺，也只是“顺着错误往下说”。

4. 生成：模型基于资料来组织答案

等最相关的片段筛出来之后，才轮到大模型真正开始生成答案。

这时候系统会把“用户问题”和“经过召回、重排之后的关键片段”一起交给大模型，让它基于这些上下文来生成回复。也就是说，此时模型并不是在单纯依赖记忆作答，而是在“参考资料的基础上组织语言”。

这一点特别重要。因为很多人一说到生成式模型，就会觉得它是在“自由发挥”。但在 RAG 场景里，更准确的说法应该是：模型是在读完材料之后，再把内容说出来。

这其实和人回答问题很像。
看到问题之后，不是立刻开口，
而是先查资料、找依据、抓重点，
最后再把答案整理成一句自然的话。

这不就是 RAG 最核心的思路吗？

六、把整个流程压缩成一句话，其实就是这样

如果要把 RAG 的整体流程压缩成一句很容易记住的话，我觉得可以这么说：

先把文档切开、向量化、建索引存起来；等用户提问时，再把问题向量化，去知识库里召回相关内容，经过重排后，把最关键的上下文交给大模型生成答案。

如果再写得更像流程图一点，大致就是：

提问前：分片 → 向量化 → 建索引 / 入库
提问后：问题向量化 → 召回 → 重排 → 生成

表面上看步骤不少，但核心逻辑一直很简单：
不是让模型瞎猜，而是让模型基于资料回答。

七、RAG 的重点，其实往往不在“生成”，而在“检索”

很多人第一次接触 RAG，会把注意力全部放在最后的大模型生成上，觉得只要模型够强，效果自然就会好。但真正做过 RAG 系统之后，你往往会发现，最影响效果的，常常不是最后那一步“生成”，而是前面的“检索链路”。

文档怎么分片，会影响召回准不准；
Embedding 模型选得好不好，会影响语义匹配效果；
召回策略合不合理、重排做得够不够细，也会直接影响最后送进模型的上下文质量。

说到底，生成只是最后开口说话的那一步，前面“找资料找得准不准”，才是真正决定答案质量的关键。这个逻辑其实和现实世界非常像。一个人表达能力再强，如果参考材料找错了，那答案大概率也会跑偏；反过来，如果资料找得很准，就算表达稍微普通一点，至少内容不会离谱。

所以从工程角度看，RAG 其实不只是一个“生成系统”，更像是一个检索系统和生成系统的组合体。前面负责把资料找准，后面负责把内容说清楚。

八、总结

RAG 的整体流程，表面上看涉及分片、向量化、索引、召回、重排、生成，好像步骤不少，但如果抓住主线，其实并不难理解。

它做的事情很简单：
在用户提问之前，先把原始文档整理成机器可以快速检索的知识；
等用户真正提问时，再从知识库里找到最相关的内容，最后让大模型基于这些资料生成答案。

所以 RAG 真正有价值的地方，并不只是“让模型能回答问题”，而是“让模型在回答问题之前，先有机会参考真实、相关、可追溯的内容”。

尤其是在知识库问答、企业内部文档助手、智能客服这些场景里，先查再答，本来就比直接硬答更靠谱。毕竟面对真实业务问题，如果连资料都不看就开始回答，真的不会出问题吗？