Elasticsearch BBQ vs. OpenSearch FAISS: ベクトル検索パフォーマンス比較

ベクトル検索から強力なREST APIまで、Elasticsearchは開発者に最も広範な検索ツールキットを提供します。GitHubのサンプルノートブックにアクセスして新しいことを試してみましょう。また、無料トライアルを始めるか、ローカルでElasticsearchを実行することもできます。

バイナリ量子化によるベクトル検索: BBQ を使用した Elasticsearch は、 FAISS を使用した OpenSearch よりも 5 倍高速です。Elastic はコミュニティから、特にセマンティック検索/ベクター検索の領域における Elasticsearch と OpenSearch のパフォーマンスの違いを明確にしてほしいというリクエストを受けており、明確でデータに基づいた比較を提供するためにこれらのパフォーマンス テストを実施しました。

バイナリ量子化対決

高次元ベクトルを元の形式で保存すると、メモリを大量に消費する可能性があります。量子化技術はこれらのベクトルをコンパクトな表現に圧縮し、メモリフットプリントを大幅に削減します。その後、検索は圧縮された空間で実行されるため、計算の複雑さが軽減され、特に大規模なデータセットでは検索が高速化されます。

Elastic は、Lucene を最高のパフォーマンスを発揮するベクター エンジンにすることに注力しています。Elasticsearch 8.16 では Lucene をベースにBetter Binary Quantization (BBQ) を導入し、8.18 および 9.0 でさらに進化させました。BBQ は、float32 次元をビットに削減するスカラー量子化の新しいアプローチに基づいて構築されており、高いランキング品質を維持しながら約 95% のメモリ削減を実現します。

一方、OpenSearch は、nmslib (現在は非推奨)、Lucene、FAISS といった複数のベクター エンジンを使用します。以前のブログでは、ベクトル検索について Elasticsearch と OpenSearch を比較しました。3 つの異なるデータセットを使用し、両方の製品でさまざまなエンジンと構成の組み合わせをテストしました。

このブログでは、現在両方の製品で利用可能なバイナリ量子化アルゴリズムに焦点を当てています。openai_vector Rally トラックを使用して、Elasticsearch と BBQ および OpenSearch と FAISS のバイナリ量子化を テストしました。

主な目的は、同じレベルの再現率で両方のソリューションのパフォーマンスを評価することでした。リコールとはどういう意味ですか?リコールは、検索システムによって関連結果がどれだけ正常に取得されたかを測定する指標です。

この評価では、recall@k が特に重要です。ここで、 k は検討される上位の結果の数を表します。したがって、 Recall@10 、 Recall@50、および Recall@100 は、それぞれ上位 10、50、および 100 件の取得された項目内に表示される実際の関連結果の数を測定します。再現率は 0 ～ 1 (または 0% ～ 100% の精度) のスケールで表されます。これは重要なことです。なぜなら、ここでは再現率が常に 1 (100%) となる正確な KNN ではなく、近似 KNN (ANN) について話しているためです。

kの各値に対して、最終的なランキングを適用する前に考慮される候補の数であるnも指定しました。つまり、Recall@10、Recall@50、および Recall@100 の場合、システムは最初にバイナリ量子化アルゴリズムを使用してn個の候補を取得し、次にそれらをランク付けして、上位k 個の結果に期待される関連項目が含まれているかどうかを判断します。

n を制御することで、効率と精度のトレードオフを分析できます。通常、 nが大きいほど、ランキングに使用できる候補が増えるためリコールは増加しますが、レイテンシも増加し、スループットは低下します。逆に、 nを小さくすると検索速度は上がりますが、初期セットに含まれる関連候補が少なすぎるとリコール率が低下する可能性があります。

この比較では、Elasticsearch は同一の設定で OpenSearch よりも低いレイテンシと高いスループットを示しました。

方法論

完全な構成、Terraform スクリプト、Kubernetes マニフェスト、および特定の Rally トラックは、このリポジトリのopenai_vector_bqで入手できます。

以前のベンチマークと同様に、次のもので構成される Kubernetes クラスターを使用しました。

• Elasticsearch 9.0 用の 1 つのノードプール（3 台のe2-standard-32マシン、128 GB の RAM、32 個の CPU）
• OpenSearch 2.19 用の 1 つのノード プール (3 台のe2-standard-32マシン (128 GB RAM、32 個の CPU))
• Rally 用の 1 つのノードプール（2 台のe2-standard-4マシン、16 GB の RAM と 4 つの CPU）

Elasticsearch クラスター バージョン 9.0 を 1 つと OpenSearch クラスター バージョン 2.19 を 1 つセットアップしました。

Elasticsearch と OpenSearch は両方ともまったく同じ設定でテストされました。 つまり、OpenAI の text-embedding-ada-002 モデルを使用して生成された埋め込みが強化された NQ データ セットからの 250 万のドキュメントを使用する、いくつかの変更 を 加え た openai_vector Rally トラック を使用しました。

結果には、8 つの同時クライアントを使用して検索操作を実行し、さまざまなリコール レベル (recall@10、recall@50、recall@100) で測定されたレイテンシとスループットが報告されています。単一のシャードを使用し、レプリカは使用しませんでした。

我々は以下のkn-rescoreの組み合わせを実行した。10-2000-2000、またはk:10 、 n:2000 、 rescore:2000 は、2000 件の結果に対して再スコアを適用して、n 件の候補 (2000) のうち上位 k 件 (10) を取得します (これは「オーバーサンプル係数」が 1 の場合に相当します)。各検索はウォームアップとして 1,000 回実行され、10,000 回実行されました。

リコール@10

• 10-40-40
• 10-50-50
• 10-100-100
• 10-200-200
• 10-500-500
• 10-750-750
• 10-1000-1000
• 10-1500-1500
• 2000年10月

リコール@50

• 50-150-150
• 50-200-200
• 50-250-250
• 50-500-500
• 50-750-750
• 50-1000-1000
• 50-1200-1200
• 50-1500-1500
• 50-2000-2000

リコール@100

• 100-200-200
• 100-250-250
• 100-300-300
• 100-500-500
• 100-750-750
• 100-1000-1000
• 100-1200-1200
• 100-1500-1500
• 100-2000-2000

ベンチマークを再現するために、rally-elasticsearch と rally-opensearch の両方の Kubernetes マニフェストには、関連するすべての変数が ConfigMap で外部化されており、こちら(ES) とこちら(OS) から入手できます。search_opsパラメータは、k、n、rescore の任意の組み合わせをテストするようにカスタマイズできます。

OpenSearch Rallyの設定

/k8s/rally-openai_vector-os-bq.yml

Opensearchインデックス設定

ConfigMap の変数はインデックス構成で使用され、一部のパラメータは変更されません。OpenSearch における 1 ビット量子化は、圧縮レベルを「32x」に設定することによって設定されます。

index-vectors-only-mapping-with-docid-mapping.json

Elasticsearch Rallyの設定

/k8s/rally-openai_vector-es-bq.yml

Elasticsearchインデックス設定

index-vectors-only-mapping-with-docid-mapping.json

成果

結果を解釈する方法は複数あります。レイテンシとスループットの両方について、リコールの各レベルで簡略化されたグラフと詳細なグラフをプロットしました。各指標について「高いほど良い」と考えると、違いが簡単にわかります。ただし、レイテンシはマイナス（低い方が実際には良い）であり、スループットはプラスです。簡略化されたグラフでは、 (リコール / レイテンシ) * 10000 (単に「速度」と呼びます) とリコール * スループットを使用しました。したがって、両方のメトリックは、速度とスループットが高いほど優れていることを意味します。始めましょう。

10回想 - 簡略化

この再現レベルでは、Elasticsearch BBQ は OpenSearch FAISS よりも最大5 倍高速(平均で 3.9 倍高速) で、平均で3.2 倍のスループットを実現します。

リコール@10 - 詳細

50歳の思い出 - 簡略化

この再現率では、Elasticsearch BBQは最大5倍（平均4.2倍）高速で、平均3.9倍のスループットを実現しています。 OpenSearch FAISSよりも。

詳細な結果 - 50 回のリコール

リコール@100

この再現レベルでは、Elasticsearch BBQ は OpenSearch FAISS よりも最大 5 倍高速(平均 4.6 倍高速) で、平均で3.9 倍のスループットを実現します。

詳細な結果 - 再現率 100

バーベキューの改良

BBQ は最初のリリース以来長い道のりを歩んできました。Elasticsearch 8.16 では、比較のために、8.16 のベンチマーク実行を現在のものと並べて含めており、それ以降、リコールとレイテンシーがどのように改善されたかを確認できます。

Elasticsearch 8.18 および 9.0 では、ベクトルを量子化するためのコア アルゴリズムを書き直しました。つまり、8.16 の BBQ は良かったのですが、最新バージョンはさらに良くなっています。それについてはこことここで読むことができます。つまり、すべてのベクトルは、最適化されたスカラー分位数を通じて個別に量子化されます。その結果、ユーザーはパフォーマンスを犠牲にすることなくベクトル検索の精度向上の恩恵を受けることができ、Elasticsearch のベクトル検索はさらに強力になります。

まとめ

Elasticsearch BBQ と OpenSearch FAISS のパフォーマンス比較では、Elasticsearch はベクトル検索において OpenSearch を大幅に上回り、さまざまなレベルのリコールで平均最大 5 倍のクエリ速度と 3.9 倍のスループットを達成しています。

主な調査結果は次のとおりです。

• Recall@10 : Elasticsearch BBQ は、OpenSearch FAISS と比較して最大 5 倍高速 (平均 3.9 倍高速) で、平均 3.2 倍のスループットを実現します。
• Recall@50 : Elasticsearch BBQ は、OpenSearch FAISS と比較して最大 5 倍高速 (平均で 4.2 倍高速) で、平均で 3.9 倍のスループットを実現します。
• Recall@100 : Elasticsearch BBQ は、OpenSearch FAISS と比較して最大 5 倍高速 (平均で 4.6 倍高速) で、平均で 3.9 倍のスループットを実現します。

これらの結果は、特に高次元ベクトル検索シナリオにおける Elasticsearch BBQ の効率性とパフォーマンスの利点を強調しています。Elasticsearch 8.16 で導入された Better Binary Quantization (BBQ) 技術は、高いランキング品質を維持しながらメモリを大幅に削減 (約 95%) するため、大規模なベクトル検索アプリケーションに最適です。

Elastic では、RAG (Retrieval Augmented Generation) を含む検索および取得ユースケースに最適なベクター データベースを提供するために、Apache Lucene と Elasticsearch を改良するための革新を絶えず続けています。最近の進歩によりパフォーマンスが劇的に向上し、Lucene 10 から得た成果を基にして、ベクター検索が以前よりも高速かつスペース効率が高くなりました。このブログは、その革新のもう一つの例です。