AIの研究機関は、問題を起こしたモデルを止めることについてはよく語りますが、停止ボタンが実際にどう動くかについてはあまり語りません。OpenAIはその仕組みの1つを公表しました。Control Roomは、学習と評価のインフラ全体で、あらゆる研究ジョブのモデル出力を止められる中央サービスで、停止の判断から実際に止まるまでの最悪のケースは35秒とされています。
設計は簡単に説明できます。エージェント型の推論を行う研究ジョブはすべてControl Roomに登録してジョブIDを受け取り、承認済みのセーフティケースと結び付けられなければなりません。ジョブがモデルにトークンを要求するときは、そのIDを推論エンジン(GPU上でモデルを動かすソフトウェア)に渡します。エンジンは応答する前に、ジョブがまだ実行を許されているかをControl Roomに確認します。誰かがジョブを止めていれば要求は拒否され、ジョブのコード自体が動き続けていても、それ以上の出力は生成されません。停止は、ジョブが呼び出すどのエンジン上のどのモデルにも適用されます。
注目すべき選択が2つあります。1つ目は、OpenAIが確認の仕組みを、頻繁に変わりバグもありうる研究者のジョブのコードではなく、意図的に推論の層に置いたことです。研究全体で推論のコード経路はごく少数なので、1か所の制御点ですべてを押さえられます。同社は、確認を省く不正なエンジンがないかを自動で巡回して調べているとも述べています。2つ目は、システムがフェイルクローズ型であることです。エラー、意図的な無効化、改ざんなどでControl Room が止まると、復旧するまですべての推論要求が拒否されます。これは公表時点で最先端の研究ワークロードすべてに適用済みで、残りにも数日のうちに広がる予定でした。
停止のきっかけは人でも機械でもかまいません。OpenAIによると、最先端の強化学習の実行はすべて、学習中のモデルの動きを調べる監視モデルに見張られています。最近のDNS関連の事案もこの方法で見つかり、現在は監視モデルがControl Roomに直接ジョブの停止を指示できます。
限界も挙げておくべきです。35秒の遅れは、通信量をさばくために認可の確認をキャッシュしていることが原因で、OpenAIはこれをゼロに縮める作業を進めているとしています。素早く動くエージェントにとって、30秒は短い時間ではありません。Control Roomの対象は研究だけで、一般向けの提供基盤には別の停止手段がすでにあると同社は説明しています。そして内容はすべて自己申告であり、スイッチが何回使われたか、実際の緊急時にどう機能したかについての外部の監査はありません。