Amazon Connect, Amazon Lex, Amazon Bedrock Knowledge Bases を活用してコンタクトセンターに音声とチャットの生成 AI エージェントをデプロイする

この記事は DoorDash の Vraj Shah と Chaitanya Hari との共著です。

DoorDash は、世界中の 30 か国以上で消費者と地元の好みのビジネスをつないでいます。Door Dash は、Dasher として知られる契約配達員からの大量の電話対応で大きな課題に直面していました。2023 年末時点で 3,700 万人以上のアクティブな消費者と月間 200 万人のアクティブな Dasher を抱える同社は、 Dasher により効率的なセルフサービス体験を提供することで、ライブエージェントの負担を軽減する必要性を認識しました。

この課題に対処するため、DoorDash のコンタクトセンターチームは、高水準の問題解決と顧客満足度を維持しながら、迅速かつ大規模に解決策をデプロイするために生成 AI の力を活用したいと考えました。道路上にいる間はテキストよりも電話でのサポートを好む Dasher には、最小限の応答遅延で迅速で信頼性の高い支援が必要です。この低遅延要件は、 DoorDash が音声による効果的なセルフサービスソリューションを追求する上で重要な要素となりました。

ライブエージェントによる支援の必要性を減らすために、DoorDash は AWS Generative AI Innovation Center と協力してわずか 2 か月で、Dasher に低遅延のセルフサービス音声体験を提供するソリューションを構築しました。

このソリューションは、音声対応の会話型 AI サービスである Amazon Lex、主要な AI スタートアップと Amazon からの基盤モデル (FM) を API を通じて利用可能にし、ユースケースに最適なモデルを選択できる完全マネージド型サービスである Amazon Bedrock、そして大規模言語モデル (LLM) をデータソースに接続する完全マネージド型サービスの Amazon Bedrock のナレッジベースを使用しています。これは、フルサーバーレスアーキテクチャで、基盤となるインフラストラクチャを管理することなくペタバイト規模のワークロードを実行できる Amazon OpenSearch Serverless を使用しています。

このソリューションは 1 日数十万件の電話に対応し、2.5 秒以内に Dasher の質問に回答しています。また、自動テスト、会話分析、監視と可観測性、LLM ハルシネーションの防止と検出を含む運用機能も提供しています。

「私たちはDasherが最も一般的な質問や問題について、できるだけ迅速かつ効率的に支援を受けられるようにしたいと考えていました。それによって彼らの時間と労力を節約し、DoorDash のセルフサービス機能への信頼を高めることができます」
– Chaitanya Hari, Contact Center Product Lead at DoorDash.

この記事では、AWS サービスを使用してコンタクトセンターに生成 AI エージェントをデプロイする方法を紹介します。

ソリューション概要

この記事では、Example Corp Hospitality Group という架空のホテルチェーンの例を使用します。以下は、顧客と LLM による自動エージェントとの対話の例です：

顧客: こんにちは、家族旅行に最適な場所を探しています

エージェント: Example Corp Family Getaways では、テーマパーク、国立公園、歴史的な名所などの人気観光スポット近くにある家族向けホテルやリゾートを提供しています。リゾートには広々とした宿泊施設、全年齢向けのアクティビティ、多様な食事オプションがあり、忘れられない家族の思い出を作ることができます。

顧客: どこにありますか？

エージェント: Example Corp Family Getaways は、フロリダ州オーランド、カリフォルニア州アナハイム、バージニア州ウィリアムズバーグ、テネシー州ピジョンフォージ、テキサス州サンアントニオ、アリゾナ州スコッツデール、ミズーリ州ブランソン、ウィスコンシン州ウィスコンシンデルズ、ペンシルベニア州ハーシーなど、さまざまな人気の休暇先で家族向けリゾートを提供しています。

顧客: ピジョンフォージが面白そうですね。

エージェント: ピジョンフォージのリゾートでは、ドリーウッドやその他の近隣のアトラクションの興奮を楽しみながら、大自然を体験する機会を家族に提供しています。宿泊客は室内ウォーターパーク、ミニゴルフコース、ファイヤーピット周辺での夜のスモア焼きを楽しむことができます。

顧客: 子供向けメニューはありますか？

エージェント: テネシー州ピジョンフォージの Example Corp Family Getaways リゾートでは、ピザ、チキンナゲット、マカロニチーズなどのお気に入りを含む専用の子供向けメニューなど、家族向けの食事オプションを提供しています。

自分の AWS アカウントでソリューションをデプロイして、このサンプルソリューションを試すことができます。以下の図はソリューションアーキテクチャを示しています。

ソリューションの主要コンポーネントのデプロイとテストの手順を説明します：

ソリューションが質問に回答するために使用するコンテンツを保存する Amazon Bedrock Knowledge Bases を設定する AWS CloudFormation スタック
Amazon Lex ボットとコアとなる検索拡張生成（RAG）に基づく質問応答機能を実装する AWS Lambda 関数を作成する CloudFormation スタック
（オプション）会話分析ダッシュボードを有効にするデータパイプラインをデプロイする CloudFormation スタック
（オプション）LLM ハルシネーションの非同期検出機能を有効にする CloudFormation スタック
（オプション）生成された回答と正解の回答を比較し、合格/不合格の評価と説明を提供するための自動テスト機能を利用できる Amazon SageMaker の Jupyter ノートブック

必要なすべてのものは、GitHub リポジトリでオープンソースとしても提供されています。

※ 日本のお客様向けの補足事項：
本ソリューションは、英語のみに対応していますが、「RAGソリューションスタックのデプロイ」の実施後に、Amazon Lex の日本語追加を行い、Lambda 関数の該当コードにおけるプロンプトを日本語に修正することで、日本語による応対も簡易的に検証可能です。LLM として Anthropic の Claude 3 Haiku、Claude 3 Sonnet を選択した場合は、Lambda 関数コードのbedrock_utils/hotel_agents/anthropic.py と bedrock_utils/conversational_agents/anthropic.py のプロンプトを日本語に修正します。

前提条件

このアプリケーションに必要なリソースとコンポーネントを作成および管理するための権限を持つ AWS アカウントと AWS Identity and Access Management (IAM) ロールおよびユーザーが必要です。AWS アカウントをお持ちでない場合は、「新しい AWS アカウントを作成して有効化する方法を教えてください。」を参照してください。

このソリューションでは、Amazon Bedrock を使用してナレッジベースから質問に対する回答を見つけます。次に進む前に、少なくとも以下のAmazon Bedrockモデルへのアクセスをリクエストしてください（既にアクセスが有効な環境ではこの作業は不要です）：

Amazon Titan Embeddings G1 – Text
Cohere Embed English v3 と Cohere Embed Multilingual v3
Anthropic の Claude 3 Haiku と Anthropic の Claude 3 Sonnet

Amazon Connect と統合する場合は、ご自身のアカウントで利用可能な Amazon Connect インスタンスがあることを確認してください。まだない場合は作成できます。会話分析スタックをデプロイする場合は、Amazon QuickSight が必要となるため、アカウント内で有効になっていることを確認してください。

執筆時点では、このソリューションは以下の AWS リージョンで利用可能です：アジアパシフィック（シンガポール、シドニー、東京）、カナダ（中部）、ヨーロッパ（フランクフルト、ロンドン）、米国東部（バージニア北部）、米国西部（オレゴン）。

Amazon Bedrock ナレッジベースのデプロイ

Amazon Simple Storage Service (Amazon S3) をデータソースとして使用するナレッジベースには、CloudFormation スタックを使用できます。ナレッジベースをセットアップするには、以下の手順を実行します：

AWS アカウントにサインインし、“Launch Stack” を選択して CloudFormation テンプレートをデプロイします
「次へ」をクリックし、スタック名を入力します（例：contact-center-kb）。
S3 bucket where you will store your content : 既存の S3 バケット名を入力します（例：contact-center-kb-{your-account-number}）。これはデモソリューションのコンテンツが保存される場所です。まだ S3 バケットがない場合は作成してください。
S3 prefix for your content (optional) : 何も入力しないでください。
Choose an embedding model : 埋め込みモデルを選択します（例：amazon.titan-embed-text-v2:0）
Choose a chunking strategy (default, fixed-size, or none) : “Fixed-sized chunking” （固定サイズのチャンキング戦略）を選択します。
For fixed-size chunking, choose a maximum number of tokens per chunk : チャンクサイズを指定します。Amazon Titan 埋め込みモデルを使用する場合は “600” 、Cohere 埋め込みモデルの場合は “512” を入力します。これは約 1 ページ分のテキストに相当します。
For fixed-size chunking, choose an overlap percentage between chunks : チャンクのオーバーラップの割合として “10” を入力します。
Index Details : 4 つのエントリ（インデックス名、ベクトルフィールド名、メタデータフィールド名、テキストフィールド名）はデフォルト値のままにします。
「次へ」を選択します。
「スタックオプションの設定」ページの下部で、「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「次へ」を選択します。
「確認して作成」のページで、「送信」を選択します。

スタックのデプロイには約 10 分かかります。

サンプルコンテンツのアップロードとナレッジベースのテスト

このソリューションのデモサンプルには、架空のホテルチェーン Example Corp Hospitality Group に関する質問に答えることができる LLM ベースのホテルボットが含まれています。このホテルチェーンのコンテンツを、ナレッジベーススタック用に指定した S3 バケットにロードする必要があります。 CloudFormation スタックによって使用される S3 バケットは、スタックの「出力」タブで確認できます。

AWS Command Line Interface（AWS CLI）または AWS Management Console のいずれかを使用して、GitHub リポジトリの content セクションから以下のフォルダをアップロードします。PDF 版または Word 文書版（Word 版推奨）のいずれかを選択できます。
- corporate
- family-getaways
- luxury-suites
- party-times
- seaside-resorts
- waypoint-inns
完了すると、S3 バケットの最上位レベルには、それぞれ単一の Word または PDF ドキュメントを含む 6 つのフォルダがあるはずです。
Amazon Bedrock コンソールで、ナビゲーションペインの「ナレッジベース」を選択します。
CloudFormation によって作成されたナレッジベースを選択して開きます。「1 つ以上のデータソースが同期されていません」というメッセージが表示されます。
データソースを選択し、「同期」を選択します。

同期プロセスは数分しかかかりません。

データソースが同期された後、ナレッジベースを開くと、マネジメントコンソールの右側でナレッジベースによる質問回答をテストできます。必要なモデルが Amazon Bedrock の「モデルアクセス」ページで有効になっていることを確認してください。

LLM（Anthropic の Claude 3 Haiku など）を選択し、質問を始めましょう！アップロードしたサンプル文書を読んで、質問のアイデアをいくつか考えてみるとよいでしょう。

ハルシネーション検出スタックのデプロイ（オプション）

オプションの非同期ハルシネーション検出機能を使用したい場合は、このスタックをデプロイします。それ以外の場合は、次のセクションに進みます。この CloudFormation スタックは、非同期ハルシネーション検出が必要な RAG ベースのソリューションで使用できます。

“Launch Stack” を選択します
「次へ」をクリックし、スタック名を入力します（例：contact-center-hallucination-detection）
Select an LLM : ハルシネーション検出を実行する LLM を指定します。執筆時点では、ハルシネーション検出に推奨される LLM が 8 つあります。デフォルト値の “Claude V3 Sonnet” を選択します。
Create a Customer-Managed Key? : オプションで、“Create a Customer-Managed Key?” で、Amazon Simple Queue Service（Amazon SQS）キューと Lambda 関数の Amazon CloudWatch Logs ロググループを暗号化するための Amazon Key Management Service（AWS KMS）カスタマーマネージドキー（CMK）を作成します（本番環境では推奨）。

このスタックには2種類の Amazon CloudWatch アラームがあります：

ERROR アラーム – ハルシネーション検出作業を実行する Lambda 関数のコードの問題に関するもの
WARNING アラーム – Lambda 関数が実際にハルシネーションを検出した場合のためのもの

どちらのアラームタイプもオプションですが、有効化することを推奨します。

Create CloudWatch ERROR alarms? : ERROR アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。
Create CloudWatch WARNING alarms? : WARNING アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。
Subscribe to CloudWatch ERROR alarms? : オプションで、ERROR アラームを通知を受け取るためのメールアドレスを設定できます。
Subscribe to CloudWatch WARNING alarms? : オプションで、WARNING アラーム通知を受け取るためのメールアドレスを設定できます。
「次へ」を選択します。
「スタックオプションの設定」ページで「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「次へ」を選択します
「確認と作成」ページで、「送信」を選択します。

スタックのデプロイには約 1 〜 2 分かかります。
スタックが完了したら、CloudFormation スタックの「リソース」タブで作成されたリソースを確認できます。特に、 Lambda 関数のコードを確認してください。

アラーム通知用のメールアドレスを入力した場合は、サブスクリプションの確認を求めるメールリクエストを受け取るはずです。アラームが発生した場合に通知を受け取るには、メール本文の “Confirm subscription” をクリックしてください。

RAGソリューションスタックのデプロイ

Amazon Connect と統合する場合は、アカウントでインスタンスが利用可能であることを確認してください。まだない場合は作成できます。Amazon Lex ボットと Lambda 関数をデプロイするには、以下の手順を完了します：

“Launch Stack” を選択します
「次へ」をクリックし、スタック名を入力します（例：contact-center-rag-solution）
Lex bot name : Amazon Lex ボットの名前を入力します（例：hotel-bot）
Number of conversation turns for context : コンテキスト用に保持する会話ターンの数を指定します。これは異なるユースケースとデータセットに合わせて最適化できます。hotel-bot デモには、デフォルトの 4 を試してみてください。
Conversation logs group ARN : オプションで、Amazon Lex の会話ログ用に既存の CloudWatch Logs ロググループ ARN を指定します。会話分析スタックをデプロイする予定の場合は、これが必要になります。まだロググループがない場合は作成してください。
Number of AWS Lambda provisioned concurrency units (use 0 for no provisioned concurrency) : オプションで、Amazon Lex ボットハンドラー関数の Lambda Provisioned Concurrency 単位の値を入力します。ゼロ以外の数値を設定すると、Lambda コールドスタートを防ぐことができます。本番環境と内部テストに推奨されます。開発には、0 または 1 が推奨されます。
Create a Customer-Managed Key? : オプションで、Lambda 関数の CloudWatch Logs ロググループを暗号化するための KMS CMK を作成するオプションを選択します（本番環境で推奨）。
Connect instance ARN : Amazon Connect と統合する場合に指定します。Amazon Connect インスタンス ARN を入力します。
Connect contact flow name : Amazon Connect と統合する場合に指定します。スタックが作成する新しいコンタクトフローの名前を入力します。
Knowledge Base ID : 作成したナレッジベーススタックからナレッジベースIDを提供します。これは知識ベーススタックの「出力」タブで確認できます。
Knowledge Base S3 bucket : ナレッジベースで使用している S3 バケットを提供します（ナレッジベーススタックの「出力」タブで参照できます）。
SQS Queue Name : ハルシネーション検出スタックを作成した場合に、SQS キュー名を入力します。（ハルシネーション検出スタックの「出力」タブで参照できます）
SQS Queue Encryption Key ARN : ハルシネーション検出スタック用に KMS キーを選択した場合は、KMS キー ARN を入力します。
「次へ」を選択します。
「スタックオプションの設定」ページで「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「次へ」を選択します
「確認と作成」ページで、「送信」を選択します。

スタックの完了には数分かかります。

RAG ソリューションを試すには、Amazon Lex コンソールに移動し、hotel-bot ボットを開きます。ボットには英語言語セクションが 1 つあります。
ナビゲーションペインで「インテント」を選択し、このサンプルボットの意図を確認します。以下が含まれます：

ホテルチェーンと様々なホテルブランドの質問に関連するインテント – Accommodations、Amenities、CorporateOverview、Locations、Parking などが含まれます。これらのインテントは Amazon Lex によって RAG ソリューションにルーティングされます。技術的には、このような種類のリクエストを FallbackIntent で処理することもできるため、これらのインテントは省略して RAG に転送することも可能です。しかし、これらのインテント（およびそのサンプル発話）を含めることで、Amazon Lex に各ドメインの言語に関する情報を付与し、speech-to-text エンジンを最適化して文字起こしの精度を向上させることができます。さらに、これらのインテントを含めることは会話分析にも役立ちます。
SwitchBrand – このインテントは、会話の途中でユーザーが「他のホテルはどうですか？」などと言えるようにすることで、会話のフローを改善するために設計されています。
Booking – これは、発信者をライブエージェントキューにルーティングする例を示しています。
SpeakToAgent – このインテントは、発信者が特にライブエージェントをリクエストする場合のためのものです。
Welcome、Goodbye、Help – これらの会話サポートインテントは、会話の開始と終了、またはボットができることを尋ねるためのものです。
FallbackIntent – これは、他のインテントに一致しない質問やリクエストのための標準インテントです。このサンプルソリューションでは、そのようなリクエストもRAG ソリューションにルーティングされ、LLM がナレッジベース内のコンテンツに基づいて回答できるようになっています。
SelectKnowledgeBase と SelectLLM – これらは、ユーザーが RAG ソリューションに異なるナレッジベースインスタンス（複数利用可能な場合）や異なる LLM を使用するよう指示することを可能にします。これらのインテントはテスト目的で設計されており、通常は本番環境以外のデプロイメントにのみ含めるべきです。Amazon Bedrock で利用可能な任意の LLM で RAG ソリューションをテストできます。また、必要に応じて会話の途中で別のナレッジベースや LLM に切り替えることもできます。
ToggleLLMGuardrails（LLMガードレールの切り替え）とToggleLLMContext（LLMコンテキストの切り替え） – これらは、ユーザーがプロンプトベースの LLM ガードレールをオフまたはオンに切り替えたり、ナレッジベースからの情報取得を無効または有効にしたりすることを可能にします。これらのインテントはテスト目的で設計されており、通常は本番環境以外の環境にのみ含めるべきです。必要に応じて、会話の途中でこれらの設定をオフやオンに切り替えることができます。

Amazon Lex コンソールで「テスト」を選択して、ソリューションを試すことができます。

いくつかのサンプル会話を試してみてください。例えば：

“We’re looking for a nice place for a family vacation” (「家族旅行に素敵な場所を探しています」) と尋ねると、ボットは Example Corp Family Getaways offers family-friendly resorts…” (「Example Corp Family Getaways では家族向けの宿泊施設を提供しています…」) と応答します。
“Where are they located?” (「どこにありますか？」) と尋ねると、ボットは “The Example Corp Family Getaways resort in Pigeon Forge, Tennessee is…” (「Example Corp Family Getaways には…に所在地があります」) と応答します。
“Tell me more about the one in Pigeon Forge” (「ピジョンフォージについてもっと教えてください」) と尋ねると、ボットは “The Example Corp Family Getaways resort in Pigeon Forge, Tennessee is…” (「テネシー州ピジョンフォージの Example Corp Family Getaways リゾートは…」) と応答します。

質問のアイデアについては、アップロードしたサンプルドキュメントを参照してください。

ハルシネーション検出スタックをデプロイした場合は、テスト時に得た回答の評価を確認できます。ハルシネーション検出スタックの詳細ページの「リソース」タブで、「HallucinationDetectionFunctionLogGroup」エントリを選択します。これにより、Lambda ハルシネーション検出関数の CloudWatch Logs ロググループが開きます。ログステートメントを調査して、ハルシネーション検出プロセスがどのように機能しているかを確認できます。

Amazon Connect と統合している場合は、指定した Amazon Connect インスタンスに新しいコンタクトフローが作成されています。

音声でテストするには、電話番号を要求し、このコンタクトフローに関連付けて、電話をかけるだけです！

会話分析スタックのデプロイ（オプション）

このスタックは QuickSight を分析に使用するため、このスタックをデプロイする前に AWS アカウントですでに有効になっていることを確認してください。

“Launch Stack” を選択します
CloudWatch Logs log group for Lex Conversation Logs : Amazon Lex 会話ログを保存している CloudWatch ロググループの名前（※ ARNではない点に注意）を入力します。これは、RAGソリューションをデプロイした CloudFormation スタックにも使用した CloudWatch Logs ロググループです。
Purge Source Logs? : ロググループからソースログストリームを削除するオプションを選択します。テストの場合は “no” を選択します。
Redact Sensitive Data? : 会話ログから機密データを編集するオプションを選択します。テストの場合は “no” を選択します。
List of PII entity types to redact : 個人を特定できる情報（PII）のエンティティタイプを設定します。ここでは、デフォルト値のままにしておきます。
Minimum confidence score for Amazon Comprehend redaction : PII の信頼スコアのしきい値を設定します。ここでは、デフォルト値のままにしておきます。
Allow unredacted application logs? : データパイプラインの Lambda 関数の編集されていないログを許可するオプションを選択します。テストの場合は “yes” を選択します。
Create a Customer-Managed Key (CMK)? : KMS CMK を作成するオプションを選択します。
作成された CMK は、会話データを格納するためにこのスタックが作成する S3 バケットのデータを暗号化するために使用されます。これにより、どの IAM プリンシパルがデータを復号化して表示できるかを制御できます。この設定は本番環境で推奨されます。
Create CloudWatch ERROR alarms? : Amazon Lex データパイプラインで、ERROR アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。
Subscribe to CloudWatch ERROR alarms? : オプションで、ERROR アラームを通知を受け取るためのメールアドレスを設定できます。
Create CloudWatch WARNING alarms? : Amazon Lex データパイプラインで、WARNING アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。
Subscribe to CloudWatch WARNING alarms? : オプションで、WARNING アラーム通知を受け取るためのメールアドレスを設定できます。
「次へ」を選択します。
「スタックオプションの設定」ページで「次へ」を選択します
「確認と作成」ページで、IAM 機能メッセージを承認し、「送信」を選択します

スタックの完了には約 5 分かかるはずです。
以下の図はスタックのアーキテクチャを示しています。

Amazon Lex が CloudWatch Logs (1) に会話ログエントリを書き込むと、Amazon Data Firehose によって取得され、S3 バケット (2) にストリーミングされます。その過程で、Lambda 変換関数 (3) がデータの JSON 構造を簡素化し、クエリ目的でよりユーザーフレンドリーにします。Lambda 関数は Amazon Comprehend (4) を使用して機密データを編集することもでき、オプションで CloudWatch Logs ロググループからエントリを消費する際に削除することもできます。

スケジュールベース (5 分間隔) で、AWS Glue クローラー (5) が S3 バケットの新しいデータを検査し、Amazon Athena (6) がデータへの SQL インターフェースを提供するために使用するデータスキーマを更新します。これにより、QuickSight (7) のようなツールがデータのほぼリアルタイムのダッシュボード、分析、視覚化を作成できるようになります。

QuickSightダッシュボードの設定（オプション）

QuickSight ダッシュボードを作成する前に、Amazon Lex コンソールに戻り、ダッシュボード用のデータを生成するためにいくつかの質問をしてください。パイプラインがこの新しい会話データを処理して QuickSight で利用できるようになるまで約 5 分かかります。
QuickSight でダッシュボードと視覚化を設定するには、以下の手順を完了します。

QuickSight コンソールで、ユーザープロファイルアイコンを選択し、「QuickSight を管理」を選択します。
「セキュリティとアクセス許可」の、「QuickSight の AWS のサービスへのアクセス」の「管理」を選択します。
「Amazon S3」の下で、「S3 バケットを選択」を選択します。
会話分析スタックによって作成された S3 バケットへのアクセスを有効にします（12文字の一意の識別子が前に付いた「lex-conversation-logs」という名前になります）。書き込み権限を有効にする必要はありません。
「完了」を選択し、次に「保存」を選択します。
QuickSight メニューアイコンを選択して、QuickSight のメインページに戻ります。
ナビゲーションペインで「データセット」を選択します。
「新しいデータセット」を選択します。
データセットソースのリストから「Athena」を選択します。
データソース名を入力します（例：contact-center-analytics）。
「データソースを作成」を選択します。
「テーブルの選択」ウィンドウで、データベースを選択し、「lex_conversation_logs」テーブルを選択して、「データの編集/プレビュー」を選択します。

これにより、新しい QuickSight データセットが開きます。利用可能なさまざまな属性を確認し、テストからいくつかの結果を見ることができます。

データの表示速度を向上させるために、「クエリモード」に「SPICE」オプションを選択できますが、その場合、追加のテストに基づいてデータの更新を確認したい場合は、SPICEを更新する（または毎時自動更新スケジュールを設定する）必要があります。

現時点では、設定を「直接クエリ」のままにしておきます。
準備ができたら、「保存して視覚化」を選択します。
「新しいシート」ウィンドウでデフォルトを維持し、「作成」を選択します。

これにより分析ページが開き、視覚化の作成を開始できます。

自動テストノートブック（オプション）

自動テスト機能を試すには、SageMaker Jupyter ノートブックが必要です。または、Jupyter ノートブックをサポートする統合開発環境（IDE）やその他の環境でノートブックをローカルで実行することもできます。

Amazon SageMaker AI コンソールのナビゲーションペインの “Notebooks” を選択します。
「ノートブックインスタンスの作成」を選択します。
ノートブックに名前を付けます（例：contact-center-rag-testing）。
マルチスレッドテストを有効にするには、ml.m5.2xlarge（8 vCPU）やml.m5.4xlarge（16 vCPU）などの大きなインスタンスを選択することをお勧めします。使用していないときは停止することを忘れないでください。
プラットフォーム識別子のデフォルト設定（Amazon Linux 2、Jupyter Lab 4）を維持します。
「追加設定」の下で、「ボリュームサイズ（GB）」の設定を 50 GB に増やします。
「アクセス許可と暗号化」セクションの「IAMロール」で、ドロップダウンリストから「新しいロールを作成」を選択します（ロール作成ウィザードは使用しないでください）。
「IAMロールの作成」ウィンドウで、アクセスを提供したい S3 バケットを指定できます（このソリューションには必要ありません）。
「ロールの作成」を選択します。
「ノートブックインスタンスの作成」を選択します。
ノートブックインスタンスが利用可能になるまでには数分かかります。作成中に、Amazon Bedrock と Amazon Lex にアクセスするために必要なインラインポリシーを追加するためにIAM ロールを更新できます。
「ノートブックインスタンス」ページで、ノートブックインスタンス（例：contact-center-rag-testing）を開き、“IAM ロール ARN” の下のエントリを選択してロールを開きます。
次のインラインポリシー（GitHubリポジトリの notebooks/iam-roles フォルダで利用可能）を追加します。必要に応じてこれらのロールを修正して、リソースアクセスを制限できます。
ノートブックインスタンスが起動した後、「Jupyter を開く」を選択してノートブックを開きます。
以下をノートブックインスタンスにアップロードします（必要に応じて、ファイルをローカルで圧縮し、圧縮アーカイブをアップロードして、SageMaker で解凍することもできます）。
- bedrock_helpers.py – このスクリプトはノートブックの LLM インスタンスを設定します。
- bedrock_utils – すべてのサブフォルダとファイルをアップロードし、フォルダ構造が正しいことを確認してください。
- run_tests.ipynb – このノートブックはテストケースのセットを実行します。
- generate_ground_truths.ipynb – 質問のセットが与えられると、このノートブックは潜在的な正解の回答を生成します。
- test-runs – このフォルダにはExcelワークブックが含まれているはずです。
run_tests.ipynb ノートブックを開きます。
2 番目のセルで、bot_id と bot_alias_id の値を Amazon Lex ボットの値に置き換えます（これらは RAG ソリューションスタックの「出力」タブで確認できます）。
これらの値を更新した後、“Restart the kernel and run all cells” のアイコンを選択します。

ml.m5.2xlarge インスタンスタイプを使用している場合、test-runs/test-cases-claude-haiku-2024-09-02.xlsx ワークブックの 50 のテストケースを実行するのに約 1 分かかるはずです。完了すると、ノートブックの test-runs フォルダに対応するテスト結果ワークブックが見つかるはずです。

数分後、会話分析ダッシュボードでもテスト結果を確認できます。

ソリューションをユースケースに適応させる

このソリューションは最小限の作業で特定のユースケースに適応させることができます：

Amazon Bedrock ナレッジベースのサンプルコンテンツを置き換える – S3バケットのコンテンツを置き換え、ユースケースに合ったフォルダ構造に整理します。置き換えたコンテンツ用に新しいナレッジベースを作成できます。
Amazon Lex ボットのインテントをユースケース用のインテントで置き換える – ユースケース用に有効にしたい対話を反映するように Amazon Lex ボットの定義を変更します。
bedrock_utils コードの LLM プロンプトを変更する – Amazon Lex ボット実行 Lambda 関数で、bedrock_utils フォルダの LLM プロンプト定義を確認します。例えば、LLMベースのエージェントの役割に関するユースケース固有の定義を提供します。
必要に応じてボットハンドラーコードを変更する – Amazon Lex ボット実行 Lambda 関数で、TopicIntentHandler.py 関数のコードを確認します。知識ベース検索では、このコードはトピックとしてサンプルホテルブランドを使用する例を提供します。このメタデータ検索クエリを、ユースケースに適したものに置き換えることができます。

クリーンアップ

おめでとうございます！AWS サービスを使用して音声対応のコンタクトセンター生成 AI エージェントソリューションをセットアップするためのすべての手順を完了しました。
ソリューションを AWS アカウントにデプロイする必要がなくなった場合は、デプロイしたCloudFormation スタック、および作成した場合は SageMaker ノートブックインスタンスを削除できます。

結論

コンタクトセンター生成 AI エージェントソリューションは、Amazon Bedrock、Amazon Bedrock Knowledge Bases、OpenSearch Serverless、Amazon Lex などのサービスを使用して、コンタクトセンターでの Q&A 会話を自動化するためのスケーラブルで費用対効果の高いアプローチを提供します。
ソリューションコードはオープンソースとして提供されています。これを自分のソリューションの出発点として使用し、GitHub プルリクエストを通じて修正と機能を提供することで、より良いものにするのを手伝ってください。GitHub リポジトリを参照してコードを調査し、最新の変更についてはCHANGELOG を、最新のドキュメント更新については README を確認してください。
専門家のサポートについては、AWS Generative AI Innovation Center、AWS Professional Services、および AWS Partners がお手伝いします。

翻訳はソリューションアーキテクト新谷が担当しました。原文はこちらです。

Amazon Web Services ブログ