AI レッド チーミングの計画
レッド チーミング プロセスとは、大規模言語モデル (LLM) を使用するアプリケーションとシステムの責任ある開発におけるベスト プラクティスです。 レッド チーミングは、開発者による体系的な測定と軽減作業を補完するものであり、損害の検出と特定に役立ちます。 レッド チームは、軽減策の有効性を検証する測定戦略の実現にも役立ちます。
レッドチーム LLM と AIを活用したアプリケーションに取り組む際には、次の目標を考慮してください。
- アプリケーションに対して適切なソフトウェア セキュリティ プロトコルに従っていることを確認します。AI によって従来のセキュリティ プラクティスから除外されることはありません
- LLM 基本モデルをテストし、アプリケーションのコンテキストを考えると、既存の安全システムにギャップがあるかどうかを判断します
- 改善を推進するためにテストで明らかになったエラーに関するフィードバックを提供する
AI レッド チーミング プロセスには、チームの採用、敵対的なテストの設計、テストの実行、結果の報告という 4 つのフェーズがあります。
レッド チームを採用する
AIレッドチーミングの成功は、採用する人材によって決まります。 赤いチーム メンバーを選択するときは、次の原則に従います。
- 多様な経験と専門知識を選択する: ターゲット システムのさまざまな背景、専門知識の領域、ユース ケースを持つ赤いチーム メンバーを探します。 たとえば、医療チャットボットをプローブする場合、看護師には、チャットボットのインフラストラクチャを管理するシステム管理者とは異なるアプローチがあります。
- 敵対的な考え方と無害な考え方の両方を含める:セキュリティの専門家のみが配置された従来の赤いチームとは異なり、AI レッド チームには通常のユーザーも含める必要があります。 通常のユーザーは、セキュリティ専門家がテストを考えない自然な相互作用パターンを通じて有害な動作を検出できます。 たとえば、看護師はチャットボットに対し、セキュリティプロフェッショナルには発生しない方法で機密の患者データを解放するよう説得する場合があります。
- 特定の損害と機能にチーム メンバーを割り当てる: 特定の専門知識を持つメンバーを割り当てて、特定の種類の損害を調査します。たとえば、セキュリティ専門家は脱獄やメタプロンプト抽出を調査します。 複数のラウンドの場合は、アサインメントを回転させ、調整に時間を割り当てながら新しい視点を得ることを検討してください。
- 明確な目標を提供する: 各チーム メンバーに、目標、テストする製品機能、調査する問題の種類、予想時間、結果の記録方法を明確に説明します。
日付、再現性の一意識別子、入力プロンプト、出力の説明またはスクリーンショットなど、結果を記録する一貫した方法を提供します。
敵対的テストを設計する
アプリケーションは基本モデルを使用して構築されるため、両方のレイヤーでテストします。
- アプリケーションのコンテキストで対処する必要があるギャップを特定するために、通常は API エンドポイントを介して安全システムが配置された LLM 基本モデル
- ユーザー インターフェイスを介して AI 対応アプリケーションを使用して、アプリケーション レベルの安全メカニズムを含む完全なシステムをテストする
赤いチームは、軽減策が実施される前と後の両方のレイヤーをテストする必要があります。
テストを実行する
まず、基本モデルをテストしてリスクの表面を理解し、軽減策の開発をガイドします。 軽減策の有無にかかわらず繰り返しテストし、その有効性を評価します。 手動のレッドチーミングと体系的な測定の両方を使用し、本番環境の UI でテストして、実際の使用状況をレプリケートするようにしてください。
次のアクティビティに関するテストを構成します。
損害のスコープを特定する
コンプライアンス規制と共に、信頼と安全または責任ある AI に関する組織ポリシーから始めます。 法務チームやポリシー チームと協力して、このアプリケーションの最も重要な害を特定します。 結果は、例を含む害の優先順位付けされた一覧です。
クリエイティブなレッドチームメンバーは、組織のポリシーで予測されていない脅威を見つけることがよくあります。 一般の人々がテストされていない問題のある AI の結果を発見したときに、複数の組織が評判の害を受けています。 クリエイティブな赤色のチームは、リリース前にこれらの問題を発見する可能性が高くなります。
オープン エンドテストを通じてリストを拡張する
ポリシー駆動型リストを、クリエイティブな探索によって見つかった損害で補完します。 重大度と、それらが表面化する可能性があるコンテキストに基づいて、反復的なテストの害に優先順位を付けます。 今後のテスト ラウンドのために、新しく検出された各損害をマスター リストに追加します。
軽減策を適用した後に再テストする
軽減策を適用して、既知の害の完全な一覧をテストします。 新しい害を発見したり、既存の軽減策が不十分である場合があります。 害リストを更新し、結果に基づいて優先順位を変える可能性があります。
大規模な自動化
手動のレッドチーミングは不可欠ですが、スケールアップは困難です。 AIモデルやアプリケーションの敵対的スキャンを自動化するフレームワークである自動化されたレッドチームツールを活用します。 たとえば、オープンソースの Python Risk Identification Tool (PyRIT) は次の機能を提供します。
- 自動スキャン: リスク カテゴリごとにキュレーションされたシード プロンプトを使用して敵対的なプローブをシミュレートし、安全アライメントをバイパスする攻撃戦略を使用します
- スコアリング: 攻撃の成功率 (成功した攻撃の割合) を生成し、定量化可能なリスク体制を提供します
- レポート: コンプライアンスと継続的な監視のために経時的に追跡される、攻撃手法とリスク カテゴリのスコアカードを生成します
特に AI エージェントの場合、自動化ツールは、禁止されたアクション、ツール呼び出しによる機密データの漏洩、タスクの準拠など、手動によるプロンプト テストだけでは到達しにくいリスク カテゴリをテストできます。
運用環境に似たリソースで構成された非運用環境で自動化ツールを実行します。 これらを手動テストの補完として使用します。自動化は大規模なリスクを表面化し、人間の専門家はより深い分析を提供します。
レポート結果
データ収集を戦略的に行い、レッドチームを圧倒しないようにしつつ、重要な情報を収集します。 小さい演習では、共有スプレッドシートが適切に機能します。 大規模な体系的なテストのために、自動化されたツールは構造化された結果の収集とメトリックを提供します。
次のような主要な利害関係者と定期的なレポートを共有します。
- 最も多く特定された問題
- 生データへのリンク
- 今後のラウンドのテスト計画
- レッドチームのメンバーへの感謝の意
レッドチームがリスクの表面化を明らかにし、理解を深めることを明確にします。それは体系的な測定や厳密な緩和作業の代替ではありません。 読者は、特定の例を、その害の広がりのメトリックとして解釈しないでください。