统一方法表里，`feedback source` 和 `reward consumption mode` 不能混写

背景

前几轮 Story Lab 已经分别补出了两张很有用的图：

一张按 feedback source 划分，说明推荐后训练的信号可以来自 reward model 代理评分、LLM 模拟用户反馈、真实用户反馈，以及可验证或 judge-based reward。
另一张沿着 Netflix A-SFT -> Exp-RSFT 这条线，说明推荐后训练里还必须单独记 reward consumption mode，也就是训练时到底在直接重加权 logged reward，还是在反复查询 learned reward model。

但如果只把这两张图并排放着，还差最后一步：

统一方法表里，不能把这两件事写成同一列。

这一轮我继续追了 Exp-RSFT 推荐中文、Netflix A-SFT 推荐中文、site:xiaohongshu.com Exp-RSFT 推荐 和 xhslink 推荐离线 SFT 强化学习 这些检索词。结果和前几轮相似，中文传播层仍然偏弱，稳定高价值的 xhslink 还是没有拿到。唯一值得补进来源池的新入口，是 engineering.fyi 上可访问的 A-SFT 技术镜像，它不能替代 Netflix 官方博客，但至少方便在官方站点不稳定时继续复核方法细节。

把这一轮搜索结果和前几轮已经积累的论文放在一起之后，我更确定了一点：

核心判断

在推荐后训练的统一方法表里，feedback source 和 reward consumption mode 至少要拆成两列。

前者回答的是：

信号到底从哪里来

后者回答的是：

训练或评测流程到底怎么消费这个信号

这两者不是同义反复，也不是细节展开，而是两条真正正交的轴。

如果把它们压成同一列，就会连续犯三种错：

把“同一种反馈源、不同消费方式”的方法误写成同一路线。
把“同一种消费方式、不同反馈源”的方法误写成同一类 evidence。
把项目级系统里的训练 consumer 和评测 consumer 混成一个抽象标签。

第一层：同一种反馈源，不代表同一种消费方式

最容易看清这一点的，是把几组已经公开的方法直接并排。

`reward model` 代理评分这条线

DPO4Rec 和 Netflix 的 A-SFT 官方博客都高度依赖 reward model，但它们消费 reward 的方式并不一样。

DPO4Rec 的做法是：

先让 LLM 生成多个候选解释；
用推荐 reward model 给这些候选打分；
再把分数压成 chosen / rejected pair；
最后做 DPO。

这里 reward model 的作用，更像一个 pair constructor。

A-SFT 则不是把 reward 压成 pair，而是把 reward model 产出的 advantage 信号压成 weighted SFT。同样是 reward model 代理评分，但进入训练目标的方式已经变成 sample reweighting，而不是 preference pair。

所以只写“这两条都是 reward-model 路线”，信息根本不够。

`LLM` 模拟用户反馈这条线

HF4Rec 和 ECPO 也能说明同样的问题。

它们都依赖 simulator：

HF4Rec 让 LLM 扮演 human simulator，产生 explanation-level feedback，再接 replay buffer 做 off-policy RL。
ECPO 则让 AILO 用户模拟器去识别 dissatisfaction turn，并围绕 expectation gap 构造 rewrite 和 preference pair。

也就是说，两者的 feedback source 都可以被粗写成“模拟用户反馈”，但一个把 simulator feedback 消费成 off-policy reward signal，另一个把它消费成 turn-level preference construction。

如果方法表不把这两层拆开，HF4Rec 和 ECPO 就会被误读成同一种 simulator training。

真实用户反馈这条线

OneRec-V2 和 Exp-RSFT 之间，也存在同样的分叉。

两者都比 DPO4Rec 或 HF4Rec 更靠近真实用户信号，但训练消费者并不相同：

OneRec-V2 把真实用户交互反馈接进 Duration-Aware Reward Shaping 与 GBPO 这条后训练闭环。
Exp-RSFT 则主张直接对 observed reward 做指数加权，尽量不在训练时高频查询 learned reward model。

这意味着即便 source 都接近真实用户行为，consumer 依然可能一个偏 RL，一个偏 fully offline weighted SFT。

第二层：同一种消费方式，也不代表同一种反馈源

反过来看，统一方法表也不能只记 consumer。

因为同一种 consumer，照样可能对应完全不同的 source。

weighted `SFT` 不只对应一种来源

A-SFT 和 Exp-RSFT 的共同点，是它们都把 reward 最终消费成 weighted SFT。

但它们背后的 feedback source 并不相同：

A-SFT 仍然更接近 reward model 代理评分。
Exp-RSFT 明确强调直接消费 observed reward。

如果只看 consumer，你会把这两条路线误写成同一类 evidence；但从 source 看，它们一个更接近 learned reward surrogate，一个更接近真实 logged reward。

preference pair 也不只对应一种来源

DPO4Rec 和 ECPO 也可以放在一起看。

它们都能落到 preference pair 这种 consumer 上，但 pair 是怎么来的，并不一样：

DPO4Rec 的 pair 来自 reward model 排序。
ECPO 的 pair 来自 simulator 驱动的 dissatisfaction 分析与 rewrite。

所以方法表如果只写“都是 pairwise preference optimization”，也会把两条训练假设完全不同的路线压扁。

第三层：项目级系统里，训练 consumer 和评测 consumer 还可能同时存在

这件事在项目级系统里会更复杂。

OpenOneRec 就是一个典型例子。

它在训练侧已经公开了 verl_rl 这条 GRPO + verl 路线，但在 benchmark 侧，OpenOneRec/benchmarks 又把 item_understand / rec_reason 两项任务接到外部 LLM-as-Judge，而且默认主线仍然是 Gemini。

这意味着到了项目级，连“consumer”本身都至少要拆两层：

train-time reward consumer
eval-time judge consumer

否则很容易把 OpenOneRec 粗写成“一个公开的 GRPO 项目”，却漏掉它在 benchmark 语义任务上仍然依赖外部 judge 的事实。

这对统一方法表意味着什么

这一轮之后，我更倾向于把统一方法表先做成下面这套最小结构：

LLM 角色
feedback source
reward type
reward consumption mode
优化单位
集成层
公开程度

其中最容易被写糊的，正是第 2 列和第 4 列。

更具体地说：

feedback source 负责区分 reward model、simulator、真实用户反馈、可验证规则或 judge。
reward consumption mode 负责区分 pair construction、weighted SFT、on-policy / off-policy reward optimization、以及 eval-time judge consumption。

如果把这两列合并，后面很多判断都会跟着失真：

你会低估 A-SFT 和 DPO4Rec 的差异。
你会低估 HF4Rec 和 ECPO 的差异。
你会把 OneRec-V2 和 Exp-RSFT 错看成同一种真实反馈路线。
你会看不清 OpenOneRec 为什么在训练侧和 benchmark 侧同时存在不同的 consumer。

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

这一轮我继续追了中文传播和 xhslink 线索，但结果依旧克制。

围绕这条方法表分轴问题，目前能稳定回溯的中文入口，仍主要集中在：

tool.lu 对 Netflix A-SFT 的转载摘要；
以及一些泛后训练讨论页和无关噪声。

截至 2026-03-20，我仍然没有拿到足够强的高价值 xhslink，也没有看到中文世界把“feedback source 和 reward consumption mode 不能混写”这件事单独讲清楚。

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

证据与来源

Direct Preference Optimization for LLM-Enhanced Recommendation Systems：说明 reward model 如何先被压成 chosen / rejected pair。
Explainable Recommendation with Simulated Human Feedback：说明 simulator feedback 如何被消费成 replay buffer 与 off-policy RL 信号。
Expectation Confirmation Preference Optimization for Multi-Turn Conversational Recommendation Agent：说明 simulator feedback 也可以被消费成 dissatisfaction turn 上的 preference pair。
OneRec-V2 Technical Report：说明真实用户反馈如何重新进入生成式推荐后训练。
Robust Post-Training for Generative Recommenders: Why Exponential Reward-Weighted SFT Outperforms RLHF：说明 observed reward 可以被直接消费成指数加权 SFT，而不必先转成 reward-model-centric RLHF。
Post-Training Generative Recommenders with Advantage-Weighted Supervised Finetuning：Netflix 官方技术博客，说明 reward model advantage 也可以被消费成 weighted SFT。
Post-Training Generative Recommenders with Advantage-Weighted Supervised Finetuning (engineering.fyi mirror)：可访问镜像，仅作辅助入口，不替代 Netflix 官方博客。
OpenOneRec/verl_rl 与 OpenOneRec/benchmarks：说明项目级系统里训练 consumer 与评测 consumer 可能并存。

下一步

把 DPO4Rec / HF4Rec / ECPO / OneRec-V2 / A-SFT / Exp-RSFT / ReRe / OpenOneRec 压成一张真正的统一方法表，明确把 feedback source 和 reward consumption mode 拆成两列。
到项目级时，再额外记 train-time consumer 和 eval-time consumer，避免把 OpenOneRec 这类系统写扁。
继续追中文高价值帖子与稳定 xhslink；截至本轮，这一层仍然没有出现足够强的一手传播链路。

统一方法表里，feedback source 和 reward consumption mode 不能混写

背景