“做微调”与“做蒸馏”经常被放在同一张技术方案表里。两者确实都可能使用训练数据也都需要评测但项目目的和投入结构并不一样。微调重在让已有模型适应任务蒸馏重在把教师模型的特定能力迁移给学生模型。企业如果只看模型大小或训练轮数很难判断哪条路值得继续。微调和蒸馏到底差在哪里微调通常以一个已有的基础模型为起点通过任务样本调整它的参数让模型更稳定地完成分类、抽取、格式化或风格控制。训练数据可以来自人工标注也可以来自已经审核过的合成数据。模型大小未必因此发生明显变化。蒸馏需要一个教师模型和一个学生模型。教师可以是更强的闭源模型也可以是企业已有的大模型。团队先准备任务输入获取教师输出或其他允许使用的训练信号再检查数据质量最后训练学生模型。学生模型的规模、推理资源和部署位置通常会成为项目的重要约束。经典蒸馏会涉及教师的概率分布、logits 或中间表示普通文本接口是否提供这些信号要单独核对。很多企业项目采用的是教师生成回答、人工或规则筛选再训练学生的输出数据蒸馏路线。把两种路线混称会导致接口权限、训练方法和成本估算都出现偏差。先根据业务目标排除一部分方案如果企业只是希望输出格式更稳定已有小模型也能满足响应和部署要求微调通常更直接。它不需要先证明教师模型的能力可以迁移也不必为模型压缩承担额外工程工作。如果任务对知识新鲜度要求很高资料每天变化RAG 应该优先进入测试。蒸馏后的模型不会自动知道后来新增的内容除非重新生产数据和训练。把频繁变化的知识全部写进模型维护压力很快会超过预期。如果请求量长期存在任务边界清楚企业希望把稳定能力部署到资源受限的环境蒸馏的价值更明显。这里的目标通常包括减少单次推理资源、降低远程依赖或让一套模型覆盖多个固定任务最终目标要由业务和技术共同确定。用项目表记录每条路线的真实投入建议建立一张内部比较表至少记录以下内容。任务名称和输入范围当前大模型、人工或规则流程的基线微调所需的标注和训练工作蒸馏所需的教师调用、数据筛选和学生模型训练RAG 所需的资料处理、索引更新和检索评测目标部署环境及运维责任关键错误、人工复核和停止条件这张表的作用是把“模型效果好不好”变成一组可检查的问题。成本也要按一次性投入和持续投入分别记录。教师调用、人工复核、训练试验、评测回归和上线维护都可能影响最终结果。一个小试验可以先回答大部分疑问先从单一任务抽取经过授权的样本覆盖常见输入、长输入和历史失败输入。让当前方案、候选微调模型和候选蒸馏模型在同一批样本上运行。若任务依赖外部资料再加入 RAG 版本观察错误到底来自知识缺失还是模型行为。评测不要只看平均分。固定格式任务要检查字段缺失和非法输出客服任务要检查严重错误和升级比例知识问答要检查引用是否来自正确文档。结果还要放进目标环境里测一次离线成绩无法代表上线体验。如果需要同时调用多个教师模型147AI可以作为统一接入的候选平台参加比较帮助团队把模型选择、调用记录和样本结果放到同一流程中。它不能替代企业确定业务红线也不能从公开能力直接推导出某个蒸馏项目一定成功。选型结论要允许组合和撤回企业可以先用 RAG 解决资料更新用微调稳定输出再把其中高频且边界清晰的任务蒸馏到小模型。也可以先做微调试验确认任务稳定后再决定是否进入蒸馏。方案应保留回退路径复杂请求继续调用大模型学生模型出现异常时能切回原流程。技术资料对蒸馏的描述都强调教师和学生之间的任务迁移对微调的描述强调改变既有模型的行为对 RAG 的描述则强调在生成时检索外部内容。把这三种目的分开企业就能在成本、效果和维护工作之间做出更清楚的取舍。实际评审时还要把模型更新后的回归工作算进去。任何一条新数据进入训练集都可能影响旧任务。团队应保留一组长期不变的测试样本更新模型以后重新运行确认新能力没有破坏原来的格式、拒答和边界规则。这个动作很小却能避免上线以后才发现旧功能退化。