企业官网建设流程全解析

做推荐系统这些年，我越来越觉得传统那套“召回→粗排→精排→重排→解释生成”的链路有点笨重。每个环节一个模型，每轮迭代都要重新训练、联调、压测，线上的问题还经常互相甩锅。最近我们团队把整套流程收拢成了一个端到端生成式推荐框架，项目代号叫 OneSug（One Suggestion），用一个统一的生成模型同时完成推荐决策和推荐理由生成。效果上，核心业务指标涨了不止一个点；性能上，靠着受限解码和 KV Cache 复用，单次请求的推理延迟也压到了日常可用。这项工作近期被人工智能领域的顶级学术会议录用，也算是对这个方向的一个阶段总结。

这篇内容我不会讲太多论文式的空话，重点说清楚 OneSug 到底在解决什么问题、核心架构怎么设计、效果和性能双突破是怎么做到的，以及我们在工业落地时踩过的坑。对正在搞推荐系统、尤其是想尝试“生成式推荐”的同行来说，应该会有一些能直接搬回去用的东西。

1. OneSug 到底在解决什么问题

1.1 传统推荐系统的“模块割裂”困局

大部分推荐系统都不是单点模型，而是一条流水线。以短视频和电商场景为例，线上链路一般是召回、粗排、精排、重排，最后还可能挂一个文案模块给推荐结果生成理由。听起来很完善，但实际维护过这套系统的人都懂，它有几个非常磨人的内科病。

首先是目标不一致。召回模块追求的是覆盖度，希望把用户可能感兴趣的东西尽量捞回来；精排模块追求的是点击率或时长；重排模块又要兼顾多样性和商业约束；解释文案模块则只关心语言通顺不通顺。每个模块都在优化自己的局部目标，但放到一起时，它们之间没有一个人对整体结果负责。

其次是级联误差。召回阶段从千万级候选里筛出几百个，如果这一层漏掉了用户真正想看的，后面精排再强也救不回来。每到这种时候，大家就会在机制上打补丁，比如给召回加样本、加特征、加额外通道，链路越来越长，补丁越来越多。

再就是维护成本。一条流水线上的模型少则四五个，多则七八个，每个模型都要单独准备样本、做特征工程、配置训练任务、上线监控。改一个上游模型的输出格式，下游模型和数据管道都得跟着改。团队里经常出现“改完召回之后，精排莫名其妙跌点了”的诡异情况，最后查半天发现是特征分布变了。

用装修来解释可能更直白：传统推荐系统就像分别请了水电工、木工和油漆工，每个人手艺都不差，但没有一个总设计师对最终住进去的体验负责。结果就是客厅灯挺亮，墙也刷了，但插座位置和家具摆放互相打架。OneSug 想做的事情，就是换一种施工方式：让一个人从头到尾把整套活干完，从理解需求到出方案再到交付，一次性产出。

1.2 生成式思路的破局点

生成式推荐的核心想法是：别再把推荐当成“打分排序”，而是把它当成“序列生成”。给定用户的历史行为、场景上下文和候选池，让模型直接生成一个推荐列表，顺带生成一句解释文案。有点像你和某个熟悉你的朋友聊天，问“今天有什么好看的”，他直接告诉你——“你最近喜欢看户外类的，这部露营纪录片的节奏刚好，还有一期是讲高原天气的”。

这个思路不是拍脑袋想的，它有几个很现实的好处。

第一，任务统一。推荐和解释不再由多个模型分头完成，而是一个模型、一次推理、一套梯度信号。用户在页面上看到的物品列表和理由，从一个模型里长出来，天然一致。

第二，共享表征。生成模型需要同时理解“用户喜欢什么”“什么东西和什么东西像”“这句话怎么表达才自然”，这三个能力在同一个 Transformer 里互相复用，比分开训练三个模型的数据利用效率高得多。

第三，符合内容流场景。短视频和信息流本身就是按顺序展示内容的，用户消費的是一个序列，而不是孤立的一堆格子。用序列生成的方式来建模内容分发，逻辑上更贴近业务本质。

当然，把整个链路压成一个模型，工程上的代价也不小。最大的挑战就是推理性能：自回归生成是一个 token 一个 token 往外蹦的，候选空间又有千万级，弄不好线上延迟直接爆炸。OneSug 的整个设计，其实都是围绕“能不能让这种生成在工业环境里跑起来”展开的。

1.3 OneSug 的项目定位与实践边界

先说清楚，OneSug 不是要做一个人畜无害的学术原型。项目立项时目标就很明确：做成一套能进线上推荐主链路、替代现有“多模块串行”的生成式框架，并且性能和效果都要能打。

它的典型应用场景有两类。一类是列表推荐：进入首页后，基于用户历史行为，一次性生成一个推荐页面；另一类是交互式推荐：用户说“我想看轻松点的”，模型能够根据这个请求动态生成新的推荐内容和对应的解释。后者这类场景，传统的多模块链路处理起来非常吃力，因为用户表达是开放式的，很难用一个离散的槽位模板去覆盖。

OneSug 的设计目标我总结成三句话：一个模型统一预测与生成，一次解码输出列表与解释，一套参数同时优化效果与性能。项目代号里的 “Sug” 就是 Suggestion 的缩写，OneSug 的意思比较直白——“只出一个建议”。

2. OneSug 的核心架构：一个模型生成推荐

2.1 把行为、物品与上下文统一做成 Token

做生成式推荐，第一个绕不开的问题就是：输入和输出怎么表示。推荐系统里最常用的表达方式是 feature embedding，也就是把用户、物品、场景都映射成稠密向量。但生成模型不是这么玩的，它吃的是离散 token。所以 OneSug 做的第一件事，是把推荐系统里的各种信息全部转成 token 序列。

用户侧的信息主要来自历史行为。我们把用户最近看过的内容 ID、看过的内容类型、停留时长等级、行为发生的时间间隔都离散化成 token。时间间隔不是原始秒数，而是做分桶：比如“5分钟以内”“5到15分钟”“1小时以上”，每种分桶对应一个 token，这种粗粒度表示反而更稳，因为秒级数值对生成模型来说没有意义。

物品侧的信息也是类似思路。每个内容有自己的 ID、所属类目、标签、作者 ID、甚至封面图的视觉聚类 ID，这些都能映射成 token。但这里有一个非常现实的问题：候选集的规模是千万量级的，不可能给每个内容 ID 都留一个词表位置，词表太大不仅存不下，训练时还会让 token 分布极度稀疏。

OneSug 的处理方式是用“语义索引 + 分组 token”的思路。具体来说，模型不直接在一个千万量级的 ID 词表上做分类，而是把物品先映射到一个相对小的语义空间（比如几十万量级的簇），生成的时候先预测簇，再在簇内做细粒度的选择。这就把千万级别的输出空间拆成了两级，训练和推理的复杂度都降下来了。

上下文信息也一样。时段、星期几、用户所在城市、网络状态、设备型号，这些拼进输入序列里作为条件 token。模型在生成时能看到“现在是晚上十点，用户用 WiFi 连着，历史里刷了三条美食视频”，有了这些条件，推荐结果会更贴近具体场景。

2.2 训练目标：先学“预测下一个”，再学“解释为什么”

OneSug 的训练目标不是单一的，而是三个目标一起学。

第一个是 next-item prediction，也就是给定历史行为序列，预测下一个要展示给用户的内容。这是推荐生成模型的基础能力，训练样本来自线上真实的曝光和点击数据，核心思想是让模型学会“什么内容最有可能成为用户的下一个选择”。

第二个是 listwise generation。单点预测只能学会“下一个推什么”，但推荐场景要的是一整页，而且这些内容之间还要有差异性。所以我们在训练时会把一整段推荐列表作为生成目标，比如输入用户行为序列，输出的是一个连续 token 段，代表五个物品 ID。这样做的好处是，模型不仅要考虑“每个物品单独好不好”，还得考虑“这五个放一起合不合适”，多样性信息被直接编入训练目标。

第三个是 explanation generation。也就是让模型同时学会生成一句推荐理由。这个目标的训练样本来源比较麻烦，纯靠用户行为数据无法回答“为什么推荐这个”。我们用的是“后验文案匹配”的方式：从线上日志里提取用户看完之后真的发生了互动（比如点了关注、看完了完整视频）的样本，再让离线模型为这些匹配生成参考文案，之后进入训练管线。

三个目标的 loss 直接相加，但各自权重不同。这里有个实际教训：解释任务的 loss 量级通常比推荐任务的 loss 大很多，因为语言模型的交叉熵在短句上很容易收敛。权重如果不做约束，模型会“偷懒”，把精力都放在把句子说通顺上，推荐准确率反而被稀释。我们试过在 loss 上加不确定性加权，也试过两阶段训练——先用行为数据预训练推荐能力，再拿文案数据精调解释能力。我们的实践结果是：分阶段训练的效果更稳定，联合训练后期容易震荡，需要反复调权重，太耗时。

2.3 模型本身：为什么是 Decoder-Only 自回归

确定输入输出形式之后，就是选模型骨架。 OneSug 采用的是 decoder-only 的自回归结构，类似现在主流语言模型的范式。

为什么不选 encoder-decoder？原因有两个。一是推荐输出本身既有结构化 token（物品 ID），又有自然语言 token（解释文案），这两类 token 用同一个解码器处理起来更顺，不需要额外设计 bridge 模块；二是工业部署时，decoder-only 只有一个模型体，加载、请求、缓存都更简单。线上推理每多一个模块，延迟和故障点就多一分。

模型整体的工作方式可以描述得很直白。输入侧把用户行为、上下文、候选约束拼成一个序列；解码侧先生成结构化部分，也就是“物品1 token 物品2 token ...”，再生成文本部分，也就是“推荐理由”。这两段输出之间其实没有严格分隔，模型可以从结构化 token 无缝切到文本 token，因为训练时我们就在两者之间加了特殊分隔符。

细节上，OneSug 在解码时做了“结构化约束”，这是和普通语言模型最大的区别。普通语言模型每个位置都可以从全词表里选 token，而 OneSug 在物品槽位只允许从候选索引里选 token，这些候选是先用向量检索从千万级内容里筛出来的几百个“可选项”。这样既约束了解码空间，又大幅缩小了搜索范围，属于工业可用的关键设计。

2.4 一个可供参考的模型配置

每个场景的 Vocab、序列长度和模型尺寸都会不一样，但我们可以给出一个内部跑通过的基准配置框架，供参考。这个配置在千万级候选、单卡训练的条件下是可行的。

这个配置不是最优解，但胜在稳。大模型的收益在推荐场景里并不是线性的，尤其当候选被限制以后，模型容量堆到一定程度就进入平台期。与其卷参数量，不如把数据质量做扎实。

3. 效果与性能双突破的关键细节

3.1 效果为什么能涨：端到端建模消除级联损失

先说效果。OneSug 上线后，离线评估和在线实验都有明显提升。深入分析之后，我觉得能涨的核心原因不是单个模块变强了，而是“端到端”这个属性带来了三个结构性优势。

第一个优势是训练信号的一致性。传统链路里，精排模型只看到召回模块丢过来的候选集合，它没法知道召回阶段漏掉什么；而 OneSug 在训练时直接把“从全库中选什么”和“选完之后排什么”的目标统一了。模型学到的表示同时服务于召回和排序，而不是各学各的。相当于原来两个教练分别训练球员的进攻和防守，现在一个教练同时盯全场，整体战术自然更连贯。

第二个优势是上下文信息在链路里无损传递。传统精排阶段看到的特征已经是经过召回路筛选和加工的“二手特征”，很多原始行为信号在被截断或聚合时丢了。OneSug 是全程拿着原始行为序列在做生成，信息损耗小得多。尤其在用户兴趣比较冷门的情况下，传统召回层很可能直接把这些兴趣过滤掉，而生成模型还可以通过长尾 token 之间的组合关系拿出内容。

第三个优势是解释和推荐互相反哺。解释文案并不是可有可无的装饰。训练时，解释生成任务要求模型理解“为什么推荐这个内容”，这种理解会被反向编码进推荐模块的 attention 权重里。我们做了个内部对比，把解释生成任务从训练中摘掉，推荐准确率会掉一小截，说明文案任务确实在帮助模型更深入地理解用户与内容的匹配关系，而不是单纯的附属品。

3.2 性能优化的主战场：一次解码搞定千万级候选

效果再好看，线上推理跑不动也是白搭。生成式推荐上线前，团队里反对声音最大的就是性能——大家普遍觉得自回归解码不可能替代毫秒级的向量检索和排序。OneSug 实际做下来，确实需要一轮硬核优化才能把延迟压到可用范围，主要打法是围绕“解码”下功夫。

第一步是候选约束。这一条最重要。我们不会让模型在千万级词表上做 full softmax，而是先通过ANN（近似最近邻）+ 简单规则把候选缩小到 200 到 500 个。解码时，物品槽位只能从这几个候选 token 里挑，相当于从“大海捞针”变成“小筐择菜”。这个操作直接让解码时间降了一个数量级，而且没有明显效果损失，因为真正值得选的候选大概率已经被向量召回覆盖了。

第二步是结构化解码。OneSug 会先生成一个“输出 plan”，比如“接下来我要输出 5 个物品和 1 段文案”，模型依据这个 plan 严格按槽位填充。配合强制前缀机制，每个位置该生成什么类型（物品还是文本）在解码前就确定了，既防止输出格式乱掉，也减少了解码分支数量。

第三步是 KV Cache 的极致复用。自回归解码对 Cache 的依赖极高。OneSug 在线上接收请求时，同一个用户短时间内的多次请求可以复用前缀 Cache；同一个 batch 内部做 dynamic padding，保持序列长度对齐；模型的量化也专门针对 KV Cache 做了内存压缩。这一套组合拳下来，单机吞吐能支撑线上流量，P99 延迟被控制在可接受范围内。

有个数字可参考：在一次基准测试里，同样的候选规模下，不做候选约束的生成式方案单请求延迟约 350ms；经过候选约束和结构化解码之后降到 80ms 左右；再加上 KV Cache 复用和量化，最终稳定在 40ms 附近。这个延迟虽然比传统精排模型的几条毫秒要慢，但考虑到一个模型同时干了召回、排序、重排和解释四件事，这个成本是划算的。

3.3 一份可复现的优化清单

把 OneSug 落地过程中的优化点整理成清单，方便直接对照自查。

每个优化点单独拿出来都不难实现，难的是它们之间的配合。候选约束做小了，模型效果会跌；KV Cache 复用做激进，线上流量突增时容易内存暴涨。这些参数的平衡要靠线下压测和线上灰度一起调，没有一劳永逸的配置。

4. 技术落地中的典型问题与排查实录

4.1 候选暴露偏移导致生成结果“头重脚轻”

OneSug 上线后的第一版，就出现了一个典型问题：生成结果严重偏向高热度内容。模型刷出来的推荐列表，前几个永远是头部爆款，哪怕用户行为已经表现出了很明显的长尾兴趣。

排查下来，原因还是数据偏差。训练样本来自线上日志，而线上日志里的曝光和点击天然偏向头部内容，模型从中学到的分布自然也被带偏。这和传统精排模型遇到的问题类似，但因为生成模型通过自回归把上下文关系串了起来，这种“热偏差”会被 token 之间的相互影响放大。

解决办法分两步。训练侧，我们对训练样本做了倾向性加权，给低热度内容的曝光样本提高采样权重，同时构造了部分“全局随机曝光”样本，让模型见过被随机打扰的分布；在线侧，解码时对高温内容 token 做了额外的概率惩罚，抬高长尾内容在候选中的相对权重。这两板斧下去，列表的长尾覆盖率明显回升。

4.2 Beam Search 的“复读机”问题

生成式推荐里最容易遇到的反直觉现象是：模型会连续推荐非常相似的内容。你让它生成五个视频推荐，它可能给出同一个作者拍的五条不同视频，或者同类型但内容几乎重复的五条。表面看每个物品单独打分都不低，但放到一起用户感知就是“怎么全是这类”，体验很差。

这股现象完全等同于聊天机器人中的“重复生成”问题。原因在于 beam search 天然擅长找局部最优，如果某个类型在条件概率上稍微占优，就会被一路放大。我们尝试过两个方案：一个是在解码时对已出现在结果集合里的相似 token 做重复惩罚；另一个是把多样性的约束直接写进训练目标——之前提到的 listwise 目标就派上用场了，它让模型在训练时就要考虑整段列表的整体合理性，而不只是每个位置的局部最优。

现在线上用的策略是这两者叠加：训练时学多样性习惯，解码时做重复惩罚硬兜底。这种方式在长短期效果之间找到了平衡。

4.3 多任务 Loss 互相打架

OneSug 同时训练推荐和解释两个任务，实际训练中踩到最狠的坑是：推荐准确率没怎么涨，解释文案先变得异常模板化。模型学会了生成“这个视频很好看，快来看看吧”这种泛泛而谈的废话，而这样的文案对用户其实没有信息量。

我们花了挺长时间才定位到原因。解释任务收敛太快，它的 loss 很快就压到了很低的位置，而推荐任务还在慢悠悠地学决策边界。梯度更新中，解释任务的梯度占比越来越大，把推荐任务的信号给盖住了。加上一开始是直接用加权求和的方式联合训练，权重比例又偏向了解释端。

后来改成两阶段方案：第一阶段只学行为序列上的 next-item 与 listwise 目标，让 model 先变成“一个懂内容的人”；第二阶段冻结推荐主干的底层参数，只对高层和解释模块做文案精调。这样解释任务就不会再干扰推荐能力。如果想在数据量很大的场景下玩联合训练，建议用不确定性加权来自动平衡两个 loss，而不是手动给固定权重。

4.4 线上时延抖动与稳定性问题

性能优化做得再好，线上还是会出现偶发抖动。我们遇到过两类比较典型的场景。

第一类是热门事件爆发时的流量尖峰。短时间涌入大量用户，每个人的行为序列都包含同一个热点事件，KV Cache 复用率骤降，显存开销飙升，P99 延迟会突然翻倍。我们的应对办法是给解码加上 token 数量上限，并把超长请求降级到“只生成结构化推荐、不生成文案，减少整体解码长度”。这种降级策略对用户感知影响很小，但能保证系统不被打垮。

第二类是长序列用户的解码问题。有的用户历史行为特别长，输入序列都超过了 1024 上限。直接截断会造成最近的兴趣信息丢失，全量塞进去又让内存和延迟爆炸。我们做了分层处理：用一小段高权重的最新行为，加上一部分经过摘要模型的长期兴趣摘要，共同构成输入序列，兼顾实时兴趣和长期偏好。

4.5 常见问题速查表

5. 评估这套系统的正确姿势

5.1 离线评估：推荐和解释要分开看

生成式推荐系统的评估比传统推荐要复杂，因为输出里面同时有物品序列和文案。如果只用一个指标去衡量，很容易自欺欺人。我们的做法是分成三条线。

推荐侧用 HR（Hit Rate）、NDCG、GAUC 这类经典指标，衡量物品序列和用户真实交互的匹配程度。解释侧用 BLEU、Rouge 这类文本相似度指标，但这里有个坑：文本指标只能衡量“像不像参考文案”，不能反映“用户喜不喜欢”。所以我们还会安排人工评估，从流畅性、相关性和个性化三个维度打分。系统侧再看端到端目标，比如页面整体互动率、单次会话的时长。

这里特别推荐一个内部经常用的伪指标：解释与推荐的一致性。我们会让标注员看生成的推荐列表和生成的文案，然后判断“文案是否真的在解释这些物品的选择原因”。很多模型单独看推荐和文案都不错，合在一起却驴唇不对马嘴，这一维度能把这个大问题直接照出来。

5.2 在线实验与人工评估怎么配合

OneSug 这类改动牵一发动全身，不能一上来就直接替换主链路。我们采用的是三档灰度节奏。

第一档是小流量影子模式，线上正常跑老链路，同时把请求复制一份给 OneSug，只记录结果不真正展示，用来比对两套系统的指标差异。这一阶段的成本低、风险小，能快速暴露模型在真实流量下的表现。

第二档是低比例 A/B 实验，通常 5% 到 10% 的流量切到新系统，观察一周核心指标：点击率、人均时长、次日留存。重点不是看一两天，而是看整个周期内的稳定性。

第三档是地理或用户群的分桶灰度，逐步放大到 50%，最后全量。过程中要有人工评估团队持续盯样例，不能完全依赖数据指标，因为数据指标会被短期行为干扰，比如点击率涨了但用户后续其实更累了，这种钝化现象只有人工抽检才能率先感知。

5.3 工程验收：吞吐、延迟与稳定性

除了模型效果，工程层面的验收也要前置。我们通常用三组指标卡口：延迟（P50、P95、P99）、吞吐（单机 QPS）和稳定性（成功率、错误率、超时率）。相对于那些指标激进的调优方案，我们还是倾向于保守迭代——每次改动都限流观察，宁可慢一点也不要线上翻车。

还有一个容易被忽视的指标是解码长度分布。自回归模型在不同的请求上有不同的输出长度，如果某个请求的输出长度意外超长，会拖慢整个批次的速度。我们会在线监控输出长度均值与极限值，一旦发现异常就主动截断并及时排查。

6. 项目做完之后的一点实在体会

6.1 第一件事：先把链路打通，再谈模型变大

回头看 OneSug 的整个过程，踩过最浪费时间的坑，就是一上来就把精力花在了模型结构调优上。真正让效果突飞猛进的节点，其实是数据管线和候选索引的调整。建议想做同类方向的团队，先用一个不太大的模型把“输入行为序列 → 输出物品 token → 输出解释 token”的链路完整跑通，中间哪怕效果差一点都没关系。链路通了，后面所有的优化才有验证的载体，线路不通，模型调得再花哨也无处安放。

6.2 第二件事：性能优化不只是工程问题，也影响效果

传统项目里，模型效果归算法，延迟归工程，两个团队各管一摊。但生成式推荐里，性能优化手段会直接影响生成质量。候选约束如果太紧，模型就看不到足够的候选，效果损失肉眼可见；KV Cache 复用策略太激进，长尾请求的生成质量会下滑。所以做这种系统的团队，最好让算法和工程同学坐在一起，从第一天就共同为“延迟与效果联合最优”负责，不要等到模型冻结了才开始考虑性能。

6.3 这个项目还能往哪里走

OneSug 目前还只是文本和结构化 token 的生成。我们内部已经在讨论向多模态扩展，比如根据视频封面图特征生成 token，让推荐内容从“看过哪些”升级到“可能喜欢哪个画面风格”；另一个方向是把用户实时反馈（比如点赞、滑动、留言）在解码过程中就动态并入生成条件，做到真正的交互式推荐。OneSug 的框架应该还能承载这些扩展，毕竟自回归生成的好处就是条件可以不断往输入里加，输出形式也可以越来越丰富。

如果让我给同行一句实在建议，那就是：别被“生成式推荐模型很大、跑不动”的固有印象吓住。先把推荐问题正确地翻译成生成问题，再把这套系统的链路跑通，性能问题总能靠工程手段一步步磨平。这套路，我们在 OneSug 上已经验证过了。