AI蒸馏：蒸馏后的Skill散落一地，员工遇到复杂问题不知道调哪几个、先后顺序是什么，碎片怎么串成项链？

一、导语：从“会做题”到“会做事”的断裂

过去两年，蒸馏在企业侧的典型叙事是“降本增效”：用一个大模型（Teacher）生成数据或提供软标签，训练一个参数量小一个数量级的学生模型（Student），在保持大部分任务指标的同时，把推理成本压到可接受区间。Hinton 等人在 2015 年系统化的软标签蒸馏框架，以及后续的序列级蒸馏、特征级蒸馏、自蒸馏等变体，构成了这条技术路线的基础^[1]。从纯指标看，这条路是成立的：在分类、抽取、单轮问答等“单点任务”上，学生模型往往能逼近教师模型 90% 以上的表现。

但工程现场给出的反馈更复杂。某类典型抱怨是：蒸馏后的小模型“单看每个能力都在”，可一旦任务需要串联多个步骤——先检索、再比对、再计算、最后按格式输出——它就开始出错，或者干脆只做第一步就停下。员工侧的体感则是另一种表述：系统里散落着一堆“技能”，遇到复杂问题不知道该调哪几个、先后顺序是什么。这两个抱怨指向同一个结构性问题：蒸馏保住了“点”，却丢了“线”。

笔者认为，把这一现象简单归因为“小模型能力不足”是偷懒的。能力不足解释的是“单点做不对”，而现场抱怨的核心是“组合做不成”。组合失败有其独立成因，需要独立的分析框架。本文的主线因此定为：蒸馏的首要损失是技能之间的拓扑结构（调用顺序、依赖关系、触发条件、失败回退），而非知识条目本身。围绕这条主线，后文将依次回答三个问题：拓扑为什么丢、拓扑怎么找回来、找回来之后怎么验证它真的有用。

二、背景与问题定义：什么是被蒸馏掉的“技能拓扑”

2.1 蒸馏的三种主流形态与各自的“保真对象”

要讨论“丢了什么”，先要明确蒸馏“想保什么”。业界常用的分类是：响应级蒸馏（response-based，对齐输出分布或序列）、特征级蒸馏（feature-based，对齐中间层表示）、关系级蒸馏（relation-based，对齐样本间或层间的关系结构）。三者保真的对象依次从“答案”深入到“内部表征”，再到“结构关系”。

本文评述：关系级蒸馏在概念上最接近“保拓扑”，但现有工作多对齐的是样本相似度矩阵或层间相关性，而非“任务步骤之间的依赖图”。换言之，学术界已经在“关系”层面做了大量工作，却很少把“技能调用顺序”显式建模为蒸馏目标。这正是工程侧碎片化体感的学术空白所在。

2.2 “技能拓扑”的操作性定义

为避免空谈，本文给出一个可操作的定义。把模型在完成任务时可被独立触发的行为单元称为 Skill，记作集合 S = {s₁, s₂, …, sₙ}。技能拓扑 T 是定义在 S 上的一个有向图，边 (sᵢ → sⱼ) 表示“在任务语境下，sᵢ 的输出是 sⱼ 的合法输入或前置条件”。拓扑还附带两类属性：触发条件（什么输入该激活 sᵢ）与失败回退（sᵢ 失败时转向哪个节点或终止）。

这个定义的价值在于可检验：给定一段任务轨迹，我们可以标注它实际走过的节点序列，从而把“拓扑是否完整”转化为“实际轨迹能否被图中的路径覆盖”这一可度量问题。后文的评测设计将直接使用这一转化。

2.3 问题边界：碎片化不等于能力缺失

需要强调，碎片化与能力缺失是两类问题。能力缺失表现为单点指标下降，通常可通过增加蒸馏数据、调整温度、引入中间层监督缓解；碎片化则表现为单点指标正常、组合指标骤降。二者的诊断方法与修复手段不同，混为一谈会导致“加数据—指标不涨—继续加数据”的低效循环。工程上应先做一次“单点 vs 组合”的对照评测，确认问题类型，再决定投入方向。

三、机理剖析：碎片化是怎么发生的

3.1 数据侧：轨迹被切成了样本

当前主流的蒸馏数据构造方式是“指令—回答”对：把教师模型的一次完整输出作为一个训练样本。对于多步任务，这意味着一整条轨迹被压平成一个输入输出对。学生模型学到的是“给定这个输入，输出这段文本”的映射，而不是“先做 A、再做 B、若 C 失败则回退到 D”的过程结构。序列级蒸馏（如 Kim & Rush 的序列级知识蒸馏^[2]）虽然对齐了整段输出分布，但对齐的仍是“文本形态”，不是“决策结构”。

笔者认为，这是碎片化最直接的来源：训练信号的粒度决定了学到的结构粒度。样本是平的，学到的就是平的。要让学生模型学到拓扑，训练信号本身必须携带拓扑信息，例如步骤边界标记、中间状态、分支与回退示例。

3.2 容量侧：参数压缩对“连接”的挤出效应

从表示学习角度看，技能之间的依赖关系需要模型在隐空间中维持一定的“连接结构”。参数压缩会优先保留高频、高收益的单点能力，而挤压低频的组合连接。这与持续学习中的灾难性遗忘有相似之处：新任务训练会覆盖旧任务的表征，组合能力往往比单点能力更脆弱，因为它依赖更多参数的协同。相关研究在模型剪枝与蒸馏的交互上已有讨论^[3]，但多数工作关注的是单点指标保持，对组合指标的退化缺乏系统测量。

本文评述：把碎片化完全归因于容量并不准确。容量是约束条件，不是充分原因。同样的参数量下，训练信号若携带结构信息，组合表现可以显著改善——这一点在后文的工程路径中会给出可操作的验证方式。

3.3 目标侧：损失函数里没有“顺序”这一项

标准蒸馏损失是输出分布对齐（KL 散度）与任务损失的加权和。这个目标对“输出内容”敏感，对“输出顺序”不敏感：只要最终答案对，中间步骤顺序错了也可能拿到低损失。对于需要严格顺序的任务（如先校验再写入），这种目标设计天然不鼓励模型维持顺序约束。近期一些工作尝试引入过程监督或步骤级奖励^[4]，方向上是对的，但在蒸馏场景下的系统化落地仍不充分。

3.4 一个可检验的因果链

综合以上三点，可以给出一条可检验的因果链：训练信号粒度粗 → 模型未学到步骤边界与依赖 → 组合任务中触发条件模糊、顺序错乱 → 现场表现为“不知道调哪几个、先后顺序是什么”。这条链的每一环都可以设计对照实验验证，例如在数据中加入步骤标记后观察组合指标是否提升。工程团队应把它当作假设来验证，而不是当作结论来接受。

四、工程路径：把碎片串成项链的四步法

下面给出一条从现状出发、可逐步落地的路径。四步分别是：能力盘点、依赖建模、编排路由、评测闭环。每一步都给出输入、产出与验收标准，便于团队按里程碑推进。

4.1 第一步：能力盘点——把“散落的 Skill”显式化

输入是现有的蒸馏模型与业务任务清单。做法是从真实任务日志中抽取任务轨迹，人工或半自动标注出可复用的行为单元，形成 Skill 清单。每条 Skill 记录四个字段：名称、触发条件、输入输出契约、典型失败模式。产出是一份可评审的 Skill 目录。

验收标准：随机抽取 50 条历史任务，至少 80% 能被目录中的 Skill 覆盖（允许组合）。覆盖率不足说明盘点粒度太粗或任务分布未覆盖，需要回到日志抽样环节。这一步看似朴素，却是后续所有工作的地基——没有显式的 Skill 清单，依赖建模无从谈起。

4.2 第二步：依赖建模——把 Skill 连成有向图

输入是 Skill 目录与任务轨迹。做法分两路：一路是数据驱动，从轨迹中统计 Skill 的共现与先后频次，得到候选边；另一路是专家驱动，由业务方补充“必须满足的前置条件”与“失败回退”。两路结果合并后形成技能依赖图。对于边权，可用条件概率近似：P(sⱼ 紧随 sᵢ | sᵢ 被触发)。

这里可以借用软件工程中的依赖管理思想：把 Skill 当作函数，把契约当作类型签名，把依赖图当作调用图。区别在于，模型的 Skill 边界是模糊的，因此图中应允许“软边”——即概率性依赖，而非硬编码调用。

# 依赖边统计的伪代码（示意）
edges = {}
for traj in trajectories:
    skills = annotate(traj)          # 标注出的 Skill 序列
    for a, b in zip(skills, skills[1:]):
        edges[(a, b)] = edges.get((a, b), 0) + 1
# 归一化为条件概率，过滤低频噪声边
graph = normalize(edges, threshold=0.05)

验收标准：依赖图能复现历史轨迹中 70% 以上的合法路径；图中不存在明显的环（若存在，说明 Skill 粒度需要拆分）。

4.3 第三步：编排路由——让模型“知道调哪几个、什么顺序”

有了图，下一步是让运行时真正用上它。常见做法有三种，适用场景不同：

笔者认为，工程上最稳妥的起点是“外置编排器 + 单点模型”的组合：把顺序控制从模型里拿出来，交给确定性代码，模型只负责它最擅长的单点执行。这与当前 Agent 工程中“规划与执行分离”的思路一致^[5]。待轨迹数据积累充分后，再引入学习式路由做泛化。

4.4 第四步：评测闭环——用组合指标验收，而不是单点指标

评测必须同时覆盖单点与组合。单点指标沿用原有任务指标；组合指标建议至少包含三项：路径覆盖率（实际执行路径被依赖图覆盖的比例）、顺序正确率（关键步骤顺序符合约束的比例）、回退成功率（注入失败后能正确回退的比例）。三项指标应作为发布门槛的一部分，与单点指标并列。

验收标准示例（模拟数据，仅示意阈值设定方法）：路径覆盖率 ≥ 85%，顺序正确率 ≥ 90%，回退成功率 ≥ 75%。阈值应基于基线测量后设定，不宜直接照搬。

五、关键数据与案例

5.1 公开研究中的相关证据

公开文献中，直接测量“蒸馏后组合能力退化”的工作并不多，但有几条间接证据值得关注。其一，多步推理基准上的蒸馏研究普遍报告：学生模型在单步子任务上的准确率与教师差距较小，而在需要多步串联的任务上差距明显放大^[6]。其二，过程监督相关研究表明，仅对最终答案做监督时，模型学到的中间步骤质量显著低于对过程做监督的版本^[7]。其三，工具调用类基准显示，模型在“选对工具”与“按正确顺序调用多个工具”之间存在明显的能力落差^[8]。

本文评述：这些证据方向一致，但都不是为“技能拓扑”这一概念量身设计的实验。因此本文不把它们当作直接证明，而是当作支持性证据。工程团队若要用于内部立项，建议自行做一次小规模对照实验，成本可控且说服力更强。

5.2 一个可复现的对照实验设计

实验目的：验证“训练信号是否携带步骤结构”对组合指标的影响。设计：同一教师模型、同一学生模型规模、同一数据量，构造两组蒸馏数据——A 组为平铺的输入输出对，B 组在输出中显式加入步骤标记与分支示例。评测使用同一套组合任务集，测量路径覆盖率与顺序正确率。

预期与解释：若 B 组组合指标显著优于 A 组而单点指标相当，则支持“结构信息可被蒸馏”的假设；若两组无差异，则需检查步骤标记是否真正被模型利用（可通过消融标记观察）。该实验的变量控制清晰，适合作为团队的第一块验证砖。

5.3 工程侧的观测指标建议

上线后应持续观测三类信号：任务轨迹的路径分布（是否集中在少数路径，说明覆盖不足）、失败任务的断点位置（集中在哪个 Skill，说明该点契约不清）、人工接管率（组合失败的直接代理指标）。这三类信号比单纯的准确率更能反映拓扑健康度。

六、对比与局限：哪些场景不适合“串项链”

6.1 与端到端大模型方案的对比

“串项链”方案的本质是把组合能力外置为显式结构，代价是灵活性下降、维护成本上升。与之相对，直接用大模型端到端处理复杂任务，组合能力由模型隐式承担，灵活但成本高、可观测性差。二者不是替代关系，而是成本—可控性光谱上的两个点。对于高频、流程稳定、合规要求高的任务，外置编排更合适；对于低频、开放、探索性强的任务，端到端更合适。

6.2 方法本身的边界条件

第一，Skill 边界必须相对稳定。若业务任务每周都在变，依赖图会迅速过期，维护成本超过收益。第二，组合深度不宜过深。依赖图超过一定深度后，编排器的状态管理与错误传播会变得难以控制，此时应做分层抽象。第三，需要足够的轨迹数据支撑依赖统计，冷启动阶段应以专家驱动为主。

本文评述：这些边界条件提示我们，技能拓扑化不是万能药，而是一种在特定条件下收益显著的结构化手段。工程决策应基于任务分布特征，而非概念热度。

6.3 与相关概念的辨析

技能拓扑与“技能库”“工具调用”“工作流编排”等概念有交集但不等同。技能库强调能力集合，拓扑强调集合上的关系；工具调用强调单次调用的正确性，拓扑强调多次调用的顺序与依赖；工作流编排是工程实现手段，拓扑是被编排的对象。厘清这些区别，有助于避免在讨论中把不同层次的问题混为一谈。

七、结论与展望

回到开头的问题：蒸馏后的 Skill 散落一地，碎片怎么串成项链？本文给出的回答是：先承认碎片化的独立成因——训练信号粒度、容量挤出、目标缺失共同导致技能拓扑未被保留；再用四步法把它显式重建——能力盘点、依赖建模、编排路由、评测闭环。这条路径不追求“让模型自己学会组合”，而是先把组合结构外置、可观测、可回退，再逐步把可控部分交还给模型。

展望未来，三个方向值得关注：一是“结构感知蒸馏”，把步骤边界与依赖关系作为蒸馏目标的一部分，而非事后补救；二是“技能图谱的自动维护”，用轨迹数据持续更新依赖图，降低人工成本；三是“可组合评测基准”的建设，让组合能力成为可比较、可复现的指标。笔者认为，这三者中，评测基准的建设最为紧迫——没有可靠的度量，前两个方向的进展都难以被公正评估。

对工程团队的建议是：不要等到模型“更强”再解决组合问题。组合问题是结构问题，结构问题可以在当前模型能力下通过工程手段显著缓解。先做一次单点与组合的对照评测，确认问题类型；再做一次小规模的能力盘点，看看碎片到底长什么样。这两步的成本很低，但往往能改变团队对问题的理解。

八、主要参考文献

1. Hinton G, Vinyals O, Dean J. Distilling the Knowledge in a Neural Network. arXiv:1503.02531, 2015.
2. Kim Y, Rush A M. Sequence-Level Knowledge Distillation. EMNLP, 2016.
3. Gou J, Yu B, Maybank S, Tao D. Knowledge Distillation: A Survey. International Journal of Computer Vision, 2021.
4. Lightman H, et al. Let's Verify Step by Step. arXiv:2305.20050, 2023.
5. Yao S, et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR, 2023.
6. Ho N, et al. Large Language Models for Multi-Step Reasoning: A Survey. arXiv 预印本, 2023.
7. Uesato J, et al. Solving Math Word Problems with Process- and Outcome-based Feedback. arXiv:2211.14275, 2022.
8. Qin Y, et al. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. ICLR, 2024.
9. Xu C, et al. A Survey on Knowledge Distillation of Large Language Models. arXiv 预印本, 2024.

说明：本文涉及的数据集与实验设计均为方法示意，若用于实际研究需按原始文献的预处理流程执行，包括轨迹去重、步骤边界标注一致性校验、低频边过滤阈值设定等。文中标注为“模拟数据”的阈值仅用于说明设定方法，不代表任何真实系统的测量结果。