推荐系统这个圈子每隔几年就会冒出一个让人兴奋的新方向。从最早的协同过滤到后来的深度学习排序再到近两年的生成式召回每一次范式切换都伴随着工业界架构的重新洗牌。2026年这个时间节点上Generative Recommendation、Large Recommendation Model、Recommendation Foundation Model这三个词被反复提及但真正落地到工业系统里的人并不多。我过去一年多在推荐架构方向做了不少调研和原型验证踩过的坑、看过的论文、跑过的实验加起来能写好几本笔记。这篇文章不打算做学术综述而是从一个工业从业者的视角把这三个概念之间的演进逻辑、技术底座、落地路径和现实约束讲清楚适合正在做推荐系统架构升级、或者想搞清楚这个方向到底值不值得投入的工程师和产品同学参考。1. 三个概念到底在说什么从LRM到RFM的演进逻辑1.1 Generative Recommendation不是生成式召回这么简单很多人第一次听到Generative Recommendation第一反应是哦就是用生成模型做召回。这个理解只对了一半。生成式推荐的核心变化不在于用了什么模型结构而在于推荐任务的建模方式发生了根本转变。传统推荐系统的范式是判别式的给定用户和物品的特征模型判断这个物品该不该被推荐给这个用户。无论是CTR预估还是双塔召回本质上都是在做分类或回归。而生成式推荐把问题重新定义成了序列生成给定用户的历史行为序列模型直接生成用户接下来可能感兴趣的物品标识序列。这个转变带来的第一个直接后果是物品不再需要预先编码成稠密向量。传统双塔召回里每个物品都要过一个物品塔得到embedding物品数量上亿时这个物品塔的维护和更新本身就是巨大的工程负担。生成式推荐把物品当成词表里的token用类似语言模型的方式直接生成物品ID物品塔这个概念被消解了。第二个后果是召回和排序的边界开始模糊。传统架构里召回负责从亿级候选里粗筛出千级排序负责精排。生成式模型可以在一次生成过程中同时完成候选生成和偏好表达理论上可以端到端地输出推荐列表。当然工业上完全端到端还不现实但这个趋势已经很明显了。1.2 Large Recommendation Model的大体现在哪里Large Recommendation Model这个概念借鉴了大语言模型的命名方式但它的大和LLM的大不是一回事。LLM的大主要体现在参数量和训练数据量上而LRM的大体现在三个维度第一是用户行为序列的长度。传统推荐模型处理的用户序列通常在几百到几千LRM可以处理万级甚至十万级的行为序列。这背后是注意力机制的工程优化包括稀疏注意力、滑动窗口注意力、以及各种序列压缩技术。第二是特征交叉的广度。传统模型靠人工设计特征交叉LRM通过大规模embedding表和深度网络自动学习高阶交叉。一个典型的LRM可能有数十亿的embedding参数覆盖用户、物品、上下文的各种离散特征。第三是模型容量的扩展性。LRM强调scaling law在推荐场景的适用性——模型大到一定程度后推荐效果会随着参数量和数据量的增加而持续提升。这一点在传统推荐模型上并不明显因为传统模型很快会遇到特征表达瓶颈。我实测下来的感受是LRM的大带来的收益不是线性的。参数量从1亿涨到10亿效果提升可能只有几个千分点但工程成本是数量级的增长。所以LRM的落地必须算清楚投入产出比不能盲目追大。1.3 Recommendation Foundation Model的野心与边界Recommendation Foundation Model是这三个概念里野心最大的。它的目标不是解决某一个推荐场景的问题而是构建一个通用的推荐基座模型能够跨场景、跨域、跨平台地迁移。RFM的核心假设是用户的兴趣和行为模式存在跨域的共性。一个用户在电商平台的浏览行为和在内容平台的消费行为背后可能共享同一套兴趣表征。如果能把这种共性建模出来就可以用一个基座模型服务多个推荐场景大幅降低每个场景单独建模的成本。这个假设在理论上很吸引人但工业落地面临几个硬约束。首先是数据隔离问题不同业务线的数据通常不能随意打通跨域建模在合规层面就有障碍。其次是场景异质性电商推荐和内容推荐的目标函数、评价指标、用户心智差异很大一个基座模型很难同时优化好。第三是推理成本基座模型的参数量决定了它的推理开销远高于场景专用模型在延迟敏感的推荐场景里这是致命的。所以我的判断是RFM在短期内更可能以预训练场景微调的形式落地而不是一个模型打天下。预训练阶段用大规模跨域数据学习通用表征微调阶段针对具体场景做适配。这个路径在NLP领域已经被验证过推荐领域大概率也会走类似的路。2. 生成式推荐的技术底座Token化、序列建模与解码策略2.1 物品Token化生成式推荐的第一道坎生成式推荐要生成物品首先得把物品变成模型能处理的token。这个看似简单的步骤实际上是整个技术栈里最容易被低估的环节。最直接的做法是给每个物品分配一个唯一的整数ID就像词表里的词一样。但推荐场景的物品数量通常是亿级的直接做ID token化会导致词表过大softmax层计算量爆炸而且物品ID之间没有任何语义关系模型很难学到物品之间的相似性。工业界目前主流的方案是层次化Token化。具体做法是先用物品的content特征标题、类目、图片embedding等做聚类把亿级物品组织成一棵树或者多层量化码本。每个物品用一条从根到叶的路径表示路径上的每个节点是一个token。这样词表大小可以控制在几万到几十万同时token之间天然带有语义层次。另一种方案是残差量化RQ-VAE。用多个码本逐层量化物品embedding每个物品用多个码本索引的组合表示。这种方案的好处是token序列更短解码效率更高但码本的训练和更新比较复杂。我实际对比过这两种方案。层次化Token化实现简单可解释性强但聚类质量直接决定效果上限RQ-VAE效果更优但训练不稳定码本坍塌是常见问题。如果团队刚开始做生成式推荐我建议从层次化Token化入手跑通全链路后再考虑升级。2.2 序列建模Transformer不是唯一答案生成式推荐的序列建模骨干网络目前主流是Transformer及其变体。但推荐场景的序列和NLP的序列有几个关键差异直接套用Transformer会遇到问题。差异一是序列长度。NLP的序列通常几百到几千token推荐场景的用户行为序列可以到万级。标准Transformer的注意力复杂度是O(n²)万级序列直接算不动。解决方案包括稀疏注意力只关注最近的N个行为和重要的历史行为、线性注意力用核函数近似softmax注意力、以及状态空间模型如Mamba。差异二是序列的异构性。用户行为序列里混杂着点击、购买、收藏、分享等不同类型的动作每种动作的语义和重要性不同。标准Transformer对所有token一视同仁需要额外的设计来区分行为类型。常见做法是给不同类型的行为加不同的type embedding或者在注意力计算时引入行为类型的先验。差异三是实时性要求。推荐系统的用户序列是实时更新的用户刚点了一个物品下一个请求就应该反映这个行为。这对模型的增量推理能力提出了要求。全量重算不现实需要设计增量更新机制比如缓存历史行为的KV只计算新增行为的注意力。我实测下来在万级序列场景下稀疏注意力滑动窗口的组合性价比最高。线性注意力虽然理论复杂度低但实际效果损失比较明显需要仔细调参才能追上标准注意力。2.3 解码策略Beam Search在推荐场景的适配生成式推荐的解码阶段目标是从模型输出的概率分布中生成物品序列。NLP里常用的Beam Search、Top-K采样、温度采样等策略在推荐场景需要做适配。Beam Search的问题是容易生成重复或高度相似的物品。NLP里生成的文本有语法约束重复问题不严重推荐场景里用户可能对同一类物品感兴趣Beam Search会倾向于生成同一类目的多个物品导致推荐列表多样性差。解决方案是在解码时引入多样性惩罚对已经生成过的类目或物品做抑制。Top-K采样的问题是随机性太强推荐结果不稳定。同一个用户连续两次请求可能得到完全不同的推荐这在工业场景里是不可接受的。解决方案是降低温度参数或者在采样时加入用户历史行为的约束。约束解码是推荐场景特有的需求。生成的物品必须是真实存在的、可推荐的、符合业务规则的。这需要在解码时维护一个合法的候选集合对非法token做mask。这个mask的维护本身就是一个工程挑战尤其是候选集合动态变化时。我的经验是工业场景下Beam Search配合多样性惩罚是最稳妥的方案。采样策略适合探索场景比如冷启动或新品推荐但主流量推荐还是用确定性解码。3. 工业落地的现实约束延迟、成本与效果的三方博弈3.1 推理延迟生成式推荐的阿喀琉斯之踵生成式推荐在工业落地时遇到的第一个硬约束就是推理延迟。传统双塔召回可以在几毫秒内完成亿级候选的打分生成式推荐的自回归解码是串行的生成一个长度为N的序列需要N次前向传播延迟直接和序列长度成正比。我做过一个测算一个10亿参数的生成式推荐模型在单张A100上生成一个长度为20的物品序列端到端延迟大约在50-80毫秒。这个数字在推荐场景里是偏高的传统召回排序的全链路延迟通常要求在100毫秒以内。降低延迟的手段有几个方向。一是模型量化把FP16量化到INT8甚至INT4延迟可以降低30%-50%但效果损失需要仔细评估。二是蒸馏用大模型蒸馏一个小模型做在线推理大模型只用于离线训练或周期性更新。三是并行解码用非自回归或半自回归的解码方式一次生成多个token牺牲部分效果换延迟。四是缓存对热门用户或热门物品的生成结果做缓存减少重复计算。这几个手段我都在原型里试过。量化蒸馏的组合最实用延迟能压到20毫秒以内效果损失控制在可接受范围。并行解码的效果损失比较大除非延迟要求极其苛刻否则不建议。3.2 训练成本不是每个团队都烧得起生成式推荐的训练成本比传统推荐模型高一个数量级。一个中等规模的LRM训练数据量在百亿级别参数量在十亿级别用几十张A100训练一轮需要几天时间。如果要持续迭代训练成本会快速累积。成本高的原因有几个。一是数据量大生成式推荐需要长序列数据数据预处理和加载的开销很大。二是模型大参数量决定了显存占用和计算量。三是训练不稳定生成式模型的训练比判别式模型更容易出现loss震荡、梯度爆炸等问题需要更多的调参和重启。降低训练成本的思路包括用混合精度训练减少显存占用和计算量用梯度检查点技术用时间换显存用数据并行模型并行流水线并行的组合策略提升GPU利用率以及用预训练微调的方式复用基座模型减少每个场景的从头训练成本。我的建议是如果团队没有大规模分布式训练的经验和资源不要一上来就做LRM。先从小的生成式模型做起验证技术路线和业务价值再逐步扩大规模。3.3 效果评估离线指标和在线指标的鸿沟生成式推荐的效果评估比传统推荐更复杂。传统推荐的离线指标AUC、GAUC、RecallK和在线指标CTR、GMV、停留时长虽然有gap但方向基本一致。生成式推荐的离线指标和在线指标经常出现背离。原因是生成式推荐的离线评估通常用困惑度Perplexity或序列生成准确率这些指标衡量的是模型拟合用户行为序列的能力但不直接对应推荐效果。一个困惑度很低的模型可能只是学会了复读用户的历史行为生成的都是用户已经看过的物品在线效果反而差。更合理的离线评估方式是模拟在线环境做生成给定用户的历史序列让模型生成推荐列表然后用一个独立的评估模型或规则来打分。这种方式更接近真实推荐场景但实现复杂度高。我的经验是生成式推荐的离线评估只能作为参考最终决策必须看在线AB实验。而且AB实验的周期要比传统推荐更长因为生成式模型的效果可能需要更长时间才能体现。4. 从原型到生产一条务实的落地路径4.1 阶段一用生成式模型做召回增强如果团队想试水生成式推荐我建议的第一个落地场景是召回增强而不是直接替换现有召回。具体做法是保留现有的双塔召回和规则召回额外增加一路生成式召回把生成结果作为补充候选送入排序。这个阶段的目标不是提升效果而是验证生成式召回和现有召回的互补性。如果生成式召回带来的候选和现有召回重叠度很低说明它确实捕捉到了不同的用户兴趣有增量价值。如果重叠度很高说明生成式召回只是在重复现有召回的工作没有增量。这个阶段的工程改动相对小风险可控。生成式召回可以异步生成不阻塞主链路延迟要求可以放宽。模型规模也可以控制先用小模型验证。4.2 阶段二生成式模型与排序模型的联合优化验证了生成式召回的增量价值后下一步是让生成式模型和排序模型协同工作。传统架构里召回和排序是解耦的召回只负责筛选候选不感知排序目标。生成式模型可以在生成阶段就引入排序信号比如用排序模型的打分作为生成过程的奖励信号做强化学习式的优化。这个阶段的技术挑战在于训练信号的传递。排序模型的梯度如何回传到生成模型是一个开放问题。直接端到端训练计算量太大实践中通常用两阶段的方式先训练生成模型再用排序模型的结果做微调。另一个挑战是候选集合的动态性。生成式模型生成的候选需要经过业务规则过滤下架商品、库存不足、合规问题等过滤后的候选集合和生成时的候选集合不一致会影响生成模型的训练和推理一致性。4.3 阶段三RFM形态的基座模型探索当生成式推荐在单个场景跑通后可以考虑向RFM形态演进。这个阶段的核心工作是跨场景的预训练和迁移。预训练阶段用多个场景的用户行为数据训练一个基座模型学习通用的用户兴趣表征。微调阶段针对每个场景的数据做适配可以用Adapter、LoRA等参数高效微调技术避免全量微调的成本。这个阶段最大的障碍不是技术而是组织和数据层面的协调。跨场景的数据打通需要业务方的配合模型的服务方式需要重新设计效果评估需要跨场景的统一指标。这些非技术因素往往比技术本身更难推动。我的判断是RFM在2026年还处于早期探索阶段真正落地的案例不会太多。但这个方向的潜力是确定的提前布局的团队会在下一轮技术周期里占据优势。5. 几个容易被忽视的工程细节5.1 物品ID的冷启动问题生成式推荐依赖物品的token表示新物品没有历史行为数据token化时容易出问题。如果新物品的content特征和已有物品差异大聚类时可能被分到一个不合适的簇导致生成时永远生成不到这个物品。解决方案是给新物品保留探索通道。在token化时为新物品分配一个临时的、可探索的token随着行为数据的积累逐步调整。或者在解码阶段对冷启动物品做额外的boost保证它们有机会被生成。5.2 生成结果的多样性控制生成式推荐容易出现模式坍塌即模型倾向于生成少数几个热门物品导致推荐列表多样性差。这个问题在训练数据不均衡时尤其严重。控制多样性的手段包括在训练时对热门物品做降采样在解码时引入多样性惩罚以及在损失函数里加入多样性正则项。我实测下来解码阶段的多样性惩罚最直接有效但惩罚系数需要仔细调太大会影响相关性太小起不到作用。5.3 模型更新的频率与一致性生成式推荐的模型更新比传统推荐更复杂。传统推荐模型可以每天全量更新一次生成式模型的全量训练成本高更新频率受限。但用户兴趣是实时变化的模型更新太慢会导致效果衰减。折中方案是全量更新增量更新结合。全量更新周期可以是一周或更长增量更新用在线学习的方式只更新部分参数比如最后一层或Adapter。这样既能保证模型的稳定性又能快速响应用户兴趣变化。增量更新的风险是灾难性遗忘模型在学习新数据时忘记了旧知识。缓解手段包括保留一部分旧数据做回放用正则化约束参数更新幅度以及用多任务学习的方式同时优化新旧数据。6. 我对这个方向的一些个人判断做了一年多的调研和原型我对生成式推荐在工业界的落地节奏有几个判断不一定对但都是基于实际踩坑的经验。第一生成式推荐不会完全替代传统推荐。传统推荐在特征工程、实时性、可解释性上的优势依然存在生成式推荐更适合作为补充而不是替代。未来很长一段时间里混合架构会是主流。第二LRM的规模会趋于理性。现在大家都在追大模型但推荐场景的scaling law没有LLM那么明显参数量到一定程度后收益递减很快。我预计工业界的LRM参数量会稳定在十亿级别而不是无限扩大。第三RFM的落地会先从大厂开始。跨场景的基座模型需要大量的数据和算力只有头部公司有这个资源。中小团队更现实的路径是在单场景做好生成式推荐而不是追求通用基座。第四工程能力比算法能力更关键。生成式推荐的算法方案在学术界已经比较成熟工业落地的瓶颈在工程延迟优化、成本控制、系统稳定性。算法同学需要补工程课工程同学需要理解算法原理这个交叉地带的人才最稀缺。最后分享一个我在原型验证阶段的小技巧不要一开始就追求端到端的生成式推荐先用生成式模型做离线评估看看它生成的候选和现有系统的候选有多大差异。如果差异很小说明这个方向在你的场景里可能没有增量价值及时止损比硬推更重要。技术选型最怕的不是选错而是在错误的路上投入太多。