Amazon Web Services ブログ
Amazon Bedrock Guardrails を使用したモデルに依存しない安全対策を実装する
この記事は、「Implement model-independent safety measures with Amazon Bedrock Guardrails」を翻訳したものとなります。
生成 AI モデルは幅広いトピックに関する情報を生成できますが、その応用には新たな課題があります。これには関連性の維持、有害なコンテンツの回避、個人を特定できる情報(PII)などの機密情報の保護、ハルシネーション(幻覚)の軽減が含まれます。Amazon Bedrock の基盤モデル(FM)には組み込みの保護機能がありますが、これらはモデル固有であることが多く、組織のユースケースや責任ある AI の原則に完全に合致しない可能性があります。その結果、開発者は多くの場合、追加のカスタマイズされた安全性とプライバシーの制御を実装する必要があります。このニーズは、組織が複数の FM を異なるユースケースで使用する場合により顕著になります。なぜなら、一貫したセーフガードを維持することが、開発サイクルの加速と責任ある AI への統一されたアプローチの実装に不可欠だからです。
2024 年 4 月、私たちは Amazon Bedrock Guardrails の一般提供を発表しました。これはセーフガードの導入、有害なコンテンツの防止、主要な安全性基準に対するモデルの評価を支援するものです。Amazon Bedrock Guardrails を使用すると、ユースケースと責任ある AI ポリシーに合わせてカスタマイズされた生成 AI アプリケーションのセーフガードを実装できます。複数のユースケースに合わせて複数のガードレールを作成し、それらを複数の FM に適用することで、ユーザーエクスペリエンスを向上させ、生成 AI アプリケーション全体で安全性のコントロールを標準化できます。
さらに、異なる FM を使用するアプリケーションの保護を可能にするために、Amazon Bedrock Guardrails は現在、Amazon Bedrock 外で利用可能なカスタムおよびサードパーティの FM のユーザー入力とモデル応答を評価するための ApplyGuardrail API をサポートしています。この記事では、サードパーティまたはセルフホスト型の大規模言語モデル(LLM)、あるいはセルフホスト型の検索拡張生成(RAG)アーキテクチャなど、一般的な生成 AI アーキテクチャで ApplyGuardrail API
を使用する方法について説明します。
ソリューションの概要
この記事では、FM が受託者向けのアドバイスを提供しないようにするガードレールを作成します。ガードレールの完全な設定リストは GitHub リポジトリをご覧ください。必要に応じてコードを変更できます。
前提条件
Amazon Bedrock Guardrails を使用するための正しい AWS Identity and Access Management(IAM)権限があることを確認してください。手順については、「コンテンツフィルタリングにガードレールを使用するアクセス許可を設定する」を参照してください。
さらに、このウォークスルーで使用するサードパーティまたはセルフホスト型の LLM へのアクセス権が必要です。この記事では、Amazon SageMaker JumpStart の Meta Llama 3 モデルを使用します。詳細については、「SageMaker プロジェクトと JumpStart の AWS 管理ポリシー」を参照してください。
Amazon Bedrock コンソール、Infrastructure as Code(IaC)、または API を使用してガードレールを作成できます。ガードレールを作成するためのサンプルコードについては、GitHub リポジトリを参照してください。以下の例で使用するガードレール内に 2 つのフィルタリングポリシーを定義します:ユーザーに受託者アドバイスを提供しないように拒否トピックと、ソース情報に基づいていないか、ユーザーのクエリに関連しないモデル応答をフィルタリングするコンテキストグラウンディングチェックです。ガードレールのさまざまなコンポーネントの詳細については、「ガードレールのコンポーネント」を参照してください。先に進む前にガードレールを作成したことを確認してください。
ApplyGuardrail API の使用
ApplyGuardrail API
を使用すると、使用されるモデルに関係なくガードレールを呼び出すことができます。ガードレールは text
パラメータに適用されます。以下のコードを参照してください:
この例では、ユーザーからの入力全体にガードレールを適用します。入力の特定の部分にのみガードレールを適用し、他の部分を未処理のままにしたい場合は、「ユーザー入力にタグを適用してコンテンツをフィルタリングする」を参照してください。
Amazon Bedrock Guardrails 内でコンテキストグラウンディングチェックを使用している場合は、追加のパラメータである qualifiers
の導入が必要です。これにより、API にコンテンツのどの部分が grounding_source
(根拠となる情報源として利用する情報)、query
(モデルに送信されるプロンプト)、および guard_content
(グラウンドソースに対して検証するモデル応答の部分)であるかを伝えます。コンテキストグラウンディングチェックは出力にのみ適用され、入力には適用されません。以下のコードを参照してください:
最後に必要なコンポーネントは、使用するガードレールの guardrailIdentifier
と guardrailVersion
、およびテキストがモデルへのプロンプトかモデルからの応答かを示す source
です。これは以下のコードで Boto3 を使用して示されています。完全なコード例は GitHub リポジトリで利用可能です:
API の応答は以下の詳細を提供します:
- ガードレールが介入したかどうか
- ガードレールが介入した理由
- リクエストに使用されたテキストユニット(Amazon Bedrock Guardrails の完全な価格詳細については、Amazon Bedrock の料金を参照してください)
以下の応答は、拒否トピックによってガードレールが介入したことを示しています:
以下の応答は、コンテキストグラウンディングチェックによってガードレールが介入したことを示しています:
最初のリクエストへの応答から、金融商品の推奨を求めたユーザーに受託者向けのアドバイスを提供しないようにガードレールが介入したことがわかります。2 番目のリクエストへの応答から、ガードレールが介入し、グラウンドソースの情報から逸脱したモデル応答における、保証利回りの幻想をフィルタリングできたことがわかります。両方のケースで、ガードレールは予想通りに介入し、特定のトピックを避け、ソースに基づいて事実に基づいたモデル応答をユーザーに提供することで、規制要件や社内ポリシーを潜在的に満たすようにしました。
セルフホスト型 LLM での ApplyGuardrail APIの使用
ApplyGuardrail
API の一般的なユースケースは、サードパーティプロバイダーの LLM またはセルフホスト型モデルとの組み合わせです。この組み合わせにより、リクエストの入力または出力にガードレールを適用できます。
一般的なフローには以下のステップが含まれます:
- モデルの入力を受け取ります。
ApplyGuardrail
API を使用して、この入力にガードレールを適用します。- 入力がガードレールを通過した場合、推論のためにモデルに送信します。
- モデルからの出力を受け取ります。
- 出力にガードレールを適用します。
- 出力がガードレールを通過した場合、最終出力を返します。
- 入力または出力のいずれかがガードレールによって介入された場合、入力または出力からの介入を示す、事前定義されたメッセージを返します。
このワークフローは以下の図で示されています。
ワークフローの実装を見るには、提供されたコードのサンプルを参照してください。
私たちは Amazon SageMaker エンドポイントでホストされている Meta-Llama-3-8B モデルを使用します。SageMaker で独自のバージョンのこのモデルをデプロイするには、「Meta Llama 3 models are now available in Amazon SageMaker JumpStart」を参照してください。
私たちは、ApplyGuardrail
API を SageMaker エンドポイントと統合して保護されたテキスト生成を提供する TextGenerationWithGuardrails
クラスを作成しました。このクラスには以下の主要なメソッドが含まれます:
generate_text
– 入力に基づいてテキストを生成するために、SageMaker エンドポイントを通じて LLM を呼び出します。analyze_text
– ApplyGuardrail API を使用してガードレールを適用するコアメソッドです。API 応答を解釈して、ガードレールを通過したか介入されたかを判断します。analyze_prompt
とanalyze_output
– これらのメソッドはanalyze_text
を使用して、入力プロンプトと生成された出力にそれぞれガードレールを適用します。ガードレールを通過したかどうかと関連するメッセージを含むタプルを返します。
クラスは前述の図のワークフローを実装します。以下のように機能します:
analyze_prompt
を使用して、入力プロンプトをチェックします。- 入力がガードレールを通過した場合、
generate_text
を使用してテキストを生成します。 - 生成されたテキストは
analyze_output
を使用してチェックされます。 - 両方のガードレールを通過した場合、生成されたテキストが返されます。そうでない場合は、介入メッセージが提供されます。
この構造により、テキスト生成の前後で包括的な安全性チェックが可能になり、ガードレールが介入した場合の明確な処理が可能です。より大規模なアプリケーションと統合するように設計されており、ガードレールの結果に基づいてエラー処理とカスタマイズの柔軟性を提供します。
以下の入力を提供してテストできます:
デモンストレーションの目的で、今回は Meta Llama のプロンプトのベストプラクティスに従っていません。実際のシナリオでは、LLM をプロンプトする際にモデルプロバイダーのベストプラクティスに確実に従ってください。
モデルは以下のように応答します:
これは私たちの質問に対してハルシネーションを含む応答です。ワークフローの出力でこれが示されています。
ワークフローの出力では、入力プロンプトがガードレールのチェックを通過し、ワークフローが応答を生成したことがわかります。次に、ワークフローはユーザーに提示する前にモデル出力をチェックするためにガードレールを呼び出します。そして、コンテキストグラウンディングチェックが介入したことがわかります。これは、モデル応答がグラウンドソースの情報に基づき、事実に基づいていないことを検出したためです。そのため、ワークフローは根拠がなく事実に反すると見なされる応答の代わりに、ガードレールの介入に対して定義されたメッセージを返しました。
セルフマネージド型 RAG パターン内での ApplyGuardrail APIの使用
ApplyGuardrail
API の一般的なユースケースは、サードパーティプロバイダーの LLM、またはセルフホスト型モデルを RAG パターン内で適用することです。
一般的なフローには以下のステップが含まれます:
- モデルの入力を受け取ります。
ApplyGuardrail
API を使用してこの入力にガードレールを適用します。- 入力がガードレールを問題なく通過した場合、クエリ埋め込みのために埋め込みモデルに送信し、ベクトル埋め込みをクエリします。
- 埋め込みモデルからの出力を受け取り、それをコンテキストとして使用します。
- コンテキストを入力とともに言語モデルに提供して推論を行います。
- 出力にガードレールを適用し、コンテキストをグラウンディングソースとして使用します。
- 出力がガードレールを通過した場合、最終出力を返します。
- 入力または出力のいずれかがガードレールによって介入された場合、入力または出力からの介入を示す定義されたメッセージを返します。
このワークフローは、以下の図で示されています。
図の実装を見るには、コードのサンプルを参照してください。
例では、LLM に SageMaker でセルフホストされたモデルを使用しますが、これは他のサードパーティモデルでも可能です。
私たちは SageMaker エンドポイントでホストされている Meta-Llama-3-8B モデルを使用します。埋め込みには、voyage-large-2-instruct モデルを使用します。Voyage AI 埋め込みモデルの詳細については、「Voyage AI」を参照してください。
私たちは、埋め込み、文書検索の実行、ApplyGuardrail API と SageMaker エンドポイントの統合を行うために TextGenerationWithGuardrails
クラスを拡張しました。これにより、文脈に関連する情報を用いてテキスト生成を保護します。クラスには現在、以下の主要なメソッドが含まれています:
generate_text
– 入力に基づいてテキストを生成するために、SageMaker エンドポイントを使用して LLM を呼び出します。analyze_text
–ApplyGuardrail
APIを使用してガードレールを適用するコアメソッドです。API の応答を解釈して、ガードレールを通過したか、介入されたかを判断します。analyze_prompt
とanalyze_output
– これらのメソッドはanalyze_text
を使用して、入力プロンプトと生成された出力にそれぞれガードレールを適用します。ガードレールが通過したかどうかと関連するメッセージを含むタプルを返します。embed_text
– 指定された埋め込みモデルを使用して与えられたテキストを埋め込みます。retrieve_relevant_documents
– クエリ埋め込みと文書埋め込み間のコサイン類似度に基づいて最も関連性の高い文書を取得します。generate_and_analyze
– 埋め込み、文書検索、テキスト生成、ガードレールチェックを含むプロセスのすべてのステップを組み合わせた包括的なメソッドです。
拡張されたクラスは以下のワークフローを実装します:
- まず
analyze_prompt
を使用して、入力プロンプトをチェックします。 - 入力がガードレールを通過した場合、クエリを埋め込み、関連文書を取得します。
- 取得された文書が元のクエリに追加され、拡張クエリが作成されます。
- 拡張クエリを使用して、
generate_text
でテキストが生成されます。 - 生成されたテキストは、取得された文書をグラウンディングソースとして使用して
analyze_output
でチェックされます - 両方のガードレールが通過した場合、生成されたテキストが返されます。そうでない場合は、介入メッセージが提供されます。
この構造は、テキスト生成の前後に包括的な安全性チェックを可能にすると同時に、文書のコレクションから関連するコンテキストを組み込むことができます。これは以下の目的で設計されています:
- 複数のガードレールチェックを通じて安全性を強化する。
- 取得された文書を生成プロセスに組み込むことで関連性を向上させる。
- ガードレールの結果に基づいてエラー処理とカスタマイズの柔軟性を提供する。
- より大規模なアプリケーションと統合する。
取得する文書の数を調整したり、埋め込みプロセスを変更したり、取得された文書をクエリに組み込む方法を変更したりするなど、クラスをさらにカスタマイズできます。これにより、さまざまなアプリケーションで安全でコンテキストを考慮したテキスト生成を行うための多用途なツールとなります。
以下の入力プロンプトで実装をテストしてみましょう:
ワークフローへの入力として以下の文書を使用します:
以下はワークフローの出力例です:
取得された文書は、ApplyGuardrail
API の呼び出しのグラウンディングソースとして提供されます:
以下のソース文書の記述により、ガードレールが介入したことがわかります:
一方、モデルは以下のように応答しました:
これはハルシネーションを示しています。ガードレールが介入し、ハルシネーションされた回答の代わりに定義されたメッセージをユーザーに提示しました。
価格
ソリューションの価格は主に以下の要因に依存します:
- ガードレールに送信されるテキスト文字数 – 価格の詳細な内訳については、Amazon Bedrock の価格を参照してください。
- セルフホスト型モデルのインフラのコスト – プロバイダーに依存します。
- サードパーティ管理モデルのトークンコスト – プロバイダーに依存します。
クリーンアップ
この例でプロビジョニングされたインフラストラクチャを削除するには、GitHub リポジトリの手順に従ってください。
結論
ApplyGuardrail
API を使用して、生成 AI アプリケーションのセーフガードを FM から切り離すことができます。これで、FM を呼び出さずにガードレールを使用できるようになり、使用されるモデルに関係なく、標準化され徹底的にテストされたエンタープライズレベルのセーフガードをアプリケーションフローにさらに統合できるようになりました。GitHubリポジトリのサンプルコードを試して、フィードバックがあれば提供してください。Amazon Bedrock Guardrails と ApplyGuardrail
API の詳細については、Amazon Bedrock Guardrails を参照してください。
翻訳はソリューションアーキテクト菊地が担当しました。
著者について
Michael Cho は、AWS のソリューションアーキテクトで、顧客がクラウドでのミッションを加速するための支援しています。彼は顧客に力を与える革新的なソリューションの設計し、構築することに情熱を注いでいます。最近では、複雑なビジネスの問題を解決するために生成 AI を使って実験することに時間を費やしています。
Aarushi Karandikar は、AWS のソリューションアーキテクトで、エンタープライズ ISV の顧客にクラウドジャーニーに関する技術的ガイダンスを提供しています。彼女は UC Berkeley でデータサイエンスを学び、生成 AI の技術を専門としています。
Riya Dani は、AWS のソリューションアーキテクトで、エンタープライズの顧客のクラウドジャーニーを支援しています。彼女は学ぶことに情熱を持ち、Virginia Tech でコンピューターサイエンスの学士号と修士号を取得しています。空き時間には、アクティブに過ごすことと読書を楽しんでいます。
Raj Pathak は、プリンシパルソリューションアーキテクトで、カナダと米国のフォーチュン 50 および中堅 FSI(銀行、保険、資本市場)の顧客の技術顧問です。Raj は、生成 AI、自然言語処理、インテリジェントドキュメント処理、MLOps への応用を含む機械学習を専門としています。