re:Invent 2024: FidelityのMemoryDBを用いたVector検索活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Fidelity Investments and real-time vector search for Amazon MemoryDB (DAT337)
この動画では、AWSの最速データベースであるAmazon MemoryDBのVector検索機能について解説しています。Fidelity InvestmentsのData Architecture Vice PresidentであるRamanathan Natarajanが、Vector storeとしてMemoryDBを選択した理由や実際のユースケースを詳しく説明します。MemoryDBは99.99%の耐久性を持つフルマネージド型で、P99で一桁ミリ秒のVector検索クエリを実現し、LangChainとの統合も可能です。Fidelityでは、アナリストとトレーダー間の情報共有やセルフヘルプのインシデント管理において、Role-Based Access Controlを備えたVector検索を活用。790の同時ユーザーで25ミリ秒未満のレイテンシーを達成し、特別なHashデータタイプによりストレージ使用量を1/4に削減することに成功しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon MemoryDBとVector検索：概要と活用事例
本日はご参加いただき、ありがとうございます。Amazon MemoryDBのリアルタイムVector検索についてお話しさせていただきます。MemoryDBの概要と、その上で実現されたVector検索機能についてご説明いたします。本日は、インドのFidelity Investmentsから、Data ArchitectureのVice Presidentを務めるRamanathan Natarajanさんにもご参加いただいております。後ほど、MemoryDBをVector storeとして選択した際の判断基準や、実際のユースケースについてお話しいただく予定です。
ここで、Swami Sivasubramanianの印象的な言葉を紹介させていただきます：「誰もが同じモデルにアクセスできる中で、ビジネスとその顧客を理解するGenerative AIを、一般的なAIと区別するのはデータなのです」。ここで重要なポイントは、皆様固有のデータこそが、Generative AIアプリケーションの差別化要因となるということです。Vector検索を活用することで、そういった固有のデータをLLMやGenerative AIアプリケーションに効果的に活用することができます。
MemoryDBの概要をご説明させていただきますと、これはAWSで最速のデータベースです。フルマネージド型で、 マルチAZトランザクションログによる耐久性を備え、99.99%の耐久性を提供します。また、オープンソースとの互換性を重視しており、Redis OSSやValkeyと互換性があります。Redisは3月にオープンソースライセンスを変更し、 その後、Linux FoundationによってValkeyがフォークされました。これは寛容なオープンソースライセンスを持ち、Redis OSS 7.2の完全な代替として機能します。現在、40以上の組織が参加し、100万回以上のコンテナプルを記録しています。
MemoryDBでは、ValkeyとRedis OSSの両方のエンジンでVector検索を有効化しました。 MemoryDBは、人気のあるVector databaseの中で、最高レベルのリコール率でAWS上最速のVector検索を提供します。多くのお客様が Generative AIアプリケーションにMemoryDBを信頼してご利用いただいています。数百万のVectorを保存でき、P99で一桁ミリ秒のVector検索クエリ および更新、各種CRUD操作を実現します。また、LangChainとも統合されており、in-memoryドライバーを使用して素早くアプリケーションを立ち上げることができます。
MemoryDBのVector検索は、様々なユースケースを可能にします。 例えば、Amazon.comでの広告配信にAmazon adsが使用する高速なSemantic検索を実現します。また、LLMの推論結果を耐久性のあるSemantic cachingとして保存し、 意味的に類似した質問が来た場合に、LLMに再度アクセスすることなく、Vector storeから直接回答を提供することができ、パフォーマンスとコストを改善できます。 さらに、Retrieval Augmented Generation（RAG）により、固有のデータをLLMのコンテキストとして活用し、ユーザーにより具体的な回答を提供することができます。最後に、一桁ミリ秒の応答時間で不正行為を検出する異常検知も実現可能です。
Fidelity InvestmentsにおけるVector Database活用の実践
それでは、Fidelityのユースケースと、Vector StoreとしてMemoryDBを選択した際の意思決定マトリックスについて、Ramにバトンタッチしたいと思います。 私はRamと申します。20年以上の経験を持つアーキテクトとして、AIとデータの交差点に特化して仕事をしています。Fidelityには10年以上在籍しており、当社は顧客の経済的自立をサポートするビジネスを展開しています。本日は、Vector Databaseの持つ大きな可能性を発見するまでの私たちの journey についてお話しできることを嬉しく思います。私たちの探求は、従来のデータベースでは効果的に対応できない特定のユースケースによって主に推進されてきました。金融市場に関する私たちのユースケースの1つをご紹介したいと思います。市場参加者としてアナリストとトレーダーがいます。アナリストは主に過去のデータに焦点を当て、経済データを含む基礎的な分析を行います。一方、トレーダーは取引の実行に従事し、最新の決算データなど、現在のデータにより関心を持っています。このように、彼らの役割は異なります。このソリューションのハイレベルな設計を見てみましょう。アナリストが入力した調査メモやSEC提出書類などの非構造化データが入力されます。
これには10-K提出書類や決算データが含まれます。これらはすべてPDFドキュメントです。ビジネスユースケースに応じて適切なChunking戦略を適用します。意味のある文章に変換された後、Embedding Modelを通して Vector を生成します。768次元のVectorを考えるとき、それは数値の配列、カンマ区切りの値の配列として想像でき、コンピュータエンジニアリング用語でその配列の長さは約768であると考えることができます。
これらのVectorはVector Databaseに永続的に保存されます。Vector Databaseにこのデータをプッシュする際、同時にメタデータの抽出も行います。これには企業名、株式シンボル、レポート日付やレポート名などの追加メタデータが含まれます。これらのメタデータはVectorと共にVector Databaseに保存されます。より高速な検索のために、Vectorとメタデータの両方にインデックスを付けます。ユースケースに戻りますが、アナリストとトレーダーの間の情報障壁について話しました。適切な権限を持つユーザーのみがデータにアクセスできるようにする必要があるため、Role-Based Access Controlのための優れた検索機能を組み込む必要があることは明らかです。
次のユースケースは、セルフヘルプのインシデント管理についてです。ほとんどの方がこの概念をご存知でしょう。これは、事前に構築された Knowledge Base を活用して、技術的な問題に対する解決策を個人が見つけられるようにするものです。IT サポートへの依存を減らし、問題解決を加速することを目的としています。設計を見ると、インシデントの説明とサービスリクエストの説明があります。これらの説明と解決策を取り、意味のある文章にパッケージ化するChunking戦略を決定し、これらのChunkをEmbedding Modelに通します。
これらのEmbedding Modelは前回のケースと同様にVectorを生成し、Vector Databaseに永続的に保存されます。また、インシデントの重要度やバッジの不具合やデータ管理といったインシデントのカテゴリーに関するメタデータも処理します。これらのVectorとメタデータは、より高速な検索のためにVector Databaseにインデックスされます。ユーザーが「サーバーにアクセスできずタイムアウトエラーが発生する」といった質問を入力する際、サーバーやストレージ、データウェアハウスアプリケーション、特定のエンジニアリング割当グループなどのカテゴリーに関するメタデータも提供します。約5,000件のインシデント管理チケットを持つVector Databaseを構築している場合、そのうちの約500件の有限セットを検索します。入力された自然言語のクエリはVectorに変換され、これら500件の中から一致するVectorを見つけて、上位3件のマッチを導き出します。
様々なビジネスユニットにおける広範なパターンを総合的に見ると、低レイテンシーの検索を実行したい同時接続ユーザーが存在することがわかりました。その際、Role-Based Access Controlの実装も必要とされています。純粋なVector検索だけを行うことは稀で、常にメタデータが関連付けられています。
このメタデータは、401kや学生ローンといったテキスト属性に関連するものであったり、残高が10,000ドル以上といった数値フィルターであったりします。これはデータサイエンティストからの大まかな要件でしたが、データエンジニアからも要件がありました。MLエンジニアは、Vector databaseがモデルと同じ場所に配置される必要があると指定し、それがクラウド上になることは明らかでした。アーキテクトとして受け取った要件の1つは、Vector storeの移植性を確保することでした。これは主にクロスクラウドの依存関係を作らないためのレジリエンシーパターンを実現するためです。2つ目の考慮事項は、クラウド内のIngress/Egressコストでした。最後の要件は開発速度に焦点を当てており、具体的には本番環境への展開を迅速化することでした。チームはSaaSへの労力を減らしてビジネス要件により多くの注意を向けたいと考え、そのためにManaged serviceを求めていました。
ユースケースとパターンを検討しました。 Fidelityでは、ツールやソリューションを選択する前に、Capability matrixを構築します。これにより非常に柔軟性が高まり、必要に応じて別のVector databaseや異なるクラウドに移行することができます。 このCapability matrixがどのようなものか見てみましょう。機能要件であるデータストレージについては、3つの主要な機能があります：Vectorデータタイプの保存、Vectorのインデックス作成、そしてVectorに対する操作（作成、更新、削除）です。これは永続的なストレージだけでなく、キャッシュレベルのメモリ上でも行う必要があります。
消費側では、大きく分けてBatchとリアルタイムの2つのアプローチがあります。 SageMakerやLangChain、Lama Indexなどのフレームワークから呼び出すための十分なAPIが必要です。データ処理については、加算、減算、Euclidean distanceやCosine distanceを使用した最近接Vectorの検索などのVector演算を実行します。これらの操作を実装する際には、並列処理機能と達成可能な同時実行レベルを考慮しました。
データセキュリティに移ると、Sanjitさんが既にIn-memory DBの機能について説明しました。保存時の暗号化と転送時の暗号化が重要な要件として特定されました。2つ目の側面はRole-Based Access Control（RBAC）です。3つ目の考慮事項は、データが単一テナントのインスタンス、Fidelity専用のVPC内のマルチテナント、または複数テナント間で共有されているかどうかです。 非機能要件については、マルチクラウド機能とモニタリング・アラートを優先しました。Vector databaseを構築する際、CPU、メモリ、ネットワーク、同時接続ユーザー数、認証などの周辺システムの開発を避けたいと考え、これらの機能をすぐに利用できるManaged serviceを選択しました。
メトリクスとKPIについては、アプリケーションのTierレーティングを決定した後、明確なSLAとSLOの定義に焦点を当てることでシンプルに保ちました。 運用とサポートに関しては、バージョン7.1から7.2へのアップグレードなどのバージョンアップに必要な作業や、db.r7g.4xlargeからdb.r7g.8xlargeインスタンスへのアップグレードなど、インフラのスケーリング時に必要な作業を考慮しました。これらが、Vector Databaseを構築する際に念頭に置いていた重要なポイントでした。
Vector Databaseの選定基準とMemoryDBの採用理由
次に2番目のアーキテクチャについてですが、私がここにいる理由を正当化するアーキテクチャなしでは話が完結しませんので、私たちが発見したユースケースとパターンについて検討しました。
この検討から、私たちはCapability Matrixを作成しました。 アーキテクチャの観点からこれを見てみましょう。インデックスを選択する際、私たちはカスタムインデックスに依存したくないという明確な方針を持っていました。業界で十分な文献があり、柔軟で設定可能で、高可用性のあるインデックスを採用したいと考えました。その理由は、別のVector Databaseに移行したり、別のクラウドに移行したりする際に、ネット上で十分な文献を参照して設定できるようにするためです。
もう一つの重要な側面は、Non-lossy compressionです。ベクトルをカンマ区切りの値として見た場合、32ビットの浮動小数点値を16ビットに圧縮することで、ストレージのフットプリントを削減できます。ただし、その過程で精度が失われてしまいます。私たちが実装したいのは、精度を失うことなく、かつストレージのフットプリントを小さく保てるNon-lossy compressionです。データの統合と取り込みについて調査したところ、これらのMLフレームワークには、ベクトルをVector Databaseに取り込むための様々なユーティリティやライブラリが用意されていることがわかりました。しかし、私たちが主に知りたかったのは、Vector Databaseが並列ベクトル取り込み機能を標準で提供しているかどうかでした。
モニタリングと可観測性に関しては、Amazon MemoryDB for Redisには標準で約42のメトリクスが用意されていることがわかりました。スケーリングについては、すでに垂直スケーリングとアップグレードについて話しました。 パフォーマンスのベンチマーキングを行う際、私たちが想定したのは、この部屋にいる全員にベクトルA、B、Cを与えて、Cosine距離を使って最も近いベクトルを見つけるように依頼した場合、純粋な数学的計算なので、全員が同じ結果にたどり着くだろうということでした。
業界のデータセットを使用して、正解データが既知の状態で、様々なVector Databaseの評価を行いました。Amazon MemoryDB for Redisについては、99%のRecallを達成し、約790の同時ユーザーで25ミリ秒未満のレイテンシーを実現できました。要件として97%のRecallは許容範囲だが、レイテンシーを一桁ミリ秒にしたいという声がありました。私たちはRecallを若干妥協することで一桁ミリ秒のレイテンシーを達成し、速度と品質のバランスを効果的に取ることができました。
Non-lossy compressionに関して、MemoryDB for Redisには特別なHashデータタイプがあることがわかりました。これにより、同じ精度とRecallを維持しながら、ストレージの使用量を元の約1/4に削減することができました。では、私たちのユースケースに対してどのように判断を下したのでしょうか？私たちは3つの重要なポイントを考慮しました。サイジングカリキュレーターを使用してVectorとDimensionを入力すると、推奨インスタンスが提示されて非常に便利でした。データはFidelity VPC内に保持され、特定のRDBフォーマットを使用してバックアップでき、他のクラウドやジョブでの復元が可能です。また、業界がユーザーIDとパスワードベースの認証から移行している中、セキュアなトークンベースの認証も提供されています。
私たちは、技術的な目標がビジネス成果をどのように推進しているかをお示ししたいと思います。アナリストとトレーダー間の情報障壁に関して、Key Spaceを定義することができました。Redisでユーザーを作成する際、特定のアクセス文字列を使用して作成し、特定のアナリストユーザーのみにアクセスを制限することで、トレーダーがアクセスできないようにしています。インシデント管理クエリについては、サーバーとストレージをフィルターとして使用することで、非常に限定されたセットにたどり着くことができました。これらの実装により、私たちのユースケースが実現されています。本日のホストを務めていただいたAWSと、私をここに派遣してくれたFidelity Indiaに感謝いたします。この学識のある実践的な聴衆の前でプレゼンテーションができて光栄です。
締めくくりのためにSanjitさんにバトンタッチしたいと思います。ご参加いただき、ありがとうございました。こちらに素晴らしいリンクをご用意しています：Vector 検索機能を自身で構築できるMemoryDB APIのGitHub、Semantic Cachingのブログ、そしてGenerative AIアプリケーションを構築するためのLangChainを使用したIn-memory Driverです。皆様、ありがとうございました。アンケートへのご協力をお願いいたします。フィードバックを大変ありがたく思います。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion