第 6 章 知识蒸馏与合成数据¶
开场问题：没有足够人工数据时，让更强模型生成答案再训练自己，怎样避免把教师的错误和腔调一起复制？
6.1 三种蒸馏，信号强度差一个量级¶
响应蒸馏（sequence-level KD）：只拿教师的最终输出文本当标准答案做 SFT。每个位置一个 hard label，学生学到的是"这个输入该输出这段话"。实现最简单，也是只能调用闭源 API 时唯一能做的。
过程蒸馏：连教师的中间推理和工具轨迹一起学，传递的是解题策略而不只是答案。它能教会学生"遇到这类问题先做什么"，但过程可能冗长，也可能包含看起来合理的伪推理。
分布蒸馏（logit-level KD）：不只学采样出来的那一个 token，而是学教师在每个位置上的整个概率分布：
信息量的差别在这里：一个 hard label 只说"这里应该是 the"；一个分布还告诉你"a 也有 20% 合理，cat 完全不行"。这些相对关系就是所谓的 dark knowledge——一次前向提供的是词表维度的监督，而不是 1 个 token 的信息。同样的数据量，分布蒸馏的样本效率通常显著更高。
代价也很具体：要能拿到教师 logits（闭源 API 一般不给）；教师和学生必须共享同一个 tokenizer 和词表，否则位置和词表对不齐；存储传输成本高，实践中通常只保留 top-k 再归一化。
所以"用 GPT 生成数据"不该统称为蒸馏。你拿到什么信号，决定了学生最多能学到什么。
6.2 温度与 KL 方向：两个必须想清楚的旋钮¶
温度。把 logits 除以 T 再 softmax，分布被拉平，非最大项之间的相对关系才显现出来。T=1 时一个高置信分布几乎就是 one-hot，dark knowledge 被压没了，分布蒸馏退化成 hard label。经典做法是用 T>1 计算蒸馏损失、推理时回到 T=1；注意损失要乘 T² 以保持梯度量级不随温度漂移。
KL 方向。这是 LLM 蒸馏里真正容易被忽略、又实际决定效果的一件事，因为 KL 不对称：
- Forward KL，即 \(\mathrm{KL}(p_{\text{teacher}}\|p_{\text{student}})\)：教师有概率的地方学生都必须有概率，否则 loss 爆炸。结果是 mode covering——学生把概率摊开去覆盖教师的所有模式。学生容量不够时，它会在教师其实根本不会输出的区域也分配概率，表现为生成变得平庸、偶尔胡说。
- Reverse KL，即 \(\mathrm{KL}(p_{\text{student}}\|p_{\text{teacher}})\)：只要求学生自己会输出的地方教师认可。结果是 mode seeking——学生收缩到教师的高概率模式上，生成质量更高但多样性更低。
一句话记法：forward KL 让学生什么都学一点，reverse KL 让学生学得像但更窄。 生成任务通常更想要后者。标准的 token-level KD 用的是 forward KL；要做 reverse KL 就必须在学生自己采样出的序列上计算——这自然引出下一节。
6.3 off-policy 的根本缺陷与 on-policy 蒸馏¶
上面几种做法都有一个共同前提：训练发生在教师的输出上。问题是部署时走的是学生自己的分布。学生在第 50 个 token 偏离了轨道，之后进入的状态在教师数据里从未出现过，它不知道怎么回来。这就是 exposure bias，在长轨迹和 Agent 任务上尤其致命——错误会一路放大。
on-policy 蒸馏（GKD 一类方法）换了个顺序：让学生自己生成序列，再在学生生成的每个位置上问教师"你在这里会怎么选"，用教师的分布做 token 级监督。于是训练时的状态分布等于部署时的状态分布，学生恰好在自己真正会犯错的地方拿到纠正。
它的位置介于 SFT 和 RL 之间：像 RL 一样在自己的轨迹上训练，但监督是稠密的 token 分布，而不是一条轨迹一个稀疏 reward。成本也在中间——训练循环里要跑生成（回到第二册的 rollout 工程），还要教师在线前向。
这条线就是第 22.7 节"RL 与 on-policy distillation 融合"的起点：用 verifier 提供任务目标，用教师分布提供密集纠错。
6.4 从种子任务扩展指令¶
常见流程：收集少量真实种子 → 让教师改写、扩难、组合约束 → 生成答案 → 自动验证/规则过滤 → 去重 → 人工抽检。
扩展要沿能力维度设计，而不是随机“再生成一些问题”：语言、长度、约束数、领域、难度、工具数量、是否有干扰信息。否则教师会生成大量表面不同、结构相同的简单题。
6.5 Rejection Sampling¶
对同一个 prompt 从教师或当前模型采样多个候选，用规则、测试、奖励模型或 judge 选出最好的，再作为 SFT 数据。它把“生成分布里偶尔出现的好答案”转化成稳定行为。
关键是选择器。若选择器偏好长答案，训练后模型会越来越长；若只看最终答案，可能选中过程错误但碰巧答对的轨迹。可验证任务最好用真实执行器；开放任务需要多维 rubric。
6.6 自举为何会坍缩¶
模型生成数据再训练自己，反复进行会缩窄分布：少见表达和另类解法逐轮消失，高频模板越来越占优势，错误被确认成“真相”。
缓解方法：
- 保留人工和真实数据作为锚点。
- 使用多个教师和多种采样设置增加多样性。
- 生成问题和生成答案由不同模型/提示完成。
- 对候选做语义去重和难度控制。
- 每轮都在独立、未回流的测试集上验收。
6.7 大模型教小模型的上限¶
学生容量较小时，直接模仿教师的超长复杂答案可能学不会。更有效的是把任务难度和答案长度调到学生的可学习区域，或先学短过程再逐步增加。
蒸馏并不保证学生复制教师全部能力。它通常在目标分布上逼近教师，却可能牺牲教师在分布外的泛化。评测必须同时看目标任务和通用回归。
6.8 蒸馏推理轨迹的特殊之处¶
长 CoT 轨迹是现在最有价值也最容易做坏的一类蒸馏数据：教师的文字推理不一定反映其真实计算；冗长过程同时抬高训练和推理成本；把面向用户的最终回答也训成长篇自语会直接破坏体验。
现代做法是把"内部推理"和"最终回答"用特殊区域分开，分别控制 loss、长度和展示策略。完整的做法、过滤标准和它与 RL 的分工在第 11 章展开——那一章专门讲推理时计算这条线。
核心问答¶
Q：分布蒸馏为什么比只学答案强？ hard label 每个位置只给 1 个 token 的信息；教师分布给的是整个词表上的相对关系（dark knowledge），同样数据量下监督密度高得多。代价是需要 logits 且必须共享 tokenizer。
Q：forward KL 和 reverse KL 选哪个？ forward KL 让学生覆盖教师的所有模式，容量不足时生成会变平庸；reverse KL 让学生收缩到高概率模式，生成质量更高但更窄。生成任务通常想要后者，而它需要在学生自己的采样上计算。
Q：on-policy 蒸馏解决了什么？ exposure bias。在教师数据上训练的学生，一旦偏离轨道就进入没见过的状态；让学生自己生成、教师在这些状态上逐 token 纠正，训练分布才等于部署分布。
Q：合成数据为什么必须有过滤器？ 生成模型只提供候选分布，不提供正确性保证。没有独立过滤，教师的错误会被当成高置信标签固化下来。
Q：Rejection Sampling 和 DPO 有什么区别？ 前者选出赢家后当普通 SFT；后者同时利用赢家和输家的相对信息，直接拉开两者的概率差距。
Q：教师越强越好吗？ 不一定。答案超出学生可学习容量、风格不匹配目标、或成本过高时，较贴近学生的教师配上分阶段课程更有效。