生成式推荐系统实战：从语义ID到Recommendation Foundation Model的演进与落地

1. 推荐系统正在经历一场范式迁移

如果你这两年一直在做推荐系统，应该能明显感觉到一个变化：过去我们聊的都是“特征工程怎么做”“双塔怎么调”“粗排精排怎么串”，而现在越来越多的团队开始讨论“生成式推荐”“大推荐模型”“推荐基础模型”。这不是简单的概念翻新，而是整个技术栈的底层逻辑在发生迁移。

我过去几年一直在做推荐系统的工程落地，从最早的LR+GBDT时代，到后来的DeepFM、DIN、双塔召回，再到近两年开始接触生成式推荐的工业实践。说实话，第一次看到用生成范式做推荐的时候，我的反应是“这东西能落地吗”。但当我真正跑通了一套基于语义ID的生成式召回链路之后，我意识到这条路虽然还很长，但方向已经不可逆了。

这篇文章想做的事情很明确：把“Generative Recommendation”“Large Recommendation Model”“Recommendation Foundation Model”这三个概念之间的演进关系讲清楚，把工业界目前能落地的技术方案拆开来讲透，并且给出可以直接参考的实操路径。不管你是刚入行一两年的推荐算法工程师，还是带团队做技术选型的技术负责人，都能从中拿到对自己有用的东西。

先说结论：生成式推荐不是把推荐系统推倒重来，而是在召回和排序的核心环节引入“生成”的思想，用语义ID替代离散ID，用序列生成替代传统的匹配打分。Large Recommendation Model是把推荐模型做大做深，Recommendation Foundation Model则是希望像GPT在NLP领域的角色一样，用一个基础模型适配多种推荐场景。这三者是一条递进的技术路线，不是互相替代的关系。

2. 从Large Recommendation Model到生成式推荐：核心思路拆解

2.1 为什么传统推荐系统走到了瓶颈期

传统推荐系统的核心范式是“召回-粗排-精排-重排”四级漏斗。这个架构在过去十年里非常有效，但它有几个根本性的问题，随着业务规模增长会越来越突出。

第一个问题是ID特征的局限性。传统推荐严重依赖User ID和Item ID的Embedding，这些ID是离散的、无语义的。一个Item ID为12345的商品，模型只知道它和某些用户有过交互，但完全不知道它是什么类目、什么风格、什么价格带。所有的语义信息都要靠额外的特征工程去补，而特征工程的天花板是很明显的。

第二个问题是目标割裂。召回阶段优化的是召回率，排序阶段优化的是CTR或GMV，每个阶段的目标不一致，导致整个链路的全局最优很难保证。你经常能看到召回回来的内容在排序阶段被大量过滤掉，这就是目标割裂带来的效率损失。

第三个问题是冷启动和长尾。新用户没有行为历史，新物品没有交互数据，传统ID-based的模型对这种情况几乎无能为力。虽然有很多冷启动方案，但本质上都是在“猜”，效果上限很低。

第四个问题是** scaling law 不适用**。在NLP和CV领域，模型参数越大、数据越多，效果就越好，这是一个被反复验证的规律。但传统推荐模型参数量增加到一定程度后，效果增长就趋于平缓了，甚至还会下降。这说明传统推荐模型的架构本身限制了它从更大规模数据中获益的能力。

2.2 Large Recommendation Model到底“大”在哪里

Large Recommendation Model这个概念，核心不是说把模型参数量堆到几百亿就叫Large，而是说模型的设计要能像大语言模型一样，从更大规模的数据和参数中获得持续的效果提升。

具体来说，Large Recommendation Model的“大”体现在三个维度。

第一是参数量的大。传统推荐模型的参数量通常在百万到亿级别，其中大部分还是Embedding参数。Large Recommendation Model的参数量可以到十亿甚至百亿级别，而且这些参数不是简单的Embedding lookup table，而是有实际计算能力的网络参数。

第二是训练数据的大。传统推荐模型的训练数据通常是最近几个月的行为日志，而Large Recommendation Model需要更长时间跨度的数据，甚至要引入跨域数据来增强模型的泛化能力。

第三是模型能力的大。Large Recommendation Model不只是做CTR预估，它要能同时处理召回、排序、重排等多个任务，甚至要能理解用户的自然语言指令，比如“帮我找一些适合夏天穿的透气运动鞋”。

我实测下来，Large Recommendation Model最关键的改变是把推荐问题转化成了序列生成问题。传统推荐是给定用户和候选物品，预测交互概率；生成式推荐是给定用户的历史行为序列，直接生成用户可能感兴趣的物品序列。这个转化看起来简单，但它带来的变化是根本性的。

2.3 生成式推荐的核心：语义ID与序列生成

生成式推荐能成立，靠的是两个核心支柱：语义ID和序列生成。

先说语义ID。传统推荐用离散的Item ID，每个ID之间没有任何语义关系。语义ID的做法是，先用一个内容理解模型（比如多模态模型）把每个物品编码成一个语义向量，然后用量化方法（比如RQ-VAE或者残差量化）把这个向量转化成几个离散的token。这几个token拼在一起，就构成了这个物品的语义ID。

举个例子，一个物品的语义ID可能是[23, 156, 892]，其中23代表“运动户外”这个大品类，156代表“跑步鞋”这个子品类，892代表“轻量透气”这个属性。这样，语义ID本身就携带了物品的语义信息，模型不需要额外的特征工程就能理解物品是什么。

更重要的是，语义ID让生成式推荐成为可能。因为语义ID是离散的token序列，所以可以用类似GPT的序列生成模型来生成。给定用户的历史行为序列（每个行为物品用语义ID表示），模型自回归地生成下一个可能被交互的物品的语义ID。这就是生成式推荐的基本原理。

再说序列生成。传统推荐是“匹配”范式：计算用户向量和物品向量的相似度，然后排序。生成式推荐是“生成”范式：直接生成用户可能感兴趣的物品序列。这个转变的好处是，模型可以捕捉更复杂的用户行为模式，而且天然支持多目标优化，因为生成的序列可以同时考虑多样性、新颖性、相关性等多个维度。

2.4 Recommendation Foundation Model的愿景与现实

Recommendation Foundation Model是这条技术路线的终极形态。它的目标是：用一个预训练好的基础模型，通过少量微调就能适配各种推荐场景，就像GPT-4通过prompt就能做翻译、摘要、问答一样。

这个愿景很美好，但现实是，目前还没有真正意义上的Recommendation Foundation Model。原因有几个：推荐场景的数据分布差异太大，电商、短视频、新闻、社交的推荐逻辑完全不同；推荐系统的实时性要求很高，基础模型的推理成本很难接受；推荐的效果评估比NLP复杂得多，没有一个统一的benchmark。

不过，工业界已经在往这个方向走了。一些团队在尝试用统一的语义ID空间来打通多个场景，一些团队在探索用instruction tuning的方式让推荐模型理解自然语言指令。虽然离真正的Foundation Model还有距离，但路径已经清晰了。

3. 工业级生成式推荐系统的核心细节解析

3.1 语义ID的构建：从多模态编码到残差量化

语义ID的构建是生成式推荐的第一步，也是最关键的一步。这一步做不好，后面的生成模型再强也没用。

整个流程分为三个阶段：内容编码、向量量化、ID映射。

内容编码阶段，你需要一个能理解物品内容的多模态模型。对于电商场景，物品有标题、图片、价格、类目等属性；对于短视频场景，有视频帧、音频、标题、标签等。你需要把这些多模态信息编码成一个统一的语义向量。常用的做法是用CLIP类的模型处理图文信息，用BERT类的模型处理文本信息，然后拼接或融合成一个固定维度的向量。

这里有个实操心得：不要直接用预训练模型的原始输出作为语义向量。预训练模型的输出空间和推荐任务的目标空间不一致，直接拿来用效果往往不好。我试过在预训练模型后面接一个小的投影网络，用推荐任务的交互数据做微调，让语义向量更贴合推荐场景，效果提升很明显。

向量量化阶段，你需要把连续的语义向量转化成离散的token。这一步的核心方法是残差量化（Residual Quantization）。具体来说，先用一个码本（codebook）对语义向量做第一次量化，得到第一个token和量化残差；然后用第二个码本对残差做量化，得到第二个token和新的残差；重复这个过程，直到残差足够小或者达到预设的token数量。

为什么用残差量化而不是简单的K-Means聚类？因为残差量化可以在有限的码本大小下，表达更多的语义组合。假设你有3层码本，每层码本大小是256，那么可以表达的语义ID数量是256的3次方，约1600万，足够覆盖大多数场景的物品数量。而如果只用一层码本，要达到同样的表达能力，码本大小需要1600万，这是不现实的。

ID映射阶段，你需要把量化得到的token序列映射成最终的语义ID。这里有个细节：不同层级的token应该有不同的语义粒度。第一层token通常对应粗粒度的品类信息，第二层对应中粒度的子品类，第三层对应细粒度的属性。你可以通过控制每层码本的大小和量化目标来实现这种层级结构。

3.2 生成模型的选择：Decoder-only还是Encoder-Decoder

语义ID构建好之后，下一步是选择生成模型。目前主流的选择有两种：Decoder-only架构和Encoder-Decoder架构。

Decoder-only架构就是GPT那一套，自回归地生成下一个token。优点是结构简单，训练效率高，适合大规模预训练。缺点是只能做单向生成，对用户历史行为的双向依赖建模不够充分。

Encoder-Decoder架构是T5那一套，先用Encoder编码用户历史行为，再用Decoder生成目标序列。优点是能充分建模用户历史行为的双向依赖，缺点是结构复杂，训练和推理成本更高。

我实测下来的感受是：如果用户行为序列比较短（比如50个行为以内），Decoder-only就够了；如果用户行为序列很长（几百个甚至上千个），Encoder-Decoder的优势更明显。因为长序列中，用户的行为模式往往需要双向理解才能准确捕捉。

还有一个选择是Prefix LM，它介于两者之间，对用户历史行为做双向编码，对生成目标做单向生成。这个方案在推荐场景下表现不错，但实现起来比纯Decoder-only复杂一些。

不管选哪种架构，有几个设计要点是通用的。第一，位置编码要用相对位置编码，因为用户行为序列的长度变化很大，绝对位置编码泛化能力差。第二，要加行为类型Embedding，因为用户的行为有曝光、点击、加购、购买等多种类型，这些类型信息对生成很重要。第三，要用采样策略控制生成的多样性，推荐场景不能像NLP那样只取概率最高的token，需要适当引入随机性来保证推荐结果的多样性。

3.3 训练目标的设计：从Next Item Prediction到多目标生成

生成式推荐的训练目标，最基础的是Next Item Prediction，也就是给定用户历史行为序列，预测下一个交互的物品。这个目标简单直接，但有几个问题。

第一个问题是只优化了相关性，没有优化多样性。如果模型只学Next Item Prediction，它会倾向于生成和用户历史行为高度相似的物品，导致推荐结果同质化严重。

第二个问题是没有区分行为类型。用户点击了一个物品和购买了一个物品，背后的意图强度完全不同。Next Item Prediction把所有行为一视同仁，丢失了行为类型的信息。

第三个问题是没有考虑负反馈。用户划走了一个视频，或者关闭了一个商品详情页，这些负反馈信息对推荐很重要，但Next Item Prediction没有利用。

所以工业界的做法通常是多目标生成。具体来说，在生成目标中同时加入相关性、多样性、新颖性等多个维度的信号。实现方式有两种：一种是在训练数据中构造多组目标序列，每组对应一个优化目标；另一种是在损失函数中加入多目标的权重，让模型同时优化多个目标。

我个人的经验是，多目标生成的关键在于目标之间的权重平衡。相关性权重太高，推荐结果会同质化；多样性权重太高，推荐结果会不相关。这个平衡需要根据业务场景来调，没有通用的最优值。我的做法是先固定相关性权重为1，然后逐步增加多样性权重，观察线上指标的变化，找到一个帕累托最优的点。

3.4 推理阶段的工程挑战：如何把生成模型塞进推荐链路

训练好生成模型只是第一步，真正的挑战在推理阶段。推荐系统对延迟的要求非常苛刻，通常要求整个链路在100毫秒以内完成。而生成模型的推理成本远高于传统推荐模型，这是一个很大的矛盾。

解决这个矛盾有几个思路。

第一个思路是模型蒸馏。用一个大的生成模型作为Teacher，蒸馏出一个小的Student模型用于线上推理。Student模型可以是传统的双塔模型，也可以是轻量级的生成模型。蒸馏的关键是设计好蒸馏损失，让Student模型不仅学习Teacher的输出分布，还要学习Teacher的中间表示。

第二个思路是缓存和预计算。用户的历史行为序列在短时间内变化不大，可以预先计算好用户表示并缓存起来。当用户有新行为时，只需要增量更新缓存，不需要重新跑整个模型。这个思路在实践中的效果很好，可以把推理延迟降低一个数量级。

第三个思路是分层生成。先用一个粗粒度的生成模型生成候选集，再用一个细粒度的排序模型对候选集精排。粗粒度生成模型可以做得很大，但推理频率低；细粒度排序模型可以做得小，但推理频率高。这样可以在效果和延迟之间取得平衡。

第四个思路是量化加速。把生成模型的权重从FP16量化到INT8甚至INT4，可以大幅降低推理成本。量化会带来一定的效果损失，但通过量化感知训练可以把这个损失控制在可接受的范围内。

我实测下来，缓存+分层生成的组合方案在工业场景下最实用。缓存解决了大部分请求的延迟问题，分层生成解决了效果问题。纯靠模型蒸馏或者量化加速，要么效果损失太大，要么加速效果不够。

4. 实操过程：从零搭建一套生成式召回链路

4.1 数据准备与语义ID生成

假设你现在要在一个电商场景下搭建生成式召回链路，第一步是准备数据和生成语义ID。

数据准备包括两部分：物品侧数据和用户侧数据。物品侧数据需要每个物品的标题、图片、类目、价格、属性等信息。用户侧数据需要用户的历史行为序列，包括行为类型（曝光、点击、加购、购买）、行为时间、行为物品的ID。

物品侧数据的处理流程是这样的：先用一个多模态模型（比如CLIP）提取每个物品的图文语义向量，维度通常是512或768。然后对这个向量做归一化，确保不同物品的语义向量在同一个尺度上。接着用残差量化把连续向量转化成离散token。我通常用3层量化，每层码本大小256，这样每个物品的语义ID是3个token。

这里有个实操细节：码本的初始化很重要。如果码本初始化得不好，量化误差会很大，语义ID的质量就很差。我的做法是先用K-Means对一批物品的语义向量做聚类，用聚类中心初始化码本，然后再用残差量化做微调。这样初始化出来的码本，量化误差比随机初始化小很多。

用户侧数据的处理流程是：把用户的历史行为序列按时间排序，每个行为物品用它的语义ID表示，同时加上行为类型Embedding和时间间隔Embedding。最终每个用户的行为序列是一个token序列，每个token包含语义ID和行为类型信息。

4.2 模型训练的关键参数与调参经验

数据准备好之后，就可以开始训练生成模型了。我以Decoder-only架构为例，讲一下关键参数和调参经验。

模型维度：我通常从512维开始试，如果数据量足够大（比如亿级别的行为序列），可以加到1024维甚至2048维。但要注意，模型维度增加会带来推理成本的增加，需要权衡。

层数：Decoder-only的层数通常从6层开始试，数据量大的话可以加到12层或24层。我实测下来，层数增加到12层以上后，效果提升就不明显了，但推理成本还在增加，所以12层是一个比较合适的点。

注意力头数：通常设置为模型维度除以64。比如模型维度是512，注意力头数就是8。这个比例在实践中表现比较稳定。

学习率：生成式推荐的学习率通常比传统推荐模型小，因为模型更大，更容易过拟合。我通常用1e-4到5e-5之间的学习率，配合warmup和余弦退火。

Batch Size：在显存允许的情况下尽量大，因为生成模型的训练对Batch Size比较敏感。我通常用512到2048之间的Batch Size。

训练轮数：生成式推荐通常训练1到3个epoch就够了，再多容易过拟合。我通常在第2个epoch结束后评估一次，如果效果不再提升就停止训练。

调参经验方面，有几个点值得注意。第一，Dropout对生成式推荐很重要，我通常用0.1到0.3之间的Dropout率，可以有效防止过拟合。第二，梯度裁剪是必须的，生成模型的梯度容易爆炸，我通常把梯度范数裁剪到1.0。第三，学习率warmup很重要，前10%的step做warmup，可以让训练更稳定。

4.3 线上部署与A/B测试方案

模型训练好之后，下一步是线上部署和A/B测试。

线上部署的核心是推理服务的搭建。我通常用TensorRT或者ONNX Runtime来做推理加速，把生成模型的推理延迟控制在可接受的范围内。推理服务需要支持动态Batch，因为推荐请求的QPS波动很大，动态Batch可以提高GPU利用率。

A/B测试的方案设计有几个关键点。第一，实验组和对照组的流量分配要合理，通常实验组占10%到20%的流量，对照组占剩余流量。第二，评估指标要全面，不能只看CTR，还要看多样性、新颖性、长尾覆盖率等指标。第三，实验周期要足够长，通常至少跑一周，因为推荐系统有周期性波动。

我实测下来，生成式召回在CTR上的提升通常不会特别大（5%到10%），但在多样性和长尾覆盖率上的提升很明显（20%到50%）。所以评估生成式召回的效果，不能只看CTR，要看综合指标。

4.4 效果评估：离线指标与线上指标的对齐

效果评估是生成式推荐落地过程中最容易出问题的地方。离线指标和线上指标经常对不齐，离线看起来很好的模型，上线后效果可能很差。

离线评估通常用Recall@K、NDCG@K、Hit Rate等指标。但这些指标有个问题：它们假设候选集是固定的，而生成式推荐的候选集是模型生成的，不是固定的。所以传统的离线评估指标对生成式推荐不太适用。

我的做法是用生成式评估指标，比如生成序列和真实序列的编辑距离、生成序列的多样性、生成序列的新颖性等。这些指标更贴近生成式推荐的实际表现。

线上评估就是A/B测试，用真实的用户行为数据来评估模型效果。线上评估的关键是指标要对齐业务目标。如果业务目标是提升GMV，那就要看GMV相关的指标；如果业务目标是提升用户留存，那就要看留存相关的指标。

我踩过的一个坑是：离线指标很好，但线上效果很差。后来排查发现，离线评估用的数据分布和线上数据分布不一致。离线数据是历史数据，线上数据是实时数据，两者的分布有差异。解决方法是用时间切分的方式做离线评估，用过去的数据训练，用最近的数据评估，这样离线评估的结果更接近线上表现。

5. 常见问题与排查技巧实录

5.1 语义ID质量差导致召回效果不佳

这是生成式推荐最常见的问题。语义ID质量差的表现是：生成的语义ID对应的物品和用户历史行为不相关，或者语义ID的分布很不均匀，某些ID对应大量物品，某些ID对应很少物品。

排查思路是这样的：第一步，检查内容编码模型的质量。把语义向量做降维可视化，看看同类物品的语义向量是否聚在一起。如果同类物品的语义向量很分散，说明内容编码模型有问题，需要换模型或者做微调。

第二步，检查量化误差。计算原始语义向量和量化后向量的余弦相似度，如果相似度低于0.8，说明量化误差太大，需要增加码本大小或者增加量化层数。

第三步，检查语义ID的分布。统计每个语义ID对应的物品数量，如果分布很不均匀，说明码本有问题，需要重新初始化码本或者调整量化策略。

我踩过的一个坑是：码本大小设得太小，导致大量物品共享同一个语义ID，模型无法区分这些物品。后来把码本大小从128增加到256，问题就解决了。

5.2 生成结果同质化严重

生成结果同质化是另一个常见问题。表现是：模型生成的物品序列高度相似，缺乏多样性。

这个问题的根源通常是训练目标只优化了相关性，没有优化多样性。解决方法是在训练目标中加入多样性信号。具体做法有几种：一种是在损失函数中加入多样性正则项，惩罚生成序列中相似物品的比例；另一种是在训练数据中构造多样化的目标序列，让模型学习生成多样化的结果。

还有一个原因是推理阶段的采样策略太保守。如果只用贪心解码或者Beam Search，生成的结果会倾向于高概率的token，导致同质化。我的做法是用Top-K采样或者Nucleus采样，引入适当的随机性。Top-K的K值通常设为10到50，Nucleus的p值通常设为0.9到0.95。

5.3 推理延迟过高无法满足线上要求

推理延迟过高是生成式推荐落地的最大障碍。排查思路是这样的：第一步，定位延迟瓶颈。用Profiler工具分析推理过程的各个阶段，看看是模型前向计算慢，还是后处理慢，还是网络传输慢。

第二步，优化模型推理。可以用TensorRT或者ONNX Runtime做推理加速，也可以用模型量化把FP16降到INT8。我实测下来，INT8量化可以把推理延迟降低40%到60%，效果损失通常在1%以内。

第三步，优化服务架构。用动态Batch提高GPU利用率，用缓存减少重复计算，用分层生成降低单次推理的计算量。

我踩过的一个坑是：模型量化后效果损失很大。后来发现是量化方法不对，用了Post-Training Quantization，没有做Quantization-Aware Training。改成QAT之后，效果损失就控制住了。

5.4 冷启动场景下生成式推荐的表现

冷启动是生成式推荐的一个优势场景，因为语义ID本身就携带了物品的语义信息，不需要交互数据就能生成。但实际落地中，冷启动场景下生成式推荐的表现往往不如预期。

原因是：生成模型在训练时见到的物品都是有一定交互数据的，对于完全没有交互数据的新物品，模型的生成概率会很低。解决方法是：在训练时引入一些冷启动物品，让模型学习生成这些物品；或者在推理时对冷启动物品做概率补偿，提高它们被生成的概率。

我的做法是在训练数据中保留一定比例的冷启动物品，通常占5%到10%。这样模型既能学习热门物品的生成模式，也能学习冷启动物品的生成模式。

5.5 常见问题速查表

6. 从Large Recommendation Model到Recommendation Foundation Model的演进路径

6.1 当前工业界的技术成熟度评估

从我这几年在一线的观察来看，生成式推荐的技术成熟度可以分为三个阶段。

第一阶段是语义ID+生成式召回，这个阶段的技术已经相对成熟，工业界有不少团队在落地。核心工作是构建语义ID和训练生成式召回模型，技术难点主要在语义ID的质量和推理延迟的优化。

第二阶段是Large Recommendation Model，这个阶段的技术还在探索中。核心工作是把推荐模型做大做深，让模型能从更大规模的数据中持续获益。技术难点主要在训练效率和推理成本。

第三阶段是Recommendation Foundation Model，这个阶段还处于早期研究阶段。核心工作是构建一个通用的推荐基础模型，通过少量微调适配多种场景。技术难点主要在跨域泛化和统一评估。

我个人的判断是，第一阶段的技术在未来一两年内会成为工业界的主流方案，第二阶段的技术会在头部团队中开始落地，第三阶段的技术还需要更长时间的探索。

6.2 不同规模团队的技术选型建议

不同规模的团队，技术选型的策略应该不同。

对于小型团队（推荐团队人数少于5人），我建议先从语义ID+生成式召回开始，不要一上来就搞Large Recommendation Model。语义ID的构建可以用开源的多模态模型，生成式召回可以用开源的序列生成模型，整体技术门槛不高，效果提升也比较明显。

对于中型团队（推荐团队人数5到20人），可以在语义ID+生成式召回的基础上，尝试Large Recommendation Model。重点是把模型做大做深，探索scaling law在推荐场景下的表现。同时要开始建设推理加速的基础设施，为后续的模型部署做准备。

对于大型团队（推荐团队人数20人以上），可以开始探索Recommendation Foundation Model。重点是构建统一的语义ID空间，打通多个推荐场景，探索instruction tuning在推荐场景下的应用。同时要建设统一的评估体系，为跨场景的模型对比提供基础。

6.3 未来12个月值得关注的技术方向

未来12个月，有几个技术方向值得重点关注。

第一个方向是语义ID的标准化。目前语义ID的构建方法五花八门，没有统一的标准。未来可能会出现一些标准化的语义ID构建方案，降低技术落地的门槛。

第二个方向是生成式推荐的推理加速。推理延迟是生成式推荐落地的最大障碍，未来会有更多针对推荐场景的推理加速方案出现，比如专门的推理框架、专门的量化方法等。

第三个方向是多场景统一的推荐基础模型。目前推荐模型都是场景特定的，未来可能会出现一些跨场景的推荐基础模型，通过少量微调就能适配新场景。

第四个方向是生成式推荐的可解释性。生成式推荐的决策过程比传统推荐更复杂，可解释性更差。未来可能会有一些针对生成式推荐的可解释性方案出现，帮助业务方理解模型的决策逻辑。

6.4 我个人的实践体会

最后分享几个我个人的实践体会。

第一，不要为了生成而生成。生成式推荐不是万能的，它在某些场景下确实比传统推荐好，但在某些场景下可能不如传统推荐。技术选型要根据业务场景来定，不要盲目跟风。

第二，语义ID的质量决定生成式推荐的上限。我见过很多团队在生成模型上花了很多精力，但语义ID的质量很差，导致整体效果上不去。我的建议是先把语义ID做好，再考虑生成模型的优化。

第三，推理延迟是生成式推荐落地的关键。很多团队在离线评估时效果很好，但上线后发现延迟太高，无法满足业务要求。我的建议是在模型设计阶段就要考虑推理成本，不要等到上线了才发现问题。

第四，A/B测试是检验生成式推荐效果的唯一标准。离线指标再好，也要经过线上A/B测试的验证。我见过太多离线指标很好但线上效果很差的案例，所以一定要重视线上测试。

第五，生成式推荐是一个系统工程，不是单点技术。它涉及数据、模型、推理、评估等多个环节，每个环节都要做好，整体效果才能好。不要指望靠一个模型就能解决所有问题。

这个领域变化很快，我自己的认知也在不断更新。上面这些内容是基于我目前的实践经验总结的，不一定全对，但希望能给正在探索这个方向的同行一些参考。如果你也在做生成式推荐的落地，欢迎交流踩坑经验。