互联网持续晋升指南

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

重新理解生成式召回:从负采样到物品编码

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

推荐系统技术深度与技术品味

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

推荐系统Transformer Scaling的基础认知

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

推荐系统迭代的本质是 Scaling:结构只是摩擦系数,Infra 才是核心能力

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

推荐系统的"蛋糕范式"缺失

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

生成式推荐 (Generative Recommendation) 工业界深度 Survey

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

算法组织熵减与Scaling Law的悖论

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