模型名没变，教师已经变了：蒸馏数据如何应对 DeepSeek Flash 版本漂移

最容易被忽略的模型更新，不一定是改了一个新名字的版本。

DeepSeek 在 10 月 17 日的官方更新日志中说明，deepseek-flash 已由 DeepSeek-V4.1-Flash-1017 提供服务，调用方式和价格保持不变。官方同时列出了多项基准成绩变化，并称任务运行时间和输出长度缩短。

从调用代码看，项目似乎什么都没有变；从蒸馏数据看，教师却可能已经换了一套行为。旧教师生成的答案、工具选择和拒答方式，未必仍然代表现在要模仿的目标。

这不是说新版本一定更适合所有任务，也不是说 DeepSeek 本次更新就是通过蒸馏完成的。它更适合作为一个版本管理问题来处理：如果服务端模型发生变化，蒸馏项目怎样知道自己拿到的教师数据来自哪个状态？

先把模型名和服务版本分开

训练记录中常见的一列是 model，例如 deepseek-flash。它适合记录调用时填写的名称，却不一定能说明当时真正提供回答的具体版本。

如果只保留这一列，几个月后的数据审查会遇到麻烦：同一个名称下可能经历过后训练、路由、系统提示词、工具适配或服务端配置变化。文章不需要猜测这些变化是否发生在某一次调用中，但项目应该允许自己记录和核对它们。

至少可以把以下信息分开保存：调用时的模型名、服务返回的版本标识（如果接口提供）、请求时间、接口区域或端点、系统指令版本、工具定义版本、采样参数、输入资料版本和输出快照。

这些字段不是为了把日志堆得越满越好。它们要回答一个具体问题：这条教师答案，是在什么条件下产生的？如果某个字段拿不到，就标记未知，不要用调用名称假装已经完成版本追踪。

版本漂移会改变哪些训练信号

第一类变化是答案风格。官方本次更新提到输出长度缩短。短答案可能代表模型更有效率，也可能只是表达策略发生了变化。对于需要学习结构化解释的学生，少掉的内容可能正好包括条件、例外或验证步骤。

第二类变化是工具行为。相同问题可能触发不同的搜索、代码执行或文件读取动作。蒸馏时如果只存最终回复，项目很难判断学生学到的是正确的工具选择，还是碰巧得到了一个看似合理的结论。

第三类变化是错误分布。某个版本在常见问题上变好，不代表它在边界输入、长任务和工具失败时都变好。若把新旧版本样本混在一起，却不记录来源，学生最终学到的可能是互相冲突的拒答、格式和处理顺序。

一个可执行的迁移流程

第一步，冻结旧数据的快照。不要在原文件上直接改模型名，也不要把后来重新生成的答案覆盖旧答案。旧数据的价值之一，就是它可以帮助定位行为变化。

第二步，用一小组固定任务分别请求旧教师和新教师。任务不必很多，但要覆盖正常输入、缺资料、工具报错、格式约束和需要拒答的边界。比较时同时看最终答案和可观察的工具轨迹。

第三步，把差异分成三类：新版本明确改善的行为、只是表达变化的行为、尚未判断优劣的行为。第三类不要急着写入正向训练集，可以先放入待审区。

第四步，建立独立回归集。回归任务不能只是训练样本换几个同义词，而要包含没有参与教师生成和提示词调试的新输入。否则“新版本更好”可能只是样本泄漏后的印象。

第五步，再决定是否续训。若差异只涉及格式或输出长度，可能先调整解析和评测；若差异涉及工具边界、事实条件或安全行为，则需要重新审核数据，甚至重做一部分训练。

不要把基准提升直接换算成学生收益

官方更新日志列出了多个基准数字，这是版本发布的重要信息，但它们不能直接证明某个企业任务会提升同样幅度。基准的任务、框架、参数和评测方式都有条件。

同样，教师输出变短也不能直接当作蒸馏成本下降。训练数据整理、核验、独立测试和版本维护仍然需要成本。真正要观察的是学生在新任务上的正确行为、错误类型和人工返工量。

一个版本管理做得好的蒸馏项目，应该能回答三件事：这条样本来自哪个教师状态；它为什么被判定为合格；学生在没有见过的新任务上是否保留了目标能力。模型名不变，只说明调用入口没有变，不能替项目完成这三项工作。

资料：DeepSeek API 更新日志。本文的版本记录、迁移流程和测试设计是方法建议，不代表 DeepSeek 公开了其内部训练流程。