预算有限下的偏好数据：无需研究团队即可捕获 RLHF 信号

大多数尝试使用 RLHF 微调语言模型的团队在开始之前就放弃了。典型案例是 OpenAI 的 InstructGPT：33,000 个偏好对、13,000 个有监督演示、一个专门的外包团队，以及一个需要数周时间才能稳定的强化学习流水线。如果这就是门槛，那么大多数产品团队根本玩不起这个游戏。

他们错了。现在的门槛已经没那么高了。2024–2025 年的研究共识已经悄然改变：数据质量胜过数据量，DPO 完全取代了 RL 基础设施，而最有价值的偏好信号其实已经流经你的产品，只是未被记录。看起来是研究团队的问题，实际上是埋点（instrumentation）问题。

为什么你拥有的信号比你想象的要多

设计偏好数据采集时的直觉往往是构建标注 UI——左右对比对话框、星级评分、点赞/踩。这些方式虽然可行，但它们捕捉到的只是用户通过行为表达的信号中的一小部分。

每当用户点击“重新生成”时，他们对上一个输出投出的反对票比任何“踩”都要坚决。重新生成事件摩擦力低，发生在任务进行中，且含义明确：用户认定该输出不值得修改。这是你能得到的最高分贝的否定信号，而且不需要额外的 UI 成本。

其他具有高偏好信号密度的隐式信号：

• 复制到剪贴板：用户复制 AI 的回复意味着认可其后续用途。他们阅读了内容，判定其足够好，并付诸行动。
• 编辑距离：当用户接受 AI 输出并立即修改时，修改的程度与输出质量成反比。修改一个词是认可，替换每个句子则是否定。
• 回复后放弃会话：如果用户收到回复后立即关闭标签页或离开且没有任何交互，则说明回复未能满足其需求。生成后的放弃时长是一个强有力的质量信号。
• 每个 Prompt 类型的重试率：当用户对同一个提示词进行三次改写时，他们是在告诉你该类提示词的回复分布与其意图不匹配。

这些信号都不需要用户采取任何额外行动。它们是正常完成任务的副产品。工程投入在于埋点，而非 UI。

权衡之处在于：隐式信号存在选择偏差。频繁重新生成的用户与不经常生成的用户在系统性上是不同的。拥有特定工作流的核心用户比普通用户贡献了更多信号。隐式信号的分布并不能反映你的整体用户分布。这在训练时至关重要——如果你不加注意，模型会过拟合于核心用户的偏好。通过对显式和隐式来源进行三角测量，并按 Prompt 多样性而非用户量加权，是抵消这种偏差的方法。

值得收集的显式信号

隐式信号是免费的，但噪声较大。对于最重要的 Prompt 和用例，针对性的显式偏好收集值得投入。问题在于，哪种 UI 模式能带来最高的单次标注信号收益。

成对 A/B 测试（Pairwise A/B comparison） 是黄金标准。并排显示两个回复，询问哪一个更好（以及可选的原因）。其优势在于成对判断对标注者的标准差异具有鲁棒性——即使一个用户习惯性严苛或宽容，仍然能产生有用的信号，因为相对排序才是关键。缺点是成对判断随候选数量呈平方级增长：5 个回复需要 10 次对比，20 个则需要 190 次。

对大多数产品团队而言，部分成对采样是正确的方法。与其进行穷举对比，不如有策略地采样：优先对比质量接近的回复（因为一眼就能看出好坏的对比提供的信号很少），并利用已有的对比来估算所有候选方案的排名。

行内编辑（Inline editing） 被低估了。当用户可以直接修改 AI 回复而不是在多个变体中选择时，修改本身就是偏好数据。“修改前/修改后”的组合就是一个带标签的示例：“给定此输入，用户更喜欢这个输出，而非生成的那个。”这实际上是在一次交互中同时获得了有监督微调（SFT）信号和偏好信号。任何带有建议或草稿工作流的产品都应默认记录这些数据对。

点赞/踩 是最弱的显式信号，但最容易收集。用户点击“踩”的频率远高于“点赞”（负面体验更容易激发反馈意愿），这会导致数据集偏向负面示例。如果你采用这种模式，请在训练前运行评分归一化处理——原始的“踩”率在不同 Prompt 类型、用户群体或产品界面之间并不稳定。

形状比规模更重要

最近 RLHF 研究中最违反直觉的发现是，偏好数据集的规模停止产生回报的速度有多快。Apple ML Research 表明，当数据集超过 6.5 万个示例后，将规模翻倍仅能使奖励模型的准确性提高约 1.1%。比较 SafeRLHF 数据集（1 万个示例）与 HH-RLHF（14 万个示例）的研究发现，1 万个经过高质量策划的示例产生的奖励模型效果更好。

一旦你思考奖励模型实际上在学习什么，这就有意义了。它在学习从 (prompt, response) → 标量分数的映射。它需要的是对任务分布的覆盖以及该分布中响应质量的变化。一旦你有足够的示例来合理地覆盖分布，更多同类型的示例带来的收益就会递减。你需要的广度，而不是深度。

“形状”在实践中的含义：

• 提示词多样性 (Prompt diversity)：你的偏好对应该涵盖用户实际发送的提示词范围，而不仅仅是简单的或常见的那些。如果 90% 的偏好对来自一种提示词类型，奖励模型将针对该类型进行良好的校准，但对其他类型则毫无用处。
• 质量跨度 (Quality spread)：两个响应都很好的偏好对产生的信号很弱——模型学会了更偏好略好一点的输出，但没有学会强烈惩罚坏的输出。你需要跨越整个质量光谱的偏好对，包括明显糟糕的响应，以训练一个在故障模式（failure modes）处具有陡峭梯度的奖励模型。
• 一致性校准 (Agreement calibration)：预期在偏好任务上有 60–75% 的标注者间一致性。这不是质量失败。对于固有的主观偏好，100% 的一致性意味着标注者只看到了简单的情况。在困难情况下的分歧是有意义的信号——它教会奖励模型处理歧义，而不是过度自信。

一个实用的启发式方法：涵盖核心任务分布的 5,000–10,000 个精心策划的偏好对是一个可行的起点。来自较少策划来源的 50,000+ 个也是可行的。失败的模式是 100,000 个偏好对全部来自狭窄的提示词分布，且没有质量变化。

最小可行奖励模型

一旦有了偏好对，你就需要从中估计奖励函数。传统的 RLHF 方法涉及训练一个单独的奖励模型，然后针对它运行 PPO。这很复杂，需要单独的训练运行，并引入了奖励欺骗（reward hacking）风险，即策略学会利用奖励模型的伪影（artifacts），而不是产生真正好的输出。

Bradley-Terry 模型是最小可行奖励模型的正确起点。它假设每个响应都有一个潜在质量得分，并且响应 A 比响应 B 更受青睐的概率是得分差异的 sigmoid 函数。训练相当于对成对比较进行逻辑回归。通过在基础模型的最后一层之上实现一个小型的线性头（linear head），它不需要 RL 基础设施，并且训练稳定。

但对于许多产品团队来说，甚至奖励模型都是不必要的。直接偏好优化 (DPO) 在 2023 年表明，存在一个闭式解可以完全消除奖励模型。DPO 使用重新参数化的目标函数，直接从偏好对中优化 LLM 参数，这在数学上等同于具有 KL 散度约束的 RL，但实现为监督微调（SFT）。训练循环看起来就像 SFT——没有奖励模型，没有采样循环，没有策略梯度方差。

DPO 的实际权衡：

• 更简单：一个训练阶段而不是三个（SFT → 奖励模型 → PPO）
• 计算成本更低：不需要在线展开（online rollouts）
• 对分布偏移敏感：DPO 假设偏好数据是在你正在训练的策略下收集的。如果你的偏好数据来自一个与初始检查点显著不同的模型，性能会下降。
• 天花板略低于 PPO：研究表明，在某些领域 PPO 的表现优于 DPO 1–2%，但这一差距通常被 DPO 的易实现性所抵消。

ORPO (Odds Ratio Preference Optimization) 进一步简化。它完全去除了参考模型，并在标准的 SFT 损失函数中添加了一个对数几率（log-odds-ratio）项。你在一个步骤中、针对一个目标进行微调，不需要参考检查点。一个使用 ORPO 在 10 万个示例上微调的 Llama-2-7B 在 AlpacaEval 上达到了 81.26%，超过了使用完整 RLHF 流程训练的 Llama-2-Chat。

对于没有 RL 经验且算力有限的团队，实现路径是：收集偏好对 → DPO 或 ORPO 微调 → 在预留的偏好对上进行评估。研究团队的流程是为了挤出最后 1–2% 的性能。对于大多数生产用例，更简单的路径能让你达到 95% 的水平。

当偏好数据质量不佳时会发生什么

一旦你知道要注意什么，偏好训练模型的失败模式是可以预见的。

通过流畅性进行奖励欺骗：如果标注者隐含地奖励啰嗦或自信的语气，模型就会学会产生更长、更果断的响应，而不管其准确性如何。这是最常见的隐形失败之一——奖励模型根据表面属性（长度、词汇量、避重就轻的频率）而不是语义质量进行泛化。

看起来像能力限制的覆盖范围差距：一个在特定提示词类型上表现糟糕的模型通常存在偏好数据差距，而不是能力限制。如果你的偏好数据没有涵盖对抗性提示、技术问题或特定领域，奖励模型在这些领域就没有信号，策略就会针对这些输入产生不受约束的输出。

标注者分布偏移：如果你最初的偏好数据来自比最终用户更懂技术的内部测试人员，奖励模型将过度优化技术用户的偏好。当你部署给普通用户时，模型会让人觉得对齐不准，尽管它在内部偏好评估中表现良好。这是常见且可以避免的：让你的标注者群体与你的目标用户群体相匹配。

过度优化：在固定的偏好数据集上训练时间越长，策略就越学会利用奖励模型的伪影，而不是在底层任务上改进。在训练期间监控预留偏好胜率，并在它们达到平台期（plateau）之前停止——在平台期之后继续训练只会积累奖励欺骗。

一个务实的起点

对于想要在没有研究部门的情况下发布经过偏好微调（preference-tuned）行为的产品团队来说，这条路径如下：

首先，记录你尚未捕获的隐式信号：重新生成点击、复制事件、修改后输出的编辑距离（edit distance）、以及会话放弃的时间点。这些操作几乎零成本，且能立即为你提供关于模型在何处失败的方向性信号。

对于显式收集，首先在价值最高的界面添加成对比较（pairwise comparison）的 UI —— 即用户最常发送的 prompt 以及影响下游决策的输出。你不需要标注每一个响应；每个 prompt 类别 50–100 个比较就足以提供启动所需的信号。

在开始训练前，目标是收集 5,000–10,000 个偏好对。注重覆盖率的筛选 —— 确保你的示例涵盖了 prompt 的各种分布，并在偏好对中包含一些明显糟糕的响应，以提供奖励信号的方差（variance）。

除非你有特定理由需要使用 PPO，否则建议运行 DPO 或 ORPO 作为训练方法。在留出的偏好集（held-out preference set）上进行评估，而不是在无关的基准测试上。真正重要的指标是你的模型是否产生了用户偏好的输出，且该衡量标准应基于你训练时的相同分布。

研究团队的流水线是为大规模前沿模型的质量而优化的。对于针对特定用例和用户群体微调生产模型，这些更简单的方法是有效的 —— 它们之所以奏效，是因为你从自己的用户那里收集的数据，比你可以获得授权或构建的任何大规模通用偏好数据集都更具相关性。

瓶颈通常不在于方法或模型，而在于团队还没有开始进行日志记录。