企业官网建设流程全解析

端到端生成式框架这个词，最近在推荐系统圈子里有点热度。我注意到某头部短视频平台自研的OneSug框架，以“效果、性能双突破”的姿态入选了AI领域顶级会议，引发了不少讨论。这个框架到底解决的是推荐系统里的哪个老大难，入选顶会的含金量在哪，以及我们自己如果要复现或借鉴，有哪些技术细节是文档里不会明说的，今天就用一篇实操向的文章把它拆透。

我会按照从业者看技术方案的方式，从老推荐系统的结构性问题讲起，落到OneSug的建模思路、训练和部署中的关键决策，最后分享一些我在类似生成式推荐项目上踩过的坑。内容会尽量保持可复现性，偏底层的原理讲清楚，偏工程的说清楚为什么这么做，而不是简单堆名词。

1. 推荐系统为什么需要“端到端生成式框架”：先看清老方案的痛点

1.1 级联漏斗的隐形成本

大部分工业级推荐系统，现在还是“召回-粗排-精排-重排”这种级联漏斗结构。召回阶段用双塔、物品向量或简单的规则，从几亿商品里圈出几千个候选；粗排用轻量模型把候选缩到几百；精排再用复杂模型算一个精细的点击率或时长分数；最后重排做多样性、商业规则、新鲜度之类的调节。

这套体系工程上很成熟，团队里每个人各管一段，上线也方便。但问题在于，每一个阶段都是一次信息的有损压缩。召回阶段如果没把真正用户会喜欢的物品圈进来，后面精排再强也白搭。而为了让召回能覆盖广，往往得牺牲精度；为了延迟可控，粗排又得牺牲模型复杂度。每一层都在做权衡，但层与层之间的目标还不完全一致——召回优化的是“相关性”，精排优化的是“点击率”，重排优化的是“时长和多样性”，最终用户体验实际上是被这些不一致的目标拉来拉去的。

更麻烦的是，这种级联结构天然不适合建模“用户下一顿想吃A而不是B”的序列依赖。用户的连续行为本身是一条时间线，精排模型虽然能看到更长的行为序列，但候选集已经固定了，它没法在候选生成阶段就考虑“用户刷完这个视频后，下一个动作是什么”。用一句行话来说，传统方法把推荐当成“从一个固定集合里挑TopK”，而不是“生成用户接下来最可能的动作序列”。

1.2 生成式推荐：把推荐问题重新定义为序列生成

OneSug走的是另一条路：把推荐当成一个条件生成任务。输入是用户的历史行为序列，输出是一段有序的候选商品ID序列，整个候选生成和打分的过程放在一个端到端模型里完成。模型不再需要几千路召回，不依赖提前构建的候选池打分，而是直接“写”出用户接下来可能点击的ID序列。

这个思路的本质，是把用户的行为时间线当作一种语言序列，然后训练一个类似语言模型的解码器，让它在给定历史上下文的条件下，逐步生成未来的交互ID。它绕开了级联漏斗的层层压缩，让模型拥有更大的表达空间——候选序列是动态生成的，而不是在固定候选池里排序。

当然，这里有个很多人一上来就会问的问题：候选集通常几亿甚至几十亿，生成式模型怎么可能输出一个几亿词表的token？这正是OneSug这类框架最核心的技术挑战，也是它能够入选顶会的原因之一。后面我会专门讲模型是怎么设计离散编码空间来压缩词表的。

1.3 OneSug主要解决了哪两个层面

从公开出来的信息看，OneSug的“双突破”可以拧成两条线来理解。

效果层面，端到端建模解决了信息损失和目标不一致的问题。传统链路里召回模型还在用向量相似度，召回结果和精排目标隔了好几层；OneSug直接面向最终业务目标做序列生成，在离线评测和线上A/B里都拿到了可观的提升，尤其是对长时效行为、多目标（点击、时长、互动）的联合优化改善明显。

性能层面，生成式模型天然有计算量大的问题，OneSug能落地，说明它在工程上做了大量压缩和加速：模型结构轻量化、序列剪枝、动态解码、batch推理优化等。这两点加在一起，才配得上“双突破”的说法。如果只看效果不考虑性能，那文章只会躺在论文库里，不会真正跑在线上。

2. OneSug的模型设计：如何把推荐变成条件序列生成

2.1 商品ID的离散编码：用原型向量压缩词表

生成式推荐第一个绕不开的问题：词表多大？视频平台的商品量级至少千万起步，如果直接把每个视频ID当一个token来生成，输出层的计算量会大到没法落地。OneSug的做法是，把商品ID映射到一个离散编码空间里，用k个code组合表示一个商品。

你可以这么理解：假设我们有一个包含几千个“原型向量”的码本，每个原型向量代表一类语义相近的商品。一个商品的表征，用几个原型向量的组合来表示，就像说“一只白色、长毛、中型犬”，用几个属性组合指代一个具体物种。这样生成模型只需要输出这些code组合，而不用从几亿个ID里挑一个。

这种离散编码方案的另一个好处是泛化。长尾商品虽然本身出现次数少，但如果它的编码组合在语义空间里和热门商品靠近，模型就能靠这些共享的原型向量学到一定的规律，冷启动压力会小很多。

实操上，码本大小、code数量都是超参。我当时试过类似的方案，码本太小会导致不同商品撞编码，码本太大又会增加解码复杂度。OneSug的公开分享里提到过他们在这方面做了大量实验，最终选择一个比较均衡的配置——具体数值不一定通用，但调参方向是明确的。

2.2 条件编码器与自回归解码器

模型骨架是典型的Transformer结构，分成两个部分：左侧是用户行为序列编码器，输入用户近期的交互记录（点击、搜索、看播、关注等），用attention结构把这些行为编码成一个条件向量；右侧是自回归解码器，从左到右逐个生成目标商品对应的离散code序列。

生成过程类似语言模型解码，每一步根据之前生成的code来预测下一个code。推理时并不是直接生成一个商品就完事，而是利用beam search保留多条候选路径，最后输出一个长度为N的候选序列。这个候选序列相当于传统多路召回的结果，可以替代召回阶段和一部分粗排工作。

有一个关键细节：生成顺序是有意义的。传统精排模型会给每个商品独立打分，而生成式模型天然把“前一个候选”当作后一个候选的条件，这其实隐含了对列表特征的建模。比如用户连续刷了两个美妆视频之后，第三个推荐时尚穿搭的概率会更高，这种二阶甚至高阶关系在传统打分框架里很难显式刻画。

2.3 多目标融合：不是简单加权重

推荐系统的业务目标从来不是单一指标。平台既希望用户点击，还希望用户沉浸，又希望互动率提升。OneSug的做法是把多目标融合直接嵌入生成过程，而不是等到生成完再排序过滤。

具体来说，训练时对不同目标（点击、完播、互动、关注）配置不同奖励。用强化学习或者带权重的最大似然估计来引导模型，让模型在生成序列时不仅考虑“用户会不会点”，还考虑“点完之后会不会继续看”。这个思路和语言模型里用RLHF对齐用户偏好很像，只不过目标是推荐系统的多业务指标。

多目标融合最容易翻车的地方是目标之间的冲突。点击高的内容往往是标题党或猎奇内容，完播率高的内容反而可能信息密度低。OneSug这类框架的好处是，可以在同一个序列生成过程中通过调节不同阶段的偏置来实现“前几个更重点击，后几个更重深度”这种策略，比传统重排模块更自然。

3. 效果与性能双突破的实现路径：训练、蒸馏与线上部署

3.1 训练数据怎么造：用户行为序列变目标序列

生成式推荐训练数据的构造方式和传统精排不一样。传统精排是拿用户和候选物品做特征拼接，生成式模型需要的是完整的输入输出对：输入是用户历史交互序列，输出是用户未来一段时间的交互商品序列。

我的经验是，这个数据清洗过程比模型本身更加决定上限。有几个坑：

• 行为序列要按时间排序，同时消除误点击和无效点击（比如播放时长小于2秒的曝光通常要过滤）。
• 正样本不能只看曝光点击，还要考虑搜索、关注、分享等强意图信号。
• 序列目标长度要根据实际业务场景设，太短学不到跨会话依赖，太长会把噪声也学进来。

当时我们在做类似项目时，数据清洗用了整整两周，线上效果一直不理想，最后发现是有大量点击来自自动播放的无意曝光。把这类样本过滤掉之后，指标立刻有了明显变化。

3.2 预训练加微调是目前比较可行的路线

直接从零训练一个端到端的序列生成模型，在短视频这种大规模流量场景下成本极高。OneSug的实践走的是预训练+微调路线：先在其它任务（比如用户行为预测、商品表征学习）上做大规模无监督预训练，再在推荐目标上做有监督微调。

这个思路和NLP领域预训练模型一脉相承。预训练阶段可以从海量用户行为日志中学会商品之间的共现关系、用户的兴趣演化模式；微调阶段再对齐业务指标。对我们来说，最大的启发是：如果你有小几百万的训练数据，直接上端到端模型很容易过拟合；如果用用户行为日志先预训练编码器，再用精排目标微调，模型稳定性和最终效果都会明显好不少。

3.3 性能优化的几个实操方向

端到端生成式模型要在线上跑起来，最棘手的还是延迟。一个自回归Transformer，每生成一个token就要做一次前向计算，生成一个候选序列可能要解码几十步，这个成本对在线服务来说是致命的。OneSug在压缩延迟方面，公开信息里有几个方向值得关注：

模型蒸馏。用大模型当老师，让小模型去学它的生成分布。线上部署的模型参数量要比离线训练模型小一到两个量级，靠蒸馏尽量保住效果。这个做法在精排模型里很常见，但在生成式模型上更关键，因为生成式模型的计算量通常和序列长度成正比。

解码策略优化。语言模型生成通常要用beam search，但beam search在推荐场景里性价比不高。OneSug的自适应解码，可以根据用户行为序列的置信度动态调整生成长度，如果用户的兴趣比较明确，就少生成几步，直接截断；如果不明确，再多生成几个候选。这个技术听起来不起眼，但对线上延迟的收益非常大。

batch推理和算子融合。把多个请求拼成一个batch，利用GPU的并行能力。同时把矩阵运算和激活函数、层归一化融合成少数的kernel，减少显存读写。这些工程优化不需要改模型结构，但收益稳定，也是线上部署的基本功。

我在自测时发现，如果不做解码长度控制，生成式模型的P99延迟会高2到3倍，而加了一个简单的“早停”策略以后，延迟能降到可接受范围，同时离线评估指标几乎不掉。这说明很多时候性能瓶颈不是模型本身，而是解码策略没有针对线上实时性做适配。

4. 落地踩坑记录：生成式推荐不是上了就能赢

4.1 候选重复与多样性的失衡

生成式模型容易出现一个非常典型的毛病：在beam search时倾向于生成大量相似商品。因为相似商品的embedding很接近，它们的条件概率也比较接近，最后候选序列里一半都是同类型甚至重复的内容。

这其实是语言模型生成里的老问题，放到推荐场景会直接影响用户体验。OneSug在方案里引入的多样化解码，本质是通过惩罚机制降低连续重复code的概率，同时对不同候选路径之间做差异性度量。

我们自己做的时候，最简单的保底方案是：在生成序列后加一个去重和多样性约束的轻量后处理模块。虽然它有点违背“端到端”的纯净性，但为了防止线上事故，这种保护机制是必要的。OneSug的效果到底有多好，部分原因就在于它把多样性约束做在了模型内部，而不是事后补救。

4.2 冷启动商品的生成困难

冷启动是推荐系统永远的敌人。生成式模型对低频商品的编码学习天然处于劣势。新商品在码本里没有稳定的code组合，模型的生成概率会非常低，就算偶尔生成出来，排名也会被更热门商品压下去。

OneSug这类框架处理冷启动，通常是在编码空间上做文章。比如新商品可以先利用内容信息（标题、封面、特征标签）映射到已有的码本向量空间，而不是等它积累点击行为。这个过程可以和“新商品上线”这条链路打通，在入库时就计算好商品的离散编码，用的时候直接查表。

如果你要在自己的项目里落地，一定要把新商品的编码回填流程做成实时或准实时，不然一天下来新商品完全没有曝光，模型很快会退化成只推荐老爆款，整个生态就死了。

4.3 线上延迟抖动与回退机制

生成式模型的推理时间不稳定，尤其当用户历史序列长度波动大时，解码步数可能差异很大。线上流量峰值时，纯生成式服务很容易被长尾请求打满CPU或GPU。

应对策略第一是把用户历史序列长度统一裁剪到一个固定窗口（比如64或128个行为），如果超出就截断，这样能控制特征的输入规模。第二是给解码器设置一个硬性最大步数，宁可牺牲一点效果也要保证服务稳定。第三是设计降级回退逻辑，如果生成式服务超时，切回传统双塔召回，保证用户体验不出现真空。

我在实践中最大的感受是：生成式推荐上线时，一定要能做灰度平滑放量，并准备一条完整的回退链路。因为生成式模型的行为比打分模型更难预测，全量上线前没人能保证不会出现意外。

4.4 离线指标和线上指标的“错位”

离线评估生成式推荐往往很难完全反映线上表现。比如离线用hitrate或者Recall@K评估，模型只要在候选序列里包含用户点击过的商品就算对了，但线上用户的满意度还包括内容的新鲜度、多样性、以及推荐之后用户会不会继续停留。指标设计和业务目标对不齐，很容易出现离线涨得很好，线上却没有明显变化的尴尬情况。

我当时做过一个项目，离线指标提升了将近15%，线上CTR反而掉了0.3%。后来发现原因是离线指标对重复内容敏感，模型学会了“重复推荐用户点过的同类商品”来刷分，而这种行为让用户产生了厌烦。所以搭建离线评测集时，一定要把重复度、多样性、新鲜度这些维度也量化进去，最好把线上体验的核心原则转成可计算的离线指标。

5. 从OneSug看下一阶段：生成式推荐会取代召回和精排吗

5.1 一个更合理的演进路径

OneSug的落地并不意味着传统召回和精排会被立刻彻底替换。至少在现阶段，推荐系统更适合走“生成式召回+传统精排”或者“生成式粗排+传统精排”的融合路线。

为什么？因为生成式模型虽然能直接产出候选序列，但它对排序的精细度把控还是不如一个专门的精排模型。精排模型可以对最终候选做非常精细的特征交叉和分数校准，而生成式模型的输出更侧重“全局合理性”。所以在实际工程里，比较稳妥的做法是用OneSug替换掉原先多路召回的一部分路，或者直接替代粗排层，输出几百个高质量候选，再交给精排模型做最后的打分。

OneSug入选顶会，意义在于它证明了生成式模型在推荐系统的工业级场景里，可以从论文走向落地。从这个角度看，它其实是把推荐系统和NLP大模型这两条技术线真正拉到同一个框架里了，后续的想象空间很大。

5.2 推荐大模型化的三条可复制经验

结合OneSug以及我自己折腾生成式推荐项目的经历，有几条经验是可以平移到其他场景的：

第一，不要一上来就做“纯粹”的端到端。先把生成式模型接入到现有链路的某一个环节，跑通闭环再逐步扩大范围，这样风险和恢复成本都可控。

第二，训练成本要算细账。端到端生成式模型的训练计算量远大于传统模型，团队需要有GPU资源支持和训练加速能力。如果资源有限，可以通过预训练+蒸馏来减少重复训练的成本。

第三，数据质量和数据分布的影响远大于模型结构。行为序列里噪声大的平台，生成式模型很容易学到“推荐重复内容”这类捷径，必须有完善的数据清洗和特征工程配合。

5.3 个人体会与一点建议

我在实际接触生成式推荐的过程中，最强烈的感受是：这类模型把“算法”和“工程”之间的距离拉近了很多。以前做召回和精排，可以在不同团队并行开发；现在做端到端生成式框架，你既要懂模型结构、又要懂数据管道、还要懂在线推理优化。这对个人和团队的能力栈都提出了更高要求。

如果你是带着搜索或者NLP背景切入推荐系统，OneSug这类框架会给你一种亲切感——它本质上就是一个序列生成任务，很多解码技巧、蒸馏方案、预训练策略都可以从语言模型那边直接搬过来用。如果你是从传统推荐系统走过来，也不需要担心完全推倒重来，因为大量积累的特征工程和业务理解依然有用，只是模型的输入输出形态变了。

最后再分享一个小技巧：在尝试复现OneSug这类框架时，不要急着把完整的模型服务上线。可以先离线跑通一个缩小版——用最近一周的日志训练一个规模减半的模型，在召回阶段做A/B，和现有双塔召回对比。等确认生成式召回的候选质量确实更优，再逐步增加解码长度、模型参数量和在线流量。这样每一步都有数据支撑，也不会一上来就把线上搞得不可收拾。生成式推荐这扇门已经打开了，接下来怎么走，最终拼的还是谁能在效果、性能和工程稳定性之间找到那个平衡点。