泛化悬崖：微调如何导致隐性的能力退化

一家企业软件公司的团队在客户支持工单上微调了一个 7B 模型。目标指标——解决准确率——提高了 12 个百分点。团队发布了它。三周后，产品出现了谁也没预料到的第二种失败模式：模型悄然失去了处理多步问题的能力。用户会问一些稍超出支持领域的问题，得到的是自信但逻辑混乱的回答。模型牺牲了它不知道自己需要的广度，换取了它能够衡量的深度。

这就是泛化悬崖（generalization cliff）：紧随窄领域微调而来的隐性能力退化。与崩溃或超时不同，它不产生错误。模型仍然响应。它只是在与训练分布相邻的任务上表现变差——而这些任务从未出现在评估套件中。

为什么微调模型会遗忘

研究文献中对这一现象有一个称呼：灾难性遗忘（catastrophic forgetting）。其机制是梯度干扰（gradient interference）。当你针对某项窄任务进行微调时，编码新行为的梯度更新会与存储先前能力的参数子空间发生冲突。较小的更新也会让你偏离基础模型的优化点；旧能力周围的损失函数曲面变得更加陡峭且脆弱。

一项 2025 年的机制分析确定了三种具体的失败模式。首先，注意力权重梯度在旧目标和新目标之间发生冲突——模型无法同时兼顾两者。其次，中间层表示偏离了预训练的最优点，扭曲了模型编码通用概念的方式。第三，损失景观在新任务周围变得平坦，而在之前的任务周围变得更加陡峭，使得任何参数扰动对保留下来的能力都越来越危险。

量化结果令人警醒。原始 LoRA 微调会导致约 43% 的知识损失（按预训练基准衡量）。标准的 OpenAI 微调运行会导致约 10% 的损失。专门的持续学习（continual-learning）方法能将其降至 3%，但这些方法需要大多数团队尚未具备的额外工具。对于进行直接微调的团队来说，基准预期是两位数的知识损失——其中大部分都是在评估套件之外的任务上悄然发生的。

相邻任务盲点

核心问题不在于微调导致了遗忘——而在于团队发现遗忘的时间线不对。标准的微调工作流程是这样的：定义目标任务，收集标注数据，进行微调，在来自同一任务的预留数据上进行评估，发布。一切都通过了。退化是真实的，但却是不可见的，因为评估集与训练集来自同一分布。

团队没有测试的是相邻任务：模型同样需要处理的问题，用户肯定会问的问题，但它们并未明确包含在微调目标中。一个填表企业模型仍然需要总结文档。一个客户支持模型仍然需要通过多步推理解决问题。一个针对 Python 微调的代码生成模型仍然需要用平实的英语处理架构问题。

思维链（Chain-of-thought）推理尤其脆弱。NAACL 2025 的研究发现，没有明确 CoT 训练数据的指令微调会主动损害推理能力——不仅是在新任务上，还包括那些定义现实世界用例的多步问题。这种效应在较小模型（1B–7B 参数）中更为显著，并且与微调分布偏离基础预训练分布的程度呈正相关。

对齐税（alignment tax）加剧了这一点。经过安全目标或 RLHF 微调的模型会经历一种单调的能力权衡：随着安全指标的提高，通用能力会下降。更麻烦的是，这种退化只能通过后续训练部分逆转。一旦通过延展的 SFT 导致遗忘超过某个阈值，失去的能力就无法通过 RL 完全恢复。

行为退化审计

解决方法始于运行任何微调步骤之前。行为退化审计（behavioral regression audit）是指在目标任务和模型必须继续处理的相邻任务上建立能力基准的实践。

该工作流程分为三个阶段。

第一阶段：能力映射。 在微调之前，列举模型在生产环境中处理的每个任务类别。不要局限于目标任务——包括用户向它抛出的所有内容。在所有类别中运行标准化基准测试，如 MMLU、MT-Bench 或领域特定评估，并记录得分。这就是你的基准。如果你没有基准，你就无法检测到退化。

第二阶段：退化阈值。 为每个类别定义可接受的退化阈值。一个合理的起点是 MMLU 下降不超过 2%，MT-Bench 下降不超过 1 分。对于关键推理任务，适用更严格的阈值。阈值定义了在看到任何微调结果之前，对你的系统而言“可接受的权衡”意味着什么。

第三阶段：微调后对比。 在每次微调运行后，运行相同的基准测试套件并与你的基准进行比较。任何降至阈值以下的类别都是阻碍部署的退化，而不是一个可以接受的已知权衡。分布内评估（自定义任务性能）和分布外评估（MMLU、推理基准）的结合，既能捕捉到欠拟合，也能捕捉到遗忘。

AWS 工程团队在进行强化微调时会运行一个三层评估流水线：用于捕获知识退化的标准基准测试、用于验证任务性能的自定义业务评估，以及用于针对已知优劣输出进行退化测试的自定义评判（judge）套件。其原则是：仅通过自定义评估而未通过 MMLU 是过拟合的信号，而不是成功。

任务范围定义

回归测试能捕捉到微调后的性能断崖。任务范围定义则从源头上防止了它的形成。

在编写训练数据收集简报之前，先写一份能力保留简报。需要思考的问题有：

• 哪些能力必须在这次微调运行中保留下来？需要达到什么样的质量水平？
• 在生产环境中，有多少比例的用户查询属于这些能力类别？
• 当这些能力下降 5% 时，用户的体验会如何？下降 15% 时又会如何？

这些答案将改变范围决策。如果你有 30% 的用户查询涉及多步推理，而你的微调目标与推理无关，那么你有两条路：在训练组合中加入推理示例（带 CoT 标注），或者接受模型在三分之一用户所依赖的任务上变差。

研究证实了数据混合路径是有效的。在指令微调期间，只需加入少至 9 个思维链（CoT）训练数据集，就足以在不同规模的模型中保持推理性能。代价是边际的数据收集成本；收益是保留了那些原本会隐形退化的能力。

还有一个更高层面的范围决策：是否真的需要微调。当你需要一致、高频的行为改变，且检索增强生成（RAG）无法处理时——例如特定词汇、领域格式、延迟敏感的推理——微调是正确的选择。当你的系统需要覆盖多种任务类型时，微调则是错误的选择，因为专业化与泛化之间的权衡将变得难以接受。基于 RAG 的系统以检索延迟为代价，保留了基座模型的能力。对于多领域应用，这种权衡通常更有优势。

缓解工具链

当微调是正确选择时，有几种技术手段可以缩小能力差距。

EWC-LoRA 结合了低秩自适应（LoRA）的参数效率和弹性权重整合（Elastic Weight Consolidation, EWC）正则化。EWC 在训练损失中增加了一个惩罚项，通过 Fisher 信息矩阵估计，防止模型在先前任务中重度使用的参数发生剧烈变化。结合 LoRA，在持续学习基准测试中，这比原生 LoRA 提升了 8.92%，同时无论经过多少次微调，存储和推理成本都保持不变。

锐度感知最小化 (SAM) 采取了不同的方法：它不直接正则化参数变化，而是将优化器偏向损失景观的平坦区域，在这些区域，微小的扰动不会破坏先前的知识。在达到相同目标性能的情况下，SAM 训练的 Checkpoint 比 AdamW 基准丢失的知识更少，实现了更好的学习与遗忘权衡曲线。开销大约是标准训练计算量的 2 倍，不过通过梯度范数选择层的稀疏层变体可以显著降低成本。

模型合并 (Model merging) 是侵入性最小的恢复技术。在微调前的 Checkpoint 和微调后的 Checkpoint 之间进行简单的权重平均，可以实现令人惊讶的能力保留权衡——在相邻任务上的表现通常优于仅微调的模型，同时保留了大部分特定任务的改进。Checkpoint 之间的球面线性插值（Spherical linear interpolation）可以找到在特定能力维度上优于任何单一模型的参数区域。

这些技术都无法消除权衡。它们只是缩小了权衡的范围。目标不是零遗忘，而是将遗忘控制在回归审计定义的接受阈值内。

生产流水线的样貌

在不产生隐性回归的情况下进行微调的完整工作流包含以下检查点：

微调前：

• 按子类别建立 MMLU 和 MT-Bench 的基准分数
• 映射你用户依赖的每一个相邻任务类别
• 为每个类别定义回归阈值
• 根据任务广度决定是否有必要使用 EWC-LoRA 或 SAM

微调中：

• 如果推理质量很重要，就在训练组合中包含 CoT 数据
• 记录每一层的梯度信号，以监控表征偏移（Representational drift）
• 在每个 Checkpoint 都运行评估套件，而不仅仅是在收敛时

验证时：

• 在所有类别中与微调前的基准进行对比
• 如果任何类别突破了阈值，则阻止部署
• 使用 LLM-as-judge 补充基准评估，以捕捉分数无法涵盖的定性信号

发布时：

• 使用带有 A/B 流量切分的阶段性部署
• 收集真实用户交互的遥测数据，以捕捉评估套件遗漏的缺口
• 保持至少 30 天的回滚路径，以便恢复到上一个模型版本

那些跳过基准测试步骤的团队——那些只衡量目标任务改进的团队——就是那些在生产环境中发现泛化断崖的团队。建立基准大约需要一天时间。而它所防止的生产事故则需要更长的时间来解决。

微调并不是旧模型和新模型之间的零和博弈。它是对成千上万个能力维度优先级的重新加权，而其中大多数维度并不在目标函数中。将回归审计视为必选项而非加选项，是确保这种重新加权保持在用户实际体验范围内的关键。