推荐后训练开始分化成三条公开路线

背景

过去几轮 Story Lab 主要沿着快手主线往下拆：OneRec 证明端到端生成式推荐能上线，OneRec-V2 把真实用户反馈重新接回后训练，OneRec-Think 把显式推理和推荐 reward 推到台前，OpenOneRec 则逐步把 benchmark、模型和 verl_rl 工程栈公开出来。

这条主线当然重要，但它也容易制造一个错觉：好像“推荐后训练”已经收敛成一条单线，只是公开程度不同。

这轮补检之后，我不再这么看。

Large Language Models for Generative Recommendation: A Survey and Visionary Discussions 给了一个很好的框架：当推荐问题从多阶段 score + rerank 改写成“直接从 item pool 生成目标 item”之后，真正要重新设计的，不只是模型结构，还包括后训练本身。

而截至 2026-03-20，公开论文其实已经把这层后训练拆出了至少三条不同路线：

1. DPO4Rec：离线 rerank 对齐
2. ECPO：多轮对话里的 turn-level 对齐
3. ReRe：生成式推荐里的 RLVR / GRPO

如果不把这三条线分开看，就很容易把 OneRec-V2、OneRec-Think 和 OpenOneRec 的位置也一起看糊。

核心判断

我这一轮最重要的新判断是：

推荐里的偏好优化，公开层面已经不是“一种 RL 思想在不同论文里重述”，而是至少分化成了三种优化单位完全不同的后训练路线。

它们的差别，不只是名字不同，而是优化对象、反馈来源、适用场景都不同。

第一条：DPO4Rec 更像离线 rerank 对齐

Direct Preference Optimization for LLM-Enhanced Recommendation Systems 解决的问题，不是“怎样把推荐系统彻底改成 on-policy RL”，而是“怎样把 LLM 的推理和推荐器的偏好更稳地对齐起来”。

它的路径很典型：

1. 先让 LLM 根据用户历史交互生成偏好解释；
2. 再用推荐 reward model 评估这些解释对推荐效果有没有帮助；
3. 从 N 个样本中挑出最好和最差的一对，构造 chosen / rejected；
4. 最后用 DPO 去做结构对齐。

这条线的关键特征是：它仍然高度依赖离线样本构造和 reward model 评分。

所以 DPO4Rec 的价值，不是“它代表推荐 RL 的终局”，而是它把推荐领域里一个很常见的现实问题讲清楚了：

在很多场景里，第一步并不是直接上 on-policy RL，而是先把 LLM 输出和推荐偏好对齐到足够稳定、足够可控。

从这个意义上说，DPO4Rec 更像推荐里的“偏好蒸馏 / 偏好整形”路线。它适合 LLM-enhanced reranking，但还不是最接近 OneRec-V2 或 OpenOneRec/verl_rl 的那条路。

第二条：ECPO 解决的是多轮对话里的 turn-level 对齐

Expectation Confirmation Preference Optimization for Multi-Turn Conversational Recommendation Agent 则是另一类问题。

它关注的不是单次 rerank，而是多轮对话推荐 agent 为什么会“短视”：每一轮回复看起来都还行，但整段对话却没能持续引导用户、也没能稳定满足用户预期。

这篇论文的核心点有两个。

第一，它不是简单把每一轮对话都当成同权训练样本，而是用 Expectation Confirmation Theory 去显式建模用户满意度如何在多轮对话中变化，并找出“不满意是怎么产生的”。

第二，它想避免此前 MTPO 方法里很重的 tree simulation 成本。论文明确指出，很多 turn-level 偏好关系如果靠每一轮扩树采样再整段回放，会有显著采样开销，而且对中间轮次的偏好关系并不稳。

所以 ECPO 的路线是：

1. 追踪满意度变化，
2. 对不满意回复做定向改写，
3. 构造 turn-level preference pair，
4. 再做偏好优化。

为了支撑这条线，它还专门做了 AILO 用户模拟器，用 Activities / Interests / Language / Orientations 四维 persona 去生成更像真实用户的多轮反馈。

这意味着 ECPO 补的是“对话推荐 agent 的多轮对齐”问题。它当然属于推荐后训练，但它的优化单位已经从“候选 item 或 rerank 输出”变成了“对话中的某一轮回复”。

所以把它和 DPO4Rec、ReRe 混成一类，会丢掉一个很重要的结构差异：

ECPO 的主战场是 CRA，而不是广义生成式推荐里的 item generation。

第三条：ReRe 才更像公开的推荐 RLVR 主线

如果说前两条路线都还带着明显的“离线对齐”味道，那 Reinforced Preference Optimization for Recommendation 就更接近我真正想找的那层：推荐里的公开 RLVR。

这篇论文最重要的地方，不只是提出了一个新名字，而是它把推荐场景里的 RLVR 障碍拆得很实：

1. 高质量负样本不够；
2. 训练还大量依赖 implicit reward；
3. item generation 空间很窄，容易重复、无效，采样效率低；
4. 大量未观测 item 都被压成同一个零分，ranking supervision 太稀。

它给出的解法也更像真正的推荐 RL 训练设计，而不是只是“再做一次 preference pair 构造”：

1. 用 constrained beam search 和动态采样，让生成过程更容易拿到有效且更难的负样本；
2. 用 rule-based accuracy reward 保持可验证性；
3. 再叠一层 auxiliary ranking reward，把“负样本之间并不等价”这件事显式写进奖励。

更关键的是，论文 Figure 2 直接写明：模型是根据这些 reward 计算 advantage，再通过 GRPO 更新。

也就是说，这篇工作不是抽象说“推荐也可以做 RLVR”，而是真的把：

generation -> sampling -> reward -> GRPO update

这条链条连了起来。

它的公开仓库 ReRe 也进一步强化了这个判断：README 直接列出 rere.py 和面向推荐的 rere_trainer.py，后者明确写成了 recommendation-tailored GRPO trainer。

对 Story Lab 来说，这一点很关键。因为在公开世界里，ReRe 比很多“只在论文里提到 RL”的工作更接近真正可追踪的推荐后训练样板。

这三条线怎样重新安放快手主线

把这三条路线画出来以后，快手主线的位置反而更清楚了。

OneRec-V2

OneRec-V2 更像工业真实反馈对齐路线。它关心的是：真实用户反馈怎样重新进入生成式推荐后训练，而不是只靠 reward model 代理。

这和 DPO4Rec 的离线 pair 对齐、ECPO 的多轮满意度建模、ReRe 的公开 RLVR 设计都有关，但不等价。

OneRec-Think

OneRec-Think 更像“推理推荐 + reward 设计”路线。论文已经把 VERL + GRPO + Rollout-Beam reward 写到 paper-level 细节，但公开仓库还停在 reasoning activation。

所以它和 ECPO 一样，都说明“优化单位”未必只是 item；但它公开出来的训练入口仍没有 ReRe 这么完整。

OpenOneRec

OpenOneRec/verl_rl 更像工程底盘。

它当前公开的是推荐 GRPO + verl 的工程路径，而不是把工业论文里的所有算法口径一比一抹平。因此横向看，它在工程形态上比 DPO4Rec 更接近 ReRe，但在数据、benchmark 和多模块协同上又更像一套更大的基础设施。

为什么这轮判断对项目重要

这会直接改变 Story Lab 后面怎么写 “LLM-RL 协同推荐”。

如果没有这张横向方法图，我们很容易把所有工作压缩成一句话：

“大家都在研究推荐里的 RL 和偏好优化。”

但现在更准确的写法应该是：

1. 有些工作在做离线偏好对齐，比如 DPO4Rec；
2. 有些工作在做多轮对话里的 turn-level 对齐，比如 ECPO；
3. 有些工作开始把 RLVR / GRPO 直接接进生成式推荐，比如 ReRe；
4. 工业主线则在这些路线之上，再叠真实用户反馈、显式推理和工程底盘。

这四层不分开，后续就很难把 reward design、negative sampling、reasoning reward 和真实反馈对齐这些问题真正讲清楚。

证据与来源

• Large Language Models for Generative Recommendation: A Survey and Visionary Discussions：把生成式推荐定义成“从 item pool 直接生成推荐”的单阶段问题，是这轮横向方法图的框架锚点。
• Direct Preference Optimization for LLM-Enhanced Recommendation Systems：v2 摘要和 HTML 明确写出 reward model -> chosen/rejected -> DPO 路线；实验部分使用 ML-1M / Amazon-Books / Amazon-Beauty，并报告在 ML-1M 上相对 MAP@5 提升约 1.35%-1.45%。
• Expectation Confirmation Preference Optimization for Multi-Turn Conversational Recommendation Agent：ACL Anthology 摘要和 PDF 都明确写出它要解决的是多轮对话中的 turn-level preference optimization，并通过 AILO 模拟用户反馈与 expectation confirmation。
• Reinforced Preference Optimization for Recommendation：摘要明确把问题钉在 high-quality negatives 与 implicit rewards；HTML 进一步写出 Figure 2 中模型通过 reward 计算 advantage，再用 GRPO 更新，并在 Amazon Toys / Amazon Industrial / Yelp 上报告相对提升。
• ReRe GitHub：README 直接暴露 rere.py、rere_trainer.py、rere.sh 和 evaluation.sh，表明这条推荐 RLVR 路线已经公开到代码级。
• From OneRec to RL：已有中文工程笔记已经开始把 ECPO 和 GBPO 拉进同一条中文 RL 叙事，但这类来源只适合做传播层对照，不替代一手论文。

下一步

• 把 DPO4Rec / ECPO / ReRe / OneRec-V2 / OneRec-Think / OpenOneRec 进一步压成一张“优化单位 × 反馈来源 × reward 类型 × 公开程度”的方法表。
• 继续追 ReRe 代码实现细节，尤其是它的 recommendation-tailored GRPO trainer 与 OpenOneRec/verl_rl 在 sampling / reward 设计上的差异。
• 继续检索中文高价值帖子与稳定 xhslink，但截至这一轮，围绕 ReRe / ECPO 的中文讨论仍明显少于快手主线，尚未形成足够强的一手传播链。