沿着之前一贯的哲学，推荐系统里的问题用一个 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。
本文为订阅内容
订阅 RecsysFrontier，在 Substack 阅读本文全文
- 每天的 AI / 推荐系统前沿日报，第一时间读到
- 每周周报，一周重点一次看完
- 订阅期内所有日报周报全文