企业官网建设流程全解析

这两年我参加的每一场推荐系统技术分享，几乎都会被同一个问题打断：生成式推荐到底是不是又一个被包装出来的概念？到2026年再回头看，答案其实已经比较清晰——它没有替代传统推荐链路，但它在悄悄改写工业推荐的上限。这个从Large Recommendation Model到Recommendation Foundation Model的演进，不是单纯的“把模型变大”，而是一整套关于数据、架构、训练范式和评估体系的重新设计。

这篇调研算是我把过去一年看到的论文、开源项目、工业分享以及自己动手复现的一些实验结果，做了一个交叉验证后的整理。内容主要围绕Generative Recommendation、Large Recommendation Model、Recommendation Foundation Model这三个词展开，重点聊工业界真正在解决的问题，而不是学术论文里的理想假设。如果你是做推荐系统算法或架构的工程师，或者正在给团队做技术选型，这里面会有一些可以直接拿去用的判断框架。

1. 为什么工业界正在重写推荐系统的技术栈——三个正在被推翻的旧假设

我入行做推荐那会儿，整个系统的骨架是极其稳定的：召回、粗排、精排、重排，再加一层混排，每一层各司其职。双塔模型统治召回，Deep Interest Network那一代模型统治精排，特征工程占据了我们一大半的工时。这个架构能跑这么多年，是因为它背后有三个很朴素、很自洽的假设，但如今这三个假设正在被一项一项推翻。

第一个被推翻的假设是：用户意图可以被拆分成独立的、可计算的标签。传统推荐本质上是一个判别式任务，我们根据用户历史行为预测他会不会点某个商品，或者会喜欢哪一类内容。但用户的真实意图往往是连续的，甚至是模型自己都很难用几个标签概括的。生成式推荐从第一天起就不走这条路，它把用户行为序列当成一段“语言”，直接生成用户下一步最可能交互的候选对象。2023年前后Meta提出的GR4Rec（Generative Retrieval for Sequential Recommendation）就是用T5式的Encoder-Decoder结构，把用户行为编码之后直接输出item的token序列，这个思路在当时争议很大，但后来的工业实践表明，生成式方法在长尾兴趣挖掘上确实有判别式方法抓不到的优势。

第二个被推翻的假设是：item是一个静态的、可以通过精确检索得到的对象。传统召回里每个item对应一个Embedding向量，我们建ANN索引去做近邻检索。但item在海量场景下是动态变化的，新商品每天大量入库，Embedding本身也是模型训练过程中不断漂移的。生成式推荐换了一种方式：把item当作生成目标，而不是检索目标。模型学习的是用户状态到item id或item语义之间的映射关系，这相当于把“从千万级候选里捞一百个”的问题，变成了“根据上下文逐步解码出最合理的候选集合”的问题。工业界落地时通常不会完全放弃检索，而是把生成式模型当作候选生成器，再配合轻量级检索做召回兜底。

第三个被推翻的假设是：漏斗的各阶段可以独立优化。传统链路的召回模型、精排模型各自训练，各自调参，目标不一致的问题始终存在。而Large Recommendation Model的核心逻辑就是把召回、粗排、精排甚至重排的目标统一到一个模型里，所有阶段共享一套特征表示和一套优化目标。我在调研里看到的最典型实践是2023到2024年公开的HSTU（Hierarchical 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。把方向看清楚，比走快更重要。