1. 问题与动机

推送推荐和信息流推荐的关键差别在于：推送是平台主动把内容送到用户面前，用户甚至不需要先打开应用，因此一次错误推送更容易直接造成打扰和负反馈。论文面向快手的推送场景，服务规模接近十亿用户，线上吞吐约 100K QPS。传统级联流程可以依赖候选召回与打分，但对用户长期行为、短期意图和内容语义的联合建模仍然受限于上下文长度。简单截断或随机采样会把有效历史丢掉；生成式推荐虽然能用语义 ID 把推荐改成序列生成，却存在两个落地障碍：一是语义 ID 对模型是黑盒，业务方难以审计“为什么推这个视频”；二是 OneRec-Thinking 这类在 ID 生成前加入思维链的方法会增加解码步数，不适合推送服务的吞吐与时延约束。

作者把问题拆成三个工程目标：先把更长的行为历史压缩进有限上下文；再让生成模型能生成推荐结果并给出可读的解释；最后把生成模型捕捉到的偏好信号接回成熟的 ANN 召回链，而不是把全套服务同步改造成一个大语言模型。论文正文明确把长尾曝光和冷启动也作为长期目标，因为只依赖历史热度的系统会不断强化头部视频。

2. 方法详解

PushDualGen 由“语义 ID 上下文压缩—个性化 SID 与 copy 生成—在线表示融合”三段组成。第一段采用并行语义 ID，不再像残差量化那样让第 l 层依赖前一层的残差，而是为同一个视频学习 M 个并行表示，再为每个槽位建立大小为 K 的 K-means 码本。每个槽位独立寻找最近的质心，最终得到由 M 个离散 token 组成的 SID。实际配置是 M=8、K=512，所以一个视频由 8 个离散码表示。将长行为序列中的视频替换为 SID 后，历史被压成短的离散序列，同时尽量保留内容的语义结构。

SID 原本不在语言模型词表中，作者因此设计 Text-to-SID 和 SID-to-Text 两个对齐任务。前者从推送文案和视频描述预测 SID，后者从 SID 还原文案和描述，让模型同时学会“压缩进去”和“从压缩表示理解出来”。训练时把全部码本索引登记为特殊 token，冻结原有词表 embedding，只优化新 SID token 的 embedding，避免随机新增词扰动 Qwen3-0.6B 原来的语言能力。两项任务使用 next-token prediction，分别可以写成对 SID 序列和文本序列的交叉熵。

第二段接收用户画像、时间新鲜度标记、历史交互和任务指令，先生成下一视频的 SID，再在特殊分隔符后生成可跳过的 copy 文本。损失是 SID 生成损失与 copy 生成损失的加权和：L_gen=L_SID+λ_copy L_Copy。copy 不是同步链路必须消费的解释，而是一个能够单独关闭的解释头，因而主路径不需要额外的思维链。为减少输入长度，作者还把频繁出现的 2、3、4-gram 以及语义上不可拆的 SID 合并为单 token，新 token 用组成 token 的均值初始化。

第三段把生成偏好接回线上检索。系统分别用三个 encoder 把用户特征、候选视频特征和 Top-N 个生成 SID 映射到同一维度。实践中 N=20，用户原始向量 e_u 与 SID 向量 e_s 按 e'_u=αe_u+βe_s 融合，线上 α、β 都设为 1，再用融合后的用户向量对视频库做 ANN 搜索。这样，LLM 负责从长历史中抽取偏好，成熟的向量索引负责吞吐和候选服务。

训练数据分成两部分。语义 ID 压缩使用超过 400 万个视频，最终约 0.72B token；个性化 SID 与 copy 生成使用推送点击日志，每天约 3.6B token 做增量训练。作者使用 Qwen2.5-Omni-3B 训练视频到并行表示的压缩组件，使用 Qwen3-0.6B 做 SID 适配和生成。两段学习率分别为 1e-5 和 1e-7，训练轮数为 3 和 1。

3. 核心技术贡献

第一，论文把并行量化的语义 ID 放在长历史压缩环节，避免残差 ID 的误差逐层累积；这让每个 SID 槽位可以独立表达一部分内容语义，也使历史压缩更容易并行化。第二，SID 与 copy 的顺序设计把可解释性和效率拆开：先生成离散推荐目标，只有需要解释或调试时才生成文本，不把解释推理强行放进每次在线请求。

第三，SID 不是孤立的离线生成结果，而是通过 Top-20 SID 与实时用户特征融合进入 ANN 召回，保留了现有服务的可扩展性。第四，实验显示 SID 适配是最关键的训练阶段：没有 SID Adaptation 时，Pass@1/4/20 只有 0.319/0.352/0.366，而完整模型为 0.335/0.391/0.422；说明预训练语言模型不能自然理解新加入的离散 ID，必须先用双向对齐任务建立语义接口。

4. 实验结果分析

线上实验是论文最有价值的部分。作者从平台流量中划出 15%，覆盖约 150M 用户，做 14 天 A/B，并用 CUPED 缓解哈希分桶带来的实验前不平衡。对照为原有级联服务，处理组为 PushDualGen。结果如下：

四项线上变化均达到统计显著，尤其有效播放率和不喜欢率同时改善，说明模型不是单纯增加曝光或点击，而是让点击后的内容更符合用户预期。消融中的 Pass@1/4/20 也提供了机制层证据：完整模型为 0.335/0.391/0.422，去掉并行 SID 后为 0.326/0.379/0.401，去掉 token freeze 后为 0.333/0.386/0.412，去掉 multi-token binding 后为 0.332/0.384/0.416。相比之下，去掉 SID 适配的损失最大，说明“让模型认识 SID”比微调 token 初始化和合并输入更基础。

还有一个重要的负面结果：token freeze 与 multi-token binding 带来的 Pass@k 增益相对小，不能把它们解释成主要质量来源。它们更多是训练稳定性和输入效率组件。作者还把 39 个内容类别按曝光占比分成头部、腰部和长尾，观察到生成 SID 的结果带来更长尾的曝光，并在冷启动场景表现出更好的泛化；不过长尾提升主要通过分布图展示，缺少更细的因果分解。

5. 局限与未来方向

作者在结论中明确提出两个方向：扩大 PushDualGen 的模型规模，以及把它从推送推荐扩展到推送以外的场景。方法层面，SID 使用 K-means 是为了简单和高效，作者把更先进的量化策略留给未来；当前实验也依赖 Qwen3-0.6B 和 Qwen2.5-Omni-3B 的组合，未系统比较不同语言模型大小、码本规模和 SID 长度。

从正文可见的工程局限包括：线上 A/B 主要覆盖推送流量，不能直接推断首页信息流、搜索推荐或广告排序的收益；生成的解释是 copy，不等于可靠的因果理由，不能把它直接当作用户可见的解释承诺；ANN 融合依然需要维护 SID encoder、视频 encoder 和索引更新链路。论文没有给出更详细的训练硬件、显存占用和端到端 P99，因此迁移到 UGC 社区时仍需补充压测。

6. 工业实践意义

对推荐工程来说，最可借鉴的不是“把 LLM 直接放进召回”，而是把 LLM 产生的用户偏好变成一个可缓存、可检索、可回退的中间表示。社区 UGC 推荐可以把用户最近点击、停留、跳过、不喜欢与搜索行为压成多槽位语义 ID，离线或近线更新；请求路径只读取 Top-N SID 并与现有用户向量融合，避免每次请求都做长上下文生成。

线上系统应把 SID 生成、解释 copy、向量召回和最终排序拆成可独立关闭的模块，并为 SID 版本、码本版本和候选来源打标。PushDualGen 的 100K QPS 规模说明它选择了生成偏好、ANN 扩展候选的混合形态，而不是生成完整列表；这对 P99 更友好。落地时建议先做离线 replay 和小流量 A/B，除 CTR 外同时监控有效消费率、不喜欢率、长尾曝光和冷启动覆盖；如果 copy 与真实用户反馈不一致，应只作为审计信号，不要让解释文本反向污染排序标签。

1. 问题与动机

多任务推荐通常把一段用户行为编码成一个共享表示，再在末端接 CTR、转化、目的地或其他任务 head。论文认为，这种范式在生成式推荐中会出现三类坍缩。Source collapse 是任务信号注入太晚，任务相关信息在共享压缩时已经丢失；relation collapse 是任务间依赖被 backbone 隐式吸收或被固定 funnel 锁死；hierarchical collapse 是不同任务需要不同层次的特征，却被迫从同一深度读出。

作者以地图和出行推荐为例：一次会话同时决定何时出发、去哪里、如何出行以及途中经过哪个 POI。Where 依赖当前会话和即时场景，When 依赖长期周期，How 可能受出行模式和目的地共同影响，Via 则依赖具体路线和沿途兴趣。把它们压进一个 task-agnostic 向量会让主导任务占据容量，弱信号无法恢复。论文因此不只改 loss 或多任务 head，而是把任务身份放入 encoder 早期，并允许任务彼此交互、从不同深度检索信息。

2. 方法详解

IntHQ 采用 context stream 与 task stream 双流结构。原始行为被组织成场景 token、item token、feedback token，另外加上长期用户 profile token。每个会话附加四个可学习 task token，对应 when、where、how、via。task token 和 context token 使用分离的参数，不让同一套 attention 权重同时承担行为压缩和任务查询两种互相冲突的角色。

每层先在 context stream 内做标准因果 self-attention，得到对历史和场景的上下文摘要；并行地，每个 task token 对 context stream 做 task-to-context cross-attention，Q/K/V 的 task 侧投影只受 task stream 梯度更新，context 的 K/V 来自当前层输入。随后 task token 之间再做带因果约束的 self-attention，从而允许任务信息互相影响，但不允许未来标签泄漏。因果索引同时处理跨会话可见性和会话内顺序，例如 where 的信息可以影响 via，反过来不能让前置决策看到后置结果。

Task-Interactive Modeling 是任务流内部的显式交互层。它不预设固定的任务顺序，而是根据当前会话让 task token 通过 attention 学习动态关系。这样，通勤场景中目的地可能强烈约束交通方式，旅游场景中目的地不确定时这种关系会变弱。这个设计把“任务之间有关系”从一个静态结构变成输入依赖的权重。

Hierarchical Querying 在每一层保存 task stream 的状态，形成从浅到深的 task representation bank。对任务 k，使用任务 embedding 构造 query，把每一层状态加上对应的 depth embedding 作为 key/value，通过 softmax 在深度轴上加权，得到最终 task representation。浅层更保留当前会话的高分辨率信号，深层更适合长期规律；每个任务、用户和会话都可以选择不同深度，不再强制统一读最后一层。

每个任务有自己的 InfoNCE loss，小标签空间的 when/how 可用全类 softmax，where/via 这类 POI 空间则使用正样本加采样负样本的 sampled softmax，最终损失是各任务损失之和。训练数据 IntTravel 来自真实地图与导航平台，约 4.1B 交互、163M 用户和 7.3M POI，覆盖四个耦合任务。实验还将 encoder 深度 L 从 2、4、8、16、32 和宽度 D 从 24、48、96、192、384 做网格扫描。

在线部署把重计算移出请求路径：离线任务从原始日志预构建用户的 session structured history，写入 KV store；请求到来时按 user ID 取回 prefix，在 GPU 节点打分，where/via 的表示再去 POI ANN 索引检索；反馈回写日志用于下一轮训练。生产配置能处理长度 300 的序列，其中包含最近 100 个行为，在 150 张 96GB GPU 上支持峰值 30K QPS。

3. 核心技术贡献

第一，DSD 把 task token 从第一层注入并使用独立 attention core，直接缓解共享表示带来的 source collapse。第二，TIM 用输入依赖的任务间 attention 取代固定 funnel，能表达目的地、交通方式、出发时间和沿途 POI 的条件关系。第三，HQ 在深度轴做任务特定的查询，让即时意图和长期偏好分别从更适合的层读取。

这些贡献不是简单增加参数。作者的 pilot 分析显示 fine-grained retrieval 任务通常在第 1–3 层更可解码，而 coarse intent 更依赖第 5–7 层；这解释了为什么单一末层表示会牺牲任务差异。消融也表明，去掉 DSD 会在四个任务上普遍下降；去掉 TIM 对 when/where 影响较小，却明显伤害 how/via，符合任务依赖的解释；去掉 HQ 则四个任务都会降，说明层级选择本身不可省。

4. 实验结果分析

IntTravel 的任务规模和离线结果如下。以 PLE head 为例，IntHQ 的 when accuracy 为 0.8348、how accuracy 为 0.6907、where HR@1 为 0.6842、where HR@5 为 0.8707、via HR@1 为 0.6839、via HR@5 为 0.8706；相近的 shared/one-stream 编码器通常在 when 约 0.831–0.833、how 约 0.57–0.677、where HR@1 约 0.64–0.695、via HR@1 约 0.65–0.705，IntHQ 尤其改善了依赖任务和细粒度 POI 任务。

消融表更能说明机制：

DSD 的缺失造成全局且一致的下降，证明任务信号如果晚注入会在源头丢失；TIM 的缺失主要伤害 How/Via，说明显式任务交互确实在承担条件依赖；HQ 的缺失让所有任务下降，说明不应把最后一层当成所有任务的统一最优表示。深度/宽度扫描中 L∈{2,4,8,16,32}、D∈{24,48,96,192,384} 均呈现随容量增加而变好的趋势，双流结构不需要随规模变化重新设计。

工业部署结果是论文最强的证据。高德线上每个 bucket 使用 20% 流量进行 7 天 A/B，IntHQ 的 UVCTR 相对提升 1.60%，而且按日切片稳定。服务当前已全量上线，平均 RT 40ms，P99 RT 100ms，峰值 30K QPS，序列长度 300，部署在 150 张 96GB GPU 上。这个结果说明结构设计不只是离线指标优化，而是可以嵌入大规模用户序列和 POI ANN 服务。

5. 局限与未来方向

论文主要把实验集中在地图出行场景的四个耦合任务，虽然使用了大规模真实数据和线上 A/B，但没有证明同一组 task token、可见性规则和 head 设计能直接迁移到内容推荐、广告或社区搜索。任务数量固定为四个，任务之间的标签关系也相对清晰；在动态新增任务、强噪声标签或任务目标冲突更大的平台上，TIM 的稳定性需要额外验证。

论文还显示容量增加能继续改善指标，但没有给出更完整的成本—收益曲线；150 张 GPU、30K QPS 的部署规模对中小团队并不轻。作者把重计算移到离线 KV 和 GPU 服务，解决了请求时延，却增加了用户序列更新、模型发布、索引同步和特征新鲜度运维。可能的外部局限是：InfoNCE 的负采样仍影响长尾 POI 的学习，且 UVCTR 提升不等于长期留存或多样性一定改善。

6. 工业实践意义

对社区推荐，IntHQ 提供了一个比“共享底座加多个 tower”更具体的多目标建模路线。可以把 CTR、长停留、收藏、负反馈、搜索后点击等任务各自变成 task token，context stream 负责压缩用户历史，task stream 负责按目标查询；对强耦合目标再允许 task self-attention，而不是用固定的串联 funnel。不同任务的最优深度可通过 probe 或可学习的 depth attention 找到：即时 query 意图可能偏浅层，长期兴趣和稳定偏好可能偏深层。

工程上应先离线物化用户 session history，在线只取可版本化的 prefix，再做 GPU 打分和 ANN 召回；对于短文本 UGC，序列 token 可以同时编码内容、场景、反馈类型和时间间隔。上线验收不能只看平均延迟，至少应复现论文的 sequence length、QPS、平均 RT/P99 以及模型刷新周期。若资源有限，可先在精排而非全召回层试双流结构，逐个增加任务，并用每任务离线指标、跨任务负迁移、长尾覆盖和线上 UVCTR 共同决定是否扩大流量。