RISER 到 V-STAR：生成式推荐里的 RL，开始直接改写搜索预算和比较信号

背景

补完 LERL / MiniRec / GRC 之后，我原本已经把 2026 年初这一批公开 LLM-RL 推荐工作先理解成三种系统瓶颈：

  1. LERL 处理 action-space planning
  2. MiniRec 处理 training-cost efficiency
  3. GRC 处理 trajectory correction

但这轮继续用本地 search-layer 做增量检索，再回到 arXiv HTML、中文高价值日报和 GitHub API 核验后，我发现还有一类瓶颈正在被单独写出来，而且它比“要不要 Long CoT”“要不要 reflection”更贴近生成式推荐的训练本体。

这次最值得补进 Story Lab 的两篇新论文是：

  1. Towards Sample-Efficient and Stable Reinforcement Learning for LLM-based Recommendation
  2. Spend Search Where It Pays: Value-Guided Structured Sampling and Optimization for Generative Recommendation

把它们放在一起后，我更明确地觉得，下一张系统瓶颈观察表不能只停在前三列了。

核心判断

RISER 和 V-STAR 说明，新矛盾正在从“有没有 RL”转向 search-credit coupling

这两篇方法看起来都还属于生成式推荐里的 RL 微调。

但它们真正盯住的，并不是：

  1. 再换一个 optimizer 名字
  2. 再补一种 reward 来源
  3. 再把解码轨迹拉长一点

它们盯住的是一个更底层、也更工程化的问题：

搜索过程怎样影响最终 reward，而 reward 又怎样反过来给搜索过程提供有效比较信号

我更愿意把这类问题记成：

search-credit coupling

也就是：

  1. search budget 花在什么分支
  2. 哪些 rollout 真正带来可学习信号
  3. advantage 应该在什么粒度上比较
  4. latency 预算、探索空间和 credit assignment 怎样一起耦合

如果不把这列单独拆出来，RISER、V-STAR 和此前的 GRC 很容易又被粗糙地写成同一类“推荐里的 RL 优化”。

RISER 的关键不是再给推荐补 Long CoT，而是直接反对这条迁移路径

RISER 的摘要从一开始就把态度说得很直白。

论文认为，在 LLM 里越来越常见的 Long CoT 推理链，并不适合直接拿来提升 sequential recommendation。作者给出的理由有两个：

  1. Long CoT 带来过高的 inference latency
  2. 用户行为序列本身并不显式包含那种可被长推理链稳定触发的 cognitive reasoning pattern

这点很重要。

因为它不是在说“Long CoT 还不够好”，而是在说：

推荐里更值得迁移的不是更长的 reasoning trace，而是其背后的 RL exploration 机制

所以 RISER 干脆把问题重写成：

  1. 不再围着 CoT 结构转
  2. 直接让 RL 去探索 item space
  3. 再解决这种探索本身的两个核心副作用：低样本效率与训练不稳定

这和我前面已经记录过的 MiniRec 形成了一个很好的对照。

MiniRec 更像在问：

RL 预算太贵，哪些样本值得训练

而 RISER 更像在问：

rollout 已经采出来了，但大多数都没法转成有效学习信号，怎么办

RISER 真正补的，是“怎样把零优势 rollout 也变成可学信号”

我觉得 RISER 最值得记住的创新，不是它又堆了几条 stabilization trick，而是它对“无效 rollout”这件事的处理。

论文摘要和 HTML 都明确写到：

  1. 直接上 RL 会遇到低 sample efficiency
  2. 大量 rollout 不提供有效 learning signal
  3. 它们中的一部分是 zero-advantage trajectories

作者的做法不是把这些轨迹简单丢掉。

相反，它们被通过 SimPO 回收成 pairwise preference data，用来继续训练。这意味着 RISER 在系统层面做的，其实是：

把本来几乎没有梯度价值的 rollout，重新加工成可比较、可消费的偏好信号

这对 Story Lab 很关键，因为此前我们主要把 preference constructor 写在：

  1. DPO4Rec
  2. ECPO
  3. LettinGo

这些更显式的 preference alignment 路线上。

而 RISER 说明，在生成式推荐的 RL 本体里，preference construction 其实也可能长在训练循环内部，专门负责回收低价值 rollout。

RISER 的稳定性设计，本质是在防止 policy 过早塌到热门 item

RISER 另一半工作是稳定训练。

它在 HTML 版里把这部分拆得很清楚：

  1. oversampling + de-duplication
  2. certainty-aware mask
  3. KL-Cov

其中最值得写进 Story Lab 的判断，不是名字本身，而是这些策略共同服务的目标：

防止训练过早塌到少数高频 item，并把探索空间重新打开

论文的分析段落直接把这个问题和 popularity bias 连在一起。它还专门做了 popular / unpopular item 分组分析，在 Games 数据上给出一个很醒目的结果：

unpopular group 的 HR@10 提升 126.1%，NDCG@10 提升 184.6%

这说明 RISER 的稳定性不是纯数值稳定，而是和 long-tail exploration 直接绑在一起。

所以这条线更准确的定位不是“又一个更稳的 GRPO”。

它更像：

item-space exploration + rollout recycling + anti-collapse stabilization

V-STAR 则把问题继续往前推到 search policy 本身

如果说 RISER 主要处理的是：

采样之后，怎样让 rollout 更可学

那么 V-STAR 更前一步。

它直接指出，生成式推荐里的 RL 微调可能在 search 阶段就已经歪掉了。

论文摘要把这个矛盾写得很干净：

probability-reward mismatch

更具体地说，likelihood-dominated decoding，例如传统 beam search，会导致两类失败：

  1. insufficient exploration

高回报但低概率的分支会过早被剪掉

  1. advantage compression

大量 trajectory 共用高概率前缀，最后 reward 很接近，within-group variance 太低，导致比较信号变弱

这比“beam search 不够好”更严重。

因为它意味着：

reward 并不是在一个中性的 search process 上被观察到，而是已经被 probability-biased decoding 预先塑形了

这就是为什么我觉得 V-STAR 很值得单独记。

它不是在一般意义上优化 search，而是在重写：

search 和 reward comparison 之间的接口

V-STAR 给出的答案，是把搜索预算和 advantage 都贴到 decisive branching decisions 上

V-STAR 的结构有两部分，而且两部分是连起来的。

第一部分是 VED，也就是 Value-Guided Efficient Decoding。

它不是穷举整棵树，而是：

  1. 找 decisive nodes
  2. 有选择地加深高潜力前缀
  3. 在不做 exhaustive tree search 的前提下，提高 exploration efficiency

第二部分是 Sibling-GRPO。

它利用前面诱导出来的 tree topology，在共享前缀的 sibling nodes 之间做相对 advantage 计算，把学习信号集中到真正决定分支走向的节点上。

这件事对 Story Lab 很关键，因为它说明推荐里的 GRPO 也开始显式分叉了：

  1. Rank-GRPO 把优化单位往 rank-level 推
  2. GRC 把 GRPO 压进 Generation -> Reflection -> Correction 轨迹
  3. V-STAR 则把比较粒度压到 sibling-relative branching decisions

也就是说，推荐里的 GRPO 已经不再只是一个统一大类，而是在被不同系统瓶颈重新塑形。

V-STAR 比 RISER 更进一步的地方，是它给出了线上商业验证

V-STAR 的 abstract 只写了 offline 和 online datasets。

但 arXiv HTML 版的 5.3 Online Performance 把工业验证写得更具体：

  1. 在线 A/B 运行 5 天
  2. 流量规模是微信视频号 5% live request traffic
  3. 主指标 GMV 相对 BeamSearch++ + GRPO 提升 1.23%
  4. GMV-Normal 提升 1.87%

这说明它不是普通的 decoding trick。

更准确地说，它是在：

严格 latency 约束下，把 candidate construction 和 RL credit assignment 一起改写成更适合商业目标的形态

所以如果只把它写成“又一个 GRPO 变体”，会明显低估它。

两条线合起来，逼着我们把系统瓶颈表补成四列

把 LERL / MiniRec / GRC / RISER / V-STAR 放回同一张图里之后，我现在更愿意把系统瓶颈表先写成这四列：

  1. action-space planning
  2. training-cost efficiency
  3. trajectory correction
  4. search-credit coupling

它们大致对应：

  1. LERL
  2. MiniRec
  3. GRC
  4. RISER / V-STAR

其中第四列的共同主题不是“搜索更准”这么简单，而是：

search budget、rollout reuse、relative advantage 和 latency constraint 必须联动设计

这也意味着，后续如果还补到新的生成式推荐 RL 工作，我不该再只问：

  1. 用了什么 optimizer
  2. reward 从哪里来
  3. 优化单位是什么

还得多问一层：

它到底是在改 search，还是在改 reward comparison，还是同时改两者的耦合方式

公开边界

这轮我也专门核了两条线的公开边界。

更稳的结论是：

  1. RISER 的 arXiv 页面和 HTML 页面都稳定可访问，论文提交时间是 2026-01-31
  2. 论文正文挂出了匿名 4open 代码口，但它当前仍不适合被记成稳定署名仓
  3. V-STAR 的 arXiv 页面显示 2026-02-11 首次提交，2026-02-12 更新到 v2
  4. 按 V-STAR Sibling-GRPO recommendation、Spend Search Where It Pays recommendation、RISER recommendation SimPO GRPO 和两篇论文全标题去检 GitHub API，截至 2026-03-21，返回的 repository count 都是 0

因此这两条线当前更适合被记成：

  1. paper with anonymous code pointer
  2. paper with industrial evidence but no stable public repo

而不是已经开放成可复查底盘。

中文传播层到哪一步了

这轮中文传播层比前几轮稍微好一点，至少能拿到两篇比较稳定的中文高价值日报入口：

  1. 推荐算法日报 - 2026-02-03
  2. 推荐算法日报 - 2026-02-12

前者对应 RISER，后者对应 V-STAR。

它们的价值不在于替代论文，而在于把中文传播层终于从单纯搬标题，推进到能明确点出：

  1. Long CoT 错配
  2. SimPO / KL-Cov
  3. probability-reward mismatch
  4. VED / Sibling-GRPO
  5. 微信视频号 GMV 提升

但小红书层仍然很弱。

我这轮继续用本地 search-layer 跑了：

  1. site:xiaohongshu.com RISER 推荐 强化学习
  2. site:xiaohongshu.com V-STAR 推荐 强化学习
  3. xhslink RISER 推荐
  4. xhslink V-STAR 推荐

结果主要是噪声，尤其 RISER 这个词在英文里和楼梯踏步混用严重，返回的大量结果都是楼梯施工视频或无关页面，没有形成可复用的稳定 xhslink。

所以截至 2026-03-21，这条支线仍然应以 arXiv 和中文高价值日报为主，而不是让小红书传播层主导事实判断。

证据与来源

下一步

  • 把 LERL / MiniRec / GRC / RISER / V-STAR 压到同一张系统瓶颈表里，把第四列正式写成 search-credit coupling。
  • 把 V-STAR 和 Rank-GRPO / GRC 放在一起看，继续细分 recommendation 里的 GRPO 是按 rank、按 trajectory 还是按 sibling branch 比较优势。
  • 继续追 RISER 的匿名 4open 代码口会不会转成稳定署名仓，同时继续追 V-STAR 有没有对外开放实现。