OneTrans-V2：统一召回与排序的生成式检索架构落地实践-北京尧图网络

1. 从两个模块到一条链路OneTrans-V2 到底想解决什么问题推荐系统这个行当干了几年之后你会发现一个特别拧巴的现实召回和排序明明是同一个目标的两段路却硬生生被拆成了两套模型、两套特征、两套工程链路。召回阶段用双塔讲究的是快几毫秒内从上千万候选里捞出几百个排序阶段用精排模型讲究的是准把这几百个掰开揉碎算个明白。问题就出在这个“交接”上——召回觉得不错的排序未必买账排序真正想要的召回压根没送上来。两边各自优化各自的指标最后拼在一起整体效果就卡在一个天花板上下不来。字节这次放出来的OneTrans-V2核心思路就是把这层窗户纸捅破用一个 Transformer 把召回和排序统一到同一条序列建模链路里。你不需要再维护两套割裂的模型也不需要再纠结“召回该给排序喂什么”因为从候选生成到最终打分走的是同一套注意力机制、同一套表征空间。这个方向其实不算全新业界喊“生成式检索”“统一建模”喊了有一阵子了但真正把它做到工业级可用、并且敢在字节这种体量的场景上落地的OneTrans-V2 算是把很多细节啃下来了。我先把话说在前头这篇不是论文翻译也不是官方通稿的复述。我结合自己做过推荐链路的经验把 OneTrans-V2 这套东西拆成“为什么这么设计”“关键环节怎么落地”“实际会踩哪些坑”三个层面来讲。适合谁看如果你正在做推荐系统、搜索排序或者对 Transformer 在工业推荐里的落地感兴趣尤其是被“召回排序不一致”这个问题折磨过的同学这篇应该能给你一些可以直接抄作业的思路。哪怕你只是听说过“生成式检索”这个词但没搞明白它到底怎么跑起来的我也会尽量用大白话把它讲透。先说结论性的判断OneTrans-V2 的价值不在于它发明了什么惊天动地的算子而在于它把统一建模这件事从“能跑通”推进到了“能扛住线上流量”。这中间的差距做过工程的人都懂——实验室里 F1 涨两个点容易线上 QPS 不掉、延迟不炸、效果还稳那是另一回事。2. 统一召回与排序的底层逻辑拆解2.1 为什么“双塔精排”的老架构会撞墙要理解 OneTrans-V2 为什么这么设计得先搞清楚老架构到底卡在哪。传统的召回排序两段式本质上是信息不对称下的妥协。召回阶段面对的是全量候选可能是千万甚至亿级别你不可能对每个候选都跑一遍复杂的交叉特征所以只能用双塔用户塔和物品塔各自编码成向量最后算个内积或者余弦相似度。这个结构的致命伤是用户和物品在编码阶段完全没有交互所有的交叉信息都被压缩进了那个固定维度的向量里信息损失是必然的。排序阶段就不一样了它只面对几百个候选可以奢侈地把用户特征、物品特征、上下文特征全部拼在一起送进一个复杂的 DNN 或者 Transformer 里做充分的交叉。所以排序模型天然比召回模型“聪明”。但问题来了召回送给排序的候选集是用一个“笨”模型选出来的。如果真正的好物品在召回阶段就被漏掉了排序再聪明也无力回天。这就是所谓的“召回天花板”。更麻烦的是两个阶段的目标函数往往不一致。召回优化的是“召回率”“HitRate”排序优化的是“AUC”“GAUC”。召回为了让指标好看可能会倾向于召回一些“大众款”因为这样命中率高但排序真正想要的是那些“小众但精准”的物品。两边目标一错位整体效率就下来了。我见过太多团队召回指标涨了排序指标也涨了但最终线上 GMV 没动就是因为两段之间的“接口”没对齐。2.2 OneTrans-V2 的核心思路把候选也当成序列来建模OneTrans-V2 的破局点用一句话概括就是不再把召回和排序当成两个任务而是当成一个“序列到序列”的生成问题。具体来说它把用户的历史行为序列、候选物品序列、上下文特征全部拼成一条长序列送进一个统一的 Transformer 里。Transformer 的自注意力机制天然擅长处理序列内部元素之间的交互用户行为 token 和候选物品 token 在每一层都能互相“看见”、互相影响。这个设计最妙的地方在于召回和排序共享了同一套注意力权重和表征空间。召回阶段模型学会的是“从全量候选里挑出和用户历史最相关的那些”排序阶段模型学会的是“在这些相关候选里哪个最可能被点击/转化”。因为用的是同一个模型召回学到的表征天然对排序友好排序的梯度也能反传回去优化召回的表征。这就从根子上解决了“两段目标不一致”的问题。你可以把它想象成一个经验丰富的导购他脑子里既装着“这个顾客大概喜欢什么品类”召回也装着“这几件里哪件最适合现在推荐”排序。这两个判断在他脑子里是同时发生、互相影响的而不是先由一个实习生筛一遍、再由他精挑。OneTrans-V2 做的就是把这个“导购”用一个 Transformer 实现出来。2.3 生成式检索在其中的角色热词里出现了“生成式检索”这其实是 OneTrans-V2 里一个很关键的组件。传统的召回是“向量检索”——把物品编码成向量用 ANN近似最近邻去捞。但 OneTrans-V2 走的是生成式检索的路子模型直接生成候选物品的标识比如物品 ID 或者语义 ID而不是去向量库里比对。这两者的区别在哪向量检索的问题是物品向量是离线算好的用户向量是线上算的两者在同一个空间里比对但物品向量没法根据当前用户动态调整。生成式检索则是端到端的模型根据用户当前的状态直接“说出”它认为最相关的物品。这中间没有离线预计算的信息损失也没有 ANN 检索的精度折损。当然代价是生成过程比向量检索慢所以 OneTrans-V2 在工程上做了大量优化来压延迟这个后面会细讲。生成式检索还有一个隐藏好处它天然支持“多路召回”的融合。传统多路召回是多个双塔各自捞一批然后合并去重。OneTrans-V2 里不同的召回信号比如协同过滤信号、内容信号、热度信号可以作为不同的 token 前缀或者不同的注意力头来体现模型自己学会怎么融合它们而不是靠人工拍权重。3. 核心模块与关键技术细节3.1 序列构造token 怎么排、特征怎么塞OneTrans-V2 的第一个工程难点就是怎么把五花八门的特征塞进一条序列里。推荐系统的特征类型极其杂乱有离散的 ID 类特征用户 ID、物品 ID、类目 ID有连续的数值特征价格、点击率统计有变长的行为序列用户最近点击的 N 个物品还有上下文特征时间、地点、设备。这些特征维度不同、类型不同要统一到 Transformer 的输入格式里需要一套精细的 token 化方案。根据常见的工业实践OneTrans-V2 大概率采用了分层 token 化的策略。用户侧的特征画像、长期行为被编码成一组“用户 token”物品侧的特征被编码成“物品 token”上下文特征被编码成“上下文 token”。然后这些 token 按照一定的顺序拼接通常是用户 token 在前上下文 token 居中候选物品 token 在后。这样设计的原因是Transformer 的注意力是有位置编码的把用户信息放在前面可以让候选物品在计算注意力时“回顾”到完整的用户状态。行为序列的处理更讲究。用户最近点击的 50 个物品不可能每个都展开成完整的特征那样序列长度会爆炸。常见的做法是对行为序列做层次化压缩先用一个小型 Transformer 或者 pooling 把行为序列压成固定长度的向量再把这个向量作为几个“行为 token”塞进主序列。这样既保留了行为信息又控制了序列长度。我实测下来这种压缩方式在序列长度和效果之间能找到一个不错的平衡点压缩比大概在 5:1 到 10:1 之间比较合适。注意序列长度是 OneTrans-V2 最敏感的超参之一。序列太短用户兴趣建模不充分序列太长注意力计算量是平方级增长延迟扛不住。工业界常见的做法是主序列控制在 512 到 1024 个 token行为序列单独压缩后再拼接。3.2 注意力机制的选择与优化标准 Transformer 的自注意力是 O(n²) 的复杂度n 是序列长度。当 n 到 1024 的时候注意力矩阵就是百万级别显存和算力都吃不消。OneTrans-V2 要在线上跑必须解决这个问题。从公开的技术路线看它大概率用了稀疏注意力分块计算的组合拳。稀疏注意力的思路是不是每个 token 都和其他所有 token 计算注意力而是只和一部分 token 计算。比如用户 token 只需要关注行为 token 和候选 token候选 token 之间不需要互相注意因为候选之间是独立的。这种结构化稀疏能把复杂度从 O(n²) 降到 O(n·k)k 是每个 token 平均关注的 token 数。分块计算则是把长序列切成若干块块内做全注意力块间做稀疏注意力进一步降低显存峰值。另一个关键优化是KV Cache 的复用。在生成式检索里模型是自回归地生成候选物品的每生成一个 token 都要重新计算注意力。如果每次都从头算延迟会高得离谱。KV Cache 的做法是把已经算过的 key 和 value 缓存下来生成新 token 时只计算新的 query和缓存的 KV 做注意力。这个优化能把生成延迟降低一个数量级是生成式检索能上线的关键。我踩过的一个坑是KV Cache 虽然快但它对显存的占用是随序列长度线性增长的。如果线上并发高每个请求都维护一份 KV Cache显存很快就爆了。解决办法是动态批处理 Cache 分页把不同请求的 KV Cache 分页存储按需加载。这套东西实现起来不复杂但调优很费功夫页大小、批大小、淘汰策略都要根据实际流量调。3.3 召回与排序的联合训练目标OneTrans-V2 最核心的技术点是召回和排序的联合训练。如果只是把两个任务塞进一个模型但各自用各自的 loss那和两段式没有本质区别。真正的统一需要设计一个能同时优化召回和排序的联合目标。常见的做法是多任务学习对比学习的组合。召回部分用对比学习把用户真实交互过的物品作为正样本随机采样的物品作为负样本让模型学会把正样本的分数拉高、负样本的分数压低。排序部分用点击率/转化率的交叉熵损失。两个 loss 加权求和权重需要仔细调。召回 loss 权重太高模型会偏向“广撒网”排序精度下降排序 loss 权重太高模型会过拟合到少数热门物品召回多样性变差。根据我的经验召回 loss 和排序 loss 的权重比在 1:2 到 1:3 之间比较稳。这个比例不是拍脑袋来的而是因为排序任务的梯度信号更“稠密”每个样本都有明确的 label召回任务的梯度信号相对“稀疏”只有正样本和采样负样本。让排序 loss 占主导能保证模型不会跑偏。当然具体比例还要根据业务场景调电商场景可能更偏排序内容场景可能更偏召回。还有一个细节是负样本的采样策略。召回部分的负样本如果全是随机采的模型学到的区分度会很弱因为随机负样本太容易区分了。更好的做法是难负样本挖掘用当前的模型对一批候选打分挑出那些分数高但实际没交互的作为负样本。这些“hard negative”能让模型学到更精细的边界。OneTrans-V2 大概率用了这种在线难负样本挖掘的机制因为这是工业界统一建模的标配。4. 工程落地从离线实验到线上服务4.1 训练链路的搭建要点OneTrans-V2 这种统一模型训练链路的复杂度比两段式高一个量级。两段式的时候召回和排序可以分开训练、分开部署互不干扰。统一之后训练数据要同时包含召回的正负样本和排序的正负样本数据管道的吞吐量要求翻倍。我建议的训练链路是这样的离线特征存储 - 样本拼接 - 序列化 - 分布式训练 - 模型导出。特征存储用 HDFS 或者对象存储都行关键是样本拼接要高效。因为 OneTrans-V2 的序列很长每个样本的序列化开销不小如果拼接逻辑写得低效训练速度会被数据管道拖垮。常见的优化是预序列化内存映射把特征提前序列化成二进制格式训练时直接内存映射读取避免重复的解析开销。分布式训练方面因为模型参数量大统一模型通常比单段模型大 2-3 倍单卡肯定放不下。需要用数据并行模型并行的混合策略。数据并行负责拆分 batch模型并行负责拆分 Transformer 层。通信开销是大头尤其是注意力层的 all-reduce。用 NVIDIA 的 NCCL 做通信后端配合梯度累积能把通信和计算重叠起来训练效率能提升 30% 以上。提示统一模型的训练不稳定是常态。我遇到过 loss 突然爆炸的情况排查下来是召回部分的难负样本采样太激进导致梯度方差过大。解决办法是给难负样本的 loss 加一个温度系数或者用梯度裁剪把梯度范数限制在合理范围。4.2 线上推理的延迟优化线上推理是 OneTrans-V2 最大的工程挑战。召回要求毫秒级返回排序可以稍微慢一点但也不能超过几十毫秒。统一模型把两个阶段的计算合并了总计算量其实是增加的怎么把延迟压下来第一招是模型量化。把 FP32 的权重和激活量化成 FP16 甚至 INT8计算量能降一半到四分之三精度损失通常在可接受范围内。量化的时候要注意注意力层的 softmax 对精度比较敏感最好保持 FP16其他层可以大胆用 INT8。第二招是算子融合。Transformer 里有很多可以融合的算子比如 LayerNorm Linear、Attention Residual。融合之后能减少显存读写次数延迟能降 20% 左右。TensorRT 和 ONNX Runtime 都提供了自动融合的能力但自动融合不一定最优关键路径上的算子最好手动调优。第三招是请求级批处理。线上请求是零散到来的如果每个请求单独推理GPU 利用率很低。把短时间内到达的请求攒成一个 batch 一起推理能大幅提升吞吐。批大小的选择是个权衡批太大单个请求的延迟会增加因为要等 batch 攒满批太小吞吐上不去。常见的做法是动态批处理设置一个最大等待时间比如 5ms在等待时间内尽可能攒批超时就用当前攒到的请求推理。我实测下来动态批处理能把 GPU 利用率从 30% 提到 70% 以上延迟只增加 2-3ms性价比很高。但要注意批处理对显存的要求更高因为要同时维护多个请求的 KV Cache。显存不够的时候要么减小批大小要么用 Cache 分页。4.3 效果评估与线上实验统一模型的效果评估比两段式复杂。两段式的时候召回看召回率排序看 AUC指标清晰。统一之后模型输出的是一个融合了召回和排序的分数怎么评估我的做法是分层评估。第一层看整体指标线上 CTR、转化率、人均点击次数。这些是最终的业务指标最能说明问题。第二层看召回质量从模型生成的候选里统计有多少是用户最终交互的这相当于召回率。第三层看排序质量在模型生成的候选里排序的 AUC 是多少。三层指标结合起来能定位问题出在召回还是排序。线上实验要特别注意流量分配。统一模型和两段式模型的延迟特性不同如果直接切全量流量可能会因为延迟波动影响用户体验。稳妥的做法是灰度发布先切 1% 流量观察延迟和效果稳定后再逐步放大。灰度期间要密切监控 P99 延迟一旦超过阈值立即回滚。还有一个容易被忽略的点是冷启动。统一模型对历史行为依赖很重新用户没有行为序列模型可能表现很差。解决办法是混合策略新用户走传统的热度召回或者内容召回等积累了足够行为再切换到统一模型。这个切换阈值需要根据业务数据调通常 5-10 次交互之后统一模型的效果就能超过传统策略。5. 常见问题与排查技巧实录5.1 训练不收敛怎么办统一模型训练不收敛是最常见的问题表现是 loss 震荡或者一直不下降。排查思路按优先级来问题现象可能原因排查方法解决办法loss 震荡剧烈学习率太大打印每步 loss看震荡幅度学习率降 10 倍加 warmuploss 不下降梯度消失打印各层梯度范数加 LayerNorm用残差连接loss 突然爆炸难负样本太激进检查负样本分数分布加温度系数梯度裁剪召回 loss 降但排序 loss 升任务冲突分别打印两个 loss调 loss 权重加梯度手术我踩过最坑的一次是 loss 一直不降排查了两天才发现是位置编码的 bug。序列拼接的时候用户 token 和物品 token 的位置编码重叠了导致模型分不清哪个是用户、哪个是物品。这种 bug 很隐蔽因为 loss 不会报错只是不下降。后来我养成了一个习惯每次改序列构造逻辑都先可视化位置编码确认没有重叠再跑训练。5.2 线上延迟突然飙升怎么排查延迟飙升是线上最紧急的问题排查要快。我的排查顺序是看监控大盘先确认是全局延迟涨了还是某个机房、某个模型版本涨了。如果只是某个版本涨直接回滚。看 GPU 利用率如果 GPU 利用率突然掉到很低说明是请求堆积或者批处理逻辑出问题。如果 GPU 利用率打满说明是计算量涨了可能是序列长度变了或者模型变大了。看 KV Cache 命中率生成式检索的延迟对 KV Cache 命中率很敏感。如果命中率下降说明请求的序列模式变了Cache 没复用上。看网络分布式推理的时候网络抖动也会导致延迟飙升。检查 NCCL 的通信时间。有一次线上延迟从 20ms 涨到 200ms排查下来是动态批处理的等待时间设太长了。当时为了提升吞吐把最大等待时间从 5ms 调到了 20ms结果低峰期请求少每个请求都要等满 20ms 才推理。后来改成自适应等待根据当前 QPS 动态调等待时间QPS 高的时候等短一点QPS 低的时候等长一点。这个改动把低峰期的延迟降回了 25ms 左右。5.3 效果不如两段式怎么办统一模型的效果理论上应该优于两段式但实际落地时经常出现“统一模型离线指标好线上效果反而差”的情况。原因通常有三个第一是特征穿越。统一模型的序列里包含了候选物品的特征如果这些特征在训练时用了未来信息离线指标会虚高线上就露馅了。排查方法是严格检查特征的时间戳确保每个特征在预测时刻都是可获取的。第二是样本偏差。两段式的时候排序模型的训练样本是召回模型筛选过的分布比较集中。统一之后模型要同时处理全量候选样本分布更分散如果采样策略没调好模型会学偏。解决办法是分层采样保证热门物品和长尾物品的样本比例合理不要让热门物品主导训练。第三是线上服务的一致性。离线训练用的是完整的序列线上推理时序列可能被截断因为延迟限制。如果截断策略和训练时不一致效果会打折扣。我的经验是训练时就模拟线上截断让模型适应截断后的序列这样线上线下一致性更好。5.4 独家避坑技巧汇总序列长度不要一步到位先从 256 开始效果稳定后再加到 512、1024。一步到位容易遇到显存和延迟问题排查起来很痛苦。KV Cache 要设上限不设上限的话高并发时显存会爆。设一个合理的上限比如 80% 显存超过就淘汰最久未使用的 Cache。召回和排序的 loss 权重用网格搜索不要拍脑袋定用一个小规模实验跑一遍网格找到最优比例再放大。线上灰度至少观察 24 小时统一模型的延迟特性在不同时段差异很大短时间灰度可能发现不了问题。保留两段式的降级链路统一模型出问题的时候能快速切回两段式保证业务不中断。6. 我对这套架构的真实看法OneTrans-V2 这套东西方向是对的但落地门槛不低。它适合的是已经有成熟推荐系统、有足够工程资源、并且被召回排序不一致问题困扰的团队。如果你还在从零搭建推荐系统我建议先把两段式跑通把特征、样本、训练、 serving 这套基础设施搭稳再考虑统一建模。因为统一模型对基础设施的要求更高基础设施不牢统一模型只会让你更痛苦。从技术演进的角度看召回和排序的统一是必然趋势。生成式检索、大模型推荐这些方向本质上都在做同一件事用更强的模型能力替代人工设计的链路拆分。OneTrans-V2 是这个趋势里一个比较扎实的工程实践它没有追求花哨的算法创新而是把工程细节啃透了。这种“把一件事做到极致”的思路比追热点更值得学习。最后分享一个我在实际项目中体会很深的点统一模型的效果很大程度上取决于序列构造的质量。同样的模型结构序列构造差一点效果可能差 10%。所以如果你要上手 OneTrans-V2我建议把 60% 的精力花在序列构造和特征工程上模型结构反而不是最关键的。这个经验是我踩了无数坑之后才悟出来的。

OneTrans-V2：统一召回与排序的生成式检索架构落地实践

相关推荐

Python根据输入参数计算结果的实例方法

BlueField-4 STX：AI存储加速器的架构革新与应用

无人驾驶自动泊车技术：多项式规划与单步系统优化

更多资讯

WPF三种启动方式 + 静态资源 + 数据绑定满分知识点整理

系统规划与管理师-第七章-第八章-考点记忆

系统规划与管理师-第九章-考点记忆

Python中apply与map的区别

编程基础学习

SSM医院住院系统实战：从毕设到业务闭环的全链路解析

今日更新

AI智能体开发实战：从技术原理到商业落地

OpenShell 完全定制指南：从安装到深度配置，打造高效 Windows 开始菜单

Superpowers技能体系全解析：从Skills引入到安装的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？