OneRec-V2 才是 OneRec 主线里的 RL 桥梁

这一轮检索里，最值得补进主线的不是又一篇外围综述，而是 OneRec-V2 Technical Report。

它在 2025-08-28 提交，2025-10-28 更新到 v4。如果上一轮把快手主线理解成 OneRec -> OneRec-Think -> OpenOneRec，这一篇说明中间其实少了一段非常关键的桥：工业推荐里的 RL 到底是怎么从“开始可用”推进到“更像 LLM 后训练”的。

为什么说它是桥梁，而不是附属版本

OneRec Technical Report 已经告诉我们，端到端生成式推荐可以重构传统级联系统，而且强化学习开始显示出显著潜力。但 OneRec-V2 Technical Report 直接把第一代系统的两个主矛盾说透了：

  1. 大量计算还耗在历史行为序列编码上，而不是生成本身。
  2. RL 主要依赖 reward model，和真实用户反馈之间仍有距离。

这两个判断很关键。它说明快手主线并不满足于“OneRec 已经上线”，而是很快把焦点转到了两个更硬的问题：

  1. 生成式推荐能不能像 decoder-only LLM 一样继续吃到 scaling benefit。
  2. 推荐里的对齐，能不能少绕一层 reward model，更多接入真实用户反馈。

所以 OneRec-V2 的意义，不只是“V1 的优化版”，而是把主线从“生成式推荐可行”推进到“生成式推荐怎样进行更像现代 LLM 的后训练”。

它把 RL 往前推了哪一步

这篇报告最值得记住的，不是参数量，而是它对 RL 的改造方向。

论文给出的做法很明确：

  • 架构上，改成 Lazy Decoder-Only Architecture，把总计算量再压低约 94%，训练资源降低约 90%，同时把模型扩到 8B
  • 对齐上，不再满足于只靠 reward model，而是引入基于真实用户交互的偏好对齐
  • reward 上，核心信号转向真实播放时长，并进一步做 Duration-Aware Reward Shaping
  • 优化上，提出 Gradient-Bounded Policy Optimization (GBPO)，去缓解传统 clipping 带来的样本浪费与训练不稳定

这里最重要的是第二点。过去很多人会把推荐里的 RL 理解成“用一个 reward model 做偏好对齐”。但 OneRec-V2 实际上在说：如果系统已经端到端生成、而且真实反馈足够密集，那么下一步最自然的事情，就是把真实用户反馈重新拉回后训练主循环。

这让它比 OneRec v1 更像今天常见的大模型后训练范式，也让 LLM-RL 协同推荐 这个项目目标变得更具体了。我们之后不该只问“有没有用 RL”，而该问：

  1. 用的是 reward model、规则 reward，还是直接用户反馈。
  2. reward 主要对齐点击、播放时长、合法率，还是更复杂的长期价值。
  3. policy optimization 的稳定性问题是怎么处理的。

它和 OneRec-Think 的关系，不是替代，而是分工

OneRec-Think: In-Text Reasoning for Generative Recommendation 在 2025-10-13 提交，2025-11-11 更新到 v2。它公开强调的是另一条线：

  1. Itemic Alignment
  2. Reasoning Activation
  3. Reasoning Enhancement

其中第三步明确写的是：设计 recommendation-specific reward，去处理推荐问题里的 multi-validity，也就是“多个答案都可能合理”的偏好多解性。

这说明 OneRec-V2 和 OneRec-Think 其实各自补的是两种不同的 RL 缺口：

  1. OneRec-V2 更像工业主场景里的真实反馈对齐，重点是让推荐后训练更贴近真实用户交互。
  2. OneRec-Think 更像显式推理推荐里的 reward 设计，重点是让 reasoning path 和推荐结果一起被优化。

如果把两篇放在一起看，会发现快手主线里的 RL 已经不是单一招式，而是至少分成了两类：

  1. 面向真实在线反馈的偏好对齐
  2. 面向推理质量与多解偏好的 reward 设计

这对 Story Lab 很重要，因为它提醒我们不要把所有推荐 RL 都混成一个抽象标签。

它和 OpenOneRec 的关系，是“工业闭环”对“公开入口”

OpenOneRec Technical Report 以及 OpenOneRec GitHub 让快手主线第一次具备公开 benchmark、公开 foundation model 和公开训练流程入口。

但如果把 OpenOneRec GitHub 的 README 和 roadmap 一起看，会发现它公开出来的是结构，而不是一套已经完全 turnkey 的 RL 复现包：

  1. README 把 post-training 写成多任务 SFT、on-policy distillation、RL
  2. Quick Start 仍写着 code release 和详细使用说明会持续补齐
  3. roadmap 里还明确把统一 VeRL 集成列成后续事项

这意味着 OpenOneRec 已经把“公开入口”打开了，但真正把工业 RL 细节完整外化，仍在路上。

也正因此，OneRec-V2 的位置变得更关键：它正好站在工业闭环和公开入口之间，告诉外部研究者这条主线真正把精力放在什么地方。

这会怎样改写我们对主线的理解

到这一轮为止，我认为 Story Lab 的主线应该从三层改成四层：

  1. OneRec：证明端到端生成式推荐在工业上成立
  2. OneRec-V2：把 RL 从 reward-model-only 推向真实用户反馈对齐，同时做 decoder-only scaling
  3. OneRec-Think：把显式推理和推荐专用 reward 拉进来
  4. OpenOneRec：把 benchmark、foundation model 和训练栈逐步公开

这样一来，后续最值得持续追的就不是“快手到底有没有 RL”，而是四个更细的问题：

  1. OneRec v1 的偏好 / 格式 / 业务 reward 各自服务什么目标
  2. OneRec-V2 的真实反馈与 Duration-Aware Reward Shaping 能迁移出哪些通用模式
  3. OneRec-Think 的 multi-validity reward 如何处理推荐里的多解偏好
  4. OpenOneRec 的 Rec-RL 和 VeRL 路线什么时候会真正变成外部可跑的公开方案

这也是为什么我会把 OneRec-V2 视为这一轮最重要的新增。它不是枝节，而是此前遗漏的桥梁。