做模型训练这几年，我最大的感受是：很多人把"训练"当成一个单点操作，以为拿一堆文本喂进去，等loss降下来就完事了。但真正跑过完整研发线的人都清楚，从一堆无标注的原始语料到最终一个稳定可用、符合人类口味的对话模型，中间隔着一条完整的训练链路，它不是一步，而是很多步。这篇文章不打算做百科式罗列，我围绕五种主流大模型训练方式——预训练、监督微调（SFT）、奖励模型（RM）、RLHF偏好对齐、DPO直接偏好优化——把每个阶段的核心目标、数据形态、训练原理、超参数经验和最容易翻车的细节讲透。这五条路是层层递进的关系：预训练建地基，SFT学对话形式，RM定义好坏，RLHF/DPO做偏好对齐。理解完整链路之后，你再看任何训练工程，心里都会有一张地图。

下面这张速览表可以先帮你建立全局视角，后面逐段展开。

1. 预训练：用自监督目标在原始语料里建立能力地基

预训练是所有大模型的起点。它的目标非常朴素：给模型一堆没有标注的文本，让模型自己学会"预测下一个词是什么"。就是这样一个看起来极其简单的任务，在足够大的数据和足够大的模型规模下，会涌现出语法、事实知识、逻辑推理甚至一部分上下文学习能力。

1.1 为什么Next Token Prediction能学出"智能"

很多人第一次听说预训练时会觉得很反直觉：为什么预测下一个词这么无聊的任务，最后能训出能写代码、能推理的模型？关键在于，自然语言文本本身是高度压缩的人类思考产物。模型在预测下一个词时，为了降低损失，必须建立对前文语义、实体关系、事件因果、甚至言外之意的深层表征。

这相当于让模型做一个无限长的完形填空。题目里没有标准答案，唯一的监督信号就是"真实文本中下一个词是什么"。为了不预测错，它被迫学会语法规则、学会对应关系、学会常识，甚至学会在长文本里保持局部一致性。这里有个很重要的工程认知：预训练阶段不需要人工标注，自监督信号天然免费，因此可以把数据规模推到非常大。这也是预训练能成为"通用能力底座"的根本原因——它不是被谁教出来的，而是从几十亿、上百亿个预测任务里自我组织出来的。

1.2 数据是预训练的隐形胜负手

模型架构和算力配置可以照搬成熟方案，但数据工程没法照搬。预训练阶段最常见的坑，不是训练不稳定，而是数据没做好。我参与过的项目里，好几轮训练曲线看着很漂亮，但下游评测分数不涨，最后追查下来，问题都出在数据配比和清洗上。

预训练语料有几个核心处理环节：

• 清洗：去除乱码、敏感内容、格式异常、模板广告和无意义的重复片段。
• 去重：包括精确去重和模糊去重。重复数据会让模型产生严重记忆，表现为生成时大量复述原文、创造力下降。实践上，不仅是文档级去重，还要做段落级和窗口级去重。
• 质量过滤：不是所有网页文本都有价值。经验上是按质量分层，高质量书籍、论文、专业文档要保留并提高权重，低质量社交文本大幅降权或直接剔除。
• 配比设计：常见的做法是网页语料占大头（提供广度），书籍和论文提供深度，代码语料提升逻辑能力，多语言语料占比取决于目标市场。代码比例尤其关键——代码里的强逻辑和严格语法，对模型推理能力的提升远超同样比例的普通文本。

还有一个容易忽略的细节：预训练语料必须有严格的时间切分。训练集和评测集必须严格隔离，否则模型在预训练阶段就"见过"评测题，之后你用任何评测集评估都是在自欺欺人。

1.3 训练配置的工程经验与loss spike排查

预训练超参数的常见实践范围，我直接给一套经过验证的经验值，方便新手上手参考：

• 学习率：峰值一般取 1e-4 到 3e-4（7B-13B规模常见），采用warmup + cosine decay策略。warmup阶段通常占训练总步数的 1%-3%，从峰值学习率的十分之一左右起步，线性升到峰值。
• 批量大小：按token数计算，工业界常用几百万甚至上千万token的大批量。大批量能平滑梯度估计，但相应的学习率要调高，两者存在近似线性关系，这在scaling law里已有总结。
• 优化器权重衰减和梯度裁剪：梯度范数通常裁剪到 1.0，防止个别异常batch破坏参数更新。
• 混合精度与分布式：训练基本都以bf16为主，配合ZeRO分片或张量并行。这个阶段要重点盯两个量：吞吐量（Tokens/s）和loss曲线的平滑度。

loss spike是最常见的问题。所谓 spike，就是loss曲线在正常下降过程中突然出现一个尖峰，然后又恢复。原因是某个batch里混入了异常数据块（比如损坏编码、超大重复段落、或某个文档截断异常）。处理经验：

1. 先确认spike是否带来梯度范数飙升，如果梯度范数同步飙升，多半就是这个batch的问题。
2. 紧急处理是降低当前batch的学习率或直接跳过该batch，但更根本的做法是从数据管线里找出异常源并修复。
3. 如果spike反复出现，问题通常在数据pipeline，而非模型层面，不要盲目去调学习率。
4. checkpoint策略要足够密集，建议每小时至少保存一次，并且训练脚本必须支持从任意checkpoint恢复。一次大规模预训练动辄几十天，分布式环境难免出现节点故障，断点续训设计不做好，一次故障可能浪费好几天算力。

预训练阶段的评估，我建议只看三项：loss曲线、通用能力抽查集（一组固定题目的回答或选择题，注意不能被训练数据污染）、以及生成样式的抽样观察。不要频繁跑完整下游评测，那既浪费算力，也容易让你过早陷入细节优化而忽略全局。

2. 监督微调(SFT)：把"会续写"变成"会听话"

预训练完成的模型，本质上是一个语言生成器。你给它任何前缀，它都会按概率续写，但不会"回答问题"——因为它根本没有"问题-答案"这种交互概念。SFT要解决的就是这个最朴素的问题：让模型学会人类期待的对话交互形式。

2.1 指令数据怎么构造：模板、对话格式与token级细节

SFT数据的基本单元是指令-回复对，实际工程里会拆成更具体的结构：系统指令（System）、用户输入（User）、期望输出（Assistant），多轮场景还要带历史上下文。这些字段在训练时不会直接以明文拼接，而要经过对话模板转换成模型专门训练过的特殊token序列。很多人只关注"文本内容"而忽略模板格式，结果模型输出格式混乱、角色错位。这个部分必须和最终推理服务的提示词完全一致，否则就是训练-服务不一致，上线必翻车。

数据质量优先于数量。不少团队用几千条到两三万条高质量指令数据，就能把一个基础模型调成可用的垂类助手；反而直接灌入几十万条低质量"他山之石"数据，会让模型学习到错误的回答习惯。数据构造几个关键点：

• 任务多样性：至少要覆盖问答、总结、改写、抽取、分类、代码生成、数学推导、多轮角色扮演等常见任务。只重复一种任务，模型会固化套路。
• 错误样本修正：凡是进入SFT的数据，必须假设模型会一字不差地模仿。所以答案里如果有事实错误、逻辑跳跃、语气不当，都会被模型学走。数据清洗不仅是"删掉坏样本"，还要修正错误答案。
• 难度和长度分布：回复长度要有意识拉开分布，保证短回答和长回答都有，避免模型总是输出等长的"标准段落"。

2.2 学习率、epoch与过拟合判断

SFT阶段训练参数和预训练有显著差异，最核心的区别是：预训练在教新知识，SFT主要是改行为方式，学习率必须低得多。

全参数SFT的经验学习率范围是 1e-5 到 2e-5，比预训练低了约一个数量级。原因很简单：基座模型已经学会了大量语言知识和推理能力，过高的学习率会把这些宝贵参数"冲掉"。SFT更像是微调表层行为，而不是重新学习。

训练epoch数一般控制在 1-3 之间。我见过很多团队一上来就跑10个epoch，训练loss确实降到很低，但生成结果出现大量重复、风格僵化、知识遗忘。判断是否过拟合，不要只看训练loss，要看这三个信号：

• 验证集loss开始回升，或验证badcase数量反弹。
• 模型生成的回复长度趋于单一，句式重复率高。
• 原本能回答的通用知识问题开始答错，出现灾难性遗忘。

另外要提到LoRA。LoRA在SFT阶段的应用已经非常成熟，它只训练少量低秩矩阵，参数效率极高，显存占用大幅下降。LoRA适配器训练时的常用rank是 8-64，学习率可以比全参略高，1e-4 到 2e-4 之间比较常见。先在少量高质量数据上训练LoRA，效果不行再扩数据，这一套流程在资源有限的项目里非常实用。

2.3 灾难性遗忘问题与通用语料混合

SFT最常见的问题是灾难性遗忘。模型在大量指令数据上训练后，会逐渐忘记预训练时学到的部分通用能力，表现为常识变弱、写代码变得模板化、长文本逻辑变差。

缓解方案是在SFT训练集里混入一部分通用语料，通常是预训练语料的子集，比例在5%-10%左右。这相当于让模型在学对话形式的同时，不忘掉原有的世界知识。做法上要注意通用语料不能喧宾夺主，否则指令遵循能力会被冲淡。一个相对稳妥的做法是：指令数据与通用数据交叉混合，而非按epoch分段训练，这样模型每个batch都能同时看到两种分布。

SFT之后一定要及时做人工badcase测评，重点关注：格式稳定性、指令遵循率、是否出现幻觉。这个阶段的反馈会直接影响后续对齐数据的设计，不要直接跳到RLHF才发现问题源头在SFT。

3. 奖励模型：给偏好对齐配一个可计算的裁判

SFT把模型调成了"会答话"，但它不知道"哪些回答更好"。两个回答语法都对、格式都对，一个直接清晰，一个啰嗦且错误，模型无法区分。解决这个问题需要一个裁判，这个裁判就是奖励模型（Reward Model，简称RM）。RM的定位很特殊：它不是最终产物，而是给RLHF用的"质量函数"。

3.1 为什么需要奖励模型，以及偏好数据怎么收集

为什么不让人类直接给模型输出打分，还要训练一个RM？因为对齐需要的数据规模远远超过人类标注的承受能力。RLHF每次策略采样会产生海量回答，实时请人打分不现实。所以思路是：先让人类标注一批偏好数据，把"人类对质量好坏的判断"蒸馏进一个参数化函数，训练好之后，这个RM就能替代人类实时打分。

偏好数据的收集方式经历过一个重要转变。早期做法是让标注员给单条回答打绝对分（比如1-5分），后来发现绝对评分的一致性很差：同一个回答，不同标注员可能给出天差地别的分数。后来统一改成偏好对比对（pairwise comparison）：给标注员看同一个问题的两个回答，让他们判断哪个更好。人类的相对比较比绝对打分稳定得多，这是RM数据标准化的关键经验。

标注时还有一个经验：不仅让标注员选"哪个更好"，还要记录"为什么更好"（更准确、更简洁、更礼貌、更安全）。这些理由可以在数据清洗阶段用来判断标注质量，也能在后续RM误差分析中定位问题。如果标注员之间的一致性低于某个阈值，这批数据就要重新标注，否则训练出的RM本身就是个"众说纷纭的裁判"。

3.2 RM的训练结构与pairwise损失

RM的典型结构是在基础模型之上接一个标量输出头，这个头输出一个分数。基础模型通常使用与SFT模型同源、且规模相近的模型（甚至直接复用SFT后的模型再加一个head），不要从完全不同的模型搭。因为RM必须理解真实用户问题的语义偏好。

训练数据格式是一个pair：(prompt, chosen_response, rejected_response)。核心损失函数是一个pairwise排序损失，本质很简单：

loss = -log(sigmoid(r_chosen - r_rejected))

其中r_chosen是模型对优选回答的打分，r_rejected是对劣选回答的打分。优化目标就是让好回答得分高于坏回答。用语言描述就是：一个二分类任务，判断"chosen是否排在rejected前面"，通过排序优化让分数差越大越好。

数据配对上有个技巧：同一个prompt如果有多个回答，可以组成多个pair，比如一个chosen搭配多个rejected。这样能提高同一份标注数据的利用效率。但要注意，如果chosen在所有pair里反复出现，模型容易对这个固定答案产生过度偏好，所以最好用人工挑选的方式组pair，避免机械枚举。

RM训练还有几个容易忽略的细节：

• 打分初始化：reward head的初始输出要接近0，不能让模型一开始就输出极端分数，否则训练早期会非常不稳定。
• 分数分布监控：训练过程中定期看整体打分分布，如果所有分数挤在0附近，说明模型没有区分力；如果两极分化严重，可能是loss过拟合或数据有偏。
• epoch可以比SFT稍多，2-5个epoch都常见，但同样要防过拟合。

3.3 reward hacking与标注质量审查

RM训练最大的坑是reward hacking。模型非常擅长寻找分数中的"捷径"：如果标注数据里"长回答"普遍更受偏好，RM就会倾向给长回答高分；如果某个prompt里"包含固定关键词"的回答都被标为chosen，RM就学会了关键词加分。

后果是灾难性的：RM带着偏见进入RLHF后，策略模型会疯狂放大这些偏见，生成充满废话或套路关键词的回答。规避手段有几条：

• 标注时把长度、格式、风格等无关特征在pair间做平衡，保证chosen和rejected不能只在长度上有差异。
• 训练时加入长度归一化或控制特征，让模型不把长度当作核心判据。
• 定期检查RM在人工构造的"对抗样本"上的表现，比如故意把正确答案缩短、把错误答案加长，看RM是否被表象欺骗。

再说说标注一致性审查。RM训练集少则几万对、多则几十万对，不可能逐条人工检查，但要抽样。我通常抽样5%-10%做二次审查，重点看标注员的"理由"和"选择"是否一致。如果发现某批标注员大量出现"理由标明A好但选中B"的情况，宁可丢弃整批数据，也不要让它污染RM。RM的质量上限直接决定RLHF的上限，很多团队在RM上花的精力比RLHF本身还多，这并非夸张。

另外，RM通常不止一个。工业界常见做法是按维度拆成多个奖励模型：有用性、安全性、无害性、风格等各有独立的RM，最后加权合并。维度混在一个RM里容易互相干扰，比如安全性偏好会压制有用性。拆开之后每个维度都更纯粹，RLHF时按业务需要调整权重。

4. RLHF：让策略在试错中逼近人类偏好

RM训练完成后，真正的强化学习才上场。RLHF（基于人类反馈的强化学习）让模型不满足于"模仿标注好的答案"，而是通过采样试错、接受评价、更新策略，逐步逼近人类偏好的最优区域。这一阶段是整个链路里最复杂、也最容易训练失控的部分。

4.1 四个组件的角色：Actor、Critic、Reward Model、Ref Model

典型RLHF实现（以PPO为策略优化算法的做法）会同时维护四个模型，刚开始接触时容易绕晕。我习惯用一个团队来打比方：

• Actor（演员）：正在被训练的模型，就是你要交付的模型。它负责生成回答，并在训练中不断调整参数。
• Critic（评论家）：价值模型，负责评估每个token或每条轨迹的价值，说直白点就是"这台戏到这里，后面大概能拿多少分"，给优势计算提供依据。
• Reward Model（裁判）：我们上一章训练好的RM，对完整回答打分，是最终的评分来源。
• Reference Model（参考模型）：一个参数被冻结的"行为基准"，通常是SFT模型本身。它的作用是为策略更新的稳定性提供锚点。

4.2 PPO训练循环的关键环节

RLHF的每次迭代可以拆成四步：

1. 采样：Actor对一批prompt生成回答，生成方式通常带随机性（温度采样），以获得多样性的策略探索。
2. 打分：RM对回答打分得到激励信号；同时，参考模型对同一回答计算概率，用于KL约束。
3. 优势计算：综合RM分数和Critic价值估计，算出每个token的优势值。优势值直观理解为"这个动作比平均水平好多少"。
4. 更新：Actor按照PPO目标进行若干步小批量更新，Critic同时更新自己的价值预测。

PPO目标里有一个关键约束：那是一条KL惩罚项。它惩罚Actor的回答分布偏离参考模型太多。为什么必须有它？因为RM分数只是对"偏好"的近似，实际可能的空洞很多。如果没有KL约束，Actor会拼命往RM分数高的区域狂奔，把自己原有的语言能力、多样性、甚至基本可读性都丢光，产生所谓的"奖励过度优化"——生成一堆得分极高但人看着完全不对劲的文本。KL约束相当于拉着一根缰绳：你可以探索，但不能跑出参考模型的舒适圈太远。

经验超参数范围也分享一组：

• PPO内循环epoch数：1-3次，别多。多次在同一批rollout上反复更新很容易overfit到这批数据。
• clip范围：0.1-0.2，控制单次更新步幅。
• KL系数：常见范围0.01-0.1，需要根据模型规模和数据调整。系数太小约束形同虚设，太大则策略几乎不动。
• Actor学习率：通常比SFT还低，常见1e-6到1e-5。Critic学习率可以略高一点，1e-5左右。
• 每轮rollout的prompt数量：几百到几千不等，核心是让策略探索覆盖足够多样性。

4.3 KL约束与训练稳定性监控

RLHF训练不稳定是常态，重点不是"如何避免一切波动"，而是"如何尽早发现失控并手动干预"。我日常监控四个指标：

• KL散度：Actor与参考模型之间的分布距离。如果KL突然飙升，说明策略正在失控，需要降低学习率或提高KL系数。
• Reward均值与方差：均值稳步上升是正常信号，但上升太快要警惕。如果reward均值还在涨、生成质量肉眼下降，十有八九是reward hacking。
• 回答长度漂移：模型在RLHF中经常自发学会"写得更长来刷分"。长度如果快速拉长，建议直接加长度惩罚或降低长回答的奖励权重。
• 生成熵：熵快速下降说明模型正在坍缩成单一回答模式。一个好的对齐模型应该在保持偏好的同时保留适度的多样性。

还有一个来自实践的铁律：跑RLHF一定要保留初始的SFT模型作为对照。每次迭代完了都要拿SFT baseline和当前Actor在同一条评测集上做盲评，否则你根本判断不了"分数涨"到底是真变好，还是只是RM的偏见被放大了。

5. DPO：用偏好数据一步完成对齐

RLHF虽然效果强，但工程复杂度实在高：要训练RM、要在线采样、要维护四个模型、要调一堆超参数、时刻面对训练不稳定。于是DPO（Direct Preference Optimization）出现，目标是绕过复杂的强化学习流程，把偏好对齐变成一次普通监督训练。它最大的卖点是：不需要训练奖励模型，不需要在线采样，用现成的偏好对比对就能直接对齐模型。

5.1 DPO的推导直觉：把奖励变成策略比值

DPO的核心思想是先做一个数学变换。在RLHF的优化目标里，最优策略的奖励函数是可以被反推出来的：某个回答的隐式奖励，等于当前策略模型对该回答的对数概率减去参考模型对该回答的对数概率，再除以一个温度系数。

用人话说就是：如果当前模型比参考模型更喜欢某个回答，这个回答的隐式奖励就高；反之就低。既然如此，就没必要单独训练一个RM了。把隐式奖励代入偏好排序损失，最终得到DPO损失，只依赖当前策略模型和参考模型对chosen、rejected四个对数概率值。

我之前用一句话总结过DPO的本质：它把"模型是否足够偏好chosen且足够不偏好rejected"换算成一个简单的分类损失。数学上直接从RLHF目标推导而来，所以它并不是RLHF的粗糙近似，而是同一目标下的另一种求解方式。DPO的损失函数长这样，用代码风格写更直观：

loss = -log(sigmoid(beta * (log_pi_chosen - log_ref_chosen - log_pi_rejected + log_ref_rejected)))

其中log_pi_chosen是当前策略模型给chosen回答的对数概率，log_ref_chosen是参考模型给chosen回答的对数概率；rejected一组同理。β是温度系数，控制模型偏离参考模型的程度。β越小，模型越敢于偏离参考；β越大，模型越保守。

5.2 DPO实践参数与参考模型选择

DPO虽然训练形式上和SFT很像，都是梯度下降，但技巧差别不小。

• 参考模型必须冻结：参考模型在整个DPO过程中参数不动。它通常是SFT后的模型（与DPO初始模型一致）。不能用其他外部模型，否则策略比值的尺度会混乱。
• β值：常见范围0.1-0.5。起步可以试试0.1-0.2，如果发现模型风格变化过于保守，可增大β；如果生成内容偏移太远，则减小β。需要强调的是，β与学习率、数据规模存在相互作用，调参时要整体考虑，不要单点调整。
• 学习率：DPO的学习率通常比SFT还要低，常见范围1e-7到1e-6（大模型规模越大，这个值越要保守）。DPO对学习率比SFT更敏感，学习率太高会导致chosen侧概率被粗暴拉高、rejected侧被粗暴压低，生成质量断崖式下跌。
• epoch：1-3轮足够。DPO非常容易过拟合，因为偏好pair的监督信号远强于普通指令数据，模型很快就会把"训练集里的偏好规律"背下来。

数据方面，DPO对偏好pair质量的要求比RM更高。RM还可以通过大量略噪声数据靠统计规律压制噪声，DPO则是每个pair都直接改变策略分布。一个错误的反偏好pair，能抵消掉几十个正确pair的效果。所以DPO数据需要经过更谨慎的筛选：chosen和rejected之间要有足够的质量差距，不能是"两个都还行，只是不同风格"——这种模糊pair会产生近零的log-ratio，让训练信号变得非常不稳定。

还需要特别警惕DPO的一个隐藏副作用：长度作弊。标注员有天然的"长回答更好"偏见，偏好数据里的chosen普遍更长；DPO训练中模型会迅速学会这个规律，表现为回复长度在几个epoch内大幅上升，但内容质量并没有同步改善。对策有三种：一是在偏好数据构造时做长度匹配（chosen和rejected长度大致相当）；二是训练后统计长度漂移并单独压制；三是结合长度维度做二次筛选，把"只是因为更长才被选中"的样本剔除。

5.3 DPO与RLHF怎么选：一张对比表

在工程决策中，DPO和RLHF不是简单的"谁替代谁"，它们在数据依赖、算力需求、稳定性上差异明显，我直接给对比表。

那选型上到底怎么判断？如果你的团队有标注能力、有算力预算、对对齐质量要求极高，RLHF仍然是更强的路径；如果你只有几万、几十万个偏好pair，想在两周内看到模型行为明显改善，DPO是最性价比的选择。需要说的是，两者可以串行：先用DPO做一轮低成本的对齐，把核心偏好灌进去；再用RLHF做精细化打磨，减少DPO阶段可能带来的偏差。

6. 五种训练方式的搭配策略与常见误区

看完全链路之后，你可能会问：那我做自己的项目，该走到哪一步？不是每个项目都需要五步全走。训练方式不是越多越好，而是越适配越好。

6.1 不同资源和目标下的典型训练组合

第一类：垂直领域助手微调，资源有限，目标明确是私有数据的问答、客服、文档处理。推荐组合：开源权重底座 + LoRA SFT + DPO（可选）。预训练不需要做，底座已经具备语言能力；LoRA SFT注入领域知识和指令遵循；DPO用几百到几千个偏好pair，调整输出风格（更简洁、更专业、更安全）。这套方案可以在单卡甚至消费级显卡上完成，效果对大部分垂类场景足够。

第二类：自研基座模型，面向通用或大规模专用场景，需要掌控底层能力，预算和标注资源充足。推荐组合：完整预训练 → SFT → RM → RLHF，可以在进入RLHF前先做一轮DPO预对齐。预训练决定能力天花板，SFT确定交互形态，RLHF做精细偏好对齐。全链路周期长、投入大，但模型可控性和天花板是最高的。

第三类：有特定任务但不想训练。很多人忽略了，提示工程、外部知识检索、规则后处理能解决的问题，根本不需要动训练。先穷尽不训练方案，再考虑训练。训练是手段，不是目的。

6.2 质量门禁：训练前后的评测怎么设计

无论走哪条链路，训练阶段之间必须设置质量门禁，不要让错误传导到下游。我常用的五维评测表如下：

评测集必须单独建设，并明确隔离于训练数据。尤其在对齐阶段，不要反复用同一个评测集来挑模型，这会让模型过拟合到评测集上，上线即翻车。我见过不止一次：模型在评测集上分数一路走高，投入真实用户环境后效果反而更差，根因就是"刷榜"而不是"变好"。

6.3 三个最常见的认知误区

误区一：用更高阶的训练方式去弥补数据缺陷。SFT质量差，指望RM和RLHF自动修正，结果只会放大缺陷。每一层训练都在放大上一层的模式，而不是修正它。预训练语料脏，下游全链条吃亏；SFT数据错，再强的RLHF也只能学到一个"更精致的错误回答"。

误区二：认为DPO可以完全替代RLHF。DPO解决了成本问题，但没有解决探索问题。对于全新的偏好维度、需要模型自己试错的场景，在线采样的RLHF仍然不可替代。把DPO当成RLHF的廉价平替，只在简单风格偏好调整上说得通。

误区三：忽略评测集污染和标注偏差。从头到尾如果只有一套评测集、一批标注员，你所有的"提升"都可能只是适配了这套特定的评价体系。训练方式再主流，评价体系有偏，最终产品也不会真正满足用户需求。

最后说一点个人体会。训练方式没有绝对的高下之分，只有适不适合当前资源和目标。我自己的项目里，最深的教训是：每当你准备引入一种新的训练技巧，先问自己手里的数据能不能支撑这个技巧发挥价值。预训练是数据规模的生意，SFT是数据质量的生意，RM/RLHF/DPO是偏好定义和反馈质量的生意。技术链路越来越透明，门槛其实集中在数据和评测工程上——这个认知，比会调任何一套训练代码都值钱。