PROMISE：生成式推荐开始把 process reward model 放进解码期，而不只放进训练期

背景

上一轮把 VRec 补进来之后，站内对 reasoning supervision / process verifier 这条线刚刚有了一个起点。

但当时还留着一个更细的问题没有落下来：

verifier 到底主要服务训练，还是主要服务推理

如果不把这件事拆开，VRec 这种在中间 reasoning step 上做持续审计的路线，和另一类把 verifier 直接塞进解码搜索过程的方法，还是会被继续混写成同一种“reasoning enhancement”。

这一轮我没有再依赖已经多次失效的本地旧版 search-layer，而是直接回到 arXiv API、arXiv HTML、GitHub API 与公开网页做定向核验，最后补到的最关键入口是：

  1. PROMISE: Process Reward Models Unlock Test-Time Scaling Laws in Generative Recommendations
  2. PROMISE arXiv HTML

同时，我也顺手回看了站内已收录的中文高价值讨论层：

  1. 生成式推荐 (Generative Recommendation) 工业界深度 Survey

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

process verifier 从 train-time process supervisor 继续分叉到 test-time search controller 的公开入口。

核心判断

PROMISE 的关键不是“再加一个 reward model”，而是把 process verifier 放进解码搜索期

PROMISE 最值得记住的一点，不是它也用了 PRM。

真正的重要信息是，它先把生成式推荐里的一个老问题单独命名了出来：

Semantic Drift

论文 2.4 节写得很直接。

在 hierarchical Semantic ID 生成里，前几步 token 并不是普通文本 token，而更像粗粒度语义锚点。 如果早期 token 先偏了，后面所有更细的 token 都会在错误语义子空间里继续细化，最后把整条路径带到不相关 item cluster。

而且 PROMISE 还把这个问题和推荐场景里的另一个副作用绑在了一起：

一旦进入 OOD 中间状态，模型更容易回退到训练数据的边际分布，从而放大 popularity bias

这意味着它要修的，不是传统训练损失本身，而是：

推理时怎样尽早发现并截断错误路径

所以 PROMISE 的 process reward model 从一开始就不是被当成“训练末端再打一次分”的东西。 它被设计成解码期的实时控制器。

Path-level PRM 虽然在训练，但它真正服务的是推理时的路径筛选

这篇 paper 的第二个要点，是 PRM 的训练目标和消费位置不能混在一起理解。

从 3.2 节和 Figure 2 看，PROMISE 确实会训练一个 Path-level PRM：

  1. 它在不同 path depth 上采样正负路径
  2. 用 InfoNCE 拉开正确 SID path 与错误 path 的分数差
  3. 让 PRM 学会判断“当前这条中间路径是不是还在对的语义子空间里”

这件事本身已经比普通 teacher-forcing backbone 更接近真实推理分布，因为 PRM 会看到 sampled trajectories 里的错误状态，而不是只看 ground-truth 前缀。

但更值得记住的是：

它不是为训练而训练，而是在为推理时的剪枝提供密集信号

这点和上一轮的 VRec 很不一样。

VRec 更像把 verifier 放进 reasoning loop，当作中间步骤的 process supervisor。

PROMISE 则是让 verifier 在解码期直接决定：

哪些候选分支值得继续展开，哪些分支应该立即砍掉

也就是说，同样叫 process verifier，它已经开始出现不同 consumer：

  1. train-time process supervisor
  2. test-time search controller

PRM-guided Beam Search 才是这条线真正新增的系统位置

把 PROMISE 放回 Story Lab 现在的框架里，它最重要的新位置其实不是 PRM 三个字，而是：

PRM-guided Beam Search

论文 Figure 2 和 3.3 节都写得很清楚：

  1. decoder 在每一步先放出更大的候选集合 K+
  2. Path-level PRM 对这些中间 SID path 打分
  3. 再从中选出更小的 K' < K+ 继续下一步自回归生成

这和粗暴放大 global beam size 不是一回事。

传统 beam search 只是让 decoder 自己多算几条分支。 PROMISE 则是在 decoder 外面再加一层轻量 verifier，让它专门负责：

把错误但高频、错误但看起来局部合理的分支提前剪掉

因此它修的核心问题也不是一般意义上的“搜索不够大”，而是：

搜索预算该怎样被 process reward 重新分配

这条判断对后面的统一方法表很关键，因为它说明推荐里的 reasoning supervision 已经不能只按“有没有 verifier”来记了，还得单独记：

verifier location / reasoning supervision mode

至少先区分：

  1. train-time process supervisor
  2. test-time search controller
  3. joint train+test consumer

这条线的核心收益，不是多一个模块，而是把 test-time scaling 正式带进推荐

PROMISE 另一个必须记下来的点，是它不是把 PRM 当作纯精度插件。

它真正主打的是：

test-time scaling laws for generative recommendation

论文 4.5 和 4.6 节给出的结论非常明确：

  1. 当 K+ 逐步放大时，Path-level PRM 能从更大的候选池里挑出更优路径
  2. 在保持 global beam size K = 1000 不变时，指标仍能显著提升
  3. K+ = 6000 时，工业数据上的 HRecall@3@1000 从 baseline 的 22.98% 提到 36.37%
  4. 额外增加的计算主要落在轻量 PRM，而不是 decoder 本体

更重要的是，论文 4.6.1 还直接把它和 parameter scaling 对比：

在相同 FLOPs 下，test-time scaling 更高效；达到同等效果时，所需 FLOPs 更低

这让 PROMISE 的位置一下就和一般的推荐 paper 拉开了。

它不只是说“再加一个 process reward，指标更好了”，而是在说：

生成式推荐也开始长出自己的 test-time compute 路线

这条线和 OneRec / OneRec-V2 的 parameter scaling、和 VRec 的中间 verification 不是替代关系，而是新的对照维度。

这不是纯论文技巧，它已经被写成了可部署的工业搜索策略

PROMISE 还有一个特别容易被忽略、但其实很重要的事实：

它不是只停在离线实验。

论文 4.3 节明确写到，它在 Kuaishou 和 Kuaishou Lite 上做了 7 天 A/B 测试。 控制组用传统 beam search，实验组用 PRM + PRM-guided search。

正文点名给出的线上结果至少包括：

  1. Kuaishou Lite 的 total app usage time 提升 0.131%
  2. app usage time per user 提升 0.160%

而且 5 节的 deployment 描述也很关键。

线上部署版本不是无限堆算力，而是：

  1. 只用 one PRM block
  2. 在线把 K+ 设成 4000
  3. 用 Radix Top-K 优化放大的候选集合筛选
  4. 最终总参数只比无 PRM 版本增加 15%
  5. 推理延迟只增加 10%

这说明 PROMISE 的真正系统价值，不在“理论上可以做 process reward”，而在：

它已经把 verifier 写成了一个工业上可落地的搜索控制层

当前公开边界仍然偏弱：paper 已有，稳定官方仓仍未出现

尽管这条线的工业信号很强，但它的公开边界当前并不强。

这一轮我按四组关键词追了 GitHub API：

  1. 论文全标题
  2. 缩写 PROMISE
  3. arXiv id 2601.04674
  4. PROMISE + Kuaishou + recommendation

截至 2026-03-21，都还没有看到能稳定对上的官方代码仓。

这意味着它和 RecThinker / DeepRec / GRSU 这类已公开 workflow 的路线不一样。

更准确的记法应该是：

industrial paper-first route

而不是“已有 repo、只是不够好找”。

中文传播层已经开始注意到它，但稳定高价值 xhslink 仍然缺位

传播层这边，这轮至少能稳定回溯到一条高价值中文入口：

Recsys Frontier 的生成式推荐工业综述

正文目录已经把它单独列成：

转折点 5：PROMISE — GR 的 Test-Time Scaling (2026)

这说明中文高质量工程讨论层已经开始把它视作生成式推荐时间线上的独立节点，而不是普通论文列表里的一个名字。

但另一方面，我继续补做：

  1. PROMISE 生成式推荐
  2. site:xiaohongshu.com PROMISE 生成式 推荐
  3. xhslink PROMISE 生成式 推荐

截至 2026-03-21，仍然没有拿到稳定高价值的 xhslink。

所以这条线当前仍然应该完全以论文和官方公开边界为准，中文传播层只适合做辅助导航。

证据与来源

  • PROMISE: Process Reward Models Unlock Test-Time Scaling Laws in Generative Recommendations：arXiv 摘要主入口。2026-01-08 提交，摘要已经把 Semantic Drift、Path-level PRM、PRM-guided Beam Search、test-time scaling 与 offline/online 验证一次写清。
  • PROMISE arXiv HTML：正文细节的关键入口。2.4 节正式定义 Semantic Drift，3.2-3.3 节写出 Path-level PRM + PRM-guided Beam Search，4.5-4.6 节给出 K+ 扩张、HRecall@3@1000、FLOPs 对比与 test-time scaling 结论，5 节则给出线上部署时 K+ = 4000、Radix Top-K、+15% 参数与 +10% 延迟。
  • 生成式推荐 (Generative Recommendation) 工业界深度 Survey：当前能稳定回溯到的中文高价值讨论层入口。目录已把 PROMISE 单列为“转折点 5：PROMISE — GR 的 Test-Time Scaling (2026)”，说明中文工程讨论层已经开始把它视作方法论节点。
  • GitHub API 检索 PROMISE / 论文全标题 / arXiv id 2601.04674 / PROMISE + Kuaishou + recommendation：截至 2026-03-21，仍未看到稳定官方仓，因此当前公开边界更适合写成 paper-first。
  • 公开网页检索 site:xiaohongshu.com PROMISE 生成式 推荐 与 xhslink PROMISE 生成式 推荐：截至 2026-03-21，仍未找到稳定高价值 xhslink。

下一步

  • 在已补 VRec / PROMISE 的基础上，继续沿 REG4Rec / GREAM 往下补完 reasoning supervision / process verifier 观察线，明确区分 reason-verify-recommend、PRM-guided beam search、self-reflection pruning 与 verifiable RL reward 四类接口。
  • 把统一方法表里的 reasoning 观察维度补成两列：process verifier location 与 reasoning supervision mode，避免再把 VRec 与 PROMISE 混写成同一种 verifier。
  • 继续跟踪 PROMISE 是否出现稳定官方 repo；如果后续补出训练脚本或部署细节，再把它从 paper-first 修正到更细的 workflow 边界。
  • 继续追中文高价值讨论与可复用 xhslink；在拿到稳定一手链路之前，不让传播层材料覆盖事实判断。