type
Post
status
Published
date
Apr 5, 2026 16:46
slug
rec-weekly-2026-W14
summary
本周推荐系统研究围绕三条技术主线展开：生成式推荐的工程落地、Agent 驱动的系统自进化、以及排序模型的高效 scaling。
生成式推荐从"能跑"走向"跑得稳"。 阿里巴巴的 RCLRec 用反向课程学习解决转化信号的极端稀疏问题，线上广告收入 +2.09%；复旦的 DACT 提出 tokenizer 持续更新框架，应对数据分布漂移下的标识符失效。两篇论文的共同指向是——生成式推荐的瓶颈已经不在架构设计，而在工业环境下的持续运行。
阿里巴巴同期发布两篇 Agent 推荐系统论文——AutoModel 给工程蓝图，AgenticRS 给理论框架。 阿里巴巴系统性地探索了将 Agent 范式引入推荐系统全生命周期管理，agent 的角色从"模拟用户"转变为"替代工程师"。不过两篇论文目前都缺乏线上实验数据，能否跑通自动迭代闭环尚待验证。
排序模型的 scaling 竞赛继续加速。 快手的 UniMixer 将 attention、TokenMixer、FM 三类架构统一到一个参数化框架，在同等计算预算下 AUC 优于 RankMixer；Google 的零样本跨域知识蒸馏从 YouTube 迁移知识到 YouTube Music，线上 watch time +1.2%，为低流量场景提供了低成本能力迁移路径。
tags
推荐系统
周报
论文
category
推荐技术报告
icon
password
priority
本周概览
本周推荐系统研究围绕三条技术主线展开：生成式推荐的工程落地、Agent 驱动的系统自进化、以及排序模型的高效 scaling。
生成式推荐从"能跑"走向"跑得稳"。 阿里巴巴的 RCLRec 用反向课程学习解决转化信号的极端稀疏问题，线上广告收入 +2.09%；复旦的 DACT 提出 tokenizer 持续更新框架，应对数据分布漂移下的标识符失效。两篇论文的共同指向是——生成式推荐的瓶颈已经不在架构设计，而在工业环境下的持续运行。
阿里巴巴同期发布两篇 Agent 推荐系统论文——AutoModel 给工程蓝图，AgenticRS 给理论框架。 阿里巴巴系统性地探索了将 Agent 范式引入推荐系统全生命周期管理，agent 的角色从"模拟用户"转变为"替代工程师"。不过两篇论文目前都缺乏线上实验数据，能否跑通自动迭代闭环尚待验证。
排序模型的 scaling 竞赛继续加速。 快手的 UniMixer 将 attention、TokenMixer、FM 三类架构统一到一个参数化框架，在同等计算预算下 AUC 优于 RankMixer；Google 的零样本跨域知识蒸馏从 YouTube 迁移知识到 YouTube Music，线上 watch time +1.2%，为低流量场景提供了低成本能力迁移路径。
生成式推荐的工程挑战与优化
生成式推荐的核心瓶颈正从"模型架构设计"转向"工业环境下的持续运行"。本周两篇论文分别瞄准 tokenizer 增量更新和稀疏转化信号建模，都是把生成式推荐真正跑在线上之后才会遇到的问题。
RCLRec: Reverse Curriculum Learning for Modeling Sparse Conversions in Generative Recommendation (2603.28124) — 阿里巴巴
生成式推荐通过统一 token 序列建模多类行为，缓解了部分数据稀疏问题，但转化信号（购买、下单）本身的极端稀疏性仍未解决。现有 behavior-aware 方法在全历史上做 attention，对转化决策链路的建模不够聚焦。
RCLRec 的思路很直接：对每个转化目标，从用户历史中反向抽取与转化相关的 item 子序列，作为 decoder 的 prefix。这个"反向课程"从转化点出发向前追溯，天然聚焦于用户的关键决策路径。prefix 的 semantic token 与目标转化 token 一起做联合生成训练，为转化预测提供实例级别的中间监督信号。同时引入课程质量感知损失，过滤掉信息量低的课程序列，避免噪声干扰。
线上 A/B 测试结果是核心看点：广告收入 +2.09%，订单量 +1.86%。这是在阿里巴巴广告场景的真实部署数据。对于转化这种极稀疏目标，接近 2% 的线上提升是实打实的收益。值得注意的是，这里的生成式推荐被用在精排阶段而非召回，说明 GR 的应用范围正在向漏斗下游扩展。
Drift-Aware Continual Tokenization for Generative Recommendation (DACT) (2603.29705) — 复旦大学
生成式推荐的 tokenizer 在静态数据集上效果不错，但线上环境的数据分布持续漂移：新 item 引入导致标识符碰撞，用户交互模式变化导致协同信号漂移。全量重训 tokenizer + GRM 成本高昂，但朴素 fine-tune tokenizer 会大面积改变已有 item 的 token 序列，破坏 GRM 已学到的 token-embedding 对齐关系。
DACT 分两阶段处理这个问题。第一阶段：fine-tune tokenizer 时，联合训练一个协作漂移识别模块（CDIM），输出每个 item 的漂移置信度，对漂移 item 和稳定 item 做差异化优化——漂移的需要更新，稳定的尽量保持。第二阶段：分层代码重分配，采用"先松后严"的策略更新 token 序列，在必要更新和减少不必要变更之间找平衡。
这个问题在历史工作中已有铺垫。LETTER (2405.07314) 通过 RQ-VAE 正则化和协同对齐损失改进了静态场景下的 tokenizer 质量；BLOGER (2510.21242) 用双层优化显式建模 tokenizer 和推荐器的依赖关系；但这些工作都假设一次性训练。DACT 系统性地处理了 tokenizer 持续演化问题，在三个数据集、两个 GRM 架构上均优于基线。不过目前只有离线实验，缺少线上验证，实际部署中漂移检测的延迟和重分配的频率控制仍待观察。
两篇论文的共同指向很清晰：生成式推荐的研究重心正在从"怎么建模更准"转向"怎么在真实环境里持续、可靠地运行"，数据漂移适应和稀疏信号建模都是规模化部署后的刚需问题。
Agent 驱动的推荐系统架构
阿里巴巴同日放出两篇互补论文，试图回答同一个问题：能不能让推荐系统自己迭代自己？一篇给工程蓝图，一篇给理论框架。
AgenticRS-Architecture: System Design for Agentic Recommender Systems (2603.26085) — 阿里巴巴
工业推荐系统的日常迭代高度依赖人工：读论文、复现方法、调特征、上线实验、监控性能，每个环节都需要工程师手动介入。AutoModel 把这条人肉流水线拆成三个自治 agent：AutoTrain 负责模型设计与训练，AutoFeature 负责数据分析与特征演化，AutoPerf 负责性能监控、部署和在线实验。三个 agent 之上有共享的协调与知识层，记录历史决策、配置和实验结果，形成长期记忆。
论文给出了一个具体的 case study：Paper AutoTrain 模块。它的工作流是——解析论文方法描述，自动生成训练代码，在大规模数据上跑训练，最后做离线对比。本质上是把"读论文 -> 复现 -> 跑实验"这个推荐工程师的核心工作循环自动化了。不过论文没有报告线上 A/B 测试结果，也没有给出 Paper AutoTrain 的代码生成成功率或离线指标对比的具体数字。作为系统设计论文，它更像是一份架构宣言而非实验验证。
Rethinking Recommendation Paradigms: From Pipelines to Agentic Recommender Systems (2603.26100) — 阿里巴巴
如果说上一篇是"怎么建"，这篇回答的是"为什么要建、边界在哪"。论文的核心论点：不管是传统多阶段 pipeline（召回-粗排-精排-重排）还是近年流行的 One Model 方案，本质都是静态的。模型是黑盒，系统改进依赖工程师手动提假设、做实验。在异构数据和多目标业务约束下，这种方式的 scaling 天花板很低。
AgenticRS 定义了模块升级为 agent 的三个前提条件：功能闭环（模块能独立完成一个完整子任务）、独立评估（有明确可度量的指标）、可进化决策空间（优化空间足够大且可搜索）。满足这三条才值得做 agent 化，否则只是增加系统复杂度。这个筛选标准本身比"把所有模块都变成 agent"务实得多。
自我进化方面，论文区分了两条路径：在定义明确的动作空间中用强化学习做优化（比如超参搜索、特征选择），在开放式设计空间中用 LLM 生成和筛选新架构与训练方案。同时区分了单 agent 的个体进化和多 agent 的组合进化——后者关注 agent 之间如何选择和连接。分层内外奖励设计用来耦合局部优化和全局目标：内层奖励驱动单个 agent 的局部改进，外层奖励确保全局业务指标不退化。
值得注意的是，之前 LLM agent 在推荐中的应用主要集中在用户行为模拟（如 AgentCF 将用户和物品建模为 LLM agent 做协同学习，Agent4Rec 用生成式 agent 模拟用户行为做推荐评估）以及交互增强。这两篇阿里的论文把 agent 的角色从"模拟用户"翻转为"替代工程师"——agent 不再扮演推荐系统的服务对象，而是成为推荐系统本身的构建者和维护者。今年 2 月的 LLM-powered Agent for RecSys 综述 识别了推荐导向、交互导向和模拟导向三个范式，AutoModel/AgenticRS 拓展了 agent 在推荐系统中的应用方式——从辅助推荐到驱动系统自进化。两篇论文目前都停留在架构设计和理论框架层面，缺少硬数字支撑。能否真正跑通"agent 自动迭代推荐系统"的闭环，还需要后续的线上验证来回答。
推荐模型的 Scaling 架构与知识迁移
本周两篇工业论文分别来自快手和 Google，切入推荐排序模型扩展的两个不同瓶颈：一个统一三类主流 scaling 架构以提升参数效率，一个用零样本跨域蒸馏解决低流量场景的教师模型缺位问题。
UniMixer: A Unified Architecture for Scaling Laws in Recommendation Systems (2604.00590) — 快手
推荐排序模型的 scaling 路线目前分裂为三条：attention-based、TokenMixer-based、factorization-machine-based。三者设计哲学不同，架构差异大，无法共享优化经验。快手提出 UniMixer，将三者统一到同一个理论框架下。
核心洞察：TokenMixer 中基于规则的 token mixing 操作可以等价转换为参数化结构。基于这一等价性，UniMixer 构建了一个通用的参数化特征混合模块（generalized parameterized feature mixing），将原本固定的 token mixing 模式变为可学习的。这个统一视角解开了一个架构约束——传统 TokenMixer 要求 head 数量等于 token 数量，UniMixer 消除了这一限制，让模型在 head 数和 token 数的配置上有更大自由度。
在此基础上，UniMixing-Lite 进一步压缩参数量和计算开销。论文的离线实验直接对标 RankMixer，在 AUC vs. Parameters 和 AUC vs. GFLOPs 两个维度上均优于 RankMixer，即同等参数量或计算预算下能获得更高 AUC。线上实验验证了 UniMixer 的 scaling 优势，已在快手部署（论文未公开具体线上指标数字）。
回顾历史脉络，这条线的演进很快。2025 年中，字节的 RankMixer (2507.15551) 用硬件感知的多头 token mixing 替代 Transformer 自注意力，在抖音全量部署中提升用户活跃天数 0.2-0.3%、APP 使用时长 0.5-1.08%。随后 TokenMixer-Large (2602.06563) 进一步简化注意力为轻量级 token mixing 操作，在电商、广告和直播场景中分别带来 ADSS 2.0% 和收入 1.4% 的提升。UniMixer 的贡献不在于刷出更高的单点指标，而在于提供一个统一的理论视角：attention、TokenMixer、FM 本质上是同一个参数化特征混合框架的不同特例。这意味着后续的架构搜索和 scaling 实验可以在一个统一空间内进行，而不是在三条割裂的路线上各自摸索。
Zero-shot Cross-domain Knowledge Distillation: A Case Study on YouTube Music (2603.28994) — Google
低流量推荐场景面临一个现实困境：数据量不足以训练大规模教师模型，而专门为小场景训练一个大教师的 ROI 又不划算。Google 的这篇论文给出一个直接的工程答案：从数据量 100 倍的 YouTube 视频推荐平台借教师。
挑战在于"跨域"二字。YouTube 视频推荐和 YouTube Music 音乐推荐之间，特征空间不同、用户交互界面不同、预测任务也不同。论文采用零样本跨域知识蒸馏（zero-shot cross-domain KD），不需要在目标域（Music）上训练专用教师模型。具体做法是将源域（YouTube 视频）大规模排序模型的知识，通过多任务排序框架迁移到 Music 端的排序模型。
线上 A/B 实验结果：watch time +1.2%。论文覆盖了 Music 端两个排序模型的离线和线上实验，验证了跨域蒸馏在不同模型结构上的泛化性。这篇论文的核心价值不在于方法的新颖性——知识蒸馏本身是成熟技术。价值在于工业验证：在特征空间和任务定义都有显著差异的真实跨域场景下，零样本 KD 确实能产生线上收益。这为大量"有主站大模型但子业务数据不足"的公司提供了一个低成本的能力迁移路径。
两篇论文指向同一个方向：推荐排序模型的 scaling 正在从"怎么把模型做大"转向"怎么让大模型的能力更高效地流动"。UniMixer 让不同架构族之间的参数效率可以公平比较和统一优化；Google 的跨域蒸馏则让大流量场景积累的模型能力流向数据稀疏的长尾场景。
值得关注的方向
生成式推荐的工业化运维。 DACT 和 RCLRec 共同表明，生成式推荐在部署后面临的工程挑战——tokenizer 漂移、稀疏转化建模——正在成为研究热点。阿里巴巴已在广告场景验证了 RCLRec 的线上效果。随着更多团队将 GR 推向生产环境，tokenizer 的持续学习、多行为序列的高效编码等问题将持续产生高价值工作。
Agent 驱动的推荐系统自进化。 阿里巴巴的 AutoModel 和 AgenticRS 将 agent 从"模拟用户行为"的辅助角色，提升为"自动迭代推荐系统"的核心角色。这个方向目前仍在概念验证阶段，缺少线上数据支撑。但如果后续能验证 Paper AutoTrain 等模块的端到端效果，将改变推荐系统的开发模式——从人工驱动的假设-实验循环，转向 agent 驱动的自动搜索-验证循环。
排序模型 Scaling 的架构统一与跨域迁移。 UniMixer 统一了三条 scaling 路线的理论基础，Google 的零样本跨域 KD 验证了大模型能力向低流量场景的迁移可行性。两条路线互补：一个解决"怎么更高效地扩展"，一个解决"怎么把扩展的收益传播到更多场景"。在快手、字节、Google 等头部平台的持续推进下，推荐模型的 scaling 将越来越像 LLM 的发展轨迹——架构收敛、规模扩大、能力通过蒸馏和迁移扩散。
本周论文速览
生成式推荐
RCLRec — 阿里巴巴提出反向课程学习框架，为生成式推荐中的稀疏转化目标构建决策子序列前缀；线上广告收入 +2.09%，订单 +1.86%。
DACT — 复旦大学提出漂移感知持续 tokenization 框架，通过 CDIM 模块识别协作漂移并分层重分配 token 代码；三个数据集上优于基线。
Agent 推荐系统
AutoModel — 阿里巴巴提出 agent-based 推荐系统全生命周期架构，含 AutoTrain/AutoFeature/AutoPerf 三个核心 agent；Paper AutoTrain 模块演示论文到实验的自动化闭环。
AgenticRS — 阿里巴巴提出 Agentic Recommender Systems 范式，定义模块升级为 agent 的三个标准，设计 RL + LLM 双路径自我进化机制。
Scaling 与知识迁移
UniMixer — 快手统一 attention/TokenMixer/FM 三类 scaling 架构为参数化特征混合框架，UniMixing-Lite 在同等计算预算下 AUC 优于 RankMixer；已线上部署。
Zero-shot Cross-domain KD — Google 从 YouTube 视频推荐零样本蒸馏到 YouTube Music 排序模型；线上 watch time +1.2%。
其他
SPREE — Amazon Music 提出基于激活导向的个性化流行度去偏方法，通过 Popularity Quantile Calibration 框架量化用户-推荐对齐度；用户级流行度对齐提升 10-20%。
UniRank — 阿里巴巴提出基于 VLM 的混合文本-图像多模态重排框架，结合指令微调和 RLHF 偏好对齐实现领域自适应；Recall@1 提升 8.9%/7.3%。