生成式推荐与推荐大模型：工业落地全景调研

这两年我参加的每一场推荐系统技术分享几乎都会被同一个问题打断生成式推荐到底是不是又一个被包装出来的概念到2026年再回头看答案其实已经比较清晰——它没有替代传统推荐链路但它在悄悄改写工业推荐的上限。这个从Large Recommendation Model到Recommendation Foundation Model的演进不是单纯的“把模型变大”而是一整套关于数据、架构、训练范式和评估体系的重新设计。这篇调研算是我把过去一年看到的论文、开源项目、工业分享以及自己动手复现的一些实验结果做了一个交叉验证后的整理。内容主要围绕Generative Recommendation、Large Recommendation Model、Recommendation Foundation Model这三个词展开重点聊工业界真正在解决的问题而不是学术论文里的理想假设。如果你是做推荐系统算法或架构的工程师或者正在给团队做技术选型这里面会有一些可以直接拿去用的判断框架。1. 为什么工业界正在重写推荐系统的技术栈——三个正在被推翻的旧假设我入行做推荐那会儿整个系统的骨架是极其稳定的召回、粗排、精排、重排再加一层混排每一层各司其职。双塔模型统治召回Deep Interest Network那一代模型统治精排特征工程占据了我们一大半的工时。这个架构能跑这么多年是因为它背后有三个很朴素、很自洽的假设但如今这三个假设正在被一项一项推翻。第一个被推翻的假设是用户意图可以被拆分成独立的、可计算的标签。传统推荐本质上是一个判别式任务我们根据用户历史行为预测他会不会点某个商品或者会喜欢哪一类内容。但用户的真实意图往往是连续的甚至是模型自己都很难用几个标签概括的。生成式推荐从第一天起就不走这条路它把用户行为序列当成一段“语言”直接生成用户下一步最可能交互的候选对象。2023年前后Meta提出的GR4RecGenerative Retrieval for Sequential Recommendation就是用T5式的Encoder-Decoder结构把用户行为编码之后直接输出item的token序列这个思路在当时争议很大但后来的工业实践表明生成式方法在长尾兴趣挖掘上确实有判别式方法抓不到的优势。第二个被推翻的假设是item是一个静态的、可以通过精确检索得到的对象。传统召回里每个item对应一个Embedding向量我们建ANN索引去做近邻检索。但item在海量场景下是动态变化的新商品每天大量入库Embedding本身也是模型训练过程中不断漂移的。生成式推荐换了一种方式把item当作生成目标而不是检索目标。模型学习的是用户状态到item id或item语义之间的映射关系这相当于把“从千万级候选里捞一百个”的问题变成了“根据上下文逐步解码出最合理的候选集合”的问题。工业界落地时通常不会完全放弃检索而是把生成式模型当作候选生成器再配合轻量级检索做召回兜底。第三个被推翻的假设是漏斗的各阶段可以独立优化。传统链路的召回模型、精排模型各自训练各自调参目标不一致的问题始终存在。而Large Recommendation Model的核心逻辑就是把召回、粗排、精排甚至重排的目标统一到一个模型里所有阶段共享一套特征表示和一套优化目标。我在调研里看到的最典型实践是2023到2024年公开的HSTUHierarchical Sequential Transduction Unit架构它被用于统一召回和精排场景一个模型承担了传统链路多个模型的工作。这三个假设的松动不是某篇论文一次性完成的而是过去三四年里整个社区一点点拱出来的。到2026年这个趋势已经从学术界蔓延到工业界大家讨论的不再是“要不要做生成式推荐”而是“怎么在现有系统里安全地把这条路走通”。2. 生成式推荐在工业场景的工程化真相并非让模型“生成”商品很多人第一次听生成式推荐会下意识觉得这不就是让模型凭空编一个商品出来吗这完全是误解。工业场景里生成式模型的目标是生成“已有商品库中的一个合法候选”而不是无中生有。所以工程化的第一步是把商品库变成模型可以生成的形式这一步直接决定了后面所有效果和稳定性。2.1 商品库怎么做Token化离散ID、语义Embedding与混合方案要让生成式模型输出候选首先得解决“输出什么”的问题。目前工业界主流做法有三种各有各的适用场景。第一种是离散token化就是把每个item映射成一个唯一的token ID模型解码时直接在完整的item ID词表上输出。GR4Rec那一派的做法就是这种优点在于生成结果天然可对齐到具体商品缺点是词表规模非常大——淘宝、抖音这种体量item数量是千万甚至亿级的softmax层直接没法算。通常要用采样、层次softmax、或者把候选集切成多个桶来缓解。第二种是语义空间生成也就是模型输出的不是item ID而是一个在item Embedding空间里做检索的向量。E5Rec这类方案就是这么干的模型生成一个目标Embedding然后用它去向量库里做KNN检索。这个方案的优点是训练和推理成本可控生成的不是一个硬性ID而是一个“目标表示”系统天生能兼容新入库的item因为新item只需要算好Embedding进向量库不需要重新训模型。缺点也明显——生成Embedding是在连续空间里做检索存在召回不稳定的问题模型稍微偏一点检索结果就可能抖。第三种是混合方案也是我见过工业落地效率最高的模型先生成粗粒度的聚类token或者品类token再在对应小候选桶里做生成或打分。本质上相当于用生成式模型做了一个层级路由既避免了千万级词表的开销又保留了生成式方法对用户状态建模的灵活性。我做复现实验时强烈不建议一上来就自研tokenizer。先用业界开源的序列推荐模型跑通全链路把tokenization、采样策略、去重逻辑弄明白再根据你自己的数据分布去优化这是弯路最少的路。2.2 生成式召回能扛住十亿候选吗采样、打分、去重的真实流程这是工程师最关心的问题。目前没有任何一个生产级系统敢让生成模型在十亿候选上做完整softmax谁说自己行大概率是为了拿投资。工业界的真实流程几乎都是生成、采样、打分、去重四步走。第一步模型解码器生成候选。这里不是只取argmax而是会做beam search或者随机采样一次性拿到几十到几百个候选的集合。比如beam size设为64模型一次前向能得到64个候选item序列。第二步轻量召回兜底。生成式模型的召回率再高也需要用传统的双塔或向量召回补齐它在热门item上的覆盖缺口。第三步把生成候选和召回候选合并去重喂给后续的精排模型。第四步精排或粗排模型统一打分只保留打分靠前的进入重排。我调研过的工业案例里绝大多数团队会把生成式模型当作“新增一路召回信号”而不是替换掉原有召回体系。这么做有两个好处一是风险可控原有链路照常运行新信号只做增量二是生成式模型产出的候选往往带着更丰富的上下文信息融合进精排后确实能明显提升长尾场景的多样性。如果你团队里有人说要把召回整体替换成生成式我建议你先让他做AB实验用数据说话而不是拍板推倒重来。2.3 生成式排序与列表级生成从单点打分到整页序列除了召回生成式思路也在渗透排序阶段。传统精排是逐点打分但用户感知到的其实是一整个列表列表内部的前后顺序、多样性与相互影响逐点模型是看不全的。生成式排序的做法是把用户当前请求的上下文作为输入直接解码出一个完整的推荐列表模型的损失函数学习的是“这个列表好不好”而不是“这个item单独好不好”。这一类工作在学术界叫Listwise Generative Ranking工业界落地比较少但我看到已经有团队在重排场景里试水。比如用自回归生成器逐位生成排序列表每一步都考虑前面已经放进去的item再决定下一个放什么。这样天然能控制多样性约束比如两个同类item不能相邻或者前三位必须覆盖不同品类。不过这条路目前的工程难点是生成序列的长度受限解码速度跟不上高并发请求。实际落地一般会退化成“先生成打分再列表约束”或者只在小流量场景验证。我有一个判断列表级生成在2026年还不会成为主流但它给重排和混排的未来提供了很明确的方向至少在长视频、信息流这种对列表体验极其敏感的场景里值得认真跟下去。3. HSTU、训练基建与全链路统一LRM不是把模型做大那么简单说到Large Recommendation Model最具代表性的公开工作就是LinkedIn在2024年前后展示的HSTU架构和基于它的RankGPT路线。很多人看到“Large”就以为是GPT那套暴涨参数量、海量GPU的玩法但在推荐场景里“大”指的是数据规模、序列长度和全链路统一程度而不是纯参数体量。3.1 为什么推荐场景需要一套不同于Transformer的新架构推荐模型面对的用户行为序列有几个特点极长、带有强时间因果性、包含大量异质的动作类型。拿标准Transformer来处理这种序列Self-Attention的平方复杂度会直接拖垮训练而且用户行为里大量是“看了没点”“点了没买”这类弱信号普通Transformer很难高效建模。HSTU的核心改动是用Gated Retention机制替代了传统的Self-Attention把序列建模的复杂度降到了接近线性。Gated Retention把Attention里的Softmax去掉换成可学习的门控和衰减因子让模型能灵活决定“记住”还是“遗忘”历史行为而不是机械地对所有历史行为做加权平均。这个改动从数学上看并不复杂但带来的收益很实际训练吞吐更高、长序列建模更稳定、推理时可以做状态缓存适合在线实时服务。我的理解是HSTU对于推荐大模型的意义不在于它发明了什么特别玄妙的东西而在于它证明了“工业推荐模型可以由一个深度、自回归、因果建模的统一架构承载”而不是继续靠堆积不同场景的独立小模型过日子。这是LRM最关键的一步。3.2 LRM的三大工程瓶颈特征异质性、训练稳定性与推理吞吐架构只是第一步真正让LRM工程化困难的是三个实际问题。首先是特征异质性。推荐系统的输入特征极其复杂有用户ID、商品ID这种离散特征有价格、时长这类稠密数值特征有图文、视频内容这种多模态特征还有实时统计类特征。要把它们统一塞进一个自回归模型需要一套非常繁琐的特征处理与融合模块。我调研的几家公司的做法一般是离散特征做table embedding数值特征做分箱或多层MLP编码多模态特征用pre-trained encoder抽向量再统一拼接到序列token里。这个部分不性感但工作量极大往往是整个项目周期里最耗时的一块。其次是训练稳定性。大模型训练最怕loss震荡和nan而推荐数据天然存在样本不均衡、反馈延迟、稀疏性问题。很多团队复现HSTU时都遇到过训练中期指标突然崩掉的情况最常见的诱因是学习率与lr scheduler没有配合好以及embedding层的初始化方式不对。我的建议是大规模实验之前先在小规模数据上做完稳定性测试把梯度裁剪值、学习率上下界、embedding初始化标准差这几个超参固定住再谈效果优化。第三是推理吞吐。一个统一大模型要承担召回和精排的职责在线延迟必须在几十毫秒内。这要求服务端做非常精细的工程优化KV cache、算子融合、量化压缩、batch推理甚至按业务高峰做模型分片。很多团队在离线指标上看到LRM很香一上在线就被延迟和吞吐打回原形最后退化成只用它的精排打分能力等于买椟还珠。3.3 全链路统一不是必须Transformer工业界的折中方案这里我想给一个更清醒的判断LRM不等于一定要用Transformer或HSTU。全链路统一的本质是“所有阶段共享一套表示和优化目标”架构只是实现手段。我调研到的折中方案大概有三类。第一类是“双塔升级版”用一个大容量共享底层上面长出不同任务头召回一个头、精排一个头这种方式改动小适合快速落地。第二类是“重排优先”把统一大模型先用在重排和精排上召回暂时不动通过蒸馏把大模型的知识反哺给线上小模型。第三类才是彻底的自回归统一模型代表就是HSTU路线目前能走通的团队极少但一旦走通收益也最明显。如果让我给建议中小团队别直接all in自回归统一大模型从第二类入手最稳。先让大模型在离线把特征表示学好然后蒸馏给线上模型既有收益又把风险控制在原有链路内。这是2026年最务实的一条LRM落地路径。4. Recommendation Foundation Model的路线之争通用泛化还是领域穷举从LRM再往前走一步就到了Recommendation Foundation Model。这是当前争议最大、也最被炒作的概念。我不打算回避直接把两种分歧摆在台面上说。4.1 此“基础模型”非彼“基础模型”NLP里的Foundation Model比如GPT系列底座是在海量文本上预训练的通用模型然后靠微调适配下游任务。但推荐的“基础模型”面临一个天然难题item空间是动态的、私有的每个平台有自己完全不同的商品库今天上架的item明天可能下架用户的兴趣也在实时漂移。你很难像NLP那样先在一个巨大但静态的语料上预训练因为推荐领域没有“通用语料”这种东西。所以现在行业里对RFM的理解已经分成了两派。一派认为推荐基础模型是指能处理“任意推荐任务”的统一模型——跨场景、跨任务、跨模态用一套参数做召回、排序、重排和推荐理由生成。另一派认为推荐基础模型更像一个“推荐数据引擎”重点不是模型参数大而是建立一套能持续吸收多平台异构数据的训练基础设施。我个人更认同后者的可落地性前者的宏大叙事容易让团队陷入很长时间的无效研发。4.2 跨域泛化与冷启动迁移实验要证明什么如果一定要往RFM方向走最好先把冷启动和跨域泛化的验证体系建立起来。我看过不少号称Foundation Model的项目其实只是在A域上训练、在B域上测试效果还没跑赢单域模型就说自己“具备泛化能力”。这是很典型的“自证陷阱”。跨域泛化实验至少要做三件事第一源域数据量远大于目标域验证模型在目标域数据稀疏时是否依然有效第二目标域不能出现在训练阶段验证模型是否只是记住了数据分布而非真正学会了推荐逻辑第三必须对比单域基线、跨域微调基线、以及零样本直接迁移三种设定缺一不可。以我自己的经验一个真正有价值的RFM探索会刻意把用户行为序列抽象成与具体item无关的行为模式语言——比如“点击-加购-浏览详情页-退货”这种抽象动作序列再加一层item侧的内容理解。这样模型学到的才是“人在做决策时的规律”而不是“这个平台的历史记录”。这个方向目前还很早期但它是RFM真正的价值所在值得长期投入。4.3 推荐基础模型的评测难题离线指标、在线指标与用户长期价值最后必须聊一下评测。推荐基础模型带来了一个很尴尬的问题传统离线指标比如NDCG、Recall、AUC在这类模型上已经不够用了。因为生成式模型的目标不是最大化单点点击概率而是建模用户连续的行为过程。离线你很难模拟“用户在推荐列表里看了一个item后决定不再看下一个”这种因果反馈。更麻烦的是用户长期价值指标比如月度留存和活跃时长根本没法在离线AB里测只能跑很长时间的在线实验。我见过一个团队在RFM的长期AB上跑了三个月前六周指标几乎持平后六周才开始拉开差距。这种长周期验证对团队耐心和成本预算都是巨大考验。如果你负责RFM项目的评审我建议把评估拆成三层第一层是传统离线效果保证不崩第二层是短周期在线指标包括点击、时长、互动率第三层才是长周期留存与商业化指标。三层之间允许指标有背离但要能解释背离的原因。不能解释的背离都是风险信号而不是创新突破。5. 工业落地路径推演三浪叠加从检索增强到生成式副驾说了这么多框架层面的东西肯定有人想问我们团队明年应该怎么规划我自己比较倾向用“三浪叠加”的思路来做节奏控制既不走太快也不错过窗口。5.1 第一浪2026年正当时生成式模型嵌入现有链路这个阶段的核心是把生成式能力当作增强组件接入现有漏斗。最典型的实践是新增一路生成式召回或者用生成式模型做重排阶段的列表优化。工作重点放在候选生成成功率、时延预算、以及和现有精排模型的协同训练。体感上是“旧瓶装新酒”系统架构不动外挂一个生成式模块。这个阶段的好处是风险极低、见效快团队也能积累起对生成式模型数据的敏感度。我给团队定的原则是任何生成式模块上线前必须先跑通一个“最差情况测试”——模型抽风时兜底链路能不能兜住。这一步不过功能坚决不上。5.2 第二浪全链路统一模型带来的交互范式变化第一浪跑通后你会积累大量关于数据、特征、训练和延迟的经验这时候才有资格开始动核心链路。第二浪的目标是逐步把召回、精排、重排合并到同一个LRM架构里用HSTU类的方法或改良版Transformer替代多个独立模型。这个阶段最大的变化不在算法而在交互范式原本各阶段模型独立打分、独立排序现在变成了一个模型在内部做分层解码不同的业务module共享底层表示。你需要重新设计线上服务架构、离线训练流水线和监控体系。我测算过一个中型团队50人左右的改造周期从启动到稳定至少需要两个季度这还是建立在第一浪积累充分的前提下。5.3 第三浪基础设施改造清单与团队能力要求等你有能力驾驭LRM再谈真正的Foundation Model。这一浪已经不只是算法问题而是基础设施问题。我列一个自己推演的改造清单供参考。数据层面需要统一的序列化数据格式把用户行为、item内容、上下文特征全部抽象成同构token并支持流式回放。模型层面需要支持长序列训练的高性能框架最好是能切换Attention和Retention两种算子方便做架构实验。服务层面需要有状态的推理服务支持KV cache复用和小batch高并发模型分片需要支持动态扩容。评估层面需要建设多指标长周期AB平台特别是长期价值追踪系统。团队层面算法工程师至少要有PyTorch分布式训练经验还要有人能啃CUDA优化纯调包团队做不了这件事。我的真心话是这第三浪不是所有团队都需要追也不是所有业务都需要RFM的统一能力。如果你所在平台的核心矛盾是单场景效率老老实实把LRM做到极致就够了。RFM更像是一张远期门票什么时候买、买不买取决于你公司的业务阶段和竞争格局。6. 给做技术选型的人我从复现和调研里总结的七条经验最后这部分不写系统性章节了分享一些我在调研和复现过程中收获的、比较零散但很真实的经验希望能帮你少踩几个坑。第一不要用离线指标给自己壮胆。生成式推荐模型在离线指标上通常很漂亮因为它的生成目标与训练目标一致评估时也容易获得高相关性的项目但在线上延迟、候选新鲜度、覆盖率和用户即时反馈会稀释它的优势。我见过不止一个团队因为离线Recall提升2%兴师动众上线最后线上效果打平甚至负向。上线前一定要给自己设计一版“最坏情况测试”。第二生成时延是第一个要解决的工程问题不是第二个。如果一个生成式模型p99延迟超过100ms我建议就不要进入在线AB了先优化推理管线。现在的方案里KV cache 量化 batch是性价比最高的三板斧先把这三样做熟再往上聊架构创新。第三候选稳定性的问题比你想的严重。生成式模型在beam search时容易出现同一个用户每次请求生成不同的候选集合用户感知就是推荐列表“飘”。这个问题在GR4Rec时代就被讨论过到了工业大模型阶段依然存在。解决方案一般是固化随机种子、引入确定性解码策略或者限制生成候选的更新频率。第四新item的入库流程必须单独设计。生成式推荐对已知item很友好但新item如果没有历史交互生成器可能出现“无中生有”。我把这个称为“生成式模型的盲区”处理方式通常是在token化阶段给新item分配动态embedding并加入单独的新颖度抽样逻辑。第五可解释性会变成一个新问题。传统推荐模型给出打分我们可以解释为特征权重生成式推荐给人感觉是个端到端黑盒对合规运营和用户反馈处理都不友好。我的建议是不追求全局可解释性而是做“事后归因”记录生成时最关键的几个用户行为 token作为推荐理由生成的数据来源。第六重视数据回流的闭环设计。生成式推荐训练的是完整行为序列因此每一次在线推荐结果和用户后续行为都是下一轮训练的燃料。如果数据回流链路做不好模型会慢慢退化而且很难排查是因为算法还是数据。要像维护数据库一样维护这份行为日志。第七值得长期跟踪的方向。我的个人判断是一是更高效的序列建模算子比如Retention之外的新机制会不断出现二是item token化一定会走向内容语义和离散ID融合的路线多模态内容理解会越来越重要三是用于评测生成式推荐的仿真环境会逐渐标准化这是整个领域的基础设施。团队构建能力时也优先围绕这三个方向投入。最后再说一句我的体会技术调研做得越多越觉得推荐领域的创新从来不是靠一两个模型架构就能扫平一切的它更像一场系统性的、多工种协同的持久战。如果你也在追生成式推荐的浪潮建议先把小型验证做扎实再谈宏大叙事先让业务看到现金流再说服组织投入真正的Foundation Model。把方向看清楚比走快更重要。