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