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 物理内存）是把「召回历史计算复用给排序」落到工程的关键，对延迟敏感的在线系统极具参考价值。部署上采用渐进灰度（先做召回+轻排、保留下游精排）也是稳妥的上线路径，降低一次性全链路替换风险。需注意：完整替代精排仍受分数校准、数据日志、运维工具等基建依赖制约，社区搜推若要复用需先补齐这些环节。