摘要

大模型后训练正在发生一个很重要的变化。

过去，我们经常用 SFT、普通知识蒸馏，让模型去模仿标准答案。这个思路很直观：给模型一个好答案，让它学会照着生成。

但问题是，模型真正推理的时候，看到的不是标准答案的上下文，而是它自己一步步生成出来的上下文。

一旦模型前面某一步走偏，后面就会进入训练时没见过的状态，最后越写越偏。

OPD，也就是 On-Policy Distillation，同策略蒸馏，解决的正是这个问题。

它的核心思想可以用一句话概括：

不是让学生模型背老师答案，而是让学生模型先自己做题，再让强老师在它真实犯错的位置逐 token 纠偏。

这篇文章我会用教学的方式，把 OPD 讲清楚：它和 SFT、RL、普通知识蒸馏有什么区别，为什么 reverse KL 很重要，为什么 full-vocab OPD 成本高但效果强，以及为什么多专家 OPD 正在成为大模型后训练的重要方向。

---

关键词

大模型、LLM、后训练、OPD、On-Policy Distillation、同策略蒸馏、知识蒸馏、SFT、RL、GRPO、Reverse KL、Full-vocab KL、多教师蒸馏、AI Agent

---

目录

1. 大模型后训练到底在训练什么？

2. SFT 的问题：模型只学会了标准路径

3. RL 的问题：模型知道错了，但不知道哪里错了

4. OPD 的核心：学生先生成，老师再纠偏

5. 一张表看懂 SFT、RL、OPD 的区别

6. OPD 到底在优化什么？

7. 为什么 reverse KL 适合推理、代码和 Agent？

8. Token-level、Top-k、Full-vocab 三种信号有什么区别？

9. 为什么 OPD 特别适合多专家融合？

10. Qwen、GLM、MiMo、DeepSeek 这类路线给我们的启发

11. OPD 和 GKD 是什么关系？

12. 企业 AI 项目如何借鉴 OPD 思路？

13. 最后总结

---

1. 大模型后训练到底在训练什么？

很多人理解大模型训练，会把重点放在预训练上。

预训练确实重要，因为它决定了模型的基础知识、语言能力和世界模型。

但预训练之后，模型还不能直接变成一个好用的助手。

它还需要后训练。

后训练要解决的问题主要有几个：

第一，让模型会听指令。

第二，让模型会推理。

第三，让模型会代码、数学、搜索、工具调用、Agent 规划。

第四，让模型在某个专项能力变强的时候，不要损害其他通用能力。

这背后有一个很大的问题：

多种能力怎么合到一个模型里，而且不要互相打架？

比如一个模型既要会数学，又要会代码，还要会搜索、会工具调用、会自然对话、会遵守安全边界。

这些能力不一定天然兼容。

数学任务希望模型多推理。

对话任务希望模型表达自然。

代码任务希望模型结构严谨。

Agent 任务希望模型规划稳定。

安全对齐希望模型边界清楚。

这些目标一起训练，就很容易出现能力冲突。

所以，现代大模型后训练已经不只是“让模型变聪明”这么简单，而是在解决一个更复杂的问题：

如何把多个能力稳定地压缩、迁移、融合到一个统一模型里？

OPD 的重要性，正是从这里开始的。

---

2. SFT 的问题：模型只学会了标准路径

SFT，全称 Supervised Fine-Tuning，监督微调。

它是大模型后训练里最常见的方法之一。

它的做法很简单：

给模型一批高质量问题和标准答案，让模型学习如何回答。

比如我们给模型这样一条训练数据：

用户问：

请解释一下什么是 OPD。

标准答案是：

OPD 是 On-Policy Distillation，指学生模型在自己生成的轨迹上接受教师模型监督……

模型就学习在这个问题后面生成类似的答案。

这个方法很稳定，也很容易理解。

但它有一个根本问题：

训练时，模型看到的是标准答案路径；推理时，模型看到的是自己生成出来的路径。

这两个路径不是一回事。

举个简单例子。

标准答案的推理路径可能是：

先分析题意，再列公式，再计算，再给结论。

但模型自己推理时，第一步可能就写偏了：

我先猜一个答案，然后再解释。

这时候，模型后面看到的上下文已经不是标准答案里的上下文了。

它进入了一个训练时没怎么见过的状态。

于是后面就可能越写越偏。

这就是 SFT 的核心问题：

它训练的是模型在“正确前缀”下怎么继续写，但真实推理时，模型经常处在“自己写歪了的前缀”下。

所以，只靠 SFT，模型很难学会“走偏之后怎么拉回来”。

---

3. RL 的问题：模型知道错了，但不知道哪里错了

那 RL 能不能解决这个问题？

RL，也就是强化学习，确实解决了一部分问题。

它让模型自己生成答案，然后根据结果给奖励。

比如一道数学题，模型自己生成了 2000 个 token，最后答案对了，就给正奖励；答案错了，就给负奖励。

这比 SFT 更接近真实推理，因为模型是在自己的生成路径上训练。

但 RL 也有一个非常大的问题：

反馈太稀疏。

比如模型做一道复杂数学题，生成了 3000 个 token。

最后系统只告诉它：

错了。

这时候模型并不知道：

是第一步理解题意错了？

是第二步公式列错了？

是中间计算错了？

是最后单位写错了？

还是推理过程前后矛盾？

RL 告诉模型“结果不好”，但不一定告诉模型“到底哪里不好”。

所以 RL 的问题是：

它让模型在自己的路径上训练，但反馈往往太粗，无法精确指导每一步。

这也是为什么长推理、代码、Agent 任务里，单纯依赖最终奖励很容易不稳定。

因为这些任务不是只看最终答案，而是中间每一步都很关键。

---

4. OPD 的核心：学生先生成，老师再纠偏

现在我们就可以理解 OPD 了。

OPD，全称 On-Policy Distillation，可以翻译为：

同策略蒸馏。

它的核心流程是：

第一步，学生模型先自己生成答案。

第二步，得到学生自己的生成轨迹。

第三步，老师模型在学生生成出来的每一个位置上给监督信号。

第四步，学生模型根据老师信号调整自己。

用人话讲就是：

学生先自己做题，老师站在旁边看着它做，并在它真实犯错的位置一步步纠偏。

这和普通蒸馏完全不一样。

普通蒸馏更像：

老师写好标准答案，学生照着学。

OPD 更像：

学生自己先写，老师在学生真实写出来的过程里逐步指出哪里合理、哪里不合理。

这才是 OPD 最重要的地方。

它不是让学生模型学习老师走过的路。

它是让老师模型走到学生真实会走到的路上，去指导学生。

一句话：

OPD 的本质，是让学生模型在自己真实会遇到的状态上接受老师监督。

---

5. 一张表看懂 SFT、RL、OPD 的区别

我们可以用一张表快速对比。

方法	学生看到的路径	反馈方式	最大问题
SFT	标准答案路径	token 级监督	训练路径和真实推理路径不一致
普通知识蒸馏	老师答案路径	token 分布监督	学生没有在自己犯错路径上学习
RL	学生自己生成路径	通常是整段奖励	反馈太稀疏，不知道哪一步错
OPD	学生自己生成路径	老师逐 token 纠偏	成本更高，但训练信号更精准

所以，OPD 可以理解成两种思想的结合：

OPD = RL 的 on-policy + 蒸馏的 dense feedback。

on-policy 解决的是：

模型训练时看到的路径，要尽量接近推理时真实会遇到的路径。

dense feedback 解决的是：

不只是最后给一个分数，而是在每一步都给更细的监督信号。

这就是 OPD 为什么重要。

它同时补上了 SFT 和 RL 的短板。

---

6. OPD 到底在优化什么？

不要先从公式理解 OPD。

先抓住一个直觉：

OPD 优化的不是单个标准答案，而是学生模型在真实生成状态下的行为分布。

什么叫行为分布？

模型每生成一个 token，本质上都在做一次选择。

比如当前上下文是：

我们先把 x 移到等号右边，所以……

模型下一步可能生成：

• x = 3

• x = -3

• 因此面积为 12

• 综上所述

• 可以得到

这些候选 token 背后都有概率。

学生模型有自己的概率分布。

老师模型也有自己的概率分布。

OPD 做的事情，就是在学生自己生成出来的 prefix 上，让学生的下一步 token 分布靠近老师。

注意这里的关键点：

prefix 是学生自己生成出来的，不是标准答案提供的。

这就是 OPD 和普通蒸馏最大的区别。

普通蒸馏通常是在老师或数据集提供的干净上下文上学习。

OPD 则是在学生自己真实生成的上下文上学习。

所以 OPD 训练的不是“理想情况下怎么回答”，而是：

当模型真的走到某个状态时，它下一步应该如何更接近强老师。

这就是 OPD 的训练价值。

---

7. 为什么 reverse KL 适合推理、代码和 Agent？

理解 OPD 时，有一个词很关键：

reverse KL。

你不需要一上来记公式，先理解它的行为特点。

reverse KL 有一个特点，叫 mode-seeking。

可以简单理解成：

它更鼓励学生模型集中学习老师最可靠、最高概率的路径。

举个例子。

一道数学题，老师可能知道好几种解法：

第一种是代数法。

第二种是几何法。

第三种是构造法。

第四种是枚举法。

如果学生试图把所有解法都平均学一遍，可能会出现问题。

它前面用代数法，后面突然切到几何法，中间又混入枚举思路，最后整个推理变得混乱。

这对推理任务是非常危险的。

推理任务最重要的不是“风格多样”，而是：

路径稳定、逻辑一致、步骤可靠。

reverse KL 的价值就在这里。

它不鼓励学生平均模仿老师所有可能路线，而是更倾向于让学生收缩到老师最认可的一条高质量路径上。

所以，对于下面这些任务，reverse KL 很有吸引力：

• 数学推理

• 代码生成

• 工具调用

• Agent 规划

• 多步骤任务执行

• 结构化输出

一句话理解：

forward KL 更像“尽量学全老师的所有可能”；
reverse KL 更像“集中学老师最靠谱的那条路”。

对于开放式写作，多样性可能重要。

但对于数学、代码、Agent，稳定性往往更重要。

这就是 reverse KL 在 OPD 里经常被重视的原因。

---

8. Token-level、Top-k、Full-vocab 三种信号有什么区别？

OPD 里还有一个关键问题：

老师到底给学生多少信息？

这里通常可以分成三种信号粒度。

---

8.1 Token-level：老师只评价学生刚写的那个 token

假设学生在某一步输出了 token A。

token-level 方式只问老师：

老师，你觉得 A 合理吗？

如果老师觉得 A 概率高，就说明学生这一步还不错。

如果老师觉得 A 概率低，就说明学生这一步有问题。

这种方式的优点是：

• 便宜；

• 快；

• 省显存；

• 工程实现简单。

但它的问题也明显：

• 只看一个 token，信息太少；

• 噪声大；

• 容易受标点、格式词影响；

• 学生知道这个 token 不好，但不知道更好的候选是什么。

这就像老师只告诉你：

你刚才这个字写得不好。

但老师没有告诉你：

那你应该写哪个字更好。

所以 token-level OPD 很便宜，但信号比较薄。

---

8.2 Top-k：老师告诉学生最推荐的几个候选 token

top-k 的思路是：

不只看学生刚写的 token，而是看老师最推荐的 K 个 token。

比如老师告诉学生：

在这个位置上，我最推荐这 64 个候选 token，它们的概率大概是这样分布的。

这比 token-level 稳定很多。

因为学生不只是知道自己刚才那个 token 好不好，还能看到老师认为哪些候选更好。

top-k 的优点是：

• 信息量比 token-level 大；

• 成本比 full-vocab 低很多；

• 稳定性更好；

• 更适合普通团队落地；

• 对长推理任务更友好。

所以从工程角度看，top-k OPD 往往是一个很现实的折中方案。

一句话：

token-level 太薄，full-vocab 太贵，top-k 是中间性价比最高的一类方案。

---

8.3 Full-vocab：老师给整个词表的完整分布

full-vocab 是最完整的方式。

它不是只看学生选了什么 token，也不是只看老师 top-k 候选，而是直接看：

在当前 prefix 下，老师对整个词表所有 token 的概率分布。

这意味着学生可以学习老师完整的下一步判断结构。

它的优点是：

• 信息最完整；

• 梯度更稳定；

• 更接近老师真实行为；

• 适合复杂推理和多专家融合。

但它的缺点也非常明显：

• 计算成本极高；

• 显存压力大；

• 多教师场景下更贵；

• 对训练系统工程能力要求很高。

因为每一个位置都要计算整个词表分布，成本大致和以下因素相关：

序列长度 × 词表大小 × 教师数量

所以 full-vocab OPD 不是普通团队随便就能做的。

它更适合拥有强训练基础设施的大模型团队。

一句话总结：

token-level 是便宜近似，top-k 是工程折中，full-vocab 是昂贵但最完整的监督信号。

---

9. 为什么 OPD 特别适合多专家融合？

现在我们进入 OPD 最重要的应用场景：

多专家融合。

假设我们有多个专家模型：

• 数学专家

• 代码专家

• 搜索专家

• Agent 专家

• 指令跟随专家

• 长上下文专家

• 安全对齐专家

• 通用对话专家

每个专家都很强。

问题是：

怎么把它们的能力合成一个统一模型？

传统做法可能会尝试参数合并，或者让这些能力一起进行 mixed RL。

但这样很容易出现冲突。

因为不同专家想让模型朝不同方向更新。

数学专家希望模型更擅长复杂推理。

代码专家希望模型输出更精确、更可执行。

对话专家希望模型语言更自然。

安全专家希望模型更谨慎。

搜索专家希望模型更多利用外部信息。

这些目标如果都直接改同一套参数，就容易出现跷跷板效应：

数学上去了，代码下来了；
代码上去了，对话变僵硬了；
安全加强了，回答又变得过度保守了。

OPD 的思路更加优雅。

它不一定要直接合并专家模型的参数。

它让学生模型自己生成轨迹，然后让不同专家在自己擅长的部分提供判断。

也就是说：

专家不直接把参数塞给学生，而是把自己的判断通过输出分布传给学生。

这就是 logit-space integration。

用更通俗的话说：

不是把多个老师的大脑硬拼到一起，而是让学生在真实做题过程中，同时吸收多个老师的判断标准。

这就是多教师 OPD 的核心价值。

它非常适合把多个领域专家的能力整合进一个统一模型。

---

10. 几个代表性大模型案例：OPD 到底被用来解决什么问题？

前面讲了很多 OPD 的原理，但如果只停留在概念层面，读者可能还是会觉得：

这是不是只是一个学术上的训练技巧？

实际上不是。

从近几代大模型的后训练路线可以看到，OPD 已经不只是一个理论方法，而是正在被用于解决真实的大模型工程问题。

它主要解决四类问题：

1. 大模型能力如何迁移到小模型；

2. 多阶段训练后如何减少能力遗忘；

3. 多个领域专家如何合成一个统一模型；

4. 如何用更稳定的分布监督替代不稳定的 mixed RL。

重点看技术逻辑：这些模型为什么会用 OPD，它们分别拿 OPD 解决什么问题。

---

10.1 Qwen3：用 OPD 做大模型到小模型的能力迁移

第一类场景，是把大模型能力迁移给小模型。

这类问题很常见。

旗舰大模型能力很强，但部署成本高、推理成本高、延迟也更高。很多业务场景不可能全部使用最大模型，所以需要训练更小、更便宜、更容易部署的模型。

传统做法是知识蒸馏：

大模型生成答案，小模型模仿答案。

但普通蒸馏的问题是，小模型只是在大模型的标准输出路径上学习，并没有在自己真实会犯错的路径上接受纠偏。

所以更合理的方式是：

第一步，先用 off-policy 蒸馏让小模型学到基础能力。

第二步，让小模型自己生成答案。

第三步，让强老师在小模型自己的生成轨迹上给反馈。

这就是 OPD 在小模型训练里的价值。

它解决的问题是：

小模型不是只抄大模型答案，而是在自己真实生成过程中，被大模型逐步纠偏。

从这个角度看，Qwen3 这类路线给我们的启发是：

强模型到弱模型的迁移，不应该只停留在“答案模仿”，而应该进入“过程纠偏”。

这对企业 AI 应用也很有价值。

因为很多企业不一定能长期使用最大模型，但可以用强模型给小模型、私有模型、领域模型提供训练信号，让小模型在真实业务问题中逐步对齐强模型。

一句话总结：

Qwen3 这类案例证明了 OPD 可以用于 strong-to-weak distillation，让小模型更高效地吸收大模型能力。

---

10.2 GLM-5：用 OPD 缓解多阶段训练后的能力遗忘

第二类场景，是多阶段训练后的能力回退。

大模型后训练通常不是一步完成的。

一个模型可能先训练通用指令能力，再训练数学，再训练代码，再训练 Agent，再训练工具调用，再做安全对齐。

每个阶段都可能提升某类能力。

但问题是：

后一个阶段的训练，可能会覆盖前一个阶段学到的能力。

比如模型练完数学变强了，但对话能力下降。

练完代码变强了，但指令跟随变差。

练完 Agent 规划变强了，但普通问答变得啰嗦。

这就是能力遗忘，也可以叫 capability regression。

OPD 在这里的价值是：

它可以让模型在自己的生成轨迹上，重新吸收不同阶段模型的能力信号。

也就是说，不同训练阶段得到的模型，都可以被看成某种 teacher。

最终 student 自己生成答案，然后来自不同阶段的 teacher 在它的轨迹上提供监督。

这比简单继续 RL 更稳。

因为 RL 很容易只优化当前阶段目标，而 OPD 可以把前面阶段的能力重新拉回来。

GLM-5 这类路线的启发是：

OPD 不只是用来从强模型教弱模型，也可以用来做 cross-stage capability recovery。

也就是：

把不同训练阶段已经学到的能力重新整合回最终模型。

一句话总结：

GLM-5 这类案例证明了 OPD 可以用于多阶段后训练后的能力修复，减少模型“练了新能力，忘了旧能力”的问题。

---

10.3 MiMo-V2-Flash：用多教师 OPD 做领域能力整合

第三类场景，是多教师融合。

这也是 OPD 最重要的工业价值之一。

假设我们有多个专家模型：

• 数学专家；

• 代码专家；

• 搜索专家；

• Agent 专家；

• 指令跟随专家；

• 长上下文专家；

• 安全对齐专家。

每个专家都在自己的领域里很强。

问题是：

怎么把这些专家能力合成一个统一模型？

一种粗暴做法是参数合并。

但参数合并容易冲突。

数学专家希望模型多推理。

代码专家希望模型结构严谨。

对话专家希望模型表达自然。

搜索专家希望模型引用外部信息。

安全专家希望模型更加谨慎。

这些目标如果全部直接压到同一套参数上，就容易出现跷跷板效应：

这个能力上去了，那个能力下来了。

多教师 OPD 的思路更自然。

它不直接把多个专家的参数硬合并，而是让 student 自己生成轨迹，然后不同 teacher 在自己擅长的位置提供判断。

比如：

数学问题，让数学专家提供更强监督。

代码问题，让代码专家提供更强监督。

搜索问题，让搜索专家提供更强监督。

Agent 任务，让 Agent 专家提供更强监督。

这就相当于：

学生自己做题，旁边不是一个老师，而是一组领域老师。不同题型由不同老师给出专业判断。

MiMo-V2-Flash 这类路线的启发是：

OPD 可以作为多领域专家融合的核心机制。

它解决的问题不是“单个老师怎么教学生”，而是：

多个专家老师如何共同训练一个统一学生模型。

一句话总结：

MiMo-V2-Flash 这类案例证明了 multi-teacher OPD 适合把多个领域专家能力整合进一个模型里。

---

10.4 DeepSeek-V4：用 full-vocab OPD 做高强度专家能力融合

第四类场景，是更高强度的专家融合。

前面说过，OPD 的 teacher signal 可以有不同粒度：

• token-level；

• top-k；

• full-vocab。

token-level 只看学生实际采样出来的 token，成本低，但信号薄、方差高。

top-k 看老师最推荐的一批 token，性价比更高。

full-vocab 则直接看老师在整个词表上的完整概率分布。

full-vocab 的信号最完整，但也最贵。

它的成本大致和以下因素相关：

序列长度 × 词表大小 × 教师数量

如果再叠加多教师，成本会非常高。

所以 full-vocab multi-teacher OPD 的难点不只是算法，而是工程系统能力：

• 如何避免直接缓存超大的 full logits；

• 如何复用 teacher hidden states；

• 如何按需重建 logits；

• 如何优化 KL 计算 kernel；

• 如何调度多个 teacher；

• 如何控制显存和通信成本。

DeepSeek-V4 这类路线的关键价值就在这里。

它不是简单用了 OPD，而是把 OPD 用到了一个更重的工程场景：

用多个领域专家的 full-vocab 分布信号，替代部分传统 mixed RL 式的能力融合方式。

这说明 OPD 不只是“小模型蒸馏技巧”，也可以成为大模型后训练里的能力整合主干。

它解决的问题是：

多个强专家模型如何压缩进一个统一生产模型，并尽量减少能力损耗。

一句话总结：

DeepSeek-V4 这类案例证明了 full-vocab multi-teacher OPD 可以用于更高强度的专家模型合并，是 OPD 工业化的重型形态。

---

10.5 四个案例放在一起看，OPD 的定位就清楚了

把这几个案例放在一起，就能看出 OPD 的真正定位。

代表案例	OPD 主要用途	解决的问题
Qwen3	大模型到小模型的能力迁移	小模型如何高效吸收强模型能力
GLM-5	多阶段训练后的能力修复	如何减少后训练中的能力遗忘
MiMo-V2-Flash	多教师领域能力融合	多个专家如何合成一个统一模型
DeepSeek-V4	full-vocab 多专家蒸馏	如何稳定压缩多个强专家能力

所以，OPD 不是一个单一场景的方法。

它可以用于小模型训练，也可以用于多阶段能力修复，还可以用于多专家融合，甚至可以作为替代 mixed RL 的能力整合路线。

这说明 OPD 的价值已经不只是“蒸馏效率更高”，而是：

它正在成为大模型后训练中连接专家模型、学生模型、多个训练阶段和统一生产模型的重要桥梁。

如果用一句话总结这几个案例：

Qwen3 证明 OPD 可以让小模型学强模型；GLM-5 证明 OPD 可以修复多阶段训练遗忘；MiMo 证明 OPD 可以融合多个领域专家；DeepSeek-V4 证明 OPD 可以上升为大规模专家能力整合方案。

这就是为什么 OPD 值得单独拿出来讲。

它不是一个普通训练技巧，而是大模型后训练从“单模型强化”走向“多专家能力整合”的关键方法之一。

---

11. OPD 和 GKD 是什么关系？

很多人看到 OPD，还会看到另一个词：

GKD。

GKD 的全称是 Generalized Knowledge Distillation，可以翻译成：

广义知识蒸馏。

GKD 的核心思想是：

不要只在固定数据上蒸馏，而要让学生模型在自己生成的输出上接受教师反馈。

这和 OPD 的思想非常接近。

所以可以这样理解：

GKD 更像是早期学术框架里的表达；
OPD 更像是大模型工业后训练里更常用、更工程化的表达。

它们不是完全无关的两个概念。

从思想上看，它们都在解决同一个关键问题：

学生模型不应该只在老师的标准路径上学习，而应该在自己真实生成的路径上学习。

这就是 on-policy 蒸馏思想的核心。

---

12. 企业 AI 项目如何借鉴 OPD 思路？

OPD 虽然是大模型训练方法，但它对企业 AI 应用、智能体项目、流程自动化项目也很有启发。

假设我们要做一个“技术文档智能体”。

普通做法是什么？

准备一堆标准问答，让智能体学习。

这相当于 SFT 思路。

问题是，真实用户的问题不会那么标准。

用户可能问得很乱，问题不完整，表达模糊，甚至把多个需求混在一起。

智能体一旦第一步理解错了，后面的检索、总结、引用、回答都会跟着错。

那 RL 思路是什么？

让智能体回答，然后人工最后打分。

比如：

这条回答 80 分。

但这仍然不够。

因为我们不知道智能体到底哪一步错了。

它可能是 query 写错了。

可能是召回文档不相关。

可能是引用段落不支持结论。

可能是总结偏离原文。

可能是输出格式不符合业务要求。

也可能是最后表达不清楚。

OPD 给企业 AI 项目的启发是：

不要只收集标准答案，要收集模型真实失败轨迹，并在失败轨迹上做细粒度纠偏。

比如训练一个技术文档智能体，我们可以让更强的教师系统逐步检查：

• 用户意图识别是否正确？

• 检索 query 是否合理？

• 召回文档是否相关？

• 引用内容是否支撑结论？

• 答案是否偏离原文？

• 输出格式是否符合要求？

• 是否遗漏关键业务约束？

• 是否编造了文档里没有的信息？

这比只给一个最终评分更有价值。

因为它能告诉系统：

到底是哪一步出了问题。

所以，OPD 对企业 AI 落地最大的启发是：

真正有价值的训练数据，不只是标准答案，而是模型真实犯错的位置。

很多 AI 项目从 demo 到上线，最大的难点不是模型一次都答不出来，而是模型在真实复杂场景里会走出很多错误路径。

如果没有机制持续捕捉这些错误路径，并做细粒度纠偏，系统就很难稳定。

---

13. 最后总结

OPD 不是一个简单的新名词。

它代表的是大模型后训练思路的一个重要变化。

过去，我们经常让模型学习标准答案。

但真实推理时，模型面对的是自己一步步生成出来的上下文。

如果模型只在标准路径上训练，它就很难学会在自己走偏时如何纠正。

OPD 的核心就是：

学生模型先自己生成，老师模型再在学生真实生成出来的轨迹上逐 token 纠偏。

它同时解决了三个问题。

第一，缓解 SFT / 普通蒸馏的分布错位问题。

第二，缓解 RL 反馈太稀疏的问题。

第三，为多专家能力融合提供了一条更稳定的路线。

如果用一句话总结 OPD：

以前是让学生背老师答案；OPD 是让老师盯着学生做题，并在学生真正犯错的位置纠正他。

这就是 OPD 为什么正在成为大模型后训练中非常重要的能力迁移与能力融合方法。

对于做 AI 应用的人来说，OPD 也给了我们一个非常重要的启发：

不要只关注标准答案，要关注模型真实失败轨迹；不要只做最终评分，要做过程级纠偏。

这才是 AI 系统从“能演示”走向“能稳定使用”的关键。