Anthropic 想给危险知识装上可拔掉的模块
第一性原理 佛学觉照

Anthropic 想给危险知识装上可拔掉的模块

| 阅读 9 分钟

AI 公司一直有一个很难说清的问题：有些知识本身是双重用途的。

同一类能力，可以帮助研究人员做防御、审计和科学探索，也可能被错误的人拿去制造伤害。过去的主流做法，是让模型在遇到危险请求时拒绝回答，或者用分类器把请求拦下来。

这当然有用。

但它没有改变一个底层事实：模型仍然知道那些东西。拒答和分类器像门禁，门禁可以升级，也可能被绕过；真正的知识仍在模型权重里。

Anthropic 和 AE Studio 的新研究 An off switch for dual-use knowledge in AI models，想把问题往更底层推一步。

它提出的不是一个更会拒绝的模型，而是一种训练结构：把某些双重用途能力尽量隔离到可移除的模块里。

这套方法叫 GRAM，Gradient-Routed Auxiliary Modules。

不是回答时拦截，而是部署时配置

要理解 GRAM 的意义，先要区分三种控制方式。

第一种是行为层控制。模型保留全部知识，但在回答时通过拒答、策略和分类器决定能不能说。这是今天很多系统的默认形态。

第二种是数据过滤。训练某个模型时，直接不喂某些敏感数据。这样更接近“模型本来就不会”，但问题是成本很高：如果不同用户需要不同能力组合，就可能要训练多套模型。

第三种就是 GRAM 试图做的事：一次训练，让模型的某些能力长在可配置的辅助模块里。

在 Alignment Science Blog 的技术说明 中，研究者把小型辅助模块加入 Transformer 的 MLP 层。训练时，如果数据来自某个特殊领域，相关模块参与学习；如果部署时不想提供这个能力，就删除或关闭对应模块。

这样一来，问题从“这次请求该不该回答”变成了“这个部署里是否应该存在这项能力”。

这是一种很不同的安全思路。

它不再把安全完全压在对话边界上，而是把一部分治理边界写进训练结构。

为什么这比拒答更值得看

拒答的问题不是没有价值，而是它太靠后。

当一个模型已经学会某类能力，后续再靠策略把它压住，就需要持续处理绕过、上下文误判、过度拒绝和模型更新后的再校准。

GRAM 的目标，是让能力本身变成可配置对象。

论文 Modular Pretraining Enables Access Control 把这个目标描述为 access control：不是给所有人同一个全能力模型，再靠行为层判断谁能问什么；而是在不同可信度的部署里，提供不同的能力 profile。

例如，一个高可信的安全或科研部署可能需要保留某些专业能力；普通部署则可以移除这些模块，同时尽量保留通用能力。

这不是“把模型变笨”。

理想状态下，它是把能力拆得更细：通用能力继续保留，敏感能力按部署需要开关。

研究里最有意思的一点，是这种模块化不只在玩具例子里测试。论文和技术博客都提到，实验从儿童故事的 synthetic dataset，推进到包含通用文本、代码、科学论文和四类双重用途数据的 800M 参数模型，再扩展到 50M 到 5B 参数的 scaling runs。

研究者报告说，移除 GRAM 模块后，效果接近从一开始就过滤相关数据训练出的模型；相比一些事后 unlearning 方法，也更能抵抗后续微调把能力重新拉回来。

如果这个方向继续成立，它的价值会很直接：同一训练成本下，模型可以支持多个能力配置，而不是为每一种风险档位训练一套模型。

但它还不是生产答案

这项研究最容易被误读成“Anthropic 给危险知识装上了开关”。

这不准确。

官方技术说明已经写得很清楚：这是 preliminary research，还没有应用到 Anthropic 的生产模型。

更大的问题也没有消失。

第一，能力本身可能是纠缠的。很多知识不是干净地分成“危险”和“安全”两格。基础科学、网络防御、漏洞研究和工程实践之间有大量重叠。你想移除某个危险能力时，可能也会伤到合法能力。

第二，数据标签并不总是可靠。GRAM 需要知道哪些数据应该路由到哪个模块。真实训练数据里，标签会缺失、模糊、错误，甚至随着语境变化。

第三，评估仍然有限。论文用 loss-based evals 和 adversarial elicitation 来测试能力移除与恢复风险，但这不能等同于真实部署中的完整安全证明。

第四，生产复杂度会很高。一个生产模型不只是预训练权重，还包括 instruction tuning、偏好训练、系统策略、工具调用、访问权限、监控和审计。模块关闭如何穿过这一整条链，还需要验证。

所以 GRAM 现在更像一个方向信号，而不是可以直接上线的安全产品。

它说明研究者正在尝试把 AI 安全从“输出时管住嘴”推进到“训练时管住能力结构”。

这一步很重要，但离制度化部署还很远。

真正的问题是模块归谁管

如果 GRAM 未来变得可用，治理问题会从技术细节里冒出来。

谁定义哪些能力应该成为可移除模块？

谁决定某个用户、机构或场景可以获得模块打开的版本？

谁审计模块真的被关闭了，而不是只在界面上显示关闭？

当商业客户想要更强能力、公共安全要求更保守时，谁有最终决定权？

这才是“off switch”真正难的地方。

一个红色按钮不是治理。一个可删除模块也不是治理。

治理需要的是可验证的能力配置、可信部署认证、外部审计、异常回滚，以及在风险超过阈值时真正能让能力下线的停止权。

如果这些制度没有跟上，模块化只会变成公司内部更复杂的部署选项。

如果这些制度能跟上，它可能让 AI 安全进入一个更具体的阶段：不是笼统地说某个模型安全或危险，而是说某个部署包含哪些能力、缺少哪些能力、由谁授权、如何证明。

这项研究真正改变的提问方式

GRAM 最有价值的地方，不是它让我们相信危险知识已经可以被干净拔掉。

恰恰相反，它让问题变得更具体了。

过去我们问：模型会不会拒绝危险请求？

现在可以追问：这项能力为什么必须存在于这个部署里？

过去我们问：某个用户能不能访问强模型？

现在可以追问：他需要的是哪些能力模块，哪些不该打开？

过去我们问：模型是不是安全？

现在可以追问：它的能力边界是否可配置、可验证、可撤回？

这就是 GRAM 值得关注的原因。

它把 AI 安全的一部分问题，从语言策略推向模型结构，从单次回答推向部署配置，从“相信公司会拦住坏请求”推向“证明某个能力在这里不存在”。

但最后的结论仍然要克制。

这不是危险知识的万能开关。

它更像一个新的工程方向：让模型不再只有一个整体的“知道”，而是开始拥有可以被拆分、授权和关闭的能力边界。

真正的安全不在按钮上。

在于谁能定义边界，谁能验证边界，谁能在必要时把边界收紧。

参考来源

💬 评论