Amazon Connectでコールセンター向けAIチャットボットを構築する際、Amazon Lexを利用すべきケースとそうでないケース
2024.01.05はじめに
Amazon Connectでコールセンター向けAIチャットボットを構築する際、Amazon Lexの利用すべきケースと利用すべきでないケースを考えてみました。
私はこれまでに、以下のようなConnectを利用したコールセンター向けAIチャットボットの構築経験があります。
- [電話予約の無人化]Amazon Connect + GPT-4 JSONモード + Whisperで、1回の発話から予約情報(日付,時間など)を抽出
- 【RAG】Amazon BedrockとConnect、Kendraを利用し、社内情報や社外の最新情報などの取り込んだデータをもとに回答するコールセンター向けAIチャットボットを構築してみた
- AIチャットボットで問い合わせに対応し、回答が難しい内容に限り担当者にエスカレーション[Amazon Connect + Lex + Bedrock]
大まかな処理の流れは、顧客の発話を文字起こしし、その内容を生成AIに読み込ませて、プロンプト次第で予約状況を抽出したり、RAGでの回答をしたりしました。
処理の中で、「顧客の発話を文字起こし」の実装方法は、個人的には以下の２通りに分かれると考えています。
- Amazon Lexを利用し、文字起こしする（Lexの裏でAmazon Transcribeによって、ストリーミング処理で文字起こしされる）
- 発話音声をKinesis Video Stream（KVS）に録音し、Lambdaで、Amazon TranscribeやOpenAI社のWhisper APIなどを利用し文字起こしする（バッチ処理）
主に上記の２つの構成が考えられますが、それぞれ適しているケースがあります。
今回は、Lexを利用すべきケースと、KVSの方が適しているケースについてそれぞれ解説します。
Lexを利用すべきケース
構築や運用をできるだけ容易にしたい場合
まず、できるだけ簡単に構築し、リリース後も運用を楽にしたい場合は、KVSよりもLexが適しています。
理由は、２点あります。
- KVSに比べて、Connectのフローの作り込みが不要
- KVSに比べて、Lambdaのコード量が少ない
1. Connectのフローの作り込み
AWSのチャットボットサービスとして位置づけられているLexでは、必要な機能が標準で備わっていますが、KVSの場合は、チャットボットとしての機能がなく、Connectのフローの作り込みが必要になるためです。
例えば、電話予約を行うAIチャットボットを構築する場合、以下のようなやりとりが発生します。これを考慮して構築する必要があります。
- ユーザー側) 電話をかける
- Connect側) 予約に必要な各項目をヒアリング
- ユーザー側) 各項目をそれぞれ伝える
- Connect側) ヒアリング項目を全て取得後、ユーザーが発話した予約内容を復唱する
- ユーザー側) 正しい場合、「はい」、間違っている場合、「いいえ」と伝える
- Connect側) 返答が「はい」の場合は、予約を完了する。「いいえ」の場合、再度ヒアリングするか、担当者にエスカレーション
上記のようなチャットボットを構築する場合、Lexでは以下の機能が標準で備わっています。
- 必要な予約情報をヒアリング
- 一部の予約情報をうまく聞き取れない場合、その情報のみを再度ヒアリング
- 全ての予約を取得できたら、復唱する
- 顧客が「はい」と言ったら予約を完了し、「いいえ」と言ったら、予約はしないという分岐処理
KVSの場合は、上記の処理をConnectフローとLambdaで実装する必要があるため、結果として複雑なフローになり、Lexに比べて構築や運用負荷が高いです。
実際のフロー
Lexで構築した場合とKVSの場合で、Connectフローがどの程度差があるか、ご紹介します。
電話予約を行うAIチャットボットを構築した下記の記事から、Connectフローを抜粋します。
Lexの場合は、下記のフローで実現できます。[顧客の入力を取得する]でLexボットを呼び出しています。
また、Lexボットの構築自体は、そこまで複雑なものではありません。
対して、KVSの場合は下記のフローで実現できます。
フローを比較すると、KVSのほうがブロック数が多くて複雑だと分かります。
2. Lambdaのコード量
Lambdaでのコード量に関しても、KVSの方がコード量が多いです。
コード量が多い理由は、KVSの場合は、文字起こし処理をLambdaで実装するためです。
Lexの場合は、Lex側で自動で文字起こししてくれるので、Lambdaは不要ですが、KVSの場合は、Lambdaで文字起こしの処理を実装する必要があります。
KVSでの具体的な処理内容は、下記の記事で紹介しています。100行弱のコードが必要です。
構築はできるだけ短くしたい、構成はできるだけシンプルにしたい、本番稼働後の運用は楽にしたい場合は、Lexでの文字起こしが適しています。
AWSのみで構築するケース
AWSのみで構築する要件がある場合です。企業によっては、AWSのみで完結しなければならない、セキュリティポリシーやルールが存在することがあります。
その場合は、Lexを利用することで、AWSのサービスのみで完結できます。
KVSの場合でもAmazon Transcribeを利用することで、AWSのみで構築が可能ですが、ユーザー体験がよくありません。
Transcribeで文字起こしするには、数秒の録音データでも約7秒の処理時間がかかります。さらに、Transcribeで文字起こしするために、LambdaがKVSからメディアデータを取得し、その中から音声データを抽出し、WAV形式の音声ファイルに変換する処理も行う必要があります。
つまり、KVS + Transcribeの場合、僅か数秒の発話であっても、文字起こしに最低7秒かかるため、実装は可能ですがユーザー体験としてよくありません。
ちなみに、KVS + Whisper APIでの場合、Whisper APIでの文字起こしにかかる時間は、数秒の発話であれば1秒程度です。AWSのみという制限がなく、かつ、KVSを採用する場合、Whisper APIなどのAWSではない文字起こしサービスも検討するとよいでしょう。
KVSを利用すべきケース
続いて、LexではなくKVSを利用すべきケースを紹介します。
1回の発話時間が15秒以上
発話が15秒以上かかる場合、KVSが適しています。
Lexでは、1回あたりの発話時間が最大15秒までしか聞き取りができない制限がありますが、KVSであれば、制限がありません。
AIチャットボットでLexを利用する際の制限は、下記ブログにまとめておりますのでご一読ください。
ただし、KVSでは数分程度の発話を聞き取ることができますが、電話中に回答が必要な場合、先程も話題に出たLambdaのタイムアウト8秒という制限がありますので、発話時間が長いと8秒を超えて、エラーとなります。
下記の記事で検証しましたが、「KVS + Whisper API + 生成AIで文字起こしの内容を要約」をLambdaで処理する場合、発話時間が20秒程度であれば、Lambdaの実行時間は、4秒~5秒程度でした。
発話時間が70秒の場合、Lambdaの実行時間は、10~12秒程度でしたので、１つの目安にしてください。
ただし、電話中に返答ではなく、顧客が要件を伝えた後に、折返しの電話で自動応答する場合は、発話時間が数分であっても問題にはなりません。
Transcribe以外の文字起こしサービスを利用したい場合
発話を文字起こしする際に、Transcribe以外のサービスを利用したい場合は、KVSを利用する必要があります。
Lexでの文字起こしは、Transcribeが裏で利用されており、変更はできません。
以前、TranscribeとWhisper APIの日本語の文字起こしの精度を比較しましたが、個人的にはWhisper APIの方がよい印象でした。
このように、Transcribeではなく、Whisper APIなどの他の文字起こしサービスを利用する際は、KVSを利用する必要があります。
カスタム語彙を利用する
固有名詞のヒアリング精度を向上させるため、TranscribeやWhisper APIでは、カスタム語彙が利用できます。
一方、Lexの場合、日本語ではカスタム語彙が利用できません。今後のアップデートに期待しましょう。
Lexの場合、スロットタイプAMAZON.FreeFormInputとAmazon Bedrockの組み合わせで、文字起こした一部の内容を固有名詞に変換は可能です。
最後に
今回は、Connectでコールセンター向けAIチャットボットを構築する際、LexとKVSのそれぞれ利用すべきケースを考えてみました。
それぞれ、適したケースがありますので、参考になれば幸いです。
