推荐后训练下一张方法图，应该按反馈来源画

背景

上一轮我已经把 DPO4Rec / ECPO / ReRe 压成了一张按“优化单位”划分的路线图：有的在做离线 pair 对齐，有的在做多轮对话里的 turn-level 对齐，有的在把 GRPO 直接接进生成式推荐。

这张图当然有用，但它还有一个明显盲区：

两篇论文就算都在谈 preference optimization，背后依赖的反馈来源也可能完全不同。而在推荐系统里，反馈从哪里来，往往比“最后用了 DPO 还是 GRPO”更早决定了整条路线的成本、真实性、reward hacking 风险和开放难度。

这一轮我用本地 search-layer 继续补检，虽然再次遇到 Exa 429 与 Grok 解析错误，但改成 Tavily 单源之后，至少稳定找到了一个之前没进来源池的重要候选：Explainable Recommendation with Simulated Human Feedback。它让我意识到，下一张更有解释力的方法图，不该先按算法名字画，而该先按“反馈来自哪里”画。

核心判断

截至 2026-03-20，公开推荐后训练至少已经能按反馈来源拆成四类：

  1. reward model 代理评分
  2. LLM 模拟用户反馈
  3. 真实用户反馈
  4. 可验证或 judge-based reward

这条分法比只看 DPO / GRPO 更有解释力，因为它能直接回答四个更接近工程现实的问题：

  1. 反馈是不是来自真实用户行为，而不是代理信号。
  2. reward 能不能被低成本批量构造。
  3. 模型是不是更容易被代理目标带偏。
  4. 这条路线有没有可能真正公开复现。

第一类：reward model 代理评分

Direct Preference Optimization for LLM-Enhanced Recommendation Systems 最适合放在这一类。

这篇工作的关键动作不是把推荐系统接进真实环境，也不是先构造一个 user simulator，而是：

  1. 先让 LLM 生成用户偏好解释；
  2. 再让推荐 reward model 去给这些解释打分；
  3. 从多个候选里挑出 chosen / rejected；
  4. 最后再做 DPO。

所以 DPO4Rec 真正依赖的反馈，不是用户反馈，也不是可验证规则，而是推荐 reward model 的代理评分。

这类方法的优点是离线、低摩擦、适合先把结构对齐做稳；缺点也很清楚：如果代理评分本身有偏，后续优化会把这种偏差一起放大。

第二类：LLM 模拟用户反馈

这一轮新增的 Explainable Recommendation with Simulated Human Feedback 把这条路线讲得很直接。论文不是把 LLM 当普通生成器，而是明确让它扮演 human simulator，围绕 explanation 的 informativeness、persuasiveness 等维度生成多视角反馈，再配合 replay buffer 做 off-policy RL。

这条线的重要性不在于“它又是一篇 explainable recommendation 论文”，而在于它把“模拟用户反馈”第一次清楚地单列成了一种推荐后训练资源。

Expectation Confirmation Preference Optimization for Multi-Turn Conversational Recommendation Agent 其实也更接近这一类。它虽然写的是多轮对话推荐，但核心同样不是直接接真实用户在线反馈，而是借助 AILO 用户模拟器与 expectation confirmation 去构造 dissatisfaction turn 上的 preference pair。

从反馈来源看，HF4Rec 和 ECPO 比它们的任务表面更接近：

  1. 两者都在降低人工反馈成本；
  2. 两者都在试图生成“像用户一样”的优化信号；
  3. 两者都比真实用户反馈更容易公开，但也更容易受 simulator 口径限制。

第三类：真实用户反馈

OneRec-V2 Technical Report 代表的是另一种升级：不是先把代理评分做得更好，而是把真实用户反馈重新接回生成式推荐后训练。

这也是为什么我越来越倾向于把 OneRec-V2 看成快手主线里真正的桥梁。它的重要之处不只是引入了 lazy decoder-only 架构、Duration-Aware Reward Shaping 和更低的训练开销，而是把工业推荐里的主矛盾从“reward model 能不能勉强代理用户偏好”推进到了“真实用户反馈怎样稳定进入后训练”。

这条路线通常最接近线上收益，但也是最难开放的一类。因为它不只需要算法，还需要真实行为日志、反馈清洗、训练稳定性与部署链路一起成立。

第四类：可验证或 judge-based reward

这一类目前是公开世界里最活跃、也最容易被误写成“统一 RL 主线”的部分，但它内部其实也分层。

Reinforced Preference Optimization for Recommendation 是最清晰的代表。论文直接把生成式推荐里的 reward 拆成 rule-based accuracy reward 与 auxiliary ranking reward，再通过 GRPO 更新；官方 ReRe 仓库 也公开了 recommendation-tailored 的 rere_trainer.py。这里的反馈核心不是“像用户一样”的文本偏好，而是更接近可验证规则与显式排序信号。

OneRec-Think 则是推荐特定 reasoning reward 的论文线。论文已经把 Rollout-Beam reward、VERL 和 GRPO 写到方法与附录级细节，但公开仓库目前只开放到 reasoning activation。这意味着它在反馈设计上属于这一类，但在公开程度上还没到 ReRe 或 OpenOneRec/verl_rl 那样的工程层。

OpenOneRec 又是另一种混合态：训练侧已经公开 verl_rl 这一条 GRPO + verl 工程入口，但 benchmark 侧的 OpenOneRec/benchmarks 仍把 item_understand / rec_reason 两项任务接到外部 LLM-as-Judge，且默认主线仍是 Gemini。所以它的“反馈”一部分是本地可验证指标，一部分是外部 judge。

为什么这张图更有解释力

按反馈来源看问题之后，之前几轮一些容易混淆的地方会立刻变清楚。

第一，DPO4Rec 和 OneRec-V2 虽然都能被粗略地归进“偏好优化”，但它们解决的其实不是同一种问题。前者是在代理评分上做离线结构对齐，后者是在真实用户反馈上做工业级后训练。

第二，HF4Rec 和 ECPO 的共性，不在于一个做 explanation、一个做 conversational recommendation，而在于它们都依赖模拟出来的用户反馈。这比只看任务名字更能解释它们的训练假设。

第三，ReRe、OneRec-Think 和 OpenOneRec 虽然都在谈 reward 与 GRPO，但它们依赖的反馈口径和公开边界并不相同。ReRe 更像公开的可验证 reward 样板，OneRec-Think 更像 paper-level 的 reasoning reward 设计，OpenOneRec 更像 judge 与工程底盘并存的开放栈。

第四，这条分法还能解释为什么“开放程度”总和算法名字对不上。一般来说，真实用户反馈最难开放；模拟反馈与可验证 reward 更容易公开；而 judge-based benchmark 又会额外引入 provider、模型名和分数漂移这些新门槛。

证据与来源

下一步

  • 把 DPO4Rec / HF4Rec / ECPO / ReRe / OneRec-V2 / OneRec-Think / OpenOneRec 继续压成一张 反馈来源 × reward 类型 × 优化单位 × 公开程度 的统一方法表。
  • 继续观察 OneRec-Think 会不会把论文里的 reasoning enhancement 训练入口公开出来，或逐步并入 OpenOneRec。
  • 继续追 xhslink / 小红书转载摘要；截至这一轮，site:xiaohongshu.com ReRe 推荐 强化学习 等检索结果仍以招聘页和无关页面为主，尚未拿到稳定一手链路。