#+title: 各舞其步
#+subtitle: DanceOPD: On-PPolicy Generative Field Distillation — 把多种图像生成能力放进同一个模型，让它们互不打架
#+date: [2026-06-26 Fri 19:43]
#+filetags: :paper:
#+identifier: 20260626T194315
#+source: http://t.cn/AXSlhjUf
#+authors: Wei Zhou, Xiongwei Zhu, Zelin Xu, Bo Dong, Lixue Gong, Yongyuan Liang, Meng Chu, Leigang Qu, Lingdong Kong, Wei Liu, Tat-Seng Chua
#+venue: ByteDance Seed / NUS / UMD / HKUST, 2026

* 问题

想象你在用一张图。输入一句提示词"一只橘猫坐在窗台上"，模型给你生成了一张精美的照片——这就是文本到图像（T2I）的能力。现在你想让这张图里的猫变成一只狗，但保留窗台和光线不变——这是局部编辑。如果你想把整张照片从写实风格改成水彩画——这是全局编辑。

问题是：这三个能力天然不和。你要模型在生成时自由发挥创意，又要它在编辑时死死守住原图的每一像素不被改动；全局编辑要大面积改，局部编辑要精确到点——它们互相打架。

以前的做法有三种：一是把数据混在一起联合训练，但不同能力的梯度会互相冲突，就像两个人同时踩油门和刹车；二是把模型的参数做加权合并，结果得到一个谁都不像的折中方案；三是推理时临时拼接多个模型的外部得分，但这等于每次生成都要额外调用别的模型，部署成本翻倍。

这篇文章的作者们从另一个角度看问题：他们把每个能力看作流匹配模型中一个"速度场"——一种在共享状态空间上定义的指导方向。生成过程就像一个粒子在多个速度场的叠加中运动。关键问题是：给定一个样本，应该用哪个速度场来指导它？在哪个状态点上查询？用多少个状态来监督？

作者们发现，前人把这些选择混在一起做了，而他们的答案是：分开做，并且让学生自己在自己的 rollout 上决定。

* 翻译

他们的命题很直接：每个冻结的能力源定义一个速度场，学生模型在自己的 rollout 状态上主动查询这些场，用简单的速度 MSE 目标来训练。关键是——每个样本只查一个场，不混。

具体怎么做？三个设计选择：

第一，硬路由（hard routing）。每个样本根据任务身份被分配到唯一的业务能力桶——T2I 样本只查 T2I 场，局部编辑样本只查编辑场。不是软混合，不是权重平均，是硬性的"这个样本归你管"。

第二，学生诱导查询状态（student-induced query states）。不在教师的 rollout 状态上查询，而是在学生自己的 rollout 状态上查询。这意味着学生学到的不是"模仿老师的轨迹"，而是"在我的行进路线上向老师请教"。

第三，语义侧单次查询（semantic-side single-query）。一条 rollout 轨迹上可能有几百个状态点，密集地在每个点上都查询教师场会导致高度相关的监督信号重复计数。作者的做法是在语义侧只查一次——用一条低噪声轨迹上的单个状态点。

这三根柱子合起来，形成了一个框架：DanceOPD，即 On-Policy Generative Field Distillation（在线策略生成场蒸馏）。

实验结果令人信服。在 T2I+编辑组合上，DanceOPD 的 GEditBench 平均分比最佳 OPD baseline 高出 8.1%，比编辑源本身高出 8.5%，同时 GenEval 整体分数比 T2I 源还高出 2.0%。在背景变化上提升 21.9%，风格变化提升 21.3%。

在局部+全局编辑组合上，GEditBench 平均提升 16.1%（vs 最强 competing baseline），背景变化提升 33.5%。

在真实感吸收上，关闭了 85.3% 的学生到教师的奖励差距，同时 T2I 分数反而比基线提升了 7.6%。

* 核心概念

三个关键道具：

1. 速度场（Velocity Field）。在流匹配模型中，图像生成交错过程可以被建模为从噪声到图像的速度场。每个能力源（T2I、编辑等）定义一个不同的速度场。这就像同一个城市里有不同的导航路线——去市中心和去机场的速度场完全不同，但都作用于同一个位置空间。

2. 硬路由（Hard Routing）。不是把多个能力源的平均值作为监督信号，而是每个样本只从一个能力源获取指导。这避免了梯度冲突——每个优化步只对一个方向负责。

3. 学生诱导查询（Student-Induced Query）。不在教师的 rollout 上查询教师场，而在学生自己的 rollout 上查询。这解决了一个微妙的问题：教师和学生走过的路径不同，在教师路径上学的东西可能不适用于学生自己的路径。就像学开车——教练车走的路和你自己走的路不一样，你应该在自己开的路上向教练请教，而不是在教练的车上学。

* 洞见

原来"知道止"不是天分，是可以被监督出来的能力。

更准确地说：能力之间的冲突不是因为你教得不够多，而是因为你教得太杂。DanceOPD 的核心视角是——与其让多个能力源在参数层面打架，不如让每个样本自己决定向哪个源请教。这不是"融合"的思路，是"路由"的思路。把"混合监督"换成"定向请教"，问题就解决了。

这个视角可以带到很多其他地方：多任务学习中梯度冲突的问题、多专家模型的门控机制、甚至人类学习中不同科目之间的干扰效应。

* 博导审稿

选题眼光不错。多能力组合确实是图像生成社区的真实痛点——部署一个模型支持多种能力是刚需，而现有的三种路线各有硬伤。

方法上，硬路由是标准设计，但学生诱导查询和语义侧单次查询是两个精巧的选择。前者解决了状态分布不匹配的问题，后者解决了轨迹内查询相关性的问题。这两个诊断实验做得很扎实——用 SDE rollout 做诊断，证明随机噪声有帮助但不是更好的默认方案，说明作者真的理解了问题本质。

但有一个隐忧没有被充分讨论：硬路由依赖预定义的能力桶。当任务边界模糊时（比如"把这张照片改成赛博朋克风格"——这是全局编辑还是风格专化？），硬路由的假设就不成立了。论文承认了这一点但没给解决方案。

判决：weak accept。方法设计扎实，实验充分，但硬路由的预定义假设在实际部署中可能成为瓶颈。

* 检验

生活测试：想象一个演讲者同时要做技术分享和产品演示。如果他试图在一个演讲里兼顾两种风格——时而深入技术细节，时而讲商业故事——听众两边都不满意。DanceOPD 的做法相当于让每个听众根据自己的兴趣被路由到不同的讲解轨道上。站住了——分层服务确实比一刀切好。

但破绽也在：人可以根据上下文动态调整讲解深度，而 DanceOPD 的硬路由是静态的。如果一个样本同时需要 T2I 质量和编辑精度（比如"按这个提示生成图片，但要保留原图的主体"），硬路由就无法同时满足。

押未来：如果 DanceOPD 的思路是对的，未来一两年会看到更多"路由而非融合"的多能力生成模型。具体来说——条件路由（根据样本特征动态分配能力源）可能会取代硬编码的能力桶。

* 启发

你可以试试：如果你正在训练一个多任务模型，不要急着做数据混合或参数合并。先想想——每个样本是否真的需要所有任务的指导？也许硬路由一个能力源就够了。

或者换个角度：不要让学生在老师的轨迹上学习，让学生在自己在行的路上向老师请教。