前面几节，我们已经集齐了 RAG（外挂知识库）架构的三大核心组件：
- 大模型（LLM）：负责阅读和总结的 “大脑”。
- 词向量（Embedding）：负责把文本转换成向量（数字坐标）的 “翻译官”。
- 向量数据库（Vector DB）：负责存储数字坐标的 “仓库”。
现在，我们就把这三个组件拼装在一起，来看看在真实的商业项目中，一个基于 RAG 的企业专属 AI 助手，到底是如何完整运转起来的。
我们可以把 RAG 的工作流程，想象成开一家高档餐厅，它大致分为两个阶段：
- 后厨备菜（离线准备阶段）。
- 前厅上菜（在线问答阶段）。
第一阶段：离线准备阶段（后厨备菜）
这个阶段通常是在后台悄悄进行的。不管前面有没有顾客提问，只要你们公司发布了新的规章制度、产品手册，后厨的这条流水线就会立刻开动。它一共分为 4 步。
第 1 步：文档解析（摘菜洗菜）
你们公司的机密数据往往格式五花八门：有 PDF 财报、Word 合同，甚至还有一大堆表格。
这一步，我们要靠一些自动化工具，把这些乱七八糟的文件统统读进来，去掉多余的乱码、无法识别的图片，只把干净的纯文本内容提取出来。
第 2 步：文本分块（切肉切菜）
这是决定 RAG 系统成败的最重要一步。我们绝对不能把一本 10 万字的《员工手册》直接扔给大模型。因为大模型的记忆力（上下文窗口）是有限的，而且如果一段话太长，它转化出来的 “数学坐标” 就会变得模糊不清，反而找不准。因此，我们必须像厨师切肉一样，把长篇大论切成一小段一小段的文字碎片（Chunk）。
不过切碎文档时，千万不能 “一刀盲切”。比如下面这句话：
咱们公司的报销额度是每天 500 元如果把这句话切成 “咱们公司的报销额度是” 和 “每天 500 元” 这两个碎片，这样就会导致在查询时逻辑完全断开了。
所以在实际操作中，系统会让相邻的两个碎片之间，留一小段文字 “重叠贴合”，从而完整保留上下文的连贯性。
第 3 步：向量化（贴上标签）
系统使用词向量技术，把刚刚切分好的每一个文本块，都转换成一个个向量（数字数组）。这就好比给切好的每一盘配菜，都贴上了一个专属的 “定位标签”。
第 4 步：存入向量数据库（放进专属冰柜）
系统把切好的 “原始文本” 和它对应的 “数字向量” 一对一绑定，然后一起存进向量数据库（比如 Milvus 或 Pinecone）中。
至此，后厨的备菜阶段就圆满结束了。
第二阶段：在线问答阶段（前厅上菜）
当用户在网页的对话框里输入问题、并敲下 Enter 键的那一瞬间，前厅的流水线就被激活了。它同样分为 4 步。
第 1 步：问题向量化（顾客点单）
用户的提问，本质上也是一段文本，比如：
公司出差的高铁票可以报销一等座吗？收到用户的提问后，系统会调用词向量模型（注意，这里用的不是大模型），把用户这句话也翻译成一个个向量（数学坐标）。
第 2 步：查询向量（后厨找食材）
系统拿着用户问题的数字向量，去向量数据库里发起查询。
向量数据库开始高速执行空间距离计算，从几十万个文本块中，揪出距离最近、语义最相关的 3~5 个文本块（比如找到了《员工差旅报销制度》中关于高铁座位的规定），并将原文提取出来。
重排序（Rerank）
向量检索胜在快，可它 “粗筛” 出来的前几名，排序有时并不够精准（语义最贴近的，未必正好排第一）。
所以在要求较高的系统里，工程师还会加一道 “精排” 工序：把向量库初筛出的一二十个候选，丢给一个专门的 “重排序模型” 逐个重新打分、排序，最后只挑最靠谱的两三段交给大模型。
用一句话总结：向量检索负责 “海选”，重排序负责 “决赛”。
第 3 步：拼装提示词（厨师做菜）
这是 RAG 架构中最巧妙的一步。系统会在后台，把刚才检索出来的 3 段规章制度原文，连同用户的原始问题，一起套进一个预先写好的提示词模板里。
拼装出来的完整提示词，大概长这样：
你是一个严谨的 AI 助手。请你严格根据以下【参考资料】来回答问题。如果资料里没有提到，请直接回答 “我不知道”，绝不允许编造！
--- 参考资料开始 ---
[碎片1：员工出差交通工具标准：普通员工仅限报销高铁二等座，总监及以上级别可报销高铁一等座...]
[碎片2：一线城市（北上广深）出差审批流程说明...]
[碎片3：报销发票的贴票规范...]
--- 参考资料结束 ---
用户的问题是：公司出差的高铁票可以报销一等座吗？
第 4 步：大模型生成答案（把菜端上桌）
最后，系统把上面这长长的一大段提示词，一次性发给大模型（比如 DeepSeek 或 Claude）。
大模型发挥出它超强的阅读理解能力，看完这些参考信息后，直接给出最终答案：
您好，根据公司规定，如果您是总监及以上级别，可以报销一等座；如果是普通员工，仅限报销二等座。
RAG 是 80% 的数据工程
很多小伙伴以为，只要给大模型套上了 RAG 架构，它就无敌了。可实际用起来，照样经常会 “搜不到答案” 或者 “答非所问”。
原因很简单：RAG 准不准，完全取决于你前期准备的数据干不干净。
如果我们在切分长文档时切得毫无逻辑，或者存进数据库的 PDF 全是识别错误的乱码，那么大模型最后拿到的参考资料就是一堆垃圾——这就是所谓的 “垃圾进，垃圾出”。提供的参考资料全是错的，大模型再聪明，也绝对给不出正确的回答。
所以，想搭建一个真正好用的企业级 RAG 知识库，我们必须把 80% 的精力花在处理基础数据上，比如：把文档里的乱码洗干净、把排版理顺、把长文章合理地切分开。只有把这些脏活累活做到位，AI 才能真正发挥出准确问答的威力。
给开发者的启发
对非技术的小伙伴来说，看到这里，你其实已经把市面上所有 “文档对话”、“AI 知识库” 产品的底层逻辑，给彻底看透了。
在上述所有的流程中，作为开发者，我们不需要自己去发明大模型，也不需要去写复杂的底层算法。最主要的工作，就是使用 Python、Go 或者 Node.js 等写一套后台代码，去充当一个 “调度员” 即可：
- 写代码读取文件。
- 调 API 生成向量。
- 把数据塞进数据库。
- 查出数据后，拼接字符串（拼装提示词）。
- 最后调 API 把字符串发给大模型，拿到结果传给前端。
是的，就这么简单。我们会发现：开发一个 AI 应用，其实比开发一个传统的 Web 应用（比如网站）门槛还要低！
此外补充一点，上面这套 “读取 → 切分 → 向量化 → 入库 → 检索 → 拼接 → 调用” 的流水线，其实早有现成的框架替我们打包好了——比如大名鼎鼎的 LangChain 和 LlamaIndex。
它们把这些重复的 “调度” 动作封装成了一个个开箱即用的模块，我们不必每次都从零手写。对于这套东西，我们在后面的《LangChain 教程》中会专门带大家上手。
