大規模言語モデル（LLM）が有用である理由の 1 つは、多種多様な言語タスクに対応できるクリエイティブなツールだということです。残念ながら、これは大規模な言語モデルでは、不適切なテキスト、配慮に欠けるテキスト、事実と異なるテキストなど、予期しない出力が生成される可能性があることも意味します。さらに、これらのモデルの驚くべき汎用性のために、生成される可能性がある望ましくない出力の種類を正確に予測することも困難です。Gemini API は Google の AI に関する原則を念頭に置いて設計されていますが、デベロッパーは責任を持ってこれらのモデルを適用する責任があります。デベロッパーが安全で責任あるアプリケーションを作成できるように、Gemini API には組み込みのコンテンツ フィルタリングと、4 つの有害性の範囲にわたって調整可能な安全設定が用意されています。詳細については、安全性設定のガイドをご覧ください。
このドキュメントでは、LLM の使用時に発生する可能性のある安全上のリスクを紹介し、安全性に関する設計と開発に関する最新の推奨事項を推奨します。（法律や規制によって制限が課せられることもありますが、そのような考慮事項はこのガイドの範囲外です）。
LLM を使用してアプリケーションを構築する場合は、次の手順をおすすめします。
- アプリケーションの安全性に関するリスクの把握
- 安全性のリスクを軽減するための調整を検討する
- ユースケースに適した安全性テストを実施する
- ユーザーからフィードバックを募り、使用状況をモニタリングする
調整フェーズとテストフェーズは、アプリケーションに適したパフォーマンスに達するまで繰り返す必要があります。
アプリケーションの安全性に関するリスクを把握する
ここでいう安全性とは、有害な表現や固定観念を助長するコンテンツを生成するなど、LLM がユーザーに害を及ぼすことを回避する能力と定義されます。Gemini API を通じて利用できるモデルは、Google の AI に関する原則を念頭に置いて設計されています。このモデルの使用には、生成 AI の使用禁止に関するポリシーが適用されます。この API には、有害な表現やヘイトスピーチなど、一般的な言語モデルの問題への対処、インクルーシブネスと固定観念の回避といった一般的な言語モデルの問題への対処に役立つ安全フィルタが組み込まれています。ただし、アプリケーションごとにユーザーに異なるリスクセットをもたらす可能性があります。そのため、アプリケーション オーナーは、ユーザーとアプリケーションが引き起こす潜在的な損害を把握し、アプリケーションが安全かつ責任を持って LLM を使用するようにする責任があります。
この評価の一環として、危害が発生する可能性を考慮し、その重大度と緩和策を決定する必要があります。たとえば、事実に基づくエッセイを作成するアプリは、娯楽のために架空のストーリーを生成するアプリに比べて、誤った情報を避けるように注意する必要があります。潜在的な安全性リスクの調査を始めるには、エンドユーザーや、アプリケーションの結果によって影響を受ける可能性のある他のユーザーを調査することをおすすめします。これには、アプリドメインの最先端の研究の調査、類似アプリの使用状況の観察、ユーザー調査やアンケートの実施、潜在的なユーザーとの非公式のインタビューの実施など、さまざまな方法があります。
高度なヒント
- 潜在的なリスクについてより広い視野を持ち、必要に応じて多様性の基準を調整するために、ターゲット層内の多様な潜在的ユーザーと話します。
- 米国政府の国立標準技術研究所（NIST）がリリースした AI リスク管理フレームワークでは、AI リスク管理に関する詳細なガイダンスと追加の学習リソースを提供しています。
- DeepMind の 言語モデルによる危害の倫理的および社会的リスク に関する出版物では、言語モデルのアプリケーションが害を引き起こす方法について詳しく説明しています。
安全性のリスクを軽減するための調整を検討する
リスクについて理解したら、次はリスクを軽減する方法を決定できます。ソフトウェア プロジェクトのバグのトリアージと同様に、優先順位を付けるべきリスクと、防止するためにどの程度対策を講じるべきかを決定することは、重要な決定です。優先度が決まったら、最適な緩和策を検討します。多くの場合、簡単な変更で違いが生まれ、リスクが軽減されます。
たとえば、アプリケーションを設計する際は、次の点を考慮してください。
- アプリケーションのコンテキストで許容される内容をより良く反映するようにモデル出力をチューニングする。チューニングにより、モデルの出力をより予測しやすく、一貫性のあるものにできるため、特定のリスクを軽減できます。
- より安全な出力を促進する入力方法を提供する。LLM に正確に入力することで、出力の品質に違いが生じる可能性があります。入力プロンプトを試して、ユースケースで最も安全に機能するものを見つけることは、労力に見合うだけの価値があります。それによって、入力プロンプトを容易にする UX を提供できるためです。たとえば、ユーザーが入力プロンプトのプルダウン リストからのみ選択できるように制限したり、アプリのコンテキストで安全に機能することがわかった説明的なフレーズを使ったポップアップの候補を表示したりできます。
安全でない入力をブロックし、出力をユーザーに表示する前にフィルタリングする。単純な状況では、ブロックリストを使用して、プロンプトやレスポンスで安全でない単語やフレーズを特定してブロックできます。また、人間のレビュアーが、このようなコンテンツを手動で変更またはブロックするよう要求することもできます。
トレーニング済みの分類器を使用して、潜在的な有害性や敵対的シグナルで各プロンプトにラベルを付ける。検出された危害の種類に応じて、リクエストの処理方法にさまざまな戦略を採用できます。たとえば、入力が明らかに敵対的または攻撃的である場合は、ブロックされ、代わりにスクリプト化されたレスポンスを出力できます。
高度なヒント
-
シグナルによって出力が有害であると判断された場合、アプリケーションで次のオプションを使用できます。
- エラー メッセージまたは所定の出力を提供します。
- 同じプロンプトでも異なる出力が生成されることがあるため、代替の安全な出力が生成された場合は、プロンプトをもう一度実行してください。
-
シグナルによって出力が有害であると判断された場合、アプリケーションで次のオプションを使用できます。
各ユーザーに一意の ID を割り当て、一定期間内に送信できるユーザークエリの量に上限を設定するなど、意図的な不正使用に対する安全保護対策を講じる。もう 1 つの安全策は、プロンプト インジェクションの可能性から保護することです。プロンプト インジェクションは、SQL インジェクションと同様に、悪意のあるユーザーがモデルの出力を操作する入力プロンプトを設計する方法です。たとえば、以前の例を無視するようにモデルに指示する入力プロンプトを送信します。意図的な不正使用について詳しくは、生成 AI の使用禁止に関するポリシーをご覧ください。
本質的にリスクが低いように機能を調整する。範囲が狭いタスク（テキストの文からキーワードを抽出するなど）や、人間による監視が激しいタスク（人間が確認する短文のコンテンツを生成するなど）では、多くの場合、リスクは低くなります。たとえば、返信メールを一から作成するアプリケーションを作成する代わりに、概要を展開したり、別のフレーズを提案したりするよう制限できます。
ユースケースに適した安全性テストを実施する
テストは、堅牢で安全なアプリケーションを構築するための重要な要素ですが、テストの範囲、スコープ、戦略はさまざまです。たとえば、楽しむための俳句生成ツールは、たとえば法律事務所が法的文書の要約や契約書の草案の作成に使用するアプリケーションよりも重大なリスクは低いと考えられます。ただし、俳句生成ツールは幅広いユーザーが使用する可能性があるため、敵対的試みや意図しない有害な入力が発生する可能性が高くなる可能性があります。実装のコンテキストも重要です。たとえば、なんらかの措置を講じる前に人間の専門家によって出力された出力を含むアプリケーションは、そのような監視のない同一のアプリケーションよりも、有害な出力を生成する可能性が低いと見なされる可能性があります。
リリースの準備ができていると確信する前に、比較的リスクの低いアプリであっても、変更やテストを何度か繰り返すことは珍しくありません。AI アプリケーションでは、次の 2 種類のテストが特に役立ちます。
安全性ベンチマークでは、アプリケーションがどのように使用される可能性があるかというコンテキストにおいて、アプリケーションが安全でないことを反映する安全性指標を設計し、評価データセットを使用して、指標に対するアプリケーションのパフォーマンスをテストします。テストを行う前に、安全性指標の最小許容レベルについて検討することをおすすめします。これにより、1）期待される結果に照らしてテスト結果を評価でき、2）最も重視する指標を評価するテストに基づいて評価データセットを収集できます。
高度なヒント
- アプリケーションのコンテキストに完全に適合させるために、人間の評価者を使用して独自のテスト データセットを構築する必要が生じる可能性があるため、既製のアプローチに過度に依存しないように注意してください。
- 指標が複数ある場合は、ある指標の改善が別の指標に悪影響を及ぼす場合、どのようにトレードオフするかを決定する必要があります。他のパフォーマンス エンジニアリングと同様に、評価セット全体で平均パフォーマンスではなく、最悪のケースのパフォーマンスに注目することをおすすめします。
敵対的テストには、アプリケーションの障害を未然に試みることが含まれます。目標は、弱点を特定して、必要に応じて是正措置を講じられるようにすることです。敵対的テストには、アプリケーションの専門知識を持つ評価担当者が多大な時間と労力を要しますが、やるほど、問題、特にめったに発生しない問題や、アプリケーションの繰り返し実行後にのみ発生する問題を見つける可能性が高くなります。
- 敵対的テストは、悪意のある入力または誤って有害な入力を受け取った場合の動作について学習することを目的として、ML モデルを体系的に評価するための手法です。
- 安全でない、または有害な出力を生成するように入力が明らかに設計されている場合（たとえば、特定の宗教についての差別的な怒りを生成するようテキスト生成モデルに要求するなど）、その入力は悪意のある可能性があります。
- 入力自体は無害でも、有害な出力を生成する場合、入力が誤って有害になります。たとえば、テキスト生成モデルに特定の民族の人物の説明を要求し、人種差別的な出力を受け取る場合などです。
- 敵対的テストと標準評価の違いは、テストに使用されるデータの構成です。敵対的テストでは、モデルから問題のある出力を引き出す可能性が高いテストデータを選択します。これは、安全性ポリシーに関連するまれな例や異常な例、エッジケースなど、起こりうるすべての種類の害についてモデルの動作を精査することを意味します。また、構造、意味、長さなど、文のさまざまな次元の多様性も含める必要があります。テスト データセットを構築する際に考慮すべき点の詳細については、公平性に関する Google の責任ある AI への取り組みをご覧ください。
高度なヒント
- 「レッドチーム」のメンバーにアプリケーションの問題を試すように促す従来の方法ではなく、自動テストを使用します。自動テストにおける「レッドチーム」は、テスト対象のモデルから有害な出力を引き出す入力テキストを検出するもう 1 つの言語モデルです。
- 敵対的テストは、悪意のある入力または誤って有害な入力を受け取った場合の動作について学習することを目的として、ML モデルを体系的に評価するための手法です。
問題をモニタリングする
どれほどテストして軽減したとしても、完璧を保証することはできません。発生する問題を特定して対処する方法を前もって計画しましょう。一般的なアプローチには、ユーザーがフィードバックを共有するためのモニタリング対象チャネル（高評価/低評価など）を設定し、さまざまなユーザーからフィードバックを積極的に求めるユーザー調査の実施があります。これは、使用パターンが期待と異なる場合に特に役立ちます。
高度なヒント
- ユーザーが AI プロダクトにフィードバックを提供すると、たとえばプロンプト調整に適したサンプルを選択できるようになるなど、AI のパフォーマンスとユーザー エクスペリエンスは時間の経過とともに大きく改善されます。Google の人材と AI のガイドブックのフィードバックと管理の章では、フィードバック メカニズムを設計する際に考慮すべき重要な考慮事項について説明しています。