模型查资料、会做事、还省成本，分别靠什么？

前几天我有个朋友问我：

"既然知识库已经能给模型提供资料了，为什么还要微调呢？还有，你现在用的模型是不是蒸馏出来的？"

这个问题其实挺有意思的，因为这代表了现在很多学习 AI 的人前期的一个普遍情况，就是把网上看到的几个 AI 热点词，拼成一个问题，但还没能理解他们之间的差别。

我记得好早之前网上关于 DeepSeek 模型是否蒸馏了OpenAI的讨论很热，知识库和微调也经常出现在各种文章、视频和群聊里。看得多了，这些词自然会被放进同一段对话。

就像我在 AI 群聊里也经常看到这样的场景：每天有人转发 AI 新闻，讨论新模型，复述几个热门概念，聊天很热闹，理解却未必更完整，就是试用一把，说这个好用那个不好用。

但是这和学习 AI，不是一码事。

前者是知道最近出了什么，后者则要弄清楚：它解决的到底是什么问题，和其他能力怎么配合，什么时候应该用，什么时候又不该用。

网上的 AI 知识还有一个更现实的问题：就是太分散。

今天讲 DeepSeek 的蒸馏，明天讲 RAG，后天讲 Agent。每篇内容可能都没有错，但它们之间往往没有上学时那种前后顺序。名词越积越多，知识之间的关系反而越来越模糊。

所以，我把朋友的提问拆成了三个更具体的问题：

模型不知道某件事，怎么办？
模型知道，但总是做不对，怎么办？
模型已经做对了，但太贵、太慢，怎么办？

接下来不再顺着热点背 RAG、SFT 和教师模型的定义，而是把这三个问题放进同一个电商售后客服系统里。这样看，知识库、微调和蒸馏分别改变了什么，也没有改变什么，会更清楚。

把三个问题放进一个电商客服系统

假设我们要做一个售后 Agent。它需要完成四件事：

回答最新的退货政策；
判断用户属于退款、换货还是物流咨询；
查询订单和库存；
涉及退款时，先经过审批再执行。

这四件事都可以被笼统地描述成"让模型更聪明"，但解决方法完全不同。

客服遇到的问题	真正缺的是什么	更适合的机制
退货政策昨天刚改，模型还在引用旧规则	最新资料	知识库 / RAG
用户意图总分错，字段格式也不稳定	稳定的行为和输出习惯	微调
每天几十万条简单工单，调用大模型太贵	更低的推理成本	蒸馏小模型，或直接选合适的小模型
需要查订单、扣库存、执行退款	外部动作和权限	业务 API、规则和审批系统

所以，第一步先分清：问题发生在资料、行为、成本，还是权限这一层？

如果你正在做第一个 Agent，或者正准备把大模型接进客服、运营和内部系统，看完这篇文章，你应该能判断：什么内容该放进知识库，什么问题值得微调，什么时候应该让小模型学习大模型的做法。

一、知识库：模型临时需要查什么

先看第一个问题：退货政策改了，怎么办？

假设平台上午把"7 天无理由退货"改成了"30 天无理由退货"。如果我们把这条规则写进模型参数，等它真正学会可能已经过了很久；即使学会了，下一次政策变化还得重新训练，旧规则也不容易彻底移除。

更实际的做法是把政策放在知识库里。用户提问时，系统先从知识库检索相关片段，再把片段交给模型生成回答。这就是 RAG，也就是检索增强生成。

你可以把知识库理解成模型桌边的一本资料书：模型回答前先翻一遍，回答结束后，资料书本身不会变成模型的大脑。

知识库适合放：

产品手册和接口说明；
退货、报销、售后等经常更新的制度；
价格、库存和活动规则；
需要引用来源的 FAQ；
不同部门或不同用户权限对应的文档。

它主要解决的是：模型这一次应该参考哪些资料？

知识库不能自动把模型训练成分类器

假设你把一万条历史工单放进知识库，但你希望模型每次都严格输出：

json 复制代码

{"category":"refund", "priority":"high", "next_action":"human_review"}

知识库可以让模型查到过去有哪些退款案例，却不能保证它每次都按同一套标签和格式输出。它提供的是回答上下文，不是稳定的行为训练。

同样，如果模型不会调用 get_order_status，问题也不一定是知识库缺少订单资料。可能是工具描述不清、参数 Schema 不完整、路由逻辑有问题，或者模型本身的工具调用能力不足。

所以，知识库不是"把资料塞进模型"，而是在运行时给模型补充可更新、可检索、可授权的上下文。

二、微调：模型知道任务，但还不会稳定地做

再看第二个问题：模型大概明白用户想退货，但意图经常分错，JSON 字段也总是写错。

这时缺的不是一份政策，而是一种稳定的工作习惯。

微调（Fine-tuning）是在已有预训练模型的基础上，用较小、较专门的数据继续训练，让模型更适应某项任务或某种表达方式。

例如，我们准备这样的样本：

text 复制代码

用户：商品有划痕，我想退货。
期望输出：{"category":"return", "reason":"damage"}

再提供几千或几万条质量稳定的样本，模型会逐渐熟悉：

你的分类标签；
你的字段名称；
你的术语和表达；
你的输出格式；
哪些情况下应该转人工；
哪些工具应该调用、参数应该怎样组织。

你可以把微调理解成"岗位培训"。知识库是把资料放在桌上，微调是让模型形成更稳定的做事习惯。

微调适合什么问题？

固定的分类、抽取和改写任务；
稳定的 JSON 或 XML 输出；
企业内部的标签、术语和格式；
固定的回复风格和流程习惯；
有足够高质量示范的工具调用任务。

微调不适合什么问题？

如果问题是"模型不知道今天的库存"，不要先微调，直接查库存 API。库存会变化，应该由业务系统提供事实。

如果问题是"模型擅自退款"，也不能只靠微调。退款金额校验、权限、人工确认和审计必须放在应用层。

如果问题是"模型完全不会复杂推理"，仅仅增加格式样本也不一定有效。你可能需要更强的基础模型、规则引擎，或者可以被程序验证的训练任务。

微调可以改变模型参数，但它不是万能的知识更新器、权限系统或者计算器。

三、蒸馏：模型已经做对了，但运行成本太高

最后看第三个问题。

售后 Agent 已经能把工单分得很准，但每天要处理几十万条简单请求。每一条都调用旗舰模型，效果可能不错，成本和延迟却很难接受。

这时才有必要考虑蒸馏。

蒸馏通常采用"教师模型 + 学生模型"的方式：让能力更强的教师模型先处理大量样本，再让更小的学生模型学习教师的答案、分类、工具轨迹，甚至概率分布。知识蒸馏的经典工作，讨论的就是怎样把复杂模型中的能力迁移到更容易部署的模型中。

放回客服场景，可以这样做：

让大模型处理五万条历史工单；
抽查并修正其中一部分标签和答案；
形成意图、字段、工具调用和处理建议等示范数据；
让小模型学习这些示范；
用独立测试集比较小模型和大模型的任务完成率、错误率、延迟与成本。

如果学生模型在"识别意图、抽取订单号、输出固定 JSON"这些窄任务上已经够用，就可以把大量请求切到小模型，把大模型留给复杂问题。

这里有一个容易混淆的地方：蒸馏不是把模型文件压缩一下，也不等于量化。

蒸馏关注的是"能力从谁迁移给谁"；量化关注的是"怎样用更低精度表示参数"。两者可以同时使用，但解决的是不同问题。

另一个容易混淆的地方是：蒸馏和微调可以同时出现。教师模型生成示范，学生模型用 SFT 学习这些示范，这是一种常见的蒸馏实现。但"微调"说的是训练方式，"蒸馏"说的是教师和学生之间的能力迁移关系。

四、用一句人话区分三者

知识库，是把资料放在模型旁边，让它回答时随时能查。

微调，是把模型送去培训，让它更习惯按照你的方式做事。

蒸馏，是让一个更小、更便宜的模型，学习已经验证过的大模型做法。

换成电商客服，就是：

text 复制代码

最新退货政策       -> 知识库 / RAG
固定意图和字段格式 -> 微调
大规模低成本处理   -> 蒸馏小模型
查订单和执行退款   -> 业务 API + 权限审批

这四类能力可以放进同一个系统，但不要把它们叫成同一件事。

五、最容易混淆的三组关系

知识库 vs 微调

对比项	知识库	微调
改变什么	运行时拿到的上下文	模型参数和行为倾向
资料怎么更新	更新文档、索引或数据源	重新准备数据并训练
更适合	会变化、要引用、要授权的事实	稳定、重复、可示范的行为
是否天然带来源	可以设计引用	不天然带来源
主要风险	检索不到、召回不准	数据质量差导致错误固化

一句话：知识库解决"查什么"，微调解决"怎么做"。

微调 vs 蒸馏

微调可以只用人工标注数据，也可以使用教师模型生成的数据；蒸馏则必须存在某种"教师能力向学生迁移"的关系。

所以：

SFT、LoRA、QLoRA 等，描述的是怎么训练；
蒸馏，描述的是向谁学习、要迁移什么；
一个蒸馏项目通常还会使用某种微调方法训练学生模型。

一句话：微调是训练动作，蒸馏是能力迁移目标。

蒸馏 vs 直接换小模型

如果一个小模型本来就能完成你的任务，直接使用它最简单。只有当你需要把某个大模型已经验证过的行为迁移给小模型时，蒸馏才有明确价值。

蒸馏也不是"大模型变小后一定一样好"。学生模型可能丢失复杂推理、多轮上下文或边界判断能力，必须用真实测试集验证差距。

六、一个完整系统应该怎么组合

如果我来搭这套售后 Agent，可能会这样分工：

text 复制代码

用户问题
   ↓
小模型：识别意图、抽取订单号
   ↓
知识库：检索最新退货政策
   ↓
业务 API：查询订单、库存和金额
   ↓
规则与审批：拦截高风险动作
   ↓
大模型或模板：生成最终回复

这里可能有一个经过蒸馏的小模型，也可能有一个经过微调的分类模型，但它们承担的角色不同：

知识库负责"给资料"；
微调负责"让行为更稳定"；
蒸馏负责"让已验证的能力以更低成本运行"；
API、规则和审批负责"真正执行动作"。

如果用 Dify，可以把知识检索、模型节点、条件分支、API 工具和人工确认放进一条工作流。但是哈，Dify 的工作流和知识检索是编排能力，和微调或蒸馏没啥关系。

如果用 LangChain，也可以让小模型负责路由，把复杂问题交给大模型，再通过工具节点访问订单系统。框架负责把流程串起来，但该不该微调、是否值得蒸馏，仍然要根据真实任务的失败类型和成本数据决定。

七、什么时候需要哪一种，怎么组合？

可以先按下面的顺序判断：

资料会不会变？ 会变、要引用、要按权限访问，优先知识库或业务 API。
任务行为是否稳定？ 分类、抽取、格式和语气长期稳定，并且有高质量样本，再考虑微调。
调用量和成本是否已经成为问题？ 如果任务稳定、教师模型效果已经验证，再评估蒸馏小模型。
是否涉及外部动作？ 查订单、退款、删除和转账都要交给 API、规则、权限和审批系统。
改完以后怎么证明有效？ 用独立评估集比较准确率、任务完成率、错误率、延迟、Token 消耗和每次任务成本。

一个简单的判断表是：

你真正想解决的问题	优先考虑
模型不知道最新制度、价格或库存	知识库 / 业务 API
模型知道内容，但输出总不稳定	微调，或先加强结构化输出和校验
大模型已经做对，但成本和延迟太高	蒸馏小模型，或重新评估模型路由
模型总是越权执行危险动作	权限、审批、审计和回滚
模型完全不会某类复杂推理	更强模型、规则引擎或可验证训练