GR4AD：广告生成式推荐开始把 value-aware RL 和 beam serving 写成同一套系统

背景

补完 OneRec-V2、PROMISE、OpenOneRec/verl_rl 和 From Logs to Language 之后，我原本已经比较习惯把生成式推荐里的增量拆成几类：

  1. 训练侧的 RL / preference optimization
  2. 推理侧的 search controller / test-time scaling
  3. 上游的 profile / verbalizer / simulator / verifier

但这一轮重新扫 2026-02 之后的新论文时，我补到了一条此前还没进 Story Lab 的重要工业入口：

  1. Generative Recommendation for Large-Scale Advertising
  2. GR4AD arXiv HTML
  3. Generative Recommendation for Large-Scale Advertising - 智源社区论文

核完之后，我更倾向于把这条线记成：

广告生成式推荐开始把 RL、decoder 和 serving 写成同一套 business-value production stack

更具体一点说，是：

VSL + RSPO + LazyAR + Dynamic Beam Serving

这四层不再是可以分开讲的“算法模块”，而是一起围着 eCPM / revenue / latency / QPS 做工业共设计。

如果用更接近 Story Lab 的语言来概括，这轮最值得记的不是“广告里也有生成式推荐”，而是：

training-serving co-design

开始变成生成式推荐进入广告系统之后的主问题。

顺带一提，我也更倾向于把 GR4AD 视作快手生成式推荐方法论向广告系统外扩的一条公开信号。这是一个基于来源的推断：

  1. 论文作者里继续出现了 Guorui Zhou / Changcheng Li / Peng Jiang
  2. 正文 5.1 直接把 OneRec-V2 当作 generative recommendation baseline
  3. 部署场景仍然是 Kuaishou 的工业系统

这不是论文自称“它就是 OneRec 广告版”，所以这里我明确把它当作推断，而不是原文结论。

核心判断

GR4AD 的关键不是“广告里也能做生成式推荐”，而是广告场景把系统主矛盾改写了

这篇 paper 的摘要和引言写得很直接：

deploying real-time generative recommendation in large-scale advertising requires designs beyond LLM-style training and serving recipes

也就是说，它修的不是普通 LLM4Rec 论文里常见的“模型能不能生成对的 item”，而是一个更硬的工业组合问题：

  1. tokenization 要适配广告的复杂业务信息
  2. learning 要直接贴 eCPM / revenue
  3. serving 要在 latency / QPS / traffic fluctuation 下持续跑
  4. search budget 还要能随线上负载动态变化

所以 GR4AD 一上来就不是在做单独一个模块，而是在一起做四层：

  1. UA-SID
  2. LazyAR
  3. VSL + RSPO
  4. Dynamic Beam Serving

这和此前站里记录的大多数路线都不一样。

OneRec-V2 更像“真实用户反馈怎样进入生成式推荐后训练”。 PROMISE 更像“process reward 怎样进入 test-time beam search”。 GR4AD 则把两者再往工业系统层推进了一步：

训练和搜索都要一起服从线上 business value 与 serving budget

RSPO 说明广告里的 RL consumer 已经是 list-wise business-value optimizer，而不是普通 post-training 附件

3.4 节和 Appendix A 最值得记。

论文没有把 RSPO 写成泛化的“又一个 RL trick”，而是明确把它做成：

  1. ranking-guided
  2. list-wise
  3. 直接贴 eCPM 这类价值信号

正文 3.4 说得很清楚：

  1. VSL 主要拟合 logged distribution
  2. 它能学用户兴趣分布，但不能直接优化 downstream value objective
  3. 因而需要一个额外的 ranking-guided RL stage 去做 value-aware、list-level optimization

更关键的是，Appendix A 不是泛泛而谈，而是直接把 RSPO 锚到 NDCGcost 上。

A.1 节里：

  1. 把 reward 写成 eCPM
  2. 用 NDCGcost 表示排序偏离理想业务价值排序的代价
  3. 最后给出结论：忽略常数项时，L_RSPO 优化的是 NDCGcost 的上界

这意味着 RSPO 不是普通 DPO / GRPO 的广告重命名版本。 它更像一类 recommendation-native、business-metric-native 的 list-wise RL objective。

正文 5.1 还进一步给了很强的消费侧信号：

  1. VSL 本身已经能明显抬 revenue
  2. 但 RSPO 带来的增益是所有优化组件里最显著的一档
  3. 论文还明确写出它相比 DPO 和 GRPO 更能捕捉用户偏好并提升业务收入

所以在 Story Lab 现有方法表里，GR4AD 更不能被简单压成“又一个 reward optimization route”。

更准确的理解是：

广告场景里的 RL consumer 已经从 token-level / sequence-level 对齐，前移成 list-wise business-value optimizer

Dynamic Beam Serving 把 beam width 从离线超参改成了线上 traffic controller

如果说 RSPO 代表训练侧的 business alignment，那 Dynamic Beam Serving 代表的就是推理侧的新 owner。

4.2.1 节把这件事写得非常明确：

  1. 最终返回候选数由最后一步 beam width 决定
  2. 真正主导计算开销的是前面几步 beam width
  3. 因此全程固定 beam width 在受限预算下通常是次优的

于是 DBW 做的第一件事，就是把固定 512-512-512 改成逐步放大的 128-256-512。

这和 PROMISE 的 K+ 逻辑有相通处，但系统位置不一样。

PROMISE 更强调：

用 verifier 重新分配搜索预算

而 GR4AD 更强调：

在既定 serving budget 下，beam width 本身就是需要在线调度的资源

更往前一步，TABS 又把它从“按 step 调”推进到了“按 traffic 调”。

4.2.1 和 5.1 给出的信号是：

  1. 离峰时把 beam width 放大
  2. 高峰时保持基线 beam 不变
  3. 论文正文明确写到离峰时 beam 可以提升 60%
  4. 这样做既能保住峰值时延，又能在空闲算力下换更多 revenue

这意味着推荐里的 test-time scaling 到这里已经不只是研究时的离线超参，而开始变成：

traffic-aware search budget

也就是一个显式的 serving-time controller。

LazyAR 和双 scaling law 说明广告生成式推荐已经把“算多大模型”和“搜多宽 beam”写成同一张账

LazyAR 本身也很值得记。

3.2 节和 5.1 的组合说明，它不是普通的推理小优化，而是为了让广告里的短序列、多候选生成在现实预算下跑起来。

论文给出的核心信号有三层：

  1. LazyAR 把对前一 token 的依赖延后到中间层，而不是一开始就全层自回归
  2. 在实验配置里，L = 9，前 K = 6 层在所有 beams 间共享
  3. 正文直接说它几乎把 QPS 翻倍，同时只带来边际性能下降

更重要的是，它和 DBS 一起把广告系统里的 scaling law 写成了两条并行曲线。

5.2 节给出的在线结果非常直接：

  1. model size 从 0.03B 增到 0.32B 时，revenue lift 从 +2.13% 升到 +4.43%
  2. 在固定 0.16B 模型下，beam width 从 128 放到 1024 时，revenue lift 从 +2.33% 升到 +4.21%

这说明广告生成式推荐到这一步，已经不再是单一的“模型越大越好”或“搜索越宽越好”。

它更接近：

模型规模 × 搜索预算 × 线上负载

三者联合决定最终价值。

这和 PROMISE 的 test-time scaling 形成了一个很好的互补：

  1. PROMISE 更像 verifier-guided search control
  2. GR4AD 更像 serving-budget-aware search control

两者放在一起看，Story Lab 后续就不能只记“有没有 beam search / 有没有 test-time scaling”了，还得继续问：

谁在控制搜索预算

这条线的工业信号已经非常硬，不能再按普通 academic baseline 记录

GR4AD 最不能被低估的一点，是它不只是 paper 里说“我们在工业数据上做了实验”。

摘要、引言和实验节把部署边界都写得很实：

  1. 已在 Kuaishou 广告系统全量部署
  2. 服务 400M+ 用户
  3. 推理时延控制在 <100ms
  4. 单卡 L20 做到 500+ QPS

正文 5.1 还给了几组很关键的业务结果：

  1. 相比原有 DLRM 栈，广告收入最高提升 4.2%
  2. 中小广告主的 ad delivery 提升 17.5%
  3. 广告转化率提升 10.17%
  4. 对低活用户，转化率仍提升 7.28%

这些指标的含义很重要。

它们说明 GR4AD 不只是“生成式推荐在广告里也能涨一个 offline metric”，而是已经在：

  1. 平台收入
  2. 广告主覆盖
  3. 用户转化

三边关系上都拿到了产品级信号。

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

industrial production stack

而不是普通的 paper + weak code evidence。

对 Story Lab 来说，GR4AD 逼出了一个此前没单列的观察层：training-serving co-design

把 GR4AD 放回站里现在已有的分类，会出现一个很具体的问题：

它当然可以被记到这些旧格子里：

  1. 端到端生成器
  2. 真实/估计价值信号
  3. list-wise RL
  4. test-time search

但只这么记会丢掉它最重要的新结构：

训练目标、beam 预算和 serving 负载已经被共同写进一个系统控制闭环

所以我更倾向于在 Story Lab 后续观察表里，再额外补一层：

training-serving co-design

至少先记录两件事：

  1. 有没有显式 serving-time controller
  2. 搜索预算是 fixed offline beam、progressive beam width，还是 traffic-aware adaptive beam

否则 PROMISE、GR4AD 这种都涉及 beam search 的路线，还是会再次被写成同一种“推理放大”。

证据与来源

  • Generative Recommendation for Large-Scale Advertising：arXiv 摘要主入口。2026-02-26 提交，2026-03-04 更新到 v2；摘要已写清 UA-SID、LazyAR、VSL、RSPO、Dynamic Beam Serving、4.2% ad revenue lift、400M+ 用户部署。
  • GR4AD arXiv HTML：正文关键入口。3.4 节写 RSPO 的 list-wise RL 位置，4.2.1 节写 DBW + TABS 的 traffic-aware beam 控制，5.1 节给出 17.5% 中小广告主投放增长和 10.17% 转化率提升，5.2 节给出 model scaling 与 inference scaling 的在线收益，Appendix A.1 则明确把 RSPO 锚到 NDCGcost 上界。
  • Generative Recommendation for Large-Scale Advertising - 智源社区论文：当前能稳定回溯到的中文传播层入口。它把 UA-SID / LazyAR / RSPO / Dynamic Beam Serving 压成一页中文导读，并补出“快手广告系统全量部署”的中文可见层语境。
  • GitHub API 检索 GR4AD、论文全标题与 GR4AD in:name,description,readme：截至 2026-03-21，仅看到无关个人仓与 awesome list，未见稳定官方 repo，因此当前公开边界更适合写成 industrial paper-first。
  • 公开网页检索 site:xiaohongshu.com GR4AD 快手 广告 推荐 与相关 xhslink 组合：截至 2026-03-21，仍未找到稳定高价值 xhslink。

下一步

  • 把 GR4AD 和已补的 OneRec-V2 / PROMISE 并到同一条快手工业观察线上，单独记录 training-serving co-design 与 traffic-aware search budget 这两层。
  • 在统一方法表或系统瓶颈表里新增 serving-time controller 一列，至少先区分 fixed offline beam、progressive beam width 与 traffic-aware adaptive beam。
  • 继续跟踪 GR4AD 是否出现稳定官方 repo；如果后续放出训练或 serving 代码，再把它从 paper-first 更新到更细的 workflow 边界。
  • 继续补中文传播层和 xhslink；在拿到稳定一手线索之前，传播层只做导航，不覆盖事实判断。