生成式推荐、大推荐模型与推荐基础模型：从判别式到生成式的技术演进与落地实践

1. 推荐系统正在经历一次底层范式的切换如果你这两年一直在做推荐系统应该能明显感觉到一个变化过去我们讨论的是“特征怎么交叉”“序列怎么建模”“多目标怎么融合”而现在越来越多的一线团队开始聊“生成式推荐”“大推荐模型”“推荐基础模型”。这不是概念炒作而是推荐系统从“判别式排序”向“生成式建模”演进的一个自然结果。我先把这三个词的关系理清楚因为很多人第一次听到会懵。Generative Recommendation生成式推荐是一种建模范式核心思路是把推荐问题从“给候选物品打分排序”变成“直接生成用户可能感兴趣的物品”。Large Recommendation Model大推荐模型是生成式推荐在工业界的一种落地形态强调用大参数量、大规模数据、统一架构来替代过去碎片化的多阶段模型。Recommendation Foundation Model推荐基础模型则是更进一步的愿景希望像自然语言领域的基础模型一样一个模型能适配多种推荐场景、多个业务域通过少量微调甚至零样本迁移就能工作。这三个概念不是并列关系而是递进关系生成式推荐是方法论大推荐模型是当前工业界能落地的工程实践推荐基础模型是中长期目标。理解这个递进关系对判断技术选型和投入节奏非常关键。这篇文章适合三类人看一是正在做推荐系统架构升级的技术负责人需要判断要不要跟这个方向二是算法工程师想搞清楚生成式推荐到底怎么落地、和现有链路怎么衔接三是对推荐系统感兴趣的产品和数据分析同学想理解这波变化会带来什么影响。我会尽量把原理讲透同时给出可参考的实操路径和踩坑经验。2. 从判别式到生成式为什么要换范式2.1 传统推荐链路的根本瓶颈过去十年工业推荐系统的主流架构是“召回-粗排-精排-重排”四级漏斗。这个架构能跑通核心依赖两件事一是海量候选物品的向量化表示二是判别式模型对每个候选打分。但它有几个绕不过去的瓶颈。第一个瓶颈是目标割裂。召回阶段优化的是“能不能把相关物品捞回来”精排阶段优化的是“点击率或转化率”重排阶段又要考虑多样性和业务规则。每个阶段有自己的模型、自己的特征、自己的优化目标阶段之间的信息传递靠的是粗粒度的分数和少量特征。这就导致一个经典问题召回阶段漏掉的物品后面再强的精排也救不回来。第二个瓶颈是特征工程的重度依赖。为了让判别式模型work需要构造大量交叉特征、序列特征、统计特征。这些特征往往和具体业务强绑定换一个场景就要重新设计一套。我见过一个团队光特征管道就有上千个特征维护成本极高新人上手要三个月。第三个瓶颈是泛化能力弱。判别式模型在训练分布内表现很好但遇到新用户、新物品、新场景冷启动问题就很突出。因为模型学的是“给定特征组合下的打分函数”而不是“用户兴趣的生成规律”。2.2 生成式推荐的核心思路生成式推荐的思路完全不同。它不直接学打分函数而是学一个条件概率分布给定用户的历史行为序列预测下一个可能交互的物品。用公式表示就是 P(item | user_history)而不是传统的 P(click | user, item, context)。这个转变带来的好处是根本性的。首先它把推荐问题统一成了一个序列生成问题和自然语言处理里的语言建模在形式上高度一致。这意味着很多在大模型领域成熟的技术——Transformer架构、自回归生成、大规模预训练、指令微调——都可以迁移过来。其次它天然支持端到端优化。不再需要召回、粗排、精排各管一段一个模型直接从用户历史生成推荐结果。当然工业界不会真的完全去掉多阶段但阶段之间的耦合方式会变从“分数传递”变成“语义传递”。第三它具备更强的泛化潜力。因为模型学的是物品之间的语义关系和用户兴趣的演化规律而不是具体的特征交叉模式。当新物品出现时只要它的语义表示能被模型理解就有机会被推荐出来。2.3 大推荐模型和推荐基础模型的定位差异这里要特别区分两个概念因为很多讨论把它们混在一起。大推荐模型是当前阶段能落地的形态。它的“大”体现在参数量、数据量和计算量上但通常还是针对特定业务域训练的。比如一个电商平台的大推荐模型它学的是这个平台用户的兴趣分布和物品语义。它的目标是在这个域内替代原有的多阶段链路提升效果和工程效率。推荐基础模型则是跨域、跨场景的。它希望学到一个通用的用户兴趣表示和物品语义空间然后通过少量微调适配到不同业务。这个目标更接近自然语言领域的基础模型。但目前工业界还没有真正意义上成熟的推荐基础模型更多是在探索阶段。理解这个差异很重要因为它决定了你的投入策略。如果你现在要做的是提升单业务域的效果那大推荐模型是更现实的选择如果你在考虑多业务复用和长期技术布局那可以关注推荐基础模型的进展但不要指望短期内直接落地。3. 大推荐模型的核心技术拆解3.1 物品的语义化表示从ID到Token生成式推荐的第一步是把物品变成模型能处理的token。传统推荐里物品用ID表示然后通过Embedding层映射成向量。但ID表示有个致命问题它没有语义。物品ID 12345和12346之间没有任何关系模型无法从ID本身推断出两个物品是否相似。生成式推荐的做法是给每个物品构造语义token。具体来说就是把物品的标题、描述、类目、属性、图片等多模态信息通过一个编码器压缩成离散的token序列。这个过程类似自然语言里的分词只不过分的是物品的语义。我实测下来物品语义化的质量直接决定了大推荐模型的上限。如果token化做得粗糙比如只用类目ID做token那模型学到的还是粗粒度的类别信息生成能力很有限。比较好的做法是用多模态编码器把文本和图像信息都编码进去然后通过向量量化比如RQ-VAE得到层次化的token。这里有个实操细节token的码本大小要仔细调。码本太小物品区分度不够码本太大模型训练困难而且容易过拟合。根据我的经验单层码本在几千到几万之间比较合适具体要看物品总量和分布。3.2 序列建模Transformer如何适配推荐场景物品token化之后下一步就是用Transformer建模用户行为序列。但推荐场景和自然语言有几个关键差异直接套用标准Transformer会出问题。第一个差异是序列长度。用户行为序列可能很长几千甚至上万条。标准Transformer的注意力复杂度是O(n²)直接处理长序列计算量爆炸。工业界的做法通常是先做序列压缩比如用聚类或池化把长序列压成短序列或者用稀疏注意力、线性注意力来降低复杂度。第二个差异是时间间隔。自然语言里词与词之间的间隔是均匀的但用户行为之间的时间间隔差异很大。昨天点的和半年前点的重要性完全不同。所以需要在位置编码里加入时间信息常见做法是把时间间隔做分桶然后作为额外的位置编码注入。第三个差异是多行为类型。用户可能有浏览、点击、收藏、购买等多种行为这些行为的语义强度不同。处理方式可以是给每种行为类型一个独立的token类型嵌入也可以把行为类型作为序列的一部分显式建模。我在实际项目里试过几种方案比较稳的是先用时间分桶行为类型嵌入做序列预处理然后用标准Transformer编码最后接一个自回归解码器生成下一个物品token。这个架构在多个场景下都能work而且工程实现相对成熟。3.3 训练目标从对比学习到自回归生成大推荐模型的训练目标经历了几个阶段的演进。早期做法是对比学习把用户实际交互的物品作为正样本随机采样的物品作为负样本用InfoNCE损失训练。这种方式简单有效但有个问题它只学了“哪个物品更相关”没学“为什么相关”和“物品之间的生成关系”。现在更主流的做法是自回归生成。给定用户历史序列让模型预测下一个物品的token序列。损失函数就是标准的交叉熵和语言模型一样。这种方式的好处是模型必须学会物品之间的语义转移规律而不仅仅是相关性。但纯自回归也有问题推荐场景的“下一个物品”往往不是唯一的用户可能对多个物品都感兴趣。所以实践中会结合两种目标主目标是自回归生成辅助目标是对比学习让模型既会生成又会判别。我试过纯自回归和混合目标混合目标在召回率上通常能提升几个百分点。还有一个细节是负采样策略。自回归生成天然只需要正样本但为了让模型学会区分需要在解码时做约束比如用beam search或者top-k采样。工业界常用的做法是在训练时加入一定比例的随机负样本让模型学会“不生成什么”。3.4 推理加速生成式推荐的工程挑战生成式推荐最大的工程挑战在推理。自回归生成是串行的每生成一个token都要跑一次前向延迟很高。而推荐系统对延迟极其敏感通常要求几十毫秒内返回结果。工业界的加速方案主要有几个方向。一是非自回归生成一次性生成所有token牺牲一点效果换速度。二是缓存和预计算把用户历史序列的编码结果缓存起来只对新增行为做增量计算。三是蒸馏和量化把大模型蒸馏成小模型或者用INT8量化降低计算量。我实测下来非自回归缓存量化的组合能把推理延迟压到可接受范围。但要注意非自回归会损失一些生成质量需要根据业务对延迟和效果的容忍度来权衡。如果业务对延迟要求极高可能还是得保留一部分传统召回作为兜底。4. 从大推荐模型到推荐基础模型的路径4.1 多域预训练让模型见过更多世界大推荐模型通常只在单域训练比如只学电商数据。但推荐基础模型需要跨域预训练让模型见过不同业务场景下的用户行为和物品语义。多域预训练的核心挑战是域间差异。不同业务的物品体系、用户行为模式、甚至交互方式都不同。直接混合训练会导致模型学到一个“平均”的表示在每个域上都不够好。常见的解决方案是域自适应层。底层参数共享学习通用的用户兴趣和物品语义表示顶层参数按域独立学习域特有的模式。这样既利用了跨域数据又保留了域特性。我在实际项目里试过这种架构跨域迁移效果比单域训练有明显提升尤其是在数据稀疏的域上。另一个关键是域间对齐。不同域的物品语义空间需要对齐否则模型无法跨域迁移。做法可以是用一个共享的物品编码器把所有域的物品都映射到同一个语义空间也可以做域间的对比学习让相似物品在不同域下的表示靠近。4.2 指令微调让模型理解推荐任务推荐基础模型要适配多种任务比如“给这个用户推荐商品”“给这个商品找相似商品”“预测用户下一个行为”。这些任务形式不同需要模型能理解任务指令。指令微调的做法是给每个任务构造指令模板比如“用户历史行为是[...]请推荐下一个可能交互的商品”。然后混合多个任务的数据一起训练。这样模型就学会了根据指令切换任务模式。这里有个实操经验指令模板的设计很关键。模板要清晰表达任务意图同时要和预训练时的数据格式保持一致。我见过一些团队指令模板设计得太复杂模型反而学不好。简单直接的模板通常效果更好。4.3 零样本和少样本迁移基础模型的真正价值推荐基础模型的终极价值是能在新场景下零样本或少样本工作。比如一个新业务上线没有历史数据传统推荐系统冷启动很痛苦。但如果有一个推荐基础模型它可能直接就能给出不错的推荐结果。目前工业界在这方面的进展还比较初步。零样本迁移在物品语义理解上表现不错但在用户行为建模上还有差距。少样本迁移相对成熟一些给几百条用户行为数据做微调就能达到可用的效果。我的判断是推荐基础模型在物品侧比如物品语义理解、相似物品推荐会先成熟因为物品语义相对稳定跨域迁移更容易。用户侧的行为建模因为和具体业务强相关跨域迁移难度更大可能需要更长时间。5. 工业落地的关键问题和避坑经验5.1 数据质量和规模比模型架构更重要我做了这么多项目最大的体会是数据质量比模型架构重要得多。生成式推荐对数据的要求比传统推荐更高因为它学的是生成规律数据里的噪声会被放大。具体来说有几个数据问题要特别注意。一是行为序列的完整性。如果用户行为日志有缺失模型学到的序列就是错的。我见过一个项目因为埋点问题导致部分行为丢失模型效果一直上不去排查了很久才发现是数据问题。二是物品语义的一致性。物品的标题、描述、类目如果质量差token化后的语义表示就会很乱。建议在token化之前先做一轮数据清洗把明显错误的物品信息修掉。三是数据规模。生成式推荐通常需要比传统推荐更多的数据。我的经验是至少要有千万级以上的用户行为序列模型才能学到稳定的生成规律。数据量不够的话建议先用传统方法等数据积累够了再切换。5.2 评估体系离线指标和在线效果的鸿沟生成式推荐的评估是个大问题。传统推荐用AUC、GAUC、RecallK这些指标但生成式推荐的输出是物品序列这些指标不太适用。常用的离线指标有生成准确率生成的物品和真实下一个物品的匹配度、序列困惑度模型对真实序列的预测能力。但这些指标和在线效果的相关性经常不好。我遇到过离线指标提升但在线效果下降的情况原因是离线评估没有考虑多样性和新鲜度。比较靠谱的做法是离线在线结合。离线用生成指标做快速迭代在线用A/B测试做最终判断。同时要监控一些过程指标比如生成结果的多样性、覆盖率、新物品曝光比例这些能帮助判断模型是否健康。5.3 工程架构和现有链路的衔接生成式推荐不是凭空新建一套系统而是要和现有链路衔接。我的建议是渐进式替换不要一上来就把整个推荐链路换掉。具体路径可以是先用生成式模型做召回替代原有的向量召回效果验证后再用生成式模型做粗排最后逐步替代精排。每一步都要有回滚方案确保出问题能快速切回原链路。工程上还要注意模型更新频率。生成式模型通常比传统模型大训练和更新成本高。如果业务变化快模型更新跟不上效果会衰减。我的经验是至少要做到天级更新重要业务最好做到小时级。5.4 常见问题速查表问题现象可能原因排查方向解决思路生成结果重复率高解码策略过于保守检查beam search参数、温度系数增大温度、引入多样性惩罚新物品曝光低物品语义表示不准确检查token化质量、码本覆盖优化物品编码器、增加新物品样本推理延迟高自回归串行生成检查序列长度、模型大小非自回归生成、缓存、量化离线在线效果不一致评估指标偏差对比离线指标和在线指标引入多样性、新鲜度指标跨域迁移效果差域间差异大检查域自适应层、对齐策略增加域间对比学习、调整共享层比例6. 我对这个方向的一些判断生成式推荐这个方向我的判断是方向是对的但落地节奏要比很多人预期的慢。原因很简单推荐系统和自然语言处理不一样它对延迟、稳定性、可控性的要求极高。自然语言模型生成错了用户最多觉得回答不好推荐模型生成错了可能直接影响业务收入。大推荐模型在未来一两年内会在头部团队逐步落地但不会完全替代传统链路更可能是混合架构。推荐基础模型还需要更长时间可能三到五年才会有比较成熟的工业实践。如果你现在要投入这个方向我的建议是先从物品语义化和序列建模入手这两块是基础而且相对独立可以先在现有链路里做增强。等这两块跑通了再考虑端到端的生成式架构。不要一上来就追求大而全容易踩坑。最后分享一个我在实际项目里的小技巧生成式推荐的冷启动可以先用人造数据做预训练。比如用规则生成一批用户行为序列让模型先学到一个基本的生成模式然后再用真实数据微调。这样能显著缩短冷启动周期实测下来效果不错。