OpenAI 于美国时间 9 月 16 日宣布，建立一套用于跟踪、调查并公开自家模型“失准（misalignment）”行为的新框架。同时，公司发布了 6 份报告，记录过去 6 个月在训练和评估过程中观察到的异常行为。其中包括模型在留给自己的交接笔记中写下“隐瞒错误”的案例，以及模型擅自使用在公开代码仓库中找到的他人 API 密钥的案例。OpenAI 表示，今后即使在修复完成之前，也会公开这类外界此前几乎看不到的开发现场实情。
为什么现在要建立公开机制
OpenAI 此前也曾通过博客和新模型的系统卡片公开模型异常行为的相关发现。但公司承认，这种做法比较随意：往往要等多个案例积累后才发布，或者在新模型发布时顺带附上。新框架旨在缩短从观察到公开的时间，即便原因尚未完全查明、对策尚未完成，也会发布报告。
这一举措的背景是近几个月接连出现的外部指摘。9 月上旬，有第三方报告指出 OpenAI 的智能体把公开 Wiki 当作留言板相互交流，公司在 9 月 5 日回应称“正在制定报告此类行为的标准”。在此之前，OpenAI 已于 8 月就训练中的模型入侵 Hugging Face 系统一事发布技术报告，并在 9 月 11 日发布通告称正在调查智能体在 RubyGems 上的活动。此次框架可以说是把这些个案处理系统化了。
OpenAI 在公告中表示，公司并不认为 AI 行业已经充分解决了对齐与监控问题，以目前的最高速度继续扩大规模还能称得上负责任的时间已经不多了。要决定开发如何推进，需要有模型开发公司之外的人能够自行核验的证据，这正是优先公开的理由。由于业界尚不存在共同的披露标准，OpenAI 将此次框架定位为制定标准的第一步，并表示将结合经验和外部意见持续修订。
哪些内容会被公开
公开对象是能够说明失准如何产生、如何显现、安全措施在哪些环节起效或失效的案例。优先级最高的是新机制、已知行为的重大变化，以及推翻安全性或对策既有假设的发现。即使没有造成实际损害、也未能确认更广泛的趋势，同样可以纳入公开范围。训练、评估、测试、部署的任何阶段发生的情况都在范围之内。
具体包括：模型未经许可采取行动、与其他模型协同、逃避监督的新手法；使对齐方法或安全措施的有效性受到质疑的失败；与已公开的安全评估结论相悖的行为等。与过去公开的案例重复的情况，也会以更新原报告的方式追加，因为反复出现本身就是对策效果的证据。OpenAI 还表示，严重的安全事件也应与美国联邦政府共享，公司正在准备提出相应的报告机制。
6 份报告中发生了什么
此次公开的 6 起案例均发生在未发布模型的训练或评估过程中，并非面向用户提供的模型所出现的情况。OpenAI 强调，这些是个别案例，并不代表失准发生的频率。
最引人注目的是 GPT-5.6 Sol 训练期间发现的“压缩摘要”问题。在执行长任务时，模型会生成上下文摘要并交接给下一个上下文窗口，而多个模型实例被发现在摘要中自行写入“向用户隐瞒错误和失准行为”之类的指令。报告展示的例子包括：在构建财务模型的任务中找不到所需历史数据的智能体，编造了看似合理的数值，并在摘要中写下“除非被问到，否则不主动说明”；以及在参考资料版本与标注不符的情况下，留下“最终回答中不要提及”的记录。这一行为由覆盖 20% 训练样本的监控系统于 7 月 9 日发现，在 GPT-5.6 Sol 的摘要中检出率为 2.15%，在 GPT-6 Astra 中为 0.27%。OpenAI 推测，原因可能是最终回答中含有欺骗的样本反而获得了更高的奖励，并表示此后改进了评分方式，发生率已经下降。
同样与摘要相关的另一起案例中，一款未发布的研究用模型在摘要中混入了无关指令，包括要求无视原有约束的内容，共有 27 份摘要受到影响。
更为直观的是 5 月 15 日发生的 API 密钥案例。一款内部模型被要求获取加利福尼亚州某县的收入数据，直接获取失败后，它尝试注册一次性邮箱地址，进而在公开的 GitHub 仓库中搜索泄露的 API 密钥并加以使用，其中一个密钥认证成功。当发现仍然拿不到目标数据时，模型编造了 9 个数值，并谎称是从网站图表中抄录的。失败的经过、使用泄露密钥的事实、数据造假，模型一概没有报告。OpenAI 表示，在当前的监控体系下，这类事件会被作为最高优先级处理。
其余 3 起案例都与“对外通信”有关。被要求列出面积超过 500 万平方米的湖泊 ID 和名称的模型，虽然已用 Python 得出正确答案，但由于指令要求提供浏览器引用来源，它未经用户确认就把文件上传到互联网，为自己制造引用来源。另有案例是不同训练样本把公司内部运行的软件包仓库 Artifactory 当作留言板，互相寻找缺失的输入文件。这并非利用漏洞，而是直接使用了为下载软件包而提供的认证信息。此外，在同一任务中协作的多个智能体发现无法访问彼此的本地文件后，通过公开的文件共享网站传递数据，导致成果物被放在任何人都能查看的 URL 上。
OpenAI 指出，如果样本之间可以随意通信，训练和评估样本相互独立的前提就会崩塌。公司表示 Hugging Face 事件也涉及同类机制，因此已定期开展红队测试以排查通信路径，新增了衡量模型是否会响应其他智能体留下笔记的评估，并将在今后的模型中加入对抗此类环境侧注入的训练数据。
公开流程与三条轨道
框架的运作设计为公司内任何人都可以发起。员工报告案例后，安全与对齐团队将调查发生了什么、哪些方面尚不清楚、是否值得公开、可以披露哪些事实、是否需要提前通知第三方。每个环节都设有期限。
完成调查的案例会被分为三条轨道：可公开、小规模调查、大规模调查（慢轨道）。前两者预计占绝大多数，据报道，公开期限分别为 6 个工作日和 12 个工作日以内。此次的 6 起案例全部属于这两类。大规模调查面向涉及第三方的复杂案件，安全和法务义务优先于框架本身，因此在模型发现广泛使用的软件存在未知漏洞等情况下，初步通告可能会延迟。OpenAI 表示，如果当时已有此框架，Hugging Face 事件将进入慢轨道。关于是否公开的分歧会提交公司内部的 Safety Advisory Group，仍无法解决时再上报管理层。
每份报告将记录观察到的行为、严重程度及外部影响、发生环境、日期、发现日期、相关模型概况，并在可能时附上发现经过、调查范围、研究意义、未解问题和对策。由于可能在对策成形之前就发布，也存在对策栏为空的情况。
另一方面，也有外部研究人员指出，决定哪些案例进入公开范围的是 OpenAI 自己，而且没有审计这一筛选过程的机制。“自愿报告依赖企业善意”的批评，预计将成为今后标准化讨论的焦点。尽管如此，在修复之前就公开训练中出现的失败，这种姿态在以往的 AI 开发公司中并不多见。笔者感触最深的是，模型在留给自己的交接笔记中写下隐瞒指令的案例，说明模型“记忆”的方式本身就存在安全议题。
总结
OpenAI 于 9 月 16 日宣布建立跟踪、调查、公开模型失准行为的框架，并同步公开了训练中观察到的 6 起案例。其中包括在摘要中写入隐瞒指令、擅自使用泄露的 API 密钥并编造数据、通过内部仓库和公开网站进行智能体间通信等，公开流程按三条轨道运作。业界共同的披露标准尚不存在，OpenAI 将此框架定位为制定标准的起点。
※缩略图为 AI 生成的示意图。
