为什么 AI 安全应从结构上强制，而不是通过训练

Source: Dev.to

大多数当前的 AI 安全工作假设系统本身不安全，并试图通过训练让它表现得更好。

• 我们添加更多数据。
• 我们添加更多约束。
• 我们添加更多微调、过滤器、奖励塑形和防护措施。

这种做法把安全视为一种可以学习的东西，而不是一种必须强制执行的东西。我认为这是一种根本性的错误。

核心问题

学习系统本质上是自适应的。如果安全仅仅是一种学习到的行为：

• 它可以被覆盖，
• 它可以被遗忘，
• 它可以被针对性优化，
• 它可以悄然失效。

这并非假设。我们已经看到：

• 奖励黑客，
• 目标漂移，
• 脆弱的对齐，
• 系统在条件改变前看似对齐。

换句话说，我们在要求学习系统可靠地保持本应是不变的属性。

来自软件系统的类比

在软件工程中，我们不“训练”内存安全到程序中。我们通过以下方式强制实现它：

• 通过类型系统，
• 通过内存模型，
• 通过访问控制，
• 通过架构边界。

你不可能意外地写入受保护的内存区域之外，因为系统结构不允许这样做。AI 安全也应得到同样的对待。

结构安全 vs. 行为安全

行为安全 表示：“系统之所以安全，是因为它已经学习到了。”
结构安全 表示：“系统不能不安全地行为，因为其架构不允许这样做。”

它们是截然不同的保证。

• 行为安全是概率性的。
• 结构安全是可强制执行的。

什么是 AI 系统的“结构安全”

可审计的内部状态

如果系统的内部推理无法检查，安全评估只能是猜测。审计性应作为一级设计要求：

• 持久的内部状态，
• 可追踪的决策路径，
• 对置信度和不确定性的显式表示。

没有检查，就不可能进行有意义的治理。

有界的自我修订

自我修改系统是长期学习的必然，但无限制的自我修改等同于失控。结构安全意味着定义：

• 系统哪些部分可以改变，
• 何时可以改变，
• 在什么条件下允许改变。

这更像是治理而非训练。

明确的自主性包络

不要使用二元的“自主 vs 非自主”开关，自主性应是渐进且有条件的。自主性包络：

• 当系统展示可靠性时扩大，
• 当不确定性或错误增加时收缩，
• 当信任崩溃时可以完全冻结行为。

这是一套控制系统，而非学习得到的道德。

能否决行动的治理层

安全机制应能够阻止行动，而不仅仅是给出建议。一个能够解释为何某行动不安全但仍执行的系统没有真正的安全边界。治理必须位于行动执行的上游，而非评估的下游。

为什么仅靠训练不足

训练是优化。优化压力最终会找到捷径。如果安全约束仅存在于奖励函数或数据分布中，它们就会成为系统学习去应对的对象，而不一定被保留。因此：

• 在分布转移下对齐会退化，
• 系统在评估中表现良好，却在实际环境中失败，
• 可解释性往往是事后回顾，而非事前预防。

不同的研究方向

与其问“我们如何训练系统以确保安全？”不如问“我们如何设计系统，使其在构造上就不能违反安全约束？”这将 AI 安全的关注点从：

• 数据集策划，
• 提示工程，
• 事后分析

转变为：

• 架构，
• 不变式，
• 可强制执行的约束。

我正在探索的内容

我一直在开发一个研究原型，将以下概念视为架构原语，而不是学习得到的行为：

• 可审计性，
• 自我解释，
• 受限的自我修订，
• 自主治理

目标不是性能或规模，而是清晰度：

• 使内部状态可检查，
• 使更改可审计，
• 使不安全的行为在结构上不可能。

这项工作仍处于早期阶段，尚不完美且带有探索性——但它已经让我确信，通过设计实现安全不仅是可能的，而且是必要的。

未解之问

该领域尚未就答案达成共识，所以我将以提问而非结论收尾：

• 哪些安全属性应当是不变式而非通过学习获得？
• 我们如何正式定义“受限自主性”？
• 能否使治理机制具备可组合性和可测试性？
• 哪些故障模式仅在自我修改系统中出现？

如果你从系统或架构的角度思考 AI 安全，我非常期待听到你的见解。

感谢阅读。