安全性と事実性に関するガイダンス

生成 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 を安全かつ責任ある方法で使用するようにする必要があります。

この評価の一環として、危害が発生する可能性を考慮し、その重大度と軽減策を判断する必要があります。たとえば、事実に基づく出来事に基づいてエッセイを生成するアプリは、エンターテイメント用の架空の物語を生成するアプリと比較して、誤った情報を避けることについてより慎重になる必要があります。潜在的な安全上のリスクを調査する良い方法は、エンドユーザーや、アプリケーションの結果の影響を受ける可能性のあるユーザーを調査することです。これには、アプリの分野における最先端の研究の調査、類似アプリのユーザーの利用状況の観察、ユーザー調査やアンケートの実施、潜在的なユーザーとの非公式なインタビューの実施など、さまざまな形式があります。

安全性と事実性のリスクを軽減するための調整を検討する

リスクを理解したら、リスクを軽減する方法を決定します。どのリスクを優先するか、また、リスクを回避するためにどの程度の対策を講じるべきかを判断することは、ソフトウェア プロジェクトのバグをトリアージするのと同様に、重要な決定です。優先順位を決定したら、最も適切な軽減策の種類について検討を開始できます。多くの場合、簡単な変更でリスクを軽減できます。

たとえば、アプリケーションを設計する際は、次の点を考慮します。

• アプリケーション コンテキストで許容される内容をより適切に反映するようにモデル出力をチューニングします。チューニングにより、モデルの出力の予測可能性と一貫性が高まるため、特定のリスクを軽減できます。
• より安全な出力を実現する入力方法を提供する。LLM に入力する内容によって、出力の品質が大きく変わることがあります。入力プロンプトを試して、ユースケースで最も安全に動作するものを特定することは、その後の UX の提供に役立つため、労力をかける価値があります。たとえば、ユーザーが入力プロンプトのプルダウン リストからのみ選択できるように制限したり、アプリケーション コンテキストで安全に動作することがわかっている説明的なフレーズを含むポップアップ候補を表示したりできます。

• 安全でない入力をブロックし、ユーザーに表示される前に出力をフィルタリングします。シンプルなケースでは、ブロックリストを使用して、プロンプトやレスポンスに含まれる安全でない単語やフレーズを識別してブロックしたり、人間の審査担当者がそのようなコンテンツを手動で変更またはブロックしたりできます。

• トレーニング済みの分類器を使用して、有害となる可能性のある、または敵対的なシグナルを含む各プロンプトにラベルを付ける。こうすると、検出された有害性の種類に応じて、そのリクエストの扱い方について別々の戦略を立てることができます。たとえば、入力が過度に敵対的または罵倒的である場合、ブロックされ、代わりに事前にスクリプト化された回答が出力される可能性があります。

  上級者向けのヒント

  • シグナルによって出力が有害であると判断された場合、アプリケーションは次のオプションを使用できます。
    • エラー メッセージまたは事前にスクリプト化された出力を返します。
    • 同じプロンプトでも異なる出力が生成されることがあるため、別の安全な出力が生成される可能性がある場合は、プロンプトをもう一度試してください。

• 意図的な不正使用に対する保護措置を講じる（各ユーザーに一意の ID を割り当て、特定の期間に送信できるユーザー クエリの量に上限を設けるなど）。もう 1 つの保護対策は、プロンプト インジェクションの可能性に対する保護を試みることです。プロンプト インジェクションは、SQL インジェクションと同様に、悪意のあるユーザーがモデルの出力を操作する入力プロンプトを設計する方法です。たとえば、以前の例を無視するようにモデルに指示する入力プロンプトを送信します。意図的な不正使用について詳しくは、生成 AI の使用禁止に関するポリシーをご覧ください。

• リスクが本質的に低いものに機能を調整する。 範囲が狭いタスク（テキストの抜粋からキーワードを抽出するなど）や、人間による監督が強化されているタスク（人間がレビューするショート フォーム コンテンツを生成するなど）は、リスクが低いことがよくあります。たとえば、メールの返信を最初から作成するアプリケーションを作成する代わりに、概要の展開や言い換えの提案に限定する場合があります。

• 有害なコンテンツの安全性設定を調整して、有害な可能性があるレスポンスが表示される可能性を減らします。Gemini API には、プロトタイピングの段階で調整できる安全性の設定が用意されています。これにより、アプリケーションに対してより厳しいまたは緩い安全性の構成が必要かどうかを判断できます。これらの設定は、5 つのフィルタ カテゴリにわたって調整し、特定の種類のコンテンツを制限または許可できます。Gemini API で使用可能な調整可能な安全性設定については、安全性設定ガイドをご覧ください。

• Google 検索でグラウンディングを有効にすると、事実の不正確さやハルシネーションの可能性を減らすことができます。多くの AI モデルは試験運用版であり、事実と異なる情報を提示したり、ハルシネーションを起こしたり、問題のある出力を生成したりする可能性があることにご注意ください。Google 検索によるグラウンディング機能は、Gemini モデルをリアルタイムのウェブ コンテンツに接続し、利用可能なすべての言語で動作します。これにより、Gemini はより正確な回答を提供し、モデルの知識のカットオフを超えて検証可能なソースを引用できます。

ユースケースに適した安全性テストを実施する

テストは、堅牢で安全なアプリケーションを構築するうえで重要な部分ですが、テストの範囲、スコープ、戦略はさまざまです。たとえば、単なる俳句ジェネレータは、法律事務所が法的文書の要約や契約書の作成に使用するアプリケーションよりも、リスクが低いと考えられます。しかし、俳句ジェネレータはより多くのユーザーが使用する可能性があるため、敵対的な試みや意図しない有害な入力が発生する可能性が高くなります。実装コンテキストも重要です。たとえば、アクションを実行する前に人間の専門家がアウトプットを審査するアプリケーションは、そのような監督がない同一のアプリケーションよりも有害なアウトプットを生成する可能性が低いと見なされる場合があります。

リスクが比較的低いアプリケーションであっても、変更とテストを数回繰り返してからリリースする準備が整ったと確信することは珍しくありません。AI アプリケーションには、次の 2 種類のテストが特に役立ちます。

• 安全性ベンチマークでは、アプリケーションが使用される可能性のあるコンテキストで安全でなくなる可能性のある方法を反映した安全性指標を設計し、評価データセットを使用して、アプリケーションが指標に対してどの程度機能するかをテストします。テストの前に、安全性の指標の最小許容レベルについて検討することをおすすめします。そうすることで、1）テスト結果を期待値と比較して評価できる、2）最も重要な指標を評価するテストに基づいて評価データセットを収集できる、というメリットがあります。

  高度なヒント

  • 「既製の」アプローチに過度に依存しないようにしてください。アプリケーションのコンテキストに完全に適合させるには、人間の評価者を使用して独自のテスト データセットを構築する必要がある可能性が高くなります。
  • 指標が複数ある場合は、変更によって一方の指標が改善され、他方の指標が低下した場合に、どのようにトレードオフするかを決定する必要があります。他のパフォーマンス エンジニアリングと同様に、平均パフォーマンスではなく、評価セット全体の最悪のケースのパフォーマンスに注目することをおすすめします。

• 敵対的テストでは、アプリケーションを積極的に破壊しようとします。目標は、弱点を特定して、必要に応じて対策を講じられるようにすることです。敵対的テストには、アプリケーションの専門知識を持つ評価者の時間と労力がかなり必要になりますが、テストを繰り返すほど、問題（特に、まれに発生する問題や、アプリケーションを繰り返し実行した後にのみ発生する問題）を発見できる可能性が高くなります。

  • 敵対的テストは、悪意のある入力または不注意による有害な入力が与えられた場合に、ML モデルがどのように動作するかを確認するために、ML モデルを体系的に評価するためのメソッドです。
    • 入力が明らかに安全でない、または有害な出力を生成するように設計されている場合、その入力は悪意があるとみなされます。たとえば、テキスト生成モデルに特定の宗教についてヘイトスピーチを生成するよう求める場合です。
    • 入力自体は無害でも、有害な出力を生成する場合（たとえば、テキスト生成モデルに特定の民族の人を説明するように求めて、人種差別的な出力を受け取った場合など）は、不注意による有害な入力とみなされます。
  • 敵対的テストと標準評価の違いは、テストに使用されるデータの構成です。敵対的テストでは、モデルから問題のある出力を引き出す可能性が最も高いテストデータを選択します。つまり、安全性ポリシーに関連するまれな例や異常な例、エッジケースなど、考えられるすべての種類の有害性についてモデルの動作を調査します。また、構造、意味、長さなど、文のさまざまな側面で多様性を含める必要があります。テスト データセットの構築時に考慮すべき事項の詳細については、公平性における Google の責任ある AI の取り組みをご覧ください。

    高度なヒント

    • 従来の「レッドチーム」に人を登録してアプリケーションを破壊しようとする方法ではなく、自動テストを使用します。自動テストでは、レッドチームは、テスト対象のモデルから有害な出力を引き出す入力テキストを見つける別の言語モデルです。

問題をモニタリングする

テストと軽減をどれだけ行っても、完璧を保証することはできません。そのため、発生した問題をどのように特定して対処するかを事前に計画します。一般的なアプローチとしては、ユーザーがフィードバックを共有するためのモニタリング対象チャネル（高評価/低評価など）を設定することや、ユーザー調査を実施してさまざまなユーザーから積極的にフィードバックを収集することなどがあります。特に、使用パターンが想定と異なる場合は、このアプローチが有効です。

次のステップ

• Gemini API で使用できる調整可能な安全性設定については、安全性設定ガイドをご覧ください。
• プロンプトの概要で、最初のプロンプトの作成を開始してください。