Ugo Sangiorgi - Elasticsearch Labs

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

Ugo Sangiorgi — Tue, 15 Apr 2025 00:00:00 GMT

バイナリ量子化によるベクトル検索: 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 トラックを使用しました。

{ "source-file": "open_ai_corpus-initial-indexing.json.bz2", "document-count": 2580961, "compressed-bytes": 32076749416, "uncompressed-bytes": 90263571686 }

結果には、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

apiVersion: v1 kind: ConfigMap metadata: name: rally-params-os labels: app: rally-opensearch data: user-tags.json: | { "product": "OpenSearch", "product-version": "OpenSearch-2.19.0", "product-label": "OpenSearch-2.19-faiss", "benchmark-run": "19-feb-recall@100" } track-params.json: | { "mapping_type": "vectors-only-mapping-with-docid", "standalone_search_clients": 8, "standalone_search_iterations": 5000, "ann_threshold": 0, "vector_mode": "on_disk", "compression_level": "32x", "vector_method_name": "hnsw", "vector_method_engine": "faiss", "search_ops": [ [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] ] }

Opensearchインデックス設定

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

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

{ "settings": { {% if preload_pagecache %} "index.store.preload": [ "vec", "vex", "vem", "veq", "veqm", "veb", "vebm" ], {% endif %} "index.number_of_shards": {{ number_of_shards | default(1) }}, "index.number_of_replicas": {{ number_of_replicas | default(0) }}, "index.knn": true, "index.knn.advanced.approximate_threshold": {{ ann_threshold | default(15000) }} }, "mappings": { "dynamic": false, "properties": { "docid": { "type": "keyword" }, "emb": { "type": "knn_vector", "dimension": 1536, "space_type": "innerproduct", "data_type": "float", "mode": {{ vector_mode | default("in_memory") | tojson }}, "compression_level": {{ compression_level | default("32x") | tojson }}, "method": { "name": {{ vector_method_name | default("hnsw") | tojson }}, "engine": {{ vector_method_engine | default("faiss") | tojson }}, "parameters": { "ef_construction": 100, "m": 16 } } } } } }

Elasticsearch Rallyの設定

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

apiVersion: v1 kind: ConfigMap metadata: name: rally-params-es labels: app: rally-elasticsearch data: user-tags.json: | { "product": "Elasticsearch", "product-version": "Elasticsearch-9.0.0-ade01164", "product-label": "Elasticsearch-9.0-BBQ", "benchmark-run": "19-feb-recall@100" } track-params.json: | { "mapping_type": "vectors-only-mapping-with-docid", "standalone_search_clients": 8, "standalone_search_iterations": 5000, "vector_index_type": "bbq_hnsw", "search_ops": [ [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] ] }

Elasticsearchインデックス設定

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

{ "settings": { {# non-serverless-index-settings-marker-start #} {%- if build_flavor != "serverless" or serverless_operator == true -%} {% if preload_pagecache %} "index.store.preload": [ "vec", "vex", "vem", "veq", "veqm", "veb", "vebm" ], {% endif %} "index.number_of_shards": {{ number_of_shards | default(1) }}, "index.number_of_replicas": {{ number_of_replicas | default(0) }} {%- endif -%} {# non-serverless-index-settings-marker-end #} }, "mappings": { "dynamic": false, "properties": { "docid": { "type": "keyword" }, "emb": { "type": "dense_vector", "element_type": "float", "dims": 1536, "index": true, "similarity": "dot_product", "index_options": { "type": {{ vector_index_type | default("bbq_hnsw") | tojson }}, "ef_construction": 100, "m": 16 } } } } }

成果

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

10回想 - 簡略化

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

リコール@10 - 詳細

タスク

レイテンシ平均

スループット平均

平均再現率

Elasticsearch-9.0-BBQ

10-100-100

11.70

513.58

0.89

Elasticsearch-9.0-BBQ

10-1000-100

27.33

250.55

0.95

Elasticsearch-9.0-BBQ

10-1500-1500

35.93

197.26

0.95

Elasticsearch-9.0-BBQ

10-200-200

13.33

456.16

0.92

Elasticsearch-9.0-BBQ

2000年10月

44.27

161.40

0.95

Elasticsearch-9.0-BBQ

10-40-40

10.97

539.94

0.84

Elasticsearch-9.0-BBQ

10-50-50

11時00分

535.73

0.85

Elasticsearch-9.0-BBQ

10-500-500

19.52

341.45

0.93

Elasticsearch-9.0-BBQ

10-750-750

22.94

295.19

0.94

OpenSearch-2.19-faiss

10-100-100

35.59

200.61

0.94

OpenSearch-2.19-faiss

10-1000-1000

156.81

58.30

0.96

OpenSearch-2.19-faiss

10-1500-1500

181.79

42.97

0.96

OpenSearch-2.19-faiss

10-200-200

47.91

155.16

0.95

OpenSearch-2.19-faiss

2000年10月

232.14

31.84

0.96

OpenSearch-2.19-faiss

10-40-40

27.55

249.25

0.92

OpenSearch-2.19-faiss

10-50-50

28.78

245.14

0.92

OpenSearch-2.19-faiss

10-500-500

79.44

97.06

0.96

OpenSearch-2.19-faiss

10-750-750

104.19

75.49

0.96

50歳の思い出 - 簡略化

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

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

タスク

レイテンシ平均

スループット平均

平均再現率

Elasticsearch-9.0-BBQ

50-1000-1000

25.71

246.44

0.95

Elasticsearch-9.0-BBQ

50-1200-1200

28.81

227.85

0.95

Elasticsearch-9.0-BBQ

50-150-150

13.43

362.90

0.90

Elasticsearch-9.0-BBQ

50-1500-1500

33.38

202.37

0.95

Elasticsearch-9.0-BBQ

50-200-200

12.99

406.30

0.91

Elasticsearch-9.0-BBQ

50-2000-2000

42.63

163.68

0.95

Elasticsearch-9.0-BBQ

50-250-250

14.41

373.21

0.92

Elasticsearch-9.0-BBQ

50-500-500

17.15

341.04

0.93

Elasticsearch-9.0-BBQ

50-750-750

31.25

248.60

0.94

OpenSearch-2.19-faiss

50-1000-1000

125.35

62.53

0.96

OpenSearch-2.19-faiss

50-1200-1200

143.87

54.75

0.96

OpenSearch-2.19-faiss

50-150-150

43.64

130.01

0.89

OpenSearch-2.19-faiss

50-1500-1500

169.45

46.35

0.96

OpenSearch-2.19-faiss

50-200-200

48.05

156.07

0.91

OpenSearch-2.19-faiss

50-2000-2000

216.73

36.38

0.96

OpenSearch-2.19-faiss

50-250-250

53.52

142.44

0.93

OpenSearch-2.19-faiss

50-500-500

78.98

97.82

0.95

OpenSearch-2.19-faiss

50-750-750

103.20

75.86

0.96

リコール@100

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

詳細な結果 - 再現率 100

タスク

レイテンシ平均

スループット平均

平均再現率

Elasticsearch-9.0-BBQ

100-1000-1000

27.82

243.22

0.95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224.04

0.95

Elasticsearch-9.0-BBQ

100-1500-1500

35.98

193.99

0.95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403.86

0.88

Elasticsearch-9.0-BBQ

100-2000-2000

45.36

159.88

0.95

Elasticsearch-9.0-BBQ

100-250-250

14.77

433.06

0.90

Elasticsearch-9.0-BBQ

100-300-300

14.61

375.54

0.91

Elasticsearch-9.0-BBQ

100-500-500

18.88

340.37

0.93

Elasticsearch-9.0-BBQ

100-750-750

23.59

285.79

0.94

OpenSearch-2.19-faiss

100-1000-1000

142.90

58.48

0.95

OpenSearch-2.19-faiss

100-1200-1200

153.03

51.04

0.95

OpenSearch-2.19-faiss

100-1500-1500

181.79

43.20

0.96

OpenSearch-2.19-faiss

100-200-200

50.94

131.62

0.83

OpenSearch-2.19-faiss

100-2000-2000

232.53

33.67

0.96

OpenSearch-2.19-faiss

100-250-250

57.08

131.23

0.87

OpenSearch-2.19-faiss

100-300-300

62.76

120.10

0.89

OpenSearch-2.19-faiss

100-500-500

84.36

91.54

0.93

OpenSearch-2.19-faiss

100-750-750

111.33

69.95

0.94

バーベキューの改良

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 から得た成果を基にして、ベクター検索が以前よりも高速かつスペース効率が高くなりました。このブログは、その革新のもう一つの例です。

OpenSearchとElasticsearchの違い：ベクトル検索のパフォーマンス比較

Ugo Sangiorgi — Wed, 26 Jun 2024 00:00:00 GMT

まとめ：Elasticsearchは最大12倍高速 - Elasticでは、特にセマンティック検索/ベクトル検索のレルムにおけるElasticsearchとOpenSearch のパフォーマンスの違いを明確にしてほしいというリクエストをコミュニティから多数受けていました。そこで、このパフォーマンステストを実施して、明確でデータに基づく比較を提供しました。曖昧さはなく、ユーザーに伝えるための単純な事実です。結論としては、Elasticsearchはベクトル検索においてOpenSearchより最大12倍高速であるため、必要な計算リソースが少なくなります。これは、ElasticがLuceneを検索および取得ユースケースに最適なベクトルデータベースとして統合することに重点を置いていることを反映しています。

ベクトル検索は、特にAIや機械学習のフィールドで、類似性検索の方法に革命をもたらしています。ベクトル埋め込みモデルの採用が増えるにつれ、何百万もの高次元ベクトルを効率的に検索する機能が重要になっています。

ベクトルデータベースの実現方法に関して、ElasticとOpenSearchは著しく異なるアプローチを採用しています。Elasticは、Apache LuceneとElasticsearchがベクトル検索アプリケーションにおけるトップクラスの選択肢となるべく、これらの最適化に多額の投資を行ってきました。対照的に、OpenSearchは焦点を広げ、他のベクトル検索実装を統合し、Luceneの対象範囲を超えて模索を行っています。Elasticは戦略的にLuceneへと焦点を合わせており、弊社版Elasticsearchにおいて高度に統合されたサポートを提供できるため、各コンポーネントが他のコンポーネントの機能を補完および増幅できるという特徴が強化されています。

このブログでは、Elasticsearch 8.14とOpenSearch 2.14の詳細な比較を、異なる構成とベクトルエンジンを考慮して紹介します。このパフォーマンス分析では、Elasticsearch がベクトル検索操作に優れたプラットフォームであることが証明されました。今後追加予定の機能によりその差はさらに拡大するでしょう。OpenSearchと比較すると、すべてのベンチマークトラックで優れた結果を示し、平均で2倍から12倍高速なパフォーマンスを実現しました。これは、so_vector（2Mベクトル、768D）、openai_vector（2.5Mベクトル、1536D）、およびdense_vector（10Mベクトル、96D）を含む、さまざまなベクトル量と次元を使用したシナリオ全体で行われました。これらはすべて、Google Cloudで必要なインフラストラクチャーをプロビジョニングするためのTerraformスクリプトと、テストを実行するためのKubernetesマニフェストと共に、このリポジトリで利用可能です。

このブログで詳述されている結果は、以前に公開され、サードパーティによって検証された調査の結果を補完するものであり、最も一般的な検索分析操作（テキストクエリ、並べ替え、範囲、日付ヒストグラム、用語フィルタリング）では、ElasticsearchがOpenSearchよりも40%–140%高速であることが示されています。これに、別の差別化要因であるベクトル検索を追加します。

デフォルトの設定で最大12倍高速

4つのベクトルデータセットにわたる重点的なベンチマークには、さまざまなサイズ、次元、構成を考慮した近似KNN検索と正確なKNN検索の両方が含まれ、合計40.189.820のキャッシュされていない検索要求がありました。結果：Elasticsearchはベクトル検索においてOpenSearchより最大12倍高速であるため、必要な計算リソースが少なくなります。

図1：ElasticsearchおよびOpenSearchにおけるさまざまなタスクについて、ANNと厳密なKNNをグループ化した図。

knn-10-100のようなグループは、およびのKNN検索を意味します。HNSWベクトル検索では、はクエリベクトルから取得する最近傍の数を決定します。結果として検索する類似ベクトルの数を指定します。は各セグメントで取得する候補ベクトルの数を設定します。候補の数を増やすと精度は向上しますが、より多くの計算リソースが必要になります。

また、さまざまな量子化手法とエンジン固有の最適化を活用してテストしました。各トラック、タスク、ベクトルエンジンの詳細な結果を以下に示します。

厳密なKNNと近似KNN

さまざまなデータセットとユースケースを扱う場合、ベクトル検索に適したアプローチは異なります。このブログでは、knn-10-100のようにknn-*と記載されているすべてのタスクは近似KNNを使用し、script-score-*は正確なKNNを参照していますが、それらの違いは何で、なぜ重要なのでしょうか。

基本的に、より大規模なデータセットを扱う場合、優れた拡張性のある近似K-最近傍法（ANN）が推奨されます。フィルタリング処理が必要な場合のある、より小規模なデータセットの場合、厳密なKNN法が最適です。

正確なKNNでは、ブルートフォース法を使用して、データセット内の1つのベクトルと他のすべてのベクトルとの間の距離を計算します。次に、これらの距離を順位付けして、の最も近い近傍を見つけます。この方法では正確な一致が保証されますが、大規模で高次元のデータセットでは拡張性の課題があります。ただし、正確なKNNが必要なケースは数多くあります。

再スコアリング：語彙検索または意味検索の後にベクトルベースの再スコアリングを行うシナリオでは、正確なKNNが不可欠です。例えば、製品検索エンジンでは、テキストクエリ（キーワードやカテゴリなど）に基づいて最初の検索結果をフィルタリングし、フィルタリングされたアイテムに関連付けられたベクトルを使用して、より正確な類似性評価を行うことができます。
パーソナライゼーション：多数のユーザーを扱う際、それぞれが比較的少数（100万個など）の個別のベクトルで表される場合、ユーザー固有のメタデータ（例：user_id）でインデックスをソートし、ベクトルを使用したブルートフォーススコアリングが効率的になります。このアプローチにより、個々のユーザーの好みに合わせた正確なベクトル比較に基づいて、パーソナライズされたレコメンデーションやコンテンツ配信が可能になります。

したがって、厳密なKNNでは、ベクトルの類似性に基づく最終的な順位付けと推奨が正確なものとなり、ユーザーの好みに合わせて調整されるようになります。

一方、近似KNN（またはANN）は、特に大規模で高次元のデータセットにおいて、厳密なKNNよりも高速かつ効率的にデータ検索を行う方法を採用しています。ANNは、クエリとすべての点の間の正確な最も近い距離を測定することにより計算やスケーリングの問題につながるブルートフォース的なアプローチではなく、特定の手法を使用してデータセットにおける検索可能なベクトルのインデックスと次元を効率的に再構築します。これにより若干の不正確さが生じる可能性がありますが、検索処理速度が大幅に向上するため、大規模なデータセットを処理するための効果的な代替手段となります。

このブログでは、knn-*として記載されているすべてのタスクはknn-10-100のように近似KNNを使用し、script-score-*は正確なKNNを参照します。

テスト手法

ElasticsearchとOpenSearchはBM25検索操作のAPIにおいては似ていますが、後者が前者のフォークであるため、フォーク後に導入されたベクトル検索には当てはまりません。OpenSearchはアルゴリズムに関してElasticsearchとは異なるアプローチを取り、luceneとは別にnmslibとfaissの2つのエンジンを導入しました。それぞれに特定の構成と制限があります（例：OpenSearchのnmslibでは、多くのユースケースで不可欠な機能であるフィルターが許可されていません）。

3つのエンジンはいずれも、階層型ナビゲート可能スモールワールド（HNSW）アルゴリズムを使用しています。このアルゴリズムは近似最近傍を検索するのに効率的で、特に高次元データを扱う際に強力です。faissは第2のアルゴリズムivfもサポートしていますが、データセットの事前トレーニングが必要なため、ここではHNSWのみに焦点を当てます。HNSWの中心的な考え方は、データを複数の接続されたグラフのレイヤーに整理し、各レイヤーがデータセットの異なる粒度を表すことです。検索は最も粗いビューの最上位レイヤーから始まり、ベースレベルに到達するまで、より細かいレイヤーへと進みます。

公平なテストの場を確保するために、両方の検索エンジンは制御された環境内で同一の条件下でテストされました。適用された方法は、Elasticsearch、OpenSearch、Rally専用のノードプールを使用した以前に公開されたパフォーマンス比較と似ています。terraformスクリプトは（すべてのソースとともに）Kubernetesクラスターを提供するために利用可能です。

Elasticsearch用の3台のe2-standard-32マシン（128GB RAM、32CPU）を持つ1つのNodeプール
OpenSearch用の3台のe2-standard-32マシン（128GB RAM、32CPU）を持つ1つのNodeプール
Rally用の2台のt2a-standard-16マシン（64GB RAM、16CPU）を持つ1つのNodeプール

各「トラック」（またはテスト）を、異なるエンジン、異なる設定、異なるベクトルタイプを含む各設定に対して10回実行しました。各トラックには、トラックにより1000回から10000回まで繰り返すタスクがあります。ネットワークのタイムアウトなどでトラック内のタスクの1つが失敗した場合はすべてのタスクを無視したため、すべての結果は問題なく開始して終了したトラックを表します。すべてのテスト結果は統計的に検証されており、改善が偶然ではないことが保証されています。

詳細な調査結果

平均レイテンシではなく99パーセンタイルを使用して比較するのはなぜでしょうか。特定の地域の平均住宅価格の例を想像してみましょう。平均価格によれば高価な地域となっていても、よく調べてみると、ほとんどの住宅の価値ははるかに低く、わずかな高級物件が平均値を膨らませていることがわかるかもしれません。これは、平均価格がその地域の住宅価値の全範囲を正確に表現できない可能性があることを示しています。同じようなことが、応答時間についても言えます。平均値が重要な問題を隠してしまうことがあるのです。

タスク

近似KNN（k:10 n:50）
近似KNN（k:10 n:100）
近似KNN（k:100 n:1000）
近似KNN（k:10 n:50、キーワードフィルター併用）
近似KNN（k:10 n:100、キーワードフィルター併用）
近似KNN（k:100 n:1000、キーワードフィルター併用）
近似KNN（k:10 n:100、インデックス作成と同時実行）
厳密なKNN（スクリプトスコア）

ベクトルエンジン

lucene （ElasticsearchとOpenSearchにおいて、両方ともバージョン9.10）
faiss （OpenSearchにおいて）
nmslib （OpenSearchにおいて）

ベクトルの種類

hnsw （ElasticsearchとOpenSearchにおいて）
int8_hnsw Elasticsearch内（自動8ビット量子化を備えたHNSW：リンク）
sq_fp16 hnsw OpenSearch内（自動16ビット量子化を備えたHNSW：リンク）

すぐに使える同時セグメント検索

ご存知かと思いますが、LuceneはJavaで記述された高性能なテキスト検索エンジンライブラリであり、Elasticsearch、OpenSearch、Solrなどの多くの検索プラットフォームのバックボーンとして機能します。Luceneは本質的に、データをセグメントに整理します。セグメントは本質的には自己完結型のインデックスであり、Luceneがより効率的に検索を実行できるようにします。そのため、Luceneベースの検索エンジンに検索を発行すると、検索はそれらのセグメントで順次または並行して実行されます。

OpenSearchは同時セグメント検索をオプションのフラグとして導入しましたが、デフォルトでは使用されません。特別なインデックス設定index.search.concurrent_segment_search.enabledを使用して有効にする必要があります。詳細はこちらをご覧ください。ただし、いくつかの制限があります。

一方、Elasticsearchはすぐに使用できる状態でセグメントを同時に検索するため、このブログでの比較では、さまざまなベクトルエンジンとベクトルタイプに加えて、さまざまな構成も考慮に入れます。

Elasticsearch ootb：同時セグメント検索検索を備えたデフォルト設定のElasticsearch
OpenSearch ootb：同時セグメント検索が有効でない状態
OpenSearch css：同時セグメント検索が有効な状態

それでは、テストした各ベクトルデータセットの詳細な結果を見てみましょう。

250万ベクトル、1536次元（openai_vector）

最も単純なトラックで、かつ次元の点でも最大のopenai_vectorから始めます。これは、OpenAIのtext-embedding-ada-002モデルを使用して生成された埋め込みで強化されたNQデータセットを使用します。これは、近似KNNのみをテストし、タスクが5つしかないため、最も単純です。スタンドアロン（インデキシングなし）でのテストと、インデキシングと並行してのテストが可能で、単一クライアントと8つの同時クライアントを使用します。

タスク

standalone-search-knn-10-100-multiple-clients：8クライアントで250万ベクトルを同時に検索、k: 10およびn:100
standalone-search-knn-100-1000-multiple-clients：8クライアントで250万ベクトルを同時に検索、k: 100およびn:1000
standalone-search-knn-10-100-single-client：単一クライアントで250万ベクトルを検索、k: 10およびn:100
standalone-search-knn-100-1000-single-client：単一クライアントで250万ベクトルを検索、k: 100およびn:1000
parallel-documents-indexing-search-knn-10-100：250万ベクトルを検索しながら追加の10万ドキュメントをインデキシング、k:10およびn:100

p99の平均パフォーマンスの概要は次のとおりです。

ここで、 :10、:100でベクトル検索とインデックス作成（つまり読み取り+書き込み）を実行した場合、ElasticsearchはOpenSearchよりも3～8倍高速であり、kとnが同一のインデックス作成なしの場合には2～3倍高速であることがわかりました。:100 および:1000（standalone-search-knn-100-1000-single-clientおよびstandalone-search-knn-100-1000-multiple-clients）の場合、Elasticsearchは平均して OpenSearch より2倍から7倍高速です。

詳細な結果には、比較された具体的なケースとベクトルエンジンが示されています。

リコール

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969485

0.995138

Elasticsearch-8.14.0@lucene-int8_hnsw

0.781445

0.784817

OpenSearch-2.14.0@lucene-hnsw

0.96519

0.995422

OpenSearch-2.14.0@faiss

0.984154

0.98049

OpenSearch-2.14.0@faiss-sq_fp16

0.980012

0.97721

OpenSearch-2.14.0@nmslib

0.982532

0.99832

1,000万ベクトル、96次元（dense_vector）

dense_vectorには、1,000万ベクトルと96次元があります。これはYandex DEEP1B画像データセットに基づいています。データセットは、「sample data」ファイルlearn.350M.fbinの最初の1,000万ベクトルから作成されます。検索操作では、「query data」ファイルクエリのベクトルを使用します。public.10K.fbin。

ElasticsearchとOpenSearchの両方がこのデータセットで非常に優れたパフォーマンスを発揮します。特に、通常読み取り専用のインデックスで実行されるforce mergeの後では顕著です。これは、インデックスをデフラグして検索用の単一の「テーブル」を作成するのと似ています。

タスク

各タスクは100リクエストでウォームアップされ、その後1000リクエストが測定されます。

knn-search-10-100: 1000万ベクトルを検索、k: 10およびn:100
knn-search-100-1000：1000万ベクトルを検索、k: 100およびn:1000
knn-search-10-100-force-merge：強制マージ後の1000万ベクトルの検索、k: 10およびn:100
knn-search-100-1000-force-merge：強制マージ後の1000万ベクトルの検索、k: 100およびn:1000
knn-search-100-1000-concurrent-with-indexing：1000万ベクトルを検索しながらデータセットの5%を更新、k: 100およびn:1000
script-score-query：特定の2000ベクトルの正確なKNN検索。

ElasticsearchとOpenSearchはどちらも近似KNNに対して良好なパフォーマンスを示しました。knn-search-100-1000-force-mergeおよびknn-search-10-100-force-mergeでインデックスが結合されている場合（つまり、セグメントが1つだけの場合）、nmslibおよびfaissを使用すると、いずれも約15ミリ秒で非常に近い値であるにもかかわらず、OpenSearchのパフォーマンスは他よりも優れています。

ただし、インデックスに複数のセグメントがある場合（インデックスがドキュメントの更新を受け取る典型的な状況）において、knn-search-10-100とknn-search-100-1000では、Elasticsearchは遅延を約7ミリ秒と16ミリ秒に保ちますが、他のすべてのOpenSearchエンジンはより遅くなります。

また、インデックスが検索され、同時に書き込まれる場合（knn-search-100-1000-concurrent-with-indexing）、Elasticsearchはレイテンシを15ミリ秒以下に保守し（13.8ミリ秒）、OpenSearchの出荷時（49.3ミリ秒）よりも4倍近く高速であり、同時セグメント検索が有効な場合でも（17.9ミリ秒）、依然として高速ですが、有意差があるほどではありません。

正確なKNNに関しては、その差はさらに大きくなります。Elasticsearch は OpenSearch よりも6 倍高速です（約 260 ミリ秒対約 1600 ミリ秒）。

リコール

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969843

0.996577

Elasticsearch-8.14.0@lucene-int8_hnsw

0.775458

0.840254

OpenSearch-2.14.0@lucene-hnsw

0.971333

0.996747

OpenSearch-2.14.0@faiss

0.9704

0.914755

OpenSearch-2.14.0@faiss-sq_fp16

0.968025

0.913862

OpenSearch-2.14.0@nmslib

0.9674

0.910303

200万ベクトル、768次元（so_vector）

このトラック、so_vector、は2022年4月21日にダウンロードされたStackOverflowの投稿のダンプから派生しています。質問文書のみが含まれており、回答を表す文書はすべて削除されています。各質問タイトルは、文変換モデルmulti-qa-mpnet-base-cos-v1を使用してベクトルにエンコードされました。このデータセットには最初の200万件の質問が含まれています。

前のトラックとは異なり、ここでの各ドキュメントには、フィルタリングとハイブリッド検索を備えた近似KNNなどのテスト機能をサポートするためのベクトル以外のフィールドも含まれています。OpenSearchのnmslibはフィルターをサポートしていないため、このテストには含まれていません。

タスク

各タスクは100件のリクエストに対してウォームアップされ、その後100件のリクエストが測定されます。テストには16種類の検索タイプ*2つの異なるk値*3つの異なるn値が含まれているため、簡潔にするためにタスクがグループ化されていることに注意してください。

knn-10-50：フィルターなしで200万ベクトルを検索、k:10およびn:50
knn-10-50-filtered：200万ベクトルをフィルターを使用して検索、k:10およびn:50
knn-10-50-after-force-merge：200万ベクトルを強制マージ後にフィルターを使用して検索、k:10およびn:50
knn-10-100：フィルターなしで200万ベクトルを検索、k:10およびn:100
knn-10-100-filtered：200万ベクトルをフィルターを使用して検索、k:10およびn:100
knn-10-100-after-force-merge：200万ベクトルを強制マージ後にフィルターを使用して検索、k:10およびn:100
knn-100-1000：フィルターなしで200万ベクトルを検索、k:100およびn:1000
knn-100-1000-filtered：200万ベクトルをフィルターを使用して検索、k:100およびn:1000
knn-100-1000-after-force-merge：200万ベクトルを強制マージ後にフィルターを使用して検索、k:100およびn:1000
exact-knn：フィルターあり、フィルターなしの正確なKNN検索。

このテストでは、ElasticsearchはOpenSearchよりも一貫して高速であり、OpenSearchの方が高速なのは2つのケースのみで、その差はそれほど大きくありません（knn-10-100とknn-100-1000）。knn-10-50、knn-10-100、knn-100-1000をフィルターと組み合わせて使用するタスクでは、最大7倍（112ミリ秒対803ミリ秒）の差が見られます。

当然ながら、knn-10-50-after-force-merge、knn-10-100-after-force-merge、knn-100-1000-after-force-mergeで証明されているように、両方のソリューションのパフォーマンスは「強制マージ」後に均等になるようです。これらのタスクでは、 faissの方が高速です。

Exact KNNのパフォーマンスは今回も大きく異なり、ElasticsearchはOpenSearchより13倍高速です（約385ミリ秒対約5262ミリ秒）。

リコール

knn-recall-10-100

knn-recall-100-1000

knn-recall-10-50

Elasticsearch-8.14.0@lucene-hnsw

Elasticsearch-8.14.0@lucene-int8_hnsw

0.986667

OpenSearch-2.14.0@lucene-hnsw

OpenSearch-2.14.0@faiss

OpenSearch-2.14.0@faiss-sq_fp16

OpenSearch-2.14.0@nmslib

0.9674

0.910303

0.976394

ElasticsearchとLuceneが明確な勝者に

Elasticでは、Apache LuceneとElasticsearchを絶え間なく革新し、RAG（Retrieval-Augmented Generation）を含む検索および取得のユースケースに最適なベクトルデータベースを提供できるようにしています。最近の進歩により、パフォーマンスが大幅に改善され、ベクトル検索が以前よりも高速かつスペース効率的になりました。これはLucene 9.10からの成果を基に構築されています。このブログでは、最新バージョンを比較すると、ElasticsearchがOpenSearchよりも最大12倍高速であることを示す調査を紹介しました。

両方の製品が同じバージョンのLucene（Elasticsearch 8.14リリースノートおよびOpenSearch2.14 リリースノート）を使用していることは注目に値します。

Elasticのイノベーションのペースは、オンプレミスおよびElastic Cloudのお客様だけでなく、ステートレスプラットフォームを使用しているお客様にもさらに多くの成果をもたらします。int4へのスカラー量子化のサポートなどの機能は、int8のテストと同様に、顧客が再現率を大幅に低下させることなくこれらの手法を利用できるように、厳格なテストを経て提供されます。

AIおよび機械学習アプリケーションの急増により、ベクトル検索の効率は現代の検索エンジンでは交渉の余地のない機能になりつつあります。大量で複雑なベクトルデータの要求に対応できる強力な検索エンジンを探している組織にとって、Elasticsearchは決定的な答えです。

確立されたプラットフォームを拡張する場合でも、新しいプロジェクトを開始する場合でも、ベクトル検索のニーズに合わせてElasticsearchを統合することは、具体的かつ長期的なメリットをもたらす戦略的な動きです。実証済みのパフォーマンス上の優位性を備えたElasticsearchは、検索における次のイノベーションの波を支える態勢が整っています。