Amazon Web Services ブログ
OpenSearch ベクトルエンジンのディスク最適化により、精度を維持しつつコスト削減が可能に
この記事は、OpenSearch Vector Engine is now disk-optimized for low cost, accurate vector search を翻訳したものです。
OpenSearch ベクトルエンジンは、OpenSearch 2.17 以降のドメインで、従来の 3 分の 1 のコストでベクトル検索を実行できるようになりました。k-NN (ベクトル) インデックスをディスクモードで実行するように設定し、メモリに制約のある環境に最適化することで、数百ミリ秒単位で応答する低コストで正確なベクトル検索が可能になりました。ディスクモードは、一桁ミリ秒に近いレイテンシーを求めない場合、従来のメモリモードの経済的な代替手段となります。
本記事では、この新機能の利点、基本的な仕組み、お客様の成功事例、そして始め方についてご紹介します。
ベクトル検索と OpenSearch ベクトルエンジンの概要
ベクトル検索は、機械学習 (ML) モデルによってベクトル (数値エンコーディング) にエンコードされたコンテンツに対して類似性検索を実行することで、検索の精度を向上させる手法です。これによりセマンティック検索のようなユースケースが可能になり、キーワードだけでなくコンテキストや意図も考慮した、より関連性の高い検索結果を提供できます。
OpenSearch ベクトルエンジンは、ベクトル化されたコンテンツに対してインデックスを作成することで、数十億のベクトルを超えるリアルタイムのベクトル検索を可能にします。これにより、質問、キーワード、または ML モデルによってエンコードされた画像・音声クリップ・テキストなどのコンテンツに対して、最も類似する上位 K 件のドキュメントを検索できます。
OpenSearch ベクトルエンジンのチューニング
検索アプリケーションには、速度、品質、コストに関してさまざまな要件があります。例えば、e コマースのカタログでは、購買体験を向上させるために、できるだけ短い応答時間と高品質な検索が求められます。しかし、検索の品質とパフォーマンスを最適化するには、追加のメモリやコンピューティングリソースが必要となり、コストが発生します。
速度、品質、コストの適切なバランスは、ユースケースとお客様の期待することによって異なります。OpenSearch ベクトルエンジンには包括的なチューニングオプションが用意されているため、独自の要件に応じた最適な結果を得るためのトレードオフのバランスを柔軟に調整できます。
以下のチューニングオプションを利用できます。
- アルゴリズムとパラメータ – 以下が含まれます。
- Hierarchical Navigable Small World (HNSW) アルゴリズムと、
ef_search
、ef_construct
、m
などのパラメータ - Inverted File Index (IVF) アルゴリズムと、
nlist
、nprobes
などのパラメータ - Exact k-nearest neighbors (k-NN)、別名 brute-force k-NN (BFKNN) アルゴリズム
- Hierarchical Navigable Small World (HNSW) アルゴリズムと、
- エンジン – Facebook AI Similarity Search (FAISS)、Lucene、Non-metric Space Library (NMSLIB)
- 圧縮手法 – スカラー (バイト、半精度など)、バイナリ、直積量子化
- 類似度 (距離) 指標 – 内積、コサイン類似度、L1 距離、L2 距離、ハミング距離
- ベクトル埋め込みタイプ – 可変次元の密ベクトルと疎 (スパース) ベクトル
- ランキングとスコアリング手法 – ベクトル検索、ハイブリッド検索 (ベクトルと Best Match 25 (BM25) スコアの組み合わせ)、マルチステージランキング (Cross-encoder や Personalizer など)
これらのチューニングオプションを適切に組み合わせることで、ニーズに最適化された速度、品質、コストのバランスを実現できます。以下の図では、サンプル構成の大まかなパフォーマンスプロファイルを示しています。
ディスク最適化のチューニング
OpenSearch 2.17 以降では、k-NN インデックスをディスクモードで実行できるようになり、インメモリのパフォーマンスと引き換えにレイテンシを高めることで、高品質かつ低コストなベクトル検索を実現できます。ユースケースの要件が 90 パーセンタイル (P90) のレイテンシー 100 〜 200 ミリ秒の範囲で満たされる場合、ディスクモードはコスト削減を実現しながら高い検索品質を維持するのに最適なオプションです。次の図は、さまざまなエンジン構成の中でのディスクモードのパフォーマンス特性を示しています。
ディスクモードは、すぐに利用できるように設計されており、メモリモードと比較して メモリ要件を 97% 削減 しながら高い検索品質を提供します。ただし、圧縮率とサンプリング率を調整することで、速度、品質、コストを調整できます。
以下の表は、ディスクモードのデフォルト設定におけるパフォーマンスベンチマークを示しています。最初の 3 つのテストには OpenSearch Benchmark (OSB) を使用し、最後の 2 つのテストには VectorDBBench (VDBB) を使用しました。最適な結果を得るために、パフォーマンスチューニングのベストプラクティスを適用しています。小規模テスト (Tasb-1M と Marco-1M) は、1 つのレプリカを持つ単一の r7gd.large データノードで実行しました。その他のテストは、1 つのレプリカを持つ 2 つの r7gd.2xlarge データノードで実行しました。コスト削減率は、デフォルト設定と同等の適切なサイズのインメモリモードでのデプロイメントと比較して計算されています。
データセット | Recall@100 (検索精度) | p90 レイテンシー (ms) | 次元数 | ベクトル数 (百万) | コスト削減率 | モデル | ソース |
Cohere TREC-RAG | 0.94 | 104 | 1024 | 113 | 67% | Cohere Embed V3 | 前処理済み |
Tasb-1M | 0.96 | 7 | 768 | 1 | 83% | msmacro-distilbert-base-tas-b | 未処理 |
Marco-1M | 0.99 | 7 | 768 | 1 | 67% | msmarco-distilbert | 未処理 |
OpenAI 5M | 0.98 | 62 | 1536 | 5 | 67% | text-embedding-ada-002 | 生成済み |
LAION 100M | 0.93 | 169 | 768 | 100 | 67% | CLIP | 生成済み |
これらのテストは、ディスクモードが様々なデータセットとモデルで 32 倍の圧縮を実現し、目標レイテンシー (P90 200 ミリ秒未満) を維持しながら高い検索品質を提供できることを示すために設計されています。なお、これらのベンチマークは ML モデルの評価を目的としたものではありません。モデルが検索品質に与える影響は、データセットを含む複数の要因によって変わります。
ディスクモード最適化の仕組み
ディスクモードで k-NN インデックスを実行するように構成すると、OpenSearch は自動的に量子化手法を適用し、ベクトルを圧縮しながらロードして圧縮インデックスを構築します。デフォルトでは、ディスクモードは、数百から数千の次元からなる完全な精度のベクトル (各次元が 32 ビット数値として格納されている) を、各次元を 1 ビットで表すバイナリベクトルに変換します。この変換により、32 倍の圧縮率が得られ、完全な精度のベクトルで構成されるインデックスと比較して 97% 小さいインデックスを構築できます。適切なサイズのクラスターであれば、この圧縮されたインデックスをメモリ内に保持できます。
圧縮によってベクトルエンジンのメモリ要件が削減されるため、コストは低くなりますが、その代償として精度が低下します。ディスクモードは、精度と検索品質を維持するために、2 段階の検索プロセスを使用しています。クエリ実行の最初の段階では、メモリ内の圧縮インデックスを効率的に走査して、候補となるベクトルを検索します。2 番目の段階では、これらの候補をもとに、対応する完全な精度のベクトルをオーバーサンプリングします。これらの完全な精度のベクトルは、I/O を削減し、ディスク検索の速度と効率を最適化するように設計されたフォーマットでディスクに格納されています。その後、この完全な精度のベクトルのサンプルを使用して、フェーズ 1 の検索結果を補強し、再スコアリング (exact k-NN を使用) を行うことで、圧縮による検索品質の低下を防ぎます。ディスクモードのレイテンシがインメモリモードよりも高くなるのは、この再スコアリング処理によるものです。このプロセスでは、ディスクアクセスと追加の計算が必要となるため、相対的に処理時間が長くなります。
初期のお客様の成功事例
ベクトルエンジンのディスクモードは、すでに多くの企業で導入されています。ここでは、初期導入企業の事例を紹介します。
Asana は、OpenSearch のベクトルエンジンを通じてセマンティック検索機能を段階的に導入することで、ワークマネジメントプラットフォームにおける検索品質を向上させています。当初は 直積量子化 を使用してインデックスを 16 倍に圧縮することでデプロイを最適化しましたが、ディスク最適化構成に切り替えることで、検索品質とレイテンシーの目標を維持しながら、さらに 33% のコスト削減が可能になりました。このコスト構造の改善により、Asana は数十億ものベクトルにスケールし、プラットフォーム全体でセマンティック検索を民主化することが可能になりました。
DevRev は、顧客対応チームと開発者を直接つなぐことで、ソフトウェア企業の根本的なギャップを解消します。AI 中心のプラットフォームとして、顧客からのフィードバックから製品開発への直接的な経路を作り、1,000 社以上の企業が正確な検索、高速な分析、カスタマイズ可能なワークフローを活用して成長を加速できるようサポートしています。大規模言語モデル (LLM) と OpenSearch のベクトルエンジン上で実行される Retrieval Augmented Generation (RAG) フローに基づいて構築された DevRev は、インテリジェントな会話体験を実現します。
「OpenSearch のディスク最適化されたベクトルエンジンを使用することで、16 倍の圧縮を実現しつつ、検索品質とレイテンシーの目標を達成しました。OpenSearch は、当社の数十億ベクトル規模の検索において、スケーラブルで経済的な選択肢を提供してくれます。」
– Anshu Avinash, Head of AI and Search, DevRev
OpenSearch ベクトルエンジンのディスクモードを利用開始する
まず、インデックスをホストするために必要なリソースを決定する必要があります。デフォルトの 32 倍の圧縮率を使用したディスク最適化 k-NN インデックスをサポートするために必要なメモリを、次の式を使って見積もります。
必要なメモリ (バイト) = 1.1 x ((ベクトル次元数)/8 + 8 x m) x (ベクトル数)
例えば、Amazon Titan Text V2 のデフォルト設定を使用する場合、ベクトルの次元数は 1024 になります。ディスクモードでは HNSW アルゴリズムを使用してインデックスを構築するため、「m」はアルゴリズムのパラメータの 1 つで、デフォルトは 16 です。10 億個のベクトルを持つコーパスを Amazon Titan Text でエンコードしてインデックスを作成する場合、必要なメモリは 282 GB となります。
高スループットのワークロードを扱う場合は、ドメインに十分な IOPS と CPU が確保されているかを確認する必要があります。デプロイのベストプラクティスに従えば、インスタンスストアとストレージ最適化インスタンスタイプを利用でき、一般的には十分な IOPS が得られます。高スループットワークロードの場合は必ず負荷テストを実施し、IOPS や CPU の要件を考慮して初期見積もりを調整してください。
今すぐ、ニーズに合わせて適切なサイズに設定された OpenSearch 2.17 + ドメインをデプロイできます。k-NN インデックスを作成する際に、mode パラメータを on_disk に設定してから、データを取り込んでください。すでにデフォルトの in_memory
モードで k-NN インデックスを実行している場合は、モードを on_disk
に切り替えた後、reindex 処理を実行することで変換できます。インデックスの再構築が完了したら、それに応じてドメインのサイズを調整してください。
結論
この記事では、OpenSearch ベクトルエンジンをディスクモードで実行することのメリット、お客様の成功事例、および導入の手順について説明しました。これで、従来のコストの 3 分の 1 まで抑えながら OpenSearch ベクトルを運用できる準備が整いました。
詳細は、ドキュメントを参照してください。