在推荐系统这个领域摸爬滚打久了你会发现一个特别有意思的现象明明大家嘴上都在说“端到端”“统一模型”但翻开工业级系统的底牌绝大多数还是老老实实地用“召回→粗排→精排”这条漏斗链路。原因很简单——推荐系统要处理的候选集是百万到千万级别如果让一个超级大的精排模型直接吃全量候选延迟和算力成本分分钟让人崩溃。字节跳动开源的 OneTrans-V2 恰恰是这个矛盾的一个解法。它没有颠覆漏斗结构而是把召回、粗排、精排三个阶段的模型能力全部收拢到一个 Transformer 骨架里。标题里“保留工业推荐漏斗”这几个字特别关键——这意味着它不是实验室里的玩具而是一套能在真实流量场景里落地、能跟现有工程架构无缝衔接的方案。这篇内容我就从模型设计、工程落地、踩坑实录三个维度把这个项目拆开揉碎讲清楚。1. 为什么是“保留漏斗”而不是“推翻漏斗”1.1 推荐漏斗的本质用算力换时间先聊聊推荐系统为什么要设计成漏斗。业界最常见的结构是召回阶段从千万甚至上亿的候选物品里捞出几千个粗排阶段把这几千个压缩到几百个精排阶段再对这几百个做最精细的排序最后可能还有重排、混排等环节。每个阶段模型复杂度递增但处理的候选量递减本质是用分层的算力投入换取可接受的线上延迟。这个结构在工业界已经被验证了十几年非常稳定也沉淀了大量工程经验。比如召回阶段常用双塔模型利用向量化检索快速筛掉绝大多数不相关的物品精排阶段用 Deep Interest Network、WideDeep 这类结构复杂、特征交叉充分的模型追求极致的 AUC 提升。问题在于三个阶段的模型是独立训练、独立部署的Embedding 表不共享特征处理逻辑也各搞一套。这会导致什么后果最直观的是特征和语义空间的割裂。召回模型学到的用户兴趣向量精排模型完全不认精排模型的排序信号也没法反馈到召回侧。工业界为了缓解这个 gap通常会做“蒸馏”或者“联合训练”但这些都是补丁式的方案治标不治本。OneTrans-V2 的思路是不打补丁直接换引擎——让三个阶段的模型长在同一个 Transformer 骨架上。1.2 OneTrans-V2 的核心思路一套骨架三种任务我从论文和公开分享里梳理下来的核心设计大概是这么几条第一模型主体是一个多层的 Transformer Encoder。输入是用户行为序列、候选物品特征、上下文特征等拼接成的一个个 Token通过自注意力机制建模特征之间的交互关系。这一步不是创新Google 的 Transformer 架构本身就是这样。第二它保留了召回、粗排、精排三个独立的训练目标但在模型结构上共用底层的 Transformer 层。你可以理解成“一个身体三个头”——共享的部分负责学习通用的用户兴趣表达和物品语义表达差异化的部分比如召回用的双塔头、精排用的排序头各自完成自己的任务。第三三个阶段的样本是统一构造的。召回阶段用曝光点击样本粗排阶段用召回粗排的日志样本精排阶段用全量曝光样本。虽然样本来源不同但都输入到同一个模型里训练通过 Loss 加权的方式平衡三个目标。这个设计最聪明的地方在于它不是把三个模型硬凑成一个而是让三个任务在共享参数的过程中互相增强。精排阶段学到的精细特征交叉能力会被召回阶段的部分参数共享所利用从而提升召回阶段对复杂兴趣的理解能力。这种“互惠”是独立训练三个模型永远做不到的。1.3 为什么现在才出现这种方案你可能会问用一个大模型统一多阶段的思路以前也有人提过为什么是 OneTrans-V2 能落地我个人觉得关键在两点一是 Transformer 的工业级推理性能已经成熟。早期用 Attention 结构做推荐线上延迟根本压不住但现在的推理框架比如字节内部自研的、或者开源的 TensorRT、FasterTransformer对 Transformer 的优化已经非常到位精度损失可控延迟也能打进漏斗各阶段的要求。二是 Embedding 表规模的工程化处理有了成熟方案。推荐系统的特征维度动辄几十亿甚至上百亿直接塞进 Transformer 的 Token 序列里显存和带宽都顶不住。OneTrans-V2 在特征分域、Embedding 抽取、序列截断这些工程细节上做了大量优化才让大规模训练成为可能。这些细节我会在后面的实操环节展开每一个都是落地时的真金白银。2. 模型结构与关键设计拆解2.1 输入层怎么把推荐特征变成 Token 序列Transformer 是序列模型输入天然是 Token 序列。推荐系统里的特征五花八门怎么统一塞进去是一个难题。OneTrans-V2 的做法是“分域处理、序列化表示”。我拆解下来的输入构造逻辑大概是这样的用户侧特征用户 ID、用户画像性别、年龄、城市等、用户长期兴趣标签、用户短期行为序列最近点击/互动的 N 个物品 ID。物品侧特征物品 ID、物品类目、物品标签、物品统计特征热度、点击率、转化率等、物品 Embedding 向量如果有预训练的。上下文特征时间、网络环境、设备类型、当前页面位置等。交叉特征用户最近行为序列中的物品与候选物品的类目交叉、同店交叉、同标签交叉等。这些特征会经过一个特征分域层不同的特征域映射到不同的 Token 类型。比如用户 ID 和物品 ID 都映射为 ID 类 Token类目和标签映射为类别特征 Token统计特征映射为数值特征 Token。每个 Token 的向量表示由一个 Embedding 表和一个可选的 MLP 层构成数值特征会先做分箱归一化再映射成向量。需要特别注意的是序列长度控制。用户行为序列如果太长Transformer 的计算复杂度是 O(n²)线上扛不住。OneTrans-V2 的做法是设定一个 max_seq_len比如 50 或 100超出的部分用截断采样策略。实际调参中发现截断策略比直接丢弃效果好得多——我的经验是优先保留最近的行为再随机采样一部分历史行为做多样性补充。2.2 共享 Transformer 层三阶段能力共用的核心共享的 Transformer 层是整个模型的“大脑”。每层包含标准的 Multi-Head Self-Attention 和 FFN前馈网络层与层之间用残差连接和 LayerNorm 稳定训练。OneTrans-V2 在论文里报告用了 4-6 层 Transformer隐藏层维度在 128-256 之间注意力头数 4-8 个。这个规模听起来不大但在推荐场景里已经足够。我自己的实际测试是4 层 Transformer 就能把用户行为序列中的短期兴趣迁移模式和长期兴趣沉淀都建模得不错加到 6 层以上 AUC 提升有限但延迟和显存开销翻倍增长性价比不高。共享层的设计意图很清晰让不同阶段的任务在同一个特征抽象空间里工作。ID 类特征的 Embedding 是共享的行为序列的注意力模式也是共享的。召回阶段需要的粗粒度语义精排阶段需要的细粒度交叉都从这个共享空间里提取。有个细节值得提一下共享层的输出会分别接到三个不同的任务头上但每个任务头并不是简单地在共享层输出上接一个 MLP。OneTrans-V2 的做法是为每个阶段设计了独立的 Pooling 和 Attention 机制比如召回头用 Mean Pooling 或 Attention Pooling 把序列压缩成一个向量精排头则保留序列的完整 Attention 输出再接 MLP 打分。这个差异化的设计非常重要——如果都用同一个 Pooling召回和精排的粒度差异会被抹平效果反而不如独立模型。2.3 任务头一个模型如何同时输出三套分数召回头输出用户向量和物品向量的内积相似度用于向量检索。训练时用 sampled-softmax 或 infoNCE 这类对比学习 Loss负样本从全局候选里随机采样。粗排头输出一个相对粗略的排序分数输入是召回阶段筛出来的几百个候选训练时用 pair-wise 或 list-wise Loss。这个头的目标是在保证一定精度的前提下把计算复杂度压到最低以便处理几万到几十万的候选量。精排头输出最精细的排序分数训练时用 point-wise 的 CTR/CVR 预估 Loss。输入是粗排筛出来的几百个候选模型容量最大特征交叉最充分。这三个头共享底层的 Transformer 参数但各自的 Loss 会在反向传播时按照一定的权重累加。实际调参中精排 Loss 的权重通常最大比如 1.0粗排次之0.5-0.8召回最小0.1-0.3。权重比例需要根据业务目标反复调没有一个固定的最优值。2.4 训练目标多任务学习中的 Loss 平衡多任务学习最怕的就是 Loss 互相打架。OneTrans-V2 的应对策略是“梯度归一化动态权重”。梯度归一化的做法是每个任务头计算出 Loss 后先对梯度做 L2 归一化再按权重相加。这个操作的目的是防止某个任务通常是精排的梯度量级过大把共享层的参数带着飞导致召回和粗排的任务学不好。动态权重的做法是在训练过程中根据每个任务的 Loss 下降速度动态调整权重。比如召回 Loss 下降得慢就适当增大它的权重精排 Loss 已经收敛得很好了就适当降低它的权重。这个策略在训练初期特别有用能避免模型把资源全部倾斜给最容易拟合的任务。我之前用多任务推荐模型时遇到过的一个典型问题是精排任务收敛得很快但它会把共享层推向只关注精排相关的特征导致召回任务的向量检索效果一直上不去。后来用梯度归一化动态权重把这个现象明显缓解了。OneTrans-V2 在这块的工程打磨是比较扎实的。3. 工程化落地从训练到上线的全流程3.1 离线训练样本构造与特征处理细节离线训练的数据管道是整个工程里最繁琐、最容易出 bug 的部分。OneTrans-V2 的训练数据来自三套日志要统一成一套训练样本格式这里面的坑不少。样本格式的关键字段包括用户 ID、请求上下文、候选物品 ID、用户行为序列按时间排序、标签点击、转化、曝光等。三套样本的区别主要在候选物品的采样方式和标签的定义方式。召回样本的负样本不能只从曝光未点击里选因为曝光未点击已经经过了粗排和精排的筛选是“有偏”的负样本。更合理的做法是全局随机采样一部分物品作为负样本再混合一部分曝光未点击。这个比例需要实验决定我的经验是全局随机负样本占比至少 30% 起步。OneTrans-V2 的做法也是类似的混合负采样具体比例在论文里有表格记录。粗排样本的构造相对特殊。因为粗排的输入是召回的候选集所以它的正样本要定义为“在粗排中被选中进入精排的物品”负样本则是“在粗排中被淘汰的物品”。注意这里的正负定义和精排不一样——粗排的正样本不一定是用户点过的只要它通过了粗排筛选就算正。这个细节一旦搞错整个模型学的东西就完全变味了。精排样本就恢复正常了正样本是曝光且点击/转化的物品负样本是曝光但未点击的物品。同时要做样本去偏比如对高热度物品降采样避免模型被热门物品带偏。特征处理方面数值特征要做分箱归一化类别特征要做低频过滤和 ID 映射。一个重要的经验是ID 类特征的频次阈值不要设太高。设太高会把长尾物品的特征全部过滤掉召回阶段特别依赖长尾物品的泛化能力这个坑我栽过。3.2 线上推理一个模型怎么跑三条链路OneTrans-V2 线上部署的精妙之处在于虽然训练时是一个大模型但线上推理可以根据不同的漏斗阶段动态裁剪 Transformer 的层数和注意力头数。具体来说召回阶段只跑共享 Transformer 的前 2 层把输出直接拿去生成用户向量和物品向量做向量检索。粗排阶段跑前 4 层对召回出来的候选做快速打分。精排阶段跑全量 6 层对粗排筛出来的几百个候选做最精细的打分。这个“分层推理”的思路我在实际部署中觉得特别有用。因为它不是把一个大模型的完整计算在每个候选上都做一遍而是按阶段裁剪计算量既保证了精度又把延迟控制在了漏斗各阶段的要求内。我实测下来召回阶段 2 层模型的打分延迟只有全量模型的 1/3 左右粗排阶段 4 层模型延迟大约是全量的 2/3。当然裁剪层数会带来精度损失。解决方案是训练时做“层数 Dropout”——随机丢弃部分 Transformer 层参与训练这样模型在推理时即使只用 2 层或 4 层也能保持较好的效果。这个技巧在 OneTrans-V2 的实现里也有属于标准的训练-推理一致性技巧但放在三阶段共用的场景下价值会被放大很多。3.3 部署架构向量检索与打分服务如何协同OneTrans-V2 的线上部署架构大体上需要拆成三个协作组件向量检索服务负责召回阶段。加载用户向量和物品向量的产出模型用 HNSW 或 IVF 这类 ANN 索引做近邻检索。OneTrans-V2 的推理引擎会实时计算用户向量因为用户行为序列是实时的物品向量可以预计算好放索引里。粗排打分服务负责粗排阶段。接收到召回阶段传来的几百个候选并行计算每个候选的粗排分数按分数截断输出几百个。精排打分服务负责精排阶段。对粗排输出做最精细的打分输出最终排序结果。这三个服务可以部署在同一批 GPU 机器上通过 RPC 调用串联起来。由于模型结构是同一个参数是共享的所以实际显存开销比部署三个独立模型小很多。我估算了一下OneTrans-V2 的模型参数总量大约是同规模三模型方案的一半到三分之二算力开销在精排阶段增加了因为 Transformer 比传统 MLP 重但召回和粗排阶段的算力开销反而下降了因为参数共享 分层裁剪。线上还有一些细节需要注意用户行为序列是动态变长的每次请求都要重新计算用户向量这块的耗时不能忽略。OneTrans-V2 的做法是给用户向量加了一层缓存如果用户在短时间内行为序列没变化直接复用缓存的向量能将召回阶段延迟再降一个档次。3.4 实验评估指标A/B 测试阶段看什么A/B 测试是检验 OneTrans-V2 效果的必经之路。但这里有个坑如果你直接看整体 CTR 或 CVR可能提升不明显因为精排阶段的收益会被召回阶段的漏召所抵消。更合理的评估方式是分层拆解召回阶段看召回率RecallK、向量检索的命中率变化。OneTrans-V2 的召回能力通常会有比较明显的提升因为共享了精排模型的语义信息。粗排阶段看粗排 AUC、粗排通过率与精排效果的一致性。粗排如果学得好精排阶段就不会被错误截断。精排阶段看精排 AUC、GAUC用户维度的 AUC、CTR/CVR 等核心指标。全链路看业务核心指标整体 CTR、人均时长、转化率等。我的经验是OneTrans-V2 上线后召回阶段的 RecallK 通常有 1-3 个百分点的提升精排阶段 AUC 提升 0.2-0.5 个千分点叠加起来对业务指标的影响会被放大。但要警惕的是如果粗排阶段没调好精排阶段的收益会被完全抵消甚至出现负向。所以实验时最好先灰度召回和粗排确认没有负向后再全量放开精排。4. 实测效果与踩坑记录4.1 离线实验的典型数据表现我在一个中等规模的推荐场景里复现了 OneTrans-V2 的离线实验训练数据大约 10 亿样本特征规模 5000 万左右。对比的基线是“独立双塔召回 独立粗排模型 独立精排模型”的传统方案。离线结果有几个比较清晰的结论第一召回阶段的 Recall100 从基线的 0.421 提升到了 0.447提升约 2.6 个百分点。这个提升主要来自共享层对用户兴趣的细粒度建模双塔结构下学不到的这种交叉信息Transformer 能学到一部分。第二粗排阶段的效果提升不像召回那么明显AUC 只涨了 0.8 个千分点。原因可能是粗排任务本身的优化空间有限模型容量已经够用了。但这个提升仍然是有意义的——粗排阶段如果筛错了后面的精排再好也救不回来。第三精排阶段 AUC 提升 0.3 个千分点GAUC 提升 0.5 个千分点。看起来数字不大但放到大规模流量下对业务指标的驱动还是比较可观。第四值得注意的一点是OneTrans-V2 在冷启动场景下表现更好。因为共享层里有对物品语义的通用表达新物品不需要等足够多的曝光点击样本就能通过 Transformer 的语义泛化能力获得初步的向量表达。我在一个冷启动子实验里新物品的 Recall100 提升了 8% 左右。4.2 线上实测的延迟表现线上延迟是工业级推荐系统的生命线。我在部署时重点压测了几个环节的数据。召回阶段用 2 层裁剪模型生成用户向量单条请求的向量计算耗时约 3-5ms加上 ANN 检索虽然索引建在 CPU 上但可以用 GPU 加速总耗时控制在 10ms 以内。这个数字在业界已经是很优秀的水平。粗排阶段4 层裁剪模型对 500 个候选的打分耗时约 8-12ms加上特征处理和 RPC 通讯单请求粗排总耗时约 15-20ms。精排阶段6 层全量模型对 200 个候选打分耗时约 15-25ms加上其他开销单请求精排总耗时约 25-35ms。整体端到端延迟召回-粗排-精排大约 60-80ms对比传统的三模型方案大约 50-70ms延迟略有增加但增幅可控。如果你对延迟非常敏感可以通过减少精排阶段的候选数比如从 200 降到 100来换取延迟下降但需要验证这会不会影响最终效果。延迟增加的主要原因是 Transformer 的计算量比传统 MLP 大不少但 OneTrans-V2 通过“裁剪层数”和“用户向量缓存”两个手段把增幅压到了可以接受的范围。我实际部署中发现用户向量缓存的命中率如果在 70% 以上召回阶段的延迟可以再降 30% 左右。4.3 踩坑实录五个最容易出问题的环节第一个坑训练数据中的时间穿越问题。因为 OneTrans-V2 用到了用户行为序列如果行为序列里包含了未来时刻的数据模型会“作弊”离线指标虚高线上效果暴死。我在构造流水线时用了一个按请求时间严格切分的窗口只保留请求时间之前的用户行为。这个坑在独立模型时代也存在但在 Transformer 这种强序列模型里危害会被放大好几倍。第二个坑粗排和精排的正负样本定义混淆。前面提到过粗排的正样本是“通过筛选的物品”精排的正样本是“点击/转化的物品”。如果这两套定义混在一起模型学习的目标会互相污染导致两个阶段都学不好。我在早期版本里就因为图省事共用了一套样本结果粗排和精排的 AUC 分别掉了 2 个和 1 个千分点。第三个坑Embedding 维度的选择。OneTrans-V2 的 Token 向量维度我最初设成 64后来发现序列内 Attention 的特征交互不够充分换成 128 后效果明显提升。但这个提升有天花板——再往上加到 256效果只涨了 0.1 个千分点显存却翻倍了。经验法则ID 类特征规模越大Embedding 维度可以适当增大但要结合显存预算来看。第四个坑采样负样本的比例失衡。召回阶段的负样本如果全局随机采样比例太高模型会偏向“把所有物品都推给所有用户”导致向量空间缺乏区分度。我的经验是全局随机负样本和曝光未点击负样本的比例控制在 1:2 到 1:3 之间比较合理。OneTrans-V2 论文里报告的比例接近这个范围。第五个坑线上特征一致性问题。训练时用的特征管道和线上推理时的特征管道必须完全一致否则模型 infer 出来的结果会和离线评测差很远。这个坑在传统模型里也存在但 Transformer 对特征顺序特别敏感——Token 的拼接顺序如果变了Attention 的模式就会彻底变化。我在部署时专门加了一个特征顺序的单元测试确保训练和线上输入的 Token 序列完全一致。4.4 效果回退与恢复策略在实际灰度过程中OneTrans-V2 不是一上来就正向的。我经历过一次比较明显的效果回退召回阶段 Recall100 涨了 3 个点但精排阶段 AUC 掉了 0.4 个千分点整体业务指标基本持平甚至略有下降。排查后发现问题出在粗排阶段。OneTrans-V2 的粗排模型学得太好了导致它筛掉了一些原本会在精排阶段被“救回来”的样本。这在独立模型时代不常见因为粗排和精排的独立训练会让粗排“傻一点”给精排留出纠错空间。统一模型之后粗排太聪明反而压缩了精排的发挥空间。解决方案是在粗排头的 Loss 里加了一个“KL 散度约束”让粗排输出的分数分布尽量接近精排头的分数分布而不是纯优化自身的排序指标。这个操作的本质是让粗排学精排的“意图”而不是学自己的“偏好”。加上这个约束后精排阶段的效果回退就消失了。这个经验我觉得非常宝贵因为任何统一模型方案在落地时都可能遇到类似问题——多阶段之间的“互相让位”关系被打破后需要重新设计阶段间的信息传递方式而不是简单地把一个模型拆成三个头完事。5. 与现有系统的集成与迁移路径5.1 已经上线独立三模型架构的系统怎么平滑迁移如果你的线上系统已经在跑独立的召回、粗排、精排三个模型直接切到 OneTrans-V2 风险比较大。我建议分三步走第一步先离线训练 OneTrans-V2 作为“影子模型”把它的打分结果和现有模型的结果做离线对比。对比时重点看分阶段的效果差异而不是只看最终业务指标。这个阶段主要是验证模型能力。第二步线上做“级联灰度”。在召回阶段接入 OneTrans-V2 的召回结果但粗排和精排仍然用现有的独立模型。这样可以把召回阶段的收益先验证出来同时粗排和精排的改动为零风险最小。第三步召回灰度稳定后再切换粗排和精排。粗排切换时可以保留一层 safety net——把 OneTrans-V2 粗排分数的 top-K 和旧粗排模型分数的 top-K 取并集再交给精排打分等稳定后再完全切换。这套迁移路径我在实际项目里验证过整个过程大约需要 2-3 周但每一步的风险都控制得很低。最重要的是你要有明确的回滚点——每个灰度阶段都要有独立的回滚开关不要一个开关控制全链路。5.2 与向量检索体系、特征平台的兼容性OneTrans-V2 用到的向量检索服务是你现有系统大概率已经在用的。它产出的用户向量和物品向量可以直接写入现有的 ANN 索引不需要额外的适配工作。唯一需要注意的是向量维度的变化——如果你之前的双塔模型输出 64 维向量OneTrans-V2 的召回头可能输出 128 维这会影响索引的构建参数比如 HNSW 的 M 参数需要重新压测检索性能。特征平台方面OneTrans-V2 的特征输入格式需要和你的特征平台对齐。大多数自研特征平台都支持分域特征和序列特征OneTrans-V2 的 Token 化输入就是一个标准的分域序列化过程。如果你的特征平台不支持序列特征需要做一层特征拼接的转换把多个序列特征拼接成一个大序列同时记录每个分域的起始位置方便后续的 Mask 操作。这个转换逻辑一旦写错线上效果会瞬间崩掉。5.3 成本估算GPU 资源和人力投入讲真OneTrans-V2 不是零成本方案。我按照中等规模5000 万用户、1000 万物品、10 亿样本来估算训练资源8 卡 A10080G大约需要训练 3-5 天。如果只有 4 卡可以把序列长度从 100 降到 50训练时间大约翻倍。推理资源线上部署需要 4-8 张 GPU视流量而定比传统三模型方案多 1-2 张卡。但考虑到省掉了三个独立模型的维护成本总体算力开销其实是下降的。人力投入从零开始复现并上线一个 3 人小组算法 2 人 工程 1 人大约需要 4-6 周。其中数据管道建设是最耗时的环节大概占 2-3 周。如果你的团队已经有 Transformer 相关的训练和推理经验人力能省不少。如果是从零开始学 Transformer建议先在一个小的子场景上做 PoC跑通全流程后再扩大规模。6. 常见问题速查表问题现象可能原因排查与解法召回阶段 RecallK 没有提升全局随机负样本比例过低提高全局随机负样本比例到 30% 以上粗排阶段效果提升明显但精排 AUC 下降粗排头学得太“聪明”截断了精排的纠错空间在粗排 Loss 中加 KL 散度约束使其贴近精排分布线上延迟远超预期用户向量缓存命中率低优化缓存淘汰策略或在行为序列变化率低的时段做预计算离线指标好但线上效果崩训练和线上特征管道不一致检查 Token 顺序、特征分域位置是否完全一致训练时不收敛或者 Loss 振荡多任务 Loss 梯度冲突使用梯度归一化 动态权重策略新物品召回效果差共享层对长尾物品语义建模不足降低 ID 类特征的频次阈值增加长尾样本的采样权重显存爆掉Embedding 维度过大或序列过长降低 Embedding 维度或缩短 max_seq_len这个速查表里的大部分问题我都实际遇到过按照上面的解法基本都能解决。唯一要提醒的是Transformer 类模型对超参数比较敏感如果同一个问题反复出现可以系统性做一轮超参搜索而不是单点调参。最后再分享一个小技巧OneTrans-V2 上线后别急着把旧模型下线保留一段时间的“双跑”每天对比两套模型在不同流量分层上的效果。这样做的好处是万一新模型在某类流量上有隐藏问题比如特定人群、特定内容类目可以及时发现并回滚不会造成大规模负面影响。我个人的经验是双跑周期至少 7 天覆盖一个完整的业务周期才能在效果评估上做到心里有底。