前几天我有个朋友问我：
“既然知识库已经能给模型提供资料了，为什么还要微调呢？还有，你现在用的模型是不是蒸馏出来的？”
这个问题其实挺有意思的，因为这代表了现在很多学习 AI 的人前期的一个普遍情况，就是把网上看到的几个 AI 热点词，拼成一个问题，但还没能理解他们之间的差别。
我记得好早之前网上关于 DeepSeek 模型是否蒸馏了OpenAI的讨论很热，知识库和微调也经常出现在各种文章、视频和群聊里。看得多了，这些词自然会被放进同一段对话。
就像我在 AI 群聊里也经常看到这样的场景：每天有人转发 AI 新闻，讨论新模型，复述几个热门概念，聊天很热闹，理解却未必更完整，就是试用一把，说这个好用那个不好用。
但是这和学习 AI，不是一码事。
前者是知道最近出了什么，后者则要弄清楚：它解决的到底是什么问题，和其他能力怎么配合，什么时候应该用，什么时候又不该用。
网上的 AI 知识还有一个更现实的问题：就是太分散。
今天讲 DeepSeek 的蒸馏，明天讲 RAG，后天讲 Agent。每篇内容可能都没有错，但它们之间往往没有上学时那种前后顺序。名词越积越多，知识之间的关系反而越来越模糊。
所以，我把朋友的提问拆成了三个更具体的问题：
- 模型不知道某件事，怎么办？
- 模型知道，但总是做不对，怎么办？
- 模型已经做对了，但太贵、太慢，怎么办？
接下来不再顺着热点背 RAG、SFT 和教师模型的定义，而是把这三个问题放进同一个电商售后客服系统里。这样看，知识库、微调和蒸馏分别改变了什么，也没有改变什么，会更清楚。
把三个问题放进一个电商客服系统
假设我们要做一个售后 Agent。它需要完成四件事：
- 回答最新的退货政策；
- 判断用户属于退款、换货还是物流咨询；
- 查询订单和库存；
- 涉及退款时，先经过审批再执行。
这四件事都可以被笼统地描述成“让模型更聪明”，但解决方法完全不同。
| 客服遇到的问题 | 真正缺的是什么 | 更适合的机制 |
|---|---|---|
| 退货政策昨天刚改，模型还在引用旧规则 | 最新资料 | 知识库 / RAG |
| 用户意图总分错，字段格式也不稳定 | 稳定的行为和输出习惯 | 微调 |
| 每天几十万条简单工单，调用大模型太贵 | 更低的推理成本 | 蒸馏小模型，或直接选合适的小模型 |
| 需要查订单、扣库存、执行退款 | 外部动作和权限 | 业务 API、规则和审批系统 |
所以，第一步先分清：问题发生在资料、行为、成本，还是权限这一层？
如果你正在做第一个 Agent，或者正准备把大模型接进客服、运营和内部系统，看完这篇文章，你应该能判断：什么内容该放进知识库，什么问题值得微调，什么时候应该让小模型学习大模型的做法。
一、知识库：模型临时需要查什么
先看第一个问题：退货政策改了，怎么办？
假设平台上午把“7 天无理由退货”改成了“30 天无理由退货”。如果我们把这条规则写进模型参数，等它真正学会可能已经过了很久；即使学会了，下一次政策变化还得重新训练，旧规则也不容易彻底移除。
更实际的做法是把政策放在知识库里。用户提问时，系统先从知识库检索相关片段，再把片段交给模型生成回答。这就是 RAG，也就是检索增强生成。
你可以把知识库理解成模型桌边的一本资料书：模型回答前先翻一遍，回答结束后，资料书本身不会变成模型的大脑。
知识库适合放：
- 产品手册和接口说明；
- 退货、报销、售后等经常更新的制度；
- 价格、库存和活动规则；
- 需要引用来源的 FAQ；
- 不同部门或不同用户权限对应的文档。
它主要解决的是：模型这一次应该参考哪些资料？
知识库不能自动把模型训练成分类器
假设你把一万条历史工单放进知识库，但你希望模型每次都严格输出：
{"category":"refund", "priority":"high", "next_action":"human_review"}
知识库可以让模型查到过去有哪些退款案例，却不能保证它每次都按同一套标签和格式输出。它提供的是回答上下文，不是稳定的行为训练。
同样，如果模型不会调用 get_order_status，问题也不一定是知识库缺少订单资料。可能是工具描述不清、参数 Schema 不完整、路由逻辑有问题，或者模型本身的工具调用能力不足。
所以，知识库不是“把资料塞进模型”，而是在运行时给模型补充可更新、可检索、可授权的上下文。
二、微调：模型知道任务，但还不会稳定地做
再看第二个问题：模型大概明白用户想退货，但意图经常分错，JSON 字段也总是写错。
这时缺的不是一份政策，而是一种稳定的工作习惯。
微调（Fine-tuning）是在已有预训练模型的基础上，用较小、较专门的数据继续训练，让模型更适应某项任务或某种表达方式。
例如，我们准备这样的样本：
用户：商品有划痕，我想退货。
期望输出：{"category":"return", "reason":"damage"}
再提供几千或几万条质量稳定的样本，模型会逐渐熟悉：
- 你的分类标签；
- 你的字段名称；
- 你的术语和表达；
- 你的输出格式；
- 哪些情况下应该转人工；
- 哪些工具应该调用、参数应该怎样组织。
你可以把微调理解成“岗位培训”。知识库是把资料放在桌上，微调是让模型形成更稳定的做事习惯。
微调适合什么问题？
- 固定的分类、抽取和改写任务；
- 稳定的 JSON 或 XML 输出；
- 企业内部的标签、术语和格式；
- 固定的回复风格和流程习惯；
- 有足够高质量示范的工具调用任务。
微调不适合什么问题？
如果问题是“模型不知道今天的库存”，不要先微调，直接查库存 API。库存会变化，应该由业务系统提供事实。
如果问题是“模型擅自退款”，也不能只靠微调。退款金额校验、权限、人工确认和审计必须放在应用层。
如果问题是“模型完全不会复杂推理”，仅仅增加格式样本也不一定有效。你可能需要更强的基础模型、规则引擎，或者可以被程序验证的训练任务。
微调可以改变模型参数，但它不是万能的知识更新器、权限系统或者计算器。
三、蒸馏：模型已经做对了，但运行成本太高
最后看第三个问题。
售后 Agent 已经能把工单分得很准，但每天要处理几十万条简单请求。每一条都调用旗舰模型，效果可能不错，成本和延迟却很难接受。
这时才有必要考虑蒸馏。
蒸馏通常采用“教师模型 + 学生模型”的方式：让能力更强的教师模型先处理大量样本，再让更小的学生模型学习教师的答案、分类、工具轨迹，甚至概率分布。知识蒸馏的经典工作，讨论的就是怎样把复杂模型中的能力迁移到更容易部署的模型中。
放回客服场景，可以这样做：
- 让大模型处理五万条历史工单；
- 抽查并修正其中一部分标签和答案；
- 形成意图、字段、工具调用和处理建议等示范数据；
- 让小模型学习这些示范；
- 用独立测试集比较小模型和大模型的任务完成率、错误率、延迟与成本。
如果学生模型在“识别意图、抽取订单号、输出固定 JSON”这些窄任务上已经够用，就可以把大量请求切到小模型，把大模型留给复杂问题。
这里有一个容易混淆的地方：蒸馏不是把模型文件压缩一下，也不等于量化。
蒸馏关注的是“能力从谁迁移给谁”；量化关注的是“怎样用更低精度表示参数”。两者可以同时使用，但解决的是不同问题。
另一个容易混淆的地方是：蒸馏和微调可以同时出现。教师模型生成示范，学生模型用 SFT 学习这些示范，这是一种常见的蒸馏实现。但“微调”说的是训练方式，“蒸馏”说的是教师和学生之间的能力迁移关系。
四、用一句人话区分三者
知识库，是把资料放在模型旁边，让它回答时随时能查。
微调，是把模型送去培训，让它更习惯按照你的方式做事。
蒸馏，是让一个更小、更便宜的模型，学习已经验证过的大模型做法。
换成电商客服，就是：
最新退货政策 -> 知识库 / RAG
固定意图和字段格式 -> 微调
大规模低成本处理 -> 蒸馏小模型
查订单和执行退款 -> 业务 API + 权限审批
这四类能力可以放进同一个系统，但不要把它们叫成同一件事。
五、最容易混淆的三组关系
知识库 vs 微调
| 对比项 | 知识库 | 微调 |
|---|---|---|
| 改变什么 | 运行时拿到的上下文 | 模型参数和行为倾向 |
| 资料怎么更新 | 更新文档、索引或数据源 | 重新准备数据并训练 |
| 更适合 | 会变化、要引用、要授权的事实 | 稳定、重复、可示范的行为 |
| 是否天然带来源 | 可以设计引用 | 不天然带来源 |
| 主要风险 | 检索不到、召回不准 | 数据质量差导致错误固化 |
一句话：知识库解决“查什么”，微调解决“怎么做”。
微调 vs 蒸馏
微调可以只用人工标注数据，也可以使用教师模型生成的数据；蒸馏则必须存在某种“教师能力向学生迁移”的关系。
所以：
- SFT、LoRA、QLoRA 等，描述的是怎么训练；
- 蒸馏，描述的是向谁学习、要迁移什么；
- 一个蒸馏项目通常还会使用某种微调方法训练学生模型。
一句话：微调是训练动作，蒸馏是能力迁移目标。
蒸馏 vs 直接换小模型
如果一个小模型本来就能完成你的任务，直接使用它最简单。只有当你需要把某个大模型已经验证过的行为迁移给小模型时，蒸馏才有明确价值。
蒸馏也不是“大模型变小后一定一样好”。学生模型可能丢失复杂推理、多轮上下文或边界判断能力，必须用真实测试集验证差距。
六、一个完整系统应该怎么组合
如果我来搭这套售后 Agent，可能会这样分工：
用户问题
↓
小模型：识别意图、抽取订单号
↓
知识库：检索最新退货政策
↓
业务 API：查询订单、库存和金额
↓
规则与审批：拦截高风险动作
↓
大模型或模板：生成最终回复
这里可能有一个经过蒸馏的小模型，也可能有一个经过微调的分类模型，但它们承担的角色不同：
- 知识库负责“给资料”；
- 微调负责“让行为更稳定”；
- 蒸馏负责“让已验证的能力以更低成本运行”；
- API、规则和审批负责“真正执行动作”。
如果用 Dify，可以把知识检索、模型节点、条件分支、API 工具和人工确认放进一条工作流。但是哈，Dify 的工作流和知识检索是编排能力，和微调或蒸馏没啥关系。
如果用 LangChain，也可以让小模型负责路由，把复杂问题交给大模型，再通过工具节点访问订单系统。框架负责把流程串起来，但该不该微调、是否值得蒸馏，仍然要根据真实任务的失败类型和成本数据决定。
七、什么时候需要哪一种，怎么组合？
可以先按下面的顺序判断：
- 资料会不会变？ 会变、要引用、要按权限访问，优先知识库或业务 API。
- 任务行为是否稳定？ 分类、抽取、格式和语气长期稳定，并且有高质量样本，再考虑微调。
- 调用量和成本是否已经成为问题？ 如果任务稳定、教师模型效果已经验证，再评估蒸馏小模型。
- 是否涉及外部动作？ 查订单、退款、删除和转账都要交给 API、规则、权限和审批系统。
- 改完以后怎么证明有效？ 用独立评估集比较准确率、任务完成率、错误率、延迟、Token 消耗和每次任务成本。
一个简单的判断表是：
| 你真正想解决的问题 | 优先考虑 |
|---|---|
| 模型不知道最新制度、价格或库存 | 知识库 / 业务 API |
| 模型知道内容，但输出总不稳定 | 微调，或先加强结构化输出和校验 |
| 大模型已经做对，但成本和延迟太高 | 蒸馏小模型，或重新评估模型路由 |
| 模型总是越权执行危险动作 | 权限、审批、审计和回滚 |
| 模型完全不会某类复杂推理 | 更强模型、规则引擎或可验证训练 |
