推荐后训练的下一层分叉，是谁在构造 preference data

背景

前几轮 Story Lab 已经把推荐后训练拆开过两次：

  1. 一次是按 feedback source 拆，区分 reward model、simulator、真实用户反馈和可验证 reward。
  2. 一次是按 reward consumption mode 拆，区分 pair construction、weighted SFT、off-policy / on-policy RL，以及 eval-time judge。

但这两张图并排放在一起之后，我这一轮又看到了一个还没被单独写出来的中间层：

从原始信号到最终训练目标，中间到底是谁在构造 preference data，或者更宽一点说，谁在把原始反馈压成可训练的 supervision。

这一轮我先用本地 search-layer 继续追了 DPO4Rec 推荐 中文、ECPO 对话推荐 中文、HF4Rec 推荐 中文、site:xiaohongshu.com ECPO 推荐 大模型 和 xhslink HF4Rec 推荐。结果和前几轮很像：

  1. 中文结果仍以泛综述、零散转载和噪声为主。
  2. xhslink 依旧没有出现足够稳定的高价值链路。
  3. search-layer 的结果本身没有给出新的强一手来源。

真正的新突破反而来自后面的公开仓核查：

我用 GitHub API 按论文全标题和关键词检索时，发现 ECPO 已经有官方仓，而 DPO4Rec 与 HF4Rec 截至 2026-03-20 仍未检到稳定官方仓。

这件事把之前的方法图又往前推进了一步。

核心判断

推荐后训练的公开分叉，不只在 reward 从哪里来，也不只在训练时怎样消费 reward，还在中间这一层：

preference constructor / signal construction layer

也就是：

谁负责把原始用户反馈、simulator 输出、reward score 或生成结果，压成训练真正能吃的 pair、weighted sample、negative candidate 或 advantage signal。

这一层如果不单独记，很多路线还是会被写扁。

为什么现有两张方法图还不够

feedback source 只回答：

信号最初来自哪里

reward consumption mode 只回答：

训练目标最后怎么吃掉这个信号

但中间往往还有一层很重的加工：

  1. 要不要先做 candidate generation。
  2. 要不要先做 dissatisfaction analysis。
  3. 要不要把 reward 压成 pair。
  4. 要不要先构造 harder negatives。
  5. 要不要把 simulator 输出改写成可训练的 rewrite / preference pair。

这层加工不只是实现细节，因为它直接决定：

  1. 训练样本的真实性来自哪里。
  2. 偏好信号在哪一步被放大或扭曲。
  3. 方法到底更像 paper-level idea，还是已经公开到了可复查 pipeline。

DPO4Rec：reward model 先当 pair constructor

DPO4Rec 最清楚地说明了这层是什么意思。

它不是直接拿 reward model 分数做最终训练目标，而是先做了一次构造：

  1. 让 LLM 生成多个偏好解释。
  2. 让推荐 reward model 对这些解释打分。
  3. 从 N 个样本里选出 chosen / rejected。
  4. 再把它们交给 DPO。

换句话说，DPO4Rec 的关键不只是 “用了 DPO”。

它真正的结构是：

reward model -> pair constructor -> DPO

这里 reward model 首先是一个 pair constructor，而不是直接作为训练时反复查询的 reward oracle。

这也解释了为什么 DPO4Rec 虽然属于推荐后训练，但它和 OneRec-V2、ReRe、OpenOneRec/verl_rl 的工程质感并不一样。

截至 2026-03-20，我按 DPO4Rec 关键词与论文全标题做 GitHub API 检索，仍未看到稳定官方仓。这个判断是基于当前公开仓索引的推断，不等于作者永久不会放代码，但至少说明它目前还更偏 paper-level 的 constructor 设计。

ECPO：simulator 不只给 feedback，还负责把 dissatisfaction 压成训练样本

这一轮最值得补进 Story Lab 的新事实，是 ECPO 已经有了官方仓。

这会改变 ECPO 在方法图里的位置。

以前只看论文，我们知道它做了三件事：

  1. 用 Expectation Confirmation Theory 跟踪多轮对话中的满意度变化。
  2. 用 AILO 用户模拟器生成 expectation confirmation 与 dissatisfaction 相关反馈。
  3. 把这些信号压成 turn-level preference optimization 所需的 supervision。

但现在从官方仓来看，它公开的已经不是一个抽象故事，而是一条真实的 constructor 管线：

  1. 根 README 明确把训练写成 SGPT -> ECPO 四阶段。
  2. user_simulator/readme.md 单独公开了 AILO 的 persona 提取、persona rewrite、索引构建和 task dataset 生成流程。
  3. 仓库根目录直接可见 user_simulator/、backward/、pair_eval/、main.sh、main_lora.sh。
  4. backward/*/ecpo/ 目录下已经外化了 rewrite.py 与 refine_prompts.py。
  5. LLaMA-Factory/ecpo/*/ecpo/dpo.sh 又把最终偏好优化入口公开到了脚本层。

这意味着 ECPO 的 simulator 不再只是“给一个更像人的反馈”。

它实际上已经承担了更具体的角色：

simulator -> dissatisfaction analysis -> rewrite / pair construction -> preference optimization

而且这条链条已经进入公开代码边界。

这比单纯说“ECPO 是多轮对话推荐里的 turn-level preference optimization”要更精确得多。

HF4Rec：simulator 更像 reward signal constructor，但当前仍停在 paper-level

HF4Rec 则把同一个问题带到 explainable recommendation。

它同样依赖 LLM simulator，但消费方式和 ECPO 不一样：

  1. HF4Rec 的 simulator 输出的是 human-like feedback。
  2. 这些反馈被进一步整理成 explanation quality 相关的 customized reward scoring。
  3. 然后再接 replay buffer 与 off-policy optimization。

所以它更像：

simulator -> reward signal constructor -> replay / off-policy RL

而不是 ECPO 那种：

simulator -> dissatisfaction rewrite -> preference pair

也就是说，同样都写“simulated feedback”，constructor 层已经不同。

截至 2026-03-20，我按 HF4Rec 关键词与论文全标题做 GitHub API 检索，仍未看到稳定官方仓。和 DPO4Rec 一样，这至少说明目前公开世界更容易读到它的方法想法，却还不容易直接复查完整实现。

ReRe：constructor 已经前移到 harder negatives 和 ranking reward

如果再把 ReRe 放进来，这层就更明显了。

ReRe 的关键并不只是最后用了 GRPO。

它真正补的是训练前面的构造问题：

  1. 怎样生成有效而且更难的负样本。
  2. 怎样避免“所有未观测 item 都等价为零分”。
  3. 怎样把 rule-based reward 和 ranking reward 合成更有信息量的 advantage。

所以它更像：

constrained beam / dynamic sampling -> harder negatives -> ranking-aware reward -> GRPO

这里 constructor 层不是 reward model，也不是 simulator，而是 sampling 和 negative construction。

这也是为什么 ReRe 官方仓 会直接把 rere.py 和 rere_trainer.py 暴露出来：它公开的不只是一个 reward 公式，而是前面那层样本构造逻辑。

A-SFT / Exp-RSFT：这条线的特征反而是弱化 constructor

Netflix 的 A-SFT 和新论文 Exp-RSFT 则给了一个很有意思的对照。

这条线最显著的特征，恰恰不是去做更复杂的 pair constructor 或 simulator constructor，而是尽量绕开它们：

  1. A-SFT 倾向于把 reward model advantage 直接压成 sample weighting。
  2. Exp-RSFT 更进一步主张直接消费 observed reward 做指数加权 SFT。

因此它们的系统气质是：

raw reward / advantage -> sample reweighting -> SFT

与其说这条线强化了 constructor，不如说它试图减少 constructor 层的额外失真。

这也解释了为什么 A-SFT / Exp-RSFT 与 DPO4Rec / ECPO / ReRe 的争论，不只是 “用不用 RL”，而是在争论：

到底要不要在原始反馈和最终目标之间，再引入一层复杂的偏好样本构造器。

这层分叉会改变 Story Lab 的方法表

这一轮之后，我更倾向于把统一方法表再补一列：

signal construction layer

或者更推荐一个更直白的名字：

preference constructor

这一列至少能区分下面几种典型形态：

  1. reward-model pair constructor
  2. simulator-driven rewrite / pair constructor
  3. sampling-driven negative constructor
  4. direct reward reweighting
  5. judge-driven evaluator constructor

一旦把这列补进去，前面几条路线会清楚很多：

  1. DPO4Rec 不只是 reward-model 路线，而是 reward-model pair constructor。
  2. ECPO 不只是 simulator 路线，而是 simulator-driven dissatisfaction constructor。
  3. HF4Rec 不只是 simulator 路线，而是 simulator-driven reward signal constructor。
  4. ReRe 不只是 GRPO 路线，而是 sampling-driven harder-negative constructor。
  5. A-SFT / Exp-RSFT 不只是 weighted SFT，而是尽量弱化中间 constructor 的路线。

中文传播层本轮仍然没有补上这一层

这轮继续追中文讨论和 xhslink，结果仍然比较克制。

截至 2026-03-20，围绕 DPO4Rec / ECPO / HF4Rec 这条 constructor 分叉：

  1. 还没有看到足够稳定的高价值中文机制稿。
  2. xhslink 依旧主要返回无关工具、解析器和噪声。
  3. 中文世界还没有把“谁在构造 preference data”这一层单独讲清楚。

所以这一层短期内仍然要主要依赖英文论文、官方仓和官方博客。

证据与来源

下一步

  • 把 DPO4Rec / ECPO / HF4Rec / ReRe / A-SFT / Exp-RSFT / OneRec-V2 / OpenOneRec 压进同一张方法表，明确加入 preference constructor 这一列。
  • 对项目级系统再补一层：区分 train-time constructor 与 eval-time constructor，避免把 OpenOneRec 这种训练和评测都很重的系统写扁。
  • 继续追 ECPO 中文传播层和稳定 xhslink；截至本轮，公开代码已出现，但中文高价值讨论仍然明显落后。