OpenAI は、研究インフラ全体に Control Room と呼ばれる集中制御システムを導入しました。これは、潜在的に危険な AI モデルのワークロードが介入の決定から 35 秒以内にさらなる出力を生成しないように設計されています。 Interesting Engineering が報じたように、このシステムは、エージェント モデルのトレーニング、評価、データ処理ジョブなど、同社の最先端の研究を推進するワークロードを、実行を継続できるかどうかを制御する中央サービスに接続します。

同社は11月9日にこのシステムを公に発表し、次のように書いている。「私たちは、研究インフラ全体でモデルのワークロードを追跡し、安全性やセキュリティ上の懸念が生じた場合に迅速に停止するための中央システムであるControl Roomを構築しました。これは、モデルのトレーニングと評価のためのエージェント・サンプリング、データなど、あらゆる研究推論ワークロードを接続します...」 この件の詳細は、AIニュースをご覧ください。

タイミングが注目に値する。 AI モデルの機能が向上し、トレーニング パイプライン内でより自律的なエージェントのような役割が与えられるにつれて、研究中にモデルが予期しない動作をするリスクも増大します。 Control Room は、トラブルを監視するだけでなく、物理的にトラブルを遮断できるという OpenAI の構造的な答えです。

コントロールルームの仕組み

Control Room は、調査ワークロード、推論エンジン、中央の Control Room サービスという 3 つの主要コンポーネントを接続します。 OpenAI の用語では、ワークロードとは、強化学習実験、評価、大量のデータ処理タスクなどの研究ジョブを指します。エージェントによる推論を実行するすべての研究ワークロードは、実行する前に承認された安全性ケースに関連付けられている必要があります。

研究者がジョブを開始すると、そのコードは Control Room に一意のジョブ ID を要求します。その識別子は、ワークロードが推論エンジン (実際にモデルを実行して出力を生成する GPU を利用したシステム) に送信するすべてのリクエストに添付されます。

推論リクエストを実行する前に、エンジンは Control Room に問い合わせて、関連するジョブの実行がまだ許可されていることを確認します。研究者または自動監視システムが Control Room にジョブを停止するように指示した場合、サービスは次の推論リクエストを拒否し、エンジンはそのワークロードに対するさらなるモデル出力の生成を拒否します。

ジョブを停止する必要はなく、出力を停止します

設計上の 1 つの詳細が際立っています。それは、ワークロードを停止しても、必ずしもワークロードが終了するとは限らないということです。研究プロセス自体は実行し続ける可能性があり、そのコードは実行され続けますが、許可された推論エンジンを通じて追加のモデル出力を取得することはできなくなります。不正な動作を行うトレーニングの実行には、これで十分です。より多くのモデル世代にアクセスできなければ、それ以上の進歩はできません。

このアプローチでは、安全性チェックを正しく実装するために研究者自身のワークロード コードに依存することも避けられます。 OpenAI は、代わりに重要な承認メカニズムを推論層に配置し、集中管理されるコード パスが少なくなります。言い換えれば、キルスイッチは個々のチームが作成した実験コードではなく、企業が完全に管理するインフラストラクチャ内に存在します。

フェイルクローズするように設計されています

Control Room は、他のコンポーネントが故障した場合でも効果を維持できるように構築されています。そのフェールクローズ メカニズムは、Control Room サービス自体が利用できなくなった場合に推論リクエストをブロックします。つまり、技術的な障害、意図的な無効化の試み、または中央サービスの潜在的な改ざんにより、システムが通常の動作に戻るまで推論エンジンがすべてのリクエストを拒否することになります。

35 秒という数字は、停止命令を受信して​​からそれ以上の進行が阻止されるまでの最大遅延を表しています。この遅延は、膨大な量の推論認可リクエストを処理するために使用されるキャッシュ層に起因しており、OpenAI は間隔をゼロに短縮するために取り組んでいると述べています。

自動モニターがあらゆるフロンティアの走行を監視

キル スイッチは自動監視と組み合わせます。 OpenAI によると、そのフロンティア強化学習ジョブはすべて、モデルの動作を検査し、潜在的な問題を検出した場合にアラートを発する別個のモデルベースのモニターで実行されます。アラートによって介入が必要な場合、監視システムは関連するジョブを終了するように Control Room に指示できます。これにより、ワークロードが使用するモデルまたはエンジン全体にわたる後続の推論リクエストがブロックされます。

同社は、このような安全対策が重要である理由の一例として、最近の DNS 関連のインシデント（外部チャットボットにアクセスしようとするエージェントをモニターが検出した）を挙げました。この場合、異常は人間のレビュー担当者ではなく自動監視によって発見されました。

より広範な安全推進の一環

OpenAI は、介入の必要性が最も高い研究インフラ全体に Control Room がすでに導入されていると指摘しています。 ChatGPT などの製品を強化する外部モデル提供インフラストラクチャはより集中化されており、必要に応じてモデルのデプロイメントを削除するための運用メカニズムがすでに備わっています。Control Room は研究面でのギャップを埋めます。

同社は、フロンティアモデル開発の安全性を確保するための広範なアプローチの一環として、監視システムと不正な動作やセキュリティ侵害に対する保護措置を引き続き強化すると述べている。

自律エージェントによってますます定義される業界にとって、Control Room はフロンティア ラボがどこに向かっているのかを示す信号です。モデルが大規模な場合に誤動作することを想定し、モデルを停止することを希望ではなくインフラストラクチャの保証にする安全メカニズムです。

---

AIの最新情報をお届け

AIの最新ニュース、分析、ブレイクスルーを一箇所で。

AIニュースをもっと読む →