擦除模型原生对齐的微调过程

你选择了基础模型，“因为它是更安全的那一个”。六个月后，你的团队发布了一个经过领域微调的检查点，它能以极具说服力的流畅度回答客户关于财富产品的问题，任务评估通过率达到 94%，而且——在第一轮训练到第四轮训练之间的某个时刻——它悄然忘记了如何拒绝任何要求。没人注意到这一点，因为你的发布评估套件从未衡量过微调消除了什么。它被剥离的能力从未出现在你的任务分布中，因此也从未出现在仪表盘上。

这是目前生产环境中 LLM 系统最少被报道的故障模式：训练后的对齐并不是模型家族的固有属性。它是某个特定检查点的属性，而有监督微调（SFT）默认会腐蚀这种属性。进行微调的团队发布的并不是他们评审过的模型的微调版本。他们发布的是一个不同的模型——其模型卡描述的是根本没有在提供服务的权重。

对齐是一个检查点，而非一个品牌

当采购团队写下“我们选择 Provider X 是因为模型卡记录了防越狱能力和宪法训练过程”时，他们是在对托管在供应商评估服务器上的基础检查点做出声明。当你的机器学习团队在内部数据上运行 SFT 的那一刻，这个声明就转移到了一个除了你公司内部以外没人评估过的检查点上。模型卡描述的是基础权重。端点提供的是微调后的权重。合规态势参考的是文档，而不是实际交付的产物。

相关文献在过去两年里一直在敲响这一警钟。对齐模型中的拒绝行为是由一个极其狭窄的电路介导的——在某些开源权重模型中，只是残差流中的一个方向。这种脆弱性具有两面性。对于想要廉价研究拒绝行为的安全研究员来说，这是个好消息；但对于任何假设安全训练是权重的鲁棒属性而非其表层的薄层的团队来说，这则是糟糕的消息。

独立攻击已经证明了其实际影响。NOICE——一种成本约为 85 美元 API 额度的微调攻击——其攻击成功率比以往针对 ChatGPT-4o 的微调攻击高出七倍，据报道对 GPT-4o 的成功率为 57%，对 Claude Haiku 为 72%。BadGPT-4o 报告称，仅通过 10 个训练样本，对 gpt-3.5-turbo 的有害率就达到了 87%。这些不是国家级的攻击。这些只是预算清单上的普通支出项。

关键在于，即使是“良性”的微调也会产生同样的结果。一项被广泛引用的研究发现——10 个良性的问答对就足以让原本对齐的模型将有害问题与拒绝回答解耦——这是从业者需要内化的结论，因为它打破了“我们永远不会用有害数据进行微调，所以我们很安全”这种自我安慰的说法。在一个完全干净的内部文档语料库上进行微调的团队，可以在从不接触任何危险内容的情况下，发布一个未对齐的检查点。

为什么你的评估套件漏掉了它

标准微调工作流程有一个默认的衡量方案，其设计几乎就是为了掩盖对齐退化。团队根据与训练数据相同的分布构建评估集——客户查询、领域文档、特定任务场景。任务准确率上升了。评估集是由关注任务性能的人构建的，而不是由关注拒绝行为的人构建的。拒绝相关的输入在任何现实的任务分布中都只占极小一部分，因此评估集在构建时就对它们的采样不足。

2025 年发布的一项研究发现，微调不仅降低了安全性，还破坏了后续安全评估的一致性：相同的提示词在微调模型的不同评估运行中会产生不同的结果，而基础模型则会产生稳定的判定。这是最糟糕的一种退化——它对团队的主要指标是不可见的，同时还破坏了安全团队本应用来捕获它的次要指标。

复盘中反复出现的三种故障模式：

• 微调仅根据任务准确率评分。 防越狱能力、提示词注入防御和政策遵循情况都没有被衡量。直到第一份红队报告出炉时，团队才意识到模型可以被说服做任何事——而这通常发生在发布之后，因为红队测试通常受限于“模型已完成”这一前提。
• 运行了通用安全基准测试且通过了。 基础模型的安全属性是针对广泛分布进行衡量的；而部署的模型则是在狭窄分布上运行。民主与技术中心（CDT）对基础模型微调的评论专门指出了这一点：领域微调模型在多轮、特定任务的交互中会出现安全漂移，而单轮基准测试无法检测到这些。
• 模型卡描述的是基础权重。 当审计人员或客户要求提供安全文档时，团队会转发供应商的模型卡。模型卡描述的是部署检查点已不再具备的能力。团队中没人意识到那张卡片是关于另一个不同产物的文档。

另一个模式加剧了这些问题：许多微调语料库是为了优化任务示例而构建的。它们包含很少甚至没有模型拒绝其本该拒绝的事情的示例。梯度更新忠实地履行了它的职责——它侵蚀了数据中未体现的行为。最近的研究认为，即使领域语料库中存在少量的“低质量”数据，也足以让微调后的模型在不相关的提示词上表现出明显的失调，研究人员称之为“涌现式失调（emergent misalignment）”。

弥合差距的严谨实践

那些负责任地交付产品的团队，不再将对齐（alignment）视为基础模型“自带”的属性，而是将其视为一种必须以与任务性能（task performance）相同的频率进行衡量、保护和重新衡量的属性。在各种生产环境的实践指南中，有四种值得借鉴的做法：

一个在结构上与任务评估（task eval）分离的部署前对齐评估。 这不是同一个评估 notebook 里的一个标签页。它是一个独立的套件，由不同的角色负责，设定了不同的阈值门禁，并针对微调后的检查点（checkpoint）运行——绝不是针对基础模型。微软的 Azure OpenAI 服务现在提供内置的安全评估，在部署前针对微调模型运行，这种形式是正确的：部署被对即将提供服务的实际工件（artifact）的检查所阻断。没有这类工具的团队需要自己构建等效的门禁。

显式保留拒绝轮次（refusal turns）的微调数据审计。 这是团队投入不足的部分，因为这感觉像是在无中生有。你需要针对安全相关的类别对训练语料库进行采样。如果你的微调数据中拒绝示例为零，你就是在训练模型永远不要拒绝。注入规范的拒绝配对——其比例根据你所在领域的风险状况进行校准——以便梯度更新有东西可以强化，而不仅仅是侵蚀。2025 年围绕“不被遗忘的安全（unforgotten safety）”收敛的持续学习文献明确指出，解决办法在于数据混合，而不是某种巧妙的训练后补丁。

对齐评估可以消耗的回归预算（regression budget）。 当任务准确率提高但对齐评估出现退步（regress）时，会发生什么？在大多数团队中，答案是不言而喻的：任务的提升出现在发布幻灯片中，而退步则记录在没人阅读的文档里。将其显性化。对齐评估的任何下降都应阻断发布，即使任务指标有所改善。无法清晰说明权衡的团队实际上并没有做出决定——他们只是将其推迟到了那个最先到达发布评审的指标上。

基础模型与微调模型之间的“我们遗忘了什么”差异对比（diff）。 将两个检查点都通过一组固定的探测集，这些探测集旨在测试团队并未直接优化的能力：各政策类别的拒绝、提示词注入（prompt-injection）防御、对对抗性输入的指令遵循、对分布外（out-of-distribution）请求的行为。成对对比回复。基础模型能做到而微调模型不能做到的任何事情，都是你丢失的能力。你可能会认为这种损失是可以接受的，也可能不这么认为。但你不能有意识地接受一个你从未见过的损失。

技术失败背后的组织失败

技术失败是真实的且有据可查的。而组织失败才是导致技术失败最终上线的元凶。

在我见过的每一个遇到此问题的团队中，权责边界的划分方式都导致没有任何一个角色对所服务的检查点的安全态势负责。ML 团队负责微调，安全团队负责政策，平台团队负责端点，合规团队负责文档，面向客户的团队负责发布幻灯片。

微调后的检查点是跨越所有这些边界并交付给客户的工件。但这些团队中没有一个拥有它。ML 团队会告诉你任务准确率提高了；安全团队会告诉你政策没变；平台团队会告诉你端点运行良好；合规团队会给你一张模型卡（model card）；面向客户的团队会告诉你发布幻灯片已获批准。与此同时，检查点刚刚学会了回答向它提出的任何问题。

这是存在于角色之间而非角色内部的典型失败形式。解决办法不是“让 ML 团队关心安全”。ML 团队已经很关心了；他们之所以不衡量安全，是因为衡量安全不是他们的工作。解决办法是为所服务的检查点设立单一负责人，对检查点的 所有 属性——任务性能、安全性、延迟、成本——负责，并能在其中任何一项指标退步时阻止部署。有些团队将此角色称为 模型所有者（model owner），有些称之为 检查点管家（checkpoint steward）。名称并不重要，重要的是该角色的存在及其随之而来的权威。

架构层面的启示

对齐（alignment）不是你的模型系列（model family）所做的事情。它是你的特定检查点在面对客户发送的特定输入、在你的应用程序生成的特定对话结构中所表现出的行为。进行了微调的团队交付的是一个与其评审过的模型不同的模型。除非团队能够证明所服务的检查点通过了与基础模型相同的对齐门槛——且是在所服务的检查点上衡量的，而不是在基础模型上——否则它就不能声称拥有其初始模型系列的安全属性。

微调不仅仅是增加知识或使行为专业化的手段。它是一种对权重属性的破坏性操作，厂商投入了巨大的算力才植入这些属性，而你的团队几乎不需要消耗算力就能将其移除。请妥善对待。衡量你擦除了什么，重新安装你需要的，并保持对你交付的工件（而非你购买的工件）进行评估的严谨性。