Amazon Web Services ブログ

生成 AI アプリケーションのデータベース選択における重要な考慮事項

2024 年 1 月 4 日、データベースの講義で知られる CMU の Andy Pavlo 教授が 2023 年のデータベースレビューを公開しました。主にベクトルデータベースの台頭に焦点を当てたものです。こうした革新的なデータストレージソリューションが注目を集めています。生成人工知能 (AI) モデルの人気が高まり続ける中、ベクトルストレージと検索機能を備えたデータベースに関心が寄せられています。ベクトルデータベースは、基盤モデル (FM) の機能を拡張するための費用対効果の高い仕組みを提供します。分散コンピューティング、クラウドベースのアーキテクチャ、特殊なハードウェアアクセラレータの進歩により、ベクトル検索機能をもつデータベースはさらに強力でスケーラブルになる可能性を秘めています。

本投稿では、生成 AI アプリケーションのデータベース選択において鍵となる要素について解説します。解説にあたっては、現在 AWS で利用可能なベクトル検索機能を備えたフルマネージドデータベースに関連する、高レベルの考慮事項とサービス特性に焦点を当てています。各データベースにおける動作とパフォーマンス面の差異を確認し、特定の要件に基づいて情報に基づいた決定を行う方法についてのガイダンスを提供していきます。これらの本質的な側面を理解することで、生成 AI ワークロードに最適なデータベースを選択し、最適なパフォーマンス、スケーラビリティ、および実装の容易さを達成するための準備を整えることができます。

Retrieval Augmented Generation

Retrieval Augmented Generation (RAG) は、大規模言語モデル (LLM) の出力を最適化するプロセスで、応答を生成する前にトレーニングデータソース外の信頼できるナレッジベースを参照します。データベースは、モデルを再トレーニングする必要なく、LLM が持つ既存の強力な機能を、特定のドメインや組織内部のナレッジベースに拡張できます。RAG は、LLM の出力を様々な文脈で関連性、正確性、有用性を維持しながら改善する費用対効果の高いアプローチです。

以下の図は RAG ワークフローを示しています。

RAG ワークフローの主要なステップは以下の通りです。

  1. 処理されたデータソースからドキュメントチャンクが作成されます。テキストは埋め込みモデル (Amazon Titan Text Embeddings V2 など) を介して、数値表現である 埋め込み に変換されます。これらの埋め込みはテキストの意図を含んでおり、元のドキュメントチャンクと共にベクトル検索に最適化されたデータベースに格納されます。
  2. ユーザー入力は同じ埋め込みモデルを使用して埋め込みに変換されます。ユーザー入力埋め込みをクエリベクトルとして使用することで、データベース上でセマンティック検索が実行され、ベクトル空間での近さに基づいて上位 k 個の最も関連性の高いドキュメントチャンクが取得されます。取得されたチャンクは、後続の生成ステップのコンテキストとして機能します。
  3. ユーザー入力はプロンプトとして使用されます。取得されたドキュメントチャンクはプロンプト拡張に使用されます。拡張されたプロンプトは基盤モデル (Amazon Bedrock 上の Anthropic Claude 3 など) に送られ、事前トレーニングされた知識とデータベースから提供されたコンテキストに基づいて応答を生成します。生成された応答は、取得された情報により基づいた、文脈に沿った適切なものとなります。

RAG のデータベースを選択する際にはじめに考慮することの 1 つは、ユースケースに適したデータベースを決定することです。データベースと生成 AI に関する議論は広範かつ多面的であるため、本投稿では議論を簡略化し、主にベクトル検索機能を持つどのデータベースが適しているかの意思決定プロセスに焦点を当てています。LLM に関するガイダンスが必要な場合は、Generative AI with LLMs を参照してください。

AWS のベクトル検索

このポストの公開時点で、AWS はベクトルストレージ、取得、インデックス、検索を含む完全なベクトル機能スイートを備えた以下のデータベースを提供しています。AWS はまた、Knowledge Bases for Amazon Bedrock と統合されたデータベースも提供しています。

  • Amazon Aurora PostgreSQL-Compatible Edition と Amazon Relational Database Service (Amazon RDS) for PostgreSQL は、オープンソースの pgvector によるベクトル検索拡張機能を備えたフルマネージドリレーショナルデータベースです。Aurora PostgreSQL は Amazon Aurora Serverless v2 デプロイメントでもベクトル検索をサポートしています。
  • Amazon OpenSearch Service は、オープンソースの検索エンジンおよび分析スイートである OpenSearch を実行するためのフルマネージドサービスです。OpenSearch は、マネージドクラスターとサーバーレスコレクションの両方でベクトルエンジンによるベクトル検索をサポートしています。OpenSearch Service は Amazon OpenSearch Serverless デプロイメントオプションでもベクトル検索を利用可能です。
  • Amazon Neptune Analytics は、グラフアルゴリズムとベクトル検索を備えた分析グラフデータベースエンジンで、GraphRAG といったグラフと RAG の組み合わせを利用することができます。
  • Amazon DocumentDB (MongoDB 互換) のベクトル検索は、Amazon DocumentDB 5.0 インスタンスベースのクラスターで利用可能です。
  • Amazon MemoryDB の ベクトル検索 は、AWS 上の一般的なベクトルデータベースの中で最速のベクトル検索パフォーマンスを最高のリコール率で提供するインメモリデータベースです。MemoryDB は、最高レベルのリコールでも、一桁ミリ秒のベクトル検索・更新レイテンシーを実現します。
  • Amazon DynamoDB と OpenSearch Service のゼロ ETL 統合 は、Amazon DynamoDB 上のデータに対して、全文検索やベクトル検索などの高度な検索機能を提供します。

以降のセクションでは、生成 AI アプリケーションに適したデータベースを選択するために役立つ主要な考慮事項について解説していきます。

  • 親和性
  • 実装の容易さ
  • スケーラビリティ
  • パフォーマンス

親和性

慣れ親しんだ技術を選択することが可能であれば、最終的に開発者の時間を節約し、複雑さを軽減できます。開発チームが特定のデータベースエンジンに既に精通している場合、ベクトル検索に同じデータベースエンジンを使用することで、既存の知識を活用してスムーズな体験を実現できます。新しいスキルセットを学ぶ代わりに、開発者は現在のスキル、ツール、フレームワーク、プロセスを活用して、既存のデータベースエンジンの新機能を含めることができます。

例えば、データベースエンジニアのチームが Aurora PostgreSQL でホストされている 100 のリレーショナルデータベースのセットを既に管理している場合、アプリケーションのベクトル検索要件をサポートする新しいデータベースを検討する際には、まず既存の Aurora PostgreSQL データベースで pgvector 拡張機能を評価することから始めるとよいでしょう。

同様に、チームがグラフデータを扱っている場合は、既存の AWS インフラストラクチャとシームレスに統合し、強力なグラフクエリと視覚化機能を提供する Neptune Analytics の使用を検討できます。

チームが JSON ドキュメントを扱い、スケーラブルでフルマネージドのドキュメントデータベースが必要な場合、Amazon DocumentDB は互換性のある馴染みのある MongoDB エクスペリエンスを提供し、既存のスキルと知識を活用できます。

チームが Redis OSS に精通しており、リアルタイムアプリケーション用の高度にスケーラブルなインメモリデータベースが必要な場合は、MemoryDB の使用を検討してください。MemoryDB は馴染みのある Redis OSS 互換インターフェースを提供し、チームは既存の Redis OSS の知識とクライアントライブラリを使用しながら、MemoryDB のフルマネージド、耐久性、スケーラブルな機能の恩恵を受けることができます。

これらの例では、データベースエンジニアリングチームは新しいデータベースソフトウェアを導入する必要がなく、より多くの開発者ツールや統合を追加する必要もありません。代わりに、彼らの専門分野内で新しい機能を有効にすることに集中できます。開発のベストプラクティス、運用、クエリ言語は同じままであり、成功の方程式における新しい変数の数を減らします。既存のデータベースを使用することのもう 1 つの利点は、セキュリティ、可用性、スケーラビリティ、信頼性、パフォーマンスに関するアプリケーションの要件に合致することです。さらに、データベース管理者は馴染みのある技術、スキル、プログラミングツールを使用できます。

現在の技術スタックにベクトル検索のサポートがない場合は、サーバーレスオファリングを活用してベクトル検索のニーズのギャップを埋めることができます。例えば、Amazon Bedrock コンソールでの クイック作成 エクスペリエンスを備えた OpenSearch Serverless を使用すると、クラスターを作成または管理する必要なく開始できます。この場合、新しい技術の導入は避けられませんが、サーバーレスを選択することで管理のオーバーヘッドを最小限に抑えることができます。

実装の容易さ

親和性以上に、実際にデータベースを実装する際に予期されるプロセスは、評価プロセスにおける次の主要な考慮事項となります。シームレスな統合プロセスは、中断を最小限に抑え、データベースの価値実現までの時間を短縮できます。このセクションでは、ベクトル化、管理、アクセス制御、コンプライアンス、インターフェースなどのコア実装の焦点領域にわたってデータベースを評価する方法を探ります。

ベクトル化

実装における最も重要な考慮事項は、ベクトル埋め込みでデータベースを投入するプロセスです。データがベクトルとして表現されていない場合、埋め込みモデルを使用してベクトルに変換し、ベクトルに対応したデータベースに格納する必要があります。例えば、OpenSearch Service を Amazon Bedrock のナレッジベースとして使用する場合、生成 AI アプリケーションは Amazon Simple Storage Service (Amazon S3) に格納された非構造化データを取り、テキストチャンクとベクトルに変換し、自動的に OpenSearch Service に格納できます。

管理性

日々の管理性に対する要求は、全体実装における考慮事項となります。既存のチームのデータベース管理ワークロードに過度の負担をかけないデータベースを選択する必要があります。例えば、Amazon Elastic Compute Cloud (Amazon EC2) 上のセルフマネージドデータベースの管理オーバーヘッドを負担することに代えて、Aurora Serverless v2 や OpenSearch Serverless などのベクトル検索をサポートするサーバーレスデータベースを選択することができます。

アクセス制御

既存のインフラストラクチャにベクトル検索を統合する際、アクセス制御は重要な考慮事項となります。現在のセキュリティ標準を遵守するために、潜在的なデータベースが提供するアクセス制御メカニズムを徹底的に評価する必要があります。例えば、非ベクトルの Amazon DocumentDB 実装に対して堅牢な ロールベースのアクセス制御 (RBAC) を有しているのであれば、ベクトル検索に Amazon DocumentDB を選択することは理想的といえます。既に確立されたアクセス制御要件に合致しているためです。

コンプライアンス

コンプライアンス認証は、データベース選定における重要な評価基準です。データベースがアプリケーションの本質的なコンプライアンスニーズを満たさない場合、候補となりえません。AWS は 300 以上のセキュリティ、コンプライアンス、およびガバナンスサービスと機能を備えた深いクラウドセキュリティツールセットに支えられています。さらに、AWS は PCI-DSS、HIPAA/HITECH、FedRAMP、GDPR、FIPS 140-2、NIST 800-171 を含む 143 の セキュリティ基準とコンプライアンス認証をサポートしており、世界中のほぼすべての規制機関のコンプライアンス要件を満たすのに役立ち、データベースがセキュリティ・コンプライアンス要求を満たすことを実現します。

インターフェース

生成 AI アプリケーションがデータベースと対話する方法は、実装におけるもう一つの考慮事項です。これはデータベースの一般的な使いやすさに影響を与える可能性があります。データベースへの接続方法と対話方法を評価し、ニーズを満たすシンプルで直感的なインターフェースを持つオプションを選択する必要があります。例えば、Neptune Analytics は API 呼び出しとストアドプロシージャを通じてベクトル検索を簡素化しており、合理化されたユーザーフレンドリーなインターフェースを優先する場合に魅力的な選択肢となります。詳細については、Neptune Analytics でのベクトル類似性の操作を参照してください。

統合

Knowledge Bases for Amazon Bedrock との統合は、データ取り込みとランタイムオーケストレーションワークフローを自動化したい場合に重要です。Aurora PostgreSQL-Compatible と OpenSearch Service の両方が Knowledge Bases for Amazon Bedrock と統合されており、さらに多くの統合が予定されています。同様に、Amazon SageMaker との統合により、ベクトル類似性検索、パーソナライズされた推奨、またはその他のベクトルベースの操作に依存するアプリケーションを構築するための、シームレスで、スケーラブルで、カスタマイズ可能なソリューションが提供されます。これは機械学習 (ML) と AWS 環境の力を活用しています。Aurora PostgreSQL と OpenSearch Service に加えて、Amazon DocumentDB と Neptune Analytics も SageMaker と統合されています。

さらに、LangChain や LlamaIndex などのオープンソースフレームワークは、LLM アプリケーションの構築に役立ちます。これらは強力なツール、抽象化、ユーティリティのセットを提供し、開発プロセスを簡素化し、生産性を向上させ、開発者が付加価値の高い機能の作成に集中できるようにします。LangChain は様々な AWS データベース、ストレージシステム、外部 API とシームレスに統合されており、Amazon Bedrock とも統合されています。この統合により、開発者は LangChain フレームワーク内で AWS データベースと Bedrock のモデルを簡単に使用できます。LlamaIndex は Neptune Analytics をベクトルストアとグラフデータベースとしてサポートし、GraphRAG アプリケーションの構築をサポートしています。同様に、Hugging Face は BERT、GPT、T5 を含む幅広い事前トレーニング済みモデルを提供するポピュラーなプラットフォームです。Hugging Face は AWS サービスと統合されており、AWS インフラストラクチャ上でモデルをデプロイし、OpenSearch Service、Aurora PostgreSQL-Compatible、Neptune Analytics、または MemoryDB などのデータベースと共に使用できます。

スケーラビリティ

スケーラビリティは、プロダクションアプリケーションが中断なく効率的に実行できるようにするための、データベース評価における重要な要素です。ベクトルデータベースのスケーラビリティは、高次元ベクトルと膨大な数の埋め込みをサポートする能力と結びついています。各データベースは、リソース使用量の増加に対応するために異なるスケーリングメカニズムを持っています。例えば、Aurora PostgreSQL のスケーリングメカニズムとエンジニアリングは、OpenSearch Service や MemoryDB のスケーリングとは異なります。データベースのスケーリングメカニズムを理解することは、アプリケーションの継続的な成長を計画するために不可欠です。急速に成長する音楽推奨エンジンを構築しようとしている音楽会社の例を考えてみましょう。OpenSearch Service は、スケールアウト分散インフラストラクチャを提供することで、レコメンデーションエンジンのスケーラビリティを容易に制御可能なものにしています。同様に、グローバルな金融サービス企業は Amazon Aurora Global Database を使用して、パーソナライズされた投資推奨のためのスケーラブルで耐障害性のあるベクトル検索ソリューションを構築できます。1 つの AWS リージョンにプライマリデータベースをデプロイし、複数のセカンダリリージョンに複製することで、企業は高可用性、災害復旧、最小限のレイテンシーでのグローバルアプリケーションアクセスを提供しながら、世界中の顧客に正確でパーソナライズされたレコメンデーションを提供することができます。

AWS データベースは、多様なスケーリングメカニズムを備えた幅広いデータベースエンジンを提供し、ほぼすべての生成 AI 要件のスケーリング要求を満たすことに貢献します。

パフォーマンス

もう 1 つの重要な考慮事項は、データベースのパフォーマンスです。組織が膨大な量の高次元ベクトル データから貴重な洞察を抽出しようと努めるにつれて、複雑なベクトル検索と操作を大規模に実行する機能は最も重要な要素となります。

  • スループット – 1 秒で処理できるクエリの数
  • 再現率 – 取得されたベクトルの関連性と完全性、正確な応答の提供
  • インデックス構築時間 – ベクトルインデックスの構築に必要な時間
  • スケール・コスト – 数十億のベクトルを効率的にスケールしながら処理しつつ、コストパフォーマンスを維持する能力
  • p99 レイテンシ – リクエストの 99% の最大レイテンシ、応答時間の期待を満たす
  • ストレージ使用量 – 高次元ベクトルのストレージがどれほど効率的に使用されるか、特に高次元ベクトルの場合に重要

例えば、金融商品のリアルタイム推奨エンジンを構築しているグローバルバンクは、確立されたエンドツーエンドのレイテンシ予算内に留まりながら、数万の同時ユーザーに対して一桁ミリ秒のレイテンシで高度に関連性のあるベクトル検索結果とエクスペリエンスを提供する必要があります。このシナリオでは、MemoryDB が正しい選択となります。インデックス作成技術の選択も、クエリパフォーマンスに大きな影響を与えます。Hierarchical Navigable Small World (HNSW) や inverted file with flat compression (IVFFlat) などの近似最近傍 (ANN) ベースの技術は、他の k-NN 技術に比べて検索パフォーマンスとのトレードオフを行い、最も関連性の高い結果を返します。これらのインデックス作成方法を理解することは、特定のユースケースとパフォーマンス要件に最適なデータベースを選択するために不可欠です。例えば、HNSW インデックスを使用した NVMe キャッシングによる Aurora Optimized Reads は、Optimized Reads を使用しないインスタンスと比較して、平均クエリスループットを最大 9 倍向上させることができます。

AWS は、アプリケーションのベクトル検索パフォーマンス要求を満たすために有用なデータベースを提供しています。これらのデータベースは、様々なパフォーマンス最適化技術と高度な監視ツールを提供し、組織がベクトルデータ管理ソリューションを微調整し、パフォーマンスのボトルネックに対処し、スケールで一貫したパフォーマンスを達成できるようにします。AWS のデータベースを使用することで、企業はベクトル検索要件の全ポテンシャルを解放し、リアルタイムの洞察、パーソナライズされたエクスペリエンス、成長とイノベーションを推進する革新的な AI および ML アプリケーションを実現できます。

高レベルのサービス特性

Well-Architected Framework の柱によってサポートされる、ベクトルワークロードを実行するための AWS のフルマネージドデータベースを選択することには、大きなメリットがあります。AWS インフラストラクチャのスケーラビリティ、セキュリティ、信頼性と、管理に関する運用の優秀性とベストプラクティスを組み合わせ、企業が確立されたデータベース技術を使用しながら、合理化された運用、軽減されたオーバーヘッド、ニーズの変化に応じてシームレスにスケールする能力の恩恵を受けられるからです。以下の特徴は、データベース評価プロセスにおいて重要であることが確認されたものです。

  • セマンティック検索 – セマンティック検索は、検索クエリの意味とコンテキストを理解し、より関連性の高い正確な結果を提供する情報検索技術です。セマンティック検索は、現在 AWS で提供されているベクトル検索機能をサポートする多くのデータベースでサポートされています。
  • サーバーレス – ユーザーの管理がほとんど、あるいは全く必要なく、効率的に需要を満たすようにデータベースが弾力的にスケールする能力です。サーバーレスは現在、OpenSearch Service と Aurora PostgreSQL で利用可能であり、両方とも完全に管理された RAG ワークフローを提供する Amazon Bedrock のナレッジベースと統合されています。
  • 次元数 – 多くの AWS の顧客は、幅広い次元数にわたるオープンソースまたはカスタム埋め込みモデルを採用しています。例えば、Amazon Bedrock 上の Cohere Embed English v3 の 1,024 次元や、256、512、または 1,024 次元を選択できる Amazon Titan Text Embeddings V2 などのモデルがあります。ベクトル検索をサポートする AWS データベースは、これらのモデルのすべてでこれらの次元数をサポートしており、スケーラビリティと機能の新しい標準を提供するために継続的にイノベーションを行っています。
  • インデックス作成 – 顧客ベースの中で最も広く採用されているインデックス作成アルゴリズムは HNSW であり、ベクトル検索をサポートするすべての AWS データベースサービスが HNSW をサポートしています。IVFFlat インデックス作成方法も、これらのデータベースサービスのサブセットでサポートされています。
  • 10 億スケールのベクトルワークロード – 2024 年から 2025 年にかけて、ベクトルワークロードがエンタープライズアプリケーションをサポートするために成長するにつれて、当社のデータベースサービスは 10 億スケールのベクトルワークロードを処理する準備が整っています。
  • 関連性 – ユースケースによってアプリケーションを最適化するには、再現率によって測定されるベクトル検索結果の関連性も確認する必要があります。ベクトル検索をサポートするすべての AWS データベースサービスは、何らかの形で設定可能な再現率をサポートしています。
  • ハイブリッド検索と事前フィルタリング – 多くの顧客は、特定の製品カテゴリ、地理的領域、またはその他のデータサブセクションに焦点を当てるために、ベクトル検索クエリを事前および事後にフィルタリングする方法を考慮しています。AWS データベースサービスは、ハイブリッド検索または事前フィルタリング機能のレイヤーを提供しています。Aurora PostgreSQL、Amazon RDS for PostgreSQL、MemoryDB、OpenSearch Service など、いくつかのサービスは、一歩進んだ全文検索とハイブリッド検索機能を提供しています。

まとめ

生成 AI アプリケーションに適したデータベースの選択は、成功の鍵です。親和性、実装の容易さ、スケーラビリティ、パフォーマンスなどの要因が重要ですが、この急速に進化する分野でより具体的なガイダンスの必要性を認識しています。AWS マネージドデータベースポートフォリオにおける現状の認識と利用可能なオプションに基づき、以下の通り推奨事項を列挙します。

  • すでに OpenSearch Service、Aurora PostgreSQL、RDS for PostgreSQL、DocumentDB、または MemoryDB を使用している場合は、既存のデータに対して既存データベースが持つベクトル検索機能を利用してください。
  • グラフベースの RAG アプリケーションの場合は、Amazon Neptune を検討してください。
  • データが DynamoDB に格納されている場合、ゼロ ETL 統合を使用したベクトル検索には OpenSearch が優れた選択肢となります。
  • 判断に迷う場合は、Amazon Bedrock のデフォルトのデータベースエンジンである OpenSearch Service をご検討ください。

生成 AI を取り巻く環境は流動的で、急速に進化し続けています。特定のデータセットと ML アルゴリズムを使用して異なるデータベースサービスをテストし、時間の経過とともにデータがどのように成長するかを考慮することをお勧めします。これにより、ワークロードに合わせてソリューションがシームレスにスケールできるようになります。

AWS は、それぞれ独自の強みを持つ多様なデータベースオプションを提供しています。AWS の強力なエコシステムを活用することで、組織はベクトルストレージと検索機能を備えた効率的でスケーラブルなデータベースでアプリケーションを強化し、イノベーションと競争優位性を推進できます。AWS はこの旅路をナビゲートするお手伝いをすることをお約束します。生成 AI の最適な進路を設計する上でさらに質問がある場合や支援が必要な場合は、エキスパートチームにお問い合わせください。

著者について

Shayon Sanyal は、プリンシパルデータベーススペシャリストソリューションアーキテクトであり、Amazon のフラッグシップリレーショナルデータベースである Amazon Aurora の SME (Subject Matter Expert) です。彼はリレーショナルデータベースと分析ワークロードの管理に 15 年以上の経験を持っています。Shayon は顧客成功への飽くなき献身を以て、顧客がスケーラブルで安全かつ堅牢なクラウドネイティブアーキテクチャを設計するのを支援しています。Shayon はまた、生成 AI などの先駆的な機能の設計と提供においてサービスチームを支援しています。

Graham Kutchek は、Amazon のすべてのデータベース製品にわたる専門知識を持つデータベーススペシャリストソリューションアーキテクトです。彼はメディアとエンターテインメント業界の専門家であり、世界最大のメディア企業の一部がスケーラブルで効率的かつ信頼性の高いデータベースデプロイメントを実行するのを支援しています。Graham は特にグラフデータベース、ベクトルデータベース、AI 推奨システムに焦点を当てています。

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