PRECTR-V2 深度解读

论文: PRECTR-V2: Unified Relevance-CTR Framework with Cross-User Preference Mining, Exposure Bias Correction, and LLM-Distilled Encoder Optimization
来源: 阿里巴巴闲鱼搜索团队 | arxiv: 2602.20676

1. 问题与动机

PRECTR-V2 是对前作 PRECTR（统一搜索相关性与 CTR 预估框架）的迭代升级，针对其在大规模工业部署中暴露的三个关键缺陷：

冷启动个性化失效：PRECTR 依赖用户自身的历史行为序列来建模"相关性偏好"（即用户对搜索结果相关性的敏感程度）。但在闲鱼这样的 C2C 平台上，大量低活用户缺乏足够的行为数据，导致个性化相关性激励分 τ(x) 退化为全局均值，失去区分能力。

曝光偏差严重：训练数据中 80%以上的样本是高相关性 item（rsl=4），因为排序系统本身就倾向于曝光相关性高的结果。这导致模型在训练时几乎看不到低相关性样本，而推理时需要对大量低相关性候选做评估——训练与推理的分布严重不匹配。

编码器无法联合优化：原始 PRECTR 使用冻结的 BERT（110M 参数）提取文本 embedding，再接 MLP 做 CTR 预测。冻结 BERT 的原因是线上延迟要求，但这阻止了文本表征与 CTR 目标的端到端联合优化，限制了模型上限。

这三个问题在搜索排序系统中极为普遍——冷启动、曝光偏差、语义理解与行为预估脱节——是搜索/推荐领域的核心痛点，解决它们具有很强的实际意义。

2. 方法概述

PRECTR-V2 在 PRECTR 的统一框架（将点击概率分解为 P(click|x) = Σ P(click|rsl=i, x)·P(rsl=i|x)）基础上，新增三个模块：

整体思路是：在不破坏统一相关性-CTR 框架的前提下，逐个击破工业落地中的关键瓶颈。

3. 核心技术贡献

3.1 跨用户相关性偏好挖掘

这是本文最有新意的模块。核心洞察是：同一 query 类目下的用户群体对相关性的偏好模式是可迁移的。

具体做法：

• 对低活用户，在同 query 类目下采样 50 个相似用户
• 按 query 文本相似度筛选 top-k 行为
• 合并序列 S = {S_u, S_q}（用户自身 + 跨用户采样）
• 用 Multi-Head Target Attention 分别生成 user-level 和 category-level 的偏好表征
• 最终通过 MoE（两个专家网络 + 不同激活函数） 融合输出相关性激励分 τ

与常见的 user-CF 补全不同，这里迁移的不是 item 偏好而是相关性敏感度偏好——某些用户更在意相关性（只点高相关结果），某些用户更宽容。这个视角比较独特。

3.2 曝光偏差校正

构造困难负样本的方式很巧妙：

1. 取 click=1 且 rsl=4 的正样本
2. 将 rsl 降级（按概率 p1/p2 分配到 1/2/3）
3. 对 item 文本 embedding 注入高斯噪声：Q_emb^fake = Q_emb + ε, ε ~ N(0,1)
4. 用 pairwise ranking loss 约束 f(x⁺) > f(x⁻)

关键创新在于两个校准机制，防止 ranking loss 破坏绝对预估校准（PCOC）：

• Relative order critical distance penalty：对正负样本分数差设 margin 上限，避免过度拉开
• Dynamic truncation weighting：当 batch 平均分数超过阈值时将 loss 权重截断为 0

这两个设计在工业实践中很关键——纯 pairwise loss 会破坏 pCTR 的绝对值语义，而搜索/推荐系统的竞价、流控等模块都依赖 pCTR 的校准性。

3.3 LLM 蒸馏轻量编码器

用 2M 参数的 3 层 Transformer 替代 110M 的 BERT，训练分三步：

1. Relevance SFT：在相关性标注数据上做分类微调
2. LLM Embedding 蒸馏：以 Qwen-7B（RAG 增强）为教师，MSE 损失蒸馏
3. 端到端联合微调：以较小学习率与 CTR 主模型联合训练

参数量缩减 55 倍（110M → 2M），满足线上延迟要求的同时实现了端到端优化。

4. 实验结果分析

离线实验

在闲鱼 16 亿日曝光数据 上的实验结果：

• 相比 PRECTR 提升 AUC +0.0093、GAUC +0.0041，在十亿级数据上这是非常显著的提升

消融实验

• LLM 蒸馏编码器贡献最大（+3.13%），说明端到端联合优化的重要性
• 三个模块有正向叠加效应（3.60% > max(1.08%, 2.98%, 3.13%)）

在线 A/B 实验

• 20%+ 流量对照
• 人均订单量 +1.39%
• GMV +3.18%
• PCOC 偏差从 2.3% 降至 1.7%（校准性更好）
• 高相关性 badcase 率仅微升 0.15%（绝对值），可忽略
• 已全量部署上线

5. 局限与未来方向

现有局限

1. 跨用户采样的在线开销：采样 50 个相似用户并计算 query 文本相似度，在线 serving 时的延迟和存储开销未详细讨论。在流量高峰时这可能成为瓶颈。

1. 噪声注入的粗糙性：用标准高斯噪声破坏 embedding 来模拟"低相关性"，这种构造方式较为粗糙。真实的低相关性样本有其自身的语义模式（如 query="手机壳"但展示了"手机膜"），简单加噪声可能无法准确模拟。

1. 蒸馏教师的局限：Qwen-7B 作为教师模型，其语义理解能力在电商垂直领域可能不够精确，尤其是对闲鱼这类非标品平台。

1. 相关性 badcase 微升：虽然论文称 0.15% 的绝对增幅可忽略，但在搜索场景中相关性是底线，长期积累可能影响用户体验。

1. 单平台验证：仅在闲鱼（C2C 二手电商）上验证，泛化性到 B2C、内容搜索等场景未知。

未来方向

• 动态负样本生成：用生成模型（如 LLM）构造更真实的困难负样本，而非简单噪声注入
• 多粒度蒸馏：不仅蒸馏 embedding，还可蒸馏 attention pattern 和中间层表征
• 在线学习适配：跨用户偏好挖掘模块可结合在线学习，实时更新相似用户图谱
• 多目标扩展：从 relevance-CTR 二元统一扩展到 relevance-CTR-CVR-satisfaction 多目标统一

6. 工业实践意义

对搜索系统

统一建模范式的验证：PRECTR 系列持续证明 relevance 和 CTR 不应割裂优化。工业搜索系统中常见的"先相关性过滤、再 CTR 排序"的级联架构，可以考虑向统一框架迁移。核心公式 P(click) = Σ P(click|rsl=i)·P(rsl=i) 提供了一个干净的分解视角。

对推荐系统

冷启动偏好迁移的思路：跨用户偏好挖掘不局限于搜索场景。推荐系统中的新用户冷启动同样可以从"类目/场景相似用户"中迁移偏好模式，且迁移的维度可以从"相关性偏好"扩展到"多样性偏好""价格敏感度"等。

对广告系统

曝光偏差校正 + 校准保持的双重设计：广告系统对 pCTR 校准性的要求极高（直接影响出价和收入），本文的 margin + dynamic truncation 机制是 pairwise 学习与校准保持的一个很好的平衡方案，值得广告排序借鉴。

对 LLM 落地

大模型蒸馏到端上的务实路线：110M → 2M 的压缩比（55x）且保持甚至提升效果，给出了一条"LLM 预训练语义 → 轻量模型蒸馏 → 端到端联合训练"的工业化路径。这比直接在线上部署大模型做推理要务实得多，是当前 LLM 赋能搜推广的主流思路之一。

关键 takeaway

搜索排序的核心矛盾不是"要相关性还是要 CTR"，而是如何在统一框架中让两者协同增强。PRECTR-V2 给出的答案是：补齐偏好信号（冷启动）、校正数据偏差（曝光偏差）、打通表征学习（LLM蒸馏），三管齐下。

HiSAC 深度解读

1. 问题与动机

HiSAC 解决的是工业推荐里非常具体的问题：高活跃用户的历史行为可以超过 1 万次交互，但直接把全量序列送进 attention ranker 会让在线延迟和显存成本失控。论文指出，多头注意力在长序列上的计算复杂度随历史长度急剧上升，生产系统难以承受；同时，大量无关或噪声行为会稀释注意力权重，导致模型不能有效捕捉真正有用的长期偏好。

已有长序列压缩方法主要有两类。第一类用固定数量的全局兴趣中心，例如 ELASTIC、PolyEncoder 风格的 learnable prototype；问题是每个用户的兴趣数量和粒度不同，固定 prototype 容易把个性化偏好压成平均模板。第二类使用 K-Means、LSH 或时间分片做 hard assignment；问题是时间相近不等于语义相近，哈希/聚类也会把语义相近但 code 不完全匹配的长尾行为丢掉。论文把这种损失称为 quantization error，并强调它对稀疏长尾兴趣尤其致命。

HiSAC 的动机因此很清晰：需要一种在线可服务的压缩表示，既能用完整历史，又能按用户自适应地选择兴趣中心，还要避免硬分配带来的长尾偏好损失。它把多模态语义离散化、层次投票、soft routing attention 组合起来，在淘宝首页“猜你喜欢”场景中验证。

2. 方法详解

HiSAC 的输入是用户按时间排序的历史行为序列，长度可以超过 10,000。目标不是选一个候选相关的子序列，而是构造若干 interest-level summaries，每个 summary 表示用户某个兴趣簇。整体流程有三步：行为 tokenization、hierarchical voting、soft-routing attention。

第一步是多模态语义 tokenization。每个 item 收集标题、类目等文本元数据和商品图像，用冻结的 CLIP ViT-B/32 加 Q-Former 融合成多模态 embedding。这个 embedding 不参与推荐任务端到端训练，目的是保留相对去偏的内容语义，减少曝光频率和交互数据对路由空间的扭曲。随后用 RQ-VAE 做多级残差量化：第一级量化原始 embedding，后续级别量化残差，得到一个多层 semantic identifier，也就是穿过层级 codebook 的路径。RQ-VAE 用重构损失和 commitment loss 训练，codebook 使用 EMA 更新，decay 为 0.99。

第二步是层次投票。所有 item 的 SID 构成全局层级语义树，root 到 leaf 的路径对应完整 SID。对某个用户，把历史 item 投影到 leaf 节点，先自底向上传播 vote count，再自顶向下按每层预算保留 top-k 子节点。保留下来的 leaf 节点就是该用户的 personalized interest-agents，数量由每层预算控制。这个设计比固定全局兴趣中心更灵活：兴趣集中用户会激活少量强节点，兴趣分散用户会保留更多语义分支。

第三步是 Soft-Routing Attention。hard routing 只把行为分给完全匹配的 interest-agent，容易丢掉 SID 不匹配但语义相近的长尾 item。HiSAC 为此解耦两个 embedding 空间：semantic embedding 来自冻结多模态编码器与 RQ-VAE，只用于计算 item 与 agent 的相似度；ranking embedding 则由 CTR 目标端到端训练，包含交互驱动信号和类目、品牌、时间衰减等特征，用作被聚合的 value。每个 agent 先通过其 SID codeword 重构语义 prototype，再对全历史 item 计算负距离 softmax 权重，并乘以 agent 本身的兴趣强度，最终得到压缩序列。生产部署中，HiSAC 做离线 agent 构建、request-level compression 和 cache-enhanced MHA：用户序列每个请求压缩一次，候选 query 离线预计算并每 2 小时刷新，user key/value 每请求复用。

3. 核心技术贡献

第一，HiSAC 将“长序列压缩”从固定 prototype 转成用户自适应的层级兴趣激活。全局语义树提供共享索引，但每个用户通过投票选择自己的 interest-agents，解决了不同用户兴趣数量和粒度不同的问题。

第二，论文把语义路由空间和排序聚合空间彻底解耦。很多推荐模型把 item embedding 同时用于相似度分组和 CTR 排序，结果 popularity bias 会污染路由；HiSAC 用冻结语义 embedding 决定“应该归到哪个兴趣附近”，用训练 embedding 决定“这个行为对排序有什么价值”，两者分工明确。

第三，soft routing 不是简单平滑，而是为长尾兴趣保留梯度和信息。论文的案例中，一个“棉袜”行为没有精确匹配的 agent，hard routing 会丢弃或错分；soft routing 可以把它分配给语义相近的“鞋类/足部穿戴”agent。线上结果显示，top 10% 之外长尾 item 的 CTR 提升 12.6%，说明这个机制确实改善了头部曝光挤压。

第四，论文提供了可部署优化。离线构建 agent、按请求压缩、缓存候选 Q 和用户 K/V，使得模型不是停留在离线 AUC 论文，而是在 10k 历史、2,000 候选的淘宝首页在线链路中满足服务约束。

4. 实验结果分析

论文使用三个数据集：淘宝工业数据、Taobao-MM、KuaiRec。工业数据包含 14 天日志、2 亿用户、10 亿 item、300 亿交互，最大序列长度截到 10,000；前 13 天训练，最后 1 天验证。Taobao-MM 有 879 万用户、3540 万 item，最大序列 1,000；KuaiRec 有 7,176 用户、10,728 item。离线指标是 AUC 与 GAUC，线上指标包括 IPV、CTR、CTCVR 和订单。

主要离线结果显示，HiSAC 在工业数据不同长度上稳定领先。以 10k 序列为例：

把 HiSAC 接入已有长序列模型也有效。例如 HiSAC + ELASTIC 在 10k 工业数据上达到 AUC 0.6449、GAUC 0.5531；HiSAC + Longer 达到 AUC 0.6455、GAUC 0.5537。这说明它不是只能搭配单一 ranker，而是可以替换多种模型内部的压缩模块。

消融实验更关键。去掉多模态编码器，AUC 从 0.6444 降到 0.6424，下降 0.20 个百分点；只去掉文本或图像分别降到 0.6429 和 0.6431，说明文本语义在电商场景中更重要。用 RQ-KMeans 替代 RQ-VAE，AUC 降到 0.6438；论文还报告 RQ-VAE 的 Silhouette Coefficient 为 0.42、重构误差 0.018，而 RQ-KMeans 分别是 0.28 和 0.027。压缩机制方面，去掉 soft routing 改成 hard routing，AUC 降到 0.6429；去掉长尾兴趣保留是 0.6438；去掉层级投票 AUC 几乎不降但 agent 数量增加 3 倍，在线成本不可接受。最强的反例是把 semantic 和 ranking embedding 合并，AUC 直接掉到 0.6253、GAUC 0.5392，证明解耦空间是核心。

线上两周 A/B 测试结果也很完整：HiSAC 在淘宝“猜你喜欢”首页相对最强生产压缩基线带来 IPV +1.93%、CTR +1.65%、CTCVR +2.24%、订单 +2.56%。生产优化后，论文称端到端推理延迟降低超过 40%；缓存增强 MHA 中，Q/K/V projection 占超过 70% serving FLOPs，预计算候选 Q、复用用户 K/V 后 projection FLOPs 降低 72%，cache hit rate 99%。

5. 局限与未来方向

论文没有显式 limitations 章节，但从实验设置可以看到一些限制。第一，最强证据来自淘宝电商首页，item 具有丰富文本、图片、类目、品牌等多模态信息；在纯短文本 UGC 或稀疏元数据平台，RQ-VAE 语义树质量可能下降。第二，HiSAC 依赖每日离线 item SID 分配与用户 agent 构建，新内容极速增长或实时兴趣突变场景需要补充增量更新策略。

第三，虽然 soft routing 减少长尾损失，但它仍以冻结多模态语义距离作为路由基础。如果文本/图片 embedding 无法表达社区语境、梗、时效话题或地域语言，长尾兴趣可能被路由到错误 agent。第四，论文的部分数学符号在 HTML 中缺失，学习率等训练超参也没有完整披露，外部复现会依赖作者代码或内部工程细节。

未来方向上，可以研究实时 agent 更新，而不是每日离线更新；可以引入搜索 query、评论文本、社交关系等 UGC 特有信号来增强 semantic tree；也可以把 soft routing 的温度和层级预算做成用户自适应，而不是固定全局超参。对于搜索推荐统一系统，还可以尝试让 query、item、作者、topic 进入同一层级语义树，用同一套压缩表示服务召回和排序。

6. 工业实践意义

HiSAC 对工业推荐团队的最大价值是给“全量长历史建模”提供了可落地方案。很多平台为了时延只截断最近 N 条行为，或者按候选检索一小段相关历史，这会损失长期兴趣和长尾偏好。HiSAC 表明，可以先离线把完整历史压成个性化 interest-agents，再在线让候选和压缩后的兴趣摘要交互，从而兼顾历史覆盖和服务成本。

对社区 UGC 场景，方法可这样迁移：把帖子标题、正文摘要、图片/视频封面、作者、话题标签编码为多模态 embedding；用 RQ-VAE 构建层级语义树；按用户历史浏览、点击、收藏、评论、关注做层级投票，形成用户兴趣 agents；排序时用 soft routing 聚合完整历史，而不是只看最近点击。对于短文本搜索，用户近期 query 与长期内容消费也可以共同投票，形成 query-aware interest-agents。

落地时有几个工程注意点。首先，路由 embedding 要尽量去偏，不能直接用 CTR embedding，否则热门内容会统治语义树。其次，agent 构建要有增量机制，新帖子、新作者、新话题需要快速进入 codebook 或临时节点。第三，线上监控不能只看 CTR，还要看长尾曝光、类目多样性、冷启动内容点击和 per-user latency。论文里长尾 item CTR +12.6%、每用户 distinct categories +5.7% 是很好的监控模板。

总体来说，HiSAC 不是单纯提高一点 AUC 的压缩技巧，而是一个“语义离散索引 + 个性化兴趣压缩 + 在线高效交互”的系统设计。对于需要在千万到亿级用户上保留长期行为的推荐系统，它比固定兴趣中心、时间分片和候选相关截断更稳健，也更容易解释每个兴趣 agent 对应的语义分支。

Towards Generalizable and Efficient Large-Scale Generative Recommenders 深度解读

1. 问题与动机

论文来自 Netflix 的标题推荐（title recommendation）生产实践，核心问题是：把生成式推荐主干从 2M 扩到 1B 参数，预训练阶段的收益不会自动传导到下游应用。作者把"生产迁移"拆成多个互相牵制的因素：任务自身的提升空间（task headroom）、重复训练成本、serving 延迟、item 时效性。

量化证据很硬：系统每个刷新周期要在 2 万亿（2 trillion）行为 token 上训练，频繁重训使效率成为硬约束；缓存式 serving 带来 staleness——训练标签里的 item 在 serving 时可能已被消费；新标题缺乏可靠的协同 embedding。最关键的观察是"serving 延迟敏感性因任务而异"：Task B 在 24 小时 serving 延迟下 MRR 掉 31%、48 小时掉 41%，而 Task A 几乎不受影响（≤4%），Task C 居中（48h 掉 18%）。这说明"该不该堆模型"不能一刀切，必须按任务诊断。

2. 方法详解

主干架构：基于 HSTU（hierarchical sequential transducer）的 Transformer 生成式推荐器，把用户行为编码成 token 序列，每个 event 把 action、context、metadata 压进单个 token。参数 scaling 区间 2M→1B（不含 embedding 与 decoding 层），embedding 维度 4096。

四个效率配方是落地关键：

1. Sampled softmax：仅用 1% 均匀采样负样本，且不做 LogQ 校正（刻意保持训练 recipe 简单）。
2. Projected decoding head：把维度从 d 投到 d/8（4096→512），在 10^6 词表规模下输出层 FLOPs 降 35.5×，10^7 item 规模下约降 249×——这是让"十亿模型反复重训"在工程上可行的核心。
3. Semantic item towers：用知识图谱 embedding、LLM2Vec 语言表征、人工标注特征，给协同信号弱的 item 兜底。
4. Collaborative-embedding masking：训练时按"线上冷启动率"随机替换 item embedding，让模型学会在没有协同 ID 时也能打分。

训练流程用"small-to-large 漏斗"：先在小主干上验证改动，再上十亿参数，避免直接在 1B 上试错的高成本。

3. 核心技术贡献

贡献一：offset scaling-law 拟合作为诊断工具。 不同于传统 log-linear 拟合 P=a·log(N)+b，作者对每个任务拟合带偏移的形式 P(N)=P₀−(N/N₀)^(−a)，其中 P₀ 是任务相关的饱和上限。在 Table 2 上 offset 形式全面胜出：Task A 的 RMSE 降 48.4%、Task B 降 61.8%、Task C 降 14.9%。诊断结论很直接——Task A P₀=0.311 已接近经验上限，Task C P₀≈1.075（基本被 1.0 截断）几乎饱和。这把"还要不要继续堆容量"变成可量化的决策，并区分"下一步该加容量、还是改目标、还是改 item 表征"。

贡献二：Multi-Token Prediction (MTP) 的 serving-horizon 依赖性。 论文揭示 MTP 不是无脑收益：在 48 小时缓存式 serving 下用优化窗口能涨 MRR，但在 <1s p95 的在线路径上，窗口变大反而伤害顺序敏感的任务。

贡献三：语义塔 + OOV embedding 处理冷启动。 把语义证据与协同信号解耦，使新标题在没有协同 ID 时仍可打分。

4. 实验结果分析

MTP 结果（Figure 5）：48h 缓存 serving + 优化窗口下，Task A +22.1%、Task B +27.8%、Task C +27.9% 相对 MRR；但在线 serving（<1s p95）下，MTP 让 Task A +19.6%，却随窗口增大损害 Task B/C——印证 MTP 的收益强依赖 serving 时序与是否顺序敏感。

Production-shadow 评测（Figure 7）：1M 用户 × 1 周影子流量，1B vs 2M 主干：Task A +22.5%、Task B +11.3%、Task C +7.4% MRR，冷启动标题（词表未见）+28.1%。两个对照很说明问题：冷启动收益最大，印证语义塔设计有效；Task C 收益最小，印证 scaling-law 预测的天花板。最终在多个生产 A/B 中取得正向结果。

消融/趋势：MRR 为主指标，作者称 Hit Rate、NDCG 趋势一致但未详列。

5. 局限与未来方向

作者明确指出：（1）分析只用三个粗粒度任务类别，回避了实现细节；（2）offset law 拟合要求指标有界，对无界目标适用性未知；（3）sampled softmax 省掉 LogQ 校正是为简化，可能引入偏差；（4）production-shadow 衡量的是下游集成质量，不是单面的因果增益；（5）冷启动 masking 概率"对齐线上冷启动率"，但具体数值未披露。

6. 工业实践意义

对要落地生成式推荐/搜索的团队，这篇是难得的生产真账：

• 别只看离线 loss：模型 scale 只是迁移问题的一个分量，必须和 task headroom、解码成本、serving-延迟对齐、item 泛化一起评估。用 offset scaling-law 拟合判断"哪些任务已到顶、哪些还能扛容量"，按任务分配算力。
• 解码层是大模型反复重训的成本瓶颈：projected head（4096→512，FLOPs 降 35.5×~249×）+ 1% sampled softmax 是让十亿模型可运维的关键，对算力受限团队尤有参考。
• MTP 要按 serving horizon 选用：缓存/可乱序场景受益，顺序敏感的在线路径慎用。
• 冷启动靠语义塔兜底：UGC/新内容密集的社区场景，知识图谱+语言表征+OOV embedding 的组合能在协同信号缺失时维持打分质量（此处冷启动 +28.1% 是最大亮点）。

• 时效性是被低估的隐形成本：Task B 在 48h serving 延迟下掉 41% MRR，说明对时效敏感的任务，缩短训练-serving 链路（更频繁刷新、更短缓存窗口）的收益可能大于堆模型容量；应把"serving 延迟敏感性"做成上线前标准画像，避免在已饱和或时效主导的任务上浪费算力。

部署考量：十亿主干的可运维性来自两点——projected head 把输出层从 4096 维压到 512 维，使大词表（10^7 item）下解码 FLOPs 降约 249×；small-to-large 漏斗把昂贵的 1B 验证前置到小模型上筛掉无效改动。这套组合让"在 2 万亿 token 上反复重训十亿模型"从纸面变成可落地流程，是想复刻 HSTU/生成式推荐 scaling 的团队绕不开的工程账。内存与延迟方面，sampled softmax（1% 负样本、省去 LogQ 校正）进一步压低训练开销，但代价是采样偏差未被显式纠正，落地时需自行评估对长尾排序的影响。