ジェネレーティブ AI の敵対的テスト

敵対的テストは、悪意のある入力や意図せず有害な入力が与えられた場合にそれがどのように動作するかを学習することを目的に、ML モデルを体系的に評価する方法です。このガイドでは、ジェネレーティブ AI の敵対的テスト ワークフローの例について説明します。

敵対的テストとは

テストは、堅牢で安全な AI アプリケーションを構築するための重要な要素です。敵対的テストでは、問題のある出力を引き出す可能性が高いデータをアプリケーションに提供することで、アプリケーションの破壊を積極的に試みます。敵対的なクエリにより、モデルが安全でない方法で失敗する(安全ポリシー違反)可能性があります。また、人間が認識するのは簡単ですが、機械には認識しにくいエラーが発生する可能性があります。

クエリはさまざまな方法で「敵対的」になる可能性があります。明らかに敵対的なクエリには、ポリシーに違反する言葉が含まれていることや、ポリシーに違反する視点が表現されていることがあります。また、モデルを危険にさらしたり、有害または不適切と表現したりすることもあるでしょう。暗黙的に敵対的クエリは無害に見えるかもしれませんが、論争や文化的な問題、または有害となる可能性があるデリケートなトピックは含まれている可能性があります。これには、ユーザー属性、健康、金融、宗教に関する情報が含まれる場合があります。

敵対的テストでは、現在の障害を公開して微調整、モデルの安全保護対策、フィルタなどの緩和策を実施することで、モデルとプロダクトを改善できます。さらに、モデルの出力がポリシーに違反する可能性など、軽減される可能性のあるリスクを測定することで、プロダクトのリリースを判断できます。

このガイドでは、責任ある AI の新しいベスト プラクティスとして、生成モデルとシステムの敵対的テストのワークフロー例を示します。

敵対的テストのワークフロー例

敵対的テストは、標準モデルの評価と同様のワークフローに従います。

入力の特定と定義

攻撃者テスト ワークフローの最初のステップは、意図的かつ体系的な攻撃を受けたときのシステムの動作を把握するための入力を決めることです。よく考えた入力は、テスト ワークフローの有効性に直接影響します。次の入力は、敵対的テストのスコープと目標を定義するのに役立ちます。

  • プロダクト ポリシーと障害モード
  • ユースケース
  • ダイバーシティ要件

プロダクト ポリシーと障害モード

ジェネレーティブ AI プロダクトでは、プロダクトの動作と許可されない(安全でない)モデル出力を表現する安全ポリシーを定義する必要があります。ポリシーには、ポリシー違反とみなされる障害モードを列挙する必要があります。この障害モードのリストは、敵対的テストのベースとして使用する必要があります。障害モードの例として、冒とく的な言葉や、経済的、法律的、医学的なアドバイスを含むコンテンツなどがあります。

ユースケース

敵対的テストへの重要な入力事項は、生成モデルまたはプロダクトが提供しようとしているユースケースです。これにより、テストデータには、ユーザーが現実世界でプロダクトとやり取りする方法が示されます。どの世代のプロダクトでもユースケースは多少異なりますが、一般的な例としては、言語モデルのファクト検出、要約、コード生成、地理や地形、アート、衣類スタイルによる背景の画像生成などがあります。

ダイバーシティ要件

攻撃者のテスト データセットは、ターゲットの障害モードとユースケースに関して十分に多様性があり、代表的なものにする必要があります。テスト データセットの多様性を測定することで、潜在的なバイアスを識別し、多様なユーザー集団を念頭に置いてモデルのテストを詳細に行うことができます。

ダイバーシティに関する 3 つの考え方:

  • 語彙の多様性: クエリにはさまざまな長さ(単語カウントなど)を持たせ、幅広い語彙を使用し、重複が含まれず、さまざまなクエリ形式(wh 質問、直接リクエストと間接リクエストなど)を表すようにします。
  • セマンティックの多様性: デリケートなユースケースやアイデンティティに基づく特性(性別、民族など)を含め、ポリシーごとにさまざまなユースケースやグローバル コンテキストで広範囲のトピックをクエリできるようにします。
  • ポリシーとユースケースの多様性: クエリがすべてのポリシー違反(ヘイトスピーチなど)とユースケース(エキスパートによるアドバイスなど)を網羅している。

テスト データセットを検索または作成する

敵対的テストのテスト データセットの構成は、標準のモデル評価テストセットとは異なります。標準的なモデル評価では、テスト データセットは通常、モデルがプロダクトで遭遇するデータの分布を正確に反映するように設計されています。敵対的テストの場合、テストデータは、安全ポリシーに関連する分布外のサンプルとエッジケースでモデルの動作を証明することで、モデルから問題のある出力を引き出すために選択されます。高品質な敵対的テストセットは、すべての安全ポリシーのディメンションをカバーし、モデルがサポートしようとしているユースケースを最大限にカバーする必要があります。語彙は多様である(さまざまな長さや言語のクエリなど)と同時に、意味論的である(異なるトピックやユーザー層を対象とするなど)必要があります。

既存のテスト データセットを調査して、安全ポリシー、障害モード、テキスト生成モデルとテキストから画像モデルまでのユースケースをカバーします。チームは、既存のデータセットを使用してプロダクトのパフォーマンスのベースラインを確立し、プロダクトが使用している特定の障害モードについてより詳細に分析できます。

既存のテスト データセットが不十分な場合、チームは特定の障害モードとユースケースをターゲットとする新しいデータを生成できます。新しいデータセットを作成する 1 つの方法は、クエリの小さなデータセット(カテゴリごとに数十の例)を手動で作成してから、データ合成ツールを使用してこの「シード」データセットを拡張することです。

シード データセットには、本番環境で発生するものと似た、似たようなサンプルを含めて、ポリシー違反を引き出すことを目的とします。有害性の高い言語は安全機能によって検出される可能性が高いため、クリエイティブの表現や暗黙的に敵対的な入力を検討してください。

テスト データセットでは、機密性の高い属性(年齢、性別、人種、宗教など)を直接または間接的に参照することができます。これらの用語の使用は文化によって異なることに留意してください。さまざまなトーン、文の構造、長さの選択、意味。複数のラベル(ヘイトスピーチとわいせつなど)が適用される場合、ノイズと重複が発生し、評価システムまたはトレーニング システムで適切に処理されない場合があります。

敵対的なテストセットを分析して、語彙とセマンティックの多様性、ポリシー違反とユースケースを網羅する構成、一意性、敵対性、ノイズの観点から全体的な品質を理解する必要があります。

モデル出力を生成する

次のステップでは、テスト データセットに基づいてモデル出力を生成します。この結果は、悪意のあるユーザーに公開されたり、誤って有害な情報が入力されたときのモデルのパフォーマンスをプロダクト チームに報告します。これらのシステムの動作と応答のパターンを特定すると、将来のモデル開発で軽減できるベースライン測定値を提供できます。

出力にアノテーションを追加する

敵対的テストからの出力が生成されたら、それにアノテーションを付けて、障害モードと損害の両方または両方に分類します。これらのラベルは、テキスト コンテンツや画像コンテンツの安全性シグナルを提供します。さらに、これらのシグナルにより、複数のモデルとプロダクトで損害を測定し、その影響を軽減できます。

安全性分類器を使用すると、ポリシー違反の出力(または入力)に自動的にアノテーションを付けることができます。ヘイトスピーチなど、厳密に定義されていない構成要素を検出しようとする場合、精度が低くなる可能性があります。これらのシグナルでは、評価者が「不確定」な分類器生成ラベルを確認して修正することが重要です。

自動アノテーションに加え、評価者がデータのサンプルにアノテーションを付けることもできます。敵対的なテストの一環としてモデルの出力にアノテーションを付けるには、手動のコンテンツ管理と同様に、問題のある有害なテキストや画像を調べる必要があることに留意してください。また、評価者は、個人的なバックグラウンド、知識、信念に基づいて、同じコンテンツに対して異なるアノテーションを付ける場合があります。評価者のプールの多様性がアノテーションの結果に影響を与える可能性があることに留意し、評価者向けのガイドラインまたはテンプレートを作成することが有効です。

報告と緩和

最後に、テスト結果をレポートでまとめてみます。指標を計算し、結果を報告して、安全率、可視化、問題のある障害の例を提供します。この結果は、モデルの改善に役立ち、フィルタやブロックリストなどのモデルの安全保護対策に役立ちます。レポートは、関係者や意思決定者とのコミュニケーションにも重要です。

その他のリソース

Google の AI レッドチーム: 倫理的なハッカーが AI をより安全に

レッドチーム チーミング モデルと言語モデル

機械学習デベロッパー向けのプロダクト公平性テスト(動画):

デベロッパー向けのプロダクト公平性テスト(Codelab)