UniPinRec:Pinterest 规模下统一生成式召回与排序
1. 问题与动机
现代推荐系统普遍把召回(retrieval)与排序(ranking)训练成两套独立模型,尽管二者越来越依赖在相同用户行为数据上训练的大 Transformer。作者指出这种重复是低效的主要来源:参数、训练算力、在线服务成本三重重复。两阶段的算力画像本不同——召回需在毫秒级延迟下用 ANN 点积对百万级候选打分,排序只需对数百个候选打分、可承受 cross-attention 的更重逐候选计算。先前工作(如 HSTU)只统一了模型架构,但「输入格式、训练流程、服务栈在各阶段仍然割裂」。UniPinRec 的目标是做全栈统一:一种输入格式、一个模型、一个训练阶段,且部署在 Pinterest 现有服务栈内。这一动机对社区搜推同样切中要害——多阶段级联各自维护一套大模型,存储与一致性成本高、迭代慢。
2. 方法详解
共享主干:一个 causal decoder-only Transformer 处理用户行为序列。每个 item 用预训练 embedding(Omnisage + CLIP 多模态)表示,经 MLP 投影并做 L2 归一化。
Masked Action Modeling(MAM)是核心创新。传统做法把 action token 与 item token 交错(interleave),会使上下文长度翻倍;MAM 改为把 action 的 multi-hot 经线性层编码成 dense embedding,沿特征维与 item 表示拼接,再做随机掩码:
- 历史位置:每个 action 以概率 p_mask 独立掩码;
- 候选(未来)位置:action 一律掩码(m_j=0);
- 被掩位置用 [MASK] token 替换,以区分「action 未知」与「无 action 发生」。
注意力沿用 M-FALCON 模式的改良 causal mask:历史位置保持标准 causal 注意力;每个候选位置可注意全部历史、但互相不可见,从而把注意力代价从 O((n+k)²) 降到 O(n²+nk),并用 flex attention 的 CUDA kernel 实现。
双任务联合损失:召回用 next-item prediction(在每个未掩历史位置,对 in-batch + 随机负样本做带频率校正的 sampled-softmax,ℒ_item);排序用 per-action-type 的 MLP head 输出标量 logit 做 BCE(ℒ_action,按 action 类型加权 w_c)。总损失 ℒ = ℒ_item + ℒ_action。排序 head 直接从召回 checkpoint 初始化,实现完全权重共享。
训练设置:以 feedview 为中心构造样本,每条样本同时含用户互动历史(供召回)与完整曝光 slate 含负反馈(供排序);对未互动 feedview 下采样保留 10% 以放大稀有互动类。用户行为序列与 feedview 分别存为按 user ID hash-bucket 的 Iceberg 表,训练时经 Ray 分布式 dataloader 在内存中 join,避免数据冗余。采用 FP8 混合精度(前向 E4M3、反向 E5M2)+ Transformer Engine 融合算子;benchmark 环境 NVIDIA L40S(B=8, n=992, k=656, L=12 层)。
3. 核心技术贡献
- MAM:用特征维拼接 + 随机掩码替代 token 交错,在不膨胀上下文长度、不破坏因果性的前提下实现召回/排序权重共享,且掩码本身起去噪正则作用——当 action 不可得时泛化更好。消融显示 p_mask=0.2 时 Hit@3 最优(0.10096),优于不掩码(0.09923)。
- Blended Training:把 action 序列与 feedview 曝光 slate 配对(用「过去」行为序列配「未来」请求的 feedview),让单条样本同时满足两个目标。
- Cross-Stage KV-Cache Sharing:召回阶段缓存 O(n²) 的历史计算,排序阶段以 O(nk) 的边际成本复用。通过预分配 GPU 内存池并经 CUDA IPC handle 映射进召回与排序两个进程地址空间,避免 GPU→host→GPU 往返。
4. 实验结果分析
离线(Table 1):UniPinRec 召回 Recall@10=0.77659,相对生产基线 PinRec(0.77486)约 +0.2%(持平略升);排序 Hit@3=0.10096,相对生产排序器 TransActV2+DCNv2(0.088008)超出约 14.7–14.8%;在相同上下文长度下优于 HSTU。
服务性能(Table 2/3):前向延迟拆解——KV-cache 复用约 2.4× 加速、FP8+CUDA graph 约 1.25×、flex attention 约 1.3×,组合最高 3.92× 端到端加速;相比朴素分离部署,在线 E2E 延迟 -11.1%、QPS +63.6%。
在线 A/B(RQ3):Board More Ideas surface save +0.95%、site-wide +0.08%;Notifications push opens +0.91%(沉睡用户 +1.72%,约 2 倍)、notification surface saves +3.84%、email clicks +0.30%、WAU +0.09%。
消融/Scaling:MAM 掩码比 p_mask=0.2 最佳、0.3 收益递减;深度 2→24 层线性算力换持续质量提升;序列长 256→2048 仍在改善,暗示序列压缩是有前景的方向。注意 FP8 量化代价为离线指标 -0.5%。
5. 局限与未来方向
作者明确:(1) 目前不替代 L2 精排——精排在分数校准、训练数据日志、运维工具上有额外基础设施依赖,超出本文范围;(2) 采用渐进灰度(UniPinRec 作为 L0+L1 召回+轻排,结果再送下游生产精排 TransAct V2),有意衰减离线增益以验证增量收益,因此尚未做全链路替换;(3) 未横向扩展到 Search/Ads 场景;(4) FP8 带来 0.5% 离线指标下降。
6. 工业实践意义
对搜推工程团队的可借鉴点:召回与排序可共享同一 Transformer 底座,用「候选无关的共享编码 + 任务专属 head」消除双模型的参数/算力/服务三重重复——QPS +63.6%、延迟 -11.1% 是实打实的成本收益。MAM 的特征维拼接掩码是规避 token 交错导致上下文翻倍的关键技巧,值得在自研生成式序列模型中尝试;其掩码去噪还顺带提升泛化。Cross-Stage KV-Cache 跨进程共享(CUDA IPC 映射同一 GPU 物理内存)是把「召回历史计算复用给排序」落到工程的关键,对延迟敏感的在线系统极具参考价值。部署上采用渐进灰度(先做召回+轻排、保留下游精排)也是稳妥的上线路径,降低一次性全链路替换风险。需注意:完整替代精排仍受分数校准、数据日志、运维工具等基建依赖制约,社区搜推若要复用需先补齐这些环节。