RAG vs 微调：知识应该放进检索，还是写进参数？

上一篇《评估体系》讨论了一个判断前提：

模型有没有变好，不能只看训练日志。

要看它在真实任务里，是否更稳定、更准确、更可控。

但当评估做起来以后，一个更现实的问题马上出现：

如果模型答错了
到底是因为它不会？
还是因为它不知道？

这两个问题看起来很像，但解决方式完全不同。

如果模型不知道公司最新政策、产品价格、接口文档、课程安排，那不一定应该训练它。

可能只是应该让它去查资料。

如果模型知道资料，却总是不会按要求回答、不会抓重点、不会稳定输出格式、不会遵守业务流程，那也不一定是知识库的问题。

可能才需要微调，或者至少需要更强的提示词、规则和评估。

这就是本篇要拆开的核心问题：

知识应该放进检索，还是写进参数？

这句话听起来像工程架构问题，其实更像一个生活问题。

有些东西适合被内化成能力。

比如骑车、打字、做饭时的火候感、和人沟通时的分寸。

有些东西不适合硬背。

比如今天的航班、最新价格、某个政策版本、某篇文档里的具体条款。

前者更像能力。

后者更像资料。

RAG 和微调的分界，也大多藏在这里。

---

1. 先把两句话讲清楚

可以先用一组区别建立直觉：

RAG 解决的是：回答时去哪里查资料
微调解决的是：模型应该养成什么稳定能力

RAG 的全称是 Retrieval-Augmented Generation，也就是检索增强生成。

它不是把所有知识都塞进模型脑子里，而是在模型回答前，先从外部资料库里找相关内容，再把这些内容交给模型，让模型带着材料回答。

微调则是拿一批样本继续训练模型，让模型的参数发生变化。

它更像把某种行为习惯、表达方式、任务模式，写进模型的身体记忆里。

一个是开卷考试。

一个是长期训练。

开卷考试适合查事实。

长期训练适合练能力。

这不是谁高级谁低级的问题。

真正高级的做法，是知道什么时候开卷，什么时候练习。

---

2. 什么叫知识，什么叫能力

很多 RAG 和微调的争论，都是因为大家把“知识”和“能力”混在一起了。

比如下面这些东西，都叫“模型要知道”，但其实不是同一类问题。

问题	更像知识还是能力	更适合
公司最新报销规则是什么	知识	RAG
这个产品今天多少钱	知识	RAG / 工具
用户问售后时应该先确认哪些信息	能力 / 流程	微调 / 提示词 / 规则
按固定 JSON 格式输出	能力 / 格式习惯	微调 / 约束解码 / 校验
根据文档回答并给出处	知识 + 能力	RAG + 评估
不要编造没有来源的内容	行为约束	提示词 / 微调 / 风控
把一段长投诉拆成原因、诉求、风险	能力	微调 / 样本训练

所以不要先问：

是否需要训练？

更好的问题是：

目标是让模型获得资料，还是养成能力？

资料变化快，就不要急着写进参数。

能力要稳定，就不要只靠每次临时塞一大段提示词。

---

3. RAG 像什么

RAG 很像带着一个聪明助手去图书馆。

提出一个问题。

助手先去书架上找几页可能相关的材料。

然后它坐回来，拿着这些材料组织答案。

理想情况下，它不是凭记忆乱说，而是：

已查到这些材料
根据这些材料
答案更可能是这样
出处在这里

一个典型 RAG 链路大概长这样：

flowchart LR
  A["用户问题"] --> B["改写 / 理解问题"]
  B --> C["检索相关文档"]
  C --> D["排序与筛选"]
  D --> E["把材料放进上下文"]
  E --> F["模型生成回答"]
  F --> G["检查来源与风险"]
  G --> H["输出答案"]

看起来很顺，但每一步都可能出问题。

用户问得不清楚，检索词可能错。

文档切得不好，相关内容可能被切散。

召回不准，真正有用的材料可能没被找出来。

上下文塞太多，模型可能被干扰。

资料之间互相矛盾，模型可能不知道该信谁。

所以 RAG 不是“接一个知识库就完事”。

它是一套让模型使用外部资料的工程系统。

---

4. RAG 最适合什么

RAG 最适合处理那些变化快、需要追溯、不能靠记忆乱说的东西。

比如：

1. 公司制度
2. 产品说明书
3. API 文档
4. 客服知识库
5. 合同条款
6. 课程资料
7. 内部操作手册
8. 经常更新的价格、库存、排期

这些东西有一个共同点：

答案不应该存在模型感觉里
答案应该存在资料来源里

如果资料更新了，RAG 只需要更新文档库。

如果把这些东西训练进参数，问题就麻烦了。

今天训练进去的是 A 版本。

明天制度变成 B 版本。

模型可能还在按 A 版本回答。

追问来源时，它也不一定能说清楚答案来自哪个版本。

这就像把一本随时会改的说明书背下来。

背得越熟，改版以后反而越危险。

---

5. RAG 的真正价值不是“知道更多”

很多人以为 RAG 的价值是让模型知道更多东西。

这只说对了一半。

RAG 更重要的价值，是让答案变得可控。

它至少带来四个好处：

1. 可更新：文档变了，可以更新知识库，不必重新训练模型。
2. 可追溯：答案可以带来源，方便人工检查。
3. 可隔离：不同业务、不同客户、不同权限，可以看不同资料。
4. 可降级：查不到就说查不到，而不是硬编。

这对真实业务特别重要。

因为业务里最怕的不是模型“不够聪明”。

很多时候最怕的是它“看起来很聪明地胡说”。

RAG 至少给系统一个机会：

让模型先看材料
再组织语言
而不是凭空发挥

当然，它不是万灵药。

如果检索不到正确材料，模型依然可能答错。

如果材料本身脏乱差，模型也会跟着乱。

如果问题需要跨很多文档推理，RAG 的难度也会突然变高。

所以 RAG 的核心不是“有知识库”。

而是：

能不能在正确时间，把正确材料，以正确形态，送到模型面前。

---

6. RAG 的坑：不是找不到，就是找太多

RAG 最常见的失败，有两种。

第一种是找不到。

用户问：

退货超过 7 天但商品质量有问题怎么办？

知识库里明明有售后政策，但文档切分不好，检索只找到了“7 天无理由退货”，没找到“质量问题例外处理”。

模型拿到的材料不完整，就可能回答得很死：

超过 7 天不支持退货。

这就是召回失败。

第二种是找太多。

系统把十几段文档都塞进上下文，有旧政策、有新政策、有 FAQ、有客服话术，还有历史公告。

模型一看，材料很多，但互相打架。

最后它可能拼出一个“看起来合理但其实不准确”的答案。

这就是上下文污染。

所以做 RAG，不是文档越多越好。

更像做菜。

食材要新鲜。

刀工要合适。

火候要稳定。

不是把冰箱里所有东西倒进锅里，就会变成一道好菜。

---

7. 微调像什么

如果 RAG 像查资料，微调就像练基本功。

一个人不会因为看了十页游泳教材，就立刻会游泳。

他需要反复练。

模型也一样。

有些能力不是临时给资料就能稳定做到的。

比如：

1. 永远按某种结构拆解问题
2. 面对投诉先识别情绪和风险
3. 输出固定字段，减少格式飘移
4. 学会某个行业的表达方式
5. 在多轮对话中遵守流程
6. 看到低质量问题时先追问关键信息
7. 在工具调用前先判断是否需要调用

这些更像行为模式。

每次都可以用提示词提醒它。

但如果任务重复很多次，提醒会越来越长，成本会越来越高，稳定性也不一定好。

微调的意义，就是把一部分反复出现的任务习惯，变成模型更自然的倾向。

不是让模型背一本资料
而是让模型更像一个经过训练的人

---

8. 微调最适合什么

微调最适合稳定、重复、可评估的任务。

比如：

目标	为什么适合微调
客服消息分类	输入类型稳定，输出标签明确
固定格式摘要	样本容易构造，评估也比较清楚
行业话术风格	需要长期一致，不适合每次提示词堆很长
工具调用判断	可以用历史任务构造正负样本
多轮流程控制	需要稳定遵守步骤
文档问答的拒答习惯	查不到来源时不乱编，是一种行为约束

注意最后一条。

“查不到就拒答”看起来是 RAG 的问题，其实也可以通过微调增强。

因为 RAG 负责把资料拿来。

但模型拿到资料以后，是否能克制住不乱补，仍然是一种行为能力。

这也是为什么真实系统里，RAG 和微调经常不是二选一。

更常见的是：

RAG 负责外部知识
微调负责稳定行为
评估负责判断有没有真的变好

---

9. 微调不适合什么

微调最容易被误用的地方，是拿它记事实。

比如把公司所有文档、商品说明、价格表、政策手册都整理成训练集，然后希望模型以后都能记住。

听起来很诱人。

但这里有几个问题。

第一，模型不是数据库。

它可能记住大概倾向，却不能保证每个事实都准确。

第二，参数里的知识很难追溯。

很难要求模型回答：

这句话来自哪一份文档的哪一页？

第三，事实会变。

一旦资料更新，参数里的旧知识就可能和新现实冲突。

第四，训练会带来副作用。

表面上只是让模型记住文档，但它可能同时改变表达风格、拒答倾向和原有能力边界。

这也是上一篇评估体系反复强调的原因：

训练不是只会增加能力。

训练也可能改坏能力。

所以微调不是知识库的替代品。

它更像一场肌肉训练。

训练得好，会让动作更稳定。

训练错了，也会把坏动作练熟。

---

10. 一个选择框架

当无法判断该用 RAG 还是微调时，可以按下面四个问题拆开。

第一，答案会不会经常变化

如果会变，优先 RAG。

价格、政策、库存、排期、接口字段、课程安排、活动规则，都属于这一类。

变化越快，越不适合写进参数。

第二，回答需不需要出处

如果需要出处，优先 RAG。

比如合同、政策、医疗、财务、法律、内部流程、售后纠纷。

只要答案需要被追溯，就不要完全依赖模型记忆。

第三，这件事是不是一种稳定行为

如果是行为，考虑微调。

比如分类、摘要、结构化输出、话术风格、工具调用、任务分流。

这些东西不是“查到就会”，而是“练过才稳”。

第四，错了以后代价大不大

如果代价大，要做组合方案。

RAG 给来源，微调稳行为，规则做兜底，人工做验收。

不要把所有风险都压在一个模型回答上。

可以把判断画成这样：

flowchart TD
  A["遇到一个模型任务"] --> B{"需要最新事实吗"}
  B -->|"需要"| C["优先 RAG / 工具查询"]
  B -->|"不需要"| D{"需要稳定行为吗"}
  D -->|"需要"| E["提示词 / 微调 / 规则约束"]
  D -->|"不需要"| F["直接提示词可能够用"]
  C --> G{"是否需要固定输出或强约束"}
  G -->|"需要"| H["RAG + 微调 / 规则校验"]
  G -->|"不需要"| I["RAG + 引用来源"]
  E --> J{"是否涉及外部资料"}
  J -->|"涉及"| H
  J -->|"不涉及"| K["微调 + 评估集"]

这个图不复杂，但很有用。

因为它能防止一开始就陷入技术兴奋：

能不能训练？
能不能接知识库？
能不能做 Agent？

真正应该先问的是：

这个任务的错误来自哪里？
是资料缺失？
是行为不稳？
还是评估没做清楚？

---

11. 三个具体场景

只讲概念还是会飘。

可以看三个具体场景。

场景一：公司内部制度问答

用户问：

出差住宿标准是多少？
报销需要哪些材料？
超过预算怎么办？

这类问题明显适合 RAG。

因为制度会更新，也需要出处。

如果模型答错，员工可能真的按错流程走。

这里最重要的不是让模型“背制度”，而是让它：

1. 找到当前有效版本
2. 引用对应条款
3. 对不确定内容提示人工确认
4. 不要拿旧制度乱回答

如果还想做得更好，可以微调什么？

不是微调制度内容。

而是微调它的回答习惯：

先给结论
再列依据
最后提示例外情况

这就是 RAG 和微调的配合。

场景二：客服售后助手

用户发来一大段话：

我买的东西用了两天就坏了，客服一直不回，我现在很生气。

这里不只是查知识库。

模型要先判断：

1. 用户情绪
2. 商品问题
3. 是否涉及质量风险
4. 是否需要售后流程
5. 下一步应该问订单号还是先安抚

这些更像能力。

知识库可以告诉它售后政策。

但“先识别投诉风险，再选择回应方式”，这是行为训练。

所以客服场景通常是组合：

flowchart LR
  A["用户消息"] --> B["意图 / 情绪 / 风险识别"]
  B --> C["检索售后政策"]
  C --> D["生成回复草稿"]
  D --> E["规则检查"]
  E --> F{"是否高风险"}
  F -->|"是"| G["转人工"]
  F -->|"否"| H["发送或人工确认"]

这里 B 更适合通过样本、微调、分类器或规则来稳定。

C 更适合 RAG。

E 和 F 则是业务安全边界。

场景三：个人知识库写作助手

比如把个人文章、笔记、阅读记录、设备体验都放进知识库，希望模型辅助写新文章。

这里也不能只说“用 RAG”。

如果问题是：

之前如何评价这台显示器？

应该 RAG。

因为它需要查过去真实写过什么。

如果目标是让模型长期学会一种写作节奏：

不要太营销
先讲判断
再讲理由
最后讲适合谁和不适合谁

这更像微调或长期提示词规范。

更实际的做法是：

先用 RAG 找到过去的真实材料。

再用固定写作模板约束输出。

等样本足够多，且风格确实稳定，再考虑微调。

小团队和个人不要一开始就追求“训练一个完全懂自己的模型”。

先建立真实材料库，反而更重要。

---

12. 为什么很多人会选错

很多人选错，不是因为不懂技术，而是因为太想一步到位。

看到模型答错事实，就想微调。

看到模型格式不稳，就想接知识库。

看到系统效果不好，就想换更大的模型。

但真实问题可能只是：

1. 文档没有清洗
2. 检索切片太粗
3. 样本没有覆盖边界情况
4. 提示词没有说清拒答规则
5. 没有评估集
6. 没有旧能力回归测试
7. 没有人定义什么叫“答得好”

这也是为什么这个系列的顺序要这样排：

flowchart LR
  A["数据工程"] --> B["样本构造"]
  B --> C["LoRA / QLoRA"]
  C --> D["评估体系"]
  D --> E["RAG vs 微调"]

如果没有数据工程，资料可能是脏的。

如果没有样本构造，很难知道模型到底学什么。

如果没有低成本微调方法，就很难反复试。

如果没有评估体系，就不知道改完有没有变好。

到了 RAG vs 微调，问题才真正变成工程选择：

这个能力应该放在哪里？
这个知识应该怎么流动？
这个系统错了以后怎么查？

---

13. 小团队的现实路线

个人或小团队，更建议这个顺序：

先 RAG
再评估
再微调
最后再做复杂 Agent

原因很简单。

RAG 的第一阶段，成本比较低。

可以先把文档整理好，做出一个能查资料、能引用来源、能拒绝不确定问题的系统。

这一步做完，会立刻暴露很多真实问题：

1. 文档有没有缺口
2. 用户到底怎么问
3. 哪些问题经常查不到
4. 哪些回答需要固定结构
5. 哪些场景必须人工兜底

这些问题暴露出来以后，微调才有意义。

因为此时才更清楚要训练什么。

否则一开始就微调，很容易变成：

问题还没弄清
就先让模型认真学了一遍混乱

这会投入很多，却未必有效。

---

14. 一个更完整的组合方案

比较成熟的系统，通常不会只选 RAG 或只选微调。

它更像一个分工明确的小团队：

flowchart TD
  A["用户问题"] --> B["任务识别"]
  B --> C{"需要外部资料吗"}
  C -->|"需要"| D["RAG 检索资料"]
  C -->|"不需要"| E["直接任务处理"]
  D --> F{"资料是否足够可靠"}
  F -->|"可靠"| G["带来源生成回答"]
  F -->|"不可靠"| H["说明不确定 / 请求补充 / 转人工"]
  E --> I{"需要稳定格式或流程吗"}
  I -->|"需要"| J["微调能力 / 规则校验"]
  I -->|"不需要"| K["提示词处理"]
  G --> L["评估与日志"]
  H --> L
  J --> L
  K --> L
  L --> M["下一轮数据改进"]

这里每一层都有自己的责任：

层	负责什么
任务识别	判断用户到底要什么
RAG	找外部资料
微调	稳定行为模式
规则校验	防止格式、权限、风险出问题
人工兜底	处理高风险和不确定场景
评估日志	判断系统是否真的变好

这样设计，系统才不会把所有压力都丢给模型。

模型很强，但不应该一个人背锅。

---

15. 个人判断口诀

为了让这篇更好用，可以把判断压缩成几句话。

如果答案经常变：

放 RAG

如果答案需要出处：

放 RAG

如果是稳定格式、稳定流程、稳定风格：

考虑微调

如果既要查资料，又要稳定执行：

RAG + 微调 + 评估

如果还没评估，不知道哪里错：

先别急着训练

这几句话比很多架构图都重要。

因为它能帮助系统设计少走弯路。

---

16. 这篇的核心结论

1. RAG 和微调不是谁替代谁，而是解决不同问题
2. RAG 更适合变化快、需要追溯、需要权限隔离的知识
3. 微调更适合稳定、重复、可评估的行为和能力
4. 模型不是数据库，不要指望微调精确记住所有事实
5. 知识库不是训练集，不要指望 RAG 自动修好模型行为
6. RAG 的难点在召回、切片、排序、上下文组织和拒答
7. 微调的难点在样本质量、能力边界、评估和副作用
8. 小团队更适合先做 RAG 和评估，再决定要不要微调
9. 成熟系统往往是 RAG、微调、规则、人工兜底和评估的组合
10. 最重要的问题不是“用什么技术”，而是“错误来自资料缺失，还是能力不稳”

把这一篇和上一篇串起来，就能看到一个更完整的训练观：

训练不是为了让模型什么都记住
而是为了让系统在真实任务里更可靠

有些东西应该交给资料库。

有些东西应该交给模型能力。

有些东西必须交给规则和人工。

把它们分清楚，才是真正的工程能力。

---

下一篇预告

《推理与部署：模型能力如何稳定跑起来？》

下一篇会进入模型真正上线时的成本世界：

训练完、评估完、知识位置也想清楚了。

那模型怎么稳定地跑起来？

会拆开这些问题：

• 为什么推理成本和训练成本不是一回事
• 量化到底省了什么
• KV Cache 为什么会影响长对话成本
• 吞吐、并发、延迟分别是什么意思
• 小模型部署时怎么做取舍
• 为什么“能跑起来”和“能稳定服务用户”不是同一件事

核心观点是：模型能力只有被稳定、可控、可负担地跑起来，才真正进入产品世界。

持续学习，持续记录，持续筛选

如果这篇对你有用，可以继续沿着主题读下去。

福星家和会长期记录 AI 技术、生活成长、真实好物与正向文化观察。产品体验、人物故事、教育内容、生活方式、文化作品和内容共创都欢迎邮件沟通，合作内容会清楚标注。

继续读本系列 合作与交流