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

我们招一个有经验的人进来，通常默认他的价值是"做过"：他知道方案，知道坑在哪里，所以能更快把事情做出来。 但仔细想会发现一个问题。换了公司，infra 不一样，数据不一样，业务约束和组织形态也不一样，他以前的实现细节可能 80% 都没法复用。他不可能在新环境里照搬旧方案。 那他凭什么还是能做出来？我的答案是：他未必知道路径，但他见过终点，知道这件事是能做出来的。他见过，所以他相信。 人和人的差距，很多时候不是能力，而是看见和相信。一个人没办法做出他不相信的东西，再强的人也不行。

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

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

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

第一次听到“技术深度”这个词，是我工作的第二年。那时候我觉得工作已经比较得心应手，绩效反馈也很好，拿到了第一次晋升机会。但在 review 的过程中，我第一次被挑战了一个问题：技术深度不足。 我其实没有理解什么叫“技术深度”，第一反应是“技术难度”。当时我的工作都很业务导向，但也不乏有难度的项目，比如在几乎没有 Infra 的前提下搭建了一版双塔召回。部门的 Leader，也是当时的评委，给我举了一个例子。他说他在 review 达摩院的晋升时，会看到有人把失败的实验也放在 PPT 上，不只是知道什么方法成功了，还要知道哪些因素导致成功、哪些因素导致失败，要知其所以然。

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

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

最近 DeepSeek V4 的多专家整合方案采用了OPD（On-Policy Distillation），在工业级项目上证明了OPD 在后训练中占据一席之地。而它的进阶版本OPSD（On-Policy Self-Distillation）也在 Cursor 的模型训练上大规模使用，并且展现出在利用隐式反馈数据，定向纠错和持续学习上的潜力。 文章包括： • 知识蒸馏的 3 种范式：KD，OPD，OPSD。 • RLVR 的信用分配问题与稀疏 Reward问题，OPSD能联合弥补，定向纠错 • OPSD 不局限于显式的人类标注（RLHF），有潜力利用文本隐式用户反馈持续学习。

在 DeepSeek-V4，MiMo-V2，Minimax-M2，Qwen3-Next，GLM-4.5 的最新技术报告里，有一个被共同采用的技术模块MTP（Multi-Token Prediction）。它不仅作为预训练的辅助 loss，提升了模型效果，又能作为 draft model 进行投机解码推理加速，实现了多快好省，变成了 LLM 标配之选。

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

之前是一次开放性的问答，问到了这个问题。可以有非常多的答案，比如通常的说法，更专注于代码能力，代码加速了模型的研发，形成了飞轮；更加专注于 B 端付费客户，比起 C 端没有成型的商业模式，B 端可以一边赚钱，一边积累真实的问题解决反馈。 这些肯定都是，但是我觉得那都是伴随着大量表象的或然，它背后的必然是什么？我认为是一种认知，我最近深刻地认识到：在技术的变革期，你的 Team 当下能落地什么，取决于一年前的认知，模型很大，建立新的 Infra 需要时间，这个放到推荐系统是这样，在 LLM 的发展期（20～26）就影响了更大的时间尺度。