OneMall：快手开始把电商生成式推荐写成多场景 family，并让 ranking reward 回流 retrieval

背景

补完 OneRec / OneRec-V2 / OpenOneRec 和 GR4AD 之后，我原本已经比较习惯这样理解快手公开出来的生成式推荐主线：

  1. OneRec 代表短视频主线里的端到端 generative retrieval。
  2. GR4AD 代表广告主线里的 value-aware RL + serving co-design。
  3. OpenOneRec 代表对外开放的训练与 benchmark 底盘。

但这一轮继续沿 Kuaishou + e-commerce + generative recommendation + reinforcement learning 做增量检索，再回到 arXiv 摘要页、arXiv HTML 和 GitHub API 定向核验后，我补到了一条此前还没进 Story Lab 的关键入口：

  1. OneMall: One Architecture, More Scenarios -- End-to-End Generative Recommender Family at Kuaishou E-Commerce

核完之后，我更倾向于把它记成：

快手开始把生成式推荐从单场景主线扩成电商多场景 family

而且这条线真正补出来的，不只是“电商也能做 generative recommendation”，而是两层更具体的新结构：

  1. product-card / short-video / live-streaming 三种 item 分布被压进同一个 family。
  2. ranking model -> reward signal -> retrieval policy 这条桥被显式写成 end-to-end RL。

核心判断

OneMall 的关键不是“快手电商版 OneRec”，而是公开主线开始出现 scenario family

这篇论文最值得记住的点，不是它也来自 Kuaishou。

真正重要的是，它明确把电商写成：

one architecture, more scenarios

也就是一个多场景 family，而不是一个单一场景模型。

摘要和引言都把三类 item 说得很清楚：

  1. Product-Card
  2. Short-Video
  3. Live-Streaming

而且它们不是表面上的三个流量入口，而是三种不同的系统对象：

  1. Product-Card 只服务购物。
  2. Short-Video 同时带内容观看和商品转化。
  3. Live-Streaming 还会随着售卖商品变化，动态改写 item 语义。

这和 OneRec 那种更接近单一短视频 generative retrieval 的公开主线不一样。

更准确地说，OneMall 在补的是：

item role heterogeneity

也就是：

同一个 generative recommender，不只要会生成 item，还要同时处理多种 item 在不同业务场景里的不同职责。

所以它对 Story Lab 最直接的新提醒不是“再多一篇快手论文”，而是：

公开工业主线已经不再只有单场景模型，而开始显式长出 scenario family。

这条线把 ranking model 的角色重新写清了：它不是下游终点，而是 retrieval policy 的 reward supplier

OneMall 的第二个关键点，是它把传统推荐链路里比较隐含的一层写得非常明白：

  1. retrieval model 负责生成候选。
  2. ranking model 拿更全的 user/item/cross features 给出更精细的打分。
  3. 这些 ranking outputs 再被融合成 reward，回流去优化 retrieval policy。

论文 3.3 节直接把这条线写成：

retrieval-ranking connection pipeline

而不是普通的“后面再接一个 ranker”。

更具体一点，它把 ranking model 输出的：

  1. CTR
  2. CTCVR
  3. EGPM

按手工系数融合成 reward，再用 DPO / GRPO 去更新 retrieval 侧 policy。

这意味着在 OneMall 里：

  1. policy owner 是 generative retrieval model。
  2. reward supplier 是 ranking model。
  3. business objective 则更偏单一 GMV 导向。

这和站里之前已经写过的几条线都不完全一样。

OneRec-V2 更强调真实用户反馈怎样重新进入生成式推荐后训练。

GR4AD 更强调 VSL + RSPO + Dynamic Beam Serving 这种 training-serving co-design。

而 OneMall 更像在电商场景里，把传统推荐链路最重要的一座桥重新写成：

ranking-guided retrieval RL

所以 Story Lab 后面更合理的记法，至少该再补一列：

reward supplier

至少先区分：

  1. real user feedback
  2. simulator / judge
  3. ranking model
  4. verifiable rule reward

否则 OneMall 很容易被粗写成又一个普通 GRPO 推荐模型。

电商语境下的 Semantic ID 也不再是静态 item token，而开始受 item role 和 scenario 约束

这篇 paper 还有一个很值得单独记的地方：

它没有把 semantic tokenizer 当成通用配件，而是把 tokenizer 设计直接绑定到电商 item 的业务角色上。

正文 3.1 节写得很清楚：

  1. Product-Card 的语义更偏商品内在商业关系。
  2. Short-Video 既要带商品语义，也要带观看体验。
  3. Live-Streaming 的语义还要随着当前卖什么商品动态更新。

为了做到这点，它不是简单把 title 塞进 tokenizer。

论文直接写出：

  1. 用 product-card 的商业 Item2Item 关系做一层对齐。
  2. 再用 short-video -> product-card 的观看关系做另一层对齐。
  3. Product 吃主图加标题。
  4. Short-Video 吃 6 帧图像、标题、OCR 和 ASR。
  5. live-streaming embedding 再和售卖商品的 Semantic ID 一起动态生成。

这说明 OneMall 的 Semantic ID 不是纯静态 catalog token。

更准确地说，它更像：

scenario-aware business semantic carrier

也就是说，对 Story Lab 来说，后面光记录“有没有 semantic ID”已经不够了，还得继续问：

  1. token 对应的是静态 item，还是动态 item-role
  2. tokenizer 对齐的是通用语义，还是业务关系
  3. token stability 在不同场景里是不是一致

否则 OneMall 和 OneRec / GR4AD / ROS 这几条线都会被写扁成同一种 tokenization 设计。

这条线真正证明的是 family-level 有效，而不是只在一个入口涨点

OneMall 最有说服力的一点，是它不是只在一个电商入口做方法展示。

论文 Table 2 和 Table 3 直接给出三类场景的 replay 与线上结果。

先看 replay：

  1. Product-Card 上，HR@50 从 TIGER 的 29.5% 提到 34.3%
  2. Short-Video 上，HR@50 从 35.1% 提到 44.7%
  3. Live-Streaming 上，HR@50 从 57.3% 提到 65.9%

再看线上 A/B：

  1. Product-Card：GMV +14.71%
  2. Short-Video：GMV +10.33%
  3. Live-Streaming：GMV +4.90%

Short-Video 这一列还有一个容易被忽略的信号：

  1. Exposure +15.32%
  2. Click +5.76%
  3. Order +11.65%

这说明 OneMall 想证明的不是“一个购物 tab 里换个 retrieval 模型能涨单点指标”，而是：

同一套 generative family 可以跨 item distribution scenarios 带来稳定商业收益。

这点和 GR4AD 的广告系统价值不一样。

GR4AD 更像：

同一业务场景里，训练和 serving 如何一起贴 eCPM

OneMall 更像：

同一 generative family 如何跨多个电商入口共享 tokenizer / architecture / RL bridge

所以后续如果要把快手公开路线压成一张工业观察表，至少要再补一列：

scenario-family regime

至少先区分：

  1. single-scenario industrial route
  2. multi-scenario family
  3. cross-product open stack

OneMall 也明确暴露了电商生成式推荐的三个特殊约束

这篇 paper 的引言还有一个很值得记的点：

它没有把电商简单写成“another recommendation vertical”。

它直接把电商场景的三种特殊约束列出来：

  1. item 类型更杂，不只是内容，还要兼顾卖货属性
  2. 正反馈比短视频更稀疏，决策成本更高
  3. 目标更集中在 GMV，不像多目标排序那样天然分散

这三点合起来非常关键。

它们意味着电商 generative recommendation 的主问题，并不只是“能不能生成 item”。

更准确地说，是：

能不能在极稀疏正反馈、强商业目标和多种 item 角色并存的情况下，把 retrieval 继续写成 generative family

这也解释了为什么 OneMall 要把 ranking model 拉回来当 reward supplier。

因为在这种场景里，retrieval 自己拿到的监督显然不够细。

当前公开边界仍是 paper-first，中文传播层和 xhslink 也仍然偏弱

这轮我继续按论文全标题、OneMall、Kuaishou 与 generative recommendation e-commerce 做 GitHub API 检索，截至 2026-03-22 仍未看到稳定官方 repo。

所以这条线当前更适合记成：

industrial paper-first e-commerce scenario family route

而不是已公开 workflow。

中文传播层也还明显偏弱。

这轮继续补做：

  1. OneMall 快手 电商 推荐
  2. OneMall: One Architecture, More Scenarios 中文
  3. site:xiaohongshu.com OneMall 快手 电商 推荐
  4. xhslink OneMall 快手 电商 推荐

稳定结果仍主要回到 arXiv 原文页、自动摘要页和无关噪声，没有拿到足够强的中文机制稿或可复用小红书线索。

证据与来源

下一步

  • 把 OneMall 和 OneRec / GR4AD / OpenOneRec 压到同一张快手公开工业路线表里，至少先区分 single-scenario retrieval route / multi-scenario e-commerce family / advertising training-serving stack / open stack。
  • 在统一方法表里新增 scenario-family regime 与 reward supplier 两列，避免把 ranking model -> reward -> retrieval policy 这类桥接继续写成普通 feedback source。
  • 继续跟踪这篇论文是否补出官方仓、技术博客或更稳定的中文传播层；如果公开边界变化，再回头修正来源池记录。