给大模型装一套"内核安全模块"，让可解释性研究真正管住输出

2003 年前后，Linux 内核有一个让开发者头疼的问题。

每次想给系统加一种新的访问控制策略，比如某个机构想用 SELinux，另一个想用 AppArmor，开发者就得把这套策略硬编码进内核最核心的代码路径里。策略一多，内核就成了一团乱麻。后来有人想通一件事：与其把每种策略都焊死在内核里，不如在内核的关键操作点上留一个"钩子"，让外部的安全模块来做判断，内核只负责在正确的位置调用这个钩子、并执行返回的结果。这就是 Linux Security Modules（LSM）的由来，SELinux 和 AppArmor 后来都是插在这个统一钩子上的模块，谁也没有改动内核本身。

二十年后，几乎一模一样的困境出现在了大语言模型的部署现场，只不过这次问题不是内核策略，而是怎么把模型内部的可解释性研究成果，变成真正能拦截危险输出的安全防线。

这篇论文的作者们，来自新加坡国立大学、中国科技大学等机构，观察到了这个似曾相识的乱象，于是提出了 LMSM（Language Model Security Modules），一套照搬 LSM 设计哲学的大模型安全框架。

一堆聪明的探测器，却各自为战

先说说问题到底出在哪。

这几年可解释性研究进展很快，稀疏自编码器能把模型内部密密麻麻的神经元激活拆解成人类能看懂的"特征"，探针（probe）能学会一条直线，把危险内容的激活模式和正常内容分开，电路断路器能在模型即将生成有害内容时直接掐断。这些技术单独拎出来看都挺厉害，论文里的图表也漂亮。

引用块：稀疏自编码器（SAE）：一种能把模型内部纠缠在一起的激活信号，拆解成若干个含义相对清晰的"特征"的神经网络工具，方便研究者理解模型到底在想什么。

但这里有个被普遍忽视的现实问题：一个能看懂模型内部状态的探测器，离一个能真正拦下危险回复的安全系统，中间还差着十万八千里。

想把探针的判断变成实际的拦截动作，工程师得给它配一整套东西，怎么校准阈值、什么时候触发、触发了要执行什么操作（是终止生成还是换成一句固定的拒绝回复）。这一整套东西通常是跟着这一个探测器专门写的。

后果是什么？后果是每换一个新的探测器或者新模型，前面搭好的这套触发逻辑和执行代码基本作废，得从头再写一遍。论文里管这个叫"另起一个守卫栈"，一个探测器一个守卫栈，三个探测器就是三套互不相通的判断和执行系统，未来想加第四个，还得再来一套。

这就好比一个小区雇了三个保安公司，分别负责门禁、监控、和巡逻，但三家公司互不通气，各用各的对讲机系统，各按各的流程记录异常。有一天想再加一家做人脸识别的保安公司，物业发现根本接不进现有系统，只能又单独给这第四家配一套独立的记录、报警、开门流程。如果不做统一接口，小区安保规模每扩大一次，管理复杂度就要跟着翻倍，而且四套系统之间互相不知道对方发现了什么。

LMSM 想做的，就是把这四家保安公司拉到同一套调度系统下面，谁来查、怎么判断、出了问题怎么处理，这三件事分开管理，谁都不用重复造轮子。

三层分离：观察、决策、执行各管一段

LMSM 的核心设计思路，其实就是把 LSM 那套"内核提供钩子，模块提供策略，内核执行结果"的分工，原封不动地搬到大模型的推理服务里。

具体拆成三层。

第一层叫后端（backend），它的工作只有一件事：从模型的内部计算过程里，读出一些经过校准的证据信号。这个后端可以是前面提到的 SAE、transcoder，也可以是运营方自己训练的一个简单的线性探针。

引用块：Transcoder：一种通过稀疏中间特征，去逼近模型某一层到另一层之间变换关系的分析工具，能揭示模型某个模块（比如 MLP 层）具体在做什么样的计算。

第二层叫策略（policy），它读取后端吐出来的证据，判断当前这条规则该不该触发。这一层是有版本号的，运营方可以随时更新激活哪些规则、按什么时间点检查，而不动前面的后端和后面的执行层。

第三层叫执行门（enforcement gate），也是整个系统里唯一有权真正改变服务状态的组件。它只接受策略层给出的最终决定：放行、终止，还是拒绝。执行门本身不含任何具体的判断逻辑，它不知道阈值是多少，也不关心是哪个规则触发的，它只负责按指令动手。

论文里给了一个特别具体的例子，很能说明这套分工的价值。假设一个远程医疗服务用的是一个已经对齐过的模型，但当地法规要求这个服务绝对不能给出针对具体病人的用药剂量建议，这是这家机构自己的合规要求，模型厂商不会替它管这个。

如果这家机构手头正好有一个公开发布的 SAE，里面恰好有和"用药建议"相关的特征方向，运营方就直接绑定这个现成的产品，校准一条规则。如果没有现成的，运营方就自己用领域内的样本训练一个专属的探针。规则一旦校准完，就被放进一个带版本号的规则库里，再被激活进当前生效的策略包。生成过程中，后端吐出证据，策略判断该规则是否命中，执行门负责把已经缓冲好的、还没发给用户的回复换成配置好的拒绝语。

以后如果出现了更好的检测方法，运营方只需要更新后端绑定和规则条件，整个决策接口、请求处理流程、执行路径完全不用动。

这套三层分离带来的最大好处，是把"这套机制到底管不管用"（论文里叫 mediation correctness，调解正确性）和"装的这条规则到底准不准"（policy effectiveness，策略有效性）彻底剥离开了。一个系统架构本身可以是完全正确的，哪怕装进去的规则质量很差、校准得不好。这两件事分开谈，出了问题才好定位到底是哪一层出的错。

如果只用一个统一后端呈现证据，行不行？

这里有个细节值得多说一句。LMSM 对后端的证据形式几乎不做任何假设，规定的只是一个统一的数据接口，每个活跃请求在每一步都对应若干个标量证据通道。不管这个通道背后是稀疏特征、探针边距还是别的什么信号，策略层看到的都是一样的数字向量，完全不掺杂具体是哪种技术产生的这些数字。

引用块：证据通道（evidence channel）：在每次评估时，为每一个正在处理的请求暴露出来的一个具名标量信号，可以是某个 SAE 特征值、transcoder 坐标值，也可以是探针给出的判别边距。

这个设计像极了插座标准。家里的电器不管是电视还是冰箱，接的都是同一种规格的插座，插座本身不管你插的是什么，只提供电。如果没有这个统一标准，每种电器都要配一种专属插座，家里就得装几十种不同形状的插座孔，换一个新电器就得重新开一次墙。LMSM 的证据接口就是这个插座，不管后端是 SAE 还是探针，接口形状永远一样，换后端不用"重新装修"整个推理服务。

正因为这个抽象层的存在，论文才能做到"绑定一个 SAE 和绑定一个探针，走的是同一套代码"，这在实验部分被专门验证过。

请求在乱序调度里也不能"认错人"

真正让这套系统难做的，其实不是单个请求怎么处理，而是现在的大模型服务几乎都用连续批处理（continuous batching）在同时处理几十上百个请求，请求会不断完成、退出，新请求会不断补进空出来的位置。

引用块：连续批处理（continuous batching）：一种让 GPU 同时处理多个不同长度、不同进度请求的调度方式，通过动态地往批次里填充新请求、移出已完成请求，来最大化硬件利用率，vLLM 是实现这套机制的代表性推理引擎之一。

这就带来一个隐患：如果安全策略的状态是按"这个请求现在坐在批次里第几行"这种临时位置来记录的，那一旦调度器把请求挪了个位置，状态很可能会张冠李戴，把 A 请求的证据错记到刚补位进来的 B 请求头上。

LMSM 的解决办法，是坚持用宿主服务分配的、在请求存活期间绝不重复使用的唯一身份编号，来给每个请求的策略状态"上户口"，而不是用它临时所在的那一行位置。请求挪到哪一行，状态就跟到哪一行；请求结束了，状态立刻清空；新请求补进这个空位，得到的是全新的、干净的状态。

这就像医院里给病人建的病历本子，靠的是身份证号，不是靠"3 号病床"。如果病历是按床位号记录的，那病人换了床位，或者原来那个病人出院了新病人躺进同一张床，病历系统很可能就把新病人的检查结果和旧病人的病史搞混。用身份证号做主键，不管病人挪到几号床，病历永远认得是同一个人。

论文的实验专门验证了这一点：让 32 对完全相同的请求在系统里反复经历调度器挪位、退出、补位，结果全部 32 对请求都完整保留了它们各自的最终动作、命中的规则类别、触发的时间点，以及每一条规则是否被触发的完整记录。这说明这套按身份而非位置记录状态的设计，在剧烈的调度变动下依然站得住。

多条规则一起触发时，谁说了算

一个真实部署里，运营方往往不止装一条规则，可能同时激活了十几条不同的检测规则，负责不同的风险类别。这时候如果好几条规则同时命中同一个请求，该按谁的处理方式来？

LMSM 给出的答案很朴素，叫固定 OR 组合加上运营方预先声明好的优先顺序。只要有任意一条激活的规则命中了，这个请求就被判定为需要干预，如果同时命中了好几条，就按照运营方事先排好的顺序，取排在最前面的那条规则对应的处理方式。这个顺序是配置时就定好的，不是运行时临时决定的，所以出了问题以后能明确追溯到是哪条规则、在第几步、用了什么阈值触发的干预。

引用块：intervention record（干预记录）：每当执行门真正采取了一次干预动作，系统会同步生成的一条记录，包含请求编号、命中的规则和目标类别、具体分数和阈值、发生的解码步骤、当时生效的策略和规则库版本，以及干预前后的文本片段。

这套记录机制解决的其实是审计的问题。安全系统最怕的不是拦错了一次，而是拦错了却说不清为什么拦错。有了这份带版本号的干预记录，运营方事后可以精确复盘每一次拦截的来龙去脉，这对于一个要接受监管审查的系统来说，几乎是刚需。

两种节奏：早查快判还是全程盯梢

论文里实现并对比了两种时间调度策略，分别叫 Checkpoint 和 Anytime，这两个名字很直白地说明了它们的区别。

Checkpoint 走的是"定点体检"的思路，它把生成过程中固定几个时间段的证据汇总起来，只在生成到第 64 个 token 的时候统一做一次判断。这个判断点是配置阶段就定死的，不是跑测试时挑出来的最优值。

Anytime 走的是"全程心电监护"的思路，它维护一个不断更新的前缀表示，在解码的每一步都重新评估一次，一旦某条规则的分数越过阈值就立刻出手，实测中它触发干预的中位步数只有第 15 步，比 Checkpoint 早了将近 50 步。

这就像体检和心电监护仪的区别。体检是约定好某一天做一次全面检查，成本低、可预测，但万一体检间隔期间出了急性问题，可能要等到下次体检才被发现。心电监护仪是实时盯着，任何一次异常心跳都能立刻捕捉到，但代价是设备要一直耗电、一直占用医护人员的注意力。如果一个医院只能选一种，选体检的医院会漏掉突发情况，选心电监护的医院会把大量资源耗在日常巡检上。LMSM 的价值就在于，它让同一套后端和执行框架，既能配出体检模式，也能配出监护模式，看运营方更在意哪一头。

实验数据也印证了这个权衡。Checkpoint 在批处理宽度 32 的情况下，只比完全不做任何监控的空跑基线多花 1.86% 的吞吐量成本，而 Anytime 因为要在每一步都做一次证据汇总甚至挪到 CPU 上跑判断，多花了 16.09%。反过来，在避免有害内容外泄这件事上，Anytime 平均能让每次拦截多挡住 48 个本来会被生成出来的模型 token，说明它出手更早、拦得更彻底一些。

拿具体的实验数字来说话

论文选择在 Qwen3-4B 这个模型上做主要评测，用了三个业界常见的测试集：HarmBench（衡量有害内容能不能被生成出来）、WildJailbreak（另一套越狱攻击测试）、XSTest（衡量模型会不会对完全无害的请求也过度拒绝）。

先看攻击成功率（ASR，就是有害请求最终真的拿到了有害回复的比例）。在完全不启用任何拦截动作的对照组下，HarmBench 上的攻击成功率是 39.20%，也就是说每 100 个精心构造的攻击请求里，有将近 40 个能骗过模型本身的安全对齐拿到危险回复。这个数字本身就说明了单靠模型训练阶段的对齐，防线并不牢固。

装上 LMSM-Checkpoint 之后，这个数字掉到了 3.32%，相当于把攻击成功率砍掉了九成还多。WildJailbreak 上也是类似的情况，从 41.90% 降到 7.35%。LMSM-Anytime 在 WildJailbreak 上表现更好，降到 6.00%，因为它出手更早。

但天下没有免费的午餐，防御做狠了，误伤也会上升。XSTest 上原本的误拒率是 2.40%，Checkpoint 上线后升到 4.40%，Anytime 升到 5.60%。论文也很坦诚地把这个代价摆出来，没有藏着掖着。

论文还找了几个同期发表的、走训练阶段安全对齐路线的方法做对照，比如 SafeKey、ThinkSafe、STAR-1 这些。这几个方法有的在误拒率上做得比 LMSM 更低（SafeKey 只有 0.80%），但它们几乎全部需要重新训练或者微调模型权重。LMSM 最大的差异化优势在于完全不动模型参数，靠的是外挂一层运行时策略，这意味着换模型、换供应商、甚至同一个模型服务不同客户不同合规要求，都不用重新走一遍训练流程。

后端能换吗，换了会不会伤筋动骨

论文做了两组跨后端的实验，专门验证前面提到的"接口统一"到底管不管用。

第一组是彻底换模型、换证据来源：一组用 Gemma-3 模型配合 SAE 后端，另一组用 Qwen3 配合 transcoder 后端。两套完全不同的组合，最后都复用了同一套请求状态管理、决策接口、动作词表和执行逻辑，只是绑定的模型和证据机制不一样。结果两边都把 HarmBench 上的攻击成功率从 46% 上下压到了个位数附近。

第二组是在同一个 vLLM 服务里，只换掉后端绑定这一层，把探针换成 transcoder，其余一律不动。这组实验是"仅监控不动作"的，结果两种后端每一步都能给所有 32 个请求返回有效的证据，吞吐量也差不多。这组实验想说明的不是哪种信号更准确，而是接口层面的复用是不是真的成立，答案是成立的。

代价和边界：这套系统解决不了什么

论文对自己的边界说得也很清楚。LMSM 本身不替运营方判断哪些内容该被禁止，那是运营方自己的责任，这套框架只负责把运营方定好的规则，可靠地贯彻到输出之前。如果运营方定的规则本身有问题，比如定义过宽、带有偏见，LMSM 会原封不动地把这个有问题的规则执行到位，架构本身没有能力去纠正一个糟糕的策略。

另外，这套系统假设的是运营方对自己部署环境有完全控制权，模型本身、推理引擎、后端产物、规则库、执行代码都被信任。如果攻击者能够攻陷这个服务进程本身，那就不在这套威胁模型的保护范围之内了。论文也承认，即便证据机制本身没问题，攻击者依然可以通过混淆手段绕过基于激活空间的监控，这是已经在别的研究里被证实过的风险。

目前的实现还只支持一个策略绑定一个后端，动作也只有放行、终止、拒绝这三种，还没有支持组合多个后端的证据，也没有支持诸如内容打码、二次审核转人工这类更精细的动作，不过论文认为这些扩展可以复用现有的请求状态和执行路径，不需要另起炉灱。

写在后面

读完这篇论文，最触动我的其实不是具体的数字，而是这套"调解正确性"和"策略有效性"必须分开谈的观点。很多安全系统的争论最后都吵成了一锅粥，因为大家把"这套系统架构对不对"和"这条具体规则准不准"混在一起讨论，一旦某次拦截出了岔子，没人说得清是哪一层的问题。LMSM 把这两件事从设计上就切开了，这个思路本身比具体拦下多少个攻击更值得记住。

另外一个让我意外的细节是，Checkpoint 和 Anytime 用的探针不是同一套训练出来的参数，是分别针对各自的时间语义单独拟合的。也就是说，同样是"在第 15 类目标上判断是否违规"，早查和全程盯梢用的判别边界是不一样的。这说明时间调度不只是"什么时候查"这么简单的开关，它其实倒逼着底层的证据表示也得跟着重新校准，这一点在论文正文里一句话带过，但细想一下工程量不小。

这套框架目前还只验证到十五条规则同时激活的规模，如果未来一个真实部署要装上几百条覆盖各行各业合规要求的规则，固定 OR 加优先级排序这套简单机制还够不够用，是个值得继续追问的问题。

一个内核用了二十年才把安全模块的钩子设计打磨顺手，大模型的安全机制会不会也要走这么长的路，现在还不好说。

Q&A

Q1：LMSM是什么？

A：LMSM是一套借鉴Linux Security Modules设计思路的大模型安全框架，把模型内部证据的获取、安全规则的判断、最终的拦截执行这三件事拆分成独立的模块，让可解释性研究成果能可靠地转化为运行时的安全拦截，而不用每换一个探测器就重写一整套安全代码。

Q2：LMSM会不会让模型变得反应特别慢？

A：不会明显拖慢。论文实验显示，在批处理宽度32时，LMSM-Checkpoint策略只比完全不监控的基线多花不到2%的吞吐量成本，即便同时激活15条规则也能保留96.89%的吞吐量，Anytime因为要每步都检查开销稍高，约多花16%。

Q3：LMSM能完全防住所有越狱攻击吗？

A：不能完全防住，但效果显著。在Qwen3-4B上，LMSM-Checkpoint把HarmBench攻击成功率从39.20%降到3.32%，同时误拒率仅从2.40%升到4.40%，但论文也承认攻击者仍可能通过混淆手段绕过基于激活的监控。