NAPO：推荐里的 DPO，不只要更多 negative，还要先解决负样本扩容效率和信息量调权

背景

补完 S-DPO、SPRec、RosePO 和 ReRe 之后，站里对推荐里的偏好对齐已经能分出几类主矛盾：

multiple negatives 在 loss 里是逐对比较还是共同竞争
rejected 到底是谁提供的
不同 value axis 是否需要不同的 negatives
on-policy negative exposure 是否要靠 constrained generation 和 beam search 先约束住

但这一轮继续沿 DPO / recommendation / negative-aware 做定向检索时，我发现这里还缺一个更靠前、也更工程化的 owner：

negative pool 怎样在不增加额外解码开销的前提下被扩容，以及不同 negative 的更新力度该由谁决定。

如果这层不单独拆出来，后面很容易继续把下面几类方法粗写成同一种“推荐里的 DPO 变体”：

S-DPO 重点解决的是 multi-negative 的耦合几何
SPRec 重点解决的是 negative sample owner
RosePO 重点解决的是 value-axis-specific rejected sampling
ReRe 重点解决的是 negative exposure 和 output validity
NAPO 则重点解决 negative coverage efficiency + informativeness-aware margin

这一轮我直接用一手材料做核验，最终锁定：

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

推荐里的 DPO，不只要更多 negative，还要先解决负样本扩容效率和信息量调权。

核心判断

这条线真正新增的，不是“再加更多 negative”，而是 `negative coverage regime`

S-DPO 已经告诉我们：

多个 negatives 在 loss 里不该只是 K 个独立 pair。

但 NAPO 继续往前追的不是 loss 几何，而是更基础的训练现实：

LLM-based recommender 想多吃一些 negatives，每多一个 negative 都要多做一次 prompt-conditioned decoding。

这和传统推荐器里直接共享 negative embedding 不是一回事。

论文 Section 3.2 把这一点写得很清楚：

LLM 推荐里的 scaled log probability 可以拆成 F(x_u) 生成 prompt-dependent logits，再由 G(z_u, y) 做 item-conditioned autoregressive decoding
如果要为每个 user sequence 额外计算 batch 内其他 negative，就会把复杂度推到 O(n^2 |Ê|)
因而真正的主问题不是“能不能再采样更多 negatives”，而是“negative coverage 的扩张由谁承担计算”

NAPO 的回答不是再多跑模型，而是：

把同一 batch 里已经算出来的 negative log-probability 在相似序列之间共享。

这意味着它补出的第一个系统位，不是 ordinary negative sampling，而是：

negative coverage regime

也就是：

negative 覆盖究竟靠额外解码扩出来
还是靠 batch 内共享已有信号扩出来

如果不把这层单独记下来，后面很容易继续把 S-DPO、NAPO 和 ReRe 都写成“反正都在多用 negative”。

这条线最关键的工程契约，不是“共享就行”，而是 `sharing validity contract`

NAPO 最值得长期记住的，不是单纯复用 negatives，而是作者明确知道：

共享 negative log-probability 这件事本身是有条件的。

因为同一个 item 在不同 user context 下的意义并不一样。

论文直接给出反例：

给科幻片爱好者算出来的 negative，对浪漫喜剧偏好的用户不一定仍然成立。

所以它没有做无条件复用，而是加了一个 similarity-guided filtering：

用轻量 sequential recommender 的 sequence embedding 去表征用户历史
计算 sequence 相似度
只在 top-K 相似序列之间共享 negative log-probability
K = floor((bp - 1) * rho)，由批大小和共享比例 rho 决定

这就把一个此前没单独命名的位写清楚了：

sharing validity contract

也就是：

negative 信号不是因为“在 batch 里”就能共享，而是要先满足“在偏好空间里足够像”。

这层很关键，因为它说明 NAPO 真正在做的不是缓存技巧，而是：

similarity-gated negative transfer

如果后面只把它写成“更高效的 negative sharing”，还是会错过这条线真正的系统位。

它修的第二个问题也不是“margin 再调一下”，而是 `informativeness-aware margin`

SimPO 里已经有固定 reward margin。

RosePO 则把 label noise 和 value axis 拆开。

但 NAPO 继续前推了一步：

不是所有 negative 都该被同样力度地压。

论文 Section 3.3 的核心判断非常明确：

高置信度 negative 更像真正远离用户偏好的 item
低置信度 negative 可能靠近 decision boundary，甚至有 false negative 风险
因而固定 γ 会把不同信息量的 negative 一起等权处理

于是它引入 dynamic γ adjustment：

仍然用同一个辅助 sequential recommender
对每个 (sequence, negative item) 计算 confidence
高 confidence negative 给更大的 margin
低 confidence negative 给更小的 margin
再用 batch-level moving average 的 R0 和动量 m 去平滑更新

这意味着 NAPO 真正补出的不是 another margin trick，而是：

informativeness-aware margin

也就是说：

negative 的作用强度，不应只由主 loss 决定，还要由外部 confidence estimator 决定。

这会逼着 Story Lab 后续在 DPO / preference alignment 观察表里再补两列：

informativeness-aware margin
auxiliary confidence owner

否则 SimPO 的固定 margin、RosePO 的 preference-oracle smoothing 和 NAPO 的 dynamic γ 还是会被写成同一种“调一下超参”。

`Table 2 / Table 3` 说明它的主价值，不只是更省算力，而是 `negative efficiency` 真能换回 ranking gain

这篇 paper 的主结果很适合沉淀到长期 memory，因为它把 accuracy、validity 和效率一起钉住了。

Table 2 给出的完整模型结果是：

Goodreads 上 HR@1 / ValidRatio = 0.7458 / 0.9933
LastFM 上 HR@1 / ValidRatio = 0.6961 / 0.9979
Steam 上 HR@1 / ValidRatio = 0.8220 / 0.9932

对比同表里的 S-DPO：

Goodreads 是 0.6661 / 0.9950
LastFM 是 0.6477 / 0.9980
Steam 是 0.6703 / 0.9881

正文还直接总结：

相对第二名 baseline，NAPO 的 HR@1 提升分别是 11.96% / 7.47% / 22.63%
相对 S-DPO 的平均 HR@1 增幅是 14.02%

更关键的是 Table 3 的 ablation。

它把两个 owner 拆得很清楚：

去掉 negative sharing 后，Goodreads / LastFM 会从 0.7458 / 0.6961 掉到 0.6727 / 0.6549
去掉 dynamic γ 后，则掉到 0.7241 / 0.6797
只给 S-DPO 加上 negative sharing，就能从 0.6661 / 0.6448 提到 0.7408 / 0.6857

这组结果非常关键，因为它说明：

negative sharing 本身就是主要 owner
dynamic γ 不是配角，而是在 sharing 之上继续补稳定性和精细区分

所以这条线不能只写成“效率更高一点”。

更准确的判断应该是：

negative efficiency 已经开始直接决定 recommendation quality，而不只是训练成本。

`Figure 3(c) / Table 5` 又补出一个此前没单独记开的位：`negative-efficiency frontier`

我觉得 NAPO 最值得单独成文的一点，是它把“多负样本更强”这件事从普通经验，推进成了一个更具体的工程前沿：

negative-efficiency frontier

论文 Figure 3(c) 写得很具体：

S-DPO 随着 sampled negatives 增加，性能会稳步涨，但显存和计算也继续涨
NAPO 在 n_neg = 3 左右就接近平台期
即使拿 S-DPO n_neg = 15 去比 NAPO n_neg = 1，NAPO 仍能保持更好的效果

更强的工程信号在 Section 4.4 和 Appendix E / Table 5：

受 GPU memory 限制，S-DPO 最多只能容纳 15 个 sampled negatives
NAPO 能容纳 19 个 sampled negatives，对应优化中的等效 209 个 negatives
训练时间上，LastFM 从 5.5h 降到 4.2h
Goodreads 从 19.5h 降到 15.3h
Steam 从 25h 降到 20h

这意味着后续不能只记：

negative 数量是多少

还要单独记：

negative coverage regime
negative-efficiency frontier

否则 S-DPO、NAPO 和 ReRe 这些路线里“negative 用得更好”这句话会过于粗糙。

公开边界与中文传播层

这条线的公开边界当前要写得保守。

我这轮直接用 GitHub API 按：

论文全标题
arXiv id 2508.09653
作者关键词

做精确和模糊检索，截至 2026-03-25 都没有看到稳定官方 repo。

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

paper-first negative-efficiency preference alignment route

中文传播层目前至少有一个可稳定访问的入口：

ChatPaper 中文页可以正常打开
内容已经能复述 in-batch negative sharing 和 dynamic reward margin adjustment

但边界也要写准：

它本质上仍是二手 AI 评述，不能替代论文原文
site:xiaohongshu.com 与 xhslink NAPO recommendation 这轮仍没有稳定高价值结果
搜索结果里 NAPO 这个缩写还会被大量无关页面污染

因此这轮来源池只补：

论文主入口
ChatPaper 中文传播层入口

对 Story Lab 的意义

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

negative coverage regime
sharing validity contract
informativeness-aware margin
auxiliary confidence owner
negative-efficiency frontier

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

S-DPO
SPRec
RosePO
ReRe

时，还是会把“multiple negatives 如何共同竞争”“negative 由谁供给”“negative 服务哪条价值轴”“negative 怎样高效扩容”“negative 的更新力度由谁调”混成同一件事。

而 NAPO 提醒了一件非常具体的事：

推荐里的 negative，不只是监督对象，也是稀缺预算。

谁来扩它、怎么共享它、哪些该重罚、哪些该轻放，本身就是方法学主角。

NAPO：推荐里的 DPO，不只要更多 negative，还要先解决负样本扩容效率和信息量调权

背景

核心判断

这条线真正新增的，不是“再加更多 negative”，而是 negative coverage regime

这条线最关键的工程契约，不是“共享就行”，而是 sharing validity contract

它修的第二个问题也不是“margin 再调一下”，而是 informativeness-aware margin

Table 2 / Table 3 说明它的主价值，不只是更省算力，而是 negative efficiency 真能换回 ranking gain

Figure 3(c) / Table 5 又补出一个此前没单独记开的位：negative-efficiency frontier