符合之前一贯的哲学，推荐系统里的问题用一个 Transformer 就能解决，如果不能那就再 Scaling 一下。用工程确定性取消算法的玄学性，把更多的精力用于算法和 Infra 的 Co-Desgin。 这是我年初写下的一个判断。现在回头看，这个趋势比当时预想得还要明显：越来越多公司的推荐系统开始收敛到 Transformer 架构。区别逐渐不再是“要不要 Transformer”，而是数据怎么 Tokenize、Attention 怎么做，以及如何通过算法和 Infra 的 Co-Design 把它 Scale 起来。

到今年 7 月，我工作就满 10 年。十年观察下来，毕业时起点相似的人，后来的差距甚至在 10 倍以上。有人第一个职级就卡住，换行业重启；有人顺利升两三级，一直升到天花板；也有人一直在跳槽，情况却越来越糟。这个差距不是努力决定的，能在大厂活下来的人，没有一个不努力。 决定差距的，是运气和认知。 运气不可控，认知可以。这篇文章想拆掉思维里的几堵墙（误区）。之后，正常的路径会自然显露出来，有些甚至是捷径。

生成式召回如果不是轻轻松松地拿到收益，大概率是做错了。 其实生成式比双塔简单 一方面，业界越来越多的人用生成式召回很快拿到了不小的业务结果；另一方面来与和传统召回对比，相比从零到一落地一套双塔召回，生成式召回在建模和 infra 上其实简单得多。这听起来有点反直觉：在一家推荐 Infra 足够成熟的公司里，上线一路双塔已经非常标准化，生成式召回反而容易被当成更新、更复杂的技术。但这只是因为业界在双塔上积累了接近十年的 Infra 和认知，很多今天看来理所当然的能力，当年都不是免费的。

Transformer 在推荐系统中也开始被广泛地采用，加上参数和算力的 Scaling Up，可以持续地在推荐系统中获得收益。但是从日常面试中，我也发现大多数的推荐系统从业者缺乏对 Transformer 的基本认知，导致了在Scaling 中出现常识性地错误引发失败。 Transformer Scaling 的核心问题，是尺度匹配。 Transformer 从来不是一个可以随意放大的黑盒模型。当模型的深度和宽度发生变化时，residual stream 的尺度、每一层的梯度、参数更新量、Attention logit、优化器的二阶矩估计，甚至最优 learning rate 都会一起发生变化。如果这些量没有被控制在合适的区间里，增加的参数不但不会变成有效容量，反而可能让模型进入一个“能训练，但没有真正学好”的状态。

LeCun 在 2016 年的 NeurIPS 主题演讲上,提了一个被广泛引用的比喻:"如果智能是一块蛋糕,蛋糕主体是无监督学习,糖霜是监督学习,樱桃是强化学习。"刚提出来时备受质疑,因为那几年正是 ImageNet 监督学习的全盛期。十年过去,这个预言被 LLM 一步步兑现。 而推荐系统的 ML,绝大多数算力都压在监督学习上。那这块蛋糕的主体和樱桃,在哪里?

推荐系统 20 年来方法换了六七轮，但问题定义从未改变——始终是预测下一个 item。缺多样性、缺发现性、规则泛滥，根源都在这里。真正的范式改变不是换方法，而是重新定义问题：从 Next One 到 Next N。

我们先思考下，一个公司组织里，为什么需要 Leader，需要层级？任何一个超过几十人的组织都需要架构设计。这件事如此普遍，以至于我们很少追问：为什么需要组织架构？组织架构本质上在解决什么问题？ 表面上看，组织架构是在划分职责、分配资源、明确汇报关系。但如果往下挖一层，会发现一个有趣的视角：一个组织本质上是一个分布式信息处理系统。 外部信息进来，内部处理，输出决策和行动。组织架构定义的，其实是信息如何在这个系统里流动——谁产生信息，谁消费信息，信息经过哪些节点，在哪里被过滤，在哪里被聚合。

2017 年，Ilya Sutskever 读到《Attention Is All You Need》时，立即意识到”这就是我们需要的一切”。OpenAI 随即放弃了 RNN/LSTM 路线，全面转向 Transformer，催生出整个 GPT 系列。Transformer 的并行能力让他们得以实现一直相信的 Scaling 路径。八年后的今天，推荐系统终于走到了同样的路口。 2024 年之前，推荐领域有了 HSTU、TIGER 这样的工作，但大多数团队还在观望。2025 年，我观察到一个明显的转变：大家开始认真地把排序模型 Dense Scaling Up，搞生成式召回和端到端推荐。这很像 2017 年——当时大家忙着把 LR/GBDT/FM 切换到 Deep Model 和双塔，切换过程持续了一两年，之后再没人回头。我的判断是，2026 年将是推荐系统 All-In Transformer 的一年，不改变就落后。

在和很多产品、运营团队合作的过程中，我常不得不扮演那个“泼冷水”的角色，特别是当大家对推荐算法寄予厚望的时候。 听到这样的战略规划：“我们明年目标是增长 80%，推荐系统是其中的关键。” 我的观点很直接：如果你的增长战略严重依赖推荐算法，一旦算法效果不及预期，目标就直接崩盘，那么这本质上是一个糟糕的战略**。对于规模增长，推荐算法不能雪中送炭，它只能在规模之上锦上添花。

本文不是从系统优化角度谈复杂的模型的部署和优化问题，而是从行业成本角度，看线上推理多复杂的模型是可以满足成本及ROI要求的。 做一个假设： • 电商推荐行业，主要是更熟悉成本核算 • 部署标准的Transformer作为排序模型，参考OneTrans结构 • 参数规模对齐qwen2的系列模型，更直观看看能跑哪个尺寸

从精排切换成深度学习以来，工业界一直会把排序的模型结构研究切分成基本的两部分，序列处理和特征交叉，甚至有一些公司的排序组，下面都拆成两个Team分别处理行为序列和特征交叉。从最早的时候，比如序列用DIN来处理，序列就被压成了一个或多个向量表征，再参与与其他特征的交叉。我们可以理解成MLP(concat(DIN, Features))，发展到今天大多数的模型研究，还是分立地把MLP换成DCN，增加个LHUC，复杂化为Rank Mixer或Transformer，把DIN叠加MHA，直接换成Transformer，可以写成RankMixer(concat(Transformer, Features))。 从MLP(concat(DIN, Features))到RankMixer(concat(Transformer, Features))，本质没有变，就是序列处理和特征交叉是一个隐式的两阶段处理，序列被压缩到Vector Space才和特征发生交叉。而LLM的有趣之处，就是在Next Token Prediction利用到的交叉发生在词序列的Token Space之中，它能启发推荐排序模型的，就是每一个特征的交叉应该发生在用户序列的Token Space之中。