OneTrans-DCGR：生成式召回的”CoT”机制与多目标

type

Post

status

Published

date

Oct 7, 2026

slug

dcgr-cot-ant-multi-task

summary

之前分享过 OneTrans-V2 的工作，无论是 paper 还是 blog，篇幅和关注点更多放在 OneModel 上，其中提到的生成式召回 DCGR（Decision Conditioned Generative Retrieval）反而没有展开，这值得单独讲讲。大家问得最多的一个问题是：它有没有把其他路召回（比如双塔）替代掉？这事值得细说。

多路召回普遍存在

一个复杂的推荐系统，往往是多路召回的。每一个召回的 channel，可以是一种新的检索算法——如I2I/双塔&MIND/二向箔/生成式，也可以是某一种业务目标——GMV/冷启动/发现性/重定向&复购/广告。

一个发展了多年的系统，线上几十路召回很平常。一路召回要替代掉其他路，不仅效果要足够好，还要能覆盖各种目标。DCGR 在实验中已经合并了发现性和广告这两路独立召回，但还没有完全替代多路召回，原因有两个：

时间问题。替换老召回的实验要一点点做，还要保持各个业务目标的效果平稳，这件事还在进行中。

组织问题。多路召回平行独立实验，是各个业务目标的抓手。合并成一路，所有业务目标就会集中到少数几个人手里：原来是"一人一业务，一人一 P0"，现在必须分出核心目标和次要目标。组织的并行协作问题，比技术问题更难解决。

但退一步看，多路召回本身也许并不是问题。为什么觉得 OneModel 就一定要替代多路召回呢？多路的优势是多目标可以组织并行，劣势是各路召回彼此独立、重复建模、浪费资源。要解决的是冗余，而不是多路本身。

OneTrans-V2 并不对抗级联，DCGR 也不对抗多路。OneModel 的出发点不是替代老系统，而是在最大兼容的前提下整合冗余，让老系统可以平稳地迈出第一步。

DCGR 运行机制

DCGR的核心是，在生成SID 之前，先生成几个 Decision Token。这些 Decision Token 来自一系列基于业务的定义，一类是业务outcome，一类是候选属性，如 paper 所展示的——成单量/平均价格/发现性/是否是广告，当然作为一种机制，它不限于这些，可以自由地扩展下去。

先生成了 Decision Token，再根据决策条件做Beam Search 生成 SIDs，是为 Decision Conditioned Generative Retrieval。

先看一个最小表达。设是用户上下文，是商品，是决策组合。一般生成式召回直接学习，DCGR 则把生成过程拆成：

前半部分判断下一次交互可能具有哪些结果和属性，后半部分在这些条件下生成商品。

训练时使用日志中的真实决策标签与商品 SID，做交叉熵学习。推理时，决策组合携带自己的预测分数和业务偏置，进入 SID 的 beam search。

电商业务的核心目标是 GMV，paper 给出的业务拆分例子是拆成“成单量 x AOV（平均价）”，形成一个串行的决策链。是否是发现品（历史 N 天没出过的新类目），是否是广告品其实是属性，与成单和均价属于不同维度，他们与成单量共享一个token。

每一个决策前缀都对应一个用户状态概率，每一个SID 生成对应一个物品的生成概率。业务偏置加入后，完整路径的搜索分数可以理解成三部分：

第一项判断用户下一次交互的结果和属性，第三项判断在该条件下会选哪个商品，第二项是业务偏置，只调整各决策分支的竞争力。

到第一层 SID 时，每个决策分支都扩展出自己的候选，再按累计分数共同竞争 beam。假设总宽度为 100，最终可能留下 60 条“普通均价且自然供给”路径、30 条“高均价且自然供给”路径、10 条“高均价且广告供给”路径。这个比例是搜索出来的；决策概率为 0.6，并不意味着提前固定分到 60 个名额。

以上是主路召回的搞法，它也可以兼容系统原有的多路召回机制，比如增加一个冷启动Decision Token，代表召回物品历史 0 成单。设置一路独立召回，把冷启动的 DT 设置为 1，其他的正常按上述逻辑生成，以期待这一路产生更多的 0 单冷启动候选。

虽然多了一路召回，但用户历史序列和 CTX 的 prefill 是可以通过 KV Cache 做完全复用的，无论是一路召回的 BeamSearch 分配，还是定死一个业务 Decision Token 的独立召回，都是prefill 零冗余，新增的只是轻量 decode。

Decision Conditioned 的三重价值

第一重价值，是把商品预测拆成有语义的中间步骤。

相对直接生成 SID，先生成 Decision 再生成 SID，增加了中间计算，也让后面的商品预测可以利用前面形成的状态。这就是标题里“CoT”的含义：先形成一个中间判断，再给出最终推荐，非语言版本的 CoT。

如果类比传统推荐，它很像 intention model。我们以前会判断用户的点击意图、购买意图、探索意图，再调整推荐策略。DCGR 把这类判断直接纳入商品生成过程，并让多个可能的判断与商品路径共同竞争。

这也让“多目标”有了不同于多头打分的表达方式。购买、消费均价、探索等中间变量，不仅输出一个预测值，还会影响接下来生成哪些商品。

从机制上看，这提供了用更多推理计算换效果的空间：可以设计更丰富的中间决策，或者让更多决策分支参与搜索。前者改变任务分解，后者增加搜索预算，都值得沿着 test-time scaling 的方向研究。

这里的设计空间，也不局限于当前的 token 数量。怎样拆解中间决策、怎样组织条件依赖，以及给多少搜索预算，都是可以继续扩展的方向。我们关心的是怎样把增加的计算转化为更好的商品预测。

决策维度既提供了商品预测所需的信息，也能控制生成方向：在推理时改变 Decision token，召回结果便会向相应目标移动，说明模型确实利用了中间决策来生成商品。

第二重价值，是利用离线日志学习并改进推荐策略，向更高的期望业务价值优化。

历史日志记录了用户看过什么、选择了什么，也记录了这些交互最终带来了什么结果。把结果作为 Decision token，模型就能学习不同结果条件下的商品选择模式，为面向目标的策略改进提供基础。

推理时，我们可以调用这些条件化的生成能力，调整最终的召回策略。例如，围绕购买或消费目标，提高相应决策路径在搜索中的竞争力，让模型更多地生成符合目标的候选。这种调整同时利用用户上下文、模型学到的决策概率，以及各条件下的商品匹配能力，使业务目标能够参与商品生成的过程。

这让同一路召回具备了持续优化核心目标的空间：模型从离线经验中学习，推理时再按目标组织这些经验，形成更有价值的推荐策略。业务偏置是落实这一步策略改进的手段，背后对应的是结果条件化的 Offline RL 思路。为什么监督学习能够提供这种能力，以及概率调整如何对应策略优化，原理见后文。

直接指定最高消费等级，虽然提高了客单价，却损失了订单和 GMV；在模型预测的决策分布上施加业务偏置，可以取得更好的目标权衡，联合调控购买与消费等级时，用户全部曝光口径下的 GMV 提升了 3.0%。

这里补充一点，在电商领域Order 比 GMV 更容易优化，因为推荐系统会更自然地导向低价品而达成订单目标，单纯地提高排序的 Price 项，往往会导致order 下降，GMV 波动。所以召回阶段如何对齐 GMV 目标，是一个关键问题。更好的 AOV，意味着同等物流成本下更好的利润空间。

第三重价值，是让同一个模型兼容多路召回和多业务目标。

不同业务目标可以通过 Decision token 表达，在共享模型中形成不同的条件召回分支。

广告属性、是否属于用户历史有行为的类目（发现种草），都能自然形成条件。沿着同样的设计，还可以探索冷启动、复购等业务维度。

这些条件可以与用户意图组合。一个分支可以同时表示“有购买倾向、探索新类目、选择某类供给”，而不必让每一个组合都对应一个独立模型。

这些分支既可以参与统一竞争，也可以分配独立的 beam quota，保留多路召回的调度方式：

调度方式	做法	业务含义
共同竞争	各条件分支带着偏置分数，共享 beam	软性调整候选构成
配额保障	给指定条件分支保留独立 beam quota	保证某类业务有候选入口

这样，一个模型既可以提供一路综合召回，也可以在内部保留多个可控的业务分支。新增一个业务目标，不再意味着新增一套模型，只是新增一个 token。

关闭独立的发现性和广告召回后，DCGR 同时承接三类目标，相对各自的专项通道，触达用户的人均新类目数达到 2.2 倍，广告商品的千次曝光 GMV 达到 2.1 倍，体现了同一模型整合多路召回的能力。

Offline RL 的原理

DCGR 的训练看起来很简单：把日志中的结果和属性作为 Decision token，再用交叉熵学习这些 token 和商品 SID。为什么这样一个监督学习过程，能够学出可以按目标调整的推荐策略？

从 Offline RL 的角度看，关键在于监督学习所表达的任务。离线日志既记录了当时采取的动作，也记录了动作之后得到的结果。把这些结果作为条件，就能够从历史经验中学习“为了得到某种结果，应该采取什么动作”。

2019 年的 Upside-Down RL，在标题里就把这个思路说得很直接：

Don't Predict Rewards -- Just Map Them to Actions

一种常见的 RL 路径，是评估在某个状态下采取一个动作，能够得到多少回报，再据此选择动作。Upside-Down RL 把映射方向倒过来：给定状态和期望回报，直接生成动作。

原来的日志记录是“状态 s、动作 a、实际得到的回报 R”。把它组织成监督学习样本，模型学习的是：

训练时，R 是历史中实际得到的回报；推理时，R 可以换成希望得到的回报。不同结果的经验都可以利用，模型在同一个参数空间里学习不同回报条件下的动作模式，推理时再调用其中符合目标的策略。

普通的监督学习学的是"用户会做什么"，结果条件化学的是"想要某个结果，该做什么"。这里的能力来自训练任务的组织方式：把结果放进输入，使模型学会结果与动作之间的条件关系。

2021 年的 Decision Transformer 进一步将这个思路落实到 Transformer 序列建模中，把期望的后续累计回报（return-to-go）、历史状态和动作作为条件，预测接下来的动作，并用于离线 RL。它说明了，策略学习可以通过条件序列建模来完成，并不要求训练形式一定是价值迭代或策略梯度。

回到推荐，状态对应用户上下文，动作对应生成的商品，结果对应购买、消费等级等交互结果。DCGR 把这种结果条件化扩展到属性条件，用 Decision token 统一表达，学习：

例如，日志里既有浏览后离开的交互，也有最终购买的交互。把它们各自的结果作为条件，模型就能学习同一个用户上下文下，不同结果所对应的商品选择模式。推理时，调整决策条件及其分布，就能改变最终的召回策略。

这就是 DC 机制背后的支撑：通过离线经验中的结果监督，学习条件化的动作生成能力。模型先学会“给定目标，怎样生成商品”，再通过决策分布上的策略改进，面向业务目标调用这些能力。

2022 年的 Multi-Game Decision Transformers 给出了更直接的对应。它的 Expert Action Inference 先预测回报分布，再乘上向高回报偏移，随后采样回报并条件化生成动作，其中是归一化回报。这与 DCGR“预测决策、调整分布、条件化生成商品”的用法一致，分布调整也具有下面 KL 推导得到的形式。

为什么概率偏置对应 KL 正则

固定用户上下文，记日志中学到的决策分布为，业务效用为。我们想要一个新分布，业务效用更高，但又不能离太远：KL 约束限制调整后的决策分布过度偏离模型根据用户上下文预测的分布。把这两点写成一个目标：

这个问题有标准的闭式解：

也就是在模型原有的决策概率上，按业务效用乘一个权重，再归一化。取对数：

常数在同一请求内不影响排序。所以在 log 概率上加，就是这一步 KL 正则策略改进。KL 正则 RLHF 的最优策略也是同一个形式。

β 有明确的优化含义，它是"期望效用"和"偏离日志分布"之间的汇率。时，完全相信模型；时集中到最大的决策上，等于直接指定决策，前文"直接指定最高消费等级反而损失 GMV"就是这个极端。β 越大，效用越高，偏离也越大；而任一 β 给出的，都是同等偏离程度下效用最高的分布。所以调 β，就是在一条最优权衡曲线上选点，具体取值交给线上实验。

令、、，就得到 Multi-Game DT 的回报分布调整形式。

组织效能

我们既希望多路多目标召回是模型复用的，又希望保持“一人一业务，一人一 P0” 的并行迭代组织效能。

这件事可以类比 LLM 的后训练，有 Agentic 任务，代码任务，对话任务，每一个任务都同等重要，拆给了不同的子团队，但模型其实就一个。

MOPD——Multi-Teacher On-Policy Distillation 将不同领域的专项训练与最终能力整合分开：从共同起点出发，各领域独立进行 RL 训练，得到教师模型，再把这些教师的能力蒸馏到一个学生模型中。DeepSeek V4 的突出变化也是从混合 RL 改成 MOPD。

同一个模型里可以保留多路召回，每一路仍然对应自己的业务目标。要保留原来的组织效能，各团队就需要能够围绕自己负责的那一路，独立设计数据、优化目标、训练和实验，再把改进汇入共同模型。

对应到推荐系统，发现性、冷启动、广告等团队可以从共同的模型版本出发，分别训练自己的Expert。每个团队继续对自己负责的业务目标进行优化和验证。

DCGR 的条件分支对应各路召回。例如，发现性Expert学习在发现性条件下怎样生成商品，广告Expert学习在广告条件下怎样生成商品。统一模型通过对应条件学习各Expert的能力，线上再按这些条件生成各路候选。

这套流程可以这样组织：

各团队独立训练并验证自己负责的专项Expert。

统一模型在各业务条件下采样 SID 序列。

对应教师读取相同的上下文、条件与学生生成的 SID 前缀，提供下一 token 的概率监督。

通过 MOPD 更新统一模型，再按各业务指标验收整合后的版本。

线上由统一模型生成各路候选，保留各路的搜索配额和实验入口。

这样，各业务团队仍然对自己的一路召回负责，独立改进数据、目标和专项Expert，验证后通过 MOPD 将能力汇入共同模型；共享模型团队负责基座、蒸馏流程和统一发布，整合后的版本又成为下一轮专项训练的起点。DCGR 与 MOPD 配合，让“一人一业务，一人一 P0”的并行协作方式得以保留，同时共享线上模型的用户理解、商品知识和计算资源。

回到开头的问题：DCGR 有没有把双塔替代掉？更准确的回答是，它让"新增一个业务目标就要新增一路召回"不再是唯一选择。合并的是模型，不是团队：模型可以只有一个，OKR还是每人一个。

References

MOPD：多领域专项教师并行训练，再通过学生自身轨迹上的蒸馏完成能力整合。

OneTrans-V2：§4.2.1 介绍 DCGR，OneModel召回部分。

Reinforcement Learning Upside Down：结果与时间范围作为动作生成条件。

Decision Transformer：用期望回报条件化 Transformer 的动作序列生成。

Multi-Game Decision Transformers：在 Atari 多游戏中预测回报分布，通过偏向高回报，再条件化生成动作。直接对应 DCGR 的决策预测与概率偏置。