03. RAG、Memory、Fine-tuning 与 Distillation

聊到这里，通常会进入另一类困惑：

• RAG 到底是不是“过时技术”？
• memory、context、session summary 是不是一回事？
• fine-tuning 是不是就是后训练？
• distillation 和 fine-tuning 到底是什么关系？

这一篇把这些系统和训练概念放在一条线上看。

1. context、memory、session summary、RAG 分别是什么？

可以先用一句很粗但很好记的话区分：

context = 当前工作台
memory = 长期便签
session summary = 会议纪要
RAG = 去资料库找资料，再摆到工作台上

Context

上下文窗口是模型这次回答时“眼前能看到的所有东西”，包括：

• 当前问题
• 系统提示
• 历史消息
• 工具返回
• 检索结果
• 当前读到的文件

它是短期的、易失的，窗口满了就得压缩或丢弃一部分。

Memory

memory 是跨会话保留的少量稳定信息，比如：

• 用户偏好
• 项目规范
• 常用命令
• 常见坑

它不是整段聊天历史，而是“下次还值得带上的东西”。

Session Summary

会话摘要是为了省上下文，把已经发生过的一长段对话压成一份结构化摘要。它解决的是“窗口不够大”，不是“长期记住一切”。

RAG

RAG 是运行时去外部知识库检索相关内容，再把结果放进当前 context，让模型据此回答。

一个容易混淆的问题是：

RAG 是不是 memory 的一种？

更准确的理解是：

RAG 可以参与实现 memory，但 RAG 本身不等于 memory。

因为两者的关注点不一样：

• memory 关注“什么信息值得长期留下来”，比如用户偏好、项目规则、历史决策。
• RAG 关注“回答当前问题时，怎么从外部资料里把相关内容找回来”。

所以 memory 更像长期保存的笔记本，RAG 更像查笔记本、查文档、查数据库的方法。一个 AI 助手可以把 memory 存进数据库，再用类似 RAG 的方式按需取出来；但也可以用 RAG 去查公司文档、代码库、论文库，这些资料并不是用户记忆。

一个判断例子是：

如果 AI 助手记住了“我喜欢中文解释、偏好 first-principles、常用某个项目路径”，
这更像 memory，而不是 RAG。

因为这些信息的核心不是“从哪里被取出来”，而是它们会跨很多任务反复生效。RAG 也可以负责把这些信息检索出来，但那只是读取机制；真正被长期保留、代表用户偏好和工作习惯的内容，才是 memory。

另一个反向例子是：

如果用户问：“请根据我们公司最新的报销制度，判断这张发票能不能报销。”
AI 去公司知识库查制度文档，再根据查到的内容回答，
这更像 RAG，而不是 memory。

因为这里的重点不是“长期记住用户偏好”，而是“为当前问题找到权威资料”。公司制度可能会变，答案必须以最新文档为准；如果把这类信息硬塞进 memory，反而容易过期。

所以区分 memory 和 RAG 时，不要只问“是不是从外部存储里取出来”，而要问：

这是长期稳定、跨任务复用的个人/项目偏好？
还是当前问题需要临时查证的外部资料？

前者更偏 memory，后者更偏 RAG。

再看一个更完整的企业助手场景：

场景	更接近什么	原因
记住用户喜欢中文、偏好先讲原理、常用项目路径	memory	这是稳定的用户偏好和工作习惯，会跨任务反复生效。
回答报销、休假、绩效流程等公司制度问题	RAG	这些信息要以最新制度文档为准，适合运行时检索权威资料。
总结一次两小时会议并产出行动项	session summary	这是对当前会话或当前材料的压缩，不一定要长期保留。
帮用户改代码，读取当前 repo 文件、历史提交、测试输出	RAG + context	查 repo、提交历史更像 RAG；已经读入当前窗口的文件和测试输出则属于 context。
以后再遇到类似 bug，记住之前踩过的坑	memory	如果沉淀成“项目里长期有效的经验规则”，它就应该进入 memory。

这里有一个细节：很多真实系统不是三选一，而是组合使用。

RAG 负责把外部资料取进来；
context 负责承载这一次任务正在使用的信息；
session summary 负责压缩一段长过程；
memory 负责留下以后仍然有用的稳定经验。

所以一句话区分是：

memory 是把以后大概率还要用的规则和偏好留下来；
session summary 是把刚刚发生过的长对话压缩一下；
RAG 是在回答当下问题时，临时去外部知识库取资料补进 context。

2. RAG 现在还有人用吗？

有，而且仍然很重要。

更准确地说：

RAG 没死，只是升级了。

早期大家理解的 RAG 往往很粗糙，比如：

切块 + embedding + top-k 检索

现在实际系统更常见的是：

• retrieval + metadata filter
• 关键词和语义混合检索
• 引用和证据归因
• 工具调用、数据库查询、搜索 API
• reasoning model 对检索结果做整合和判断

所以今天很多系统表面上不天天喊 “RAG”，但底层仍然是：

retrieval-grounded generation

3. RAG / 搜索 / 工具调用，补的是知识还是推理？

更接近事实的回答是：

它们主要补的是知识、证据和外部能力，
不直接等于补了模型本身的推理能力；
但它们可以间接提高系统的推理效果。

更细一点地看：

• RAG / 搜索 主要补知识缺口
• 工具调用 除了补知识，还能补执行和验证能力
• 推理能力 决定模型会不会提对问题、取对信息、按对的方式使用这些信息

所以一句很好记的话是：

RAG 提供材料，工具提供手段，推理负责把它们变成答案。

4. fine-tuning 是什么？

fine-tuning 可以先理解成：

在一个已经预训练好的模型上，
再用更有针对性的数据继续训练，
让它更适合某类任务、领域或输出风格。

它更适合：

• 固定输出格式
• 特定语气风格
• 稳定的任务模式
• 用小模型替代大模型
• 减少每次都塞很多 few-shot 示例的成本

但它不适合拿来补最新事实。知识经常变的场景，通常更适合 RAG。

比如客服机器人经常答错售后政策、保修条款、退款流程时，第一反应通常应该是：

先接 RAG，而不是先 fine-tuning。

原因不只是 fine-tuning 需要重新训练模型，更重要的是这类信息有几个特点：

• 政策会变，模型一旦训进去就容易过期。
• 回答需要可追溯，最好能引用最新制度原文。
• 错误成本高，应该让答案依赖权威资料，而不是依赖模型记忆。
• 更新 RAG 知识库通常比重新训练和重新发布模型更快。

fine-tuning 在这个场景里也不是完全没用，但它解决的是另一类问题：

• 让客服回答更符合公司话术。
• 让输出格式更稳定。
• 让模型学会固定的工单分类方式。
• 让小模型更像大模型客服助手。

如果公司政策本身很稳定，但客服机器人总是输出格式不一致，比如有时不给工单分类，有时忘记按“问题摘要 / 判断依据 / 处理建议 / 风险提示”的结构回答，这就更适合 fine-tuning。

因为这类问题不是“缺资料”，而是“行为模式不稳定”。fine-tuning 适合让模型长期掌握一种稳定技能、格式或风格。

所以这类场景更合理的组合是：

RAG 负责最新政策和证据；
fine-tuning 负责稳定话术、格式和任务习惯。

一个很实用的判断是：

知识经常变 -> 优先 RAG
规则/风格长期稳定 -> 可以考虑 fine-tuning
只是想让它更听话 -> 先改 prompt
只是想记住你/项目 -> 用 memory

真实系统里经常会有人说：

回答质量不好，那就 prompt、RAG、memory、fine-tuning 全都做。

这个直觉可以理解，但工程上要先定位失败类型。因为这些方法不是同一层的开关：

• prompt 解决的是“这次该怎么做”的指令问题。
• RAG 解决的是“缺外部资料、缺最新证据”的问题。
• memory 解决的是“长期偏好和项目经验没有保留”的问题。
• fine-tuning 解决的是“稳定行为模式、格式、风格、任务习惯没有学牢”的问题。
• distillation 解决的是“想把强模型的行为迁移给更小、更便宜、更快的模型”的问题。

所以更好的判断顺序是：

先看错误来自哪里，再选最便宜、最可控的修复手段。

5. post-training 和 fine-tuning 是什么关系？

一句话先说：

post-training 是大伞；
fine-tuning 是其中一种常见方式。

post-training 指的是模型在预训练之后，为了提升可用性、安全性、对齐性、推理表现和任务能力而进行的一系列训练。

里面通常会包括：

• instruction tuning / SFT
• preference tuning
• RLHF / RLAIF
• safety tuning
• tool-use training
• reasoning-oriented tuning
• distillation

所以更准确的说法是：

post-training 是预训练后的总加工阶段，
fine-tuning 是其中一种定向加工方式。

6. distillation 是什么？

distillation 的核心是：

让一个较小或较便宜的 student model，
去学习较强 teacher model 的行为。

teacher 可以提供：

• 最终答案
• 中间步骤
• 偏好排序
• 工具使用方式
• 推理轨迹

所以 distillation 更像是一种：

“老师带学生”的训练策略

而 fine-tuning 更像是一种：

“继续训练”的动作

更工程化地说，distillation 通常是：

用一个更强、更贵、更慢的 teacher model 产生高质量示例，
再用这些示例训练一个更小、更便宜、更快的 student model。

比如一个公司发现大模型客服效果很好，但线上成本太高，就可以让大模型先生成大量高质量客服回答、分类结果、处理步骤或工具调用轨迹，再拿这些数据训练一个小模型。上线时，小模型不一定和老师一样强，但它可能足够便宜、足够快、效果也接近可用水平。

所以 distillation 解决的不是“知识库怎么更新”，而是：

怎么把一个强模型的能力，压缩到一个更适合部署的模型里。

所以一句很好记的话是：

post-training 是“什么时候训”，
fine-tuning 是“怎么继续训”，
distillation 是“跟谁学”。

7. 为什么推理能力很难被完整蒸馏？

蒸馏有时能把推理能力传下去，有时又传不完整，核心原因通常不是老师会不会说，而是学生有没有足够容量去承载这种能力。

更准确地说：

蒸馏更容易复制老师的外部表现，
不一定能完整复制老师的内部能力结构。

原因通常包括：

• student 模型容量有限
• 推理是长链条能力，压缩损失更大
• 蒸馏到的往往是“表现”，不一定是“机制”
• teacher 数据质量不稳定时，student 也会学偏
• student 容易学到局部模式模仿，难以学到更深层的可迁移结构

一句很好记的总结是：

蒸馏更容易传下“解题样子”，更难传下“解题上限”。

8. 现在发布新模型，是不是基模不变，只做 fine-tuning？

不能一概而论。

更接近事实的说法是：

“全新一代模型”通常不是只做 fine-tuning；
“同一家族的某些变体”有时更像是在已有基础上继续做 post-training、蒸馏、推理强化或产品化封装。

所以把所有新模型都理解成“只是 fine-tuning 一下”是过度简化。

更合理的理解是：

• 有些发布是新 base model + 新 post-training 一起升级
• 有些发布更像是在现有家族上做衍生版本

小结

这一篇最重要的几句话是：

• context 是当前工作台，memory 是长期便签，session summary 是压缩后的会议纪要，RAG 是运行时去拿资料。
• RAG 主要补知识和证据，不直接等于提升模型本体推理，但能显著提高系统表现。
• fine-tuning 更适合固化行为模式，不适合补持续变化的最新知识。
• post-training 是大伞，fine-tuning 是一种继续训练方式，distillation 是一种老师带学生的训练策略。
• 蒸馏更容易传下“解题样子”，更难传下“解题上限”。

如果你想先看一篇浓缩总览，可以回到 AI 推理入门：从 token 生成到 reasoning model、RAG 与 Agent。