Amazon Web Services ブログ
Amazon OpenSearch Service ベクトルデータベースを自動最適化する
本記事は 2025 年 12 月 8 日 に公開された「Auto-optimize your Amazon OpenSearch Service vector database」を翻訳したものです。
AWS は先日、Amazon OpenSearch Service ベクトルエンジンの自動最適化機能の一般提供を発表しました。この機能は、検索品質、速度、コスト削減のトレードオフを自動的に評価することで、ベクトルインデックスの最適化を効率化します。その後、ベクトル取り込みパイプラインを実行して、目的のコレクションまたはドメインに最適化されたインデックスを構築できます。従来、アルゴリズム、圧縮、エンジン設定を含むインデックス構成の最適化には、専門家と数週間のテストが必要でした。最適化は特定のデータ特性と要件に固有であるため、このプロセスを繰り返す必要があります。自動最適化により、インフラストラクチャを管理したりインデックスチューニングの専門知識を習得したりすることなく、1 時間以内にベクトルデータベースを最適化できるようになりました。
この記事では、自動最適化機能の仕組み、そのメリット、および自動最適化の結果例を紹介します。
ベクトル検索とベクトルインデックスの概要
ベクトル検索は、検索品質を向上させる技術であり、生成 AI アプリケーションの基盤となっています。AI モデルを使用してコンテンツを数値エンコーディング (ベクトル) に変換し、キーワードだけでなく意味的な類似性によるコンテンツマッチングを可能にします。ベクトルを OpenSearch に取り込んでインデックスを構築することで、数十億のベクトルをミリ秒単位で検索できるベクトルデータベースを構築します。
ベクトルインデックスの最適化のメリットと仕組み
OpenSearch ベクトルエンジンは、検索品質 (再現率)、速度 (レイテンシー)、コスト (RAM 要件) の間で有利なトレードオフを行うのに役立つさまざまなインデックス構成を提供します。普遍的に最適な構成は存在しません。専門家は、Hierarchal Navigable Small Worlds (HNSW) アルゴリズムパラメータ (m や ef_construction など)、量子化技術 (スカラー、バイナリ、プロダクトなど)、エンジンパラメータ (メモリ最適化、ディスク最適化、ウォームコールドストレージなど) の組み合わせを評価する必要があります。構成の違いにより、検索品質で 10% 以上の差、検索レイテンシーで数百ミリ秒の差、またはコスト削減で最大 3 倍の差が生じる可能性があります。大規模なデプロイメントでは、コスト最適化が予算を左右する可能性があります。
次の図は、インデックス構成間のトレードオフの概念図です。
ベクトルインデックスの最適化には時間がかかります。専門家はインデックスを構築し、その速度、品質、コストを評価し、適切な構成調整を行ってから、このプロセスを繰り返す必要があります。大規模なインデックスの構築と評価には相当な計算能力が必要で、1 つのインデックスだけで数時間から数日の処理が必要になるため、これらの実験を大規模に実行するには数週間かかる可能性があります。最適化は特定のビジネス要件と各データセットに固有であり、トレードオフの決定は主観的です。最適なトレードオフは、社内 Wiki の検索や e コマースサイトなど、ユースケースによって異なります。そのため、このプロセスはインデックスごとに繰り返す必要があります。最後に、アプリケーションデータが継続的に変化する場合、ベクトル検索の品質が低下する可能性があり、ベクトルインデックスを定期的に再構築して再度最適化する必要があります。
ソリューションの概要
自動最適化を使用すると、ジョブを実行して最適化の推奨事項を生成できます。これには、パフォーマンス測定値と推奨構成の説明を詳述したレポートが含まれます。アプリケーションの許容可能な検索レイテンシーと品質要件を指定するだけで、自動最適化ジョブを構成できます。k-NN アルゴリズム、量子化技術、エンジン設定の専門知識は必要ありません。事前構成された少数のデプロイメントタイプに基づくソリューションの画一的な制限を回避し、ワークロードに合わせたカスタマイズを提供します。前述の手動作業を自動化します。ジョブごとの定額料金でサーバーレスの自動最適化ジョブを実行するだけです。これらのジョブはコレクションやドメインのリソースを消費しません。OpenSearch Service は別のマルチテナントウォームプールサーバーを管理し、セキュアなシングルテナントワーカー間でインデックス評価を並列化して、結果を迅速に提供します。自動最適化はベクトル取り込みパイプラインとも統合されているため、Amazon Simple Storage Service (Amazon S3) データソースからコレクションまたはドメインに最適化されたベクトルインデックスを迅速に構築できます。
次のスクリーンショットは、OpenSearch Service コンソールで自動最適化ジョブを構成する方法を示しています。
ジョブが完了すると (通常、100 万以上のサイズのデータセットで 30〜60 分以内)、次のスクリーンショットに示すように、推奨事項とレポートを確認できます。
このスクリーンショットは、最適なトレードオフを選択する必要がある例を示しています。最高のコスト削減 (メモリ要件の削減による) を実現する最初のオプションを選択しますか？それとも、1.76% の検索品質向上を実現するが、コストが高くなる 3 番目のオプションを選択しますか？これらの結果を提供するために使用された構成の詳細を理解したい場合は、前のスクリーンショットに示されている Algorithm parameters タブなど、Details ペインのサブタブを表示できます。
選択後、次のスクリーンショットに示すように、ターゲットの OpenSearch Service ドメインまたはコレクションに最適化されたインデックスを構築できます。コレクションまたは OpenSearch 3.1 以降を実行しているドメインにインデックスを構築する場合、GPU アクセラレーションを有効にして、構築速度を最大 10 倍高速化し、インデックス作成コストを 4 分の 1 に削減できます。
自動最適化の結果
次の表は、自動最適化の結果例をいくつか示しています。自動最適化を実行する価値を定量化するために、デフォルト設定と比較した改善を示しています。推定 RAM 要件は、標準的なドメインサイジング推定に基づいています。
必要な RAM = 1.1 x (次元あたりのバイト数 x 次元数 + hnsw.parameters.m x 8) x ベクトル数
デフォルト設定と最適化設定でインデックスをホストするための最小限のインフラストラクチャ (十分な RAM を持つ) を比較することで、コスト削減を推定しています。
| データセット | 自動最適化ジョブの構成 | デフォルトからの推奨変更 |
必要な RAM (削減率) |
推定コスト削減 (デフォルト構成と最適化構成に必要なデータノード) |
再現率 (改善率) |
| msmarco-distilbert-base-tas-b: MSMARCO v1 から生成された 1,000 万 384 次元ベクトル | 許容再現率 >= 0.95、中程度のレイテンシー (約 200〜300 ms) | インデックス作成と検索メモリの増加 (ef_search=256, ef_constructon=128)、Lucene エンジンの使用、5 倍オーバーサンプリングのディスク最適化モード、4 倍圧縮 (4 ビットバイナリ量子化) |
5.6 GB (-69.4%) |
75% 削減 (3 x r8g.medium.search vs. 3 x r8g.xlarge.search) |
0.995(+2.6%) |
| all-mpnet-base-v2: MSMARCO v2.1 から生成された 100 万 768 次元ベクトル | 許容再現率 >= 0.95、中程度のレイテンシー (約 200〜300 ms) | より密な HNSW グラフ (m=32)、インデックス作成と検索メモリの増加 (ef_search=256, ef_constructon=128)、3 倍オーバーサンプリングのディスク最適化モード、8 倍圧縮 (4 ビットバイナリ量子化) |
0.7GB (-80.9%) |
50.7% 削減 (t3.small.search vs. t3.medium.search) |
0.999 (+0.9%) |
| Cohere Embed V3: MSMARCO v2.1 から生成された 1 億 1,300 万 1024 次元ベクトル | 許容再現率 >= 0.95、高速レイテンシー (約 50 ms 以下) | より密な HNSW グラフ (m=32)、インデックス作成と検索メモリの増加 (ef_search=256, ef_constructon=128)、Lucene エンジンの使用、4 倍圧縮 (uint8 スカラー量子化) |
159GB (-69.7%) |
50.7% 削減 (6 x r8g.4xlarge.search vs. 6 x r8g.8xlarge.search) |
0.997 (+8.4%) |
まとめ
OpenSearch Service コンソールの Vector ingestion ページで、自動最適化されたベクトルデータベースの構築を開始できます。この機能を GPU アクセラレーションベクトルインデックスと組み合わせて使用し、数時間以内に最適化された数十億規模のベクトルデータベースを構築できます。
自動最適化は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、シンガポール、シドニー、東京)、欧州 (フランクフルト、アイルランド、ストックホルム) の AWS リージョンで、OpenSearch Service ベクトルコレクションおよび OpenSearch 2.17 以降のドメインで利用できます。
著者について
Dylan Tong Amazon Web Services のシニアプロダクトマネージャーです。OpenSearch のベクトルデータベース機能を含む、OpenSearch の AI および機械学習 (ML) の製品イニシアチブをリードしています。Dylan は、データベース、分析、AI/ML 分野で顧客と直接協力し、製品やソリューションを作成してきた数十年の経験があります。Dylan は Cornell University でコンピュータサイエンスの学士号と修士号を取得しています。
Vamshi Vijay Nakkirtha OpenSearch Project と Amazon OpenSearch Service に取り組むソフトウェアエンジニアリングマネージャーです。主な関心分野は分散システムです。
Vikash Tiwari AWS のシニアソフトウェア開発エンジニアで、OpenSearch ベクトル検索を専門としています。分散システム、大規模機械学習、スケーラブルな検索アーキテクチャ、データベース内部に情熱を持っています。専門分野はベクトル検索、インデックス最適化、効率的なデータ取得であり、最新のデータベースシステムの学習と強化に深い関心を持っています。
Janelle Arita AWS で OpenSearch に取り組む UX デザイナーです。オブザーバビリティ、セキュリティ分析、検索ワークフローの直感的なユーザーエクスペリエンスの作成に注力しています。ユーザー中心のデザインとデータ駆動型のインサイトを通じて、複雑な運用上の課題を解決することに情熱を持っています。
Huibin Shen AWS のサイエンティストで、機械学習とその応用に関心を持っています。
この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。