Blog Post

OPD 如何重构后训练的不可能三角

June 05, 2026
2026 on-policy-distillation llm post-training distillation rl sft rlvr kd Research

OPD 如何重构后训练的不可能三角

准确、稠密、易得的学习信号从哪里来

0. 开场：后训练里的”不可能三角”

今天想从一个很实际的问题开始：后训练到底需要什么样的学习信号？

01-impossible-triangle

我们当然希望这个信号同时满足三个条件。

第一，它要准确。

也就是说，它真的能告诉模型什么行为更好，什么行为更差。比如一道数学题最后答案是否正确，代码能不能通过测试，工具调用是否真的完成任务，用户最终是否满意。

这里的”准确”不是说某个信号一定代表绝对真理，而是说它和我们真正想优化的任务目标足够一致。如果学习信号和目标不一致，训练就会直接把模型带偏。

第二，它要稠密。

只知道最终答案对不对，很多时候是不够的。

一个长链推理可能有二十步，最后错了，不代表前十九步都错。一个 Agent 任务可能有十几轮交互，最终失败，也不代表每一次工具调用都没有价值。

我们希望信号能更细地告诉模型：哪一步对，哪一步错，哪一段推理应该保留，哪一个动作应该修正。

第三，它要易得。

信号不能太贵，也不能太难获得。

如果每个 token 都要调用一个超大教师模型打分，或者每个样本都要人工详细标注，那工程上很难持续扩大规模。真正可用的后训练信号，必须能在成本、吞吐、系统接入和稳定性上站得住。

“易得”不只是便宜，也包括能不能稳定接入训练系统：能不能拿到 logits，能不能批量调用 verifier，能不能复用线上反馈闭环，能不能在训练吞吐上承受这些额外信号。

但问题是，这三个条件很难同时满足。

  • 如果信号很准确，往往不稠密。 比如 RLVR 里的 outcome reward，答案对错、测试通过与否通常很可靠，但它只在最终结果上给反馈。
  • 如果信号很稠密，往往不一定准确。 比如 SFT 的 token-level imitation 很稠密，但它只是让模型模仿固定答案，并不保证这些 token 级监督在模型真实推理路径上仍然有效。
  • 如果信号又准确又稠密，往往不易得。 比如白盒强教师的 full logits 可以提供很丰富的分布信息，但它要求能访问教师 logits，计算和存储成本也很高。

所以后训练里存在一个很现实的”不可能三角”：

准确性、稠密性、易得性，很难同时达到最优。

今天讲 OPD，不是说它真的魔法般打破了这个三角。更准确地说，OPD 提供了一种新的组织方式：它让学生模型在自己的行为分布上生成轨迹，再把教师、历史 checkpoint、验证器、rubric、reward model 或环境反馈组织成更密集、更贴近部署分布的学习信号。

因此，我想讨论的核心问题不是”OPD 是不是又一个蒸馏方法”，而是：

OPD 如何重构后训练信号在准确、稠密和易得之间的 trade-off？

这是今天这场分享的主线。

1. 三种传统后训练信号，各自卡在哪里

理解 OPD 之前，先看 SFT、传统 KD 和 RLVR 分别处在这个三角的什么位置。

1.1 SFT：信号稠密、工程成熟，但不一定贴近模型真实分布

SFT 是后训练里最基础、最成熟的方法。

它的信号非常稠密。每个 token 都有监督，模型可以稳定地学习标准答案的表达方式、格式、推理模式和任务风格。

它也相对易得。只要有高质量标注、人类答案、教师生成答案，或者经过过滤的数据，就可以做 SFT。工程上也最成熟，训练过程稳定，调参成本相对低。

但 SFT 的问题在于，它通常是 off-policy 的。

模型训练时看到的是固定答案，推理时面对的却是自己生成的前缀。一旦前面某个 token 或某一步推理走偏，后续状态就可能脱离训练数据覆盖的区域。

SFT 很擅长让模型学会”标准路径”，但它不一定覆盖模型真实会犯错的路径。

所以放在不可能三角里看：

SFT 的信号稠密、相对易得，但准确性依赖数据质量和分布匹配。它不一定能准确指导模型在自己真实轨迹上的行为。

这就是 SFT 的根本限制。

1.2 传统 KD：信号更丰富，但容易出现 teacher-forced mismatch

传统知识蒸馏比 SFT 更进一步。

SFT 通常只告诉学生”这个 token 是答案里的下一个 token”。KD 则让学生匹配教师的输出分布。教师不仅告诉学生哪个 token 最可能，还告诉学生不同候选之间的相对偏好。这种 soft target 的信息量通常比 hard label 更丰富。

因此，KD 的优势是信号稠密，而且比普通 SFT 更细。

但传统 KD 经常发生在固定数据上。也就是说，学生是在某些预先给定的输入和答案前缀上匹配教师，而不是在自己真实生成的前缀上学习。这样就会出现 teacher-forced mismatch：教师教得很细，但教的未必是学生部署时真实会走到的状态。

比如，学生在真实推理中第三步已经写偏了。传统 KD 如果只在标准答案路径上蒸馏，就没有告诉学生在这个错误前缀之后应该怎么恢复。

所以放在不可能三角里看：

传统 KD 的信号稠密，白盒教师下也相对准确，但它往往不在学生真实分布上发生，因此准确性会受到分布错配影响。同时，拿到高质量教师 logits 本身也不总是容易。

这为 OPD 埋下了伏笔：如果蒸馏要更有效，就不能只在固定路径上蒸馏，而应该在学生自己的轨迹上蒸馏。

1.3 RLVR：信号贴近目标，但太稀疏

RLVR 走的是另一条路。

它不要求教师告诉模型每个 token 怎么写，只要最终结果可验证即可。数学题答案对不对，代码测试过不过，工具调用是否成功，这些都可以作为 reward。

RLVR 的优势是信号通常比较准确，而且直接对齐任务目标。它让模型自己探索，而不是只模仿已有答案。这也是为什么 RLVR 在数学、代码、可验证推理任务上很重要。

但 RLVR 的问题也很明显：reward 太稀疏。

一道题最后错了，reward 只告诉模型这条轨迹不好，但不告诉它到底哪一步出了问题。一个 Agent 最终失败，reward 也很难区分是计划错了、工具选错了、参数填错了，还是最后总结错了。

这种信用分配，也就是 credit assignment 的困难，使得 RL 需要大量采样，训练不稳定，尤其在长链推理和 Agent 任务中表现明显。

所以 RLVR 虽然在分布上更 on-policy，目标也更准确，但它面临严重的 credit assignment 问题。

放在不可能三角里看：

RLVR 的信号准确、相对易验证，但不稠密。它能告诉模型结果好坏，却很难直接告诉模型过程应该如何修正。

这就是 OPD 试图补的另一个缺口。

1.4 小结：后训练最缺的是可组织的学习信号

到这里可以看到，SFT、KD、RLVR 不是谁绝对更好，而是分别占据了不可能三角里的不同位置。

SFT 稠密、稳定，但通常 off-policy。

传统 KD 信号更丰富，但经常发生在固定路径上。

RLVR 更贴近目标和学生分布，但反馈太稀疏。

所以后训练最缺的不是再多一个 loss 名字，而是一套机制，能够把不同信号源放到模型真实会走到的轨迹上，并在准确性、稠密性和易得性之间做更灵活的组合。

这就是 OPD 出场的位置。

02-traditional-signals

2. OPD 的核心：在学生自己的轨迹上组织密集监督

现在可以给出 OPD 的定义。

On-Policy Distillation，简称 OPD，可以用一句话概括：

在学生模型当前策略生成的轨迹上，让教师模型、历史 checkpoint、自教师、验证器或评分机制提供监督信号，从而让学生在自己的行为分布上学习。

这句话里有三个关键词。

2.1 第一个关键词：on-policy

OPD 和传统 SFT/KD 最大的区别，是训练数据来自学生当前策略。

学生先自己生成 rollout，然后教师或评分机制在这些 rollout 上提供反馈。这样训练分布更接近模型真实推理时会遇到的状态。

这解决的是 SFT 和传统 KD 的一个核心问题：固定数据上的监督不一定覆盖学生真实会走到的状态。

换句话说，OPD 的第一步是把学习信号搬到学生自己的行为分布上。

2.2 第二个关键词：trajectory

OPD 关心的是轨迹，而不是单个输入输出。

对于长链推理，轨迹可以是一整段思考过程。对于 Agent，轨迹可以包括多轮 observation、action、tool call 和 environment feedback。对于代码任务，轨迹可以包括生成代码、运行测试、根据错误信息修改代码的过程。

OPD 的意义在于，它可以在这些真实轨迹上提供过程信号，而不是只在最终答案上给一个 reward。

在 Agent 任务中，早期动作会改变环境状态。比如选错工具、传错参数，后续 observation 就已经变了。此时教师在原来状态下的动作不一定还能对应到学生当前状态。因此，OPD 对轨迹的关注比单纯关注输入输出要重要得多。

2.3 第三个关键词：dense supervision

OPD 不满足于最终 reward。

它可以用很多种更细的监督信号：

  • token-level logits；
  • step-level 权重；
  • teacher-student divergence；
  • rubric score；
  • verifier score；
  • discriminator feedback；
  • 历史 checkpoint 的偏好；
  • 工具调用结果；
  • 线上 badcase 的后验反馈。

这些信号不一定都是传统意义上的 reward，但它们都在扮演类似角色：告诉学生在自己的轨迹上哪些行为应该靠近、哪些行为应该远离。

所以，OPD 的核心不是”蒸馏”这个词，而是：

在学生真实会到达的状态上，把原本稀疏或分散的信号组织成更密集的学习信号。

这正是它重构不可能三角的地方。

03-on-policy-supervision

3. OPD 并不打破三角，而是重构 trade-off

这里需要强调一点：OPD 不是严格意义上”打破”准确、稠密、易得的不可能三角。

它并没有让三者同时免费最优。不同 OPD recipe 仍然有不同代价。

  • 如果使用白盒强教师 logits，那么信号很稠密，通常也比较可靠，但不一定易得。因为需要访问教师 logits，还要承担额外计算和显存成本。
  • 如果使用黑盒 rubric 或 verifier，那么信号更易得，也更容易接入业务系统，但准确性依赖评分规则、验证器和校准质量。
  • 如果使用多教师 OPD，那么信号来源更丰富，但会引入教师冲突、样本路由和训练稳定性问题。
  • 如果使用长轨迹 OPD，那么它更贴近 Agent 真实行为，但轨迹越长，教师信号越容易在后半段失真。

所以，OPD 的意义不是消灭 trade-off，而是提供一个新的操作空间。

过去我们可能只能在几个固定点之间选择：

  • SFT：稠密、稳定，但 off-policy；
  • KD：稠密、信息丰富，但经常 teacher-forced；
  • RLVR：准确、on-policy，但稀疏；
  • 人工标注：准确，但昂贵；
  • verifier：目标明确，但粒度有限。

OPD 把这些信号重新组合起来：

数据来自学生当前 rollout，监督可以来自教师、历史模型、verifier、rubric、reward 或环境反馈。

也就是说，它把”数据分布”和”监督信号”拆开了。

学生负责提供 on-policy trajectory，教师和验证机制负责提供 dense signal。二者组合后，就形成了一个新的后训练设计空间。它让我们可以在准确性、稠密性和易得性之间做更灵活的组合，而不是被迫在几个固定选项中做取舍。

4. 用二维框架看 OPD：轨迹怎么来，信号从哪来

要真正理解 OPD，不需要记住一堆方法名。更简单的方式是看两个维度。

第一个维度是：学生在哪些轨迹上学习？

第二个维度是：学生在这些轨迹上向什么信号学习？

也就是：

数据轨迹 × 监督信号。

这个框架直接对应不可能三角。

轨迹选择决定了信号是否贴近模型真实分布，也影响信号可靠性。

监督选择决定了信号是否准确、是否稠密、是否易得。

这一节的重点是”OPD recipe 怎么设计出来”。下一节会换一个角度，看不同 recipe 在不可能三角里分别落在哪个位置，以及各自付出了什么代价。

4.1 维度一：学生在哪些轨迹上学习

第一种是 full rollout。

让学生完整生成一条回答或一段 Agent 交互，然后在整条轨迹上蒸馏。它最贴近部署分布，但如果学生早期走偏，后半段可能已经没有太大学习价值。

full rollout 适合学生已经比较强、轨迹整体质量可控的阶段。它的优势是分布最真实，缺点是噪声也最容易积累。

第二种是 partial rollout。

只使用轨迹的前若干步，或者只在相对可靠的片段上蒸馏。它适合训练早期，也适合学生明显弱于教师的场景。

核心逻辑是：不要在学生已经严重偏移的状态上盲目信任教师反馈。

第三种是 curriculum rollout。

把轨迹长度当成课程难度。先短后长，或者从接近成功的位置向前回溯。这在长链推理和多轮 Agent 中尤其重要，因为轨迹长度越长，错误累积越明显。

在 Agent 任务中，一个错误动作会改变整个后续环境状态，因此逐步拉长轨迹长度是更稳妥的做法。

第四种是 gated rollout。

用 reward、verifier 或规则筛选轨迹，只对成功样本、高质量片段或高置信区域做蒸馏。这适合 OPD 和 RL 结合的场景：RL 负责探索，OPD 负责把成功经验提炼成更密集的过程信号。

这里的关键 takeaway 是：

OPD 不是 rollout 越长越好，而是要在学生轨迹仍然有学习价值、教师信号仍然可信的区域学习。

4.2 维度二：监督信号从哪里来

第一种是白盒教师 logits。

这是最经典的 OPD。教师在学生生成的 token 上给出概率分布，学生通过 KL 或类似目标靠近教师。它的信号稠密，信息量高，但需要白盒教师，成本也较高。适合 strong-to-weak 蒸馏、跨阶段蒸馏等场景。

第二种是历史 checkpoint。

如果一个模型经过多个训练阶段，不同 checkpoint 各自保留了不同能力，可以把这些历史模型作为教师。这样 OPD 就可以用来做能力回灌和防遗忘。

例如，后面的 RL 阶段可能侵蚀了前面 SFT 阶段学到的能力，OPD 可以把历史 checkpoint 中的能力重新拉回来。

第三种是多教师信号。

不同专家模型负责不同领域，比如数学、代码、Agent、通用对话。学生根据样本类型向对应教师学习。这样 OPD 从模型压缩工具变成能力整合工具。

它的优势是信号来源丰富，但也会带来新的挑战：教师之间可能冲突，样本路由可能错误，学生可能学到平均化行为。

第四种是 verifier 或 outcome reward。

代码测试、数学验证、工具调用结果、业务规则校验，都可以作为监督信号。这类信号通常更接近真实目标，但粒度可能不够细，所以适合和 token/step-level 蒸馏结合。

第五种是 rubric。

如果拿不到教师 logits，可以让教师或人工规则生成评分维度，例如答案是否正确、推理是否完整、格式是否符合要求、是否遗漏关键条件。rubric 的优势是可解释，缺点是质量和校准非常关键。

如果 rubric 写得不好，模型可能学会迎合评分格式，而不是提升真实能力。

第六种是环境和线上后验反馈。

用户是否满意、工单是否被人工改写、工具调用是否失败、线上 badcase 怎么修正，这些都可以成为训练时的后验信号。它们在推理时不可见，但训练时可以作为 teacher 的特权信息。

这在业务闭环场景中尤其有价值，因为企业内部往往比公开数据更容易拿到真实的后验反馈。

这里的关键 takeaway 是：

OPD 不要求所有信号都是 logits。它真正关心的是：这些信号能否在学生自己的轨迹上提供可信、相对密集、工程上可获得的监督。

5. OPD 在不可能三角中的几个典型位置

第 4 节是在讲 OPD recipe 怎么搭出来。接下来换一个角度，看这些 recipe 在”不可能三角”里分别落在哪个位置。这样我们才不会误以为 OPD 是一种无成本的万能解法。

用”不可能三角”的视角看，不同 OPD recipe 实际上是在准确性、稠密性和易得性之间选择不同位置。

5.1 白盒 logits OPD：稠密、较准确，但不一定易得

如果我们有一个白盒强教师，可以拿到 logits，那么 OPD 的做法最直接。

学生先生成自己的 rollout，教师在这些 rollout 上给出 token-level 分布，学生通过 KL 对齐教师。

这类方法在信号稠密性上很强，因为每个 token 都可以得到教师反馈。

准确性通常也不错，因为教师模型足够强，而且反馈发生在学生真实生成的轨迹上，比传统固定路径 KD 更贴近部署分布。

但问题是易得性。教师 logits 不一定能拿到，尤其是商业 API 或跨系统模型。即使能拿到，计算成本、显存成本、吞吐压力也都不低。

所以它的位置是：

稠密性强，准确性较强，但易得性较弱。

适合的场景是：内部有白盒强教师，目标是 strong-to-weak 蒸馏、模型族训练、历史 checkpoint 回灌，或者高价值能力迁移。

5.2 Verifier / reward OPD：准确、较易得，但不够稠密

如果任务本身可验证，比如代码、数学、工具调用，那么 verifier 或 outcome reward 很有价值。

这类信号通常比较准确，也相对易得。代码能不能跑过测试，工具调用是否成功，业务规则是否满足，这些判断可以自动化。

但它们的问题是稀疏。最终通过或失败，不等于能精确指出哪一个 token 或哪一步动作应该调整。

所以它的位置是：

准确性较强，易得性较强，但稠密性不足。

OPD 的作用是把这些 outcome-level 信号进一步转化成过程信号。比如只对成功轨迹做自蒸馏，或者用 verifier 筛选高质量片段，再在这些片段上做 token/step-level 学习。

适合的场景是：RLVR、代码修复、数学推理、工具调用、Agent 成功轨迹提炼。

5.3 Rubric / 黑盒 OPD：易得性更好，但校准决定上限

如果拿不到 logits，也没有严格 verifier，可以用 rubric 或黑盒评分。

例如，让教师模型或人工规则评价学生回答是否完整、是否符合格式、是否解决用户问题、是否有幻觉、是否遗漏约束。

这类方法的优势是易接入。只要能访问黑盒模型输出，或者能定义业务评分规则，就可以构造监督信号。

但准确性取决于 rubric 质量。如果 rubric 写得不好，模型可能学会迎合评分格式，而不是提升真实能力。

稠密性也取决于设计。如果 rubric 只给整体分，它仍然比较粗；如果能拆成 step-level 或维度级评分，就会更密。

所以它的位置是：

易得性较强，但准确性和稠密性高度依赖评分设计。

适合的场景是：闭源教师、业务规则复杂、人工反馈可结构化、没有 full logits 的产品模型优化。

5.4 多教师 OPD：信号丰富，但冲突管理成为核心

多教师 OPD 看起来非常诱人。

数学教师、代码教师、Agent 教师、通用对话教师，各自负责自己擅长的领域。学生在自己的 rollout 上向不同教师学习，似乎可以把多种能力整合到一个模型里。

它的优势是信号来源丰富，稠密性和覆盖面都更好。

但它也带来新的问题：教师之间可能冲突，样本路由可能错误，学生可能学到平均化行为，最后不是每个能力都强，而是每个能力都折中。

所以它的位置不是简单地”更好”，而是：

提高了信号覆盖度，但牺牲了系统简单性，需要额外解决冲突、路由和校准问题。

适合的场景是：多领域专家整合、多阶段 checkpoint 回灌、避免 mixed RL 的 see-saw effect。

5.5 小结：OPD 是新的操作空间，不是免费午餐

把这几类 recipe 放在一起看，可以得到一个很清楚的结论：

OPD 不是一种固定算法，而是一组后训练信号组织方式。

白盒 logits OPD 更靠近”稠密、较准确、成本高”的角落。

Verifier / reward OPD 更靠近”准确、易自动化、但稀疏”的角落。

Rubric / 黑盒 OPD 更靠近”易接入、但依赖校准”的角落。

多教师 OPD 提高了覆盖度，但引入了冲突管理和路由问题。

所以 OPD 的工程问题不是”要不要 OPD”，而是：

在我的任务里，哪种信号最可信？哪段轨迹最值得学？我愿意为稠密性和准确性付出多少成本？

6. 工业实践：OPD 的四种角色

如果前面讲的是 OPD 的抽象框架，那么工业实践说明了一件事：OPD 已经不只是 paper 里的 recipe，而是在真实后训练 pipeline 里承担不同角色。

从工业实践看，OPD 至少有四种角色：效率工具、遗忘修复器、能力整合器和统一接口。

6.1 效率工具：降低轻量模型训练成本

第一种角色是效率工具。

如果旗舰模型已经完整经历了复杂的后训练流程，那么让每个小模型都重复同样流程，成本会非常高。更现实的做法是：用旗舰模型作为教师，把能力蒸馏到轻量模型上。

这里 OPD 的意义是：小模型不只是模仿固定答案，而是在自己的生成分布上向强教师靠近。

这类场景里，OPD 重构的是”准确性和成本”的关系。强教师信号比较准确，也比较稠密，但成本高。OPD 的目标是让学生用更少训练成本吸收旗舰模型能力。

Qwen3 的路线就是一个典型代表：旗舰模型先学到能力，再通过 OPD 把能力迁移到不同尺寸的轻量模型上，适合边缘部署和多尺寸模型族训练。

对我们的启发是：

如果主模型完整走一遍复杂 RL 或多阶段后训练成本过高，小模型、专项模型或部署模型不一定要重复完整 pipeline。可以考虑”强模型完整训练 + 小模型 OPD 接收能力”的模式，把 OPD 作为模型族训练里的效率工具。

6.2 遗忘修复器：整合多阶段训练的收益

第二种角色是遗忘修复器。

多阶段后训练通常是顺序进行的：SFT、推理 RL、Agent RL、通用 RL。每个阶段都可能提升某些能力，也可能损害之前学到的能力。比如通用对话能力提升了，但推理能力掉了；Agent 能力增强了，但代码能力变差了。

如果最后一个阶段侵蚀了前面的能力，就需要一种机制把历史阶段的能力拉回来。OPD 可以把不同阶段的优秀 checkpoint 作为教师，让最终模型在自己的 rollout 上重新学习这些能力。

这里 OPD 重构的是”多阶段能力保留”的问题。能力不必只靠参数继承自然保留，也可以通过教师信号重新回灌。

GLM-5 的 cross-stage OPD 路线就体现了这种角色：把不同阶段的优秀 checkpoint 当作教师，让最终模型在自己的 rollout 上同时向这些历史版本学习，降低灾难性遗忘。

对我们的启发是：

不要把历史 checkpoint 只当作废弃产物。不同阶段的模型可能保留了某些峰值能力，例如推理、代码、工具调用、通用对话或安全对齐。OPD 提供了一种能力回灌方式，让这些阶段性能力重新进入最终模型，而不是只能依赖混合数据或继续训练自然保留。

6.3 能力整合器：融合多领域专家

第三种角色是能力整合器。

一个产品模型可能需要数学、代码、Agent、工具调用、通用对话等多种能力。直接混合训练容易出现 see-saw effect：一个能力上升，另一个能力下降。

OPD 提供的思路是：让专家模型保持独立，不直接在参数空间合并；学生通过 on-policy rollout 向不同专家学习。

这时 OPD 的关键价值是：

能力不在参数空间硬合并，而是在学生自己的行为分布上通过监督信号整合。

这也是 OPD 从”蒸馏小模型”升级为”整合复杂能力”的重要原因。

MiMo-V2-Flash 的路线就是典型：先让不同领域专家分别变强，再通过 multi-teacher OPD，把这些专家能力整合到一个学生模型里。

对我们的启发是：

多能力整合不一定都要在参数空间里硬合并，也不一定只能靠 mixed RL。可以让专家模型或专项 checkpoint 保持独立，在 logit、verifier 或评分空间里给学生提供监督。这样做的关键不只是”多找几个教师”，而是要有可靠的样本路由、教师冲突检测和能力监控。

6.4 统一接口：组织教师、奖励、验证器和历史模型

第四种角色更抽象：OPD 可以成为后训练里的统一接口。

后训练信号来源越来越复杂：教师模型、历史 checkpoint、verifier、reward model、工具执行结果、线上反馈、人工修正。过去这些信号可能分别进入 SFT、RL、DPO、KD 或规则系统。

OPD 的价值在于，它提供了一个共同框架：

学生生成当前轨迹，不同信号源在这些轨迹上提供监督。

这样，后训练就不再只是”选择 SFT 还是 RL”，而是变成一个信号组织问题：什么轨迹、什么信号、什么权重、什么阶段、什么教师。

DeepSeek-V4 路线可以理解为更激进的统一化思路：当教师数量很多、能力来源复杂时，OPD 提供了一个让学生向多个教师和多个信号来源学习的统一机制。

对我们的启发是：

当后训练信号来源足够复杂时，核心问题会从”选哪个 loss”变成”如何调度多个教师和多个反馈源”。OPD 的价值不只是一个目标函数，而是把教师、历史模型、verifier、reward、线上反馈放到同一个 on-policy 轨迹框架里组织起来。

6.5 小结：工业实践说明 OPD 的角色正在升级

四种角色可以概括成四句话：

  • Qwen3 类型路线把 OPD 用作效率工具：降低轻量模型完整后训练成本。
  • GLM-5 类型路线把 OPD 用作遗忘修复器：把多阶段训练中丢失的能力拉回来。
  • MiMo 类型路线把 OPD 用作能力整合器：把多个领域专家的能力合到一个学生。
  • DeepSeek-V4 类型路线把 OPD 推向统一接口：用 OPD 组织复杂教师集合和后训练信号。

这些路线在 KL 粒度、是否加 reward、教师怎么选、OPD 放在哪个阶段上都有分歧，但共同趋势很清楚：

OPD 正在从小模型压缩工具，变成后训练中的信号组织层和能力整合层。

7. 为什么 OPD 仍然会失败

既然 OPD 不是严格打破不可能三角，它当然也会失败。

OPD 的 failure mode 也可以回到不可能三角里理解：失败往往不是因为 OPD 这个框架错了，而是我们误判了某个信号到底有多准确、多稠密、或多易得。

7.1 高估教师信号的准确性

第一类失败是高估教师信号的准确性。

教师在标准输入上很强，不代表它在学生错误前缀上仍然可靠。学生一旦走到教师不熟悉的状态，教师给出的 token 概率可能没有太大意义。

尤其是在长链推理和 Agent 场景中，学生一步走偏后，后续状态可能已经不是教师熟悉的分布。此时继续强行蒸馏教师 logits，可能不是在学习能力，而是在放大学生偏移状态下的噪声反馈。

这对应的是不可能三角里的”准确性误判”。

7.2 过度追求稠密信号

第二类失败是过度追求稠密信号。

不是所有 token 都值得蒸馏。长轨迹后半段、严重偏移状态、低质量 rollout 上的密集监督，可能只是密集噪声。此时继续做 token-level 蒸馏，可能只是把错误状态下的随机偏好放大。

所以，信号稠密不等于信号有效。

这对应的是不可能三角里的”稠密性误判”：我们以为更密的监督一定更好，但密集噪声可能比稀疏正确信号更危险。

7.3 低估易得性的真实成本

第三类失败是低估易得性的真实成本。

白盒 logits 看起来信息丰富，但教师调用、显存、吞吐、缓存、数据同步都可能成为瓶颈。黑盒 rubric 看起来便宜，但校准和稳定性也需要成本。Verifier 看起来可自动化，但如果测试覆盖不足、规则不稳定、调用链复杂，也会引入系统成本。

这对应的是不可能三角里的”易得性误判”：信号理论上可用，不代表工程上可持续接入训练。

7.4 忽视多教师冲突

第四类失败是忽视多教师冲突。

多个教师不一定越多越好。如果没有路由和冲突检测，学生可能学到折中行为，而不是整合优势能力。不同教师在同一个样本上的分歧，如果没有监控，multi-teacher OPD 很可能变成平均化蒸馏。

这本质上是多个信号源之间的准确性不一致：每个教师在自己的领域可能是准确的，但放到同一个样本上未必都可靠。

7.5 蒸馏过度导致模型变短、变保守

第五类失败是蒸馏过度导致模型变短、变保守。

自蒸馏或强教师蒸馏可能让模型学到更短、更确定的表达。这在一些任务上是好事，但在复杂推理中，模型可能因此减少探索、减少不确定性表达，甚至损害 OOD 推理能力。

尤其是 self-distillation，如果过度强化”干净、短、确定”的 trace，可能会伤害模型主动纠错和多路径思考的能力。

这对应的是另一个稠密性风险：模型不仅学到了能力，也可能学到了教师的表达习惯、保守倾向和不必要的确定性。

7.6 小结：OPD 的关键不是更密，而是更可信

所以 OPD 的实践原则不是：

信号越密越好，教师越强越好，rollout 越长越好。

更合理的原则是：

在何时、何处、以何种强度相信教师。

这句话应该是 OPD 工程落地里最重要的判断标准。

04-trust-region

8. 对我们有什么启发：可以怎么落地

如果把 OPD 放到业务和内部模型训练中，我觉得有几类比较现实的方向。

8.1 用 OPD 修复 badcase，同时降低 SFT 遗忘

线上 badcase 通常可以通过 SFT 修复，但直接 SFT 容易带来遗忘，尤其是数据分布窄、样本量少、风格强的时候。

一个更稳的路线是：

  1. 收集线上 badcase；
  2. 用人工、规则、强模型或业务系统给出修正答案；
  3. 先通过 SFT 或局部训练得到一个能修复 badcase 的 teacher / 中间模型；
  4. 让主模型生成 on-policy rollout；
  5. 让 teacher、verifier 或 rubric 在这些 rollout 上提供监督；
  6. 用 OPD 把修复能力回灌到主模型，同时监控原有能力是否遗忘。

简单说：

SFT 负责把问题修好，OPD 负责把修好的能力更平滑地蒸回主模型。

这可以减少小数据 SFT 对整体模型能力的破坏。

这是最适合短期试点的方向，因为数据闭环比较短，工程复杂度也相对低。

8.2 把线上后验反馈变成特权信息

很多业务场景里，模型推理时看不到某些信息，但事后我们能拿到。

比如：

  • 用户最终是否满意；
  • 工单是否被人工改写；
  • 工具调用是否成功；
  • API 返回是否异常；
  • 代码是否通过测试；
  • 检索结果是否真的被使用；
  • Agent 任务在哪一步失败；
  • 人工审核给出了什么修正。

这些后验信息可以作为 teacher 的特权信息。

也就是说，teacher 在训练时看到更多信息，student 在推理时看不到这些信息；然后通过 OPD，把 teacher 在更充分信息下的行为蒸馏给 student。

这类路线很适合企业内部场景，因为内部系统往往能拿到公开数据拿不到的业务闭环反馈。

这里的关键不是”再标一批数据”，而是把已经存在的业务后验信号结构化：哪些反馈能作为 verifier，哪些能作为 rubric，哪些能作为 teacher 的额外上下文，哪些只能作为样本筛选信号。

8.3 用历史版本和专项模型做能力回灌

很多团队会有多个模型版本：

  • 某个版本通用对话更稳；
  • 某个版本代码更强；
  • 某个 checkpoint 数学更好；
  • 某个版本工具调用更可靠；
  • 某个模型在特定客户场景表现更好。

传统做法可能是选一个最终版本，或者混合数据重新训练。OPD 提供另一种方式：把这些版本当作教师，让学生在自己的轨迹上学习不同版本的优势。

一个可行流程是：

  1. 先识别不同 checkpoint 或专项模型的优势能力；
  2. 建立任务类型、样本领域和教师之间的 routing 规则；
  3. 让主模型生成 on-policy rollout；
  4. 让对应教师在这些 rollout 上提供 logits、评分或偏好；
  5. 通过 OPD 做能力回灌；
  6. 监控不同能力之间是否发生冲突或互相稀释。

关键是不要让所有教师对所有样本都生效。更合理的是按任务、领域、样本类型、置信度和 verifier 结果做 routing。

这个方向的价值比 badcase 修复更大，但也更依赖评测体系和教师路由。

8.4 在 Agent 训练中把 OPD 作为 RL 的辅助目标

Agent 任务里，单纯 RL 成本高、reward 稀疏、训练不稳定。OPD 可以作为辅助目标，帮助模型从成功轨迹中学习过程模式。

可以这样理解：

  • 环境 reward 判断任务是否成功；
  • verifier 判断某一步工具调用是否合理；
  • teacher 或历史成功轨迹提供过程指导；
  • OPD 把这些过程信号蒸馏到学生自己的轨迹上。

一个更工程化的流程是：

  1. 先通过 RL、搜索或人工轨迹收集成功案例；
  2. 用 verifier 标记关键 step，例如工具选择、参数填写、结果检查；
  3. 让学生在相似任务上生成自己的 trajectory；
  4. 对状态仍然对齐、信号仍然可信的 step 做 OPD；
  5. 对严重偏移的后半段降低权重或不蒸馏；
  6. 同时保留环境 reward，避免 OPD 变成纯 imitation。

但 Agent 场景下不要把 OPD 当成 RL 的替代品。

更合理的定位是：

RL 负责探索方向，OPD 负责把成功路径中的过程信号变成可学习的密集监督。

这个方向最有想象力，但也最依赖 verifier、环境日志、step-level 诊断和轨迹管理能力。

05-opd-adoption-path

9. 仍然没有解决的问题

最后讲几个开放问题。

第 7 节讲的是 OPD 工程上为什么会失败；这一节更关注一些还没有完全搞清楚的判断问题。

9.1 OPD 到底是在蒸馏知识，还是在整合已有能力？

如果学生完全没有某种能力，教师在学生错误轨迹上的指导未必能让它凭空学会。很多时候，OPD 更像能力传播、能力回灌和能力整合，而不是自动拓展能力边界。

这会影响我们对 OPD 的定位。

如果 OPD 主要是能力整合工具，那它最适合把已有教师、已有 checkpoint、已有 verifier 的能力组织起来。

如果 OPD 能在某些条件下拓展能力边界，那就需要解释：额外能力到底来自哪里？来自多教师互补？来自 on-policy 分布校准？来自 verifier 筛选？还是来自搜索和数据扩展？

9.2 学生什么时候能超过教师？

学生有时可以通过多教师整合、verifier 筛选、on-policy 分布校准，在某些任务上超过单个教师。

但这通常依赖额外因素，例如更好的数据、更强 verifier、更多样教师、更好的搜索，而不是 OPD 本身自动保证。

所以问题不是”学生能不能超过教师”，而是：

什么条件下，OPD 不只是模仿教师，而是能把多个信号源组合出比单个教师更好的策略？

这是 OPD 从压缩工具走向能力整合工具时必须回答的问题。

9.3 效果主要来自 on-policy 数据，还是来自 dense signal？

OPD 同时改变了两个变量：数据来自学生当前分布，监督也比 RL 更密集。

到底哪个贡献更大，很多场景下并不容易拆开。

如果主要收益来自 on-policy 数据，那么我们应该重点优化 rollout 分布、轨迹筛选和 curriculum。

如果主要收益来自 dense signal，那么我们应该重点优化教师信号、KL 设计、rubric、verifier 和权重调度。

现实中，二者往往相互作用：on-policy 数据让监督更贴近部署分布，dense signal 又降低了 credit assignment 难度。

9.4 回复变短到底是好事还是坏事？

蒸馏经常让模型输出更短、更确定、更像教师。

这可能提升效率，也可能损害复杂推理中的不确定性表达、分支探索和自我纠错。尤其需要警惕的是，模型是否只是学到了教师风格，而不是任务能力。

所以”回复变短”不能简单判断为优化或退化。

在一些业务问答里，更短更稳定可能是好事。

在复杂推理、探索式代码修复、Agent 任务里，过早变短可能意味着模型减少了必要的检查、假设分支和自我纠错。

这需要任务级指标和过程级指标一起判断。

9.5 多教师冲突如何诊断？

多个教师信号同时存在时，学生应该听谁？

教师分歧是互补信息，还是噪声冲突？

如果不能诊断这个问题，多教师 OPD 很容易变成平均化蒸馏。

这需要更细的监控，比如：

  • 哪些样本上教师分歧最大；
  • 哪些任务上某个教师稳定优于其他教师；
  • 哪些教师在同一个样本上给出相互冲突的偏好；
  • 学生最后学到的是某个教师的优势能力，还是多个教师的平均风格。

多教师 OPD 的核心难点不是”教师数量”，而是”冲突解析”。

9.6 OPD 与 RL 的边界在哪里？

OPD 和 RL 并不是替代关系。

白盒 logits OPD 看起来更像蒸馏；黑盒 verifier / rubric OPD 越来越接近 RL；Agent 场景下，OPD 往往会成为 RL 的辅助目标。

所以一个长期问题是：

哪些能力应该靠 RL 探索出来，哪些能力应该靠 OPD 蒸馏下来？

我的理解是：RL 更适合负责探索方向、发现新策略和突破边界；OPD 更适合负责过程稳定化、能力回灌和降低 credit assignment 难度。

但在具体系统里，二者的权重、阶段和交互方式还需要大量经验和诊断工具支持。

9.7 未来需要哪些监控指标？

这些问题说明，未来 OPD 不应该只监控 loss 和 benchmark score。我们还需要监控：

  • 哪些样本上教师分歧最大；
  • 哪些 step 上学生和教师开始偏离；
  • rollout 后半段的监督是否仍然可靠；
  • OPD 后模型是否明显变短、变保守；
  • 某个领域提升是否以另一个领域下降为代价；
  • 学生是否学到了能力，而不只是学到了教师风格；
  • 不同信号源之间是互补、冗余，还是互相抵消。

只有这些诊断建立起来，OPD 才能从经验 recipe 变成可控训练系统。

10. 结语：OPD 的意义是重新组织学习信号

最后回到开头的不可能三角。

后训练希望学习信号同时准确、稠密、易得，但现实里很难三者兼得。

  • SFT 稠密、稳定，但 off-policy。
  • 传统 KD 信号丰富，但常常发生在固定路径上。
  • RLVR 目标准确、贴近结果，但 reward 稀疏。
  • 人工标注准确，但成本高。
  • Verifier 易自动化，但粒度有限。

OPD 的意义不是彻底打破这个三角，而是重构这个三角。

它把”学生当前轨迹”和”监督信号来源”拆开：学生负责生成 on-policy trajectory，教师、历史 checkpoint、verifier、rubric、reward model 和环境反馈负责提供监督。这样，我们就可以在准确性、稠密性和易得性之间做更灵活的组合。

短期看，OPD 可以用来降低小模型训练成本、修复 badcase、减少 SFT 遗忘、整合历史 checkpoint。

中期看，OPD 会成为多专家能力整合和 Agent 训练的重要组件。它可以把数学、代码、工具调用、Agent、通用对话等能力通过教师信号整合到一个学生模型里，也可以在 Agent RL 中缓解稀疏 reward 的 credit assignment 问题。

长期看，如果多教师冲突解析、黑盒评分、verifier 设计、训练诊断和 OPD+RL 组合目标都成熟，OPD 可能会成为后训练系统里非常核心的信号组织机制。

但也要保持清醒：

OPD 更像能力传播、能力整合和训练稳定化机制，不一定自动拓展能力边界。

真正的突破仍然需要新的数据、新的环境反馈、新的搜索、新的 reward 和更强的 verifier。

所以，理解 OPD，不是为了记住一堆新缩写，而是为了理解一个正在成形的新抽象：

用在线轨迹承载学习，用密集信号降低 credit assignment 难度，用教师和验证器整合复杂能力，在准确、稠密和易得之间重新组织后训练信号。

这就是 OPD 在后训练里真正重要的地方。