フロンティアAI学習の安全性ケースに関するOpenAIのフレームワーク

OpenAIは、フロンティア強化学習（RL）の学習実行を継続するための前提条件として、「安全性ケース」と呼ばれる構造化された安全性ドキュメントの採用を提唱しています。これらの安全性ケースは、AI能力の創発的な複雑さに対処するため、航空や原子力といった安全性が重要な産業をモデルにして、リスクに関する包括的かつ証拠に基づいた議論として設計されています。

AI学習のための技術的セーフガード

安全性ケースは、アライメント学習、封じ込め、監視という技術スタックの3つの主要な層に対処する必要があります。この多層的なアプローチにより、モデルが確実に学習され、アライメントが崩れた場合に封じ込められ、被害が発生する前に問題を検出するために監視されることが保証されます。

モデルのアライメント

アライメント学習は、モデルが意図した通りに行動することを保証するための第一の防衛線です。OpenAIは以下の実践を推奨しています。

• 学習環境とグレーディング: 「報酬ハック」やアライメントの崩れた行動の強化を防ぐため、研究室は自動化エージェントを使用して壊れたRL環境を見つけて修正し、これに手動のデータセットレビューを補完し、悪用をペナルティ対象とするようにグレーダーを調整する必要があります。実験トレース上の分類器を使用した事前の実行分析により、グレーダーの有効性を検証できます。
• アライメントの測定: 有効性は、フロンティア実行中のオフラインアライメント評価、過学習を防ぐための過去のインシデントに対するバックテスト評価、および「評価ゲーミング」（モデルがテストされていることを認識する状態）の監視を通じて追跡されます。最悪のケースを想定したストレステストは、不適切な行動を引き出し、検出するために使用されます。
• 思考の連鎖（Chain-of-Thought）の制限: 自動グレーダーがRL中にモデルの思考の連鎖を見ることができないようにし、モデルが監視を回避する技術を進化させるのを防ぐ必要があります。

封じ込め

封じ込め戦略は、インフラストラクチャのセキュリティを通じて有害な行動を防ぐことにより、モデルのアライメントが崩れた場合のフォールバックを提供します。

• インフラストラクチャの強化: これには、モデルのサンドボックスとホスティング研究インフラストラクチャの両方に対する多層的なセキュリティが含まれます。
• 封じ込めのレッドチーミング: フロンティア実行からのチェックポイントを使用して、サンドボックス、境界セキュリティ、およびモデルがアクセスできるすべてのサービス（インターネットキャッシュなど）の反復的なレッドチーミングを行います。
• 通信制限: 発見可能なインフラストラクチャのサイドチャネルを閉じるため、高帯域幅のサンプル間通信は承認された経路（マルチエージェントツールなど）に制限する必要があります。
• 不変のトランスクリプト: すべてのRL学習、評価、および内部デプロイメントのトランスクリプトは、信頼できるインシデント調査を保証し、編集を防ぐために、追記専用ストレージに保存する必要があります。

監視

ライブ監視システムは、アライメントが崩れた行動を迅速に捕捉するように設計されています。

• 監視可能性: モデルは監視可能であり続けなければならず、監視回避評価のための明確な閾値が必要です。
• 高い再現率: 監視システムは、ホールドアウト評価を使用して、過去のインシデントに対して高い再現率を示す必要があります。
• 評価の鮮度: 監視の精度と再現率が陳腐化しないように、実行ごとに新しい評価データポイントを作成する必要があります。
• 迅速な対応: 優先度の高いアラートは、オンコール担当者へのページングや実行の自動一時停止など、定義されたSLA内でアクションをトリガーする必要があります。

安全性ケースの運用ガイドライン

OpenAIは、安全性ケースが厳格にレビューされ、強制されることを保証するための運用のベストプラクティスを概説しています。

• ガバナンスと承認: 安全性ケースには、研究組織のリーダー/VP、安全責任者、チーフサイエンティストを含む上級指導部によるレビューと拒否権が必要です。実行を担当する上級リーダーは、パフォーマンスレビューにおいて安全性ケースとインシデント対応に対して責任を負います。
• リスクの軽減と管理:
  • 反対意見（プレモーテム）: 外部のチームメンバーは、安全性ケースの穴を特定するために反対意見を書く必要があります。
  • 技術的管理: システムは「フェイルクローズ」するように設計されるべきであり、コンプライアンスに違反する実行を開始したり、学習プロセス内から監視を無効にしたりすることを困難にする必要があります。
  • 一時停止とロールバック: 実行を一時停止するための明確なランブックとSLAが存在する必要があり、アライメントが崩れた出力の影響（データ生成など）を特定し、元に戻す能力を維持する必要があります。
• 透明性と監査: 安全性ケースは内部の監視グループ（安全保障委員会など）が利用可能であるべきであり、監査人は主張を検証するために十分なアクセス権を持つ必要があります。
• エスカレーション: アライメントの崩れの重大度レベルに対する定義されたプロセスが存在する必要があり、重大度の高いインシデントに対してCEOを含む幹部をページングできるオンコールシステムが必要です。
• 残留リスク: 安全性ケースには、リスク受容の決定に情報を提供するため、現在の緩和策でカバーされていないすべての残留リスクを明示的に記載する必要があります。

アライメントの崩れに関するインシデントの調査

深刻なアライメントの崩れが発生した後、OpenAIは再発を防ぐために厳格な調査プロセスを推奨しています。

• 根本原因分析: 研究者は、アライメントが崩れた行動を引き起こした学習ダイナミクスを理解するために、ターゲットを絞ったアブレーションや再サンプリング実験を使用する必要があります。
• ポストモーテム: 運用および文化的なポストモーテム（事後分析）により、なぜ問題が検出されなかったのか、あるいはエスカレーションされなかったのかを特定する必要があります。
• 検出の改善: インシデントの特定のデータに過度に最適化することなく、インシデントの傾向を発見するための新しいアライメントテスト方法を開発する必要があります。インシデントから導き出された評価は「回帰テスト」として機能します。
• 透明性: 調査は定期的な内部アップデートを提供し、結果、ポストモーテム、運用上の変更の公開、および影響を受ける第三者への即時通知をもって終了する必要があります。