こんにちは。AWS CLIが好きな福島です。
はじめに
今回は、AWSを利用したチャットボットアプリを考えたため、1例としてご紹介いたします。
構成例②も公開したため、ご興味がありましたらご覧ください。
チャットボットアプリのイメージ
構成例のご紹介の前にチャットボットアプリのイメージを載せておきます。
RAG(Retrieval-Augmented Generation)を利用し、サーバーワークスの役員も聞いてみます。
補足ですが、RAGとは関連情報を「検索（Retrieval）」し、その情報を基に新しいテキストを「生成（Generation）」することで、より精度の高い答えを出力する手法です。
今回は関連情報として、会社概要や役員の紹介ページを取り込むことでサーバーワークスの役員に関する情報を聞き出していますが、この手法を使わずに質問をすると以下のように間違った回答が返ってきます。 これをRAGを使うことで上記動画のように正確な情報を回答させることができます。
構成
AWSを利用したチャットボットアプリ構成の1例は以下の通りです。
構成の説明
AWSへのプライベート接続
- オンプレミス環境からAWSへのアクセスには、Direct ConnectやSite-to-Site VPNを使用してプライベートな接続を確立できます。
- Direct ConnectやSite-to-Site VPNが利用できないが、IP制限だけで問題ない場合は、ELBをパブリックに配置し、インターネット経由でアクセスすることもできます。
ECSによるアプリケーション実装
- ECSを用いて、フロントエンド及びバックエンドの機能を実装します。
- フロントエンドではStreamlitを利用し、バックエンドではLangChainを主用しています。
会話履歴の保存と利用
- DynamoDBに会話履歴を保存し、過去のやりとりを含めた対話が可能になります。
質問応答システム
- Bedrockを使用して質問に対する回答を生成します。RAGを使用する場合は、埋め込みの際にも利用しています。
ログの保存と分析
- モデルの実行ログはCloudWatch LogsやS3に保存します。
- クイックにログを確認したい場合は、CloudWatch Logsを使い、長期保存にはS3を使うイメージになるかなと思います。
RAGのセットアップ
- RAGのセットアップには、ドキュメントを格納するためのS3、ドキュメントからインデックス（Faissを使用して作成）を生成するLambda関数、そしてインデックスを配置するS3が含まれます。
効率的なインデックス利用
- ECSを使用してRAGを利用する際は、S3に配置されたインデックスをダウンロードし、それを基に回答を生成します。
- 毎回S3からインデックスをダウンロードするのは非効率なため、インデックスが更新された場合にのみダウンロードするようにします。
検討が必要な点
私の中で未検討なこともあるため、以下に記載します。
チャットボットアプリケーションのユーザー認証について
今回は、ユーザー認証をしない構成ですが、StreamlitやCognitoなどを利用することで実装が可能と考えられます。
会話履歴について
今回の構成では、会話履歴はStreamlitのセッションごとに保存しているため、ページを更新するなどした場合、会話履歴がリセットされます。 これはユーザー認証を実装した上でユーザーごとに会話履歴を保存することでより使いやすくすることはできると思います。
操作ログについて
今回の構成は、操作ログを取得することは可能ですが、特定のユーザーの操作を追跡することはできません。 ユーザー認証機能を導入し、ログ情報をカスタマイズすることで、ユーザーの操作を特定できるようになりそうです。
インデックスの更新タイミングについて
今回の構成は、S3にドキュメントが格納されたことをトリガーにインデックスを作成するLambdaを実行することを想定していますが、 この場合複数のドキュメントをアップロードした際にドキュメントの数分、Lambdaが実行されることになると思うので、 Lambdaを定期実行するなどの検討が必要かなと思いました。
インデックス作成用のドキュメントを取得する方法について
現在は手動でドキュメントをアップロードする設計ですが、これによりデータの二重管理が発生してしまいます。
実際の運用を考えた場合、一次ソースから直接データを取得する仕組みが必要になります。
※ドキュメントの更新頻度が少なければ今回の構成でも成り立つかもしれません。
回答に含まれるソースドキュメントについて
RAGシステムの構成において、回答に利用するソースドキュメントは、今回の構成ではS3からダウンロードしたものをLambdaでインデックス化しています。 このため、チャットボットが参照するソースドキュメントの情報は、インデックス作成時に指定されたパスのものであり、ユーザーがアクセスすることはできません。 ※以下は私のローカルでインデックスを作成したため、私のローカルのパスが表示されています。
AIが間違った回答を生成する可能性もあるため、生成された内容は参考程度に留め、ソースドキュメントを確認すべきですが、現在の構成ではその確認が行えなく課題かなと思います。 ただ、この問題は、一次ソースから直接データを取得する仕組みを開発することで同時に解決することができそうです。
終わりに
今回は、AWSを利用したチャットボットアプリの構成例をご紹介いたしました。
まずはお試しでということであれば、今回の構成でも充分かなとは思いますため、ご興味がありましたら、ぜひサーバーワークスにご相談ください！
