SPARC: Sequence-aware Progressive Attribute Routing and Compression Framework for Generative Recommendation
Chang Liu, Changfa Wu, Hui Qian, Binbin Cao, Jian Wu, Yuliang Yan, Han Zhu, Bo Zheng
cs.IR
2026-07-28
生成式推荐里 SPARC 先按字段建模上下文再动态路由压缩,不增加主干输入长度,淘宝点击命中率 +6.4%、公开数据集 +70%。
生成式推荐把每个商品编码成一串离散的语义 ID(SID),像语言模型生成下一个词一样,从用户的历史 SID 序列自回归地预测下一个商品。问题在于真实的一次交互不止带商品 ID,还带一堆异构字段:品类、品牌、卖家、价格、库存、行为类型、时间戳。
怎么把这些字段塞进生成式主干?两条路都不好走。一是全展开,每个字段单独成一个 token,L 次交互从 L 个 token 膨胀到 L×F 个,自注意力的二次复杂度扛不住。二是直接压缩成单个表示再喂进去,但会在信息还没分清主次之前就揉成一团,丢掉「上下文相关」的信号(比如同一个品牌,用户反复买同品牌时才关键,换用户可能无关紧要)。
SPARC 来自阿里,原则是「先上下文化,再压缩」,分三段。
第一段 FCM 按字段类型分别建模序列依赖。把所有「品牌」字段沿用户历史排成一条序列,用一个轻量编码器算出带上下文的品牌表示。这样每个字段既有原始值,也有它在这条历史里的上下文版本。
第二段 CAR 是核心。字段分两组:SID 字段(商品身份)原样保留不参与混合;其余 side 字段(品类、价格、行为类型等)走动态路由。路由用一个可学习的「槽位」去算每个 side 字段该往哪个槽里塞多少,同一个商品在不同用户历史下路由分布不同,这就是「上下文相关」。最终每次交互被压成固定数量 token(SID token 加两个 side token),主干输入长度不增加。
第三段 STC 把这些中间 token 在序列层面再融合一次,用一个初始化得很小的残差门慢慢引入跨 token 交互,避免一上来就扰乱压缩好的表示空间。
在淘宝工业数据(21M 用户、0.27B 商品、26B 交互)上,SPARC 叠在 RankGR 主干之上。点击命中率 HRclick@20 从 RankGR 的 0.1568 提到 0.1669(+6.4%),HRclick@1000 从 0.5777 提到 0.5883。公开的 Amazon Beauty/Toys 上提升更大(Beauty HR@20 从 0.0466 到 0.0794,约 +70%),因为数据更稀疏,自适应保留信息的收益更明显。
消融对比了几种静态压缩(QFormer、MLP、Modulated),SPARC 全部胜出。赢点在按上下文决定保留什么,不靠堆大压缩模块的容量。
| 指标(淘宝) | RankGR | SPARC | 提升 |
| HRclick@20 | 0.1568 | 0.1669 | +6.4% |
| HRclick@1000 | 0.5777 | 0.5883 | +1.8% |
生成式推荐的主干输入长度是个硬约束,这篇在不增加主干输入的前提下,把上下文相关的多字段信息塞了进去。对做工业推荐的人,这是个能落地的改动:它叠在现有生成式主干上,工程改动集中在表示压缩那一段。路由学出来的模式也对得上直觉(一个槽位盯行为类型和时效,另一个盯卖家和品牌)。
每次交互的 token 预算固定(2 个 SID 加 2 个 side),作者自己也说未来该做自适应预算分配。只用了 9 个字段,更丰富的行为特征没测。淘宝这种超大规模的提升相对温和,作者归因于海量交互已经缓解了一部分表示瓶颈,但这也意味着往数据量没那么夸张的场景外推要谨慎。