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

Scaling 这个词从 LLM 扩展到推荐系统，最近也是驱动了推荐系统的核心收益。它有 Scaling Law 的 paper 提出，原本是指算力、参数、数据和 Loss 的 powerlaw 经验关系。由于推荐系统一直也是用全数据的，那么实际就是指扩展推荐模型的网络参数量，能够持续稳定地提升离线指标。 之前迭代了很久的成熟的工业模型，折腾网络结构和特征，每次迭代收益来到了千分位，突然又能有几个百分点地提升了，这就是网络参数 Scaling 的魅力，和转为业界共识的核心原因。 但这不是推荐系统的第一次 Scaling，或者说 网络参数Scaling 背后是一种做推荐目标优化的思维方式：放弃掉算法局部技巧的细枝末节，找到一个可以扩展的轴，转动它能够稳定地影响业务指标，你就把一个玄妙未定的算法研究问题转化成了稳定可预期的工程问题。

覆盖 101 篇核心论文（58 篇工业界 + 43 篇学术精选），系统梳理 2022-2026 年生成式推荐从学术概念到工业主流范式的完整技术演进。以 TIGER、HSTU、OneRec 等里程碑论文为核心，深入分析 Semantic ID、模型架构、训练范式、推理增强、长序列建模等关键技术方向。

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

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