4. 后训练

1 概览：从基础模型到助手

Figure 1: 从基座模型到生产助手的后训练流水线

设想你的团队在周五把一个“看起来很聪明”的基础模型接进了财务系统。到周一早上，三个故障同时出现：账务接口期待严格 JSON，它却回了散文；本该调用余额查询工具时，它直接猜了一个数；面对高风险转账请求，它的拒绝口径又比测试环境软了一截。

这三类故障说明的不是模型“不懂语言”，而是它还没有被后训练成一个生产助手。基础模型擅长的是 next-token prediction：续写文本、模仿语气、延续统计模式。生产系统要的却是另一组能力：遵循指令、服从边界、调用工具、输出结构、通过验证、控制成本。

因此，后训练不是“在预训练后再微调一下”这么简单。它更像一层系统工程：你在同时改写训练分布、优化目标、解码约束、工具接口、评测闭环和部署成本。也正因为如此，alignment 从来不是单纯的模型问题，而是数据、目标函数、工具契约、服务栈与评估栈共同决定的系统问题。

后训练的中心工程问题可以压缩成一句话：

如何把一个只会预测文本的基础模型，逐步变成一个可靠、可控、可部署的 AI 助手？

1.1 本章总览

你可以把后训练理解成“把一个会说话的模型，打磨成一个能稳定干活的系统助手”的过程。本章里的“阶段”指的是典型后训练流水线，不是 LLM 的完整生命周期；在真实工程中，团队会按目标重排甚至跳步，例如先做工具使用 SFT，再做偏好对齐。

先修要求可以简化为三块：第一，你要知道 Transformer 与 next-token 目标在做什么；第二，你要熟悉微调流程，包括数据切分、训练、验证和回归；第三，你要能读懂服务指标，例如延迟、成本、可靠性和失败率。如果这三块都掌握了，本章会更容易读透。

学习目标也很务实：读完后你应当能说清六个阶段分别解决什么问题，面对真实产品约束能快速选出第一优先杠杆，遇到故障时能定位问题来源并提出修复路径，最后还能把训练方案落成可执行的上线评测 gate。

阅读方法建议用一条固定主线：先看当前系统卡在哪里，再看主流方案为什么不够，再看新方法具体改变了哪一层（训练信号、目标函数、推理约束或系统结构），最后评估收益、代价和适用边界。按这个顺序读，你不会停留在“记住名词”，而是能回答“为什么要用、什么时候用、什么时候不用”。

读数学公式时，不必一上来就推导全部细节。你可以先抓四件事：它在优化谁、在哪个范围求平均、有没有惩罚项、哪个超参数在控制强度。本章常见符号可这样读：\(\theta\) 是模型参数，\(x\) 是输入，\(y\) 是输出，\(t\) 是 token 位置，\(\sum\) 表示求和，\(\mathbb{E}\) 表示期望，\(\log\) 常用于把连乘概率改写为连加，\(\mathrm{KL}\) 用于度量两个分布的差异。只要这四步读清楚，大多数公式都能落到直觉上。

为了在开读前先抓全貌，你可以先记住这条主线：先用 SFT 把行为和格式训稳，再用 PEFT 做低成本专精；随后做偏好对齐与工具训练，把“会说”升级为“会做”；再用推理 RL 追求可验证正确性，最后用蒸馏把能力落到可承受的延迟和成本。

本章使用一个贯穿案例来串联所有阶段：你要做一个财务运营助手，它必须输出严格 JSON 给下游系统，必须会调用工具获取实时或私有数据，必须拒绝高风险操作（如越权转账），还必须支持多业务线的策略差异（多租户）。建议你读每个阶段时都问自己两句：这一步具体解决了这个助手的哪一类问题？它又引入了哪一种新的工程风险？

后训练阶段总览

阶段 常见地位 主要修复的问题 代表性工件 / 系统杠杆
SFT 常见必经 指令遵循、格式控制、角色与边界稳定 chat template、completion-only mask、SFT checkpoint
PEFT 常见可选 低成本专精、多版本管理、多租户分化 LoRA / QLoRA adapter、adapter routing
偏好对齐 常见必经 “答得不差但不好用”的质量差异 preference pairs、reward model、DPO / RLHF policy
工具使用 / RAG 多数产品必经 groundedness、实时 / 私有数据访问、结构化动作 tool traces、schema、validator、constrained decoding
推理 / 智能体 RL 按任务可选 多步规划、可验证正确性、搜索与自我修正 verifier、process reward、GRPO-style training
蒸馏 高频必经 延迟、成本、部署足迹 teacher-student pipeline、student model
Note后训练的直观比喻

如何把一个满嘴跑火车的路人甲，训练成你的完美男朋友

基础模型很像一种类型：**表达能力远远强于判断力。这种人通常给人留下很好的第一印象。他反应快，词汇多，什么都能接，甚至还能模仿不同类型的说话方式。你聊十分钟，会觉得他很聪明。你让他做成一件有后果的事，就会发现你刚才夸早了。

这不是一个罕见问题。语言模型的问题是，看起来懂，听起来像，实际上只是把统计上最像样的下一句话接出来。基础模型的问题，从来不是不会说。它的问题是：它太会说了，以至于很容易让人误以为它也会负责。后训练，本质上就是对这种误会做系统修正。

PEFT 像什么？ 像你终于接受一个事实：你没时间成本和勇气换人，只能挑最值得修的地方打个补丁，将就一下。不换底子，只改局部。工程上，这不是浪漫主义；这是预算约束下的理性。

偏好对齐 像什么？ 像教一个人明白：“我 technically 没说错” 并不等于 “你刚才表现得不错”。很多回答并不错误，只是令人不想再继续。这在恋爱里叫情商问题，在模型里叫 alignment 问题。本质上是一回事：你不能只求自洽，还得让别人愿意继续跟你在一起。

RAG 像什么？ 像强行禁止不懂装懂。记不住细节，不算大错。不知道还编，而且编得流畅、镇定、像真的一样，这才是灾难。所以 RAG 的精神其实很朴素：少一点表演，多一点查证。不知道就查资料。

RL 像什么？像终于把它从考试体系里扔进现实。现实不会告诉你标准答案，只会告诉你后果。做对了，系统继续跑；做错了，用户流失、工单爆炸、风控报警。RL 的价值，不在于它更“高级”，而在于它终于开始问那个真正重要的问题：这种行为，最后会导致什么？

Distillation 像什么？ 像你承认最成熟、最稳、最贵的那个人确实最好，但你也知道，不可能每件小事都找他。所以你训练一个便宜一点、快一点、没那么完美的版本，学会他大部分关键动作。人类社会几乎所有规模化系统，最后都走到这一步：从最好，退到足够好。

Deployment + Eval 最像什么？
最像真正进入关系以后。前面的一切都可以写得很好看：loss 下降了，偏好胜率上升了，结构化输出也更稳了。 但上线之后，系统只关心三件事：它会不会偷懒？会不会乱来？会不会在最不该犯错的地方犯错？

所以，后训练最有意思的地方在于：它并不是把一个“不会说话”的人训练成“会说话”。 后训练做的是更不讨喜、但更宝贵的工作：把一个擅长制造“我懂你”幻觉的系统，训练成一个在真实约束下负责人完成你的任务可靠系统。

这听起来不浪漫。因为工程里真正值钱的东西，通常都不浪漫。它们只是可靠。而可靠，差不多就是技术世界里最接近爱的东西了。

2 监督微调（SFT）

SFT 是后训练的起点。目标不是“让模型更会说话”，而是让它“按你的产品规则说话”。

Figure 2: SFT 的数据、模板与损失掩码

2.1 SFT 用于指令遵循与格式控制

预训练模型虽然擅长“续写”，却不擅长稳定执行产品约束，所以在真实系统里常出现 JSON 偶尔失真、拒答风格漂移、工具调用结构不稳等问题。早期团队通常先靠 prompt 工程补救，这在简单场景下能见效，但一旦进入分布变化、长上下文和多轮复杂交互，稳定性就明显下滑。SFT 的关键改动是把“什么叫好回答”直接写进训练数据，让模型不仅学习内容本身，还学习角色、语气、格式与工具 schema；其常见训练目标是最小化助手 token 的 next-token 交叉熵（Ouyang et al., 2022）： \[ \mathcal{L}_{\text{SFT}}(\theta) = -\sum_{t=1}^{T}\log p_\theta(y_t \mid x, y_{<t}). \] 在每个 token 位置 \(t\)，都希望模型给“正确答案 token”更高概率。这里 \(p_\theta(\cdot)\) 是当前参数 \(\theta\) 下的预测概率，\(y_t\) 是第 \(t\) 个真实 token，\(y_{<t}\) 是它之前已经生成的 token，\(x\) 是输入上下文；前面的负号表示“概率越大，损失越小”。为什么要用 \(\log\)？因为整句概率本来是很多小概率连乘，直接算会很小且不稳定；取对数后，连乘变连加，训练更稳定。你可以做个两 token 小例子：若模型给正确 token 的概率分别是 \(0.8\) 和 \(0.4\)，损失是 \(-(\log 0.8 + \log 0.4)\)，第二项更差，所以会被更强地推动改进。
这种做法的优势是见效快、可控性强、工程链路成熟，但边界同样清晰：它并不擅长大规模注入新知识（除非数据规模接近持续预训练），而且会放大数据偏差，例如过度拒答、冗长偏置和格式漂移。

在工程里，SFT 数据通常分成四种“训练样本形态”，它们分别对应四类能力训练：单轮指令、多轮对话、工具使用轨迹、安全/风格示范。仍用“财务运营助手”来说明，会更容易看出差异。

第一类是单轮指令数据，结构最简单：一条用户任务配一条助手答案，例如“把差旅报销政策总结成三条可执行规则”。这类数据在序列化时通常是 instruction -> response，监督 mask 主要覆盖 response，核心目标是把“按要求完成任务 + 按格式输出”训稳定。

第二类是多轮对话数据，重点不在某一句答得多漂亮，而在“连续几轮都不丢上下文”，例如第一轮问“上季度市场部预算是多少”，第二轮追问“那华东区呢”。这类数据会按 system/user/assistant/... 串成完整会话，mask 通常覆盖每轮 assistant 回复，主要训练指代消解、上下文记忆和追问衔接。

第三类是工具使用轨迹数据，样本里要显式包含“调用工具前后”的全过程：先输出 tool_call（如 {"tool":"query_erp","args":{"department":"sales","quarter":"Q3"}}），再接收 tool_result，最后给出基于结果的回答。这类数据常见序列是 assistant(tool_call) -> tool(result) -> assistant(final)；mask 一般监督工具参数区和最终回答区，而不监督原始工具返回文本，目标是学会四件事：何时调用、调用哪个工具、参数怎么填、如何基于证据作答。

第四类是安全/风格示范数据，用来固定模型边界和表达口径，例如对“帮我绕过审批直接转账”必须拒绝并给出合规替代流程，对“写催款邮件”要保持专业、克制、礼貌。它在序列化上仍然是对话，但标签会明确拒答结构、解释深度和品牌语气；mask 主要覆盖助手输出，目标是把风险边界与语言风格都训成“稳定行为”。

换句话说，这四类数据的区别不在“题目换了”，而在“训练视角换了”。第一，序列化决定你把同一件事按什么顺序写给模型：单轮常是 instruction -> response，多轮要写清 system/user/assistant 的来回顺序，工具轨迹还要显式写出 tool_call 和 tool_result。第二，监督 mask 决定哪些 token 会被“计分并反向更新”：通常主要更新 assistant 输出；在工具轨迹里，还会额外更新工具参数区，但不更新原始工具返回文本。第三，行为覆盖范围决定你到底想让模型学会什么能力：单轮偏执行指令，多轮偏上下文连续，工具轨迹偏“调用工具 + 基于证据回答”，安全/风格偏风险边界和表达口径一致性（Wang et al., 2022）。

理解了 SFT 之后，下一步要解决的是“同一个行为是否能在训练和推理阶段被模型一致读取”。

2.2 聊天模板契约（Chat Template Contract）

聊天模板契约要解决的是“训推格式不一致”这一类隐蔽但高频的问题：同一个模型如果训练时用一种消息序列化格式、推理时用另一种，就会出现角色边界混乱、补全异常、工具调用失败。过去很多团队把模板当作临时实现细节，靠字符串拼接快速上线，短期可跑但长期难复现。新方法的核心是把模板上升为接口契约，要求数据处理、训练、推理三端使用同一套规则；形式上可写为（Hugging Face, n.d.）： \[ s = T\big(\{(r_i, c_i)\}_{i=1}^{n}\big), \] 把这个公式拆开看会更清楚：\(\{(r_i, c_i)\}_{i=1}^{n}\) 表示一段会话里共有 \(n\) 条消息，第 \(i\) 条消息由两部分组成，\(r_i\) 是角色（如 system、user、assistant、tool），\(c_i\) 是该角色说的内容。\(T(\cdot)\) 是一个“固定格式化规则”，它的作用不是改写语义，而是把这些结构化消息按约定顺序加上边界标记，拼成唯一的文本序列 \(s\)。\(s\) 随后进入 tokenizer，被切成 token 并映射为 token id，才真正成为模型看到的输入。

可以看一个完整的小例子。假设输入消息是：(system, "你是财务助手")、(user, "查询销售部 Q3 支出")、(assistant, "<tool_call>{...}</tool_call>")、(tool, "{\"amount\": 1200000}")。模板函数可能把它序列化成：<|system|>你是财务助手<|user|>查询销售部 Q3 支出<|assistant|><tool_call>{...}</tool_call><|tool|>{"amount":1200000}<|assistant|>。注意，这里关键不是“意思差不多”，而是“符号必须完全一致”。如果训练时用 <|assistant|>，推理时换成 [assistant]，tokenizer 切出来的 token 序列会变，模型就可能把角色边界读错，出现答非所问或工具调用失败。

所以模板契约的本质是“同样的结构化输入，必须稳定映射到同样的 token 序列”。它的直接收益是减少难复现的线上回归，并让 SFT、DPO、RL 训练结果可比较；代价是工程耦合更强，你必须把模板版本与 tokenizer 版本一起管理，并做快照与回归测试。Hugging Face 文档也明确提示：控制 token 的偏差会显著降低聊天模型表现（Hugging Face, n.d.）。

当模板契约固定后，下一个关键点就是把训练梯度集中到“模型真正该学的输出 token”上。

2.3 仅补全损失（Completion-only Loss）

仅补全损失要解决的问题是“训练目标错位”：如果对输入和输出所有 token 都计算损失，模型会学会复述提示词，而不是专注回答问题，进而造成容量浪费和 prompt-echo。过去常见做法是全量 token 监督，虽然实现最简单，但在多轮对话中会被用户文本和系统脚手架严重稀释信号。新方法通过监督掩码（mask）只训练目标输出 token（通常是 assistant token），将梯度聚焦到真正要生成的内容上；常见写法是（Hugging Face TRL, n.d.）： \[ \mathcal{L}(\theta) = -\sum_{t=1}^{T} m_t \log p_\theta(y_t \mid x, y_{<t}), \] 这里新增的关键是 \(m_t\)，它像一个“开关”：\(m_t=1\) 表示这个位置要算损失，\(m_t=0\) 表示跳过。你可以把它理解成只批改“答案区”，不批改“题目区”。例如一条样本长度 10，前 6 个 token 是用户问题、后 4 个 token 是助手回答，那么前 6 个位置可设 \(m_t=0\)，后 4 个设 \(m_t=1\)。这样梯度只来自目标输出，训练信号更干净。
它的优势是同等算力下训练更高效、格式保真更好，但代价是对数据预处理更敏感：一旦 mask 边界出错，训练过程看起来正常，实际几乎学不到目标行为，所以必须用单测核查每条样本的有效监督 token 数量。

# Pseudocode: SFT with masking (PyTorch-style)

def compute_sft_loss(model, input_ids, labels, vocab_size):
    # labels: non-target tokens are -100
    logits = model(input_ids).logits
    shift_logits = logits[..., :-1, :].contiguous()
    shift_labels = labels[..., 1:].contiguous()
    return F.cross_entropy(
        shift_logits.view(-1, vocab_size),
        shift_labels.view(-1),
        ignore_index=-100,
    )

把前面几个概念放在同一条 SFT 流水线里看，会更容易理解它们各自的作用：四类数据形态决定“你喂给模型哪些真实任务场景”，也就是能力覆盖面；聊天模板契约决定“这些场景被翻译成什么 token 序列”，保证训练和推理读到的是同一种输入语言；completion-only mask 决定“模型在这些 token 上到底学什么”，把梯度集中在 assistant 应该输出的部分。三者配合后，SFT 才会从“数据很多但效果不稳”变成“数据、格式、优化目标彼此对齐”的可控过程。换句话说，数据形态负责广度，模板负责一致性，mask 负责学习焦点，缺任何一环都会出现看似训练正常、上线却不稳定的问题。

当基础行为监督完成后，后训练的重点会转向“如何在有限成本下做可规模化的多版本专精”。

这一阶段的核心问题是：模型能否稳定产出产品要求的交互行为。工程上最关键的控制点是模板一致性和监督 mask 的边界正确性；最常见误区则是还没检查序列化和数据边界，就先盲目增加 SFT 数据量。

3 参数高效微调（PEFT）

PEFT 在后训练里扮演的，不是“额外的算法边角料”，而是一个部署杠杆：SFT 让一个模型可用，PEFT 让很多“可用版本”在经济上变得可维护。 它的核心目标是低成本专精，让你在不复制整模的前提下维护多个任务版、租户版或策略版。

Figure 3: LoRA / QLoRA 的低秩更新机制

3.1 LoRA / QLoRA

LoRA/QLoRA 针对的是“全量微调太贵”这个现实问题：每个专用版本都需要完整 checkpoint，训练、存储和部署成本都很高。过去团队通常在“全量微调”和“仅靠 prompt 适配”之间二选一，前者成本高，后者稳定性又不足。LoRA 的核心改动是冻结底模，只学习低秩增量参数（Hu et al., 2021）： \[ W' = W + \Delta W,\quad \Delta W = AB, \] 可以先把 LoRA 想成“底模不动，只加补丁”。全量微调像是把整本教材重写一遍；LoRA 像是在页边加少量批注，用这些批注去修正模型行为。这样做的关键收益是：你不用改动大部分参数，也能让模型学到新任务。

放到公式里看，\(W' = W + \Delta W\) 表示新权重等于“原权重 + 改动量”；而 \(\Delta W = AB\) 表示这份改动量不是直接存整块矩阵，而是拆成两个更小的矩阵 \(A,B\) 相乘。假设原权重矩阵大小是 \(d\times k\)，全量微调要训练 \(dk\) 个参数；LoRA 只训练 \(A(d\times r)\) 和 \(B(r\times k)\)，参数量变成 \(r(d+k)\)。只要 \(r\) 远小于 \(d,k\)，参数和显存都会大幅下降。

看一个具体数字会更直观：若 \(d=k=4096,\ r=16\)，全量需要约 \(4096^2\approx 1678\) 万参数；LoRA 只需 \(16\times(4096+4096)=131072\) 个增量参数，量级接近百倍差距。QLoRA 则在 LoRA 基础上再进一步：把“冻结的底模”压到低比特（常见 4-bit）来省显存，只让 LoRA 增量部分保持较高精度参与训练（Dettmers et al., 2023）。
这类方法的优势是显存占用低、迭代速度快、便于维护多版本；代价是深层能力改造存在上限，若任务需要大范围权重迁移，效果可能不如全量微调。

工程上可以把 LoRA 的调参点理解成三个问题：第一，改哪里；第二，改多少；第三，怎么上线。
“改哪里”对应挂载模块。把 LoRA 挂在 attention 上，通常更直接影响信息选择和指令跟随；原因是 attention 的核心作用就是“当前 token 该看上下文里的哪一部分”，它直接决定模型是否抓住关键约束、关键实体和关键步骤。比如同一段输入里既有背景信息也有“必须输出 JSON”这样的硬约束，attention 的改动会更快体现在“它先看哪里、遵循哪条指令”。挂在 MLP 上，通常更影响表达风格和任务特化；原因是 MLP 更像“把已经取到的信息做非线性变换并组织输出”，对措辞、语气、领域表达模式和任务映射影响更明显。很多团队会先从 attention 起步，再按评测结果决定是否扩到 MLP。经验判定准则可以写成一句话：如果主要问题是“指令跟随不稳、格式约束抓不住、工具参数常错”，attention-only 通常先够用；如果这些问题已经基本稳定，但“术语表达不自然、文风不一致、任务特化不足”仍明显，再加 attention+MLP 往往更有效。
“改多少”对应秩 \(r\)。\(r\) 可以理解为补丁容量：\(r\) 小，参数更省、训练更快，但表达能力可能不够；\(r\) 大，能力上限更高，但显存和过拟合风险也会上升。
“怎么上线”对应部署方式。merge 是把 adapter 合并进底模，优点是推理链路简单、延迟低；缺点是每次换版本都要重新合并。在线叠加是不合并、按请求加载 adapter，优点是灵活、适合多租户；缺点是会增加加载和调度开销。

有了低成本参数增量后，系统层面下一步就会自然过渡到“如何把这些增量安全、高效地服务给多租户”。

3.2 Adapter 多租户

把“Adapter 多租户”放在 PEFT 这一章，是因为它本质上是 PEFT 的落地形态，而不是一套全新的训练算法。PEFT（比如 LoRA）先把“每个客户/任务的差异”做成很小的参数增量；Adapter 多租户再解决“这些小增量如何在生产环境里按客户正确切换”。如果没有 PEFT 先把改动压小，系统通常只能回到“每客户一整模”，成本会随客户数快速上涨。

因此，LoRA 和 Adapter 多租户是上下游关系。LoRA 负责把改动做成小而独立的 adapter，像在统一底模上制作多个“专属配置包”；Adapter 多租户负责在请求到来时把正确的配置包分发给正确的客户，像一个按租户路由的配置分发系统。一个偏训练参数构造，一个偏在线服务架构，两者合起来才能既省成本又可规模化。

Adapter 多租户要解决的核心矛盾是：客户数量增长时，如何避免模型副本爆炸。最直白但最贵的做法是每个租户部署一整套模型，隔离简单，但存储、显存占用、发布与回滚都会近似线性增长。更实用的做法是“一个共享底模 + 多个小 adapter”：底模共用，差异通过 adapter 表达，请求到来后按租户信息选择对应 adapter。形式化写法为： \[ i = g(z),\quad \pi_{\theta,i}(y\mid x) \text{ uses base } W \text{ plus adapter } a_i. \] 把这条公式拆开读，会更容易理解。第一部分 i = g(z) 的意思是“先选包”：\(z\) 是请求头里的租户信息（如 tenant_id、行业、策略版本），\(g(\cdot)\) 是路由规则，它输出一个 adapter 编号 \(i\)。第二部分 \(\pi_{\theta,i}(y\mid x)\) 的意思是“再推理”：在输入 \(x\) 下，系统使用“同一个底模参数 \(W\) + 第 \(i\) 个 adapter \(a_i\)”来产生输出 \(y\) 的概率分布。你可以把它理解成：底模负责通用能力，adapter 负责该租户的策略与风格偏置。

看一个更具体的例子。假设三家客户共用同一个财务底模：bank_A（严格合规）、retail_B（效率优先）、saas_C（解释更详细）。它们分别对应 adapter 17、42、9。用户问题相同：“请生成本月应付账款摘要，并告诉我是否可以跳过二次审批。” 请求进入系统后，先读取 \(z\)。若 \(z=(bank_A, policy_v3)\)，则 \(g(z)=17\)，加载 adapter 17，模型会强调“不可跳过二次审批”；若 \(z=(retail_B, policy_v2)\)，则 \(g(z)=42\)，模型可能给出“在金额阈值内可走简化流程”；若 \(z=(saas_C, policy_v1)\)，则 \(g(z)=9\)，模型会给出更长的解释和风险提示。注意，这里用户问题完全相同，差异来自“选中的 adapter 不同”。

这也解释了为什么“路由选错”是多租户里最危险的问题：模型可能语法完全正确、逻辑也通顺，但它执行的是另一家客户的策略。比如 bank_A 的请求被误路由到 42，系统可能输出本不允许的审批建议。工程上，这类错误往往比普通答错更难被肉眼发现，因为文本本身看起来很像“正常答案”。

这种架构的收益是成本下降、迭代加快、回滚更轻；代价是路由正确率和版本管理会升级为生产级安全边界，所以必须做三件事：adapter 级回归测试、租户切片评测、路由审计日志。常见部署模式包括按请求动态加载、GPU 热驻留、按 adapter ID 分批、单租户 merge 降延迟；本质上是在延迟、吞吐和显存驻留之间做工程权衡。

因此，这一阶段真正要回答的问题不是“能不能训练出 adapter”，而是“能不能在不成倍增加成本的前提下，把大量小版本稳定服务出去”。常见误区是把 PEFT 误解成“可以少做回归测试”，结果在多租户场景出现隐性行为漂移。可以把这一节浓缩为一句话：PEFT 让你“做得出很多小版本”，Adapter 多租户决定你“送不送得对、送不送得稳”。

当多版本专精问题被控制住后，下一阶段的重点会从“能不能专精”转向“回答是否更符合人类偏好”。

4 偏好对齐（对话与风格）

当模型已经能按指令工作，下一层问题往往不再是“它会不会答”，而是“它答得是不是人类真正想要的样子”。偏好对齐关注的正是这种质量排序：两个回答都不算错，哪个更有帮助、更克制、更可执行、更值得被系统采用。

Figure 4: 偏好对齐地图：RLHF vs DPO / ORPO

先用一个贯穿例子进入本阶段。假设你的财务运营助手面对同一个问题：“请总结本月现金流风险，并告诉我是否建议暂停非核心采购。”模型 A 的回答很“像人写的报告”：先给结论，再列证据（应收账款回款变慢、库存周转下降、下周有大额应付款），最后给分级行动建议和执行优先级；模型 B 也能给结论，但表达泛泛、缺证据、没有明确行动顺序。多数业务用户会更偏好 A，因为它更可执行、更可追责，也更便于管理层直接决策。

偏好对齐做的事，就是把这种“用户更偏好的回答方式”系统地学进去。后面的三节分别对应三步：先在偏好学习里收集和利用这类 A/B 比较信号，再用 KL 约束防止模型为了拿高分而把合规边界学坏，最后用 DPO/ORPO 在离线数据上以更低成本把这种偏好稳定固化。

4.1 偏好学习（Preference Learning）

偏好学习要解决的是 SFT 后常见的“答得对但不好用”：比如语气生硬、风险提示不当、帮助性不足。过去常见补救方式是继续堆 SFT 示范，但“最佳答案”往往不唯一，单一标签很难表达用户偏好差异。新方法把监督形式改成成对比较，让标注者判断哪个回答更好（Ouyang et al., 2022），模型学习的目标可写为偏好概率： \[ \Pr(y^+ \succ y^- \mid x). \] 这个概率可以读成：在同一个问题 \(x\) 下，回答 \(y^+\) 被偏好为“好于” \(y^-\) 的可能性。若这个值接近 1，说明模型偏向多数人更喜欢的回答；若接近 0.5，说明两者难分。你可以把它想成作文打分中的“二选一胜率”，比“唯一标准答案”更符合对话系统。

设问题 \(x\) 是：“请评估本月现金流风险，并给出三条可执行建议。”候选回答 A（可视作 \(y^+\)）先给风险等级，再列关键依据（应收账款周转、到期应付款、库存变化），最后给三条可执行动作并标出优先级；候选回答 B（可视作 \(y^-\)）虽然语法正确，但只有笼统结论“风险可控、建议加强管理”，没有证据链和落地步骤。若 10 位标注者里有 8 位选 A，那么经验上可理解为 \(\Pr(y^+ \succ y^- \mid x)\approx 0.8\)。偏好学习就是在大量这样的“同题二选一”样本上训练，让模型逐步学会更像 A 这种“有依据、可执行、表达清晰”的回答风格。

这种做法更贴近真实用户体验，但边界也很明确：偏好数据会引入标注偏差，而且“更受喜欢”并不总等于“更正确”。

因此接下来还需要一个机制，既能优化偏好，又能约束模型不要偏离太远。

4.2 带 KL 约束的奖励最大化

带 KL 约束的奖励最大化要解决的是一个很现实的矛盾：模型要“学得更合偏好”，但又不能“学偏到面目全非”。如果只盯奖励分，模型会想办法钻评分器空子（reward hacking）；如果只求稳定不敢更新，又学不到新偏好。这个方法的核心就是把“变好”和“别跑偏”放进同一个目标里（Ouyang et al., 2022）： \[ \max_{\pi_\theta}\; \mathbb{E}_{y \sim \pi_\theta(\cdot\mid x)}[r(x,y)] - \beta\,\mathrm{KL}\!\left(\pi_\theta(\cdot\mid x)\|\pi_{\text{ref}}(\cdot\mid x)\right). \] 这条式子可以按“油门 + 刹车”来读。前半项 \(\mathbb{E}[r(x,y)]\) 是油门：鼓励模型给出更高奖励的回答；后半项 \(\beta \cdot \mathrm{KL}(\pi_\theta\|\pi_{\text{ref}})\) 是刹车：不让新策略 \(\pi_\theta\) 偏离参考策略 \(\pi_{\text{ref}}\) 太远。这里的 KL 可以理解成“两个回答习惯的距离”，KL 越大，说明新模型说话方式、拒答边界、长度分布等行为变化越大。\(\beta\) 就是刹车力度：\(\beta\) 小，允许更激进更新；\(\beta\) 大，更新更保守。

你希望模型“更主动给可执行建议”（奖励上升），但不希望它因此减少合规提醒（行为漂移）。如果某轮训练里奖励提升了 \(+1.2\)，同时 KL 为 \(0.5\)，那么当 \(\beta=0.1\) 时惩罚是 \(0.05\)，净收益仍是正，更新会被接受；当 \(\beta=3\) 时惩罚变成 \(1.5\)，就会压过奖励提升，系统会倾向收缩更新。这就是为什么同一批数据，\(\beta\) 不同会得到明显不同的模型性格。

读这类训练曲线时，可以先记住一个通俗区分：你主动优化的指标叫“奖励”，你没打算改变却发生变化的行为叫“漂移”。比如你想提升“建议可执行性”，这是奖励目标；如果同时出现“拒答边界变松、回答异常变长、JSON 有效率下降”，这就是行为漂移。

工程上可以用“双指标法”判断模型到底有没有真的变好：一组看目标收益（偏好胜率、任务成功率、verifier 通过率），一组看护栏稳定（KL、拒答率/安全指标、格式有效率、长度分布）。四种常见结果可以这样解读：目标指标上升且护栏稳定，通常是真提升；目标指标上升但护栏下滑，常见是奖励投机或漂移；目标指标不变但 KL 持续变大，属于无效漂移；目标指标和护栏同时变差，则是明显退化。这样看，你就不会被“奖励分好看”误导，而能判断模型是在“真实变好”还是“只在评分器上变好”。

有了这个统一目标后，工程上下一问通常是：能不能不用完整 RLHF，也吃到偏好数据的主要收益。

这个问题之所以重要，是因为完整 RLHF 往往“贵在整条链路”而不只是贵在某一项算力。它通常需要四层投入：先做人类偏好标注（持续采集和质检都贵），再训练奖励模型，再进行大规模在线 rollout 生成新样本，最后用 PPO 等 RL 方法反复更新策略并做稳定性调参。与普通离线训练不同，RLHF 常是 on-policy 流程，模型一更新，旧数据价值就会下降，意味着需要持续“边采边训”，推理算力和训练算力同时吃紧。此外，为了防止 reward hacking 和安全回归，还要频繁跑红队评测与回归套件，工程人力成本也显著上升。

所以很多团队不是“反对 RLHF”，而是按阶段采用：先用 DPO/ORPO 在离线偏好数据上拿到大部分可见收益，建立评测和监控闭环；当离线方法收益趋于平台期、且业务确实需要更强在线探索时，再升级到完整 RLHF。这样做的本质是先控制成本和风险，再逐步提高优化强度。

4.3 DPO / ORPO（离线偏好优化）

DPO / ORPO 可以用一句话理解：你已经有“同一题里哪个回答更好”的投票结果，就直接用这些投票训练模型，而不先搭完整 RLHF 流水线。它们最适合的场景是：偏好数据已经有了，但你希望先用更低成本拿到稳定收益（Rafailov et al., 2023; Hong et al., 2024）。

把它和 RLHF 对比会更清楚。RLHF 常见路径是“先训练奖励模型，再做在线 RL 更新”；DPO/ORPO 的路径是“直接在离线偏好对上优化”。所以 DPO/ORPO 通常更轻量、迭代更快，也更容易先搭出第一版偏好对齐系统。

具体到训练数据，每条样本通常是三元组：问题 \(x\)、更好的回答 \(y^+\)、较差的回答 \(y^-\). 模型要学到的不是“唯一标准答案”，而是“在同一问题下把好答案概率抬高、把差答案概率压低”。这就是下面公式在做的事： \[ \Delta_\theta(x)=\log\pi_\theta(y^+\mid x)-\log\pi_\theta(y^-\mid x),\quad \text{train to increase } \Delta_\theta(x). \] \(\Delta_\theta(x)\) 就是“偏好间距”。它越大，说明模型越偏向 \(y^+\)；它为负，说明模型还在偏向 \(y^-\). 例如同一题下，模型给 \(y^+\) 的概率是 0.6、给 \(y^-\) 的概率是 0.2，那么 \(\Delta=\log 0.6-\log 0.2=\log 3>0\)；训练会继续把这个间距拉大。用对数的好处是优化更稳定，便于训练。

如果把 DPO 再写得更“训练目标”一点，它常被写成下面这种逻辑斯蒂形式： \[ \mathcal{L}_{\text{DPO}}(\theta) = - \log \sigma\!\Big( \beta \big[ (\log \pi_\theta(y^+\!\mid x)-\log \pi_\theta(y^-\!\mid x)) - (\log \pi_{\text{ref}}(y^+\!\mid x)-\log \pi_{\text{ref}}(y^-\!\mid x)) \big] \Big) \] 其中 \(\sigma(\cdot)\) 是 logistic 函数，\(\pi_{\text{ref}}\) 是参考模型。这个目标的直觉非常直接：不仅要让当前模型更偏向 \(y^+\) 而不是 \(y^-\)，还要以参考模型为锚，避免因为偏好优化把整体行为拉得过远。你可以把它理解成“在参考模型定义的局部坐标系里，拉大 chosen 与 rejected 的概率间距”。

DPO 和 ORPO 的差异可以先这样记。DPO 通常有一个“参考模型锚点”，更强调不要偏移过快；ORPO 更强调单阶段目标，把监督学习和偏好优化并在一起，流程更紧凑。实务上，若你更看重训练稳定和漂移可解释性，常先试 DPO；若你更看重流程简化和训练效率，常把 ORPO 作为候选。

这类方法的优点是：实现相对简单、离线数据即可起步、收敛通常更平稳。边界同样明显：它学到的能力上限受偏好数据覆盖限制，而且“更受喜欢”不一定等于“更正确”。因此评估时不能只看偏好胜率，还要同时看任务正确率、安全指标和分布漂移；必要时要配 verifier 或任务评测来补上正确性约束。

当偏好层稳定后，下一阶段就会进入“模型如何在真实系统里可靠调用工具”这个更工程化的问题。

这一阶段的核心是把优化目标从“语言似然更高”转向“用户真实更满意”。落地时最关键的控制点是偏好数据覆盖度、标注质量和漂移约束；最常见误区是把偏好胜率提升直接等同于正确性提升，忽视了“好看答案”和“正确答案”之间的差距。

5 工具使用与 RAG

这一步把模型从“会说”推进到“会调用系统完成任务”。

Figure 5: 工具使用训练与约束解码

以财务运营助手为例，用户问：“请给出本周现金流预警，并判断是否需要延后市场投放预算。”如果模型只“会说”，它可能给出一段看起来合理但缺乏依据的建议；因为它并没有实时拿到应收账款、应付账款、银行余额和预算执行率。这样的回答语言流畅，但决策风险很高。

进入工具使用与 RAG 阶段后，流程会变成“先查数据，再下结论”：先调用 ERP/资金系统接口拉取最新余额与账期，再调用预算系统读取投放执行进度，必要时通过 RAG 检索内部财务政策，然后基于这些证据生成结论和行动建议。这样得到的回答不只是“像对”，而是“有数据来源、可追溯、可执行”。

5.1 工具使用训练（Tool-use Training）

工具使用训练解决的是“模型会说但不一定会做”这个问题：它会幻觉，难以稳定访问实时/私有数据，也不擅长精确计算。过去常见办法是在提示词里反复强调“不要猜”，但这种软约束无法保证模型稳定触发工具，更不能保证参数结构合法。新方法把工具调用本身纳入训练轨迹，让模型学习“选工具—填参数—读结果—再作答”的完整闭环（Schick et al., 2023; Patil et al., 2023; Qin et al., 2023），可抽象为： \[ k \sim p_\theta(k\mid x),\quad a=f_\theta(x),\quad o=\text{Tool}_k(a),\quad y\sim\pi_\theta(\cdot\mid x,o). \] 这串式子可以按流程读：先按概率选工具 \(k\)，再生成参数 \(a\)，调用工具得到观测 \(o\)，最后基于 \((x,o)\) 生成答案 \(y\)。其中“\(\sim\)”表示“按该分布采样”。比如问“今天美元兑人民币是多少”，模型先选汇率 API，再填参数（币种、日期），拿到返回值后再组织语言回答。
RAG 是其中一种特例，即把“工具”具体化为检索器（Lewis et al., 2020）。这种做法能显著提升 groundedness 和事实性，但代价是系统复杂度明显上升：执行环境、错误恢复、权限边界和工具预算都需要工程化治理。

工具会用了之后，下一步要解决的是“调用结果是否稳定可执行”，也就是解码阶段的结构可靠性问题。

5.2 约束解码（Constrained Decoding）

约束解码针对的是“几乎正确但不可执行”的结构错误：即使工具使用训练做得不错，模型仍可能输出解析失败的 JSON 或不合 schema 的参数。旧做法通常是“先生成、再校验、再修复”，虽然可行，但失败路径长、重试成本高、线上稳定性依赖补丁逻辑。约束解码把校验前移到生成过程，在 token 级别限制输出空间，只允许合法延展： \[ y \in \mathcal{V}, \] 这里 \(y\) 是模型输出字符串，\(\mathcal{V}\) 是“所有合法输出”的集合（比如满足某个 JSON schema 的所有字符串）。\(y \in \mathcal{V}\) 的意思是：输出必须属于合法集合，不能越界。直觉上它像一条“轨道”，模型每走一步都不能脱轨。OpenAI Structured Outputs 的 strict: true 就体现了这个思想（OpenAI, 2024）。
它的优势是结构可靠性显著提升，代价是可能增加延迟，而且“格式正确”依然不等于“语义正确”。

当结构可靠性建立后，后训练的重点会转向“如何在可验证任务上系统性提升正确率”。

这一阶段最关键的问题不是“会不会调用工具”，而是“是否在正确时机调用并稳定调用成功”。因此评估重点应放在 schema 有效率、工具成功率和 groundedness，而不是只看工具调用率；后者是最常见误区，因为高调用率并不代表高质量调用。

6 推理与智能体 RL（可验证正确性）

这一步的核心是：把“看起来像对”升级成“可验证地对”。

用财务运营助手举例最直观。设任务是“月末关账异常排查”：系统要读取总账、应收、应付和银行流水，定位差异来源，并给出可执行修复步骤。一个“会说但不一定真对”的模型，可能写出很像审计报告的文字，却把借贷方向、科目映射或对账口径搞错；这类错误在表面上不明显，但会直接影响财务决策。

RL的目标就是把这类任务变成“可机器核验”的训练问题。比如你可以把 verifier 设成：分录平衡是否成立、差异金额是否与系统记录一致、修复步骤是否满足公司关账 SOP。后面三节正好对应这个例子：先决定只看最终是否对账通过（ORM）还是连中间步骤都打分（PRM）；再用自训练闭环扩大“已验证正确”的轨迹数据；最后用 GRPO 类方法在可验证奖励上做更稳定的大规模优化。

6.1 结果监督 vs 过程监督（ORM vs PRM）

ORM vs PRM 讨论的是“监督信号放在哪里”这一核心问题：只看最终答案会让奖励过于稀疏，只模仿推理文本又容易学会“像在推理”而不是真的做对。过去常见路线是结果奖励（实现简单）或纯 SFT（扩展容易），但两者都有明显上限。过程监督的关键改动是把反馈下沉到中间步骤（Lightman et al., 2023），对比写法是： \[ r_{\text{out}} = \mathbf{1}[\text{final answer passes}],\qquad R_{\text{proc}}=\sum_{t=1}^{T} r_t. \] 第一个式子里的 \(\mathbf{1}[\cdot]\) 是“指示函数”：条件成立取 1，不成立取 0，所以它只看最终对错；第二个式子把每步奖励 \(r_t\) 累加，表示“过程对一点就加一点分”。可以类比数学解题：只看最终答案是“对/错”二元评分，过程奖励是“步骤分”。
结果监督便宜稳健但学习慢，过程监督信号密但标注成本高且噪声风险大，两者都高度依赖 verifier 精度。

继续沿用“月末对账差异 12 万元排查，ORM 的打分规则可以是“最终是否给出正确差异来源 + 调整分录是否借贷平衡 + 是否通过 SOP 校验”，全部满足记 1，否则记 0。PRM 会把同一任务拆成步骤打分，例如“是否先核对银行流水”“是否正确计算应收账龄差”“是否定位到未匹配回款”“是否生成合法调整分录”，每步给局部奖励。这样即使最终答案没全对，模型也能从中间正确步骤中学习，通常比纯结果监督收敛更快。

当监督形式确定后，下一步自然是解决“高质量推理数据从哪里来”的规模化问题。

6.2 自训练闭环（STaR / ReST）

自训练闭环要解决的是推理数据供给瓶颈：高质量轨迹昂贵，靠人工全量标注无法持续扩容。旧路线主要依赖人工扩库，成本高且增长慢。STaR/ReST 的核心改动是“生成候选—自动验证—回灌训练”的循环（Zelikman et al., 2022; Zhang et al., 2024），其 best-of-\(K\) 的基本概率收益可写为： \[ \Pr(\text{at least one correct}) = 1-(1-p)^K. \] 这个公式来自最基础的概率补集：先算“\(K\) 次都失败”的概率 \((1-p)^K\)，再用 1 减掉它，就得到“至少成功一次”的概率。举例：若单次成功率 \(p=0.2\)，采样 \(K=5\) 次，则成功至少一次的概率是 \(1-0.8^5=0.672\)，比单次 0.2 高很多。
这种闭环的数据放大效率很高，但也容易进入“自我确认循环”：如果 verifier 偏弱或有偏，系统会稳定学偏。

系统针对“12 万元差异排查”一次采样 8 条候选推理轨迹。每条轨迹都要通过自动校验：差异来源是否与系统账实一致、调整分录是否借贷平衡、模拟过账后差异是否归零、步骤是否符合关账 SOP。若 8 条里只有 2 条通过，就把这 2 条作为“高质量轨迹”回灌训练；下一轮再采样时，模型更容易生成类似轨迹。这个循环的本质是“先多试，再只学被 verifier 证明正确的答案”。

当同一任务的数据闭环跑起来后，训练算法层面就会转向“怎样在大规模下更稳、更省资源地优化策略”。

6.3 GRPO 及其变体

GRPO 及其变体解决的是“PPO 在长推理场景里成本高、稳定性压力大”的问题。过去主流是继续沿用 PPO + critic，路径成熟但资源开销和调参负担都偏重。GRPO 的关键改动是使用同题多样本的组内相对比较构造优势，弱化对显式 critic 的依赖（Shao et al., 2024）： \[ \bar r = \frac{1}{K}\sum_{i=1}^{K} r_i,\qquad A_i=r_i-\bar r. \] 这里先算组内平均奖励 \(\bar r\)，再把每个样本的优势写成 \(A_i=r_i-\bar r\)，意思是“比组平均好多少/差多少”。例如同题 4 个候选奖励是 [1, 0, 0, 0]，则 \(\bar r=0.25\)，第一个样本优势 \(A_1=0.75\)，其余是 -0.25，更新时自然会推高第一个、压低其余。这个设计把“绝对打分”转成“同题相对比较”，方差通常更小。
后续变体（Dr. GRPO、GSPO、DAPO、LUFFY）本质上都在回答同一个问题：怎样让“同题多采样 + 相对比较”这条路线更稳、更省、更不容易学偏（Liu et al., 2025; Zheng et al., 2025; Yu et al., 2025; Yan et al., 2025）。先把四个关键词讲清楚会更好理解。
基线（baseline）：用来衡量“这个样本比平均好多少”。基线估计不稳，优势值就会抖，训练容易乱跳。
clipping：限制每次更新幅度，避免策略一步走太远。它像“安全护栏”，太松会发散，太紧会学不动。
更新粒度：到底按 token 级更新，还是按整条序列更新。粒度越细，信号越密但噪声也可能更大；粒度越粗，稳定性常更好但细节反馈更少。
采样策略：每个问题采几条、怎么采、是否引入更强模型轨迹。采样决定了探索强度，也直接决定训练成本。

对应到各变体，可以这样读：Dr. GRPO 更关注基线/归一化带来的优化偏差与效率问题；GSPO 更强调序列级比率与序列级 clipping，在长输出任务里通常更稳；DAPO 强调解耦 clipping 与动态采样调度，让“稳定性”和“探索强度”更可控；LUFFY 引入 off-policy guidance，让模型不只依赖当前策略采样，还能学习更强轨迹。它们并不是互斥关系，而是沿着这四个旋钮做不同侧重。

这一路线的优势是可扩展性和训练稳定性更好，代价是采样成本线性增加，且 verifier 一旦可被利用，模型会更快学偏。

模型对“12 万元差异排查”生成 4 条完整轨迹，verifier 奖励分别是 [1.0, 0.6, 0.2, 0.0]。可以把它们理解为：第一条差异定位正确且分录可过账；第二条差异定位正确但修复步骤不完整；第三条只给出模糊怀疑点；第四条方向错误。组均值是 \(\bar r=0.45\)，对应优势是 [0.55, 0.15, -0.25, -0.45]。更新时第一条被明显强化，第二条小幅强化，后两条被抑制。你可以把 GRPO 理解成“同题内部排名学习”：不是问“绝对几分”，而是问“这组里谁更值得学”。

当可验证正确性提升到位后，最后一个工程问题往往是“如何把能力迁移到更便宜的部署形态”。

这一阶段的重点不是“回答写得像不像专家”，而是“答案能不能被机器检查为真”。例如在财务任务里，措辞再专业，只要分录不平衡或金额对不上，就应判定为错。工程上最重要的三件事是：第一，verifier 本身要准（别把错判成对）；第二，要做反作弊评测（防止模型学会钻评分规则空子）；第三，要监控长度漂移（防止模型靠无意义变长刷分）。最常见误区是先把 rollout 数量做大，以为“样本更多就会更好”，却没有先验证奖励和校验器质量；这样只会更快把错误信号放大，模型会稳定学偏。

7 蒸馏

Figure 6: 蒸馏：从强教师到便宜学生

蒸馏解决的是“效果可以，但部署太贵”的问题。

7.1 黑盒蒸馏 vs 白盒蒸馏

黑盒/白盒蒸馏解决的是同一个现实矛盾：教师模型效果很好，但部署太贵；学生模型便宜，但直接训练又很难复现教师能力。两者主要区别不在“目标不同”，而在“你能拿到教师模型多少内部信息”。

黑盒蒸馏指你看不到教师内部，只能拿到输入和教师输出文本（常见于调用闭源 API）。在这种设置下，你通常做的是“让学生学会复现教师回答风格与决策模式”，常见做法是采样高质量教师答案后用 SFT 或偏好优化训练学生。它的优点是工程门槛低、适配闭源教师；缺点是信号相对粗糙，学生只能学到“教师最后说了什么”，学不到“教师在每个 token 上如何权衡其他候选词”。

白盒蒸馏指你能访问教师 logits 或概率分布（有时还包括中间层表示）。这时可以直接对齐教师和学生在每一步的分布差异，训练信号更细，迁移通常更充分。典型目标是最小化教师分布与学生分布之间的 KL 距离（Hinton et al., 2015）： \[ \mathcal{L}_{\text{KD}} = \mathrm{KL}\!\left(p_T(\cdot\mid x)\|p_S(\cdot\mid x)\right). \] 这里 \(p_T\) 是教师分布，\(p_S\) 是学生分布，KL 越小，表示学生在“每一步 token 判断”上越像教师。一个二分类小例子：若教师给 [0.9, 0.1]，学生给 [0.6, 0.4]，KL 较大；训练后学生变成 [0.85, 0.15]，KL 下降，表示迁移更成功。

什么时候用什么，可以按这条准则判断：如果教师是闭源 API、拿不到 logits、目标是快速降本上线，优先黑盒蒸馏；如果你能访问教师权重或 logits，且任务对保真度要求高（如安全边界、工具格式、专业术语细粒度行为），优先白盒蒸馏。很多团队会采用混合路径：先黑盒快速做第一版学生，再在可控教师上做白盒精修关键能力。

无论黑盒还是白盒，蒸馏都能显著降低延迟和成本，支持高 QPS 和端侧部署；共同风险是学生会继承教师偏差，而且教师版本变化会引发学生行为漂移，因此都需要版本锁定、数据来源追踪和学生回归评测（Kim & Rush, 2016; Chen et al., 2024）。

理解蒸馏的收益和边界后，本章的六阶段后训练闭环就完整了。

这一阶段的关键问题是：在降本降延迟时，哪些教师能力必须被保住。落地时应把注意力放在蒸馏样本质量、教师版本管理和学生回归评测上；最常见误区是只看压缩比与速度收益，而忽略安全行为和格式一致性回归。

8 对齐评估

如果前六个阶段解决的是“如何改变模型”，那么评估解决的就是“你怎么知道它真的变好了”。对齐系统最危险的错觉，不是没有指标，而是只有局部指标：人类偏好胜率上升了，真实性却下降了；schema 合法率上升了，语义正确性却下降了；安全拒答率上升了，正常请求也被一起拒掉了。没有独立的评估栈，post-training 很容易变成“围着训练目标自我感动”。

8.1 概念：为什么 alignment 很难测

alignment 之所以难测，首先因为它不是单一标量，而更像一个向量。一个真实的生产助手，至少同时受四类目标约束：

  • helpfulness：是否真的帮助用户完成任务；
  • harmlessness：是否越过安全、合规和权限边界；
  • truthfulness / faithfulness：答案是否真实，是否与证据一致；
  • system reliability：格式是否可执行、工具是否稳定、延迟和成本是否可接受。

如果把上线 gate 写成一个最简的布尔函数，可以抽象成： \[ G(x)=\mathbf{1}[\text{safe}(x)\land \text{schema-valid}(x)\land \text{grounded}(x)\land \ell(x)\le \tau_\ell \land c(x)\le \tau_c] \] 其中 \(\ell(x)\) 是延迟，\(c(x)\) 是单位请求成本，\(\tau_\ell,\tau_c\) 是上线阈值。这个公式的工程意义很直接：只要有一项越界，整个样本就不应被判为“上线可接受”。也正因为如此，对齐评估必须是多维 gate，而不是单一分数排行榜。

8.2 工程系统：自动评测、人类评测、红队与线上回放

成熟团队的评估栈通常分成四层。

第一层是自动离线评测。它适合测结构性和高频指标，例如 schema 合法率、字段完整率、tool-call 成功率、verifier 通过率、引用覆盖率和 benchmark 正确率。自动评测便宜、快、可持续集成，但它对“回答是否像一个成熟产品”这类细腻偏好不够敏感。

第二层是人类评测。它适合评估帮助性、信息密度、解释质量、品牌语气和高风险边界判断。工程上，人类评测常被做成 pairwise comparison，于是模型间的偏好胜率可以写成： \[ \widehat{\text{WinRate}} = \frac{1}{N}\sum_{i=1}^{N}\mathbf{1}\!\left[y_{\text{model}}^{(i)} \succ y_{\text{baseline}}^{(i)}\right] \] 这里的 \(\widehat{\text{WinRate}}\) 不是“绝对正确率”，而是“在固定样本集上，相对于某个基线模型的头对头胜率”。

第三层是红队与对抗评测。它专门测试 happy path 之外的失败：prompt injection、越权请求、越狱、过度拒绝、误触发工具、风险操作建议、schema 边界绕过。没有红队，系统常常只是在理想输入上看起来很稳。

第四层是线上回放与 shadow traffic。这部分用来捕捉模板漂移、检索索引变化、工具版本变化、路由错误和真实分布切片中的静默回归。很多最贵的事故，离线集根本看不出来，只有上了真实流量或近真实流量才会暴露。

对工具型系统，至少要把下面几类指标拆开，而不是混成一个“整体分数”：

\[ \text{SchemaValid} = \frac{\#(\text{schema-valid outputs})}{\#(\text{all outputs})} \]

\[ \text{Tool Precision} = \frac{\#(\text{correct tool calls})}{\#(\text{all tool calls})}, \qquad \text{Tool Recall} = \frac{\#(\text{correct tool calls})}{\#(\text{tool-needed cases})} \]

\[ \text{Grounded Claim Rate} = \frac{\#(\text{claims supported by retrieved/tool evidence})}{\#(\text{all factual claims})} \]

维度 典型问题 常用指标
指令遵循 是否按角色、按格式、按系统提示输出 schema 有效率、字段完整率、system-prompt 遵循率
偏好质量 是否“更像产品想要的答案” 人类偏好胜率、简洁度、可执行性、品牌语气一致性
工具可靠性 会不会在该调时调、参数对不对、结果有没有正确消费 tool precision / recall、参数合法率、工具成功率
grounding 是否引用证据、是否无依据断言 引用覆盖率、证据一致性、无证据断言率
安全性 是否越权、是否过度拒绝 违规率、过度拒绝率、拒答 precision / recall
运行成本 是否满足上线预算 p50/p95 延迟、平均 token、平均工具调用数、单位请求成本

8.3 失败模式：评估栈本身也会误导你

评估体系也会出错，甚至会主动把系统带偏。

第一类是 benchmark overfitting。模型在固定测试集上持续上涨，真实用户体验却没有同步改善。这往往意味着模型学会了题型，而不是学会了任务。

第二类是 judge drift。很多团队会用更强模型做 LLM-as-judge，这很实用，但 judge 本身也有偏好与漂移。如果长期只用一个 judge，训练系统很容易朝“讨 judge 喜欢”的方向优化，而不是真朝用户价值优化。

第三类是 指标混淆。最典型的例子是把 schema-valid 当成 semantic-valid，把人类偏好胜率当成事实正确率，把高工具调用率当成高 groundedness。只要指标没有拆开，模型就很容易在一个便宜代理量上“做得很漂亮”，同时把真正重要的能力一起训坏。

第四类是 线上静默回归。模型权重没变，但模板、tokenizer、工具版本或检索索引变了。离线集全绿，上线表现却显著漂移。没有 shadow traffic、A/B 和回放集，这类问题往往发现得最晚。

8.4 实践结论：评测是训练闭环的一部分

成熟的 post-training 团队不会把评测当成训练完成后的“验收动作”，而会把它当成训练环的一部分。一个稳健流程通常是：

  1. 先围绕关键故障模式建立离线集和切片集；
  2. 每次训练后先跑自动回归，再看切片；
  3. 对关键版本做人类评测与红队；
  4. 上线后继续采 shadow traffic、失败样本和线上 drift 信号；
  5. 把失败切片回灌成下一轮训练数据、偏好对或 verifier case。

换句话说，alignment 不是“训练完 → 测一下”，而是“训练 → 评测 → 失败分析 → 数据回灌”的闭环系统。

9 工程案例

案例1：安全样本加重之后，模型开始过度拒答

症状：模型在高风险请求上的拒答更稳定了，但它也开始拒绝大量本来可以安全回答的财务问题，例如正常的预算解释、审批流程说明和合规范围内的报销咨询。

根因：SFT 或偏好数据中过度强调了拒答示范，或者把”敏感外观”误当成了”必须拒绝”。模型学到的不是细粒度边界，而是一个粗糙启发式：只要闻起来像风险，就先拒绝。

工程修复：重新平衡安全数据比例，补充”看起来敏感但其实可以安全回答”的正例；把拒答评估拆成 precision / recall，而不是只看总拒答率；对边界模糊场景加入”可回答但需加约束”的中间标签。

案例2：JSON 完全合法，但动作完全错误

症状：系统输出的 tool-call JSON 总是合法，validator 也通过，但模型经常调用错工具、填错 account_id，或者把查询日期写成未来日期。表面上”一切结构都对”，业务上却在执行错误动作。

根因：团队把 schema-valid 当成 success，把 semantic-valid 留空。训练和评测只奖励”结构可解析”，没有额外检查”动作是否和当前任务、权限和世界状态一致”。

工程修复：把结构正确和语义正确拆成两类指标与两类数据；在训练中加入”结构合法但语义错误”的反例；在评测中为工具调用加入 argument-level correctness、world-state consistency 和 action authorization 检查。

案例3：SFT 之后模型像客服脚本

症状：模型能遵循指令，结构也正确，但回答拖沓、格式刻板、句式高度重复。用户觉得它”像客服脚本”“像标准答案生成器”。

根因：SFT 标签过长、风格过度统一；大量样本来自同一个合成源；训练数据过于强调礼貌和完整性，缺少真实对话中的信息密度变化。

工程修复：缩短目标答案；显式加入”先直答、再解释”的示范；混入更自然的真实交互；用长度切片评测和用户偏好比较替代单纯 benchmark。

案例4：RLHF 后模型越来越谄媚

症状：模型开始频繁使用”好问题”“你说得非常对”“你的判断很有洞察力”之类的话术，哪怕并不能帮助完成任务。

根因：奖励模型把礼貌、迎合和长度误当成高质量代理变量。策略在 RL 中学会放大这些高 reward 但低价值的表面特征。

工程修复：重做偏好 rubric，把真实性、校准和不确定性表达写进去；加入”态度好但事实差”的反例；在评测里单独切片检查 sycophancy，而不是只看偏好胜率。

案例5：有检索工具，模型还是硬猜

症状：系统已经接入知识库和搜索工具，但模型常在没有证据时直接回答，甚至把过时信息说得很笃定。

根因：训练数据里”信息不足时必须检索”的模式太弱；运行时没有把”无证据直接回答”视为失败；评测只看最终语言质量，不看 grounding。

工程修复：补工具轨迹数据；对关键结论要求引用；将”有无证据支持”纳入自动评测；必要时在高风险场景强制工具优先，而不是允许直接回答。

案例6：对齐更好了，但推理能力更差了

症状：模型变得更礼貌、更安全、更稳定，却在复杂推理任务上明显退步：更早停、更多保守措辞、更少直接下结论。

根因：偏好或安全优化过度压制了”探索性”和”明确给出结论”的行为；训练数据过度奖励保守口径，导致 reasoning 任务中也沿用了同样策略。

工程修复：把评测按任务类型切开：对话对齐、工具任务、数学 / 代码 reasoning 分开测；在 reasoning 场景单独保留更直接、更有验证约束的训练目标；不要用同一个偏好目标去压所有任务。

案例7：模型没换，线上行为却突然变了

症状：离线评测没有明显退化，但上线后工具调用边界、拒答位置和多轮对话行为都变了。

根因：训练时和推理时使用了不同聊天模板，或 tokenizer / special token 版本漂移。模型权重没变，输入分布却悄悄变了。

工程修复：把 chat template 当成接口契约；固定模板和 tokenizer 版本；对典型会话保存字符串与 token id 级金样本回归；上线前做模板 diff，而不是只看 prompt 文案。

10 本章小结

这一章讲的是同一件事：怎样把“本来会生成文本的模型”，一步步变成“能在真实系统里稳定做事的助手”。后训练不是某一个算法名字，而是一条从行为塑形到上线降本的工程链路。

六个阶段可以按“先能用、再好用、再可靠、再便宜”来理解。SFT解决“先把话说对格式、说对角色”；重点是模板一致性与监督边界。PEFT解决“同一个底模如何低成本做很多专精版本”；重点是 adapter 设计、路由正确率和版本管理。偏好对齐解决“答得对但不好用”的问题；重点是把用户偏好和安全边界一起学进去，并控制行为漂移。工具使用与 RAG解决“只会说不会做”；重点是把调用工具、读结果、按证据回答这条链路做稳。推理与智能体 RL解决“看起来像对但不一定真对”；重点是引入可验证奖励，用 verifier 驱动可核验正确性。蒸馏解决“效果够好但部署太贵”；重点是把能力迁移到更小模型，同时守住安全与格式回归。

如果要抓住后训练最重要的意义，可以记一句话：后训练是在做“能力产品化”。它把模型的原始生成能力，转化成可控行为、可验证质量和可承受成本。没有后训练，模型可能“看起来聪明”；有了后训练，模型才更可能“在生产里可靠”。

落地时建议始终用同一套思维检查每个阶段：你改了哪一个训练杠杆、用什么指标证明它真的变好、出了问题能否快速回滚。真正稳定的方案，不是“单点最优”，而是“训练杠杆 + 评测闭环 + 回滚机制”三者同时成立。

10.1 问题小结

1. 什么是 post-training？
Post-training 是把一个预训练得到的基础语言模型，进一步改造成可作为助手使用的过程。它通常包括 SFT、偏好优化、工具使用训练、推理训练和蒸馏，目标是让模型从“会续写文本”变成“会遵循指令、能安全工作、可部署”。

2. 为什么预训练模型不能直接拿来当 AI 助手？
因为预训练目标只是拟合文本分布，而不是拟合“产品想要的行为”。基础模型会生成看起来合理的文本，但不会天然遵守角色、格式、工具接口和安全边界，也不知道什么时候该拒绝、什么时候该调用外部系统。

3. instruction tuning 是什么？它和预训练的区别是什么？
instruction tuning 本质上是一类面向任务与角色行为的监督微调。预训练教模型“像语料那样继续写”；instruction tuning 教模型“像助手那样完成用户任务”。

4. 为什么 alignment 是必要的？
因为产品不是语言基准。一个可上线的助手必须同时满足 helpfulness、safety、truthfulness、schema validity、tool reliability 和 cost constraints。alignment 就是在这些约束下塑造行为。

5. 现代 post-training 为什么是多阶段的？
因为不同阶段修的是不同故障：SFT 修行为与格式，偏好优化修质量排序，工具训练修外部动作，reasoning RL 修可验证正确性，蒸馏修部署成本。它们不是同一个问题的不同叫法，而是系统中不同层的杠杆。

6. 什么是 SFT？它什么时候是首选？
SFT 是用高质量示范回答训练模型，使其学会按指令、按角色、按格式输出。它是行为和格式故障的第一杠杆；如果问题主要是知识缺口、grounding 或 verifier 缺失，SFT 往往不是首选。

7. 什么时候应该选 PEFT？
当你需要很多专精版本、预算有限、希望快速迭代任务版或租户版时，PEFT 很合适。全量微调适合能力迁移非常深或版本数很少的情况；只靠 prompt 适合低风险试探，但通常不够稳定。

8. 偏好数据是怎么收集的？
先为同一个 prompt 生成多个候选回答，再让人工或 AI 辅助评审比较哪个更好，最后构造成 (prompt, chosen, rejected)。关键不在于“有没有选出 winner”，而在于 rubric 是否真的在奖励你想要的产品行为。

9. RLHF 和 DPO 的区别是什么？
RLHF 先学奖励模型，再做在线 RL；DPO 直接在离线偏好对上优化 chosen 与 rejected 的相对概率。前者表达力更强但系统成本更高，后者更轻量、更稳、也更容易先落地。

10. 什么是 schema-valid 的工具输出，什么又是语义正确的工具使用？
schema-valid 只表示输出在结构上可解析、满足 JSON schema 或 function signature。语义正确则要求工具选对、参数填对、动作符合权限和世界状态、结果被正确消费。前者是语法层，后者是任务层。

11. 为什么 verifier 常常比更大的模型更重要？
因为在可验证任务中，真正决定训练方向的是反馈质量。没有 verifier，再大的模型也只能靠语言先验“猜”；有了强 verifier，较小模型也能围绕真实任务成败信号学习更有效的轨迹。

12. 现代 post-training pipeline 一般长什么样？
一个常见顺序是：SFT → PEFT（可选）→ 偏好对齐 → 工具使用 / RAG → 推理 / 智能体 RL（可选）→ 蒸馏。顺序背后的逻辑是：先让模型可用，再让它更像产品想要的助手，再让它会做事、会验证、最后能便宜部署。

13. 如何评估 alignment 质量？
不能只看一个分数。至少要同时看偏好胜率、事实性 / groundedness、安全性、schema validity、tool precision / recall，以及延迟和成本。成熟团队还会把红队、线上回放和 shadow traffic 纳入 release gate。

14. helpfulness 和 safety 的冲突怎么处理？
不要抽象地讨论“更安全还是更有帮助”，而要把场景切片。对每个切片单独定义可回答、需约束回答、必须拒答三类边界，再分别评估 precision / recall，而不是只看总拒答率。

15. 为什么 post-training 往往是迭代的？
因为模型一更新，数据分布、失败模式和用户交互都会变。旧的偏好对会过时，新的工具错误会出现，新的风险边界也会暴露。所以后训练天然是“训练—评测—失败分析—回灌”的迭代过程。

16. 为什么对齐好了还要蒸馏？
因为“已经很好用的教师模型”不等于“已经适合直接上线的模型”。蒸馏解决的是成本重新对齐：把教师的关键行为迁到更快、更便宜、更易部署的学生模型上，同时为学生单独做长尾与安全回归。

10.2 给 AI 工程师的实践清单

把这一章压缩成工程动作，可以落成下面这张“先问什么，再动哪根杠杆”的清单：

如果你的主要故障是…… 第一优先杠杆 先别急着做什么
输出格式不稳、角色漂移、工具字段老写错 SFT + chat template + completion-only mask 先别急着上更复杂的偏好优化
需要很多专精版本，但全参数微调太贵 PEFT + adapter routing 不要为了省训练费而省回归测试
两个答案都不算错，但总有一个更像产品想要的答案 preference data + DPO / ORPO 不要把偏好胜率当成事实正确率
该查工具时不查、该停时不停 tool traces + schema + validator + constrained decoding 不要只靠 prompt 反复提醒
多步任务经常在中间走偏 verifier + process reward + search / self-training loop 不要把“更长的思维链”误当成“更强推理”
成本和延迟已经无法上线 distillation + targeted regression 不要只看总体 benchmark 就上线学生模型

还有四条更高层的原则值得反复记住：

  1. 先按故障类型选方法，再按流行度选方法。
    问题是行为故障、偏好故障、工具故障、verifier 故障还是部署成本故障，决定了第一根杠杆。

  2. 把训练目标和上线 gate 分开管理。
    reward 不是 release gate，偏好胜率也不是 production readiness。上线要看的是多维约束是否同时满足。

  3. 把工具当契约，不把工具当文字装饰。
    训练负责“什么时候该调、调什么、如何消费结果”；运行时约束负责“输出是否合法、能不能执行”。

  4. 把评测栈当成和训练栈同等重要的系统。
    没有自动回归、切片集、人类评测、红队和线上回放，后训练几乎不可能稳定迭代。

11 参考资料

  1. Ouyang et al. Training Language Models to Follow Instructions with Human Feedback. 2022.
  2. Wang et al. Self-Instruct: Aligning Language Models with Self-Generated Instructions. 2022.
  3. Hugging Face. Chat Templating documentation.
  4. Hugging Face TRL. SFTTrainer documentation.
  5. Hu et al. LoRA: Low-Rank Adaptation of Large Language Models. 2021.
  6. Dettmers et al. QLoRA: Efficient Finetuning of Quantized Language Models. 2023.
  7. Schulman et al. Proximal Policy Optimization Algorithms. 2017.
  8. Williams. Simple Statistical Gradient-Following Algorithms for Connectionist Reinforcement Learning. 1992.
  9. Rafailov et al. Direct Preference Optimization: Your Language Model is Secretly a Reward Model. 2023.
  10. Hong et al. ORPO: Monolithic Preference Optimization without Reference Model. 2024.
  11. Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools. 2023.
  12. Qin et al. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. 2023.
  13. Patil et al. Gorilla: Large Language Model Connected with Massive APIs. 2023.
  14. OpenAI. Function Calling documentation.
  15. OpenAI. Introducing Structured Outputs in the API. 2024.
  16. Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. 2020.
  17. Lightman et al. Let’s Verify Step by Step. 2023.
  18. Wang et al. Math-Shepherd: Verify and Reinforce LLMs Step-by-step without Human Annotations. 2023.
  19. Shao et al. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models. 2024.
  20. Liu et al. Understanding R1-Zero-Like Training: A Critical Perspective (Dr. GRPO). 2025.
  21. Zheng et al. Group Sequence Policy Optimization. 2025.
  22. Yu et al. DAPO: An Open-Source LLM Reinforcement Learning System at Scale. 2025.
  23. Yan et al. Learning to Reason under Off-Policy Guidance (LUFFY). 2025.
  24. Zelikman et al. STaR: Bootstrapping Reasoning With Reasoning. 2022.
  25. Zhang et al. ReST-MCTS*: LLM Self-Training via Process Reward Guided Tree Search. 2024.
  26. Hinton et al. Distilling the Knowledge in a Neural Network. 2015.
  27. Kim, Rush. Sequence-Level Knowledge Distillation. 2016.
  28. Chen et al. Knowledge Distillation of Black-Box Large Language Models. 2024.