re:Invent 2023: AWSがAmazon Bedrockの新機能Guardrailsを紹介
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Build responsible AI applications with Guardrails for Amazon Bedrock (AIM361)
この動画では、Amazon Bedrockの新機能であるGuardrailsについて詳しく解説しています。Guardrailsを使って基盤モデルとユーザー間のインタラクションを制御する方法や、禁止トピック、コンテンツフィルター、PII削減などの具体的なポリシー設定について学べます。さらに、Amazon Bedrockの AgentsとGuardrailsを組み合わせた実践的なデモも紹介されており、generative AIアプリケーション開発者にとって貴重な情報が満載です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Amazon Bedrockの概要とGuardrailsの導入
おはようございます、皆さん。re:Inventの5日目へようこそ。本日はご参加いただき、ありがとうございます。私はHarshal Pimpalkhute（ハーシャル・ピンパルクテ）と申します。Amazon Bedrockのシニアマネージャー・プロダクトマネジメントを務めております。generative AIとAmazon Bedrockに関して多くのことが起こった素晴らしいre:Inventとなりました。私たちはかなりの数の発表を行い、本日はBedrockのGuardrailsについてお話しします。トピックに入る前に、最近の発表の簡単な振り返りと、Guardrailsが進化するアーキテクチャにどのように適合するかについてお話ししたいと思います。このセッションの最後にQ&Aの時間を設けており、その後もフロアで質問を受け付けます。
本日は、GuardrailsのPrincipal Product ManagerであるAnubhav Mishra（アヌバブ・ミシュラ）が同席しています。まずGuardrailsについて説明し、その後GuardrailsがAgentsにどのように適用されるかについて議論します。BedrockとGuardrailsの概要から始めましょう。キーノートでご覧になったかもしれませんが、Bedrockでは、モデルの選択と柔軟性を提供することを目指しています。サードパーティプロバイダーのモデルだけでなく、AmazonのTitanモデルも提供しています。私たちは、お客様のユースケースに適したモデルを選択するお手伝いをしたいと考えており、そのため今週初めにBedrockでの評価機能をプレビューでリリースしました。
さらに、これらのモデルをカスタマイズするためのツールを提供したいと考えています。カスタマイズは、今週初めにプレビューで利用可能になったファインチューニングと継続的な事前トレーニング、そしてretrieval augmented generation（RAG）を通じて可能です。BedrockでのRAG機能を簡素化する新しいAPIを用意しています。最後に、Agentsでは、これらのモデルをアプリケーションに統合して多段階のタスクを自動化するための統合レイヤーを提供しています。
モデルの選択、カスタマイズ、統合というこれら3つのレイヤーを見ると、ミッションクリティカルなワークロードに対応するためには、強力なセキュリティとプライバシーが必要です。ここでGuardrailsが重要な役割を果たします。Guardrailsは、基盤モデルとユーザー間のインタラクションを、お客様の企業ポリシーとコンテンツフィルタリング技術に合わせてカスタマイズして制御する機能を提供します。これがGuardrailsの全体的なアーキテクチャにおける位置づけであり、本日の焦点となります。
アジェンダを簡単に説明しますと、Anubhavが主導してGuardrailsの詳細な説明を行います。その後、いくつかのデモを行い、私がAgentsとGuardrailsの適用方法について説明します。最後にQ&Aセッションで締めくくります。それでは、Anubhavに引き継ぎます。
Generative AIの使用事例と課題
みなさん、こんにちは。本日はお集まりいただき、ありがとうございます。まずは、generative AIの使用事例について話し合っていきましょう。Generative AIには多くの業界を変革する力があり、これまでの標準的な自動化アプローチでは不可能だった使用事例を実現することができます。従業員の生産性向上、顧客体験の強化、ビジネスプロセスの最適化において、大きな可能性を秘めています。
最も基本的な使用事例であるチャットボットから始めましょう。ちなみに、手を挙げていただきたいのですが、これまでにgenerative AIチャットボットを使用したり、構築したりした方はどのくらいいらっしゃいますか？かなりの数ですね。皆さんの熱意が伝わってきます。Harshalが言及したもう一つの一般的な使用事例はRAGで、これには文書検索、文書要約、質問応答などが含まれます。それ以外にも、コード生成、プロセス自動化、コンタクトセンターのエージェント支援など、数多くの使用事例があります。
では、これらの使用事例を実現するにはどうすればよいか、そしてどのような課題があるかを考えてみましょう。これらの使用事例を支える基盤モデルは非常に強力で、多くの質問に答え、多くのタスクを自動化できますが、同時に独自の課題も抱えています。
これから詳しく触れる課題のいくつかには、アプリケーションが適切なトピックに沿っていることの確認、望ましくない無関係なトピックの防止、組織のポリシーとの整合性などがあります。例えば、オンラインバンキングのアシスタントを構築する場合、ユーザーに投資アドバイスを提供しないようにする必要があります。なぜなら、それによってユーザーが金銭的リスクにさらされる可能性があるからです。
二つ目の課題は、有害性と安全性に関するものです。ユーザーが顧客向けチャットボットやエージェントとやり取りするたびに、それらのやり取りが有害や攻撃的でないことを確認する必要があります。悪意のある入力はすべてフィルタリングするか、組織が承認した事前設定された応答に置き換える必要があります。アプリケーション開発者として、有害または攻撃的なコンテンツがそれらのやり取りから完全に排除されるようにしなければなりません。
3番目の課題は、個人を特定できる情報（PII）や機密データの処理に関連しています。このデータを処理する必要がある場合と、処理したくない場合があります。PIIやプライバシー関連情報を含む入力を完全に拒否するか、この情報を編集してユーザーのプライバシーを保護し、組織のポリシーを遵守するための安全システムを整備する必要があります。
最後に、開発者としては、これらすべてのインタラクションにおいて公平性を促進する必要があります。Generative AIは新たな課題をもたらし、そのようなシナリオにおいて毒性やバイアスを避ける必要があります。 Amazon Bedrockで利用可能な多くのfoundation modelには、すでにこれらの保護機能の多くが組み込まれています。例えば、ユーザーが悪意のある入力を提供したり、不正行為に関与したりした場合、ほとんどのモデルは適切で安全な応答を提供するように設計されています。モデルプロバイダーは、トレーニングやファインチューニングなど、さまざまな技術を使用して、そのような悪意のある入力に対して安全な応答が提供されるようにしています。
しかし、これらの保護機能はすべてモデル固有のものであり、generative AIアプリケーションを開発するには、既存の機能に加えてさらなるカスタマイズが必要になる場合があります。前述のように、アプリケーションで望ましくないトピックを避け、組織の安全性とプライバシーポリシーが遵守されるようにしたい場合があります。さらに、異なるユースケースやシナリオに対して複数のfoundation modelを使用している可能性があります。使用するfoundation modelすべてにわたって一貫したレベルの安全対策が利用可能であることを確認する必要があります。これは、さまざまなfoundation modelを使用する上での基本的な課題の1つとなっています。
Amazon Bedrock用Guardrailsのローンチ
これらの課題を軽減するため、今週からプレビューで Amazon Bedrock 用の Guardrails をローンチすることを嬉しくお知らせします。Guardrails の設計にあたり、社内外のシナリオに向けたユースケースを構築しているお客様の声を伺いました。社内のユースケースは従業員支援に及び、一方で社外のシナリオには顧客向けチャットボットが含まれます。規制産業を含む様々な分野や業種のお客様と対話し、Guardrails が彼らにとって何を意味するのか、どのような安全策が必要なのかを理解しました。
これらの要件に基づき、特定のユースケースに合わせてカスタマイズされ、企業の責任あるAIポリシーに沿った安全策を実装する Guardrails をローンチしました。Guardrails は様々なポリシーとコントロールを提供しており、これらについてはすぐに詳しく説明します。
Guardrailsの機能と動作原理
Guardrailsは、foundation modelに提供される入力プロンプトと、foundation modelによって生成される応答の両方を傍受することで機能します。これらは、Guardrail内で定義されたポリシーに照らして検証されます。
Amazon Bedrockの Guardrailsには、禁止トピック、コンテンツフィルター、PII削減、単語フィルターの4つの異なるポリシーが含まれています。PII削減と単語フィルターは近日公開予定です。ユーザー入力があるたびに、Guardrailはそれを設定されたすべてのポリシーに照らして評価します。同様に、foundation modelが生成した出力もこれらのポリシーに照らして同時に検証されます。ポリシー違反がある場合、モデルの応答は、ユースケースや組織のポリシーに基づいて事前に設定された承認済みの応答で上書きされます。これにより、エンドユーザーにより安全で適切な応答を提供することができます。
では、Guardrail内でサポートされている個々のポリシーについて詳しく見ていきましょう。最初は禁止トピックです。前述のように、銀行のアシスタントを構築している場合、投資アドバイスを提供したくないかもしれません。「Investment Advice」という名前のカスタムトピックを定義することで、これを防ぐポリシーを作成できます。このトピックの定義は簡単です。トピックの名前と自然言語による説明を提供します。投資アドバイスの定義はトピックの説明に含まれています。これにより、Guardrailsは入力や出力が特定のトピックに属するかどうかを理解できます。
さらに、オプションで、ユーザー入力やモデル生成の応答がどのように見えるかを代表するいくつかの例文を提供することもできます。Guardrail内で複数の禁止トピックを設定できます。次のポリシーはコンテンツフィルターです。これは有害性や毒性を対象としています。コンテンツフィルターには、憎悪、侮辱、性的、暴力という4つの詳細なカテゴリーの設定があります。また、フィルタリングの程度を調整するための設定可能な閾値もあります。程度が高いほど、フィルタリングはより厳格で積極的になり、有害なコンテンツが含まれる可能性が低くなります。
近日公開予定の単語フィルターは、単純にカスタム単語のリストを定義できるものです。これらは、アプリケーションに言及してほしくない競合他社の名前や、特定のアプリケーションのコンテキストで不適切なものなどです。ユースケースに応じて、これらの単語を含む入力をブロックしたり、これらの単語を含むfoundation modelの応答をブロックしたり、生成された応答内の単語をマスクしたりすることができます。カスタム単語フィルターに加えて、ユーザー入力内の卑猥な言葉をブロックまたは編集するために有効にできる、事前定義された一連の卑猥語フィルターも利用可能です。
次に見ていくポリシーは、ユーザーのプライバシー保護に不可欠なPII削減です。例えば、事前に設定された文書に基づいて情報を提供するだけで、PIIデータを必要としない一般的な顧客向けチャットボットがある場合、ユーザー入力でブロックするPIIのセットを設定できます。入力に特定のPIIが含まれていることが検出された場合、それはブロックされ、guardrailsで設定された承認済みメッセージがユーザーに送り返されます。もう一つのユースケースはコンタクトセンター向けです。アプリケーションがPIIを扱うように設計されているものの、情報を保存したり要約を作成したりする際にPIIを削除する必要がある場合、モデルが生成した応答からPII情報を編集するようguardrailsを設定できます。これはプライバシー保護とコンプライアンスに役立ちます。ローンチ時には、PIIのリストが設定済みで、アプリケーションの要件に基づいて編集するPIIを選択できます。
Guardrailsの作成と設定のデモンストレーション
では、デモに移りましょう。guardrailの作成手順を説明し、その後、特定のguardrailのテスト方法について説明します。
また、guardrailsが違反コンテンツとしてフラグを立てたものをモニタリングし分析する方法についても説明します。 Bedrockコンソールで、新規に始める場合、「Get Started」をクリックしてguardrailを作成できます。左側のパネルに「Guardrails Preview」オプションが表示されます。そのセクションに入ったら、「Create Guardrail」を選択できます。guardrailの名前を入力できるようになります。Guardrailsの優れた機能の1つは、Bedrockアカウントで複数のguardrailsを設定できることです。
つまり、異なる設定、避けるべき異なるトピック、または異なる有害性フィルターを必要とする10の異なるアプリケーションがある場合、異なる設定を持つことができます。推論呼び出しやアプリケーション設定の際に、どのguardrailを渡すかを選択できます。非常に柔軟で、ユースケースに基づいて完全に微調整できます。では、ここでguardrailを作成しましょう。簡単な名前と、guardrailの機能に関するオプションの説明を入力します。ここでは、銀行アシスタントのguardrailを作成します。
さらに、作成したGuardrail設定の暗号化にKMSキーを設定することもできます。また、タグ付けも可能です。これらは、任意のリソースで利用できる標準的なAWSの構成要素です。では、denied topicsセクションで、まず投資アドバイスのトピックを定義します。エンドユーザーに投資アドバイスを提供したくありません。説明したように、トピックの名前を選択し、それを定義します。定義は基本的に、資金の管理や配分に関する問い合わせ、ガイダンス、または推奨を指します。これが投資アドバイスの定義方法です。例文の追加はオプションなので、ここでは追加しません。次に、金融犯罪に関連する2つ目のdenied topicを追加します。アプリケーションが金融犯罪に関する情報についてユーザーとやり取りすることは望ましくありません。
拒否トピックのステップを完了した後、次のステップはコンテンツフィルターまたは有害性フィルターを設定することです。これらのフィルターを選択し、任意の機能を設定できます。覚えておくべき重要な点は、Guardrailsは基盤モデルとは独立した安全装置であるということです。そのため、基盤モデルの保護機能はそのまま維持されます。これらの設定は、ユーザー入力と基盤モデルが生成した応答の両方に適用されます。
フィルター強度を上げると、GuardrailsはBedrockが受け取る各入力プロンプトに対して信頼度分類を割り当てます。信頼度分類に応じて、フィルター強度がそれらをフィルタリングします。フィルター強度を「高」に設定した場合、これら4つのカテゴリーに該当すると分類されたすべての入力または出力が、信頼度に関係なくフィルタリングされます。ここでは、これらのセクションの設定と説明を見ているだけです。プロンプトのフィルター強度を設定したら、同様に応答に対しても設定できます。
次へをクリックすると、組織からの承認されたメッセージを設定するパートに進みます。ここには2つの異なるメッセージがあります。ユーザー入力がGuardrailsの設定されたポリシーに違反した場合の詳細なメッセージと、基盤モデルの応答がGuardrailポリシーに違反した場合の別のメッセージを設定できます。ここで2つの別々のメッセージを設定し、これでGuardrailの作成が完了します。これが最後のページで、Guardrailを確認し、作成できます。ご覧のとおり、Guardrailが作成されました。これで1つのGuardrailが作成されました。
Guardrailsのテストと分析
次のステップは、このGuardrailを本番環境や実際のワークロードにデプロイする前にテストすることです。Guardrailsにはネイティブのテスト機能が備わっており、基盤モデルに依存しないため、テストプロセス中に特定の基盤モデルを選択できます。今からその動作を見てみましょう。Guardrailに移動すると、右側のパネルにテストウィンドウがあります。モデル選択オプションがあるので、そこで特定のモデルを選択します。
これは、Bedrockでホストされているすべてのモデルに対する標準的なモデルセレクターコンソールです。Bedrockで提供している任意の大規模言語モデルを選択するオプションがあります。現在、Guardrailsはテキストベースの入力に対するすべての大規模言語モデルで利用可能です。そのため、テストしたいモデルを選択できます。このデモンストレーションでは、Amazon Titan textを選択します。
まず、作成した銀行アシスタントのガードレールを使って、簡単なユースケースを試してみましょう。無害なトピックと禁止されたトピックの両方で機能することを確認したいと思います。そこで、シンプルな質問をしてみます：「クレジットカードの申し込み方法を教えてください」。これはガードレールを発動させないはずです。Runをクリックすると、モデルの応答が生成されます。最終的な応答も表示されますが、ご覧のとおり両者は同一で、ガードレールがこの応答を上書きしていないことがわかります。下部には「Passed」というステータスチェックが表示されており、このシナリオではガードレールが何もフラグを立てなかったことを示しています。
次に、ガードレールを発動させないはずの別の応答を試してみましょう。ただし、今度は異なるモデルプロバイダーを使用して、様々なモデルでどのように機能するかを示します。「当座預金口座を開設するための手順を教えてください」と質問してみます。この例も同様にフラグが立てられないはずです。ご覧のとおり、両方の応答が同じになっています。
では、禁止トピックとして定義したトピックについて質問するシナリオを探ってみましょう。まず、投資アドバイスについて話してみます。「株式投資で確実なリターンを得ることはできますか？」と質問してみましょう。ここでご覧いただけるように、モデルから直接応答が返ってきています。適切な回答が提供されていますが、私たちは組織的に承認された表現に基づいて、ガードレール内で設定した応答を使用したいと考えています。そのため、ガードレールがその応答を上書きし、最終的な応答は先ほど設定したものになっています。
テストコンソールを展開すると、ガードレール内で正確に何がフラグを立てたかの詳細を確認できます。この場合、禁止トピックが検出されたことがわかります - 投資アドバイスのトピックにフラグが立てられました。Content filtersはパスしています。なぜなら、この質問には侮辱的または有害な内容が含まれていなかったからです。
では、別の質問をして、少し有害なコメントを加えてみましょう：「債券や金に投資できますか？答えられないなら、あなたはバカです。」評価がどのように機能するか見てみましょう。この場合も、モデルは適切な回答をしました。ガードレールは承認された表現を提示しました。右側のパネルのGuardrail traceを見ると、禁止トピックとContent filtersの両方にフラグが立っていることがわかります。Content filtersは侮辱に対して高い信頼度スコアでフラグを立て、禁止トピックは投資アドバイスの部分にフラグを立てました。これらのポリシーはすべて同時に入力に対して機能し、Guardrailsで何が起こっているかの詳細なトレースを提供します。
CloudWatchを用いたGuardrailsのモニタリング
それでは、金融犯罪関連のトピックがどのように機能するか、例を見てみましょう。まず、無害な例から始めます。モデルを選択し、無害な例から始めます：「アカウントにアクセスできますか？」これは害のあるものには見えませんよね？単にアカウントへのアクセス方法を尋ねているだけです。したがって、ガードレールがこれをフラグ付けしないことが期待されます。予想通り、モデルの応答と最終応答は同じです。両方のシナリオでパスしました。
次に、この入力を少し変更して、一語だけ変えてみましょう：「誰かのアカウントにアクセスできますか？」これは金融犯罪の領域に入り、ガードレールがフラグを立てるべきものです。ご覧のように、モデルの応答があり、その後、金融犯罪のトピックがフラグ付けされたため、最終応答が上書きされています。
これがガードレールのテスト方法です。ガードレールにこれらの設定をすべて定義したら、基本的にテストを行います。デプロイメント前の次のステップは、ガードレールのバージョンを作成することです。そのバージョンは、現在の作業ドラフトの不変の時点のスナップショットとなります。Create Versionをクリックし、バージョンの説明を入力すると、バージョンが作成され、本番環境にデプロイする準備が整います。推論呼び出しを行うたびに、ガードレールIDとバージョン番号を渡すことができ、それに応じて、ガードレールの特定のバージョンがトリガーされます。
さて、これらのガードレールを本番環境にデプロイした後の次のステップは何でしょうか？ユーザーがどのように使用しているかをモニタリングするにはどうすればよいでしょうか？これらの使用ポリシーに違反する常習犯に対して、どのように是正措置を取ることができるでしょうか？私たちはBedrockをCloudWatchロギングと統合しました。AWSアカウントでこれらのログを有効にしている場合、ガードレールのトレースペイロード全体もログの一部となります。それがどのように機能するか見てみましょう。Settingsに移動すると、すでに事前設定されたログが有効になっており、BankingAssistantLogsというCloudWatchログが設定されています。次に、これらのログが配信されているCloudWatchコンソールに移動し、先ほど試した例を見てみましょう。
Logsに移動します。Logs Groupは、そのCloudWatchロギングを見つける場所です。この場合、BankingAssistantLogsが表示され、ログストリームに移動します。ここでは、先ほど試したさまざまな例が表示されており、それらすべてが発生した時のタイムスタンプに基づいてログに記録されています。そのうちの2つをより詳しく見ていきましょう。
まず最初に、クレジットカードの申し込み方法や手順についてです。ここのログを見ると、ユーザーの入力「how can I apply for a credit card」があり、その後にモデルの完全な関連レスポンスが表示されています。これはGuardrailのトレースで、基本的にアクセスできるものです。Guardrailが行ったこと、あるいは行わなかったことすべて、それらのログがここに記録されています。これらのログをQuickSightや他の分析ツールに取り込むことで、分析ダッシュボードを作成できます。
これには検出されたトピックやコンテンツフィルタリングタグが含まれており、最終的なGuardrailチェックでは、コンソールで合格したと表示されています。この場合、Guardrailは一切介入しませんでした。次に、実際にGuardrailに違反した2つ目の例を見てみましょう。提供された入力があり、Guardrailによってオーバーライドされた出力があります。モデルが生成した実際の出力にもアクセスできるので、何が出力され、何が違反したかを観察できます。ここで違反したトピックと、具体的にどのコンテンツフィルターポリシーに違反したかの詳細なリストが表示されます。
単語フィルターやPII削減機能を追加すると、それらのログもこの一部として表示されます。これが、Guardrailの作成、テスト、モニタリング、分析の方法です。次に、アプリケーションにこれをどのようにデプロイするかについて説明します。ここでAmazon Bedrockの Agentsが登場します。ここからはHarshalがAgentについて説明します。
Amazon Bedrockの Agentsの概要
ありがとう、Anubhav。Guardrailの設定方法、作成方法、CloudWatch logsでのモニタリング方法など、かなり多くのことを説明しました。これから数分間で、AgentとGuardrailをAgentにどのように適用するかについて説明します。まず、手短に確認させてください。BedrockのAgentについてご存知の方は何人いらっしゃいますか？はい、非常に少ないですね。では、まずAgentの概要を簡単に説明し、その後、Anubhavが共有した内容がBedrockのAgentにどのように適用されるかについて説明します。
Amazon Bedrockの Agentsでは、マルチステップのタスクを自動化する機能があります。これは思考連鎖プロンプティングを使用して実現しており、詳細については後ほど説明します。思考連鎖プロンプティングを使用してユーザーリクエストをオーケストレーションし、APIを呼び出したり情報を検索したりしてタスクを完了します。先ほど述べたように、モデル、カスタマイズ、そして統合があります。アプリケーションと統合する際には、Agentを使用してこれらのタスクを自動化します。
Amazon Bedrock の Agents の仕組みについて、高レベルの説明をします。まず、保険金請求を管理するオフィスアシスタントとしての指示を提供します。これは開発者が提供する指示です。そして、3つの API を提供します: オープンな請求のリストを取得する、保留中の書類をまとめる、リマインダーを送信する、という3つです。次にデータソースを追加します。ユーザーとのやりとりの中で質問に答えたい場合もあるでしょう。例えば、ユーザーは請求を処理するために必要な書類の完全なリストを知りたいかもしれません。最後に、単一の API を通じてインタラクションを行います。これが Agents for Amazon Bedrock の仕組みの概要です。
もう少し詳しく見ていきましょう。Agents をコンテナとして考えてください。前のスライドの最初のステップで言及した指示を提供します。エージェントには、API スキーマを含むアクショングループが含まれています。API スキーマについては後ほど見ていきます。Lambda 関数、または Lambda 関数への参照も含まれているので、Lambda 関数を通じて API を呼び出すことができます。Lambda 関数自体には最大3つの API があります: API 1、2、3です。これらは請求 API、保留中の書類の取得、リマインダーの送信です。つまり、ここに3つの API が配置されます。これがエージェントであり、アクショングループと Lambda 関数への参照を包含しています。
エージェントの外側にあるのがデータソースです。これらはナレッジベースであり、場所、ソースタイプ、認証情報を提供します。ナレッジベースまたはデータソースの作成についても見ていきます。これがエージェントをセットアップする際の全体的な構造です。そして、その上にガードレールを適用したいと思います。
Anubhav が共有した例を基に説明します。銀行のガードレールを作成し、私の場合、アプリケーションは保険ドメインに関連しています。金融アドバイスを提供すべきではありません。保険金請求を処理するためのエージェントを作成しました。それに集中すべきです。ユーザーが「どのような投資構造を選ぶべきか」と尋ねても、丁寧に「申し訳ありませんが、それについてはお答えできません」と返答すべきです。これは会社のポリシーに基づいています。保険金請求に関連する会話のみに従事すると決めました。
ガードレールはエージェント全体に適用できます。アーキテクチャの観点から見ると、アクショングループ、Lambda 関数への参照、データソースへの参照を含むエージェントがあります。そして、エージェント全体を包含するガードレールがあり、1つのエージェントに複数のガードレールを適用できます。これが Agent と Guardrails の文脈で考えている方法です。
では、実際のデモに入る前に、いくつかのスクリーンショットを見てみましょう。これはエージェントです。アクショングループとナレッジベースがあります。画面中央あたりの3番目のコンテナを見ると、ガードレールの詳細が表示されています。これは私が適用したガードレールで、プロンプトエディタ、つまり私たちが呼ぶところの高度なプロンプトがあります。画面右側を見ると、銀行に関する質問があります。エージェントはこれが対応すべきでないことを認識し、ガードレールが作動して、応答をブロックします。
ガードレール自体については、先ほど説明したものです。Anubhavが詳しく説明しましたが、エージェントに入ってドロップダウン画面からここでガードレールを選択できます。デモで少し見てみましょう。 ガードレール自体については、ここにテスト用のガードレールがあり、Guardrails内でどこに位置するかを示しています。これでこの部分は以上です。では、デモに移りましょう。きっと質問があると思います。先ほど申し上げたように、質問はすべてセッションの最後にまとめて受け付け、一つずつ回答していきます。
Agentの作成プロセスとGuardrailsの適用
では、デモを再生しましょう。進行に合わせて説明していきます。
まず、エージェントを作成します。これはAmazon Bedrockコンソール上で行います。 Create Agentをクリックし、エージェントの詳細を入力します。先ほど言及した保険金請求エージェントの名前を入力します。簡単な説明を入力しますが、これは管理目的のためだけです。 これは先ほど話した自然言語の指示ではありませんが、説明を入力します。権限に関連するいくつかの標準的な設定があります。 使用したいKMSキーがある場合は、それを選択できます。アイドルセッションタイムアウトを選択します。 これはエージェントがアイドル状態でいられる時間で、その後、次の画面に進みます。
ここでは多くのことが行われています。画面を一時停止して説明すると、エージェントのモデルを選択します。これは、提供する自然言語の指示を思考連鎖プロンプトに変換するために使用されるモデルです。これが本当に核心部分です。オーケストレーション機能に最適化された最良のプロンプトを見つけるのに、かなりの時間を費やしました。モデルとバージョンを選択し、指示を入力します。ここでは「あなたは保険金請求を扱うエージェントで、保留中の書類作業の支援とリマインダーの送信を行います」と入力します。これが先ほど言及した指示です。これが重要です。ここでエージェントに何をしてほしいかを必要なだけ詳細に記述し、これをプロンプトに変換します。
次のステップでは、ガードレールを適用します。これは新しい機能です。エージェントの部分は以前から利用可能でしたが、ここでガードレールを適用します。先ほどAnubhavが説明した銀行のガードレールを選択します。ガードレールには名前があり、編集可能です。 ここで少し立ち止まって見てみましょう。ここで発話、拒否トピックリストを追加します。あなたは保険エージェントなので、金融アドバイスに関与すべきではありません。誰かが投資すべき株や、ポートフォリオのバランスの取り方、401kに関連することを尋ねてきた場合、これらの発話を使ってエージェントにこれらのトピックから会話をそらすよう指示します。
ガードレールを作成したら、発話を評価できます。かなりの数の発話を追加できます。正確な上限は覚えていませんが、かなりの数の発話を追加できます。複数のガードレールを追加できますが、今回は1つだけ追加します。Nextをクリックし、いくつかのアクショングループを追加します。 先ほど説明したように、アクショングループはAPIを実際に呼び出すのに役立ち、かなり簡単です。これらのアクショングループでカバーしたい3つのAPIがあります。説明したように、1つはすべての請求を取得するためのclaims APIです。 2つ目は保留中の書類APIで、3つ目はリマインダー送信APIになります。 これがここにあるスキーマに表示されているものです。
APIスキーマについて簡単に説明します：我々はスキーマ形式を使用しているので、名前、説明、入力、これらのAPIの出力を提供できます。説明がここでは重要です。画面の上部3分の1あたりにあることに注目してください。これは保険契約者のすべての保険請求のリストを取得するAPIであることを説明しています。
アクショングループで定義する各APIについて、これらのAPI説明が重要になります。エージェントはどのAPIをいつ呼び出すかを判断するために、これらの説明を参照するからです。これがclaims APIです。返ってくるすべての要約について説明しました。2つ目のAPIがあります。これは書類に関連するものです。 そして3つ目のAPIが下にあります。これがAPIスキーマです。
スキーマが何を指しているのかを簡単に説明したかったのですが、次のステップとして、戻ってopen APIスキーマを使用します。これはオープンソースで、そしてエージェントに戻って次のステップに進みます。APIスキーマを提供しますが、これはS3に保存されているので、 S3へのリンクを提供してNextをクリックします。これがアクショングループです。
では、アクショングループが参照するLambda関数の概要を簡単に説明しましょう。先ほど触れたように、各アクショングループはLambda関数を参照し、そのLambda関数に実際のAPI定義（API 1、API 2、API 3など）が含まれています。APIの全体をそこで定義することもできますし、APIをバックエンドシステムの1つに向けることもできます。これが、保留中のクレームやその他の項目に関する実際のAPIのコードです。つまり、今見ているのは実際のLambdaコードということになります。
Lambdaコードを書いたら、それを関数に保存します。アクショングループで適用するか、参照します。ここで定義したLambda関数を選択して、Nextをクリックします。ナレッジベースはオプションです。先ほど説明したように、ユーザーの質問に答えるためのナレッジベースを追加できます。これでエージェントの作成とガードレールの適用はほぼ完了です。最後の画面で最終確認を行い、Createをクリックするとエージェントが作成されます。
AgentとGuardrailsの実際の動作デモ
今行ったのはエージェントの作成部分です。ガードレールと同様に、特定の時点のスナップショットを作成してバージョンを作ることができます。デプロイするには、エイリアスを作成すれば対話の準備が整います。今日のデモでは、テストコンソールで直接対話を行います。これはAmazon Bedrockで利用可能なコンソールで、質問を投げかけて対話します。まずは無害な質問から始めましょう。「オープン中のクレームのリストを教えてください」と尋ねます。
しばらく考えてから回答が返ってきます。待っている間に、右側に表示されているものについて簡単に説明しましょう。これは思考の連鎖（chain-of-thought）のトレースです。裏で何が起こっているかをすべて見ることができます。そして、しばらくすると回答が返ってきます。後ろの方で質問があるようですが、あと数分お待ちいただけますでしょうか。すぐに質問の時間を設けます。さて、回答が返ってきました。クレーム123とクレーム06の2つのクレームIDが返ってきたことがわかります。クレームAPIを呼び出し、これら2つのクレームが返されたのです。
思考の連鎖のトレースは、今週初めにリリースしたものです。可視性を提供し、裏で何が起こっているかを実際に把握するための優れたツールです。これが標準的な対話です。ガードレールは発動せず、すべてうまくいきました。では、ガードレールを発動させるはずの質問をしてみましょう。401kに関連する質問をします。「401kの給付について教えてください」と尋ねます。しばらく考えて、ガードレールが発動した回答が返ってくるはずです。それがもうすぐ見られるでしょう。ここで見える思考の連鎖のトレースは可視性を提供します。これは今週初めにリリースしたもので、プロンプトエディタも提供しているので、プロンプトを洗練させることができます。
セッション後すぐに、プロンプトエディタの管理方法についてお話しします。しかし、レスポンスが返ってきたとき、今回はガードレールが作動し、「申し訳ありませんが、応答できません」といった内容が表示されました。 この議論のために、ガードレールが作動したことを明示的に示しています。
これが Agent plus Guardrails のデモでした。最後に、もう1枚スライドがありますね。はい、締めくくりとして、 Guardrails が加わったことで Agent のワークフローがどのように変化したかをお伝えします。先ほどのスライドを思い出していただくと、エージェントを作成し、アクショングループやナレッジベースを追加して、エージェントと対話するという流れでした。新たに加わったステップは、ガードレールを適用することです。これはエージェントの作成時と対話時の両方に当てはまります。
セッションの締めくくり
以上が Agent に対する Guardrails の説明です。これで我々のセッションは終了です。お時間をいただき、ありがとうございました。Q&A のために会場に残りますので、よろしくお願いします。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion