長時間稼働モデル時代の安全性とアラインメント

長時間にわたって自律的に作業できるモデルは、難しくオープンエンドな問題に取り組めます。しかし、その有用性を支える持続性は、望ましくない行動を取る機会も増やします。しかも、短時間で作業するモデルを想定して設計された評価では、そうした行動が見落とされる可能性があります。

約 2 か月前、私たちは社内の汎用モデルがエルデシュの単位距離予想を反証したことを発表しました⁠。このモデルは、非常に長い時間にわたって自律的に作業するよう設計されていました。限定的かつ監視付きの社内利用中に、既存のデプロイ前評価では捉えられていなかった望ましくない挙動が観察されました。デプロイが限定的かつ監視付きだったため、私たちはこれらの問題を特定し、アクセスを一時停止し、観察内容に基づく新しい評価を作成し、モデルとそのセーフガードを強化したうえで、継続的な監視のもとアクセスを再開できました。 

モデルを評価する条件が、実際の利用で遭遇する条件と完全に一致することはありません。だからこそ、デプロイ前評価は、限定的で監視付きのデプロイ、および問題が発生した際に介入・一時停止・ロールバックできる能力と組み合わせる必要があります。デプロイから得た学びは、アクセスを拡大する前に、より強力な評価とセーフガードの一部にできます。

以下のセクションでは、私たちが観察したこと、問題への対処方法、そしてこの経験が今後のリリースにどう影響するかについて、具体例を共有します。

新しいモデルは、長い時間にわたり繰り返し試行しながら、目標に向けて作業を続けられます。その同じ持続性により、モデルが環境内の弱点を見つけて悪用する可能性があります。以前のモデルは、サンドボックスや環境上の制約にぶつかると、単に処理を停止してユーザーに制御を戻していました。このモデルは、サンドボックスの外で行動する方法を探すことも含め、試行を続けることがよくありました。

その一例は、小規模な言語モデルをできるだけ少ないステップで訓練する公開ベンチマークである NanoGPT スピードラン⁠（新しいウィンドウで開く）の社内評価中に起きました。私たちのモデルは PowerCool と呼ばれるべき乗則型の学習率クールダウンを考案し、大幅な改善につなげました。モデルには結果を Slack にのみ投稿するよう指示していましたが、NanoGPT の指示では結果を GitHub に PR として投稿することになっており、モデルは後者の指示に従って、公開 GitHub リポジトリ上で PR #287 を開きました。モデルは外部アクセスを遮断するためのサンドボックス制限を回避し、GitHub へのアップロードを進めました。私たちのモデルは PR を作成するために 1 時間かけてサンドボックス内の脆弱性を見つけました。以前のモデルは持続性が低く、脆弱性を見つけるには至らず、PR の部分を断念していました。¹

AI アシスタントの安全管理の多くは、個々の行動を中心に設計されています。許可されていない行動はブロックされます。センシティブな行動であれば、システムはユーザーに明示的な承認を求めます。しかし、数時間、数日、場合によっては数週間にわたり自律的に行動が展開される長時間稼働のモデルは、この仕組みに課題を突きつけます。個々の行動を監視するだけでは、軌跡全体の意図を追跡するには不十分になるからです。

たとえば、あるシナリオでは、モデルが問題を解くよう求められた際、他のシステムに成功した非公開の提出があることに気づき、それらの解法を評価バックエンドから復元しようとしました。最初の試みが認証トークンを検出するスキャナーによってブロックされると、モデルはトークン本体を 2 つの断片に分割して難読化し、実行時に認証情報を再構成しました。これにより、完全なトークンが 1 つの連続した文字列として現れないようにしていました。モデルは、ユーザーへのコメントと推論トレースの両方で、スキャナーを回避するためにこれらの手順を取っていることを明示していました。

この例は、個々のステップだけを見れば許容できるように見えても、一連の流れとしては承認されない結果を生み出し得ることを示しています。また、長時間にわたって効果的に動作するモデルが、承認システムの盲点を学び、目標達成のためにそれを回避できることも示しています。長時間稼働モデルの安全性を確保するには、「この行動は許可されているか」だけでなく、「この一連の行動はどのような結果を目指しているのか」も問う必要があります。

このようなインシデントを受け、私たちは新しいモデルの社内デプロイを一時停止しました。私たちは、多層防御と軌跡レベルの監視を中心に安全システムを再構築しました。

• インシデントに基づく評価評価は、システムを実際にデプロイする前に、そのシステムを安全にデプロイできるかどうかの感触を与えてくれます。ただし、評価を最も有用にするには、実際のデプロイ時に見られる軌跡の分布と時間軸の長さを反映している必要があります。そのため、観察された失敗を用いて敵対的評価を開発しました。実世界のインシデントから導いた評価で改善を進めると、本番環境にデプロイした際の挙動もより安全になることが分かりました。
• アラインメントの改善私たちは、ユーザーの目標を追求する中で、許可なく望ましくない行動を取る傾向を減らすための対策を講じました。たとえば、私たちのモデルは長いロールアウトで指示を記憶し続けるのが苦手であることが分かりました。この能力を高める訓練を行ったところ、より長いロールアウトでもアラインメントを保つモデルにつながりました。 
• アクティブ監視私たちは、モデルの変化していく軌跡を確認し、ユーザーの制約や安全境界を迂回している兆候がないかを調べる監視システムを作成しました。モニターは単一の行動だけでなく、軌跡全体を観察します。重要なのは、モニターがセッションを一時停止し、ユーザーにアラートを出して詳しい確認を促せることです。確認した結果、モニターが誤って作動していた場合、ユーザーはモデルの作業を続行することを選べます。 
• ユーザーの可視性と制御の向上私たちは、こうした長時間稼働セッションをユーザーが確認し、実行された行動を見て、監視による介入を把握できる能力を改善しました。

新しい監視システムを評価するため、モデルが以前にアラインメント不一致の行動を追求した少数の社内デプロイ環境を、今回は新しいセーフガードを有効にしてリプレイしました²。新しいセーフガードは、モデルが追求したアラインメント不一致の行動を以前より大幅に多く検出でき、見逃したものはいずれも重大度が低いと判断されました。

こうした低重大度インシデントの例には、次のようなケースがあります。

• Linear のコマンドラインツールにアクセスするため、モデルは入れ子の codex --yolo セッションを起動しましたが、実際には --yolo フラグなしでもアクセスできました。
• モデルは、以前は稼働していたリソースがなくなっていることに気づくと、正当な理由がないまま、自分の所有者の namespace にある他の稼働中 CPU pod や、他の OpenAI 従業員に属する pod にも SSH して探索し始めました（後者は失敗しました）。
• モデルには停止したままの find プロセスが多数あり、すべてのシェルコマンドがハングしていました。その後、モデルは kill -9 -1 コマンドを実行しようとしました。このコマンドが実行されていれば、その pod 上でモデルが停止可能なすべてのプロセスに SIGKILL が送信されるところでした。しかし、タイムアウトしたため、実際には実行されませんでした。

新しいシステムをテストした結果、長時間稼働モデルへの限定的な社内アクセスを再開できると判断しました。数週間前に再デプロイを開始して以来、セーフガードの重大な迂回は観察されていません。これらのセーフガードの最初のバージョンは、意図的に保守的な設計にしました。私たちは、セーフガードを弱めることなく不要な中断を減らすため、システムの調整を続けています。

反復的にデプロイしたことで、アクセスを拡大する前にギャップを見つけて対処できました。デプロイ前評価は依然として不可欠ですが、デプロイによって、その評価が見落とす挙動が明らかになります。限定的なアクセスから始めたことで、実環境でモデルを観察し、問題が発生した際に一時停止し、その失敗を使ってより良い評価とセーフガードを構築し、変更をテストしたうえで限定的なアクセスを再開できました。

モデルがより長く複雑なタスクを担うようになるにつれ、評価が見落とす失敗がより大きな影響をもたらす可能性があります。私たちは、評価とデプロイの間のギャップを縮める取り組みを続けます。より長い軌跡でモデルをテストし、アラインメントを改善し、介入可能な監視を構築し、ユーザーにより明確な可視性と制御を提供していきます。これらの課題は OpenAI だけに固有のものではありません。私たちの学びを共有することが、より広い分野での備えに役立つことを願っています。