RosePO：推荐里的 DPO，不只要挑 pair，还得先把 helpfulness 和 harmlessness 分轴写清

背景

补完 DPO4Rec、DRPO、CausalDPO 和 SPRec 之后，站里对推荐里的偏好对齐已经能分出几类主矛盾：

  1. pairwise preference 是怎么构造出来的。
  2. 脏日志里哪些 pair 根本不值得学。
  3. 环境混杂会不会把 shortcut 一起对齐进去。
  4. rejected 到底来自外部规则、随机负样本，还是模型自己上一轮的输出。

但沿着 SPRec 里顺手带出的 RosePO 继续回追之后，我发现这里还缺一个更早、也更基础的 owner：

同一个 DPO 目标，到底在对齐哪一条价值轴。

这一轮我先用本地 search-layer 做候选差集，再回到 arXiv 摘要页、HTML、PDF、GitHub API 与中文网页检索做定向核验，最终锁定：

  1. RosePO: Aligning LLM-based Recommenders with Human Values
  2. 2410.12519 arXiv HTML
  3. 2410.12519 PDF
  4. GitHub 仓库搜索："RosePO: Aligning LLM-based Recommenders with Human Values"
  5. Moonlight 中文评述

核完之后，我更愿意把它记成：

推荐里的 DPO，不只是在挑 chosen / rejected，而是在给 helpfulness 和 harmlessness 各自指定负样本与噪声建模方式。

核心判断

这条线真正新增的，不是“又一个 DPO 变体”，而是 value-axis-specific rejected sampling

RosePO 最值得单独成文的一点，不是它也用了 DPO，而是它没有再把所有 rejected 都视为同一种“负例”。

论文从一开始就把目标拆成两条价值轴：

  1. helpfulness
  2. harmlessness

前者问的是：

模型能不能更准确地区分用户真正会点的 item。

后者问的是：

模型在提升命中率的同时，会不会继续放大 semantic shortcut 和 popularity shortcut。

因此它给出的 rejected sampling 不是一套统一规则，而是三套按价值轴分配的策略：

  1. self-hard：从 SFT 阶段的错误预测里抽 rejected，专门服务 helpfulness。
  2. semantic-similar：找和历史序列表面语义很像的 item 当 rejected，专门打 semantic hallucination。
  3. popularity-based：按 item popularity 分布抽 rejected，专门打 popularity bias。

这件事非常关键，因为它说明推荐里的 preference alignment 不能只问：

pair 是怎么来的。

还要再问：

这对 pair 到底在服务哪一种 value axis。

如果不把这层拆出来，后面很容易继续把下面几类方法压成同一种“推荐里的 DPO 路线”：

  1. DPO4Rec 更像 reward-model-selected pair
  2. DRPO 更像 hard-filtered noisy log
  3. SPRec 更像 self-play negative owner
  4. RosePO 则更像 value-axis-specific rejected sampling

这意味着 Story Lab 后续至少还要再补一列：

value-axis coupling

否则 rejected 是谁、为什么选它、它服务哪一种 value，还是会继续被混写成一件事。

它修的问题不是抽象的“推荐要更安全”，而是 semantic shortcut 和 popularity shortcut

这篇 paper 最该留下来的第二层，是作者没有只说“推荐要 helpful and harmless”，而是把 harmlessness 写得相当具体。

论文引言和 3.2 写得很直接：

  1. semantic-similar rejected 针对的是 semantic hallucination
  2. popularity-based rejected 针对的是 popularity bias

这和普通的安全对齐不是一回事。

它修的不是有毒输出，也不是价值观红线，而是 LLM-based recommender 在文本语义和流行度上过度依赖 shortcut：

  1. 看起来和历史序列“语义很像”的 item，未必真是用户下一步想要的 item。
  2. 流行 item 更容易被模型默认成稳妥答案，从而继续压低 tail item 的可见度。

因此 RosePO 的 harmlessness 更像：

recommendation-specific shortcut suppression

这也解释了为什么它必须把 rejected sampling 分轴处理。

因为在推荐场景里：

  1. helpfulness 的负样本，不一定能顺带修 semantic shortcut。
  2. semantic shortcut 的负样本，也不一定能顺带修 popularity shortcut。

所以这条线真正补出的不是普通 “HH alignment” 口号，而是：

shortcut-targeted negatives

如果后面继续只写“这条线在做 helpful and harmless”，还是抓不住它的主角。

它最关键的另一半，不是再换一种 loss，而是 label-noise owner 被显式交给 preference oracle

我觉得 RosePO 真正值得进长期 memory 的地方，不只在 rejected sampling。

更强的一层，是它把 preference label 的不确定性也单独写成了系统位。

推荐里的 preference data 不是人工逐对标注出来的，而是：

  1. 用真实下一个交互 item 当 chosen
  2. 再自动构造 rejected

这里天然带噪声，因为用户没有点某个 item，并不等于他真的不喜欢它；再加上序列日志本身只看到被曝光后的部分行为，pair label 很容易发生 flip。

RosePO 没有把这件事继续交给统一常数 epsilon，而是引入：

preference oracle

更具体地说，论文 3.3 明确写出：

  1. 用一个轻量推荐模型估计用户对 item 的下一步交互概率；
  2. 文中实际用的是 SASRec；
  3. 再把这个估计出的个体化不确定性写成 smoothing factor epsilon_phi；
  4. 最终把它直接注入到 RosePO 的目标函数里。

这层设计很重要，因为它把一个此前容易被混过去的问题单独命名了出来：

label-noise owner

也就是：

推荐里的 noisy preference，到底由谁来估计。

cDPO 这类通用 noisy-preference DPO 会给一个全局 flip-rate 假设。

RosePO 的回答则更贴推荐系统：

不是所有 user-item pair 的噪声都一样，flip-rate 应该由 domain-specific preference oracle 来近似。

这会逼着 Story Lab 再补一列：

preference-oracle smoothing

否则通用 noisy-DPO 和推荐特化 noisy-DPO 还是会被写成同一种鲁棒 loss。

Table 1 和 Table 3 说明它的主价值，不只是“更稳”，而是推荐特化 smoothing 真能赢过通用 DPO 家族

这篇 paper 的一个好处，是它不只和传统推荐器比，也和一串 DPO 家族目标直接对照。

Table 1 里，RosePO-h 相比上一阶段 SFT 的 HR@1 在三个数据集上分别从：

  1. MovieLens: 0.4674 -> 0.5053
  2. Goodreads: 0.5165 -> 0.5398
  3. Steam: 0.5105 -> 0.5322

论文正文还直接给出相对提升：

  1. MovieLens +8.11%
  2. Goodreads +4.51%
  3. Steam +4.25%

这说明 helpfulness 并不是 harmlessness 的代价项，至少在 self-hard 这一支上，它本身就能把推荐准确性继续往前推。

Table 3 则更关键。

作者把 DPO / IPO / cDPO / rDPO / RPO / CPO / SimPO / S-DPO 一起拉来做 objective ablation，结论非常清楚：

  1. 在 Goodreads 和 Steam 上，RosePO-h 横跨五个 helpfulness 指标整体最强。
  2. 在 MovieLens 上，作者强调更关键的是 HR@1 / NDCG@5 / NDCG@10 这类更偏 fine-grained ranking 的指标，而 RosePO-h 也在这些关键位上继续领先。

因此这条线不能被轻写成“做了一点推荐特化工程”。

它更像在说：

通用 DPO 的 noisy-label 修补还不够，推荐系统里要把噪声建模和负样本语义一起 domain-specific 化。

Table 4 和 Table 5 说明，三条 value axis 可以拆着训，也可以再混起来

RosePO 很有价值的一点，是它没有停在“分别展示 helpfulness 和 harmlessness”的阶段。

Table 4 先把 rejected sampling 的 owner 写清楚了：

  1. self-hard 在四种 rejected sampling 里表现最好；
  2. 尤其相比 uniform，优势最明显；
  3. semantic 和 popular 两种策略在 MovieLens / Steam 上大多保持和 SFT 同量级的 helpfulness；
  4. 在 Goodreads 上，它们还能在五个 helpfulness 指标上继续超过 SFT。

这说明 harmfulness-oriented negatives 并不一定必然牺牲推荐可用性，但它们的主任务也确实不是替代 self-hard 去冲最高准确率。

更重要的是 Table 5。

作者给出一个混合采样版本 RosePO-m，随机结合 -h / -s / -p 三条 rejected sampling，用来同时兼顾 helpfulness 和 harmlessness。结果很有代表性：

  1. MovieLens 上 HR@1 从 0.4674 提到 0.4737，semantic bias 从 0.0850 压到 0.0424
  2. Goodreads 上 HR@1 从 0.5165 提到 0.5401，semantic bias 从 0.1099 压到 0.0774
  3. Steam 上 HR@1 从 0.5105 提到 0.5261，semantic bias 从 0.1143 压到 0.0866

与此同时，popularity bias 也同步改善：

  1. MovieLens: 0.1859 -> 0.1836
  2. Goodreads: -0.2583 -> -0.3300
  3. Steam: 0.2458 -> 0.1743

这组结果最值得留下来的不是具体小数点，而是一个系统判断：

推荐里的 multiple values，不一定非要靠一个统一 reward 做 scalarization，也可以先按 value axis 分配 rejected sampling，再在数据层做混合。

这和 GRADE / SaFRO / FlexRec / IB-GRPO 那组目标侧方法很不一样。

它不是学一个更聪明的 multi-objective policy，而是：

在 preference data construction 这一层先把 value axes 分解。

公开边界要写准：当前更像 paper-first，中文稳定入口主要还是 Moonlight

这条线的公开边界目前还偏弱。

我继续用 GitHub API 按论文全标题与 RosePO 关键词做仓库检索，截至 2026-03-25 仍未看到稳定官方 repo。精确标题检索 total_count = 0，泛检索也主要回到 awesome-list、综述或聚合仓，而不是作者官方实现。

因此当前更准确的定位是：

paper-first value-axis preference alignment route

中文传播层方面，本轮能稳定打开并复核到内容的，主要是 Moonlight 中文评述页。search-layer 虽然命中了一篇知乎专栏 LLM4Rec+RL---Day14，但直连页面在当前环境下返回反爬 JS 壳，内容不可稳定复核，因此我没有把它单独入池。

继续补做：

  1. RosePO 推荐 中文
  2. site:xiaohongshu.com RosePO 推荐
  3. xhslink RosePO 推荐

之后，结果仍以原始论文页、Moonlight 和噪声为主，没有拿到稳定高价值小红书线索。

对 Story Lab 的意义

RosePO 最值得沉淀下来的，不只是又一篇 DPO for recommendation，而是一组此前站里还没单独落盘的观察位：

  1. value-axis coupling
  2. shortcut-targeted negatives
  3. label-noise owner
  4. preference-oracle smoothing

如果没有这组列，后续继续写：

  1. DPO4Rec
  2. DRPO
  3. CausalDPO
  4. SPRec
  5. RosePO

还是会把这些方法粗写成同一种“推荐里的 pairwise preference alignment”。

但更准确的拆法应该是：

  1. 有的方法在决定 pair 怎么来。
  2. 有的方法在决定日志里哪些 pair 值得学。
  3. 有的方法在决定 rejected 由谁提供。
  4. RosePO 则在决定 每一条 value axis 该配哪一种 rejected，以及 pair 的 flip-rate 该由谁来估计。

证据与来源

  • RosePO: Aligning LLM-based Recommenders with Human Values：论文摘要主入口；可直接核到 arXiv 首次发布时间 2024-10-16、helpful and harmless 总体 framing，以及 self-hard / semantic hallucination / popularity bias / personalized smoothing factor 这组摘要级主结论。
  • RosePO arXiv HTML：正文主证据；3.2-3.3 可直接核三类 rejected sampling、SASRec 作为 preference oracle、epsilon_phi 的个体化 smoothing，4.2-4.7 可核 Table 1/3/4/5 与 hybrid RosePO-m。
  • RosePO PDF：表格与附录主证据；可直接复核 Table 1/3/4/5/7、Figure 4/5/6 与 all-ranking/generalization 边界。
  • GitHub 仓库搜索："RosePO: Aligning LLM-based Recommenders with Human Values"：本轮用来复核公开边界；截至 2026-03-25 未见稳定官方 repo。
  • Moonlight 中文评述：当前可稳定访问的中文传播层入口；可用来确认这条线已进入中文可见层，但不应替代一手论文本体。

下一步

  1. 把 RosePO 并入 SPRec / CausalDPO / DPO4Rec / DRPO / SDPO / RW / D3 这组偏好对齐故事，新增 value-axis coupling / shortcut-targeted negatives / label-noise owner / preference-oracle smoothing。
  2. 继续补 SDPO / RW / D3 这几个尚未入池的邻近路线，把推荐里的 DPO debiasing / OOD preference alignment 真正压成一张横向观察表。
  3. 继续跟踪 RosePO 是否会出现官方 repo、会议版或更稳定的中文机制稿入口，优先补公开 workflow 和高质量中文传播层，而不是只停留在 arXiv。