那些在评估集中遗漏、却在模型蒸馏中丢失的能力

一个团队将一个 200B 的教师模型压缩成一个 7B 的学生模型，因为评估套件——包含五万个覆盖产品发布时所有功能的样本——显示学生模型仅落后教师模型不到两个点，且推理成本降低了一个数量级。迁移上线了。成本曲线下降。客户满意度曲线持平。三周后，客服开始看到一类团队无法在评估中复现的故障。

学生模型不再识别教师模型曾默默处理的边缘案例输入格式。它不再能从教师模型曾可靠消除歧义的特定模糊指令中恢复。它不再产生那种罕见但关键的“与其猜测不如询问澄清问题”的行为——因为评估集以这些提示词是“坏数据”为由，清除了其中的模糊提示词。

评估结果显示蒸馏是忠实的。评估对于“忠实性”的定义是错误的。

蒸馏压缩了评估衡量的部分，并丢弃了其他所有内容

大多数团队对蒸馏的心理模型是“制作一个做同样事情的小型模型”。实际过程更为狭隘：在有限的输入样本上最小化学生模型与教师模型之间的分歧，然后通过有限的评估进行验证。任何样本未涵盖的内容以及评估未测试的内容，从优化器的角度来看，都是自由熵。学生模型可以自由地丢弃它。大多数情况下它确实会这么做。

这不是某种特定蒸馏技术的缺陷。这就是压缩的本质。知识蒸馏必须考虑它失去了什么，而不仅仅是学生模型在主要指标上保留了什么。最近的行业调查明确指出了这一点：学生模型可以在保住教师模型核心分数的同时，丢失那些让教师模型变得可靠的行为。风险最高的能力正是那些在你评估中基础率（base rate）最低的能力——而这些最低基础率的能力往往与最终出故障时用户面临的最高成本相关联。

在实践中，“最低基础率”是什么样的？以下是由于触发频率太低而从评估平均值中消失的行为简表（并不完整）：

• 校准后的放弃（Calibrated abstention）。教师模型在 3% 的输入上说“我不知道”，且通常这种判断是正确的。学生模型在 0% 的情况下这么说，而是开始胡编乱造。平均准确率波动不到一个百分点，但信任感崩塌了。
• 格式鲁棒性。用户粘贴了一个带有尾随逗号的错误 JSON 格式，或者一个你的评估从未采样过的地区格式日期字符串。教师模型解析了它，学生模型则拒绝了整个请求。
• 澄清性问题。现实世界中的模糊指令很常见；但在评估中，它们被当作噪声过滤掉了。在过滤后的分布上训练的学生模型会挑选出最可能的意图并直接执行。
• 多步计划修复。当工具调用在任务执行一半失败时，教师模型会修改计划。学生模型则会第二次发出相同的计划，并等待再次被告知失败。
• 针对对抗性输入的拒绝校准。教师模型拒绝了越狱攻击，同时没有过度拒绝良性的边缘案例。学生模型继承了其中一半的状态，却丢了另一半。

这些行为中的每一项，其在任何现实评估中的频率都低到无法影响核心数字，但其失败时的重要性却足以定义产品的体验感。

评估套件是合同的一个样本；蒸馏是对该样本的忠实

一个常见的组织故事：AI 团队将评估视为合同，产品团队也将评估视为合同，由于评估达标，蒸馏被判定为忠实。在评估所描述的世界里，这一切都没有错。错误在于那个潜移默化的假设：即评估描述了合同。

事实并非如此。即使是五万个样本的评估也只是开放行为空间的一个样本。一个基于线上生产流量构建的样本会反映出教师模型已经处理得很好的事情——因为这些是产品目前看到的请求——同时低估了那些教师模型本来可以处理得很好，但产品尚未要求它处理的事情。你的评估偏向于教师模型的强项，就像你的客户群一样。针对该评估优化的蒸馏会继承这种偏见并忘记其余部分。

有一种更尖锐的表达方式：评估是对一组有限测试点的前向测量。部署后的系统会遇到一组无限的真实输入，这些输入与测试点相关但并不相同。这两个集合之间的差距就是能力消失的鸿沟。根据定义，这个差距在评估内部是不可见的。

行为覆盖是你缺失的审计

弥补差距并不意味着放弃聚合评估——这些评估仍然能捕捉到蒸馏破坏了某些显而易见功能的情况——但它确实意味着要增加一个审计层，来对评估本身进行评分，而不仅仅是针对模型。

能力覆盖审计提出了一个与准确率评估不同的问题。它问的是：教师模型展示的行为空间是什么，而评估实际上行使了该空间的多少比例？审计大致分为四个步骤。

首先，从外部枚举教师模型的行为类别。这不只是“模型执行什么任务”——那是你已经拥有的评估覆盖范围。它是“模型在执行任务的过程中做了哪些让用户受益的事”：放弃、澄清、拒绝、恢复、重新计划、偏好某种格式、校准信心、基于检索到的上下文进行论证。每个类别都成为覆盖矩阵中的一行。

第二，针对矩阵对现有评估进行评分。对于每个行为类别，统计有多少评估项专门针对它进行测试——不是有多少项碰巧触发了它，而是如果该行为改变，有多少项的得分会随之改变。大多数团队会发现，他们的评估在三四个类别上有实质性的覆盖，而在其他十几个类别上几乎没有覆盖。这十几个类别并不冷门，它们只是评估设计时未曾围绕其构建的部分。

第三，为未覆盖的类别构建对抗性探针。刻意加入模糊的提示词（衡量澄清能力）、分布外格式（衡量鲁棒性）、部分失败的工具序列（衡量恢复能力）、正确答案是“我不知道”的提示词（衡量放弃能力），以及那些曾因被视为噪声而被评估集清除的提示词。对抗性评估套件的意义在于精准地引出生产环境中会出现而核心评估会忽略的输入。如果你的评估套件从未引出触发故障的输入，那么你不是在测试你的系统——你是在测试你对系统的假设。

第四，在相同的真实流量样本上运行教师和学生之间的行为差异分析（Behavior diff）。按行为类别而不是准确率增量来对分歧进行聚类。这是大多数团队跳过的部分，因为它需要教师模型的推理在采样量级上保持可用——但替代方案是让学生模型在丢失了某些行为的情况下盲目上线。

将行为覆盖率损失视为发布门槛

发布前仅运行一次的覆盖率审计只是一种表演。只有当行为矩阵成为每个蒸馏出的后续模型的发布门槛（release gate）时，它才能发挥作用。

实际操作形式很简单。维护一个小规模的数据集——几百个示例就足够了——包含“教师模型能做但核心评估（headline eval）未衡量的行为”。每个示例都打上其训练的行为类别和预期行为的标签，而不是预期的精确答案。每个候选的后续模型——无论是经过蒸馏、微调、重新训练，还是仅仅是一个新的检查点（checkpoint）——都要独立于核心评估，对照这个数据集进行评分。任何行为类别的回归（regression）都会阻止部署，直到该行为被修复，或者团队做出记录在案的决定，选择舍弃该行为。

这听起来很繁重，但事实并非如此。这个数据集之所以小，正是因为每一项都在代表核心评估原本会忽略的一类行为。成本主要集中在构建阶段；后续的持续评分成本很低。这样做的好处是，“我们运行了蒸馏且数据看起来不错”不再是一个团队在对数据未涵盖的情况一无所知时所能做出的发布决策。

在此基础上，还值得增加一个低调的规范：在筛选评估套件时，记录哪些内容被剔除以及原因。被标记为“噪声”、“超出范围”、“模棱两可”或“不良数据”而移除的条目，恰恰是最有可能代表核心评估无法衡量且蒸馏模型无法习得的行为。保留下来的剔除队列（scrub queue）会成为能力探测的一个免费来源——这些条目是团队已经注意到在行为上很有趣，却又选择遗忘的内容。

成本框架是不对称的，而这正是真正的陷阱

成功的蒸馏所带来的成本图表是立竿见影的，并会直接显示在仪表盘上。而失败的蒸馏所产生的成本图表则散落在支持工单、用户流失、产品信任度侵蚀，以及团队最终不得不重新添加到另一个模型中的各项能力中。前者在季度评估中清晰可见；后者则直到积累到足够多，以至于有人注意到用户流失的模式或投诉量的激增，并将其追溯到那个在仪表盘上看起来很完美的部署时，才变得清晰。

这种不对称性正是让能力损失成为一种持久失效模式的原因。节省的成本体现在模型所有者的成绩单上；而产生的代价则体现在其他人的账单上。负责蒸馏的团队通常并不负责那些因丢失行为而导致失败的产品界面。当失败汇聚成可识别的信号时，部署已经过去数月，而下一次蒸馏已经在计划中。如果没有覆盖率审计和行为类别发布门槛，下一次蒸馏将失去另一种不同的能力——之所以不同，是因为它取决于新评估中代表性不足的行为——于是循环往复。

在这一切的背后，隐藏着一个合理的架构决策：评估套件是对无限行为空间的有限测量，而一个在评估中获得高分的蒸馏模型，并不能保证它在评估未提及的行为上也表现一致。那些在压缩前没有衡量能力覆盖率的团队，得到的并不是一个能完成相同任务的小型模型。他们得到的是一个仅能完成测试任务的小型模型，并且可能将最实用的行为遗留在了教师模型中。

如果这是一种有意的权衡，那也没问题。但如果根本没人意识到这是一种权衡，那它就是一个糟糕的决策。