re:Invent 2024: ElastiCacheとAuroraを使用したサーバーレスチャットボット構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Build serverless chatbots using Amazon ElastiCache & Aurora PostgreSQL (DAT326)
この動画では、Serverlessなチャットボットを構築するためのアーキテクチャパターンについて、AZFlightsという架空の旅行会社を例に解説しています。Amazon ElastiCacheとAurora PostgreSQLを組み合わせたRAGベースのアーキテクチャにより、サブミリ秒レベルの応答時間とコスト最適化を実現する方法を、実際のデモを交えて説明しています。さらに、Bedrock AgentsとKnowledge Baseを活用することで、複数のステップを必要とする複雑なタスクをオーケストレーションする方法も紹介しています。Vector Embeddingのキャッシング手法やI/O最適化ストレージ構成による40%のコスト削減など、実践的な最適化手法も含まれています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
re:Inventセッション「Serverless Chatbots with Amazon ElastiCache and Aurora PostgreSQL」の概要
おはようございます。re:Inventの3日目へようこそ。カンファレンスに参加していると、時間が驚くほど早く過ぎていきますね。今朝考えていたのですが、日曜日が昨日のようで、もう水曜日になっています。ちょうど折り返し地点ですね。これからもたくさんの素晴らしいことが待っています。ちょっとお聞きしたいのですが、re:Inventに初めて参加される方は手を挙げていただけますか？なるほど、過半数の方ですね。素晴らしいです。素晴らしいセッションやアナウンスメントを楽しんでいただけていることを願っています。今週は多くの発表がありますよ。
私はAWSのPrincipal Worldwide PostgreSQL Specialist Solutions ArchitectのShayon Sanyalです。主にAurora PostgreSQLに携わっており、最近は特にgen関連に注力しています。本日のセッションは「Building Serverless Chatbots with Amazon ElastiCache and Aurora PostgreSQL」です。たくさんの内容をカバーする予定です。多くの方が初参加とのことですが、このセッションは通常のブレイクアウトセッションとは少し異なります。サイレントセッションですので、ご質問がある場合はセッション終了後に外でお会いしましょう。どんな具体的なトピックについても詳しくお話できます。
それでは始めましょう。こんな状況を想像してみてください：来週ハワイへの休暇を計画していて、フレンドリーなChatbotにチケットの予約を依頼したところ、延々と待たされる状況に陥ってしまいました。とてもイライラしますよね。 メールアプリに切り替えて確認すると、皮肉にも競合他社が、予約しようとしていたのと同じチケットでお得な料金を提供しているのが目に入ります。 旅行予約のBotに戻ってみると、まだ処理中です。これらはすべて30秒以内の出来事です。そうしているうちにすぐに競合他社のウェブサイトに移動し、お得な料金を確認して、そちらでチケットを予約してしまいます。
このように、旅行業界では状況は非常に素早く変化します。顧客の注意が逸れたり、エンゲージメントが途切れたりすることは、顧客の損失、収益の損失、販売機会の損失につながります。顧客の維持率を最大限に保つことが非常に重要なのです。 本日のセッションでは、これをいかに顧客にとって最適化できるかについて、その概要を説明していきます。Chatbotの進化について簡単に触れた後、アーキテクチャパターンやアーキテクチャの概要、そして実際の顧客が本番環境でどのように実装しているかについて、多くの時間を割いて説明します。
Amazon ElastiCacheやAurora PostgreSQLといった特定のサービスを使用した実装方法についても見ていきます。この2つのサービスに重点を置きます。また、大規模言語モデルプロバイダーとしてAmazon Bedrockについても取り上げます。Retrieval Augmented Generation（RAG）についても重点的に説明します。そして、RAGの先にある次のステップとして、Bedrock Agentsについても触れていきます。これらの内容が皆さんの思考を正しい方向に導き、このセッションの最後には私が意図した理解に到達していただけることを願っています。
Chatbotの進化と旅行業界における課題
2023年は間違いなくGenerative AIの年でした。Chatbotの大きな波が押し寄せ、企業からは「モデルを自社開発すべきか、それとも既存のものを購入すべきか？」「データセキュリティをどのように確保すべきか？」といった質問が相次ぎました。セキュリティの懸念は非常に大きな問題でした。当時、RAGはまだ表面的な段階でした。「モデルが誤った情報を生成したらどうするか」「望ましくない応答が返ってきたらどうするか」といった懸念がありました。また、既存システムとの統合に関する質問も多く、「既存のRelationalデータストアやNon-relationalデータストアとどのように連携させるか」「既存のインフラにChatbotアーキテクチャをどのように組み込むか」といった課題がありました。
そして1年後の現在、状況はどうでしょうか？Chatbotはファーストクラスの市民となりました。企業にとって、製品やサービスに関する一般的な質問に答えるBasicなChatbotの導入は、最低限の要件となっています。企業におけるRAGの概念も一般的になってきており、組織内の分断されたサイロ - ヘルスケアデータ、財務データ、マーケティングデータ、CRMデータなどの統合が課題となっています。
課題は、これらすべての問題を解決する1つのChatbotで、統一されたアプローチをどのように実現するかということです。企業におけるRAGの重要性が高まっていますが、さらに重要なのは、Agentsが注目を集め始めていることです。これが業界のトレンドであり、進むべき方向性です。Agentsは自律的な意思決定を行うボット、つまり自身の思考プロセスを通じて意思決定を行うChatbotです。業界では、Chain of Thought思考、ステップバイステップ実行、マルチステップ実行、オーケストレーションといった用語が使われています。これらについては後ほど詳しく説明しますが、Agentsは確実に標準となりつつあります。
ユースケースについて話すと、様々な分野の顧客で典型的なシナリオを見てきました。 業界や分野を超えて共通するユースケースの1つが、カスタマーサポートです。製品やサービスに関する同じような質問が繰り返されるFAQを考えてみてください。Chatbotが人手による作業を軽減できます。また、感情面での利点もあります。人間が1日1000回も同じ質問に答えていると、どうしてもイライラしてしまうものです。ボットは感情に左右されることなく、標準的なプロセスに従って特定のタイプの質問に対応できます。
旅行業界は、フライト予約やレコメンデーションなど、非常に大きな分野です。 Amazon.comなどのEコマースサイトのように、顧客が気に入りそうな商品をレコメンドするRetailアシスタントもあります。 ヘルスケア分野も成長し始めていますが、データセキュリティの懸念から、まだ完全な普及には至っていません。患者の医療履歴や症状に関する質問に答える患者ケアコンシェルジュサービスなど、進化を続けています。
本日は、特定の立場から考えていただきたいと思います。先ほどのデモでご覧いただいたように、終わりのない待機ループに悩まされていたAZFlightsという会社に焦点を当てていきます。私たちには2つのシンプルな目標があります。1つ目は、フライト予約体験の最適化です。エンドレスな待機ループがお客様にとって決して快適な体験ではないことはご覧の通りですので、この問題を解決していきます。2つ目は、事業の多角化です。フライトチケットの予約が主力事業ではありますが、次の休暇を計画しているお客様向けにパーソナライズされたおすすめプランやイチネラリーの提案にも事業を拡大していきたいと考えています。
私たちには豊富な情報が利用可能です。このような企業と仕事をする際、通常はリレーショナルおよびノンリレーショナルのデータストアに既に多くのデータが存在しています。ここでは、一般的にCustomer 360データと呼ばれる、過去の旅行情報、Web履歴、好み、顧客プロファイルなどを扱っています。さらに、フライト情報、ホテル情報、進行中のプロモーション、類似した旅行者プロファイルなどの企業データも保有しています。この既存の豊富な情報をすべて活用していきたいと考えています。
RAGアーキテクチャとAmazon ElastiCacheの役割
それでは、このアーキテクチャの構築を始めましょう。私たちが企業の開発者やアーキテクトとして、まさに始めようとしているところだと想像してください。ハイレベルな視点で見ると、ユーザーが「バリのビーチリゾートを探して」といった簡単な質問をしてきた時、私たちのTravel Assistantは、Knowledge BaseやVector Storeから関連情報を取得します。ここには、ドキュメントソースやCustomer 360データの豊富な情報が格納されています。この情報を取得し、ユーザーからの質問と組み合わせて、Augmented Promptあるいは Context-aware Promptと呼ばれるものを形成します。
Knowledge BaseやVector Storeからのコンテキストは、インターネットスケールの数十億規模のデータでトレーニングされたLLM（Large Language Model）に送られます。LLMは、ビーチフロントリゾートの好みやユーザーの予算プロファイルなどを考慮しながら、ユーザーに対してコンテキストに基づいてカスタマイズされた回答を提供する役割を担っています。これが、私たちが構築を目指すハイレベルなアーキテクチャです。
では、これをどのように実装できるか見ていきましょう。先ほどのアーキテクチャで見た要素の中で、中心となっていたのがPromptでした。簡単なおさらいとして、これはPrompt Engineeringの詳細な説明ではありません。Promptは本質的に、Large Language Modelに特定の方法で応答するよう指示する一連の入力です。フレンドリーな口調やプロフェッショナルな口調で回答をカスタマイズできるという点で創造性を発揮できるため、非常に有用です。Prompt Engineeringは過小評価されがちですが、実際にはとてもシンプルで、経済的に効率的に問題を実装・解決できる手法なのです。
AZFlightsの一員としてのロールプレイ演習に戻って、ユーザー向けのプロンプトを作成する際のビルダーの視点について見ていきましょう。 まずはシンプルなところから始めます：あなたはAZFlightsの親切な旅行アシスタントとして、常にフレンドリーで会話的、かつプロフェッショナルなトーンを保ちます。このプロンプトは、Customer 360データを含む指定されたデータソースから関連データを取得するよう指示しています。Amazon ElastiCacheは、チャット履歴や設定などの要素を保存するのに強力なツールです。私たちは、チャットボットにAmazon ElastiCacheに保存されているユーザー設定を考慮し、簡潔でありながら十分に役立つ情報を提供するよう求めています。
チャットボットにおけるユーザー設定とキャッシングについて、そもそもなぜキャッシュが必要なのでしょうか？ その理由は2つあります。1つ目は速度です - キャッシングサービスはマイクロ秒単位のレイテンシーを提供します。 これは、リレーショナルでもノンリレーショナルでも、従来のデータベースアーキテクチャでは前例のない速さです。現代のチャットボットでは、ユーザーが簡単にメールチェックや競合他社でのチケット予約に切り替えられるため、ユーザーエクスペリエンスが極めて重要です。キャッシングソリューションを実装することで、一貫したミリ秒以下の応答時間を実現し、データベースの往復を排除し、安定したパフォーマンスを確保できます。
2つ目の重要な理由は運用コストの削減です。顧客が同じ質問を繰り返す場合、典型的なRAGベースのアーキテクチャでは、検索距離の再計算、埋め込みの再生成、ユーザークエリの埋め込みへの変換、データベースからの類似レスポンスの取得、プロンプトでの補強が必要です。このプロセスには複数のデータベース往復が必要です。頻繁に尋ねられる質問と回答のペアをキャッシュすることで、総運用コストを大幅に削減できます。これらがキャッシングを実装する説得力のある理由です。 AWSスタックには、Amazon ElastiCacheがあり、さらにServerlessオプションもあります。
私がニューヨークの例を挙げましょう。夜11時にJFK空港で足止めされるのは大変です。フライトがキャンセルされた場合のホテル探しは本当に大変で、次のフライトを見つけるのも同様に困難です。朝の便に乗る場合は、近くのホテルに一泊する必要があります。同じフライトに200人の乗客がいれば、全員が必死でホテルを探すことになります。このような場合、プロビジョニング型のキャッシングサービスやクラスターがあっても、その時点で上下のスパイクに対応するキャパシティを計画する時間やリソースがありません。ホテル予約が急増する中、通常時には動的にスケールアップ・ダウンできるソリューションが必要です。Serverlessはこのアーキテクチャ全体にとても適しています。
キャッシングとその必要性を理解したところで、Amazon ElastiCache Serverlessについて見ていきましょう。これは業界で一般的な3つのエンジン：Redis、Memcached、Valkeyに対応した完全マネージド型のキャッシングソリューションです。 これにより、単一のクライアントエンドポイントを通じて接続でき、クライアントアプリケーションはこのエンドポイントに接続するだけです。内部では、接続先となる一連のプロキシノードが存在します。アプリケーションの観点からは完全に透過的です。顧客は実際にどこに接続しているかを知る必要はありませんが、これは本質的にロードバランスされたネットワークです。このプロキシレイヤーがクラスター全体を抽象化するので、需要のスパイクに対応するためにシャードやキャパシティ、リソースを追加する必要がある場合でも、心配する必要はありません。このアーキテクチャから自動的にリソースの追加と削除が行われます。
Vector StoreとAurora PostgreSQLの重要性
このアーキテクチャは、AZFlightsが高いキャッシュヒット率を達成するのに適しています。 キャッシュングソリューションであるため、非常に高いキャッシュ率を実現できます。毎回一貫してサブミリ秒での顧客レスポンスを確保し、データベースの負荷を軽減することができます。 AWSのキャッシングスタックにおける各マネージドサービスで提供されるサービス保証により、99.99%の可用性とアップタイムを維持します。 さらに、閑散期やホリデーシーズンのピーク時、緊急事態、予期せぬ状況でも自動的にスケールすることができます。フライトがキャンセルされた際などにアクセスが急増しても、自動的かつ容易にそれらのサージに対応できます。
最重要要件である高速データアクセスについて説明しましたが、次はそのデータに意味を持たせる方法を見ていきましょう。キャッシングソリューションは、投入されたすべてのデータに対して即座にキャッシュを提供しますが、キャッシュしているデータに対するインテリジェンスや意味付けはありません。レスポンスを取得する際にユーザーの好みやプロファイルに合わせる必要があるため、データに意味とインテリジェンスを付加したいと考えています。ここで重要な疑問が生じます：なぜVector Storeが必要なのでしょうか？ プロンプトでは、多くの顧客がVector Storeとして利用しているpg_vector拡張機能を持つAurora PostgreSQLから旅行関連情報を取得する必要がありました。これは、なぜ単にキャッシングソリューションで一時的に保持するのではなく、永続的に保存する必要があるのかという疑問を投げかけます。
その理由は次の通りです： 質問と回答のペアを追加する際、前の質問に対する追加の質問があった場合、Chatbotには記憶や保持機能がありません。 会話履歴がないためコンテキストを失い、その質問に対して適切に応答することができません。そのため、Chatbotが提供する応答に何らかのインテリジェンスと方法論を追加する必要があります。AZFlightsのシナリオでは、ホテル、フライト、人気の休暇先に関する情報を含むCSV、PDFファイル、あるいはリレーショナルデータベースなどのドキュメントをベースとした知識ソースを投入します。そしてそのソース、つまりドキュメントは、Embedding Modelを使用してベクトル処理されます。
重要な点として、ソースはテキストである必要はなく、マルチモーダルモデルが increasingly popularになっているため、画像や動画でも構いません。例えば、バリの海岸の写真を使用して、「バリでこれに似たようなリゾートを探して」といった質問をユーザーができるようになります。このプロセスは、ドキュメントソースをEmbedding Modelを通してVector Storeに取り込む際に発生します。
Embedding Modelは、テキスト、画像、動画などの人間が読める形式の自然言語を、ベクトルと呼ばれるN次元の浮動小数点数に変換します。整数、バイナリ、浮動小数点数といった一般的なデータ型ではなく、何千倍もの3次元配列のような巨大なベクトルという新しいデータ型を扱います。これは情報の豊かさを表現し、Vector Databaseに保存するソースにベクトルの形で意味を付加します。
ユーザーが「ナイトライフが充実しているビーチリゾートが欲しい」といったような質問をする場合、それは自然な言語での簡単な質問です。その質問は英語でもフランス語でも、どんな言語でも構いません。重要なのは、ユーザーの質問も同じEmbedding Modelを使って変換されるということです。もし異なるEmbedding Modelを使用すると、同じ質問に対して全く異なるベクトルが生成され、すべての処理に支障をきたしてしまいます。質問が浮動小数点数に変換されると、Vector StoreからSimilarity SearchやSemantic Searchと呼ばれる処理を実行し、関連する情報を抽出してユーザーに最適な回答を返します。
Vector Storeに関して、AWSは多数のVector Search機能を備えたデータベースを提供しています。実際、現在では当社のフルマネージドデータベースのほとんどがこの機能を提供しており、将来的には、データベースとアナリティクスサービスの両方でVector Search機能が提供される予定です。その一例が、pgvector拡張機能を備えたPostgreSQLです。これは単にN次元の浮動小数点数を格納するためのもう一つのデータ型です。このデータ型は、Similarity Search用のインデックスと特定の関数を導入することで大きなメリットをもたらします。Amazon Aurora Serverless v2はPostgreSQLとMySQLの両方のエンジンで提供されていますが、今回はpgvector拡張機能を備えたPostgreSQLエンジンに焦点を当てています。
Aurora Serverless v2は、ご存じない方のために説明すると、Amazon Auroraのオンデマンド自動スケーリング構成で、Elastic Scalingと同様の機能を実行できます。コンピュートノードは必要に応じて自動的に垂直方向に拡大・縮小し、容量を追加・削減します。これはAZFlightsにとって理想的な選択肢です。なぜなら、需要に応じて自動的にスケールできるため、検索のスパイクや急な予約の殺到にも最小限の労力で対応できるからです。最近、Aurora Serverless v2でScale-to-Zero機能をリリースしました。これにより、ワークロードがない場合は最小ACU容量の支払いが不要になり、直接的なコスト削減が可能になります。さらなるコスト削減は、昨年のre:Invent周辺で発表したI/O最適化ストレージ構成で実現可能です。
Amazon Bedrock Knowledge Baseとその実装
さらに、I/O最適化ストレージ構成により、I/Oコストをゼロにすることができます。Chatbotや生成AIソリューションの構築、距離計算やSemantic Searchの実行など、これらの操作は非常にI/O集約的です。I/Oコストが完全に無効化されることで、Chatbotに関する予測可能な事前コストを見積もることができます。この最適化により、お客様は最大40%のコスト削減を達成できることが確認されています。
3つ目のメリットは、後のスライドで詳しく説明するBedrock Knowledge Baseです。AuroraとVector Storeの直接統合により、カスタマーサポートエージェントは大規模なスケーリングが可能になります。複雑なインフラストラクチャを管理したり、特殊なパイプラインを構築したりすることなく、何千もの地域や場所にわたって顧客サービス機能を完全に自動化できます。これについては後ほど詳しく説明します。最大のメリットは、Vector DataをTransactional DataやCustomer 360 Dataと共に配置できることで、全体的なアーキテクチャが簡素化されることです。専用のVector Databaseとの間でデータをやり取りしたり、クライアントドライバーの接続性を心配したりする必要がありません。JDBCやODBCなどの既存のクライアントドライバーは、このアーキテクチャでシームレスに動作します。さらに、Fast Clone、Global Database、Zero ETLなど、従来のAuroraの機能も利用できます。
それでは本題に入りましょう。私たちは本番環境で使用できる旅行アシスタントを構築しようとしています。これをどのように進めていけばよいでしょうか？これを旅のように考えてみましょう - 千里の道も一歩から始まるのです。これが最初のステップです。 まず、ユーザーが質問をする基本的なアーキテクチャから始めます。例えば「Las VegasからHawaiiまでのチケットを予約できますか？」といった質問です。 この場合、言語モデル（Amazon Bedrock）は、データソースやキャッシュにアクセスすることなく、一般的な応答を提供します。これはシンプルなインタラクションループですが、この基本的な統合部分を土台として発展させていくため、重要なステップとなります。応答は、旅行代理店に連絡するかウェブサイトを訪問することを提案するような基本的なものになるでしょう。
このシナリオを考えてみましょう：スマートフォンやウェブブラウザで旅行エージェントとチャットしているときにネットワークが切断されると、接続とセッションが失われてしまいます。再度ログインしたとき、チャットボットにメモリがない場合（これは標準的な言語モデルがステートレスであるため発生します）、イライラしながら会話の履歴全体を繰り返さなければなりません。これは、以前のケースノートや履歴にアクセスできない別のカスタマーサービス担当者に回されるようなものです。 ここで、基本的なチケット予約アーキテクチャに基づいて、チャット履歴の概念を導入します。Amazon ElastiCacheは、短期的なストレージとメモリ保持に特に強力な機能を提供します。
そこで、Las VegasからHawaiiへのチケット予約に関する最初の質問の後、滞在中のおすすめスポットについてフォローアップの質問をするかもしれません。 Amazon ElastiCacheを使用することで、前回の質問を保存できます。 このフォローアップの質問をすると、チャット履歴を素早く取得し、Oahu、Maui、Waikikiなど、Hawaiiの主要な観光スポットについてカスタマイズされた回答を提供します。これは基本的なインタラクションループからの重要な進歩です。
さらにコンテキスト化を進めていきましょう。 「私の興味に基づいてアクティビティを推薦して」というフォローアップの質問があったとします。 Amazon ElastiCacheのキャッシュサービスに保存された設定情報がある場合を考えてみましょう。チャット履歴、設定、質問をしているユーザーのコンテキストがすべてAmazon ElastiCacheから取得されます。
このコンテキストがあれば、はるかに適切な応答が得られます。 例えば、ユーザーがサーフィン、アウトドア、またはビーチアクティビティに興味がある場合、Molokiniでのシュノーケリングなどを推薦するでしょう。 そして最後に、最も洗練された段階である Retrieval Augmented Generation に到達します。
次のフォローアップの質問が来ました：「とてもワクワクしています。旅程は計画できました。予約するために現在のチケット料金を教えてください。」 ここで、チャット履歴やコンテキスト、ユーザーの設定を保存するAmazon ElastiCacheがあります。 そこに、現在のチケット料金や、よくある質問、現在の開館・閉館時間といった関係データベースに保存されているデータを追加し、それをLanguage Modelに送ることで、ユーザーの好みや持っているコンテキストに基づいてカスタマイズされた応答を得ることができます。
現在、これが最適な入場時間で、これがチケットの価格で、食事代としてこれだけ必要になります。ここで、Retrieval Augmented Generation（RAG）という概念を紹介しました。これは重要なテクニックです。現在私たちが構築している、そしてお客様と一緒に見ているすべてのChatbotは、内部でRAGを活用しています。この話題に関する別の議論として、Language Modelはどんどん大きくなっており、コンテキストウィンドウも拡大しているということがあります。しかし、フォローアップの質問が出るたびに、Chatbotが記憶を失ってしまう閾値やティッピングポイントが必ず存在します。ここで重要なのは、単にLanguage Modelをそのまま使用するのではなく、Cacheを組み込んでVector Storeを導入するかどうかを見極めることです。さらにコストやパフォーマンスの考慮も必要です。
RAGについて詳しく見ていきましょう。 「エッフェル塔に入場するのに最適な時間は？」という質問を想像してください。 Language Modelが、トランザクションデータベースや関係データストアからリアルタイムのエレベーター待ち時間にアクセスできれば、その状況から情報を引き出すことができます。これを状況コンテキストと呼びます。 また、スライドでたくさん見てきたKnowledge Baseにもアクセスできます。Knowledge Baseは静的コンテキストと考えることができます。リアルタイムの待ち時間が動的コンテキストです。静的コンテキストには開館時間やチケット料金、あまり変更されない情報やFAQが含まれますが、これを動的コンテキストと組み合わせます。
これが実際にはセマンティックコンテキストです。FAQや開館時間、チケット料金への完全な一致はありません。エッフェル塔を訪れるべき時間帯や、各種チケットの価格帯についての情報になります。これがセマンティックコンテキスト、つまりインテリジェンスとデータに意味を付加することです。 ここでRAGを定義します。リアルタイムのエレベーター待ち時間という動的コンテキスト（状況コンテキスト）と、開館時間やチケット料金といった静的情報に基づいて、最短の待ち時間で入場できる正確な時間として午前9時から10時の早朝を推奨できます。また、Promptに指示しているため、Botは親切にも「チケットの予約のお手伝いをしましょうか？」というフォローアップを提案してくれます。
これが、私たちが構築していく中核のアーキテクチャとテクニックです。RAGによって、この場合は独自のデータである、データソースを外部のインテリジェンスでChatbotの応答を強化することができます。これは、最近お客様のユースケースでよく見かける非常に重要なトピックです。 Knowledge Baseについて言えば、Amazon Bedrockは完全マネージド型のRAGパイプラインをKnowledge Baseを通じて提供しており、Knowledge Baseを通じてより簡単に実現できるようにしています。「エッフェル塔を訪れるのに最適な時間は？」という同じ質問を想像してみてください。
Knowledge Baseはデータソースにアクセスすることができ、これにはフラットファイルのCSVファイルやその他のフォーマットが含まれます。また、PostgreSQLなどのVector Storeにもアクセスできます。Amazon Bedrock Knowledge Baseにデータソースを入力すると、ソースファイルのChunking、Embedding Modelを使用したベクトル化、そしてVector Data Storeへのベクトル埋め込みの保存を自動的に処理してくれます。ユーザーとして必要なのは、Chunkingの戦略、Embedding Model、Vector Storeを決定することだけです。これらは高レベルの意思決定であり、Chunkingと保存の基礎的なプロセスは自動的に処理されます。
Bedrock Knowledge Baseは、このようなRAGパイプラインの管理を非常に簡単にしてくれます。今朝、PostgreSQLのクイッククリエイトオプションを新しく公開しました。Bedrock Knowledge BaseとPostgreSQLをVector Storeとして統合することが、さらに簡単になりました。これは新しいローンチで、最初にシンガポールとUS West 2リージョンで利用可能となり、その後、他のリージョンに段階的に展開される予定です。Vector Storeの選択は重要な決定です - Pinecone、OpenSearch、MemoryDB、PostgreSQL、MySQLのどれを選ぶべきでしょうか？多くの考慮事項がありますが、このワンクリック統合によって、より簡単になります。
Chatbotアーキテクチャの実装デモンストレーション
この統合機能を使用するには、2つのことだけ行えば良いのです。Knowledge Baseを作成する際にVector Storeを選択するとき、推奨されているクイッククリエイトVector Storeオプションを選び、バックエンドエンジンとしてPostgreSQLを選択します。バックグラウンドでは、最小構成と最大構成でこれらのリソースをスピンアップするCloudFormationテンプレートをプロビジョニングします。必要に応じて構成をカスタマイズして変更することもできますが、適切なパイプラインを構築するための意思決定プロセスを非常に簡単にしようとしています。以前は数日かかっていた計画が、今では数分で設定できるようになりました。
さて、Knowledge Baseを説明する際、私はよく車のアナロジーを使用します。Knowledge Baseをハイブリッド車のように考えてください - ちょうど中間に位置するものです。座って運転するだけで機能しますが、ある程度のコントロールは可能ですが、完全な柔軟性はありません。Bedrock Knowledge Baseは選択できるモデルをいくつか提供していますが、Amazonのエコシステム内に制限されています。完全な自動運転車が欲しい場合は、Amazon Qを選びます - シートを開いて座るだけです。サービスのプロビジョニングや容量、その他の心配は必要ありません。単にドキュメントをアップロードして質問を始めるだけです。
一方で、LangChainのようなサードパーティ統合もあります。これはマニュアル車のようなもので、より多くの柔軟性が得られます。複数のプロバイダーと接続でき、Hugging FaceやOpenAIのようなオープンソースソリューションと統合することができます。ただし、それに伴って運用上のオーバーヘッドも増加します。マニュアル車と同様に、選択は本当にリソースとコストに依存します - 結局はそこに行き着くのです。
まずはAmazon Qについて詳しく見ていきましょう。Qは、Amazonが提供する完全マネージド型のノーコードローカルソリューションです。必要なのは、ドキュメントをアップロードするだけです。私は航空券や旅行に関するボット用のAmazon Qドキュメントを用意していて、「アムステルダムでの移動手段で最適なのは何ですか？」といった質問を投げかけることができます。セットアップは一切不要で、すぐに質問に答え始めます。統合や接続を構築する必要もありません。RAGの精度を備えており、ベクトルインデックス機能が組み込まれているため、クイックルックアップ用のインデックスを構築する必要もありません。40以上の一般的なデータソースに接続でき、チャットボットのパフォーマンステストを素早く簡単に始められます。
次に、スペクトラムの反対側にあるLangChainを見てみましょう。LangChainは大規模なアプリケーションを構築するためのフレームワークで、Vector Storeの選択に関して非常に柔軟性があります。Embedding Modelの選択についても、ドキュメントストアについても同様に柔軟に対応できます。ただし、それに伴う運用上のオーバーヘッドも大きくなります。通常、これらのRAGアプリケーションを構築する際、サードパーティプロバイダーに依存している場合、ある朝出社してみると、プロバイダーがライブラリやSDK、コネクタをアップデートしたために統合が完全に機能しなくなっているということがよくあります。pip installでアップグレードを行い、インフラ全体をアップグレードする必要がありますが、カスタマーエクスペリエンスがどうなるかという不確実性が高いのです。これがサードパーティ統合を扱う際の不確実性です。もちろん、そのような細かな制御が必要な場合は、LangChainやLAMA Indexを使用することができます。
ここで、私たちが日々お客様とお話しする中で、ますます人気が高まっているアーキテクチャパターンをいくつか見てみましょう。大規模なLLMを扱う際、リアルタイムのコンテキスト取得の管理が重要な課題となります。これを解決する方法として、Amazon ElastiCacheをコンテキストキャッシュソリューションとして導入します。これには2つの利点があります。まず、高速なデータ取得が可能になります。Aurora I/O-Optimizedと組み合わせることで、読み取り負荷の高いワークロードに対して、予測可能なパフォーマンス、スパイク処理、コスト面でのメリットが得られます。チャットボットが回答を提供したり、Q&A検索に使用したりする場合、これらは非常に読み取り負荷の高いワークロードとなり、Vector Storeとペアになったキャッシュが非常に役立ちます。また、RAGパイプラインの構築を心配する必要のない、完全マネージド型のチャットボット体験を提供するワンクリック統合も確認しました。
では、このパターンが実際にどのように機能するか見てみましょう。「イタリアの7日間の理想的な旅程は？」という質問を考えてみます。これをボットに質問すると、Amazon ElastiCacheがAmazon RDSやAuroraなどのリレーショナルデータストアから状況に応じたデータを取得します。さらに、セマンティックコンテキストである静的コンテキストで補強します。そして、この補強されたプロンプトをLLMに渡すと、ユーザーに合わせた非常に適切な回答が返ってきます。これが1つ目のパターン、コンテキストキャッシングです。写真を撮る必要はありません。セッション後にスライドを共有させていただきます。
2つ目の重要なパターンは、Vector Embeddingに関するものです。Vector Embeddingは非常に強力ですが、課題もあります。多くの距離計算が行われるため、再生成、取得、変換が必要となり、Semantic Searchのパフォーマンスが低下する可能性があります。コストの面も考慮する必要があります。Vector Embeddingにおいて、パフォーマンスとコストは重要な要素です。そこで、この問題を別の角度から考えてみましょう。Amazon ElastiCacheがすべてを無差別にキャッシュする一方で、ElastiCacheを使ってEmbeddingもキャッシュしてみてはどうでしょうか？これらのEmbeddingは非常に計算負荷の高い処理ですが、一度キャッシュすれば繰り返し生成できます。「バリ島での休暇」「ベルリンのナイトライフ」といった頻繁に検索される用語について、Amazon ElastiCacheでEmbeddingをキャッシュすることで、パフォーマンスとコストを節約できます。これにより、パフォーマンスとSemantic Searchの速度を劇的に向上させることができます。さらに、コストも削減できます。Embeddingを生成する際は、入力と出力のトークン1000個ごとに課金され、これらのトークンは単語に基づいています。つまり、これらの単語をキャッシュすることで、実質的にコストを最小限に抑えることができます。
このコスト削減アプローチは、特によく使用される検索語句に効果的です。実際のアーキテクチャはこのような形になります。「アムステルダムの人気バー」「ロンドンのアートギャラリー」「パリの美味しい食事」「タイの街頭マーケット」といった大量のクエリが流入してくるシナリオを想像してみてください。これらは API Gateway に送られ、そこから2つのパスのいずれかに振り分けられます。1つ目はベストケースシナリオで、検索語句がすでにキャッシュされている場合は、ElastiCache にアクセスしてサブミリ秒単位で非常に高速に検索結果を取得できます。
また、質問がキャッシュされていない場合は、より深い検索を行います。その場合は、完全なサーバーレススタックを活用して、Lambda を経由して Amazon Aurora PostgreSQL にアクセスする方法があります。その後、同じ質問が再度行われた場合はキャッシュされます。世界中の顧客がログインして質問を投げかけるような、グローバルでスパイク的なワークロードに対して、ElastiCache と Aurora PostgreSQL を使用したサーバーレススタックは、動的に非常に簡単に対応できます。このサーバーレスアーキテクチャは、このユースケースに非常にうまく適合しています。ここでは Embedding のキャッシングについて説明していることを覚えておいてください。
実際の動作を見てみましょう。私たちは2つの問題を解決しようとしていました - チケット予約の最適化プロセスと、よりパーソナライズされた旅程の生成です。これを詳しく見ていきましょう。ユーザーが質問をすると、コンテキストを追加してプロンプトの一部とし、それを言語モデルに送ります。この場合、Amazon Bedrock を使用しており、Bedrock 内では Claude ファミリーのモデル - Claude と Haiku を使用しています。そこから2つのパスがあります。1つは質問がすでにキャッシュされているベストケースシナリオの高速パスで、Amazon ElastiCache でサブミリ秒の応答時間を実現します。もう1つは Aurora PostgreSQL を使用したより長いレイテンシーでの応答です。
初回の検索でもそれほど悪くないことにお気づきでしょう。一般的なトランザクショナルやリレーショナルのベクトルストアでは、40〜200ミリ秒のレイテンシーはそれほど大きな問題ではなく、SLA を満たす上で十分な性能です。しかし、チャットボットは全く異なります。毎回一貫してサブミリ秒の応答が求められます。最悪のケースでも、Amazon Aurora にアクセスしてやや長いレイテンシーでの応答となりますが、その後の検索はキャッシュされます。
パーソナライズされた旅行プランニングの実現
実際の動作を見てみましょう。ElastiCache のセットアップがあり、最小・最大 ACU が設定された Aurora Serverless v2 もあります。このアーキテクチャ全体について説明していきます。ここでは PostgreSQL をナレッジベースとして使用しており、pgvector 拡張機能を使用したベクトルストアとしても機能します。これにより、これらの大規模な次元のベクトルを格納できる vector という特殊なデータ型が利用可能になります。データを見てみましょう。これが私の travel_knowledge_base テーブルとそのコンテキストです。サンプルレコードはこのようになっています：「シドニーの歴史は温泉で豊かです」。このような記録が何百万件もあります。そして、これが実際のベクトル次元の様子です - これらの巨大な1024次元の数値です。
私はアプリケーションを素早く構築できる、Pythonベースの人気のあるオープンソースツールであるStreamlitを使用しています。demo_userとして、非常にシンプルな質問から始めてみましょう。「京都の文化的な観光スポットについて教えてください。」最初の質問は、キャッシュされていないためPostgreSQLに送られます。これは新規の実装で、かなり良い応答を返してきます。これはCache missです。サイドバーにはいくつかの異なるメトリクスも表示しています。Cache missで1回のデータベースクエリが発生し、40〜200ミリ秒ほどかかっていることがわかります。初回としてはこれで問題ありません。同じ質問をもう一度してみましょう。全く同じ質問、同じ検索語なので、今度はキャッシュされているはずです。見てみましょう。はい、Cache hitです。Cache hitカウンターが更新されました。
さらに重要なのは、キャッシュの取得時間がデータベースの時間と比べて200%速く、0.45ミリ秒というサブミリ秒レベルだということです。次にチャット履歴のデモンストレーションを行います。「これらの観光スポットを訪れるのに最適な時期はいつですか？」京都やその他については言及していませんが、ElastiCacheからチャット履歴を取得して賢く対応するはずです。非常に素早く適切な応答が返ってきました。ここで注目すべき重要な統計は、履歴の取得時間で、これもElastiCacheからサブミリ秒で取得できています。
さらに続けて質問します：「他に知っておくべき、または参加すべき文化的なイベントはありますか？」京都への言及はありませんが、前の質問からの文脈と継続性を維持しています。ここでも重要なメトリクスはチャット履歴の取得時間で、一貫してサブミリ秒を維持しています。これを何千回も繰り返し質問することができます。
次は、好みに基づいたレコメンデーションを見てみましょう。「予算内でビーチリゾートを訪れることに興味があります。」次の休暇でBaliに行くことにしましょう - 設定した好みは即座にElastiCacheに保存されます。「Baliでおすすめの観光スポットを教えてください。」これは初回なのでキャッシュされておらず、データベースから取得されました。44ミリ秒という非常に良好なレイテンシーを示しています。しかし重要なのは、ElastiCacheからの好み情報の統合が再びサブミリ秒で行われていることです。
もう一度フォローアップの質問をしてみましょう。Baliについて明示的な文脈がなくても、チャット履歴から取得します。Baliに関する詳細な応答が再び返ってきます。チャット履歴は再びElastiCacheから取得され、サブミリ秒です。好み情報の統合も同様にElastiCacheからサブミリ秒で取得され、データベースクエリも実行されています。これはデータベースがウォームアップされている状態なので、そこまで悪くないことにも注目してください。
Baliに関する別のフォローアップ質問では、嗜好、コンテキスト、チャット履歴、そして範囲指定された予算フィルターを考慮に入れました。これは前回のやり取りと同じコンテキストを使用します。履歴の処理はサブミリ秒、嗜好の統合もサブミリ秒で完了し、それがここでお見せする内容です。そして最後に、予算範囲フィルターは指定通りに機能しました。これにより、私たちは重要な課題の一つを解決できました。 問題の50%が解決されたことになります。私たちはよりパーソナライズされた旅行プランの提供によって、ビジネスの拡大と多様化を目指しています。
Amazon Bedrock Agentsによる複雑なタスク処理と今後の展望
しかし、最初の問題についてはどうでしょうか？顧客が延々と待たされることのないよう、予約体験をスムーズにすることです。ここでAmazon Bedrock Agentsの出番となります。これはRAGベースのアーキテクチャの次なる進化形です。Bedrock Agentsに関する多くのセッションをご覧になった方もいるでしょう。 Innovation Centerでは、まさにBedrock Agentsについての講演が行われています。これまでの私たちのTravel Assistantは質問に答えることは得意でした。訪問に適した時期は何時か、理想的な時期は何時か、この予算内でプランを作成してほしい、といった検索ベースの質問です。そこでは単純な検索と、バックグラウンドでの生成処理を行っているだけでした。
しかし、次のようなタスクベースの質問について考えてみましょう： 特定の予算内でMauiでの5日間のフードツアーを計画できますか？これは見た目ほど単純な作業ではないことがわかります。 Agentはまず、フライトの空き状況と価格を確認する時間が必要です。 予算内のホテルを探す時間も必要ですし、ユーザーの好みに合うレストランを探す時間も必要です。
そして最後に、すべての情報をまとめ、予算に合った日程表を作成し、ユーザーに返答する必要があります。Bedrock Agentsでは、Action Group内でのアクションの論理的なグループ化が可能で、これについて詳しく見ていきましょう。このような一連のステップや複数タスクの実行が必要な場合、Agent Workflowが非常に便利です。Bedrock Agentsはオーケストレーターとして考えてください。Bedrock Agentsの簡単な復習をすると、ユーザーリクエストが来ると、Agentは一連のステップを生成します。そして必要な情報、外部ソース、内部ソース、リレーショナルデータベースや非リレーショナルデータベースなどから旅行のコンテキストを取得する場所を特定します。リレーショナルデータベース、非リレーショナルデータベース、その他のデータソースにAgentはアクセスできます。
次のスライドで見るように、特定のステップに対して特定の機能を呼び出すためのLambda関数やOpenAPI Schemaにもアクセスできます。Agentによる作業の実行方法はこのようになっています - ユーザーのリクエストを満たすまで、このプランを繰り返し実行します。 そして最終的にタスクを完了させます。もちろん、これらはすべて、レスポンス生成時にアクセスする機密データや企業の独自データに対して、最高レベルのセキュリティ基準を維持しながら実行されます。
エージェントの構造はどのように構成されているのでしょうか？ 主に3つのコンポーネントから成り立っています。まず、エージェントに役割を割り当てる指示があります。例えば、親切な顧客サービスボットや旅行エージェントとして設定し、フレンドリーな会話調で応答するように指示します。次に、Knowledge BaseとAction Groupsへのアクセス権を与え、実行可能なアクションを定義します。そして最後に、Amazon Bedrockモデルへのアクセス権を持ちます。基本的なオーケストレーションの流れとしては、タスクを複数のステップに分解します。具体的なアクションを実行するか、Knowledge Baseから情報を取得し、満足のいく最終的な応答に到達するまで、観察とアクションを繰り返し行います。
アーキテクチャの例に戻りましょう。「特定の予算でマウイ島の5日間のフードツアーを計画できますか？」という質問に対して、プロセスは体系的に分解されます。Action GroupsはOpenAPI仕様とLambda関数にマッピングされます。このマッピングは非常に重要で、エージェントが実行するAction Groups、呼び出すエンドポイント、アクションを実行するLambda関数の間には1対1対1の関係があります。このアーキテクチャ全体がエージェントテクノロジーのワークフローを定義しています。
OpenAPI仕様の具体的な例として、フライトをチェックするようなサンプルAPIを見てみましょう。これは業界標準のAPI仕様に従っており、目的地、日付、予算などの必要なパラメータを提供する一般的なJSON形式です。Lambda関数がこのAPIを実装します。私たちのAPIの仕組みは次のとおりです - まずLambda関数が、質問と回答がElastiCacheに保存されているかどうかをチェックします。存在する場合はそれを取得し、存在しない場合はAuroraから検索して取得します。Vector Databaseを通じて取得した後、後続のパフォーマンス向上のためにキャッシュも行います。
ここで全体像を見てみましょう。実際にどのように機能するのか見ていきましょう。誰かが「3,000ドルでマウイ島の5日間のフードツアーを計画できますか？」と尋ねた場合、エージェントはこの複雑な質問を複数のアクションに分解します。これらのアクションは、Knowledge Base（これらはアクセス可能なツール）で検索されるか、OpenAPIとLambdaの組み合わせで構成されるAction Groupによって処理されます。同時に、キャッシュされた設定や埋め込み、チャット履歴を取得し、プロンプトを拡張します。ユーザーが質問すると、このイテレーティブなループを通過します。エージェントは思考の連鎖、結果の観察、そして最後にユーザーに詳細な旅程を返すという反復的なループを実行します。これが私たちが観察したことです。
実際の動作を見てみましょう。Bedrock AgentがAPIコールとLambda関数をシームレスで迅速な会話型予約体験に変換します。クレジットカードの詳細、名前、情報、旅行プロファイルなどをすべて取得し、答えやすいフォローアップの質問をしていくのがわかります。はい、予約が完了しました。来週ハワイに行けそうですね。
まずは始めるためのリソースをご紹介します。デモで使用したコードをはじめ、ワークショップやGitHubのサンプルもご利用いただけます。このトピックにご関心をお持ちの皆様に、本日ご紹介した内容に関連する、さらに興味深いセッションが多数開催されていますので、ぜひご参加ください。以上で終わりとなります。Mahaloそして、re:Inventの残りもお楽しみください。セッションアンケートにぜひご協力ください。皆様からのフィードバックは、来年のさらなる改善に活かさせていただきます。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion