RAG 到底是怎么工作的：搞懂这个流程，八成的问题你自己就能定位
做知识库问答，绕不开 RAG 这个词——检索增强生成。
网上讲原理的文章不少，但大多停在概念层面。这篇只讲一件事：搞懂这个流程之后，你自己就能定位八成的问题。
一个比喻
想象你请了一位记忆力很好但没读过你公司文件的顾问。
有人来问「出差住宿能报多少」，你不能指望他凭空知道。你要做的是：从文件柜里找出相关的那几页，递给他，让他照着回答。
RAG 就是这个过程的自动化：
- 提前把文件切成小段，编好索引（建库）
- 有人提问时，找出相关的几段（检索）
- 把这几段和问题一起交给模型（组装）
- 模型照着这些材料回答（生成）
关键认识：模型回答得好不好，很大程度上取决于你递给它的那几页对不对。递错了页，再聪明的顾问也答不对。
这就是为什么「换个更强的模型」通常没用——问题往往出在前三步。
四个环节，四类失败
环节一：建库（切块与索引）
文档被切成小段，每段用嵌入模型转成一串数字（向量），存起来。
这一步会怎么失败：
- 文档根本没读进去。扫描版 PDF 是图片，没有文字层，系统读到的是空的。
- 结构丢了。表格被拉平成一行文字，行列关系没了。
- 切得不合理。一条完整的规定被拦腰截断，或者十条政策塞在一段里。
怎么查：直接看系统里存的分段内容。这一步是最常被跳过、也最有价值的检查——很多人反复调参数，却从没看过系统实际读到了什么。
朴素标准：随便挑几段自己读。你读不懂的，模型也读不懂。
环节二：检索（找出相关内容）
问题也转成向量，和库里的文档向量比对，找出最接近的几段。
这一步会怎么失败：
- 同义词不认。 用文档原话能查到，换个说法就查不到。说明嵌入模型没建立起这两种说法的关联，专业术语场景尤其明显。
- 精确匹配不擅长。 你问「XX-2024 号文件」，向量检索会给一堆语义相近的文件——在它眼里「XX-2024」和「XX-2023」几乎一样。
- 召回数量不对。 太少可能漏掉正确答案，太多引入噪音。
怎么查：直接看检索结果，不看最终答案。正确的片段有没有被找出来、排第几。
这一步的分流很关键：找出来了 → 问题在后面；没找出来 → 问题在前面。
环节三：组装（把材料交给模型）
检索到的片段和用户的问题一起，按某种格式组织成给模型的输入。
这一步会怎么失败：
- 材料太多，关键信息被淹没。 召回了十段，正确答案在第七段，模型可能没抓住重点。
- 材料自相矛盾。 新旧两版制度都在库里，都被检索出来了，模型不知道信哪个。
- 超出模型的上下文长度。 塞不下的部分被截断，而被截掉的可能恰好是答案。
环节四：生成（模型组织答案）
模型基于给定的材料回答。
这一步会怎么失败：
- 模型自由发挥。 没有约束它「只用给定材料」，它会混入自己训练时学到的通用知识——听起来合理，但不是你的制度。
- 没有材料时硬答。 大模型有个天然倾向：它会尽力给出答案，而不是承认不知道。
怎么改：在提示词里明确要求「只依据提供的资料回答，资料里没有的就说不知道」。但要清楚这是概率性约束，不是保证。
定位问题的两步法
记住这个方法，比记住所有参数都有用：
第一步：看检索结果，不看答案。
- 正确片段没被检索出来 → 问题在建库或检索（环节一、二）
- 正确片段被检索出来了 → 问题在组装或生成（环节三、四）
第二步：按定位的环节去查。
这个分流五分钟就能做完，能省下几天的乱试。跳过它直接调参数，是最常见的浪费。
为什么「换更强的模型」通常没用
因为模型只参与第四个环节。
如果正确的资料压根没被检索出来，那模型手里的材料就是错的。再强的模型也只能把错误材料复述得更流畅。
反过来说，如果检索是准的，那大部分常见任务用中等规模的模型就够——它要做的是照着材料组织语言，不是靠自己的知识回答。
这个认识能帮你把预算花在对的地方。
RAG 做不到的三类事
一、跨文档的对比和推理。 「A 部门和 B 部门的报销标准有什么不同」——这需要分别检索、理解、对比。检索机制本身是找相似片段，不做分析。这类需求要在应用层设计流程。
二、精确计算。 「我工作三年能休几天年假」——如果制度里写的是规则不是结果，模型算错的概率不低。这类问题该用工具调用去算。
三、回答文档里没有的东西。 这是最根本的一条：RAG 不产生新知识，只是让已有知识可被检索。 很多组织的真实问题是知识从来没被写下来过，上系统只是把这个问题暴露出来。
一个关键判断：这个需求适不适合用 RAG
不是所有「让 AI 懂我们业务」的需求都该用 RAG。三种常见方案的适用场景不同，选错了会绕远路。
RAG（检索增强）：把资料存起来，用的时候查出来给模型看。
- 优点：资料改了立刻生效，成本低，能追溯答案来源
- 适合：知识会变、需要引用出处、内容量大的场景——绝大多数企业知识库属于这一类
微调：用你的数据训练模型，让知识进到模型参数里。
- 缺点：资料一变就要重新训练；答案没有出处，无法追溯；需要数据和算力
- 适合：需要模型掌握特定的表达风格或专业语感，而不是记住具体事实
直接把资料塞进提示词：不做检索，每次把全部资料都发给模型。
- 优点：实现最简单，没有检索误差
- 限制：受上下文长度限制，而且每次调用都传全部资料，成本随资料量线性增长
- 适合：资料很少且基本不变的场景，比如一份两页的服务说明
最常见的误判是想用微调解决知识问题。 「我们想让模型学会我们公司的制度」——这个需求用 RAG 做又快又准还能改，用微调则是费力不讨好：训练完制度改了怎么办？答案说错了怎么追溯来源？
判断标准：你要的是让它记住事实，还是让它换种说法说话？前者用 RAG，后者才考虑微调。
优化的正确顺序
按收益从高到低：
- 改文档 —— 补同义表述、清过期内容、按用户问法写
- 改切块 —— 按文档类型选合适的切法
- 改检索方式 —— 向量加全文的混合检索，加重排序
- 换嵌入模型 —— 代价大（要重建索引），放后面
- 调参数和提示词 —— 最后
大部分人的顺序是反的，从第 5 步开始。
具体做法见知识库优化的正确顺序、检索不准怎么排查和嵌入模型怎么选。
文档整理这一环的方法，见知识库项目七成工作量在文档。
如果调到最后发现平台给的空间就是不够，那可能到了低代码平台的能力边界。这类需要深度定制的活我们做，可以聊聊。