Sachin Frayne - Elasticsearch Labs

Elasticsearchのベクトル検索はOpenSearchの最大8倍高速

Sachin Frayne — Wed, 25 Feb 2026 00:00:00 GMT

AIエージェントとコンテキストエンジニアリングにおいて検索速度が重要な理由

2,000万件の文書コーパスを用いたベンチマークテストの結果、Elasticsearchはフィルタリングされたベクトル検索においてOpenSearchよりも最大8倍高いスループットを実現し、テストしたすべての構成においてより高いRecall@100を達成しました。コンテキストエンジニアリングに必要な要素は高速ベクトル取得だけではありません。ワークフローの反復につれて、チームはハイブリッド検索やフィルタリングなどの強力な関連性制御、操作の簡便性、予測可能なパフォーマンスも必要とするようになります。しかし、エージェントはリクエストごとに取得、推論、取得のループを何度も実行することが多いため、取得の遅延が乗数効果となり、ここでの改善はエンドツーエンドの応答性の向上とコスト削減に直接つながります。

コンテキストエンジニアリングにおいて、取得は一度きりのステップではありません。エージェントとアプリケーションは、クエリを洗練させ、事実を検証し、根拠に基づいたコンテキストを構築し、タスクを完了するために、取得 → 推論 → 取得といったループを繰り返し実行します。このパターンは、エージェント型ワークフローや反復型検索拡張生成（RAG）においてよく見られます。検索はユーザーリクエストごとに何度も呼び出される可能性があるため、応答に遅延が生じ、インフラコストが増加します。

ベクトル検索のパフォーマンスが重要な理由

「15インチのノートパソコンが入る、防水性があり、金曜日までに届く60ドル以下の機内持ち込み用バックパックが必要です」という質問に、店員が答える場面を想像してみてください。

実際の運用環境では、アシスタントがベクトルクエリを1回発行して停止することはほとんどありません。適切なコンテキストを構築するために検索ループを実行し、各ステップは通常、在庫状況、地域、出荷約束、ブランドルール、ポリシー適格性などのフィルターによって制約されます。

ステップ1：意図を解釈し、制約に変換する。

エージェントはリクエストを構造化されたフィルタとセマンティッククエリに変換します。例えば、次のようなものです。

フィルター：在庫あり、ユーザーの郵便番号に配達可能、金曜日までに配達、価格60ドル未満、有効な出品
ベクトルクエリ：「機内持ち込み用バックパック 15インチノートパソコン対応防水」

ステップ2：候補を取得し、絞り込む。

適切な一致を見逃さないように、しばしばバリエーションを加えて検索を繰り返します。

「旅行用バックパック機内持ち込み可能ノートパソコン用スリーブ」
「防水通勤用バックパック 15インチ」
「軽量機内リュック」

各クエリは同じ適格性フィルターを使用します。なぜなら、無関係な項目や利用できない項目を取得することは、コンテキストの無駄になるからです。

ステップ3：詳細を確認し、リスクを軽減するために展開する。

エージェントは、最終的な回答に影響を与える主要な属性を再度確認するために取得を行います。

素材と耐水性に関する記述
寸法とノートパソコン収納部の適合性
返品ポリシーや保証の制約
在庫が少ない場合の代替オプション

これは、取得、推論、取得、組み立てという複数段階のコンテキストエンジニアリングです。

コンテキストエンジニアリングにおいてレイテンシと再現率が重要な理由

これらのやり取りには、ユーザーセッションごとに数十回のフィルタリングされたデータ取得呼び出しが含まれる場合があります。それにより、呼び出しごとのレイテンシがエンドツーエンドの応答時間に直接的な乗数となり、低い再現率は追加の再試行を強制したり、エージェントが対象アイテムを見逃す原因となり、回答の質を低下させます。

要点：コンテキストエンジニアリングされたシステムでは、フィルタリングされた近似最近傍法（ANN）は単一のルックアップではありません。これは制約下での反復処理であるため、大規模言語モデル（LLM）が最も目立つ要素である場合でも、ベクトル検索のパフォーマンスはレイテンシ、スループット、コストにすぐに現れます。

ベンチマーク

成果

グラフ2では、各点が1つのテスト構成を表しています。最も良い結果は左上に表示され、これは低いレイテンシで高い再現率が得られることを意味します。Elasticsearchの結果はOpenSearchよりも常に左上に近く、同じワークロード設定下でより優れた速度と精度を示しています。

いくつかの重要な洞察

s_n_r_value: size_numCandidates_rescoreOversampleの省略形（これらのテストではkとnumCandidatesはnumCandidatesと等しく設定されます）。例えば、 100_500_1 size=100、numCandidates=500、k=500、再スコアオーバーサンプル=1 を意味します。
再現率：その構成における測定Recall@100
平均レイテンシ（ミリ秒）：クエリごとの平均エンドツーエンドレイテンシ
スループット：1秒あたりのクエリ数
再現率（％）：ElasticsearchとOpenSearchの相対的な再現率向上率（Elasticsearch - OpenSearch）/OpenSearch
レイテンシXs：OpenSearchの平均レイテンシをElasticsearchの平均レイテンシで割った値
スループットX：Elasticsearchのスループットをオープンサーチのスループットで割った値

エンジン

`s_n_r_value`

リコール

平均レイテンシ（ミリ秒）

スループット

再現率（％）

レイテンシ Xs

スループット Xs

Elasticsearch

100_250_1

0.7704

534.75

9.70％

2.28

1.91

OpenSearch

100_250_1

0.7023

57.08

279.58

Elasticsearch

100_500_1

0.8577

25.42

524.14

7.20%

2.4

OpenSearch

100_500_1

0.8001

60.9

262.12

Elasticsearch

100_750_1

0.8947

29.67

528.09

5.72％

2.25

2.21

OpenSearch

100_750_1

0.8463

66.76

239.11

Elasticsearch

100_1000_1

0.9156

29.65

534.5

4.66％

2.46

2.44

OpenSearch

100_1000_1

0.8748

72.88

219.01

Elasticsearch

100_1500_1

0.9386

31.84

497.3

3.38％

2.71

2.68

OpenSearch

100_1500_1

0.9079

86.16

185.4

Elasticsearch

100_2000_1

0.9507

34.69

457.2

2.57%

2.98

2.96

OpenSearch

100_2000_1

0.9269

103.36

154.55

Elasticsearch

100_2500_1

0.9582

37.9

418.43

1.99％

3.28

3.26

OpenSearch

100_2500_1

0.9395

124.29

128.53

Elasticsearch

100_3000_1

0.9636

41.86

379.4

1.62％

3.46

3.44

OpenSearch

100_3000_1

0.9482

144.67

110.34

Elasticsearch

100_4000_1

0.9705

50.28

316.21

1.06%

3.87

3.85

OpenSearch

100_4000_1

0.9603

194.36

82.22

Elasticsearch

100_5000_1

0.9749

58.77

270.91

0.73%

4.43

4.41

OpenSearch

100_5000_1

0.9678

260.33

61.38

Elasticsearch

100_6000_1

0.9781

66.75

238.59

0.52%

4.91

4.89

OpenSearch

100_6000_1

0.973

327.44

48.81

Elasticsearch

100_7000_1

0.9804

74.64

213.49

0.38％

5.28

5.27

OpenSearch

100_7000_1

0.9767

394.24

40.53

Elasticsearch

100_8000_1

0.9823

82.28

193.59

0.27％

6.86

6.83

OpenSearch

100_8000_1

0.9797

564.14

28.33

Elasticsearch

100_9000_1

0.9837

90.08

176.96

0.16%

7.63

7.61

OpenSearch

100_9000_1

0.9821

687.25

23.25

Elasticsearch

100_10000_1

0.9848

97.64

163.31

0.08%

8.38

8.36

OpenSearch

100_10000_1

0.984

818.64

19.53

例えば、100_9000_1では、OpenSearchの平均取得時間687ミリ秒に対してElasticsearchは90ミリ秒であり、10ステップの取得ループでは約10×(687-90)=6秒の追加待機時間となります。

全ての結果をご覧ください。

調査手法

Pythonを使ってクエリを送信し、対応タイミングやその他の統計を追跡し、以下のクエリをエンジンに送信しました。ベクター検索エンジンのパフォーマンスは、そのコアパラメータ（考慮する候補の数、再スコアリングの積極性、返されるコンテキストの量など）をどのように調整するかによって決まることを覚えておいてください。これらの設定は、再現率（正解を見つける可能性）とレイテンシ（結果を得るまでの速さ）の両方に直接影響します。

ベンチマークでは、エージェント検索ループで通常調整するのと同じ候補、再スコア、結果サイズの設定を使用し、そのワークロード下でElasticsearchがどのように機能するかを測定しました。その後、同じ設定でOpenSearchをリファレンスとして実行しました。

OpenSearch

GET /_search { "query": { "knn": { "": { "vector": [...], "k": , "method_parameters": { "ef_search": }, "rescore": { "oversample_factor": }, "filter": { } } } }, "size": , "_source": { "excludes": [ "" ] } }

"size": : クライアントに返されたヒット数。このベンチマークでは、Recall@100を計算するために、結果のサイズは100です。
"k": : 最近傍候補の数。
"ef_search": : 検査するベクトルの数。
"oversample_factor": : 再スコアリングを行う前に取得される候補ベクトルの数。

Elasticsearch

GET /_search { "query": { "knn": { "field": "", "query_vector": [...], "k": , "num_candidates": , "rescore_vector": { "oversample": }, "filter": { } } }, "size": , "_source": { "excludes": [ "" ] } }

"size": : クライアントに返されたヒット数。このベンチマークでは、Recall@100を計算するために、結果のサイズは100です。
"k": : 各シャードから返す最近傍の数。
"num_candidates": : knn検索を実行する際にシャードごとに考慮する最近傍候補の数。
"oversample": : 再スコアリングを行う前に取得される候補ベクトルの数。

例

Knn クエリ（ 100_500_1 ）は次のようになります。

OpenSearch

GET search_catalog_128/_search { "query": { "knn": { "search_catalog_embedding": { "vector": [...], "k": 500, "method_parameters": { "ef_search": 500 }, "rescore": { "oversample_factor": 1 }, "filter": { "term": { "valid": true } } } } }, "size": 100, "_source": { "excludes": [ "search_catalog_embedding" ] } }

Elasticsearch

GET search_catalog_128/_search { "query": { "knn": { "field": "search_catalog_embedding", "query_vector": [...], "k": 500, "num_candidates": 500, "rescore_vector": { "oversample": 1 }, "filter": { "term": { "valid": true } } } }, "size": 100, "_source": { "excludes": [ "search_catalog_embedding" ] } }

Terraformスクリプト、Kubernetesマニフェスト、ベンチマークコードとともに、完全な構成はこのリポジトリのes-9.3-vs-os-3.5-vector-searchフォルダで入手可能です。

クラスターの設定

私たちは、16 vCPUと64 GB RAMを備えた6台のe2-standard-16クラウドサーバーでテストを実行しました。各サーバーにおいて、検索エンジンノードを実行する各Kubernetesポッドに15個のvCPUと56GBのRAMを割り当て、そのうち28GBをJVMヒープ用に確保しました。

クラスターはElasticsearch 9.3.0とOpenSearch 3.5.0（Lucene 10.3.2）で実行しました。このベンチマークでは両方のシステムが同じLuceneバージョンを使用しているため、観測されたスループットとレイテンシの違いはLucene単独に起因するものではなく、各エンジンがフィルタリングされたk近傍法（kNN）による検索と再スコアリングをどのように統合し実行するかの違いを反映します。私たちは、3つのプライマリシャードと1つのレプリカ（合計6つのシャード、ノードごとに1つ）を持つ単一のインデックスを使用しました。

我々はまた、同じリージョン内の別のサーバーを使用してベンチマーククライアントを実行し、タイミング統計を収集しました。

データセット

このベンチマークでは、2,000万件のドキュメントを含む大規模なeコマーススタイルのカタログ埋め込みデータセットを使用しました。これは、実世界のフィルタリングされたベクトル検索を大規模なスケールで反映するように設計されています。

各ドキュメントはカタログ項目を表し、以下を含みます。

近似kNN検索に使用される128次元の密なベクトル埋め込み。
構造化されたメタデータフィールドを使用してフィルタリング（例：アイテムの有効性と可用性、およびその他のカタログ制約）を行うことで、適格なサブセット内でのみ最近傍を取得するという一般的な本番パターンを可能にします。

このデータセットを選んだ理由は、本番環境におけるエージェント型システムやRAG型システムで見られる主要なパフォーマンス上の課題を捉えているからです。つまり、ベクトル類似性だけでは不十分であり、検索はフィルタによって制約されることが多く、システムはこれらの制約の下で高い再現率を維持しながらレイテンシを低く抑える必要があるということです。より小規模なQAスタイルのデータセットと比較すると、2000万件の文書コーパスは、フィルタリングされたANNシステムが実際に直面する規模と候補数によるプレッシャーをより適切に反映しています。

まとめ

現代のAIアーキテクチャー、特にコンテキストエンジニアリングを中心としたアーキテクチャーにおいては、ベクトル探索の速度は些細な実装上の問題ではなく、乗数です。エージェントとワークフローが取得 → 推論 → 取得を繰り返す際、検索パフォーマンスはエンドツーエンドのレイテンシ、スループット、モデルに供給されるコンテキストの品質を直接形作ります。

当社のベンチマークでは、Elasticsearchは、OpenSearchと比べて、より低いレイテンシで一貫して高い再現率を達成しました。これは、類似ベクトルの取得だけでなく、正確性が「適切なドキュメントを取得できること」に左右されるシナリオで顕著でした。制御されたデータセットではその差は明確であり、本番環境では、大量の検索呼び出しを通じてそれらの利点が蓄積され、応答性が向上し、容量余裕が増加し、インフラストラクチャーコストが削減されます。

参考資料

ユースケースにBetter Binary Quantization (BBQ)を実装する方法

Sachin Frayne,Jessica Garson — Wed, 23 Apr 2025 00:00:00 GMT

ベクトル検索は、テキストのセマンティック検索や、画像、ビデオ、オーディオの類似性検索を実装する際の基盤を提供します。ベクトル検索では、ベクトルはデータの数学的表現であり、そのサイズは膨大で、場合によっては遅くなることがあります。Better Binary Quantization (以下、BBQ と呼びます) は、ベクトルの圧縮方法として機能します。これにより、ベクトルを縮小して検索と処理を高速化しながら、適切な一致を見つけることができます。この記事では、BBQ と、ベクトルを自動的に再スコアリングする量子化インデックスにのみ使用可能なフィールドである rescore_vector について説明します。

この記事で説明したすべての完全なクエリと出力は、Elasticsearch Labs コードリポジトリで確認できます。

ユースケースで Better Binary Quantization (BBQ) を実装する理由は何ですか?

注: BBQ の背後にある数学の仕組みを詳しく理解するには、以下の「さらに学ぶ」セクションをご覧ください。このブログでは、実装に重点を置いています。

数学は興味深いものですが、ベクトル検索がなぜ正確であり続けるのかを完全に理解したい場合には重要です。結局のところ、現在のベクトル検索アルゴリズムではデータの読み取り速度によって制限されることが判明しているため、これはすべて圧縮に関することです。したがって、そのデータすべてをメモリに収めることができれば、ストレージから読み取る場合と比べて速度が大幅に向上します (メモリは SSD よりも約 200 倍高速です)。

いくつか留意すべき点があります:

HNSW (Hierarchical Navigable Small World) などのグラフベースのインデックスは、ベクター検索では最も高速です。
- HNSW: 効率的な高次元類似性検索を可能にする多層グラフ構造を構築する近似最近傍検索アルゴリズム。

HNSW の速度は、基本的にメモリ、または最悪の場合、ストレージからのデータ読み取り速度によって制限されます。
- 理想的には、保存されているすべてのベクトルをメモリにロードできるようにする必要があります。
埋め込みモデルは通常、浮動小数点数ごとに 4 バイトの float32 精度のベクトルを生成します。
そして最後に、ベクトルや次元の数によっては、すべてのベクトルを保存するためのメモリがすぐに不足する可能性があります。

これを当然のこととして考えると、それぞれが数百、数千の次元を持つ可能性のある数百万、数十億のベクトルを取り込み始めると、すぐに問題が発生することがわかります。「圧縮率のおおよその数値」というセクションでは、おおよその数値が示されています。

始めるには何が必要ですか?

始めるには、次のものが必要です。

Elastic Cloud またはオンプレミスを使用している場合は、Elasticsearch のバージョン 8.18 以降が必要になります。BBQ は 8.16 で導入されましたが、この記事では 8.18 で導入されたvector_rescore使用します。
さらに、クラスター内に機械学習 (ML) ノードがあることも確認する必要があります。(注: モデルをロードするには最低 4 GB の ML ノードが必要ですが、完全な本番環境のワークロードには、はるかに大きなノードが必要になる可能性があります。)
Serverless を使用している場合は、ベクターに最適化されたインスタンスを選択する必要があります。
また、ベクターデータベースに関する基本的な知識も必要になります。Elastic のベクトル検索の概念にまだ慣れていない場合は、まず次のリソースを確認することをお勧めします。
- 弾性ベクトルデータベースのナビゲート
- 検索拡張生成の背後にある大きなアイデア

より良いバイナリ量子化（BBQ）実装

このブログをシンプルに保つために、組み込み関数が利用可能な場合はそれを使用します。この場合、機械学習ノード上の Elasticsearch 内で直接実行される.multilingual-e5-smallベクトル埋め込みモデルがあります。text_embeddingモデルを、任意の埋め込みツール ( OpenAI 、 Google AI Studio 、 Cohereなど) に置き換えることができることに注意してください。希望するモデルがまだ統合されていない場合は、独自の密なベクトル埋め込みも使用できます。

まず、特定のテキストのベクトルを生成するための推論エンドポイントを作成する必要があります。これらのコマンドはすべて、Kibana Dev Tools コンソールから実行します。このコマンドは.multilingual-e5-smallをダウンロードします。まだ存在しない場合はエンドポイントが設定されます。実行には 1 分ほどかかる場合があります。予想される出力は、Outputs フォルダー内のファイル01-create-an-inference-endpoint-output.jsonで確認できます。

PUT _inference/text_embedding/my_e5_model { "service": "elasticsearch", "service_settings": { "num_threads": 1, "model_id": ".multilingual-e5-small", "adaptive_allocations": { "enabled": true, "min_number_of_allocations": 1 } } }

これが返されると、モデルが設定され、次のコマンドを使用してモデルが期待どおりに動作するかどうかをテストできます。期待される出力は、Outputs フォルダー内のファイル02-embed-text-output.jsonで確認できます。

POST _inference/text_embedding/my_e5_model { "input": "my awesome piece of text" }

トレーニング済みのモデルがどのノードにも割り当てられないという問題が発生した場合は、モデルを手動で起動する必要がある場合があります。

POST _ml/trained_models/.multilingual-e5-small/deployment/_start

ここで、埋め込みモデルからの出力と一致するように、標準テキストフィールド ( my_field ) と 384 次元の密なベクトルフィールド ( my_vector ) の 2 つのプロパティを持つ新しいマッピングを作成しましょう。index_options.type to bbq_hnswもオーバーライドします。予想される出力は、Outputs フォルダー内のファイル03-create-byte-qauntized-index-output.jsonで確認できます。

PUT bbq-my-byte-quantized-index { "mappings": { "properties": { "my_field": { "type": "text" }, "my_vector": { "type": "dense_vector", "dims": 384, "index_options": { "type": "bbq_hnsw" } } } } }

Elasticsearch がベクトルを生成するようにするには、 Ingest Pipelineを利用できます。このパイプラインには、エンドポイント ( model_id )、ベクトルを作成するinput_field 、およびそれらのベクトルを格納するoutput_fieldの 3 つが必要です。以下の最初のコマンドは、内部で推論サービスを使用する推論取り込みパイプラインを作成し、2 番目のコマンドはパイプラインが正しく動作していることをテストします。予想される出力は、Outputs フォルダー内のファイル04-create-and-simulate-ingest-pipeline-output.jsonで確認できます。

PUT _ingest/pipeline/my_inference_pipeline { "processors": [ { "inference": { "model_id": "my_e5_model", "input_output": [ { "input_field": "my_field", "output_field": "my_vector" } ] } } ] } POST _ingest/pipeline/my_inference_pipeline/_simulate { "docs": [ { "_source": { "my_field": "my awesome text field" } } ] }

これで、以下の最初の 2 つのコマンドを使用してドキュメントを追加し、3 番目のコマンドで検索が機能することをテストする準備が整いました。予想される出力は、Outputs フォルダー内のファイル05-bbq-index-output.jsonで確認できます。

PUT bbq-my-byte-quantized-index/_doc/1?pipeline=my_inference_pipeline { "my_field": "my awesome text field" } PUT bbq-my-byte-quantized-index/_doc/2?pipeline=my_inference_pipeline { "my_field": "some other sentence" } GET bbq-my-byte-quantized-index/_search { "query": { "bool": { "must": [ { "knn": { "field": "my_vector", "query_vector_builder": { "text_embedding": { "model_id": "my_e5_model", "model_text": "my awesome search field" } }, "k": 10, "num_candidates": 100 } } ] } }, "_source": [ "my_field" ] }

この投稿で推奨されているように、圧縮の利点を活用しながら高い再現精度を維持するのに役立つため、大量のデータに拡張する場合は、再スコアリングとオーバーサンプリングが推奨されます。Elasticsearch バージョン 8.18 以降では、 rescore_vectorを使用してこの方法で実行できます。予想される出力は、Outputs フォルダー内のファイル06-bbq-search-8-18-output.jsonにあります。

GET bbq-my-byte-quantized-index/_search { "query": { "bool": { "must": [ { "knn": { "field": "my_vector", "query_vector_builder": { "text_embedding": { "model_id": "my_e5_model", "model_text": "my awesome search field" } }, "rescore_vector": { "oversample": 3 }, "k": 10, "num_candidates": 100 } } ] } }, "_source": [ "my_field" ] }

これらのスコアは、生データで得られるスコアと比べてどうでしょうか?上記のすべてをindex_options.type: hnswを使ってもう一度実行すると、スコアが非常に似ていることがわかります。予想される出力は、Outputs フォルダーのファイル07-raw-vector-output.jsonで確認できます。

PUT my-raw-vector-index { "mappings": { "properties": { "my_field": { "type": "text" }, "my_vector": { "type": "dense_vector", "dims": 384, "index_options": { "type": "hnsw" } } } } } PUT my-raw-vector-index/_doc/1?pipeline=my_inference_pipeline { "my_field": "my awesome text field" } PUT my-raw-vector-index/_doc/2?pipeline=my_inference_pipeline { "my_field": "some other sentence" } GET my-raw-vector-index/_search { "query": { "bool": { "must": [ { "knn": { "field": "my_vector", "query_vector_builder": { "text_embedding": { "model_id": "my_e5_model", "model_text": "my awesome search field" } }, "k": 10, "num_candidates": 100 } } ] } }, "_source": [ "my_field" ] }

圧縮比のおおよその数値

ベクトル検索を使用する場合、ストレージとメモリの要件がすぐに大きな課題になる可能性があります。次の内訳は、さまざまな量子化手法によってベクターデータのメモリフットプリントがいかに劇的に削減されるかを示しています。

ベクトル（V）

寸法（D）

生（V x D x 4）

int8 (V x (D x 1 + 4))

int4 (V x (D x 0.5 + 4))

バーベキュー（V×（D×0.125+4））

10,000,000

384

14.31GB

3.61GB

1.83GB

0.58GB

50,000,000

384

71.53GB

18.07GB

9.13GB

2.89GB

1億

384

143.05GB

36.14GB

18.25GB

5.77GB

まとめ

BBQ は、精度を犠牲にすることなくベクターデータを圧縮するために適用できる最適化です。これはベクトルをビットに変換することで機能し、データを効果的に検索できるようにし、AI ワークフローを拡張して検索を高速化し、データストレージを最適化できるようにします。

さらなる学習

バーベキューについてさらに詳しく知りたい場合は、次のリソースをぜひチェックしてください。