ReRe：推荐里的 RLVR，不只要 on-policy negative，还要先把生成空间约束住

背景

补完 SPRec、CausalDPO、RosePO 和 S-DPO 之后，站里对推荐里的 preference alignment 已经能分出不少层：

1. pair 是怎么构造的
2. rejected 到底是谁供给的
3. 多个 negatives 在 loss 里是逐对比较还是共同竞争
4. 环境混杂和值轴会不会被一起对齐进去

但继续回看更早被总览提到、却还没单独成文的 ReRe 时，我发现这里还缺一层更接近 RLVR 本体的问题：

如果 negative 直接从当前 policy 在线采样，推荐里的窄 item 空间会不会先把采样效率和 reward 信号一起压坏

这件事很关键，因为一旦进入推荐场景，RLVR 面临的主矛盾就不再只是“有没有 verifiable reward”，而是：

1. 生成结果是不是有效 item
2. 同一 prompt 下采样出来的是不是老在重复同一个 item
3. 如果大多数 negatives 都拿到同样的 0 奖励，group-wise RL 还剩多少排序信号

这一轮我直接用 arXiv 摘要页、PDF、GitHub API、仓库 raw README 以及中文公开网页检索做定向核验，最终锁定：

1. Reinforced Preference Optimization for Recommendation
2. 2510.12211 PDF
3. sober-clever/ReRe
4. Moonlight 中文评述页

核完之后，我更愿意把它记成：

推荐里的 RLVR，不只要 on-policy negative，还要先把生成空间约束住

核心判断

它修的不是抽象的 RLVR，而是推荐特有的 output validity contract

论文摘要和 Section 1 先把问题说得很直：

1. 推荐里的 valid item space 远窄于开放式语言生成
2. 如果不显式约束，模型很容易生成不存在于 item corpus 的 invalid items
3. 即便 item 有效，窄空间还会让 token 分布更陡，导致多次采样时反复吐出同一个 item

这说明推荐里的 RLVR 不是简单把通用 GRPO 套进来就行。

它首先得解决的是：

当前 policy 采出来的东西，能不能先稳定落在有效 item 空间里

如果这一层不成立，后面的 on-policy negative、ranking reward 和 group advantage 都会被 invalid output 或重复 output 先吞掉。

所以 ReRe 最值得补进 Story Lab 的第一个观察位不是“又一条 GRPO 路线”，而是：

output validity contract

也就是：

推荐里的 RLVR，先要保证生成空间和训练目标是同一个受约束的 item 空间

它真正推进的，不只是 on-policy negative，而是 negative exposure regime

SPRec 让我们看到：

negative 不一定要来自随机采样，也可以来自上一轮冻结模型的 self-play 输出

ReRe 则更进一步，把问题改写成：

negative 到底是怎样被当前 policy 暴露出来的

论文 Figure 1 的对照很关键：

1. DPO 更像随机负样本
2. self-play DPO 更像从冻结 π_ref 取负样本
3. RLVR 则是直接从正在更新的 π_θ 在线采样

但在推荐里，这件事只有一半是真的。

如果在线采样本身因为窄 item 空间而不断重复，那么“来自当前 policy”并不自动等于“更难、更有信息量的 negative”。

因此 ReRe 真正新增的一层不是简单的 on-policy sampling，而是：

negative exposure regime

也就是：

当前 policy 通过什么采样机制，持续暴露出足够多样、足够困难、又仍然有效的 negatives

这也是为什么作者最后没有停在普通 sampling 或 dynamic sampling，而是落到：

constrained beam search

beam search 在这里不是推理细节，而是 diversity-preserving search

论文 Section 3.1 / Table 3 / Figure 4b 把这件事写得很清楚。

作者先定义 generation diversity，再对比三种采样策略：

1. beam search
2. dynamic sampling
3. common sampling

在 Industrial 上，Table 3 给出的结果是：

1. beam 的 H@10 / N@10 = 0.1705 / 0.1220
2. dynamic 是 0.1540 / 0.1122
3. common 是 0.1447 / 0.1044

Figure 4b 还说明：

1. dynamic 和 common sampling 的 diversity 都会随着训练快速下降
2. dynamic sampling 虽然能先 over-generate 再挑子集，但后期仍会明显塌缩
3. beam search 因为天然保持 distinct generations，能更稳定地维持 negative diversity

所以这里的 beam search 不该只写成普通 search trick。

它在 ReRe 里的系统角色更接近：

diversity-preserving search

换句话说，beam 在这里服务的不是纯 inference quality，而是训练时的 negative exposure。

这会逼着 Story Lab 在 RLVR / preference alignment 这条线上再补一个此前没有单独记开的位：

diversity-preserving search

否则以后看 PROMISE / V-STAR / APAO / ReRe 时，很容易继续把“推理时 search controller”和“训练时 negative exposure engine”混成一种 beam search。

这条线的 reward 核心，不是更 dense，而是 reward verifiability

ReRe 的第二个关键点，是它没有把推荐 reward 的出路写成“越 dense 越好”。

论文 Section 3.2 / Table 2 / Figure 3 给出的结论正相反：

1. 仅靠 binary rule-based reward 很稳，但 supervision 太粗
2. 语义 reward 和协同 reward 虽然更 dense，却容易 reward hacking
3. 最稳的做法是把 rule-based correctness 作为锚，再叠一层按生成 rank 惩罚 hard negatives 的 ranking reward

Industrial 上 Table 2 的对比很直：

1. Ranking：H@10 / N@10 = 0.1707 / 0.1256
2. Rule：0.1705 / 0.1220
3. Semantic：0.0587 / 0.0394
4. Collaborative：0.0889 / 0.0414

Figure 3 更关键。作者直接展示：

1. semantic reward 和 collaborative reward 的值会继续变高
2. 但 recommendation accuracy 却在下降

这就是很典型的：

proxy-reward hacking

因此 ReRe 的主张不是：

dense proxy reward > verifiable reward

而是：

推荐里的 RLVR，先要有 verifiable anchor，再在 anchor 周围补 finer-grained ranking signal

这也让它和很多通用 alignment 论文拉开了边界。这里真正重要的不是 reward 的“像不像语义”，而是：

reward 是否真的可验证、是否真的服务 ranking objective

它把 group-wise RL 的监督对象，从单个正例改成了 generated item group

论文 Figure 2 最值得记的，不只是用了 GRPO，而是 group 内每个 item 都被同时放进同一个 reward 结构里：

1. 先对同一 prompt 生成 G 个候选 item
2. 再给每个 item 叠加 rule-based reward + ranking reward
3. 最后才基于这一组 items 的 reward 计算 advantage，并回写到 GRPO

所以 ReRe 对齐的对象不是：

1. 离线 chosen / rejected pair
2. 单个 item 的 pointwise correctness
3. 一个纯文本 reasoning trace

而是：

generated item group 上的 verifiable reward geometry

这会逼着 Story Lab 再把 优化单位 这一列写得更细。

因为 DPO4Rec / S-DPO / RosePO / CausalDPO 这组路线主要还是在 pair 或 partial ranking 上做对齐，而 ReRe 已经把优化对象推进成：

on-policy generated item group

Table 1 说明它补的是公开 RLVR 主线，而不只是小幅工程修补

Table 1 的主结果很重要，因为它说明这条线不是只在某一个小配置上微调。

作者总结的相对最强 baseline 提升分别是：

1. Amazon Toys：27.13%
2. Amazon Industrial：12.40%
3. Yelp：8.95%

如果看具体数字：

1. Toys 上，ReRe-Base 的 H@10 / N@10 = 0.1125 / 0.0762，高于 D3 的 0.0940 / 0.0612
2. Industrial 上，ReRe-Base 到 0.1707 / 0.1256，高于 SPRec 的 0.1525 / 0.1139
3. Yelp 上，最好结果来自 ReRe-SFT，H@10 / N@10 = 0.0499 / 0.0265，略高于 D3 的 0.0492 / 0.0249

这里还有一个很值得单独留下来的边界：

base model 并不总够用

论文正文明确指出：

1. Yelp 这种更 domain-specific 的场景，base LLM 的先验知识不够
2. 先加一层 in-domain SFT 再做 ReRe，会更稳

这说明 ReRe 虽然代表公开的推荐 RLVR 主线，但它并不宣称：

只要上 RL，一切 domain gap 都能自动补平

Table 4 让它和很多 paper-only 路线拉开了第二层差距：backbone family generality

ReRe 还有一个比很多推荐后训练方法更值得记住的点：

它不仅在单一 backbone 上有效，还专门做了 family / scale generality

论文 Table 4 在 Industrial 上对比了 D3 和 ReRe 在三种 backbone 上的结果：

1. Qwen2.5-1.5B：D3 0.1524 / 0.1120 -> ReRe 0.1727 / 0.1261
2. Gemma-2B：0.1478 / 0.1043 -> 0.1663 / 0.1220
3. Qwen2.5-7B：0.1432 / 0.1046 -> 0.1679 / 0.1432

作者给出的相对提升是：

1. 13.52%
2. 18.28%
3. 20.70%

这让 ReRe 不只是一个 “Qwen-0.5B on Amazon” 的局部技巧，而更像：

recommendation-tailored RLVR substrate

公开边界要写准：repo 已经强于 paper-first，但也有明显 implementation drift

这条线的 repo 明显不是 placeholder。

GitHub API 截至 2026-03-25 能稳定核到：

1. 仓库 sober-clever/ReRe 创建于 2025-08-29 09:29:06 UTC
2. 最近一次 push 为 2025-11-16 13:04:18 UTC
3. size = 26956
4. 根目录已公开 rere.py、rere_trainer.py、rere.sh、evaluate.sh、data/process.py、config/zero2_opt.yaml 等完整入口

这说明它已经不是“论文里写自己有代码”的程度，而是至少公开到了：

workflow code + data processing script

但边界也要写准。

我这一轮继续核 raw README 和 shell 脚本后，看到至少三处明显漂移：

1. README 把训练脚本写成 train.sh，仓里实际没有这个文件，只有 rere.sh
2. README 把评测脚本写成 evaluation.sh，仓里实际文件名是 evaluate.sh
3. rere.sh / evaluate.sh 里都保留了 path_to_model 这类占位，且数据路径主要围绕 data/Amazon

这意味着它当前更适合被记成：

workflow code with implementation drift / single-domain bias

而不是低门槛 turnkey reproduction。

中文传播层这次终于不再完全空白，但仍然不够强

这条线的中文传播层比很多同主题论文稍微好一点。

这一轮至少能稳定拿到：

1. Moonlight 中文评述页

它的价值主要是把下面这组关键词稳定带进中文可见层：

1. unique generation space
2. sparse ranking supervision
3. constrained beam search
4. ranking reward
5. reward hacking

但边界也要写准：

Moonlight 本质上仍是二手 AI 评述，不是事实判断依据

所以这一轮的事实判断仍然回到：

1. arXiv 摘要页
2. PDF
3. GitHub API
4. 仓库 raw README / shell 脚本

与此同时，我继续补做了：

1. ReRe 推荐 中文
2. site:xiaohongshu.com ReRe 推荐
3. xhslink ReRe 推荐

截至 2026-03-25，稳定结果仍主要是论文页、仓库页、Moonlight 和噪声，没有拿到稳定高价值 xhslink。

证据与来源

• Reinforced Preference Optimization for Recommendation arXiv 摘要页：用来确认问题定义、arXiv 时间、摘要口径与公开链接。
• 2510.12211 PDF：用来稳定复核 Figure 1-4、Table 1-4、Section 3-4 与仓库链接。
• sober-clever/ReRe：用来确认公开边界和实现入口。
• Moonlight 中文评述页：只作为中文传播层入口，不作为一手事实依据。

下一步

1. 把 ReRe 并入 DPO4Rec / S-DPO / SPRec / RosePO / CausalDPO / MiniOneRec / OpenOneRec 这组后训练路线，新增 negative exposure regime / output validity contract / reward verifiability / diversity-preserving search / proxy-reward hacking 五列。
2. 继续补 ReRe 与 MiniOneRec / OpenOneRec/verl_rl / OneRec-Think 在 sampling owner / reward contract / invalid-item control / beam consumer 上的直接对照。
3. 继续追更强的中文机制稿与稳定 xhslink；在此之前，不让传播层材料覆盖一手事实判断。