RAG 就是给大模型接一个知识库。

这句话没错。

但问题是：

“接知识库”到底是怎么接的？

难道就是：

上传 PDF↓AI 自动读懂↓以后什么都能问

当然没有这么简单。

一个真正能用的 RAG 系统，中间其实经历了完整的一条链路：

文件进入系统↓解析文件↓拆分内容↓给内容建立“索引”↓用户提问↓系统搜索相关资料↓筛选最有用的内容↓交给大模型↓生成最终答案

如果把 RAG 理解成一个“AI 图书馆”，整个过程就非常好懂了。

今天我们就沿着这条流程，从头走一遍。

第一步：先把企业资料放进“AI 图书馆”

假设公司有这些资料：

《员工差旅管理制度.pdf》《产品使用手册.docx》《售后服务标准.xlsx》《2026 年报销政策.pdf》

我们希望以后员工可以直接问：

“上海出差住宿最多可以报销多少钱？”

AI 就能根据公司制度回答。

第一步当然是：

把资料交给系统。

但这里有一个很重要的问题：

这些资料的格式可能完全不同。

有：

PDFWordExcelPPT网页扫描件图片

大模型并不能直接把所有格式都当成普通文字来处理。

所以第一件真正的技术工作其实是：

文件解析。

第二步：把各种文件“翻译”成 AI 能读的内容

比如一份 PDF 里面可能同时有：

正文表格标题页眉页脚图片扫描文字

系统需要把这些内容提取出来。

比如：

《差旅管理制度.pdf》↓解析↓第一章 总则第二章 交通标准第三章 住宿标准第四章 报销流程

如果 PDF 本身是扫描件，

可能还需要 OCR：

图片↓OCR↓文字

如果里面有表格，

还要尽量还原：

城市 | 员工级别 | 住宿标准上海 | 普通员工 | 600 元北京 | 普通员工 | 600 元深圳 | 普通员工 | 550 元

这一步非常重要。

因为：

如果文件一开始就解析错了，后面的 AI 再聪明也没用。

比如原文写的是：

住宿标准 600 元

OCR 错误识别成：

住宿标准 6000 元

后面的 RAG 很可能就会一本正经地告诉用户：

上海住宿标准是 6000 元。

所以做好 RAG 的第一步，并不是选大模型。

而是：

先保证资料被正确读出来。

第三步：不能把整本文件直接塞给 AI，要先“切块”

现在系统已经把：

100 页《差旅管理制度》

全部提取成文字了。

接下来能不能直接存进去？

理论上可以。

但检索的时候会非常麻烦。

因为用户问：

“上海住宿标准是多少？”

我们真正需要的可能只有文件里的这一小段：

第三章 住宿标准一线城市普通员工住宿标准为 600 元/晚。

根本没必要把整本 100 页文件全部交给模型。

所以系统通常会把长文档：

切成很多小段。

这个过程叫：

Chunking

可以简单理解成：

把一本书拆成很多张知识卡片。

比如：

Chunk 1差旅申请流程Chunk 2飞机、高铁交通标准Chunk 3上海、北京住宿标准Chunk 4餐饮补贴标准Chunk 5报销审批流程

以后用户问住宿问题，

系统就只需要找到：

Chunk 3

而不是把整本制度都翻出来。

所以 Chunk 可以理解成：

RAG 搜索知识时使用的最小资料单元。

第四步：给每张“知识卡片”建立编号和标签

切完之后，系统还不能直接搜索。

通常还会给每个 Chunk 保存一些附加信息。

比如：

内容：上海普通员工住宿标准为 600 元/晚来源：《2026 年差旅管理制度》章节：第三章 住宿标准发布时间：2026-01-01适用地区：上海版本：V3.0

这些信息叫：

Metadata

也就是元数据。

普通读者可以理解成：

给每张知识卡片贴标签。

为什么重要？

因为企业里面经常会出现：

2024 年制度2025 年制度2026 年制度

如果不管理版本，

系统可能同时搜出三份。

最后 AI 到底应该相信哪一份？

所以成熟的知识库不能只是：

把文件丢进去

还需要管理：

来源版本时间部门权限文件状态

第五步：把文字变成“可以搜索意思”的数字

接下来就到了 RAG 最容易听起来很技术的一步：

Embedding

其实特别好理解。

假设知识库里有一句：

员工出差住宿最高报销 600 元。

用户问：

“我去上海住酒店最多能报多少钱？”

这两句话几乎没用相同的词。

传统关键词搜索可能不好找。

但是人一看就知道：

这两个说的是一回事。

Embedding 做的事情就是：

让计算机也能判断两段话在“意思上”像不像。

系统会把每一段文字转换成一串数字。

比如：

差旅住宿标准↓[0.82, 0.13, -0.47, 0.69...]

用户问题也转换成数字：

去上海住酒店最多报多少钱↓[0.79, 0.16, -0.42, 0.72...]

如果两串数字很接近，

系统就认为：

这两段内容意思比较接近。

这些数字通常被叫做：

向量

然后系统会把这些向量保存到：

向量数据库 / 向量索引

里面。

到这里，

知识库的“准备工作”基本完成。

第六步：终于有用户来提问了

现在用户问：

“上海出差住宿最多可以报销多少钱？”

RAG 系统首先不会马上让大模型回答。

而是：

先搜索。

整个过程类似：

用户问题↓理解问题↓转换成向量↓去知识库搜索

系统可能找到：

候选 1：上海普通员工住宿标准 600 元候选 2：北京普通员工住宿标准 600 元候选 3：上海出差交通费报销规定候选 4：上海餐饮补贴 100 元/天

这些都“有一点相关”。

但我们真正最想要的是：

候选 1

所以还需要继续处理。

第七步：第一次搜索只是“海选”

现实里的 RAG 通常不会搜索一次就结束。

可以把第一次搜索理解成：

海选。

先从成千上万条资料中找出：

最可能相关的 20 条

这里现在比较成熟的做法通常不只依赖一种搜索。

经常会同时使用：

关键词搜索+语义搜索

比如用户问：

“BX202608180001 这笔报销为什么被退回？”

其中：

BX202608180001

这种编号，

关键词搜索特别好用。

而：

“住宿最多能报多少钱？”

这种表达，

语义搜索更加擅长。

所以很多企业会使用：

Hybrid Search

也就是：

关键词搜索+向量搜索

一起做。

第八步：再让系统进行一次“复试”

第一次搜索可能找出 20 条。

但是这 20 条里面，

真正有用的可能只有 3～5 条。

怎么办？

再排一次。

这个过程叫：

Rerank

重排序。

可以把它理解成：

海选↓20 条资料复试↓重新判断哪条和问题最相关最终↓留下最好的几条

例如最终得到：

Top 1《2026 差旅管理制度》上海住宿标准 600 元/晚Top 2住宿费用超过标准部分原则上由员工自行承担Top 3特殊情况需要部门负责人审批

到这里，

RAG 最重要的：

Retrieval

检索，

才算基本完成。

第九步：把找到的资料交给大模型

注意：

直到现在，

大模型才真正开始登场。

系统会把：

用户问题+刚刚找到的资料

拼在一起。

可能形成这样一段 Prompt：

请根据以下资料回答用户问题。资料 1：上海普通员工住宿标准为 600 元/晚。资料 2：超过住宿标准的部分原则上由员工自行承担。用户问题：上海出差住宿最多可以报销多少钱？请仅依据以上资料回答。

然后才交给大模型。

这时候模型就不是：

凭自己的记忆猜答案

而是：

看着资料回答问题。

所以 RAG 最核心的思想其实特别简单：

先把正确资料找出来，再让大模型负责读懂和组织语言。

第十步：大模型把资料“翻译成人话”

现在大模型拿到资料以后，

可能回答：

根据《2026 年差旅管理制度》，上海地区普通员工的住宿标准最高为 600 元/晚。如果住宿费用超过该标准，超出部分原则上需要员工自行承担。

注意这里大模型主要做了三件事：

理解问题+理解资料+组织答案

而：

600 元

这个事实并不是模型自己“记住”的。

而是：

RAG 刚刚从知识库找到的。

这就是为什么 RAG 特别适合：

企业制度产品手册医疗指南客服知识内部文件法律条款

这些内容。

第十一步：最好把“出处”一起告诉用户

成熟的 RAG 系统通常还会告诉用户：

这个答案是从哪里来的？

例如：

答案：上海普通员工住宿标准为 600 元/晚。来源：《2026 年差旅管理制度》第三章 第 12 条

用户甚至可以点击：

查看原文

这一步非常重要。

尤其是：

医疗金融法律企业制度

等场景。

因为用户不应该只能看到：

AI 是这么说的。

最好还能看到：

AI 根据什么资料这么说。

第十二步：回答完并不代表结束，还需要评估

一个 RAG 系统上线以后，

真正重要的是不断检查：

有没有搜到正确资料？

比如准备 100 个真实问题：

问题 1：上海住宿标准是多少？正确资料：《2026 差旅制度》第三章

然后检查：

系统搜到了吗？

如果没有，

问题可能出在：

文件解析Chunk 切分Embedding搜索方式Rerank

如果资料搜对了，

但答案还是错，

那问题可能出在：

Prompt模型理解答案生成

所以一个 RAG 系统真正上线以后，

还需要不断收集：

答错的问题搜不到的问题引用错的问题用户差评

继续优化。

十三、把完整 RAG 流程串起来

现在我们重新看一遍。

第一阶段：知识准备

PDF / Word / Excel / 网页↓文件解析↓提取文字和表格↓切成 Chunk↓添加来源、版本、权限等标签↓Embedding↓保存到搜索索引 / 向量数据库

这一步可以理解成：

整理图书馆。

第二阶段：用户提问

用户问题↓分析问题↓关键词搜索 + 向量搜索↓找到候选资料↓Rerank↓选出最相关内容

这一步可以理解成：

图书管理员帮你找书。

第三阶段：生成答案

用户问题+找到的资料↓交给大模型↓模型阅读资料↓生成答案↓附带资料来源

这一步可以理解成：

拿着找到的书，帮你总结答案。

所以整个 RAG 系统其实就是：

整理资料↓找到资料↓读懂资料↓回答问题

一点都不神秘。

最后总结

如果只记住一句话：

RAG 就是让 AI 回答问题之前，先帮它去资料库里找到最相关的内容。

它的完整过程可以浓缩成：

文件↓解析↓切片↓Embedding↓建立索引↓用户提问↓检索↓Rerank↓找到最相关资料↓交给大模型↓生成答案↓返回来源

所以做好 RAG，

真正需要关注的不只是：

“大模型选哪个好？”

而是整条链路：

文件有没有解析正确？Chunk 有没有切好？旧版本有没有清理？搜索能不能找到正确资料？Rerank 排得准不准？模型有没有按照资料回答？答案有没有来源？错误问题有没有持续优化？

这也是为什么企业真正做 RAG 时，

它绝不是：

上传几个 PDF+接一个大模型=完成

而是一套：

把企业知识整理好、找到对、交给 AI、再让 AI 说清楚的完整知识工程。

理解了这一点，

RAG 就不再是一个听起来很复杂的 AI 技术名词。

它本质上就是：

给大模型配了一个会整理资料、会搜索资料、还会把正确资料送到它手里的“智能图书馆”。