コンテンツへスキップ
OpenTrain AIAI企業向け

評価データ問題としてのAIレッドチーミング

OpenTrain AI 2 分
Illustration of AI red teaming as a structured evaluation-data workflow, with prompts, reviewer notes, and tagged cases rather than a generic cybersecurity scene.

AIレッドチーミングは、敵対的検証による発見が、脅威モデル、ルーブリック、判定、リーク制御、ルーティングの決定といった再現可能な評価データとなる場合に役立ちます。

AIにおけるレッドチーミングとは、本当のところ何なのでしょうか？

すでにLLMの評価を実行している場合、役立つ答えは「モデルのジェイルブレイクを試みること」ではありません。役立つ答えは、証拠を生み出す構造化された敵対的発見です。AIのレッドチーミングは、より優れた評価データ、拒否テスト、有害性ルーブリック、およびリリース決定の設計に役立つ場合に重要になります。バイラルプロンプトのギャラリーになってしまうと、その重要性は低下します。[1]

この分野ではいくつかの関連用語が曖昧に使われているため、この区別は重要です。従来のサイバーレッドチーミングは、企業のセキュリティ態勢に対する敵対者のエミュレーションです。AIレッドチーミングは、AIシステムの欠陥や脆弱性を発見するための構造化された取り組みであり、多くの場合、開発者とのコラボレーションを伴います。評価（eval）はより狭義です。システムに入力を与え、採点ロジックを適用し、目的の動作をしたかどうかを測定します。安全性テストと展開前のTEVVはより広範な概念であり、レッドチーミング、フィールドテスト、パブリックフィードバック、および正式な評価を含めることができます。[1]

AIレッドチーミングがサイバーレッドチーミングや標準的な評価とどのように異なるか。

プラクティス分析単位目標典型的な出力避けるべき誤った推論
サイバーレッドチーム組織、ネットワーク、製品、またはセキュリティプログラム。セキュリティ態勢に対する敵対者をエミュレートする。攻撃経路、エクスプロイトのシナリオ、修復リスト。サイバー演習が自動的にAI評価になるわけではない。
AIレッドチーミングAIモデル、アプリケーション、スキャフォールド、または展開サーフェス。欠陥、脆弱性、および有害な動作を発見する。調査結果、プロンプト、トランスクリプト、重大度のメモ。バイラルなジェイルブレイクが自動的に信頼できる測定になるわけではない。
モデル評価定義された入力、システムセットアップ、採点者、および指標。指定されたハーネスの下でターゲットの動作が発生するかどうかを測定する。スコア、ラベル、信頼区間、エラースライス。評価スコアは、そのハーネスがサポートできる主張のみを裏付ける。
安全性テストとTEVV証拠と保証活動のライフサイクル全体。テスト、フィールドの証拠、リスクのしきい値、およびレビューを組み合わせる。リスク登録簿、受入証拠、監視計画。レッドチームのラウンド単独では、システムが安全であることを証明できない。

NISTおよびモデル評価ガイダンスから統合された定義。

そのため、デモ用のジェイルブレイクはガバナンスの単位としては脆弱です。NISTは、ジェイルブレイクやプロンプトエンジニアリングのテストでは、妥当性や信頼性を体系的に評価できない可能性があると警告しています。Microsoftは、レッドチーミングを体系的な測定の代替としてではなく、有害性を明らかにし、リスクサーフェスを理解するための方法として位置づけています。AISIも評価者の立場から同じ指摘をしています。探索的テストは懸念事項の兆候を示すことができますが、より強力な主張を行うには、より優れた引き出し（elicitation）、採点、および結果とリスクのしきい値の間のマッピングが必要です。[2]

実践的な目標はシンプルです。発見したものを、リプレイ、ラベル付け、監査、およびルーティング可能なケースに変換することです。

脅威モデルを最初に、ジェイルブレイクギャラリーを最後に

レッドチームプログラムが「モデルを壊しに行け」と人々に求めることから始まる場合、通常、多彩な例と弱い測定結果が生み出されます。順序を逆にしてください。能力の引き出し、セーフガードの堅牢性、または共有セットアップ下でのシステム間の比較など、証拠が裏付けるべき主張を述べることから始めます。次に、その主張を意味のあるものにするハーネス、ツール、および予算を定義します。

OpenAIのサードパーティ評価ガイダンスは、この点について直接的です。スコアは、セットアップがどのような主張を裏付けているか、システムがどのように引き出されたか、およびどのような妥当性チェックが実行されたかをレポートが説明している場合にのみ解釈可能です。[3]

AIレッドチームの脅威モデルは、アクター、ターゲットの行動、アタックサーフェス、および下流の被害を特定する必要があります。AISIは、評価は明示的なリスクモデルに合わせ、被害に至る関連経路をカバーすべきであると主張しています。Microsoftは、アクター、戦術、弱点、および下流への影響を追跡する内部オントロジーについて説明しています。これは、生の発見事項は共有構造なしでは推論するにはあまりにも乱雑であるためです。[4]

ほとんどのチームにとって、「アタックサーフェス」はプロンプトボックスにとどまるべきではありません。デプロイされたシステムに検索、ツール、長いコンテキスト、マルチモーダル入力、コネクタ、またはエージェントの足場がある場合、それらのサーフェスはスコープに含まれます。ハーネスはシステムができることを変えます。OpenAIは、周囲の足場が、特にエージェントシステムにおいて、パフォーマンスを実質的に変える可能性があることを強調しています。Microsoftも同様に、可能であれば理想的には本番環境のUIを通じて、ベースモデルとアプリケーション層の両方をテストすることを推奨しています。[3][5]

ここからプロンプトのみの劇場が始まります。つまり、機能が削ぎ落とされたチャットエンドポイントに対してユーザーテキストをテストし、その結果をデプロイされた製品に関する証拠として扱うことです。これにより、間接的なプロンプトインジェクション、安全でないツールの使用、ステートフルなマルチターンのエスカレーション、検索に依存する障害、および環境固有の動作を見逃す可能性があります。問題は、プロンプトのみのテストが役に立たないということではありません。問題は、それらがシステム全体を測定したかのように扱うことです。

脅威モデルからプローブ、発見事項、裁定されたケース、評価またはトレーニングのルーティングに至る5ステップのフロー。
レッドチームは、発見事項が評価データ層を通じてルーティングされるときに役立ちます。 NIST AI RMF、OpenAI評価ガイダンス、AISI方法論、およびMicrosoft計画ガイダンスから統合されたワークフロー。

サンプリング、重大度、および裁定

サンプリングは、レッドチームが評価設計になる場所です。Googleは、製品ポリシー、ユースケース、障害モード、語彙の多様性、および意味の多様性にわたる、多様で代表的な入力を推奨しています。Microsoftは、被害を発見するための自由形式のテストから始め、次に進化する被害リストに基づいたガイド付きラウンドに移行することを推奨しています。実際には、サンプルは公開されているジェイルブレイクのリストといくつかの即興のプロンプトであってはなりません。それは、被害カテゴリ、ユーザーの意図、サーフェス、言語、およびもっともらしい引き出し戦略にわたる計画的なスライスであるべきです。[6]

重大度も、プログラムをスケールさせる前に構造化する必要があります。NISTは、リスクを可能性と結果の組み合わせとして組み立てています。レッドチームのラベリングにとって、それは出発点であり、完成したルーブリックではありません。ほとんどのチームは、被害の種類、実行可能性、再現性、現実味、および通常のセーフガード後も動作が持続するかどうかなどの次元も必要とします。このルーブリックは、引用された標準ではなく、NISTのリスクフレーミングと評価の実践に基づいた編集上の統合です。[2]

裁定は、チームが静かに失敗することが多い場所です。Googleは、人間が厄介なコンテンツに異なるアノテーションを付ける可能性があることを指摘し、評価者向けの明確なガイドラインまたはテンプレートを推奨しています。OpenAIは、複数のレビュー担当者が使用される場合、明確なルーブリック、スコアレベルの例、合否のしきい値、およびコンセンサスの集約を推奨しています。重大度が高いケースやポリシーが曖昧なケースでは、人間の意見の不一致を単なるアノテーターのノイズとしてではなく、測定システムに関するシグナルとして扱います。[6][7]

役立つ運用ルールは次のとおりです。発見事項の重大度が高い、ポリシーが曖昧である、またはドメインに特化している場合は、単一レビューのラベリングから専門家の裁定にエスカレーションします。モデルがポリシーに違反したかどうかについてレビュー担当者の意見が一致しない場合、そのケースは通常、ポストトレーニングを推進する前にルーブリックの改訂を推進する必要があります。この推奨事項は統合されたものですが、ルーブリックの明確さ、キャリブレーション、および人間のレビューに関する引用されたガイダンスに従っています。

意図的に人間と自動化の作業を分割する

自動化は、仕事が幅広さ、更新、および弱いシグナルの検出である場合に最も役立ちます。Anthropicのモデル作成による評価作業は、モデルが関連する多くの評価項目を迅速に生成するのに役立ち、その設定におけるラベルに対するクラウドワーカーの同意が高いことを示しました。AISIは、自動化された能力評価は、懸念される能力サーフェスの大部分をカバーするのに十分なスケーラビリティがあると主張しています。Googleも、既存のデータセットが不十分な場合は、シードの例から始めて合成的に拡張することを推奨しています。[8][4][6]

同じ情報源は限界も定義しています。AISIは、自動テストは現実世界の使用状況を反映しておらず、それ自体で強力な結論を裏付けるべきではないと述べています。Googleは、大まかに定義された構成要素では分類器の精度が低くなる可能性があると警告しています。OpenAIは、評価にはスコア以上のものがあるとし、人間の判断に対して自動スコアリングを調整することを推奨しています。[4][6][7]

自動化されたプローブは3つの点で強力です。第一に、少人数の人間のチームが作成できるよりも多くの語彙的および意味的バリエーションを生成することで、カバレッジを向上させます。第二に、ケースが再利用可能な評価になると、回帰テストが安価になります。第三に、チームが繰り返しサンプリングを行って大規模にシステムを攻撃できるようになります。これは、一部のジェイルブレイククラスが試行回数を増やすことで改善されるため重要です。Anthropicのメニーショットの作業は、長いコンテキストが新しい障害モードを生み出す一例です。[9]

ツールは現在、この分業を反映しています。Microsoft PyRITは、マルチモーダルシステムを調査し、構成可能なレッドチームのビルディングブロックを再利用するためのモデルに依存しないフレームワークです。AISI Inspectは、マルチターンのダイアログ、エージェントの足場、モデルの採点、および詳細なログをサポートしています。レッドチームの発見事項は、バラバラのメモではなく、分析可能な評価アーティファクトになる必要があるため、これらのツールは役立ちます。[10][11]

「ポリシーは失敗したか？」だけでなく「ここで実際に重要なのは何か？」が問われる場合、人間は依然として必要です。Microsoftは直接的です。医療、サイバーセキュリティ、CBRN、異文化間の被害、および心理社会的被害には、主題に関する判断が必要です。AISIも同様に、専門家によるレッドチームは自動テストよりも自然主義的で自由形式であると説明しています。[12][4]

LLMの審査員にも同じ懐疑論が必要です。OpenAIは、審査員モデルが回答の順序や回答の長さに偏る可能性があるため、ペアワイズまたは合否の形式、明確なルーブリック、および人間のラベルに対する検証を推奨しています。LLMの審査員は測定機器のように使用してください。キャリブレーションを行い、ドリフトがないか確認し、定期的に監査します。専門的な被害や曖昧なポリシーの境界について、彼らに最終的な権限を与えないでください。[7]

自動化が役立つ領域と、人間が依然として重要である領域。

方法最適な用途主な利点主な盲点人間のレビューが必要か？
自動化されたプローブ既知の戦術にわたる幅広い反復試行。カバレッジと更新の頻度をスケールさせます。現実的な製品コンテキストやドメインの害を見逃す可能性があります。はい、深刻なケースや曖昧なケースに適用されます。
モデル生成のバリエーション表現や意味論全体にシードの例を拡張します。語彙的および意味論的に近いものを迅速に見つけます。簡単なバリエーションに過学習する可能性があります。はい、ラベルのキャリブレーションと新規性のチェックに適用されます。
分類器大量の出力の事前スクリーニング。安価なトリアージと監視。緩い構成では精度が低くなります。はい、ポリシーと深刻度の決定に適用されます。
LLMの判定明確なルーブリックを使用した合否判定またはペアワイズスコアリング。キャリブレーションされた場合の高速で再利用可能なスコアリング。順序、長さ、スタイル、およびドメインのバイアス。はい、定期的な人間の監査を伴います。
スクリプト化された回帰スイートモデルやポリシーの変更後に既知のケースを再実行します。安定したリプレイと差分比較。過去の障害モードを測定します。はい、回帰のリスクが高い場合に適用されます。
人間のドメイン専門家医療、セキュリティ、CBRN、文化的、法的、または心理社会的危害。コンテキストと結果の判断。スループットが制限され、ルーブリックがないと意見の不一致が生じます。これらがレビューの経路となります。

AISIの階層化、Googleの敵対的テスト、OpenAIの評価実践、Anthropicのモデル作成による評価、およびMicrosoftのレッドチームの教訓に基づいています。

優れた運用上の役割分担はシンプルです。自動化によって、攻撃候補の生成、シードセットの拡張、明らかなケースの事前ラベル付け、重複のクラスタリング、回帰の再実行を行います。人間は、危害リストの定義、不確実または深刻なケースのレビュー、判定品質の監査、システム障害が製品やモデルにとって何を意味するかの解釈を行います。この役割分担は、上記のソースに基づいた統合です。

発見を逸話ではなくデータオブジェクトとして扱う

レッドチームの出力を再利用可能な評価データにする必要がある場合は、プロンプトと最終的な回答以上のものを記録してください。Microsoftは、少なくとも表面化した日付、一意の識別子、入力プロンプト、および出力の詳細を記録することを推奨しています。Googleは、出力を障害モードと危害に注釈付けすることを推奨しています。Inspectのログモデルは、より成熟した表現によって保存できるものを示しています。入力、サンプルのメタデータ、スコア、エラー、メッセージ、および複数の粒度レベルでのイベントトレースです。[5][6][11]

応用チームにとって、最小限の有用なスキーマは通常より大きくなります。プロンプトと応答に加えて、モデルのバージョン、システムプロンプトのバージョンまたはハッシュ、ツールの構成、検索コンテキストまたは参照、攻撃手法、ポリシーカテゴリ、拒否ステータス、レビュアーのラベル、深刻度のラベル、根拠、裁定ステータス、ケースクラスター、およびルーティングステータスを保持します。この正確なフィールドリストは統合されたものですが、構造化されたキャプチャ、メタデータ、およびスコアリングに関する現在のガイダンスの実用的な拡張です。

重複の処理は、ほとんどのチームが予想する以上に重要です。Googleは、敵対的データセットを生成する際に、重複やノイズの多いマルチラベルの例を避けることを推奨しています。重複排除を行わないと、「上位の障害モード」が少数のバイラルな攻撃テンプレートに集約されることが多く、それが緩和作業とトレーニングデータの両方にバイアスをかけます。標準的なケースとパラフレーズクラスターの概念を維持し、生のカウントと一意の攻撃ファミリーのカウントの両方を報告してください。標準とクラスターの推奨事項は統合されたものですが、一意性と慎重な構成の必要性はGoogleのガイダンスから直接得られたものです。[6]

評価およびポストトレーニングループ用の再利用可能なレッドチームケーススキーマ。

フィールド重要な理由トレーニングに安全か？ホールドアウトに安全か？備考
ケースIDレビュー、再実行、および修正の追跡可能性を維持します。はいはい安定したIDは、言い換えのクラスタリング後も維持される必要があります。
プロンプト/入力引き出しのアーティファクトを定義します。場合によるはい正確なホールドアウトプロンプトが、後でトレーニング例になるべきではありません。
モデル出力観察された動作を記録します。場合によるはい拒否、部分的な完了、およびツール出力を含めます。
モデルバージョン変更されるシステム間での誤った比較を防ぎます。はいはいモデル、チェックポイント、および関連するリリースチャネルを記録します。
システムプロンプトハッシュ機密情報を公開することなく、動作を指示にリンクさせます。はいはいプロンプトが機密である場合は、ハッシュまたは制御された参照を使用します。
ツール/検索コンテキストデプロイされたハーネスが利用可能にしたものを示します。場合によるはいRAG、ツールの使用、長いコンテキスト、およびエージェントのテストに不可欠です。
攻撃手法カバレッジと重複排除をサポートします。はいはい例として、直接的なジェイルブレイク、間接的なインジェクション、ロールプレイ、マルチターンのエスカレーションなどが挙げられます。
ポリシーカテゴリ発見事項をルーブリックに結び付けます。はいはい判定によって曖昧さが明らかになった場合は、カテゴリを修正します。
拒否ステータス安全でない要求への同意と過剰な拒否を区別します。はいはいすべての拒否を成功として一括りにしないでください。
レビュアーラベル人間、または調整されたジャッジによる決定を定義します。はいはいレビュアーのタイプと調整状態を追跡します。
重大度修正とリリースゲートの優先順位を決定します。はいはい重大度の次元は総合的な評価であり、普遍的な基準ではありません。
根拠後日の監査を可能にします。はいはい不透明なクラスラベルよりも、短い根拠を示す方が優れています。
判定ステータス単一レビューのラベルと解決済みのケースを分離します。はいはい重要度が高いケースや議論のあるケースは、エスカレーションが必要です。
クラスターID重複するプロンプトがレポートを独占するのを防ぎます。はいはい生のカウントと固有の攻撃ファミリーのカウントを個別にレポートします。
ルーティングステータストレーニングと測定の間のリークを防ぎます。はい（トレーニングにルーティングされる場合）はい（ホールドアウトとしてブロックされる場合）可能な状態には、トレーニング候補、評価ケース、ブロックされたホールドアウト、ルーブリックの改訂、またはリリースエビデンスが含まれます。

フィールドリストはツールのドキュメントと運用ガイダンスを組み合わせたものです。トレーニング/ホールドアウトのルーティングは編集上の統合です。

トレーニングを行う前に、各発見事項の扱いを決定する

これは運用上の核心となる問題であり、最初のポストトレーニング会議の前にその答えを書き留めておく必要があります。

レッドチームのケースは、少なくとも5つの異なるもの（トレーニング例、再利用可能な評価ケース、ブロックされたホールドアウト、ポリシーやルーブリックの改訂、またはリリースゲートのエビデンス）になり得ます。現在の主要な情報源は、これらを1つの標準的なワークフローにまとめていないものの、これらの個別のレーンの必要性を支持しています。OpenAIは、評価データを強化学習のファインチューニングにリークさせないよう警告し、定期的に更新される本番環境由来の評価について説明し、汚染や報酬ハッキングなどの妥当性に関する危険性を強調しています。AISIも同様に、モデルのライフサイクル全体にわたる事前定義されたしきい値と反復テストを主張しています。[13][14][3][4]

ラベルが安定しており、失敗が現実的な使用を代表するものであり、ポリシーの境界が明確で、その例が将来の測定用に予約されていない場合、そのケースは妥当なトレーニング候補となります。Anthropicの初期のレッドチームの取り組みでは、安全手法にレッドチームのデータを使用することで、調査対象の攻撃コーパスに対する脆弱性が低下することがわかりました。そのため、チームはすべてをトレーニングに使用したくなります。また、これがリーク制御が重要である理由でもあります。同じケースが後で進捗のエビデンスとして使用された場合、測定が損なわれるためです。[15]

ホールドアウトとして必要な場合、公開ベンチマークや将来のベンチマークに似ている場合、ラベルに議論がある場合、またはエクスプロイトが非常にケース固有であり、それについてトレーニングすると主にモデルにパッチを記憶させることになる場合は、ケースをトレーニングから除外してください。AnthropicのBrowseComp汚染に関するメモは、公開リークがどのように結果を水増しするかを示しており、OpenAIのSWE-bench Verified分析は、ベンチマーク規模で同じ失敗パターンを示しています。どちらのケースでも、教訓は同じです。同じ成果物をトレーニング資料と正確な測定エビデンスの両方にすることはできません。[16][17]

実用的なルーティングルール：ケースが新しい失敗モードを明らかにした場合、まずそれをホールドアウトバケットにブロックします。ホールドアウトを更新し、新しいケースで修正を証明した後にのみ、その失敗パターンのバリアントをトレーニングに移行することを検討する必要があります。このルールは統合されたものですが、プロバイダーや評価者の情報源からの現在のリークガイダンスを尊重しています。

安全性を保証するふりをしない、小規模チームの運用モデル

小規模なAIチームにとって、目標は「すべてを網羅する」ことではありません。目標は、モデルが変更された後でも信頼できるエビデンスを生み出すループを作成することです。

展開に関連する1つの具体的な脅威モデル、1つの狭い製品サーフェス、および1回の手動による発見ラウンドから始めます。可能であれば多様なテスターを使用しますが、少なくともドメインの害を理解している人と、システムインターフェースについて敵対的に考えることができる人を含めてください。Microsoftは、多様なテスターと、害や機能への明示的な割り当てを推奨しています。Googleは、シード例から始めて慎重に拡張することを推奨しています。OpenAIは、評価を早期に構築し、すべてをログに記録し、人間のラベルで自動化を調整することを推奨しています。[5][6][7]

次に、信頼性の高い発見事項の最初のトランシェを、ホールドアウトされた敵対的評価セットとして凍結します。それらの正確なケースでファインチューニングを行わないでください。たとえグレーダーが人間の監査による合否判定であっても、それらを中心にシンプルな回帰実行を構築します。それが機能したら、トレーニング候補用の2つ目のレーンを追加し、分割をクリーンに保ちます。OpenAIの評価ガイダンスでは、ポストトレーニングループにおけるホールドアウトデータ、重複の排除、および個別のトレーニングセットが繰り返し強調されています。[13][7]

その後、自動化は労力をかける価値があります。モデル生成による拡張、分類器、またはLLMジャッジを使用して、カバレッジを広げ、レビューコストを削減しますが、それは正しいラベルが何を意味するかを確立した領域に限られます。AISIの階層型アプローチは有用なテンプレートです。より軽量な自動テストで懸念事項を迅速に見つけ、シグナルが重要な場合は、カスタマイズされた引き出しと専門家によるレビューにエスカレーションします。[4]

これらはどれもシステムが安全であることを証明するものではありません。それは誤った約束です。優れたレッドチームのループは、再現可能なケース、防御可能なラベル、トレーニングに使用しなかったホールドアウト、そして緩和策がモデルを変更したのか、単にデモのプロンプトにパッチを当てただけなのかを判断するのに十分な構造を提供します。

OpenTrainは、チームがその作業のためにレッドチームメンバー、ドメインレビュアー、および評価スペシャリストを採用するのを支援します。評価者の調整にはLLMジャッジの信頼性リファレンスを、自動化の境界についてはRLAIFとRLHFのガイドを、測定ターゲットの設計にはPRMとORMのリファレンスを、レビューループの計画にはRLHFスコーピングガイドを使用してください。レビューループの人員配置がボトルネックになっている場合は、求人を投稿してください。

出典

このページ

この記事を共有：