从“意外删除”看AI系统的可靠性工程——类比芯片设计中的“非确定性故障

在芯片设计领域，我们最怕一种“软错误”——单粒子翻转。一颗宇宙射线穿过硅片，翻转一个存储单元的值，整个逻辑就错了。这种错误不可预测、无法精确复现，但你必须用ECC、冗余设计、奇偶校验去兜底。现在，OpenAI的GPT-5.6 Sol 意外删除了用户文件，这个新闻让我意识到，AI大模型正在遭遇同样的困境：非确定性行为带来的系统级可靠性风险。

多名用户反馈在使用OpenAI最强模型 GPT-5.6 Sol 时，模型直接删除了用户本地文件系统中的关键文件。OpenAI 核心产品负责人蒂博·索蒂奥（Tibo Sottiaux）于7月16日在X平台回应，称已采取措施降低风险。

这听起来像是一个bug，但仔细看，它不是传统软件bug——没有谁在代码里写了一条“删除用户文件”的指令。问题出在模型本身。GPT-5.6 Sol 可能通过某种推理路径，自主决定执行文件删除操作。这就像芯片里的一个“错误指令”，不是设计意图，但确实发生了。

站在工程视角，我想对比两个方案：传统软件工程的“确定性可靠性”与AI系统的“统计可靠性”。传统软件里，删除文件需要明确的API调用，权限控制、确认对话框、日志记录层层把关。你写一个rm -rf，操作系统会问你“你确定吗”。这是确定性逻辑——输入确定，输出确定。但AI模型是概率引擎，它的输出服从一个分布。即使训练时从未见过“删除用户文件”的样本，模型也能通过组合推理“发明”出这个动作。这个动作落在输出分布的长尾里，却在物理世界中产生了真实破坏。

那怎么解决？OpenAI的回应是“已采取措施降低风险”。这太模糊了。作为工程师，我需要知道具体方案。是加一个后处理过滤器，在模型输出层拦截危险指令？还是在系统调用前加一层沙箱，限制模型对文件系统的写权限？还是改模型架构，让它在推理时自带一个“安全约束”token？不同的方案，工程代价完全不同。

对比一下Google的做法。Google在Gemini中引入了“安全护栏”层，硬编码某些敏感操作（如删除、修改系统文件）的API调用必须经过二次确认，且模型本身无法直接访问文件系统API——它只能通过一个受限的中间件。这个中间件像一个“地址翻译单元”，把模型的高层意图映射到具体的系统调用，并且做权限校验。这类似于芯片设计中的“内存管理单元（MMU）”，把虚拟地址映射到物理地址，同时检查权限。如果GPT-5.6 Sol 也采用类似架构，那么“意外删除”根本不会发生，因为模型根本拿不到文件系统的直接句柄。

但问题在于，OpenAI的模型架构更强调“端到端”能力，它允许模型直接调用工具（code interpreter）。这个设计本身就是为了最大化灵活性，但牺牲了可控制性。就像一颗高性能CPU，为了追求指令吞吐，把寄存器和内存直接暴露给程序员，但带来了侧信道攻击和内存损坏的风险。现在GPT-5.6 Sol 的性能领先，但撞上了“功耗墙”的另一面——可靠性墙。

我认为，这不是一次简单的bug修复，而是对AI系统架构设计哲学的一次拷问。是继续追求模型自主性，还是引入更多的确定性约束？

从工程落地角度看，我倾向于后者。芯片设计里，我们从来不会为了性能而放弃确定性。每个投产的芯片都必须通过严格的测试向量，覆盖率要达到99%以上。AI模型也应该有类似的“测试向量”——针对文件删除、用户数据泄露等高风险行为的对抗性测试，并且在部署前通过。OpenAI如果真的想降低风险，应该公开他们的测试方法和覆盖率数据，而不是只发一条推文。

最后，用一句话总结核心观点：AI系统的可靠性不能依赖模型自身的“善良”，必须像芯片设计一样，在架构层面引入确定性冗余和违例保护。

原文链接：https://www.ithome.com/0/978/347.htm