type
Post
status
Published
date
Sep 27, 2026
slug
OneTrans-V2
summary
符合之前一贯的哲学，推荐系统里的问题用一个 Transformer 就能解决，如果不能那就再 Scaling 一下。用工程确定性取消算法的玄学性，把更多的精力用于算法和 Infra 的 Co-Desgin。
这是我年初写下的一个判断。现在回头看，这个趋势比当时预想得还要明显：越来越多公司的推荐系统开始收敛到 Transformer 架构。区别逐渐不再是“要不要 Transformer”，而是数据怎么 Tokenize、Attention 怎么做，以及如何通过算法和 Infra 的 Co-Design 把它 Scale 起来。
tags
推荐
category
推荐系统
icon
password
priority
3
符合之前一贯的哲学，推荐系统里的问题用一个 Transformer 就能解决，如果不能那就再 Scaling 一下。用工程确定性取消算法的玄学性，把更多的精力用于算法和 Infra 的 Co-Desgin。
OneTrans-V2 用一个 Transformer 统一召回、粗排、精排：https://arxiv.org/abs/2609.28589
All in Transformer
这是我年初在这篇里写下的判断：
现在回头看，这个趋势比预想的还要明显：越来越多公司的推荐系统开始收敛到 Transformer。有些工作换了注意力形式、改了 FFN，起了新名字，但本质都是 Transformer：Token 化的输入、注意力做 Token 间的信息交互、逐层残差堆叠。区别不再是"要不要 Transformer"，而是数据怎么 Tokenize、Attention 怎么做，以及如何通过算法和 Infra 的 Co-Design 把它 Scale 起来。
看几个代表性的工作：OneTrans 把数据组织成行为序列加多个 Feature Token，连独立的特征交叉模块都取消了；X 开源的 Phoenix Ranker 是标准 Transformer，Candidate 作为 Token 接在序列后面，用 Mask 做候选隔离；HSTU 和 ULTRA-HSTU 走另一个方向，让一个 Token 尽可能代表一次完整 interaction，然后 Scaling 序列长度；美团的 MTGR 在 HSTU 基础上保留了 DLRM 的丰富特征，MTFM-V2 进一步把一个 Target 拆成多个 Token，某种意义上向 OneTrans 的 feature multi-token 方向靠近了一步。
所以现在回头看，业界的数据组织形式其实已经越来越趋同：
真正的区别，无非是一个 Target 放几个 Token、哪些 Token 能互相 Attention、序列能拉多长，以及这些计算怎样被 Infra 高效承接。再往后，这些模型可能越来越难从架构图上区分，大家都是把序列和特征变成 Token 塞进去，再围绕业务改 Attention Pattern、Mask 和 Token Compression。
推荐算法正在从"设计一个更复杂的模型"，变成"设计一种更好的数据组织和 Scaling 方式"。
当 Backbone 收敛到 Transformer 以后，真正值得投入的地方就变成了输入和参数的 Scaling，以及算法和 Infra 的 Co-Design。
OneModel的思考
OneTrans-V1 用一个 Transformer 统一了序列表征和特征交叉，OneTrans-V2 用一个Transformer统一推荐级联链路的 3 个核心任务，做到 OneModel。严格意义上是 Point-wise 任务的 OneModel。
关于 OneModel 端到端的理解，HSTU 是一个任务里包含了召回和排序，但据我所知更多地落地了排序；OneRec 的思路是一个生成式模型，用原来的 Point-wise Ranking 做 Reward Model进行强化训练，claim 端到端替代老链路。
之前和一个候选人聊天，他说想做端到端，我说可以做，但是还是要召回和排序的两段式，它起初是不理解的，这叫什么端到端？那我们来想一个标准的知识检索，原始问题改写 query和 embedding 化，先倒排/向量检索，BM25，再来一个复杂模型的排序。但有了 LLM 之后的 RAG 变成了，把原始问题 prefill 进Transformer，然后输出query 和工具调用指令，查 RAG，查询结果直接塞进 Transformer 的 Context，然后生成用户想要的答案，这个过程中多次 Prefill 和 Decode调用 一个 Transformer 模型，它是 OneModel 和端到端的吗？
答案一定是“是的”，换到推荐系统也是一样的，只要一个模型，它的 Context 是共享或连续的，它做多次调用也是端到端的，而级联是IR领域有信息论支撑的Solid 模式，我理解的 OneModel 和端到端是并不放弃级联架构的。
怎么实现呢？简单到令人发指，在 OneTrans 架构下，精排多特征 Token work，粗排不用交叉特征单 Token work，生成式召回work，它们的用户序列输入是一模一样的，那么在一套（精排）样本直接 Co-Train 就好了。
这个简单性是超出我预期的，年初规划的时候画了类似架构图，但是预期中这是很困难的一件事。精排负责人把所有任务黏在一起的时候，发现它既简单又有效。
我觉得很多人会跳出来说，这有啥创新呢？我觉得这件事吧，就像那个圆珠笔和铅笔的段子：为了在太空写字，可以专门发明一支圆珠笔，也可以直接用铅笔。星舰也是一样，为了扛住再入的高温，可以去研究更复杂的隔热方案，也可以直接上耐高温的不锈钢，这种简单性才能使它普适。比如 OneRec 那套 RL 系统，我想想也都费劲，这是每一个公司都能玩明白的吗？但是你用 OneTrans 架构把全链路统一掉，既简单又高效。
效果上相互增益：
一个模型里精排蒸馏粗排，大幅涨点并提升粗精一致性：
统一了用户侧序列建模，训练和推理时的序列前向 Flops 只付出了一次，共享计算后能实现Flops 的 3 倍节省。而 Scaling 可以统一来做，而不是需要 3 个 子 Team 来做 3 遍。
当然它也有副作用，就是我们优秀的粗排负责人做完了粗排 OneTrans，达成粗精合并后，最后去了其他公司当 Leader 了。召粗精合并之后，我直接取消了召回组作为和精排平行的组织架构，召回负责人去另一个业务做技术 Leader 了。但于公司而言，这是极大地节省人力的。
DCGR：offline 强化生成式召回
在生成SID之前，先生成 Decision-Token，它包含两类：一类是期待召回结果达到的 Reward，另一类是期待召回结果具备的属性。比如，期待的结果有更高的平均价格，或期待的结果有更高的发现性。
在推理时，自然地产生这些 Decision 概率分布，然后根据目标和业务的期待可以调整。它解决了召回无法灵活调控目标的问题，也能够在 Beam Search 的时候分配 Decision Token达成多路召回的效果，在OneModel 下，如何用一路召回去替代多路召回达成不同的业务目标。
这个机制，paper 里叫 Decision-Conditioned GR，内部我们叫它 CoT。其实是受到 CoT 的启发，它确实和 CoT 类似可以通过多推几个 token 来达成test-time scaling 提升性能的效果。
它背后的原理来自于离线强化学习。
OneRec 在生成式模型之上搭建了 Online 强化学习，这很自然，受到 LLM 启发，监督学习之后，强化学习调整生成概率到期望Reward的概率。这里面使用 Reward Model 会有 Reward hacking 的问题，直接投给用户拿反馈又有Off-Policy 的问题，这里面有太多 LLM 都没搞明白的问题，值得挑战，但是成为普适标配的可能性比较低。
如果 RL 的引入只是为了微调生成概率，匹配想要的业务目标，那 Offline RL 是一个选择，它本身研究的就是如何在一个静态数据集合上，完全不产生新 interaction 的情况，学习到一个更强的策略。
DCGR 的本质是一次单步的Upside-Down RL，传统 RL 是给定状态学动作，再用 reward 去修正策略。颠倒RL 把这个过程颠倒过来：把期望的结果当作输入，让模型直接学"要达到这个结果，应该采取什么动作"。训练就是普通的监督学习，结果和动作都从历史轨迹里读出。
DCGR 做的正是这件事：decision prefix 就是 outcome，SID 就是 action，所有 label 都来自日志，推推理时的β偏移是在KL约束下向业务目标做策略改进。它不是一个地基不牢靠的 idea，而是背后有整个 offline RL 的研究所支撑，但却简单到几乎零成本复刻。
另外说一声，实际上头部的公司生成式召回都是普遍落地的，所以现在还认为生成式是个噱头的，已经在技术上落后很远了。
Scaling 与稳定性
Scaling 统一采用Sparse MoE 架构，控制住激活量，持续提升模型总容量。它背后的逻辑和 LLM 类似，是始终考虑硬件的 Co-Desgin。
GPU 上有三种资源：计算、显存带宽和显存容量。Dense 模型扩容时这三者是绑在一起涨的，参数翻倍，每个 token 的 FLOPs 和访存也翻倍。而推荐模型的一个特点是有效 batch 很大，一次请求几百上千个候选，训练时同一用户的曝光又被聚合在一起，所以 Dense 模型跑在 roofline 的 compute-bound 区域，算力打满的时候，带宽和容量其实是闲着的。
MoE 的本质，是把闲置的带宽和显存容量兑换成模型容量。
稳定性之前有聊过，这里实际才是真正有技术含量的部分，对应的人才是稀缺的。甚至说，为什么 LLM 的人特别贵，本质也是因为大规模的 Transformer 并不好训练，Infra正确性和训练稳定性是关键问题，真正有机会在大规模训练中积累经验的机会本身就是稀缺的。
训推优化
训练和推理的优化，本质上都在解决同一个问题：长序列只算一次。
训练侧，OneTrans 的时候已经把计算在一次 request 上做了序列共享，但本质它依旧是以 request 为核心的样本组织方案，在超长序列的场景下，实际造成了训练时大量的计算浪费。实际上，样本可以处理成以序列为核心的，一个大的窗口里的曝光聚合并挂载到时间线上。
它不是 HSTU 那样非常极致的把样本处理成非常纯粹的序列，因为我们发现精排积累的几千个特征并不好塞成一个 event 的 side-info。追求简单，就是让序列为中心，曝光样本做一定的窗口聚合，来共享序列的计算，我们称之为 Sequence-Native Training（SNT）。它没有那么玄妙，本质是充分利用了序列的 Causal Attention 性质：长序列仅计算一次，每一个 request 按照时间插在这条序列上，处理的时候只需要根据时间戳关系计算一个 Mask，即可高效并行，训练加速 4.4 倍。
推理侧是同样的逻辑，只是共享的维度从曝光变成了阶段。行为 token 永远不 attend 阶段 token，所以用户序列的 KV 和任何候选都无关，只需要算一次，就可以被召回、粗排、精排三个阶段反复读取。
这和前面说的 RAG 是同一件事：一次 Prefill，多次调用同一个 Transformer。
最后
回到开头那句话：推荐系统里的问题用一个 Transformer 就能解决，如果不能，那就再 Scaling 一下。OneTrans 从 V1 到 V2，其实就是这句话的两次兑现。V1 把序列建模和特征交叉收进一个 Transformer，V2 把召回、粗排、精排收进一个 Transformer。每一步看起来都不复杂，甚至会有人觉得"这也能叫创新"，但恰恰是这种不复杂，让它可以被复制、被迭代、被 Scale。
当 Backbone 收敛之后，算法的确定性来自工程，而不是来自某个巧妙的模块设计。
过去推荐算法的很多工作，是在一个固定的算力预算里找更聪明的结构，这类收益往往难以复现，换个场景就失效，带着很强的玄学色彩。而统一到 Transformer 之后，问题变成了可以量化的工程问题：数据怎么组织成 Token，Mask 怎么设计，计算怎么共享，参数怎么在硬件约束下 Scale，训练怎么保持稳定。这些问题有明确的答案，也有明确的投入产出，团队的精力可以从"猜结构"转向算法和 Infra 的 Co-Design。
这对组织的影响同样深远。以前一条推荐链路需要召回、粗排、精排三个平行的团队，各自维护模型、各自做 Scaling、各自对齐目标。现在一个模型、一套样本、一次 Scaling，人力可以集中到真正稀缺的地方：训练稳定性、Infra 正确性、以及更长的序列和更大的模型。这个过程对个人来说未必轻松，但对技术方向来说是必然。
当然，OneTrans-V2 远不是终点。它严格意义上还是 Point-wise 任务的 OneModel，List-wise 的重排和生成还没有纳入；DCGR 是单步的 Offline RL，能调控的是一次交互的目标，而留存、用户长期价值这类跨多次交互的目标，最终还是需要更完整的 RL 框架。
但方向已经很清楚了：不放弃级联，不放弃特征，不追求架构上的机巧，用一个 Transformer 把能统一的都统一掉，然后 Scaling。
招聘
已经读到了这里，顺便介绍一下我们的团队。
我们是 TikTok（TT）的电商推荐 Foundation 团队，负责 TT 电商交易链路上的商品和内容推荐，以及电商 Foundation Model 的构建。产品形式丰富，也意味着能接触到各类场景对应的技术问题。不同于很多电商的独立 App，TT 里推荐场景是 GMV 的发动机，业务里有东南亚这样的成熟市场，也有美国、欧洲的快速增长。Base 地包括新加坡、北京、上海、杭州。新加坡 6 点准时提包走人，国内内心强大也可以尝试 6 点下班。
目前整个系统所有的核心模型均基于 Transformer 构建，技术栈贴近 LLM，包括OneTrans 召粗精、基于生成式 RL 的重混排，以 Scaling Up 为核心迭代，以 GPU 高效利用为 Infra 导向。下一个里程碑是推荐系统 Foundation Model 的构建，实现 List-Wise 端到端。我们希望推荐及跨领域的人才加入，一起攻克难题，定义未来。
此刻像极了 15 年左右，那时很多推荐系统就是一个简单的协同过滤算法，业界是一步一步才形成了经验和共识，比如多阶段的推荐系统。
现在是定义未来推荐系统新范式的混沌时刻，期待你的加入，欢迎私信。