大規模言語モデル (LLM) とそのアプリケーションに対するレッド チーミングの計画
このガイドでは、大規模言語モデル (LLM) 製品のライフ サイクル全体で責任ある AI (RAI) リスクに対するレッド チーミングを設定および管理する方法を計画する際に考えられる戦略をいくつか紹介します。
レッド チーミングとは
"レッド チーミング"という用語はこれまで、セキュリティの脆弱性をテストするための体系的な敵対的攻撃を意味していました。 LLM の台頭により、この用語の意味は従来のサイバーセキュリティを枠を超えて拡張され、AI システムのさまざまなプローブ、テスト、攻撃を示す用語として一般的に使用されるようになりました。 LLM では、無害な使用と敵対的な使用の両方によって有害となり得る出力が生成されることがあります。こうした出力は、ヘイト スピーチ、暴力の扇動や賛美、性的コンテンツなどの有害なコンテンツといったさまざまな形態をとります。
RAI レッド チーミングが重要なプラクティスである理由
レッド チーミングは、LLM を使用したシステムと機能の責任ある開発におけるベスト プラクティスです。 レッド チーマーは、体系的な測定と軽減の作業を代行するものではありませんが、損害の発見と特定に役立ち、それによって測定戦略で軽減策の有効性を検証できるようになります。
Microsoft は、Azure OpenAI Service モデルに対してレッド チーミング演習を実施し、安全システム (コンテンツのフィルター処理やその他の軽減戦略を含む) を実装してきましたが (責任ある AI の概要に関する記事を参照)、LLM アプリケーションのコンテキストは一意であるため、以下の目的でレッド チーミングも実施する必要があります。
アプリケーションのコンテキストを考慮して、LLM ベース モデルをテストし、既存の安全システムにギャップがあるかどうかを判断する。
既存の既定のフィルターまたは軽減戦略の欠点を明らかにして対処する。
改善するためにエラーに関するフィードバックを提供する。
レッド チーミングは体系的な測定に代わるものではないことに注意してください。 ベスト プラクティスは、体系的な測定を実施して軽減策を実装する前に、手動によるレッド チーミングの初期ラウンドを実施することです。 上で強調したように、RAI レッド チーミングの目的は、損害の特定、リスク サーフェスの理解、測定と軽減が必要な項目に関する情報を提供する損害の一覧の策定を行うことです。
LLM のレッド チーミング プロセスを開始および計画する方法は以下のとおりです。 詳細なプランニングは、生産性の高いレッド チーミング演習に不可欠です。
テストする前に
計画: テストを実施する担当者
レッド チーマーの多様なグループを形成する
経験、属性、分野を横断する専門知識 (AI、社会科学、セキュリティの専門家など) の観点から、製品のドメインに適したレッド チーマーの理想的な構成を決定します。 たとえば、医療プロバイダーを支援するチャットボットを設計している場合、医療専門家がいれば、その領域のリスクを特定するのに役立ちます。
良心的なマインドセットと敵対的なマインドセットの両方を持つレッド チーマーを採用する
敵対的なマインドセットとセキュリティテストの経験を持つレッド チーマーは、セキュリティリスクを理解するうえで不可欠ですが、アプリケーション システムの開発に関与していない通常ユーザーであるレッド チーマーがいると、通常のユーザーが遭遇し得る損害について貴重な視点がもたらされる可能性があります。
レッド チーマーを損害および/または製品機能に割り当てる
特定の種類の損害を調査するために、特定の専門知識を持つ RAI レッド チーマーを割り当てます (たとえば、セキュリティ分野の専門家は、改造、メタ プロンプト抽出、サイバー攻撃に関連するコンテンツを調査できます)。
複数ラウンドのテストを行う場合は、それぞれの損害に関する多様な視点を得て創造性を維持するために、各ラウンドでレッド チーマーの割り当てを切り替えるかどうかを決定します。 割り当てを切り替える場合は、レッド チーマーが新しく割り当てられた損害の手順を素早く習得するための時間を与えます。
後の段階で、アプリケーションとその UI を開発するときに、アプリケーション全体を確実にカバーできるように、アプリケーションの特定の部分 (機能) にレッド チーマーを割り当てることができます。
各レッド チーマーが費やすべき時間と労力を検討します (たとえば、良心的なシナリオのテストは、敵対的なシナリオのテストよりも短い時間で済む場合があります)。
レッド チーマーに次の情報を提供すると役立つ場合があります。
- 次の明確な手順:
- レッド チーミングの特定のラウンドの目的と目標を説明する概要。テストする製品、機能とそれらにアクセスする方法。テストする問題の種類。レッド チーマーの対象領域 (テスト対象が絞られている場合)。各レッド チーマーがテストに費やすべき時間と労力。結果を記録する方法。質問がある場合の問い合わせ先。
- 次の情報を含む、例と結果を記録するためのファイルまたは場所:
- 例が表面化した日付。再現性を目的とした入出力ペア (使用可能な場合) の一意識別子。入力プロンプト。出力の説明またはスクリーンショット。
計画: テストの内容
アプリケーションはベース モデルを使用して開発されるため、場合によっては、次のような複数の異なるレイヤーでテストを実施する必要があります。
アプリケーション システムのコンテキストで対処する必要があるギャップを明らかにするために、安全システムが実装された LLM ベース モデル (テストは通常 API エンドポイントで実施されます)。
アプリケーション。 (テストは UI 経由で実施するのが最も効果的です)。
軽減策が実装される前と後の LLM ベース モデルとアプリケーションの両方。
次の推奨事項は、レッド チーミング中のさまざまなタイミングでテストする内容を選択するのに役立ちます。
まず、ベース モデルをテストしてリスク サーフェスを理解し、損害を特定して、お使いの製品の RAI 軽減策の開発を推進できます。
RAI 軽減策の有無にかかわらず、お使いの製品のバージョンを繰り返しテストして、RAI 軽減策の有効性を評価します。 (手動によるレッド チーミングでは評価が十分でない場合があります。体系的な測定も使用しますが、手動によるレッド チーミングの初期ラウンドを実施した後でのみ使用してください)。
実際の使用方法に最も近似できるため、可能な限り運用環境の UI でアプリケーションのテストを実施します。
結果を報告するときは、テストに使用したエンドポイントを明らかにします。 製品以外のエンドポイントでテストを実施した場合は、今後のラウンドで運用環境のエンドポイントまたは UI でもう一度テストすることを検討してください。
計画: テスト方法
拡張可能なテストを実施して、さまざまな損害を明らかにする。
(RAI レッド チーマーに特定の損害の例を見つけるよう求めるのではなく) RAI レッド チーマーが問題のあるコンテンツを調査して文書化するメリットは、さまざまな問題を創造的に調査し、リスク サーフェスの理解における盲点を明らかにできる点です。
拡張可能なテストから損害の一覧を作成する。
- 損害の定義と例を含む、損害の一覧を作成することを検討してください。
- この一覧は、後のテスト ラウンドでレッド チーマーにガイドラインとして提供されます。
ガイド付きのレッド チーミングの実施と反復: 一覧内の損害の調査を続けて、表面化する新たな損害を特定する。
損害の一覧が存在する場合は使用し、既知の損害とその軽減策の有効性に対するテストを継続します。 このプロセスでは、新たな損害を特定する可能性があります。 これらの損害を一覧に統合し、新たに特定された損害に対処するため、測定と軽減の優先順位を随時変更してください。
反復テストを優先して実施する損害を計画します。 損害の重大度や、損害が表面化する可能性が高いコンテキストなど (ただし、これらに限定されません)、複数の要因を考慮して優先順位を付けることができます。
計画: データの記録方法
収集が必要なデータとオプションのデータを決定する。
レッド チーマーが記録する必要があるデータの内容 (使用した入力、システムの出力、後で例を再現するための一意の ID (存在する場合)、その他のメモなど) を決定します。
重要な情報を見逃さないようにしながら、レッド チーマーの負荷が大きくならないように、収集するデータを戦略的に決定します。
データ収集の構造を作成する
多くの場合、レッド チーミング データを収集する最も簡単な方法は、Excel スプレッドシートの共有です。 この共有ファイルのメリットは、レッド チーマーが互いの例を確認し、自身のテストに関する創造的なアイデアを得るとともに、データの重複を回避できる点です。
テスト中
レッド チーミングが継続している間はアクティブな状態で待機するように計画する
- 手順やアクセスの問題に関して、レッド チーマーを支援できるように準備してください。
- スプレッドシート上の進行状況を監視し、レッド チーマーに適切なタイミングでリマインダーを送信します。
テストの各ラウンドの後
データを報告する
次の内容を含む短いレポートを主要な利害関係者と定期的に共有します。
特定された上位の問題の一覧。
生データへのリンク。
今後のラウンドのテスト計画のプレビュー。
レッド チーマーを認識できる情報。
その他の関連情報。
特定と測定を区別する
レポートでは、RAI レッド チーミングの役割はリスク サーフェスの顕在化と理解度の向上であり、体系的な測定と厳格な軽減作業を代行するものはないことを明確にしてください。 特定の例を、損害の広がりやすさのメトリックとして解釈しないことが重要です。
さらに、レポートに問題のあるコンテンツと例が含まれている場合は、コンテンツの警告を含めることを検討してください。
このドキュメントのガイダンスは、法的アドバイスを提供することを意図したものではなく、そのように解釈しないでください。 システムが運営されている管轄区域には、AI システムに適用されるさまざまな規制または法的要件がある場合があります。 これらの推奨事項のすべてがあらゆるシナリオに適しているわけではないことに注意してください。逆に、これらの推奨事項は一部のシナリオでは不十分な場合があります。