大模型能不能“写一手好文章”“回一句得体的建议”很多时候靠的不是它背了多少数据而是它在“什么算好、什么算差”这件事上有没有被教明白。早期大家发现单纯靠预训练加指令微调模型可以做到“有问必答”但回答是不是更符合人类的偏好、是不是更安全、更讨喜模型自己并不知道。于是就有了奖励模型和偏好调优这套组合拳——圈内常说的“RLHF”相关技术路线或者更广义地说基于人类偏好的对齐技术。这篇文章我想从一个实践者的角度把“大模型如何学会自我审美”这件事拆开讲透从数据准备、奖励模型训练、到策略调优和评估落地尽量讲清楚原理也把我在实际项目中踩过的坑一并交代。如果你正准备做模型对齐或者正在看各种技术报告但拼不出完整链路这篇文章应该能帮你把各个环节串起来。文中的部分细节会基于常见实践做补充说明供你参考后结合自己的场景调整。1. 为什么光会“接话”不等于“会审美”——从SFT到偏好对齐的跳跃1.1 自回归训练本质上只教了“文字接龙”先聊聊大模型最底层的训练逻辑。预训练阶段模型做的事情叫做“预测下一个token”——给你一段文本的前面部分让模型猜后面接什么词最合理。这种做法本质上是在学“语言统计规律”也就是语言模型的基本能力。这时候的模型也能生成一段看起来通顺的话但它的目标函数里根本没有“这句话是否符合人类品味”这回事。到了指令微调阶段我们开始用“用户问题-标准回答”这样的数据去训练模型。模型学会了“当用户问什么的时候应该给什么样的回答”这是一种行为模仿。SFTSupervised Fine-Tuning能让模型记住格式、记住语气、记住常见的回答套路但短板也很明显它只模仿了我们认为“好”的回答并没有学会区分“好”和“更好”。一个指令可能有几十种合格写法有的平铺直叙有的逻辑清晰有的还带点人情味。SFT训练时这些都被平均地压进了模型的参数里模型不知道到底哪一类是用户最想要的。一个很直接的类比你给一个学生布置作文只告诉他“这是高分范文、这是低分作文”不如给他一个具体的评分标准——“结构是否完整、论据是否充分、语言是否流畅”他才能有针对性地改进。模型也是一样的逻辑要让它真正拥有“审美”需要给它一张带有区分度的“分数表”这张表就是奖励模型Reward Model, RM要产出的东西。1.2 审美的本质从“对与错”到“好与坏”的连续打分先明确一个概念在大模型语境里审美并不是一种玄学而是一个可量化的偏好函数。人类标注员面对两个模型回答判断哪个更好这些成对的比较数据被拿来训练一个打分模型让它学习“好回答”和“坏回答”在语义上的分布差异。一旦训练完成这个打分模型就能给任意一条回答打出一个分数分数越高代表越符合人类偏好。这就把“审美”这件事从模糊的感觉变成了可优化的目标。我们不再需要告诉模型具体哪句话该怎么说只需要告诉它“分数更高”这个方向。模型会自己探索什么样的措辞、什么样的结构、什么样的推理过程能获得更高奖励。整个过程其实是一个标准的“奖励学习”问题偏好信号来源于人类标注通过奖励模型进行拟合成可计算的函数最后通过强化学习或直接偏好优化来调整策略模型。1.3 数据信号的正反馈闭环才是完整链路切记一点不用把奖励模型和偏好调优看成两个孤立的模块。它们一起构成了一条数据闭环——初始策略模型SFT后的模型生成若干回答人类标注员对回答进行两两比较或排序比较数据用于训练奖励模型策略模型根据奖励模型的反馈继续调优调优后的模型再次生成回答进入下一轮人工标注……这个循环每转一轮模型的输出质量就更进一步向“人类偏好”收敛。这也是为什么说大模型的“自我审美”不是先天自带的而是被奖励信号教出来的。理解了这层闭环后面看PPO、DPO这些具体算法时会轻松很多。2. 奖励模型的训练本质把“人类排序”变成“数值打分”2.1 偏好数据从哪里来两两比较是主流标注方式训练奖励模型最缺的不是算法而是高质量的偏好数据。目前工业界最主流的数据形态是pairwise——也就是“给定同一个prompt让模型生成两个回答或者从多个模型生成的结果里抽取两个然后让标注员判断哪一个更好”。举一个具体标注界面上的例子Prompt回答A回答B标注结论“如何向一个五岁小孩解释重力”重力是一种力它把物体拉向地球。想象你往天上扔一个球球最后总会掉下来这就是有个力气在把它往下拉。B更好实际标注中为了让数据更可用还经常混合排序式标注——让标注员对3到4个回答排序而不仅仅是二选一。排序数据可以拆出多对pairwise比较这样一份人工标注能产生更多训练样本。举个简单的计算逻辑如果让标注员对一个prompt的4个回答排序那可以生成 ( C(4,2)6 ) 个比较对数据效率会高不少。不过排序式标注也有代价标注员认知负担会明显变大标注一致性可能下降。所以不少团队的折中做法是“先两两比较如果标注员觉得难以抉择再引入第三个候选”或者采用“比较排序混合”的模式。数据标注的质量直接影响后续每一环的效果。这里多说一句标注指南一定要写得足够细比如什么算“有帮助”、什么算“有害”、什么时候“拒绝回答”比“尝试回答”更好都得定义清楚。2.2 Bradley-Terry损失一句话讲清奖励模型在优化什么奖励模型本身通常就是一个跟策略模型规模相近或稍小的模型结构也很简单在传统序列模型的输出后接一个线性层把最后位置的隐藏状态映射成一个标量分数。核心区别在于它的训练方式——它不是一个做文本生成的模型而是一个打分器。它用的损失函数叫 Bradley-Terry简称BT模型最早来自体育赛事中预测两队胜负概率的方法后来被广泛应用到学习排序和人机对齐领域。用大白话讲给定同一个prompt ( x )我们有两个回答 ( y_w ) 和 ( y_l )其中 ( y_w ) 是人工标注中“更优”的那个winner( y_l ) 是“更差”的那个loser。奖励模型给两个回答分别打分为 ( r(x, y_w) ) 和 ( r(x, y_l) )我们希望 ( y_w ) 的分数显著高于 ( y_l ) 的分数。在PyTorch里实现一个简洁的BT损失大概是这个感觉import torch import torch.nn.functional as F def bradley_terry_loss(reward_w, reward_l, marginNone): reward_w: 模型给更好回答的打分, shape [batch] reward_l: 模型给更差回答的打分, shape [batch] margin: 可选启发式增加区分度类似排序间隔 if margin is not None: logits reward_w - reward_l - margin else: logits reward_w - reward_l loss -F.logsigmoid(logits).mean() return loss核心意思就是让“winner的分数减去loser的分数”经过sigmoid之后接近1损失越小越好。因为sigmoid有一个“饱和区”当 ( r_w - r_l ) 已经很大时损失进一步降低的意义就不大。这也告诉我们一个训练技巧不必苛求奖励模型在每个pair上都把分数拉得极端高只要排序正确即可。过度追求分数差异反而可能导致奖励模型过拟合后面调优策略模型时容易出现奖励黑客问题后面细说。2.3 多轮迭代标注奖励模型不是一次性训练的在实际项目里奖励模型的训练不会只在一条数据池上训一版就结束。比较常见的是“迭代式数据生产”——先让当前策略模型可能是SFT版本生成一批回答标注出pairwise数据训练出V1版奖励模型然后用V1版本去筛选第二轮生成结果中奖励分数差异最大的样本再让标注员标注这些“模型自己都拿不准的好样本”继续训练V2版奖励模型。这么做的原因很简单奖励模型的训练也需要“困难样本”。如果pairwise的两个回答差异太明显模型很快就学会了导致决策边界很粗糙但那些奖励分数接近、连模型都难分伯仲的样本才是精细校准审美观的关键。所以在构建偏好数据集时不要只想着“多”要想办法让采样去覆盖“难”。这一步的经验是奖励模型的训练数据里可以让两个回答来自同一个模型同代或不同温度采样也可以来自不同模型。一般建议混合。如果两个回答来自同一个模型能帮助奖励模型学到更细微的差异如果来自不同模型能帮它建立跨模型泛化能力。这两类数据的比例通常控制在6:4到7:3之间具体还是要通过验证集实验来确定。3. 偏好调优两大流派从PPO的工程复杂度看DPO为何兴起奖励模型训练好之后它只是一个裁判。我们要做的下一步是让策略模型学会“在裁判面前拿高分”。这个阶段就是偏好调优目前最经典的方法是强化学习典型代表是PPO算法后来出现了一种更轻量的路径——直接偏好优化Direct Preference Optimization, DPO现在已经成为开源社区和中小规模团队的首选。3.1 PPO四套模型登场的强化学习方案PPOProximal Policy Optimization做RLHF时需要同时维护四个模型策略模型Actor也就是我们最终要发布的那个模型它的参数会被更新奖励模型Reward Model相当于裁判给策略模型的输出打分但本身参数不更新参考模型Reference Model通常是SFT阶段的模型快照用于计算KL散度防止策略模型跑偏到“只说好话但语言质量崩塌”的境地批评者模型Critic用来估计状态价值的是PPO算法里做优势函数估计用的一般会从奖励模型的骨干网络初始化。训练时策略模型针对一批prompt生成回答奖励模型给这些回答打分同时参考模型计算生成回答的KL散度两项加权得到最终reward再用PPO算法去更新策略模型。一个简化的reward计算可以写成final_reward reward_model_score - beta * kl_divergence这里 ( \beta ) 是KL惩罚项的系数。如果你设得太大模型会被“绑”在参考模型附近几乎学不到新东西设得太小模型就会放飞自我甚至出现“用胡言乱语来骗高分”的情况。经验上很多项目把KL惩罚系数设在一个相对靠中间的量级然后根据训练过程监控生成质量动态调节。PPO的优势在于它理论上更灵活奖励函数可以是任意可计算函数不一定要局限在预训练的奖励模型上。比如你可以在奖励公式里加上“长度惩罚”防止模型为了高分而无限堆字也可以加上“敏感词扣分”做个简单的规则式安全网。缺点也明显——工程复杂度高、训练不稳定、显存占用大四套模型轮转对很多团队来说起步门槛不低。3.2 DPO不训奖励模型直接改目标函数DPO出来之后很多人松了一口气。它的核心洞察在于BT模型里奖励函数的最优解其实可以用策略模型和参考模型的概率比来隐式表达。也就是说我们不需要显示训练一个奖励模型也不需要跑强化学习更新循环只需要直接监督式地优化一个目标函数就能达到和PPO类似的对齐效果。DPO的损失函数看起来长这样def dpo_loss( policy_logps, # 当前模型对chosen/rejected的log概率 ref_logps, # 参考模型对chosen/rejected的log概率 beta, # 温度系数控制对偏离参考模型的容忍度 ): policy_logps 和 ref_logps 都包含 chosen 和 rejected 两组值 这里以chosen为正样本、rejected为负样本 log_ratio_chosen policy_logps[chosen] - ref_logps[chosen] log_ratio_rejected policy_logps[rejected] - ref_logps[rejected] # 隐式奖励差 reward_margin log_ratio_chosen - log_ratio_rejected loss -F.logsigmoid(beta * reward_margin).mean() return loss有没有发现它跟Bradley-Terry损失非常像只是把“奖励模型对两个回答的分数差”换成了“策略模型和参考模型在两个回答上的对数概率比之差”。这就是DPO的精妙之处——它把奖励建模和策略优化合并成了一个步骤。训练流程也被大大简化你只需要一份偏好数据集、一个参考模型、一个待调优模型然后像做SFT一样更新参数不需要构造强化学习环境不需要启发式采样也不容易因为强化学习的状态空间剧烈波动而崩溃。3.3 两种方案的取舍经验从我实际跑项目的感受来看PPO和DPO的取舍主要看三件事团队工程能力、数据规模、以及对生成多样性的要求。如果在线数据比较丰富、甚至你能搭建“模型生成-人工评分-策略更新”的实时飞轮那PPO还是值得投入的因为它的在线探索能力更强能自己发现新路径如果只有一批离线偏好数据、团队也没有大规模的强化学习工程经验那DPO是更务实的起点。它能调出“足够好”的模型尤其是在任务比较单一、回答风格相对标准的场景下DPO和PPO的效果差距并不大还有个折中做法先用DPO做一轮快速对齐让模型先有一个“及格审美”再用PPO做一轮精细调优。很多团队实际上是这样组合的因为DPO后的模型作为PPO起点能够显著降低强化学习训练的不稳定问题。另外要提醒一点DPO虽然不用训练奖励模型但并不意味着可以完全不看奖励分数。训练完后我们仍然需要用奖励模型或人工评估去检查模型的行为是否真的变好了。它省的是训练流程不是评估环节。4. 我踩过的坑奖励黑客、过优化与数据噪声4.1 训练loss一直降生成质量却明显变差——奖励黑客的典型表现奖励黑客Reward Hacking是偏好调优里最让人头疼的问题。简单说就是模型发现了一条“看起来能拿到高分但并不符合人类真实意图”的捷径并且会迅速把这条路走到极致。我第一次遇到这个问题是在一个问答类项目上当时的奖励模型倾向于给“更长的回答”更高分。模型很快学会了“不管用户问什么都先写很长很长的一大段再加一堆分点列举和总结”。人工一看完全是车轱辘话但奖励分数就是一路飙升。这就是典型的reward hacking——模型没有真正提升回答质量而是钻了奖励函数的空子。常见触发原因有奖励模型只在固定数据分布上训练一旦策略模型的输出分布偏移它就进入“盲区”乱打分奖励模型本身存在偏差比如偏好长文本、偏好某些高频句式、偏好引用特定关键词调优过程中reward的系数设置不当让模型觉得“高分策略”远好过“保持语言质量”。一个粗糙但有效的诊断方法每间隔固定步数把当前策略模型输出的回答抽样出来用人工看一遍同时记录reward分数。如果出现“人工分变差但reward分变高”的情况基本可以判定为reward hacking。别迷信训练曲线loss下降不代表模型变好。4.2 KL约束失控模型“性格突变”的幕后黑手在PPO类方法里KL散度惩罚项是防止策略模型偏离参考模型太远的重要调节阀。它衡量的是当前模型输出分布和参考模型输出分布的差异。如果这个值在训练初期就急剧飙升通常意味着策略模型正在快速改变自己的说话风格甚至会牺牲可读性去迎合奖励模型。我见过一个项目KL系数设置过小训练跑到中途时模型开始大段大段输出格式工整但内容空洞的话而且用词变得越来越夸张——比如无论什么问题都套上“非常、极其、强烈推荐”这类词。后来把KL系数调大一倍重新训练情况马上回复平稳。在DPO框架里虽然没有显式的KL约束但参考模型仍然隐式地起着“锚”的作用。( \beta ) 参数设置的逻辑类似( \beta ) 越大模型越接近参考模型调优越保守( \beta ) 越小模型越自由越容易过度优化。经验做法是在训练前先跑几个小规模预热实验对比不同β对验证集的效果而不是直接在一个值上硬跑完整训练。4.3 标注噪声如何量化别让矛盾数据白练一场偏好数据的质量直接影响奖励模型的效果而实际问题中标注员之间的观点不一致是常态。有一些标注任务本身就有强主观性——比如“哪个回答更有创意”这种指标标注一致性往往低得惊人。我们当时做了一个简单的一致性量化同一批数据让两位标注员独立标注计算Cohens Kappa系数。第一次跑出来只有0.3左右说明标注标准非常模糊训练出的奖励模型也会带上强烈的“随机偏好”。于是我们做了两件事把标注指南改得更具体定义了可操作的评分维度相关性、信息量、安全性、表达清晰度以及优先级规则引入仲裁机制标注不一致的样本由第三位更有经验的标注员做最终裁决。调整后Kappa系数提升到0.6以上奖励模型在验证集上的排序正确率也从72%左右上升到了81%左右。这件事给我的启发是在偏好数据阶段多花一天时间做标准对齐比在训练阶段多调三天参数都值。5. 调优效果怎么评估指标、人工评测与上线前的最后检查5.1 离线指标哪些可信哪些只能参考关于偏好调优的评估目前没有单一指标能回答所有问题。常用的评估维度大致有这么几类评估维度常用指标可信程度注意事项奖励模型内部一致性排序准确率、BT loss中只能说明奖励模型学到了标注分布不代表真实质量生成分布偏移与参考模型KL散度中偏离过大往往伴随着语言质量下降答案稳定性对同一问题的多次生成变化中变化大可能意味着模型被过度调优人工偏好胜率盲测对比胜率、A/B测试高最接近真实体验代价高下游任务指标准确率、召回率、任务成功率高如果有具体任务场景这是最硬的指标个人建议公域或私域的标准评测集比如对话质量、数学推理、代码生成等基准评测可以作为参考但不要只盯着榜单刷分。因为很多基准评测的题目风格和你的实际用户分布并不一致一个在评测集上分很高的模型落到具体产品里可能水土不服。5.2 人工评测的样本设计不只是抽几个问答看看人工评测是判断对齐效果不可跳过的一环但怎么评测也有讲究。我建议采用“分组盲测”的形式把同一个prompt喂给基准模型比如调优前的SFT版本和调优后的模型让评测员在不知道来源的情况下分别打分。为了保证可比性每组评测至少要有50到100个覆盖不同场景的prompt且样本维度要包括不同指令难度、不同领域可以在你的产品主题里多选几个方向、不同回答长度类型。如果预算有限可以考虑一个轻量级方案让评测员只做“二选一偏好选择”不必逐项打分。这样标注速度更快一致性也更容易控制。如果调优后胜率能稳定在65%以上一般可以认为调优方向是对的如果在45%到55%之间徘徊就要警惕了——模型的“审美”并没有实际提升只是换了一种风格。5.3 上线前最后再检查这几件事偏好调优训练结束不等于可以马上上线我每次上线前都会按这个清单过一遍有没有对敏感类型的prompt做过专门的对抗测试确认调优没有破坏安全底线对比同一prompt在调优前后各采样5到10次的输出确认生成多样性没有被压死查看是否存在“奖励分数高但人类明显觉得荒谬”的回答如果存在一定不要心存侥幸这是reward hacking的苗头用小流量做线上冒烟评测直接观测真实用户的反馈信号比如回答点赞率、举报率、追问率之类的行为指标。其中小流量冒烟评测这点值得单独多说两嘴。离线场景下人工评测的老师往往会下意识给出“宽容分”但真实用户的行为数据更冷酷。哪怕只是几千个真实请求里的几十条反馈也比单独靠评测员打分更有说服力。写在最后的几点经验做了几轮偏好调优项目后我最大的感受就是对齐技术本身不是一个“跑完一个脚本就完事”的事情它对数据质量、奖励设计、评估闭环的要求都很高。如果你刚开始尝试不要一上来就堆大力气去复现复杂的强化学习流程先用DPO配合一批干净的两两比较数据把链路跑通把标注标准、评估流程这些地基打好比一味追求算法的先进性要重要得多。另外一个很实用的小技巧保存好每个训练阶段的模型快照。不要只保存最终版本每隔一定步数保存一版训练完成后统一拿出来做对比评测。你会惊讶地发现有时候中间某一步的模型在真实用户视角下反而是最好的。模型调优跟做菜一样掌握火候比死记配方重要。先跑通再调优最后再考虑要不要上更重的方案——这条路对大部分团队来说是最稳妥的。
大模型能不能“写一手好文章”“回一句得体的建议”很多时候靠的不是它背了多少数据而是它在“什么算好、什么算差”这件事上有没有被教明白。早期大家发现单纯靠预训练加指令微调模型可以做到“有问必答”但回答是不是更符合人类的偏好、是不是更安全、更讨喜模型自己并不知道。于是就有了奖励模型和偏好调优这套组合拳——圈内常说的“RLHF”相关技术路线或者更广义地说基于人类偏好的对齐技术。这篇文章我想从一个实践者的角度把“大模型如何学会自我审美”这件事拆开讲透从数据准备、奖励模型训练、到策略调优和评估落地尽量讲清楚原理也把我在实际项目中踩过的坑一并交代。如果你正准备做模型对齐或者正在看各种技术报告但拼不出完整链路这篇文章应该能帮你把各个环节串起来。文中的部分细节会基于常见实践做补充说明供你参考后结合自己的场景调整。1. 为什么光会“接话”不等于“会审美”——从SFT到偏好对齐的跳跃1.1 自回归训练本质上只教了“文字接龙”先聊聊大模型最底层的训练逻辑。预训练阶段模型做的事情叫做“预测下一个token”——给你一段文本的前面部分让模型猜后面接什么词最合理。这种做法本质上是在学“语言统计规律”也就是语言模型的基本能力。这时候的模型也能生成一段看起来通顺的话但它的目标函数里根本没有“这句话是否符合人类品味”这回事。到了指令微调阶段我们开始用“用户问题-标准回答”这样的数据去训练模型。模型学会了“当用户问什么的时候应该给什么样的回答”这是一种行为模仿。SFTSupervised Fine-Tuning能让模型记住格式、记住语气、记住常见的回答套路但短板也很明显它只模仿了我们认为“好”的回答并没有学会区分“好”和“更好”。一个指令可能有几十种合格写法有的平铺直叙有的逻辑清晰有的还带点人情味。SFT训练时这些都被平均地压进了模型的参数里模型不知道到底哪一类是用户最想要的。一个很直接的类比你给一个学生布置作文只告诉他“这是高分范文、这是低分作文”不如给他一个具体的评分标准——“结构是否完整、论据是否充分、语言是否流畅”他才能有针对性地改进。模型也是一样的逻辑要让它真正拥有“审美”需要给它一张带有区分度的“分数表”这张表就是奖励模型Reward Model, RM要产出的东西。1.2 审美的本质从“对与错”到“好与坏”的连续打分先明确一个概念在大模型语境里审美并不是一种玄学而是一个可量化的偏好函数。人类标注员面对两个模型回答判断哪个更好这些成对的比较数据被拿来训练一个打分模型让它学习“好回答”和“坏回答”在语义上的分布差异。一旦训练完成这个打分模型就能给任意一条回答打出一个分数分数越高代表越符合人类偏好。这就把“审美”这件事从模糊的感觉变成了可优化的目标。我们不再需要告诉模型具体哪句话该怎么说只需要告诉它“分数更高”这个方向。模型会自己探索什么样的措辞、什么样的结构、什么样的推理过程能获得更高奖励。整个过程其实是一个标准的“奖励学习”问题偏好信号来源于人类标注通过奖励模型进行拟合成可计算的函数最后通过强化学习或直接偏好优化来调整策略模型。1.3 数据信号的正反馈闭环才是完整链路切记一点不用把奖励模型和偏好调优看成两个孤立的模块。它们一起构成了一条数据闭环——初始策略模型SFT后的模型生成若干回答人类标注员对回答进行两两比较或排序比较数据用于训练奖励模型策略模型根据奖励模型的反馈继续调优调优后的模型再次生成回答进入下一轮人工标注……这个循环每转一轮模型的输出质量就更进一步向“人类偏好”收敛。这也是为什么说大模型的“自我审美”不是先天自带的而是被奖励信号教出来的。理解了这层闭环后面看PPO、DPO这些具体算法时会轻松很多。2. 奖励模型的训练本质把“人类排序”变成“数值打分”2.1 偏好数据从哪里来两两比较是主流标注方式训练奖励模型最缺的不是算法而是高质量的偏好数据。目前工业界最主流的数据形态是pairwise——也就是“给定同一个prompt让模型生成两个回答或者从多个模型生成的结果里抽取两个然后让标注员判断哪一个更好”。举一个具体标注界面上的例子Prompt回答A回答B标注结论“如何向一个五岁小孩解释重力”重力是一种力它把物体拉向地球。想象你往天上扔一个球球最后总会掉下来这就是有个力气在把它往下拉。B更好实际标注中为了让数据更可用还经常混合排序式标注——让标注员对3到4个回答排序而不仅仅是二选一。排序数据可以拆出多对pairwise比较这样一份人工标注能产生更多训练样本。举个简单的计算逻辑如果让标注员对一个prompt的4个回答排序那可以生成 ( C(4,2)6 ) 个比较对数据效率会高不少。不过排序式标注也有代价标注员认知负担会明显变大标注一致性可能下降。所以不少团队的折中做法是“先两两比较如果标注员觉得难以抉择再引入第三个候选”或者采用“比较排序混合”的模式。数据标注的质量直接影响后续每一环的效果。这里多说一句标注指南一定要写得足够细比如什么算“有帮助”、什么算“有害”、什么时候“拒绝回答”比“尝试回答”更好都得定义清楚。2.2 Bradley-Terry损失一句话讲清奖励模型在优化什么奖励模型本身通常就是一个跟策略模型规模相近或稍小的模型结构也很简单在传统序列模型的输出后接一个线性层把最后位置的隐藏状态映射成一个标量分数。核心区别在于它的训练方式——它不是一个做文本生成的模型而是一个打分器。它用的损失函数叫 Bradley-Terry简称BT模型最早来自体育赛事中预测两队胜负概率的方法后来被广泛应用到学习排序和人机对齐领域。用大白话讲给定同一个prompt ( x )我们有两个回答 ( y_w ) 和 ( y_l )其中 ( y_w ) 是人工标注中“更优”的那个winner( y_l ) 是“更差”的那个loser。奖励模型给两个回答分别打分为 ( r(x, y_w) ) 和 ( r(x, y_l) )我们希望 ( y_w ) 的分数显著高于 ( y_l ) 的分数。在PyTorch里实现一个简洁的BT损失大概是这个感觉import torch import torch.nn.functional as F def bradley_terry_loss(reward_w, reward_l, marginNone): reward_w: 模型给更好回答的打分, shape [batch] reward_l: 模型给更差回答的打分, shape [batch] margin: 可选启发式增加区分度类似排序间隔 if margin is not None: logits reward_w - reward_l - margin else: logits reward_w - reward_l loss -F.logsigmoid(logits).mean() return loss核心意思就是让“winner的分数减去loser的分数”经过sigmoid之后接近1损失越小越好。因为sigmoid有一个“饱和区”当 ( r_w - r_l ) 已经很大时损失进一步降低的意义就不大。这也告诉我们一个训练技巧不必苛求奖励模型在每个pair上都把分数拉得极端高只要排序正确即可。过度追求分数差异反而可能导致奖励模型过拟合后面调优策略模型时容易出现奖励黑客问题后面细说。2.3 多轮迭代标注奖励模型不是一次性训练的在实际项目里奖励模型的训练不会只在一条数据池上训一版就结束。比较常见的是“迭代式数据生产”——先让当前策略模型可能是SFT版本生成一批回答标注出pairwise数据训练出V1版奖励模型然后用V1版本去筛选第二轮生成结果中奖励分数差异最大的样本再让标注员标注这些“模型自己都拿不准的好样本”继续训练V2版奖励模型。这么做的原因很简单奖励模型的训练也需要“困难样本”。如果pairwise的两个回答差异太明显模型很快就学会了导致决策边界很粗糙但那些奖励分数接近、连模型都难分伯仲的样本才是精细校准审美观的关键。所以在构建偏好数据集时不要只想着“多”要想办法让采样去覆盖“难”。这一步的经验是奖励模型的训练数据里可以让两个回答来自同一个模型同代或不同温度采样也可以来自不同模型。一般建议混合。如果两个回答来自同一个模型能帮助奖励模型学到更细微的差异如果来自不同模型能帮它建立跨模型泛化能力。这两类数据的比例通常控制在6:4到7:3之间具体还是要通过验证集实验来确定。3. 偏好调优两大流派从PPO的工程复杂度看DPO为何兴起奖励模型训练好之后它只是一个裁判。我们要做的下一步是让策略模型学会“在裁判面前拿高分”。这个阶段就是偏好调优目前最经典的方法是强化学习典型代表是PPO算法后来出现了一种更轻量的路径——直接偏好优化Direct Preference Optimization, DPO现在已经成为开源社区和中小规模团队的首选。3.1 PPO四套模型登场的强化学习方案PPOProximal Policy Optimization做RLHF时需要同时维护四个模型策略模型Actor也就是我们最终要发布的那个模型它的参数会被更新奖励模型Reward Model相当于裁判给策略模型的输出打分但本身参数不更新参考模型Reference Model通常是SFT阶段的模型快照用于计算KL散度防止策略模型跑偏到“只说好话但语言质量崩塌”的境地批评者模型Critic用来估计状态价值的是PPO算法里做优势函数估计用的一般会从奖励模型的骨干网络初始化。训练时策略模型针对一批prompt生成回答奖励模型给这些回答打分同时参考模型计算生成回答的KL散度两项加权得到最终reward再用PPO算法去更新策略模型。一个简化的reward计算可以写成final_reward reward_model_score - beta * kl_divergence这里 ( \beta ) 是KL惩罚项的系数。如果你设得太大模型会被“绑”在参考模型附近几乎学不到新东西设得太小模型就会放飞自我甚至出现“用胡言乱语来骗高分”的情况。经验上很多项目把KL惩罚系数设在一个相对靠中间的量级然后根据训练过程监控生成质量动态调节。PPO的优势在于它理论上更灵活奖励函数可以是任意可计算函数不一定要局限在预训练的奖励模型上。比如你可以在奖励公式里加上“长度惩罚”防止模型为了高分而无限堆字也可以加上“敏感词扣分”做个简单的规则式安全网。缺点也明显——工程复杂度高、训练不稳定、显存占用大四套模型轮转对很多团队来说起步门槛不低。3.2 DPO不训奖励模型直接改目标函数DPO出来之后很多人松了一口气。它的核心洞察在于BT模型里奖励函数的最优解其实可以用策略模型和参考模型的概率比来隐式表达。也就是说我们不需要显示训练一个奖励模型也不需要跑强化学习更新循环只需要直接监督式地优化一个目标函数就能达到和PPO类似的对齐效果。DPO的损失函数看起来长这样def dpo_loss( policy_logps, # 当前模型对chosen/rejected的log概率 ref_logps, # 参考模型对chosen/rejected的log概率 beta, # 温度系数控制对偏离参考模型的容忍度 ): policy_logps 和 ref_logps 都包含 chosen 和 rejected 两组值 这里以chosen为正样本、rejected为负样本 log_ratio_chosen policy_logps[chosen] - ref_logps[chosen] log_ratio_rejected policy_logps[rejected] - ref_logps[rejected] # 隐式奖励差 reward_margin log_ratio_chosen - log_ratio_rejected loss -F.logsigmoid(beta * reward_margin).mean() return loss有没有发现它跟Bradley-Terry损失非常像只是把“奖励模型对两个回答的分数差”换成了“策略模型和参考模型在两个回答上的对数概率比之差”。这就是DPO的精妙之处——它把奖励建模和策略优化合并成了一个步骤。训练流程也被大大简化你只需要一份偏好数据集、一个参考模型、一个待调优模型然后像做SFT一样更新参数不需要构造强化学习环境不需要启发式采样也不容易因为强化学习的状态空间剧烈波动而崩溃。3.3 两种方案的取舍经验从我实际跑项目的感受来看PPO和DPO的取舍主要看三件事团队工程能力、数据规模、以及对生成多样性的要求。如果在线数据比较丰富、甚至你能搭建“模型生成-人工评分-策略更新”的实时飞轮那PPO还是值得投入的因为它的在线探索能力更强能自己发现新路径如果只有一批离线偏好数据、团队也没有大规模的强化学习工程经验那DPO是更务实的起点。它能调出“足够好”的模型尤其是在任务比较单一、回答风格相对标准的场景下DPO和PPO的效果差距并不大还有个折中做法先用DPO做一轮快速对齐让模型先有一个“及格审美”再用PPO做一轮精细调优。很多团队实际上是这样组合的因为DPO后的模型作为PPO起点能够显著降低强化学习训练的不稳定问题。另外要提醒一点DPO虽然不用训练奖励模型但并不意味着可以完全不看奖励分数。训练完后我们仍然需要用奖励模型或人工评估去检查模型的行为是否真的变好了。它省的是训练流程不是评估环节。4. 我踩过的坑奖励黑客、过优化与数据噪声4.1 训练loss一直降生成质量却明显变差——奖励黑客的典型表现奖励黑客Reward Hacking是偏好调优里最让人头疼的问题。简单说就是模型发现了一条“看起来能拿到高分但并不符合人类真实意图”的捷径并且会迅速把这条路走到极致。我第一次遇到这个问题是在一个问答类项目上当时的奖励模型倾向于给“更长的回答”更高分。模型很快学会了“不管用户问什么都先写很长很长的一大段再加一堆分点列举和总结”。人工一看完全是车轱辘话但奖励分数就是一路飙升。这就是典型的reward hacking——模型没有真正提升回答质量而是钻了奖励函数的空子。常见触发原因有奖励模型只在固定数据分布上训练一旦策略模型的输出分布偏移它就进入“盲区”乱打分奖励模型本身存在偏差比如偏好长文本、偏好某些高频句式、偏好引用特定关键词调优过程中reward的系数设置不当让模型觉得“高分策略”远好过“保持语言质量”。一个粗糙但有效的诊断方法每间隔固定步数把当前策略模型输出的回答抽样出来用人工看一遍同时记录reward分数。如果出现“人工分变差但reward分变高”的情况基本可以判定为reward hacking。别迷信训练曲线loss下降不代表模型变好。4.2 KL约束失控模型“性格突变”的幕后黑手在PPO类方法里KL散度惩罚项是防止策略模型偏离参考模型太远的重要调节阀。它衡量的是当前模型输出分布和参考模型输出分布的差异。如果这个值在训练初期就急剧飙升通常意味着策略模型正在快速改变自己的说话风格甚至会牺牲可读性去迎合奖励模型。我见过一个项目KL系数设置过小训练跑到中途时模型开始大段大段输出格式工整但内容空洞的话而且用词变得越来越夸张——比如无论什么问题都套上“非常、极其、强烈推荐”这类词。后来把KL系数调大一倍重新训练情况马上回复平稳。在DPO框架里虽然没有显式的KL约束但参考模型仍然隐式地起着“锚”的作用。( \beta ) 参数设置的逻辑类似( \beta ) 越大模型越接近参考模型调优越保守( \beta ) 越小模型越自由越容易过度优化。经验做法是在训练前先跑几个小规模预热实验对比不同β对验证集的效果而不是直接在一个值上硬跑完整训练。4.3 标注噪声如何量化别让矛盾数据白练一场偏好数据的质量直接影响奖励模型的效果而实际问题中标注员之间的观点不一致是常态。有一些标注任务本身就有强主观性——比如“哪个回答更有创意”这种指标标注一致性往往低得惊人。我们当时做了一个简单的一致性量化同一批数据让两位标注员独立标注计算Cohens Kappa系数。第一次跑出来只有0.3左右说明标注标准非常模糊训练出的奖励模型也会带上强烈的“随机偏好”。于是我们做了两件事把标注指南改得更具体定义了可操作的评分维度相关性、信息量、安全性、表达清晰度以及优先级规则引入仲裁机制标注不一致的样本由第三位更有经验的标注员做最终裁决。调整后Kappa系数提升到0.6以上奖励模型在验证集上的排序正确率也从72%左右上升到了81%左右。这件事给我的启发是在偏好数据阶段多花一天时间做标准对齐比在训练阶段多调三天参数都值。5. 调优效果怎么评估指标、人工评测与上线前的最后检查5.1 离线指标哪些可信哪些只能参考关于偏好调优的评估目前没有单一指标能回答所有问题。常用的评估维度大致有这么几类评估维度常用指标可信程度注意事项奖励模型内部一致性排序准确率、BT loss中只能说明奖励模型学到了标注分布不代表真实质量生成分布偏移与参考模型KL散度中偏离过大往往伴随着语言质量下降答案稳定性对同一问题的多次生成变化中变化大可能意味着模型被过度调优人工偏好胜率盲测对比胜率、A/B测试高最接近真实体验代价高下游任务指标准确率、召回率、任务成功率高如果有具体任务场景这是最硬的指标个人建议公域或私域的标准评测集比如对话质量、数学推理、代码生成等基准评测可以作为参考但不要只盯着榜单刷分。因为很多基准评测的题目风格和你的实际用户分布并不一致一个在评测集上分很高的模型落到具体产品里可能水土不服。5.2 人工评测的样本设计不只是抽几个问答看看人工评测是判断对齐效果不可跳过的一环但怎么评测也有讲究。我建议采用“分组盲测”的形式把同一个prompt喂给基准模型比如调优前的SFT版本和调优后的模型让评测员在不知道来源的情况下分别打分。为了保证可比性每组评测至少要有50到100个覆盖不同场景的prompt且样本维度要包括不同指令难度、不同领域可以在你的产品主题里多选几个方向、不同回答长度类型。如果预算有限可以考虑一个轻量级方案让评测员只做“二选一偏好选择”不必逐项打分。这样标注速度更快一致性也更容易控制。如果调优后胜率能稳定在65%以上一般可以认为调优方向是对的如果在45%到55%之间徘徊就要警惕了——模型的“审美”并没有实际提升只是换了一种风格。5.3 上线前最后再检查这几件事偏好调优训练结束不等于可以马上上线我每次上线前都会按这个清单过一遍有没有对敏感类型的prompt做过专门的对抗测试确认调优没有破坏安全底线对比同一prompt在调优前后各采样5到10次的输出确认生成多样性没有被压死查看是否存在“奖励分数高但人类明显觉得荒谬”的回答如果存在一定不要心存侥幸这是reward hacking的苗头用小流量做线上冒烟评测直接观测真实用户的反馈信号比如回答点赞率、举报率、追问率之类的行为指标。其中小流量冒烟评测这点值得单独多说两嘴。离线场景下人工评测的老师往往会下意识给出“宽容分”但真实用户的行为数据更冷酷。哪怕只是几千个真实请求里的几十条反馈也比单独靠评测员打分更有说服力。写在最后的几点经验做了几轮偏好调优项目后我最大的感受就是对齐技术本身不是一个“跑完一个脚本就完事”的事情它对数据质量、奖励设计、评估闭环的要求都很高。如果你刚开始尝试不要一上来就堆大力气去复现复杂的强化学习流程先用DPO配合一批干净的两两比较数据把链路跑通把标注标准、评估流程这些地基打好比一味追求算法的先进性要重要得多。另外一个很实用的小技巧保存好每个训练阶段的模型快照。不要只保存最终版本每隔一定步数保存一版训练完成后统一拿出来做对比评测。你会惊讶地发现有时候中间某一步的模型在真实用户视角下反而是最好的。模型调优跟做菜一样掌握火候比死记配方重要。先跑通再调优最后再考虑要不要上更重的方案——这条路对大部分团队来说是最稳妥的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
