安全 token 正则化：让微调后的大模型保持对齐

这是什么？

2026 年 4 月在 arXiv 上发表的论文《Guardrails in Logit Space: Safety Token Regularization for LLM Alignment》，针对一个自 2023 年起就有充分记录、却少有干净解法的问题：将一个对齐良好的模型在新领域上微调，往往会削弱其安全行为——即便微调数据完全是良性的。某团队部署了一个会拒绝有害请求的模型，用 LoRA 将其适配到例如保险理赔或医疗分诊场景，随后发现适配后的模型开始满足那些基座模型本会拒绝的请求。这里并没有攻击者；安全性的退化只是常规训练的副作用。

作者提出了安全 token 正则化（STR，safety token regularization），这是一种轻量的防御性技术，旨在让拒答行为在微调过程中得以保留。它在设计上就是防御性的：目标是让团队能够把开放权重模型适配到自身领域，而不会悄悄丢失一开始就具备的护栏。该发现与 2026 年初的其他工作相互印证——例如《Few Tokens, Big Leverage》（2026 年 3 月）——它们从不同角度指向同一个洞见。

工作原理

核心观察是：模型的拒答行为集中于少数几个「安全 token」——那些开启并支撑拒绝模板的词（如「I」「cannot」「unable」「sorry」等一次拒绝的起始 token）。在微调过程中，良性任务数据上的梯度更新会使模型的输出分布发生漂移，这些安全 token 的 logit 会被悄然拉偏，于是模型在原本会拒绝的场景中，变得更不容易开启一次拒绝。

STR 在 logit 空间中发挥作用，而不是引入第二个模型或一套偏好优化循环。它首先从对齐良好的基座模型的拒绝模板中识别出显著 token；随后在微调期间，约束这些 token 对应的 logit，使其不被任务梯度从对齐值上拉走。以持续学习正则化的视角来看，该方法把预训练模型在 token 层面的安全信息视为值得显式保留的知识，而非事后再去重新学习。由于它只是对少数 token 施加的一个正则化项，额外计算开销极小，可直接嵌入 LoRA 等参数高效方法，且无需改动数据流水线。

为何重要

良性微调如今是各组织部署开放权重模型的默认方式，这意味着该失效模式既普遍又大多不可见。团队在微调后测量任务精度；极少有人重跑一次安全评测，于是这种退化未经测量便进入了生产环境。攻击面并非某个巧妙的提示词，而是训练流程本身悄悄抹去了基座模型所宣称的安全余量。

logit 空间正则化器的实际价值在于：它足够便宜，可以默认采用。更重的修复手段——重跑一次 RLHF、把安全数据重新混入、或做一整轮偏好优化——代价高昂，因而常被省略。一种只增加一个小正则化项、且据作者称能保住任务效用的方法，削弱了「在适配时不去保护对齐」的借口。作者还指出一个附带收益：约束这些 token 提升了训练稳定性，这表明安全目标与质量目标之间的对立，或许没有惯常「对齐税」说法所暗示的那么严重。

防御措施

微调后务必重跑一次安全评测。 把微调后的安全基准当作必经关卡，而非可选检查。若只测量任务精度，你将看不到这种退化。

在训练中保护安全，而非事后补救。 安全 token 正则化之类的技术会在微调目标内部就保住拒答行为，这比在对齐已经漂移之后再试图把它硬接回去更便宜、也更可靠。

优先选择与 PEFT 兼容的轻量缓解手段。 一个计算开销可忽略、且兼容 LoRA 的正则化器，远比需要单独奖励模型或完整重对齐的防御更可能被持续采用。

保留基座模型拒答行为的参照。 无论采用哪种方法，你都需要对齐模型的拒答行为作为正则化的目标或用于对比的基线——在开始适配之前先把它记录下来。

关注整个分布，而非仅仅被拦截的字符串。 这里的退化是 token 概率的柔性偏移，而非彻底的越狱，因此输出字符串过滤器无法捕捉。请在整个微调过程中，用一个留出的安全集评估拒答率。

状态

项目	参考	说明
核心论文	arXiv:2604.17210	《Guardrails in Logit Space》，2026 年 4 月——提出安全 token 正则化（STR）
问题	同一论文	良性微调会削弱对齐良好的大模型的安全对齐
方法	同一论文	在训练中约束拒绝模板显著 token 的 logit
成本	同一论文	轻量；可与 LoRA / PEFT 集成，额外计算极小
结果	同一论文	安全性与更重的方法相当，同时保住任务效用与训练稳定性
相关工作	arXiv:2603.07445	《Few Tokens, Big Leverage》（2026 年 3 月）——在微调中约束安全 token

一个持久的要点是习惯而非单一工具：安全对齐并不是某个检查点的永久属性。它会在常规微调下被侵蚀，因此必须在适配过程中主动加以保留、并在之后重新验证——而其代价要足够低，好让任何团队都没有理由跳过。