微调与对齐：SFT、LoRA、QLoRA、DPO、RLHF、RLAIF和偏好数据
摘要
本文把微调与对齐视为一个错误归因和行为塑形问题，而不是训练算法名词表。SFT、LoRA、QLoRA、DPO、RLHF、RLAIF 和偏好数据分别适合不同缺口：任务格式、表达习惯、偏好判断、安全边界和长期可维护性。文章强调，训练不能替代检索、权限、工具和运行时控制；只有先确认问题来自模型行为而非系统链路，再选择训练方法，微调才可能提高产品质量。对齐的目标也不是让模型机械听话，而是在有用、真实、可控和可恢复之间建立稳定策略。
关键词
监督微调；LoRA；QLoRA；DPO；RLHF；RLAIF；偏好数据；模型对齐；后训练
研究问题与方法
本文研究的问题是：面对模型错误，团队如何判断应该改提示词、补检索、加工具、做 SFT，还是进入偏好优化。方法上，文章把错误按来源分解为事实缺口、格式缺口、偏好缺口、基础能力缺口和系统缺口，再把每类缺口映射到成本、数据要求、评测方法和上线风险。这个框架避免把训练当成万能修补，也避免因为训练成本下降而忽略数据治理。
下图给出训练决策的归因流程。它的作用是把“模型不行”拆成可验证的问题，而不是直接进入 LoRA 或 DPO 脚本。
偏好优化可用 DPO 目标直观表示：
公式中的 与 分别代表更被偏好的回答和较差回答。它提醒我们，偏好数据不是普通标注文本，而是把产品价值判断编码进训练目标。
大模型微调与对齐经常被混成一句话：“把模型训成想要的样子。”这句话太粗。它掩盖了至少三层完全不同的问题：模型会不会做某类任务，模型会不会按用户和产品的要求表达，模型在冲突、诱导、风险和不确定场景里会不会作出可接受的选择。SFT、LoRA、QLoRA、DPO、RLHF、RLAIF 和偏好数据，分别站在这三层问题的不同位置。把它们当成一串名词背下来，不能指导生产系统；把它们放回数据、训练目标、成本、评测和上线治理里，才知道什么时候该用，什么时候不该用。
微调不是知识库的替代品。把一批企业制度、产品手册或历史工单拿去训练，不等于模型以后就能可靠回答最新事实。训练会改变模型参数，适合沉淀稳定能力、格式、风格、任务习惯和偏好边界；检索增强适合把经常变化、需要引用、需要权限控制的外部资料放进上下文。很多团队想用微调解决“模型不知道我的资料”，最后得到的是一个更自信却更难纠错的模型。真正的问题往往不是模型不会说话，而是证据来源、版本、权限和召回链路没有治理好。
对齐也不是把模型变得“听话”那么简单。一个只会迎合用户的模型可能会帮用户做错误甚至危险的事；一个只会拒绝的模型又无法完成真实任务。生产级对齐要同时处理有用性、真实性、稳定性、安全边界、表达方式、工具使用、成本和可解释性。RLHF 论文里常见的 helpful、honest、harmless，只是把问题拆开的入口。落到业务里，它会变成“能不能回答到点子上”“能不能承认不知道”“能不能引用证据”“能不能拒绝越权请求”“能不能在拒绝后给出可行替代方案”。
这篇文章从工程视角梳理微调与对齐。先分清预训练、持续预训练、SFT 和偏好优化，再解释 LoRA 与 QLoRA 为什么能降低训练门槛，接着讨论 DPO、RLHF、RLAIF 的数据和目标差异，最后落到偏好数据建设、评测、上线和回滚。重点不是追某个算法缩写，而是建立判断：现在的问题需要训练吗，需要哪类训练，需要什么数据，训练后如何证明它真的更好。
引言：先分清模型到底缺什么
训练方案选择前，最重要的问题不是“用不用 LoRA”，而是“模型缺的是什么”。如果模型缺的是领域事实，例如最新价格、组织架构、合同版本、接口状态、客户资料，那么优先做检索、工具和权限治理。模型参数不适合承载高频变化的事实，因为事实一旦变更，重新训练、评估、发布和回滚都比更新索引慢。即使训练样本里出现过某个事实，模型也不保证在所有问法下稳定记住，更不保证能区分新旧版本。
如果模型缺的是任务格式，例如总是不能稳定输出某个 JSON 结构、工单分类标签、客服话术段落或代码补丁说明，SFT 通常比单纯提示词更有价值。SFT 通过“输入到理想输出”的监督样本，把目标输出模式写进模型权重。它适合把重复发生、边界清晰、答案可示范的行为固化下来。前提是示范答案本身质量高，且能覆盖真实输入分布。
如果模型缺的是偏好判断，例如两个答案都没有明显事实错误，但一个更简洁、更可信、更符合品牌语气、更愿意承认不确定、更少过度拒绝，那么偏好优化更合适。DPO、RLHF、RLAIF 处理的不是“标准答案只有一个”的题，而是“哪个答案更好”的题。偏好数据告诉模型在同一 prompt 下应更接近 chosen，而远离 rejected。
如果模型缺的是底层能力，例如复杂数学推理、跨文件代码理解、多语言能力、视觉理解或长上下文综合，微调未必能补上。后训练可以放大已有能力、改善调用方式和稳定性，但很难用少量样本把基础模型没有学到的能力凭空训出来。OpenAI 在 InstructGPT 相关说明里也提到，指令对齐更像释放和引导预训练中已有能力，而不是用很少计算量重造模型能力。生产团队要承认这个边界，否则会把数据工程预算浪费在不可能的目标上。
还有一种缺口来自系统设计。模型答错并不总是模型问题。检索片段无关、上下文里规则冲突、工具返回原始日志、采样参数太激进、输出验证缺失、历史对话污染，都会让强模型表现像弱模型。训练前应该先做错误归因：同一个错误在清洁上下文下是否仍出现，强模型是否也失败，人工给出正确证据后模型能否改正，输出格式是否能通过 schema 约束解决。归因不清，训练只会把系统噪声写进参数。
微调、后训练和对齐不是同一件事
预训练通常指在大规模文本、代码、多模态数据上做通用语言建模，让模型学习语言规律、知识、推理模式和世界结构。这个阶段成本最高，也最不适合普通应用团队直接参与。持续预训练或领域继续预训练，是在基础模型上继续用领域语料做语言建模，例如医学论文、法律文件、代码仓库或企业文档。它可以改善领域语言适应，但不直接教模型如何回答问题。
SFT 是监督微调。数据一般是 prompt 与理想 response，或者多轮 messages。训练目标通常仍是下一个 token 预测，只不过目标文本变成了人写或高质量模型生成的答案。它教模型“遇到这类输入时，应该生成这种输出”。SFT 是很多指令模型、聊天模型、工具调用模型和行业模型的基础步骤。它简单、稳定、可解释，也容易因为数据差而过拟合。
偏好优化站在 SFT 之后。SFT 给出“会回答”的初始策略，但不保证这个策略在主观质量、拒答边界、事实谨慎度、语气和用户价值上最优。偏好优化使用成对或排序数据，让模型学习人类或规则体系更喜欢哪种输出。DPO 直接用偏好对优化策略；RLHF 通常先训练奖励模型，再用强化学习优化策略；RLAIF 则用 AI 产生偏好反馈来替代部分人类标注。
对齐是更大的目标，不等于某一种算法。SFT 可以对齐，DPO 可以对齐，RLHF 可以对齐，RLAIF 也可以对齐。对齐还包括系统提示词、模型规范、工具权限、内容安全策略、拒答设计、评测集、红队测试和上线监控。只把对齐理解成训练，会忽略运行时上下文和产品边界；只把对齐理解成过滤器，又会忽略模型内化偏好的价值。
后训练流程常见顺序是：先准备基础或指令基座，再用 SFT 建立任务行为，然后用偏好优化改善回答选择，最后通过评测、红队和灰度上线。这个顺序不是绝对的。小团队可能只做 LoRA SFT；平台团队可能先做领域继续预训练再做 SFT；安全团队可能用 RLAIF 大规模生成拒答偏好；内容产品可能只用 DPO 调整风格。关键是每一步都有清楚目标，而不是把所有术语堆进训练脚本。
SFT 教模型照着好样本工作
SFT 最适合解决“好答案可以被直接写出来”的任务。客服问题分类、标准回复生成、会议纪要格式化、代码审查意见风格、工具调用参数、结构化抽取、表格解释、产品文案改写、行业术语表达，都可以用 SFT 建立稳定模式。OpenAI 的监督微调文档也把结构化 JSON 输出和函数调用作为可训练方向之一，这说明 SFT 不只是让模型换口吻，也可以提升固定接口行为。
SFT 数据的核心不是数量，而是一致性和覆盖。十万条低质量样本会把模型拉向平均、啰嗦和自相矛盾；几千条精心构造的样本可能足以改变某类任务行为。每条样本都应该回答四个问题：输入是否来自真实分布，输出是否代表最终标准，字段和口吻是否一致，错误边界是否被覆盖。很多微调失败不是样本太少，而是样本之间互相打架。
多轮对话样本尤其要谨慎。一个 messages 样本里，系统信息、用户信息、助手回复、工具返回和最终回答各有角色。训练时如果把工具结果、内部字段、调试内容或审核备注当成助手自然语言，模型就可能在未来对用户泄露类似结构。生产数据进入 SFT 前必须脱敏、去内部说明、统一角色、清理无效轮次，并确保最终输出只面向用户。
SFT 还容易学到“表面风格”而不是“任务能力”。例如把一批优秀报告喂给模型，模型可能学会报告语气和标题结构，却没有学会如何判断业务事实。要训练真正任务能力，样本必须包含任务输入、必要证据、决策过程和最终输出之间的可学习关系。只给最终文章，不给资料和约束，模型学到的是文风；给出资料、问题、取舍和答案，模型才可能学到工作方式。
SFT 的评测不能只看训练 loss。loss 降低说明模型更像训练答案，但不说明更适合产品。应该用独立测试集检查准确率、格式成功率、引用正确率、拒答正确率、语气一致性、长尾输入表现和成本变化。过拟合时，模型会在训练分布里表现很好，在稍微不同的问题上变僵硬。尤其是小数据 LoRA SFT，最容易把少数模板记死，导致泛化下降。
LoRA 让微调从“改整个模型”变成“插入可训练小模块”
全量微调会更新模型大部分或全部参数。对于几十亿、上百亿参数的模型，全量微调需要大量显存、优化器状态和存储空间，还会为每个任务保存一份完整模型。LoRA 的核心思路是冻结原模型权重，只在部分线性层旁边加入低秩可训练矩阵。训练时只更新这些小矩阵，推理时可以把增量合并回原权重，也可以按适配器方式加载。
LoRA 背后的工程价值很直接。第一，训练显存大幅下降，因为可训练参数少很多。第二，任务适配器体积小，便于保存多个版本。第三，基础模型不变，回滚和对比更容易。第四，同一个基座可以服务多个业务，通过加载不同适配器切换能力。Hugging Face PEFT 文档也把 LoRAConfig 和 get_peft_model 作为常用入口，说明它已经成为开源微调生态的标准工具之一。
LoRA 的效果取决于注入位置、rank、alpha、dropout、学习率、数据规模和任务难度。rank 太小，表达能力不足；rank 太大，训练成本增加，也更容易过拟合。常见做法会在 attention 的 q、k、v、o 投影，或者 MLP 层上注入适配器。不同模型结构和任务对注入位置敏感，不能只复制别人配置。对工具调用、结构化输出、专业风格这类任务，较小 LoRA 往往足够；对复杂推理或深领域能力，LoRA 未必能弥补基座差距。
LoRA 不是廉价魔法。冻结基座意味着它更像在模型已有表示空间里调整行为，而不是彻底重塑知识结构。数据质量差时，LoRA 同样会学坏。基座模型已经强时，LoRA 改动过大反而可能破坏通用能力。训练后如果把适配器合并，仍然要记录基座版本、tokenizer、chat template、训练参数和数据版本，否则后续无法复现。
生产中还要处理多适配器管理。一个团队可能为客服、销售、代码、法务分别训练 LoRA。适配器多了之后，问题变成模型路由、权限、版本兼容和评测矩阵。某个适配器在基座 v1 上好，不代表在基座 v2 上还能用。每次基座升级都应该重新跑适配器回归，而不是默认兼容。
QLoRA 把显存门槛继续压低，但质量账仍要还
QLoRA 把 LoRA 与 4 位量化结合起来。它让冻结的预训练模型以低精度形式驻留在显存中，同时通过 LoRA 适配器反向传播梯度，从而在较小硬件上微调更大模型。QLoRA 论文提出了 NF4、双重量化和分页优化器等技术组合，并展示了在单张 48GB GPU 上微调 65B 模型的可行性。它的重要性不只是省钱，而是把大模型后训练从大实验室进一步推向普通研究团队和创业团队。
QLoRA 适合预算有限但希望训练较大基座的场景。对中文行业助手、本地部署模型、企业内部私有微调、小规模实验，它很实用。相比为了显存选择很小的模型，用 QLoRA 训练更强基座的适配器，常常能得到更好的上限。尤其是当任务需要通用语言能力和领域表达兼顾时，较大基座带来的收益可能超过全量小模型微调。
但 QLoRA 的低门槛容易让团队低估质量风险。4 位量化的冻结基座参与前向和反向计算，虽然论文和实践证明很多场景效果很好，但它不是所有任务的免费替代。高精度数值、复杂代码、长上下文、多语言混合、严格格式输出，都应该和 BF16 或 FP16 基线比较。训练成功不等于质量无损，能跑起来不等于能上线。
QLoRA 还会增加排错复杂度。训练不稳定时，问题可能来自量化配置、计算 dtype、梯度检查点、优化器、batch size、packing、tokenizer、数据模板或显存分页。初学者容易把所有错误归因到“数据不够”，实际上可能是 chat template 错、label mask 错、EOS 处理错。生产团队最好先用很小样本做过拟合测试，确认训练链路能学到东西，再扩大数据集。
QLoRA 训练出的适配器也要治理。不要把“低成本可训练”变成“随手训一堆不可追踪模型”。每个版本都应该保存数据集摘要、样本数、清洗规则、评测结果、训练超参、基座哈希、依赖版本和适用范围。低成本训练越容易，版本管理越重要。
DPO 直接用偏好对优化模型
DPO 的吸引力在于简化。传统 RLHF 需要训练奖励模型，再用 PPO 等强化学习方法优化策略，还要处理奖励过拟合、KL 约束、采样成本和训练稳定性。DPO 论文把偏好优化转化为更直接的目标：给定同一个 prompt 下的 chosen 与 rejected，优化模型更偏向 chosen，同时用参考模型约束偏离。Hugging Face TRL 的 DPOTrainer 和 OpenAI 的 DPO 微调文档都把数据格式落在 prompt、preferred output、non-preferred output 这一类偏好样本上。
DPO 适合“好坏可比较，但难写唯一标准答案”的任务。比如两个客服回复哪个更有帮助，两个总结哪个更忠实，两个拒答哪个更自然，两个代码解释哪个更清楚，两个销售邮件哪个更像品牌语气。它不要求标注者写出全新理想答案，只要求在候选之间作选择。这降低了偏好数据采集成本，也更贴近真实用户体验。
DPO 的前提是偏好对质量高。chosen 必须确实更好，rejected 必须代表模型可能犯的典型错误。若 rejected 太差，模型只学会避开低级错误；若 chosen 与 rejected 差异只在长度或格式，模型可能学到偏好捷径；若标注标准不一致，模型会在冲突偏好中摇摆。偏好对不是随便两个答案，它应该浓缩明确价值判断。
DPO 常常需要一个不错的 SFT 模型作为起点。OpenAI Cookbook 中关于微调方法的说明也强调，先有 SFT 建立基础策略，再做 DPO 往往更稳。原因很简单：偏好优化是在候选行为之间塑形，如果模型连基本任务都不会，偏好对很难教会完整能力。先让模型会做，再让模型做得更符合偏好，是更自然的顺序。
DPO 也有边界。它不是事实校验器。如果 chosen 事实错但语气好，模型会学语气而不是事实。它也不是权限系统。如果偏好数据里没有越权拒答样本，模型不会自动理解企业权限。它更不是安全万灵药。偏好数据覆盖不到的诱导场景，仍然需要红队、策略、运行时过滤和工具边界。
RLHF 把偏好变成奖励，再用强化学习优化
RLHF 的典型流程包括三步。第一步，用人工示范做 SFT，让模型具备基本指令跟随能力。第二步，针对同一 prompt 采样多个模型输出，让人类排序或比较，训练奖励模型预测人类偏好。第三步，用强化学习优化语言模型，让它最大化奖励模型评分，同时通过 KL 约束避免偏离原模型太远。InstructGPT 论文就是这一范式的代表，展示了较小的对齐模型在人工偏好评估中可以超过更大的未对齐模型。
RLHF 的价值在于能把复杂偏好转成可优化信号。人类不必为每个 prompt 写完美答案，只要比较输出质量。奖励模型学到偏好后，可以批量给新输出打分，强化学习阶段再让策略探索更高奖励的回答。这种方式曾经是训练聊天助手、摘要模型和安全拒答行为的重要路径。
RLHF 的代价也很明显。奖励模型本身可能被模型钻空子。模型会学会生成奖励模型喜欢但人类未必喜欢的文本，例如过度礼貌、过长解释、看似严谨但事实空洞。强化学习训练不稳定，需要控制 KL、学习率、采样、奖励归一化和停止条件。标注成本高，标注者疲劳和标准漂移也会影响结果。生产团队如果没有足够训练工程能力，RLHF 很容易变成高成本黑盒实验。
RLHF 适合高价值、长期、大规模的模型对齐项目。比如通用助手、平台级模型、需要综合 helpfulness 和 harmlessness 的产品、需要跨任务稳定偏好的模型。对单个企业应用来说，完整 RLHF 往往不是首选。更务实的路径是先做 SFT，必要时做 DPO 或其他离线偏好优化，再用运行时评测和人工审核补齐风险场景。
RLHF 的另一个启示是：偏好数据比算法更重要。奖励模型好坏取决于人类比较样本。样本覆盖、标注指南、标注者训练、冲突处理、审核机制、长期漂移监控，都会决定最终模型行为。没有高质量偏好数据，换 PPO、DPO 或其他算法都只是换优化器。
RLAIF 用 AI 反馈扩大偏好数据规模
RLAIF 是 Reinforcement Learning from AI Feedback。它用 AI 模型生成或判断偏好，减少对人类标注的依赖。Anthropic 的 Constitutional AI 论文展示了一种重要思路：先让模型根据一组原则自我批评和修改回答，再用 AI 反馈生成偏好信号进行强化学习，从而训练更无害的助手。后续 RLAIF 论文进一步讨论用 AI 反馈扩展 RLHF 的可能性。
RLAIF 的核心优势是规模和速度。人类标注昂贵、慢、难覆盖长尾风险；AI 评审可以快速生成大量比较，尤其适合基于明确原则的安全、语气、合规和拒答场景。一个团队可以把政策、宪法式原则、品牌规范、客服准则转成评审 prompt，让强模型批量比较候选答案，从而构建初始偏好数据。
但 RLAIF 不是“让 AI 自己决定价值观”。AI 反馈的质量取决于评审模型、评审提示、原则设计和抽样审核。强模型也会有偏见、误判和模式化倾向。若完全用 AI 反馈闭环，可能把评审模型的偏差放大到被训练模型里。尤其是安全和伦理问题，原则本身就需要组织决策和人类责任，不能把价值判断外包给一个模型。
RLAIF 更适合作为人类标注的放大器，而不是替代品。合理做法是：人类定义原则和标注指南，AI 批量生成候选偏好，人类抽检和校准，发现系统性误判后更新评审标准，再把高置信样本进入训练。这样既能降低成本，又保留责任链。对于高风险行业，还需要把关键样本留给专家审核。
RLAIF 还可以用于数据发现。让评审模型寻找回答中的过度承诺、幻觉、权限越界、语气问题、引用不一致，再由人类确认。它不仅生成训练数据，也帮助团队看见模型行为缺口。把 RLAIF 只理解成训练算法，会错过它在质量治理中的作用。
偏好数据是对齐项目的真正资产
偏好数据通常包含 prompt、chosen、rejected，有时还包含评分理由、标签、任务类型、风险等级、来源、标注者、时间和审核状态。它看起来比 SFT 样本简单，但治理难度更高。因为偏好不是纯事实，它包含产品价值、用户体验、组织政策和风险容忍度。不同团队对“更好”的理解可能不同，必须显式写进标注指南。
偏好数据要覆盖真实失败。很多团队只从模型随机采样中挑两个答案比较，结果数据集中充满浅层差异。更有价值的 rejected 来自线上失败、用户差评、人工审核退回、红队攻击、格式校验失败和专家纠错。chosen 则应该代表团队真正愿意上线的回答，而不是标注者临时写的“看起来还行”。偏好数据越贴近真实错误，训练越能解决实际问题。
偏好标签最好带原因。只保存 chosen 和 rejected，后续很难分析模型学到了什么。原因标签可以包括事实更准确、证据更完整、表达更简洁、拒答更恰当、少泄露隐私、工具参数正确、没有过度承诺、符合品牌语气。训练时未必直接使用这些标签，但评测、切片分析和数据迭代会需要它们。
标注一致性是偏好数据生命线。两位标注者如果经常选择相反答案，说明标准不清或样本本身有争议。团队应该保留仲裁机制，把争议样本分类：是任务定义不清、证据不足、政策冲突、还是两种答案都可接受。争议样本不是垃圾，它们往往暴露产品边界。边界澄清后，再决定是否进入训练。
偏好数据还要防止捷径。若 chosen 总是更长，模型会学会变长；若 rejected 总是格式混乱，模型会把格式当成唯一标准；若安全 chosen 总是以固定拒答句开头，模型会过度套模板。构造偏好对时，应该让差异聚焦在真正关心的维度。例如比较忠实度时，两边长度和格式尽量相近；比较简洁度时，两边事实都正确；比较拒答时，两边都礼貌，但一个给出安全替代方案。
什么时候用 SFT，什么时候用 DPO
可以把 SFT 看成“教会正确动作”，把 DPO 看成“在多个动作中偏向更好选择”。如果模型经常不知道该输出什么结构、该调用什么工具、该用什么术语，先做 SFT。如果模型已经能输出可用答案，但答案太啰嗦、太保守、太迎合、太不稳定，DPO 更合适。把 DPO 用在不会任务的模型上，效果往往有限；把 SFT 用在主观偏好问题上，又会逼团队写大量理想答案，成本高且不自然。
结构化任务优先 SFT。比如“把报销单转成固定字段”“根据客服对话生成工单摘要”“把自然语言问题转成某个查询 DSL”“按照公司格式写代码审查”。这些任务有明确输入输出合同，示范答案可以直接生成监督信号。训练后再用验证器检查格式和字段，形成闭环。
主观质量任务优先偏好优化。比如“哪个回复更像专家”“哪个拒答更有帮助”“哪个摘要更忠实且不啰嗦”“哪个方案更符合团队操作习惯”。这些任务很难写唯一答案，但很容易比较候选。DPO 能把这种选择信号转成模型更新。
很多生产项目需要两者结合。先用 SFT 让模型掌握公司任务模板、工具格式和基本表达；再用 DPO 调整偏好，例如更短、更谨慎、更少废话、更会引用来源、更好地处理无答案。组合时要避免数据冲突。SFT 样本里如果鼓励长篇解释，DPO 样本里又偏好短回答，模型会摇摆。训练前要统一产品标准。
还有些问题不该训练。用户问答事实错误，先修检索；权限越界，先修权限过滤；输出偶尔不合法，先修 schema 和重试；不同入口需求差异大，先做路由；模型基础能力不足，先换基座。训练是改变模型行为的重手段，不应该替代系统工程。
微调数据不是越像线上越好，还要可学习
线上日志很诱人，因为它真实。但真实日志往往混杂噪声、隐私、过时规则、失败答案、用户辱骂、重复问题和内部字段。直接拿线上对话做微调，会把线上混乱固化进模型。训练数据应该来自真实分布，但必须经过筛选、修正、脱敏和规范化。真实输入加高质量目标输出，才是可学习数据。
可学习样本需要明确因果关系。输入里应包含完成任务所需信息，输出应该能从输入和常识推出。若输出依赖训练数据外的内部知识，模型只能记忆或幻觉。比如要训练合同审查，样本里要包含合同条款、审查标准和输出意见；不能只给一句“审查这份合同”和一段最终意见。模型看不到依据，就学不到审查方法。
数据还要覆盖拒答和无答案。很多团队只收集成功回答，训练后模型变得过度自信。生产系统里，模型必须知道什么时候资料不足、权限不足、请求不清、风险过高、工具失败。SFT 中应有高质量无答案模板，偏好数据中应有“承认不知道优于编造答案”的比较。对齐不是让模型永远输出，而是让模型在不该输出时保持边界。
负样本也要真实。偏好优化中的 rejected 最好来自模型真实会犯的错误，而不是人为写得很差的假答案。真实 rejected 包括：引用不存在来源、忽略关键约束、把旧版本当新版本、泄露内部字段、过度承诺、格式不合法、拒绝过度、工具参数错、遗漏下一步。模型只有见过这些近似错误，才会学会在边界上区分。
数据版本应该像代码一样管理。每次清洗规则变化、样本增加、标注指南更新，都要产生新版本。训练结果必须能追溯到数据版本。否则模型表现变化时，团队无法知道是新样本带来提升，还是某批低质量数据造成退化。微调项目的核心资产不是某次权重文件，而是可持续迭代的数据管线。
评测要覆盖能力、偏好和风险
微调后最危险的评测方式，是随机问几个问题觉得不错就上线。模型训练会产生局部改善，也可能带来隐藏退化。一个客服模型语气更像品牌，但事实准确率下降；一个代码模型输出格式更稳，但不再解释关键风险；一个安全模型拒答更强，但正常问题也拒绝。没有分层评测，团队只会看到想看到的改善。
能力评测回答“会不会做”。它关注事实正确、分类准确、结构化字段、工具调用参数、代码可运行、引用是否命中证据。能力评测最好自动化，能在每次训练后快速跑完。对结构化任务，schema 校验和业务规则校验很有用。对开放回答，可以结合人工评分和强模型评审，但要保留抽检。
偏好评测回答“做得是否更符合标准”。同一批 prompt 让基座、SFT、DPO 模型分别回答，再由人类或校准过的评审模型盲评。偏好评测要按维度评分，不要只给总分。简洁、忠实、礼貌、可操作、谨慎、引用、拒答质量，应该分开看。模型可能在一个维度提升、另一个维度下降。
风险评测回答“会不会在坏场景里出事”。它包括越权请求、提示注入、隐私诱导、危险建议、伪造来源、专业领域误导、内部字段泄露、工具误用。风险评测不应只靠公开安全 benchmark，还要来自业务真实边界。企业知识库模型就要测权限和版本；代码代理就要测危险命令；医疗法律助手就要测免责声明、转诊和不确定性表达。
成本和延迟也要评测。微调可能让回答变长，导致输出成本增加；也可能让格式更短，降低成本。LoRA 适配器加载可能影响服务架构；较大基座 QLoRA 效果好但推理成本高。最终要看单位有效回答成本，而不是只看质量分。生产系统里，质量、成本和延迟共同决定可用性。
训练不能替代运行时控制
即使模型经过 SFT 和偏好优化，也不能裸奔上线。运行时仍需要系统提示词、权限检查、检索过滤、工具白名单、输出验证、内容安全、审计日志和人工升级。训练让模型更倾向于好行为，但不能保证每次都好。大模型输出是概率过程，任何关键业务都需要外部控制。
权限尤其不能靠训练。不能因为训练样本里教过“不要泄露隐私”，就让模型看到所有用户资料。正确做法是在检索和工具层先按用户权限过滤，模型只接触它有权处理的内容。模型不知道的东西，才最安全。把越权数据给模型再期待它不说，是错误架构。
事实引用也不能只靠训练。模型可以学会“引用格式”，但引用是否真实要靠检索证据、来源 ID、片段定位和后处理校验。训练一个会写引用的模型，如果没有证据链，它可能更擅长伪造看似专业的引用。对于知识问答，训练的目标应是“基于给定证据回答并在证据不足时拒绝”，不是“记住所有知识”。
工具调用同样需要外部验证。SFT 可以让模型更会生成函数参数，DPO 可以让它选择更合适的调用方式，但参数合法性、权限、幂等、确认、回滚、超时和错误恢复都属于系统责任。真正会干活的智能体，不是只在训练中学会说“我要调用工具”，而是在运行时能看见工具结果、判断失败、修正计划，并受明确边界约束。
运行时控制和训练应该配合。把高频、低风险、稳定的行为放进训练；把高风险、变化快、依赖权限的行为放在系统层；把灰区交给人工审核或多模型评审。这样模型既不会被过度限制，也不会承担不该承担的责任。
上线要有版本、灰度和回滚
微调模型上线不是上传一个权重文件。每个版本都应该记录基座模型、tokenizer、chat template、训练方法、适配器配置、数据版本、样本规模、训练时间、评测结果、适用入口、禁用场景和回滚目标。没有这些记录，模型一旦出问题，只能靠记忆排查。
灰度应该按任务和风险切分。先在内部入口、低风险场景、可编辑草稿、人工审核链路中使用新模型；再逐步放到自动回复、客户可见、高价值任务。灰度期间要对比旧模型和新模型的成功率、用户修改率、人工接管率、引用错误、拒答率、平均长度、成本和延迟。只看总体满意度，容易漏掉小但严重的风险。
回滚要简单。模型路由不应写死在客户端，也不应依赖手动改代码。服务端配置应能快速切回旧模型、旧适配器、旧 prompt 或旧检索策略。训练上线经常同时伴随 prompt、模板、检索和工具变化，最好一次只改一个关键因素；若必须同时改，要在发布记录里写清楚。否则上线后无法判断问题来自哪里。
版本之间还要做兼容评估。LoRA 适配器与基座强绑定，基座升级后必须重新评测。DPO 后模型可能改变输出长度和拒答风格，上游 UI 和下游解析器要跟着检查。结构化输出模型改动后，所有依赖字段的业务流程都要跑回归。微调不是模型团队的独立动作，它会影响产品链路。
退役模型也要管理。旧模型可能仍被某些租户、历史任务或异步队列调用。删除前要确认调用路径、数据保留、审计需求和复现需求。生产级模型治理不是“最新就是唯一”，而是知道每个版本为什么存在、何时退役、如何复现。
常见误区
第一个误区是把微调当知识灌入。模型参数不是文档库。需要最新事实、引用和权限时，用知识库、检索和工具；需要稳定表达、任务格式和偏好时，再训练。把企业资料直接训进去，不仅更新困难，还可能造成隐私和合规风险。
第二个误区是用低质量合成数据堆规模。合成数据可以有价值，尤其用于扩展表达、生成难例和构造偏好候选。但合成数据必须经过过滤、去重、校准和抽检。模型生成的数据再训练模型，容易形成风格回声室。数据量越大，越要有质量门槛。
第三个误区是只训正例。只看成功答案，模型会在未知场景里硬答。生产模型需要学会无答案、拒答、澄清、升级人工、等待工具结果、承认不确定。负例和边界样本是对齐数据中最值钱的部分。
第四个误区是只比较平均分。微调可能让常见问题变好，让长尾问题变差。必须按任务类型、语言、长度、风险等级、入口和用户群切片。尤其是安全和权限问题，不能被平均分掩盖。
第五个误区是把 DPO 当 RLHF 的无脑替代。DPO 更简单、更稳定，但它依赖高质量偏好对，也有适用边界。若任务需要在线探索、复杂奖励或长期行为优化，完整 RLHF 或其他强化学习方法仍可能有价值。算法选择要服务目标，不要变成口号。
第六个误区是忽略人类责任。无论 RLAIF 多高效，原则、风险边界和最终验收都要有人负责。AI 可以帮助生成反馈，不能替组织承担价值选择。尤其在医疗、金融、教育、法律和安全领域，人类专家审核不是形式，而是产品责任的一部分。
给团队的一套实际决策框架
第一步，写清当前失败类型。不要说“模型不够好”，要写成可观察问题：格式失败、引用错误、拒答过度、越权、语气不一致、工具参数错、事实过时、长文档漏证据、输出太长。失败类型决定解决路径。
第二步，判断是否需要改参数。若问题来自资料、权限、检索、工具、prompt 或验证器，先修系统。若问题来自稳定任务行为或偏好选择，再考虑 SFT、LoRA、QLoRA、DPO 或 RLHF。能用系统控制解决的问题，不要急着训练；必须内化到模型行为里的问题，训练才有价值。
第三步，选择最小可行训练。任务格式问题先做 SFT；硬件有限用 LoRA 或 QLoRA；主观偏好问题做 DPO；平台级复杂偏好再考虑 RLHF；大规模原则反馈可以引入 RLAIF。不要一开始就搭最复杂流程。简单方法在高质量数据上通常比复杂方法在脏数据上更可靠。
第四步，建立数据闭环。线上失败进入候选池，人工或 AI 辅助标注，争议样本仲裁，高质量样本进入训练集，训练后用固定评测集和新鲜线上样本验证。数据闭环比单次训练重要。对齐不是一次项目，而是持续治理。
第五步，把模型发布当生产变更。保存版本，跑回归，灰度上线，监控切片指标，准备回滚。训练结果只有经过真实链路验证，才算完成。一个在 notebook 里表现很好的微调模型，如果不能稳定服务用户，就还不是生产能力。
结语
SFT、LoRA、QLoRA、DPO、RLHF、RLAIF 和偏好数据，代表的是一组后训练工具箱。SFT 教模型照着好样本做事；LoRA 让微调更轻；QLoRA 把大模型微调显存门槛降下来；DPO 直接把偏好对变成优化目标；RLHF 用奖励模型和强化学习优化复杂偏好；RLAIF 用 AI 反馈扩大偏好数据规模。它们各有位置，也各有代价。
成熟团队不会问“哪个方法最先进”，而会问“我的问题是什么，数据能否表达这个问题，训练后如何证明改善，失败时如何回滚”。微调与对齐的真正难点，不在算法名词，而在数据标准、任务归因、评测体系和生产治理。模型不是被一次训练变聪明的，它是在持续的数据、反馈、评测和系统约束中变得可靠。
当团队能把知识放在可更新的检索和工具里，把稳定行为放进 SFT，把主观偏好放进 DPO 或 RLHF，把规模化反馈交给受控的 RLAIF，把风险边界留给权限和运行时控制，微调与对齐才会从实验室技巧变成可维护的产品能力。
参考资料
- Training language models to follow instructions with human feedback, OpenAI / arXiv: https://arxiv.org/abs/2203.02155
- Aligning language models to follow instructions, OpenAI: https://openai.com/index/instruction-following/
- LoRA: Low-Rank Adaptation of Large Language Models, arXiv: https://arxiv.org/abs/2106.09685
- QLoRA: Efficient Finetuning of Quantized LLMs, arXiv: https://arxiv.org/abs/2305.14314
- Direct Preference Optimization: Your Language Model is Secretly a Reward Model, arXiv: https://arxiv.org/abs/2305.18290
- Constitutional AI: Harmlessness from AI Feedback, arXiv: https://arxiv.org/abs/2212.08073
- RLAIF: Scaling Reinforcement Learning from Human Feedback with AI Feedback, arXiv: https://arxiv.org/abs/2309.00267
- Hugging Face TRL SFT Trainer documentation: https://huggingface.co/docs/trl/main/sft_trainer
- Hugging Face TRL DPO Trainer documentation: https://huggingface.co/docs/trl/main/dpo_trainer
- Hugging Face PEFT LoRA documentation: https://huggingface.co/docs/peft/developer_guides/lora
- OpenAI Supervised Fine-Tuning documentation: https://platform.openai.com/docs/guides/supervised-fine-tuning
- OpenAI Direct Preference Optimization documentation: https://platform.openai.com/docs/guides/direct-preference-optimization
- OpenAI Cookbook, Fine-Tuning Techniques: Choosing Between SFT, DPO, and RFT: https://cookbook.openai.com/examples/fine_tuning_direct_preference_optimization_guide