产品工程师必读的训练后对齐：RLHF、DPO 和 RLAIF 对你究竟意味着什么

大多数构建 AI 功能的团队认为，一旦产品发布，用户反馈就会成为后续可以利用的资源。记录点赞和点踩信号，积累足够的量，最终进行微调。现实情况更为棘手：一年的反应记录并不等同于一年的对齐质量训练数据。这两者之间的差距，正是对齐技术——RLHF、DPO、RLAIF——要么拯救你，要么令你措手不及的地方。

这篇文章不是对对齐研究的综述。它是一份面向工程师的决策指南，旨在帮助你从数据收集的角度理解这些技术的需求，从而确保你今天部署的埋点确实能够支持你计划在六个月后进行的微调。

对齐究竟起到了什么作用（以及它不起什么作用）

预训练教会模型预测文本。它并没有教会模型在你的特定领域内，针对你的特定用户，一个好的回复应该是怎样的。监督微调（SFT）在一定程度上缩小了这一差距——你向模型展示了你希望看到的行为示例。但仅靠 SFT 产生的模型只会模仿你的示例，而无法以符合用户实际偏好的方式泛化到“更好”的状态。

后训练对齐是缩小这一剩余差距的方法。RLHF、DPO、RLAIF 这三种方法的核心机制是相同的：让模型接触关于哪些输出更受欢迎的比较信号，然后更新模型以产生更多受欢迎的输出，减少不受欢迎的输出。

区别在于如何收集、组织和应用这些信号。这些差异对于你在生产环境中需要构建的内容至关重要。

RLHF：功能强大但过于厚重

来自人类反馈的强化学习（RLHF）是一个三阶段流水线。首先，你在演示数据上对基础模型进行 SFT。其次，你训练一个独立的奖励模型，该模型将（提示词，回答）对作为输入，并输出一个标量质量分数。第三，你使用该奖励模型作为信号，通过近端策略优化（PPO）来优化策略，并使用 KL 散度惩罚来防止更新后的模型偏离原始模型太远。

奖励模型既是 RLHF 的优势所在，也是成本中心。它可以在异构反馈上进行训练——包括排名、评分、多维度的比较评估——这意味着它对混乱的、真实世界的标注具有相对较高的容忍度。如果你的标注员意见不完全一致，或者你的反馈涵盖了多样且有时冲突的用例，奖励模型会学会对这些差异取平均。它是一个噪声吸收器。

成本在于运维：RLHF 要求在训练期间保持四个模型副本处于活跃状态（被优化的策略模型、用于 KL 散度的参考策略模型、奖励模型和价值函数模型）。对于没有专门 ML 基础设施的团队来说，这是一项重大的资源投入。有意义的 RLHF 通常还需要 50,000 到 100,000 个偏好对来训练一个鲁棒的奖励模型——大多数产品团队在数月甚至数年内都无法积累到这个数据量。

DPO：更简单但更严苛

直接偏好优化（DPO）省去了奖励模型。关键的数学洞察在于，你可以重新参数化 RLHF 的目标函数，使得任何奖励函数的最优策略都可以直接通过训练策略与参考策略之间的比率来表达。这使得奖励信号可以隐含在策略本身中，只需通过对偏好对进行简单的二元交叉熵损失训练即可。

结果是比 RLHF 减少了 40-60% 的计算量，实现更简单，且需要调节的超参数显著减少。研究表明，在直接对比中，DPO 能够达到 RLHF 约 90-95% 的对齐质量。对于那些需要一条无需专门 ML 基础设施即可实现微调的实际路径的团队来说，DPO 通常是正确的起点。

但 DPO 对糟糕数据的容忍度不高。你的偏好数据有三个属性决定了 DPO 是否有效：

二元结构是不可妥协的。 DPO 只接受偏好对——每个提示词对应一个选中的回答（chosen）和一个拒绝的回答（rejected）。你不能向它输入三个或四个回答的排名。如果你的反馈系统收集的是多点评分或开放式评论，你需要先将其转换为二元比较，这涉及到会引入噪声的人为判断。

数据质量直接影响性能。 与 RLHF 中奖励模型可以缓冲标注噪声不同，DPO 训练对你选中的（偏好的）回答质量非常敏感。被拒绝的回答次之——你主要教给模型的是“好”的回复长什么样，而不仅仅是“坏”的回复长什么样。如果你选中的回答选择不一致，或者反映了标注员模棱两可的偏好，这种不一致性会直接进入模型。

策略内（On-policy）数据显著优于策略外（Off-policy）数据。 当偏好对来自你当前正在微调的模型（或者至少是与其密切相关的模型）时，DPO 的表现最好。由不同模型的输出生成的偏好对会产生分布失配：模型被要求去偏好那些并不反映其自身行为范围的输出。这种“策略外”问题很微妙，但在经验结果中是一致存在的。

RLAIF：无需标注预算的规模化方案

由 AI 反馈进行的强化学习 (RLAIF) 使用前沿模型充当裁判，从而取代了人类标注员。你定义一套评估标准——在 Anthropic 的术语中被称为“宪法 (constitution)”——并使用性能强大的 LLM 根据这些标准生成偏好标签。然后，这些标签会被输入到传统的 RLHF 奖励模型或 DPO 训练流水线中。

成本计算发生了巨大变化。专业质量的人类标注通常每对偏好需要 1 美元或更多。而 AI 生成的反馈每对成本不到一美分。这使得大多数团队以前无法企及的实验规模成为可能：你可以在获取几千个人类标注所需的时间内，生成数千万个偏好对，迭代你的宪法标准，并运行多次对齐实验。

权衡之处在于，AI 生成的偏好反映的是前沿模型的价值观和盲点，而不是你用户的。宪法 AI 允许你指定希望裁判优化的目标，但这仍然需要仔细思考在你的领域中“好”意味着什么。如果你正在构建一个法律研究工具，通用前沿模型的默认价值观可能与你用户的需求并不一致。做好 RLAIF 意味着要在编写和测试宪法原则上投入精力，而不仅仅是接入一个 API。

一个经实证记录的风险：在 DPO 数据集中使用多个不同的模型来生成被选中 (chosen) 和被拒绝 (rejected) 的回复（即“多模型”偏好数据），其产生的安全对齐效果比使用单一模型更差。推测的机制是，跨模型比较引入了分布不一致性，模型学会了利用这些不一致性而不是将其内化。对于安全至上的应用，请使用单一模型生成每个偏好对中的两个回复。

反馈与训练信号之间的鸿沟

这是大多数产品团队发现得太晚的一个令人不安的事实：收集用户反馈和收集对齐质量的训练数据是不同的活动，将两者混为一谈代价昂贵。

考虑一下典型的产品反馈循环产生了什么。用户对回复点击点赞或踩。数据量在积累。信号看似很丰富。但当你尝试将其转化为 DPO 训练数据时，会产生几个问题。

二元反馈并不说明原因。 对回复的踩可能意味着答案在事实上有误、语气不对、太长、太短、格式错误，或者针对的是查询的错误解读。如果不知道原因，你就无法构建一个有意义的“被拒绝”标签。模型将无法学会需要改变什么。

反馈反映的是用户，而非质量。 如果你的核心用户与普通用户有显著差异——更专业、对冗长的回答更宽容、更熟悉技术术语——那么反馈分布将反映他们的偏好，而不是一个可泛化的质量信号。

偏好对需要两个元素，而不是一个。 一个踩只给了你一个被拒绝的回复。对于 DPO，你需要一个对应的被选中回复。生成该被选中回复要么需要人类重写（昂贵且缓慢），要么需要模型采样（这会重新引入同策略问题）。仅记录负面信号的团队只拥有必要数据结构的一半。

标注者间的一致性决定了你的上限。 为了使偏好数据有用，不同的标注者需要对什么是更好的达成一致。衡量标准通常是 Cohen's kappa；对齐研究通常认为 0.6-0.8 是可接受的。如果你的标注者一致性 kappa 值为 0.4，那么你的偏好标签噪声太大，无法进行可靠训练。

现阶段应该收集什么

考虑到这些约束，以下是现在如何部署反馈收集的方法，以便之后能够创建可用于对齐的数据。

捕获结构化偏好对，而不仅仅是反应。 实现一个向用户展示两个版本的回复并询问哪个更好的 UI，而不是孤立地对单个回复进行评价。两两比较降低了认知负荷，并直接产生了 DPO 所需的二元结构。如果出于产品原因必须使用点赞/踩，请确保你同时也记录了完整的回复上下文，以便日后重构偏好对。

记录足够的上下文以重构出处。 每个反馈事件都应记录：提示词 (prompt)、回复、生成该回复的模型版本、用户细分和时间戳。你需要模型版本，因为同策略 (on-policy) DPO 需要知道是哪个模型产生了训练样本。你需要用户细分，因为你会想要审计偏好分布是否存在偏差。

实施基于编辑的反馈。 基于编辑的反馈——用户直接纠正或改进模型输出——提供了一种自然的成对结构：原始回复成为被拒绝的版本，编辑后的内容成为被选中的版本。这比比较评分具有更高的信号强度，并且无需单独标注即可产生 DPO 就绪的数据。

在需要标注员之前编写标注指南。 当你最终需要通过人类标注员来扩大反馈收集规模时，限制因素是标注员间的一致性。尽早建立评估标准和好/坏回复的具体案例，可以让你先校准内部团队，这样招聘额外的标注员就不会让校准过程从零开始。

在开始之前决定你的数量阈值。 DPO 使用 2,000 到 5,000 个高质量偏好对就能产生可衡量的改进。围绕在定义的时间窗口内达到该阈值来规划你的反馈基础设施，如果你想追求 RLHF，再向 50,000+ 的范围构建。大多数团队应该先以 DPO 为目标。

选择适合你当前阶段的方法

决定哪种对齐技术最好的关键不在于其通用性 —— 而在于哪种技术最契合你当前的数据状态。

如果你拥有少于 5,000 对偏好数据，且它们质量高、标注一致，并且与你部署模型的策略一致（on-policy），那么 DPO 是最合适的起点。它无需专门的机器学习基础设施即可实现，能以极低的成本获得大部分质量收益，并促使你在数据质量上保持严谨，这在日后将为你带来丰厚的回报。

如果你拥有来自多个用户细分群体和使用场景的大量多样化、且包含较多噪声的反馈，那么 RLHF 值得你去承担额外的复杂性。奖励模型能够吸收更多的标注差异，并处理 DPO 无法处理的异构反馈格式。

如果大规模人工标注并不可行 —— 无论是出于预算、时间表还是领域专业知识的限制 —— RLAIF 让你能够合成生成偏好数据，前提是你在定义“宪法准则”（constitutional criteria）方面投入足够的精力。这在早期迭代阶段特别有用，因为此时你尚未积累足够多的真实用户反馈来进行训练。

在实践中，这些方法通常是按顺序结合使用的，而不是排他性地只选其一。一个实际的工作流如下：在精选的演示数据上进行 SFT → 在初始的高质量偏好对上进行 DPO → 针对更新后的模型迭代收集新反馈 → 使用来自新模型的同策略数据（on-policy data）进行另一轮 DPO。每次迭代都会加强对齐效果，并为下一次迭代产生更好的同策略数据。

真正的风险：错位的后端设施

在对齐方面遇到最多困难的团队，并不是那些选错算法的团队。而是那些构建了针对产品指标（如点击率、点赞量、会话时长）进行优化的反馈基础设施，却未考虑对齐训练实际需求的团队。

当这些团队最终想要进行微调时，他们会发现自己的数据不具备 DPO 所需的结构，反馈分布偏向特定的用户群体，日志没有捕捉到足够的上下文来重建偏好对，而且他们在过去 18 个月里一直在衡量错误的东西。

思考这一问题的最佳时机是在发布第一个反馈机制之前，而不是在积累了一年无法使用的信号之后。算法已经成熟；数据管线才是工作的重中之重。

结论

RLHF、DPO 和 RLAIF 并不是相互竞争的研究项目 —— 它们是具有不同数据需求、成本概况和适用场景的工具。了解哪种工具适合你的情况，关键不在于理论特性，而在于你当前的反馈基础设施能产生什么。

需要弥补的实际差距存在于你收集的反馈与你需要的训练信号之间。弥补这一差距需要成对的数据结构、与标注者间一致性挂钩的质量标准、足以重建来源的上下文，以及达到每种方法所需数量阈值的明确计划。

模型已经准备好了。问题在于，你的数据是否也准备好了。