なぜ複数のグラフを使用するのかと疑問に思うかもしれません。これは、Lucene のアーキテクチャ上の選択である不変セグメントによる副作用です。ほとんどのアーキテクチャ上の選択と同様に、長所と短所があります。たとえば、最近 Serverless Elasticsearch が GA になりました。この文脈において、私たちは不変セグメントから、効率的なインデックス レプリケーションや、インデックスとクエリの計算を分離して個別に自動スケーリングする機能など、非常に大きなメリットを得ています。ベクトル量子化の場合、セグメントのマージにより、パラメータを更新してデータ特性に適合させることができます。これに沿って、データ特性を測定し、インデックスの選択を再検討する機会を持つことで得られる他の利点もあると考えています。

この投稿では、複数の HNSW グラフを構築する際のオーバーヘッドを大幅に削減し、特にグラフのマージにかかるコストを削減するために私たちが行ってきた作業について説明します。

背景

管理可能な数のセグメントを維持するために、Lucene はセグメントをマージする必要があるかどうかを定期的に確認します。これは、現在のセグメント数が、基本セグメント サイズとマージ ポリシーによって決定されるターゲット セグメント数を超えているかどうかを確認することになります。カウントを超過すると、Lucene は制約に違反しながらセグメントのグループを結合します。このプロセスについては他の場所で詳しく説明されています。

Lucene は、書き込み増幅の対数的増加を実現するため、同様のサイズのセグメントを結合することを選択します。ベクトル インデックスの場合、書き込み増幅はベクトルがグラフに挿入される回数です。Luceneはセグメントを約10個のグループにまとめ、マージしようとします。その結果、ベクトルはグラフに約挿入されます。ここで、 はインデックス ベクトル数、 予想される基本セグメント ベクトル数です。対数増加のため、巨大なインデックスの場合でも書き込み増幅は 1 桁になります。ただし、グラフのマージに費やされる合計時間は、書き込み増幅に直線的に比例します。

HNSW グラフをマージする際には、最大セグメントのグラフを保持し、他のセグメントのベクトルをそのグラフに挿入するという、小さな最適化をすでに行っています。これが上記の 9/10 要因の理由です。以下では、マージするすべてのグラフの情報を使用することで、どのように大幅に改善できるかを示します。

HNSW グラフのマージ

これまでは、最大のグラフを保持し、他のグラフからベクトルを挿入し、それらを含むグラフは無視していました。以下で利用する重要な洞察は、破棄する各 HNSW グラフには、それに含まれるベクトルに関する重要な近接情報が含まれているということです。この情報を使用して、少なくとも一部のベクトルの挿入を高速化したいと考えています。

これは任意のマージポリシーを構築するために使用できるアトミック操作であるため、小さなグラフを大きなグラフに挿入する問題に焦点を当てます。

戦略は、 の頂点のサブセットを見つけて、大きなグラフに挿入することです。次に、小さなグラフ内のこれらの頂点の接続性を使用して、残りの頂点の挿入を高速化します。以下では、小さいグラフと大きいグラフの頂点 の隣接点をそれぞれ と で表します。図式的にプロセスは次のとおりです。

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

以下で説明する手順 (1 行目) を使用して、セットを計算します。次に、標準の HNSW 挿入手順 (2 行目) を使用して、 内のすべての頂点を大きなグラフに挿入します。挿入していない各頂点については、挿入した隣接頂点と、大きなグラフ内でのその隣接頂点を見つけます (4 行目と 5 行目)。このセットでシードされたFAST-SEARCH-LAYER手順 (6 行目) を使用して、HNSW論文からSELECT-NEIGHBORS-HEURISTICの候補を検索します (7 行目)。実際には、 SEARCH-LAYER INSERTメソッド (論文のアルゴリズム 1) の候補セットを見つけるために置き換えていますが、それ以外は変更されていません。最後に、先ほど挿入した頂点を (行 8) に追加します。

これが機能するためには、 内のすべての頂点が内に少なくとも 1 つの隣接頂点を持つ必要があることは明らかです。実際、 内のすべての頂点に対して、 (あるに対して) が最大のレイヤー接続性であることが必要です。実際の HNSW グラフでは、頂点次数がかなり広がっていることがわかります。下の図は、Lucene HNSW グラフの最下層の頂点次数の典型的な累積密度関数を示しています。

に固定値を使用することと、それを頂点次数の関数にすることを検討しました。この2番目の選択肢は、グラフの品質への影響を最小限に抑えながら大幅なスピードアップにつながるため、次の方法を採用しました。

定義により、 | は小さなグラフの頂点の次数に等しいことに注意してください。下限が 2 の場合、次数が 2 未満のすべての頂点が挿入されます。

単純な計算の議論によれば、 慎重に選択すれば、約に直接挿入するだけでよいことがわかります。具体的には、グラフの端の頂点の 1 つをに挿入すると、グラフのエッジに色を付けます。すると、 内に少なくとも 個の 隣接頂点を持つためには、少なくとも 個の 辺を色付けする必要があることがわかります。さらに、我々は

ここで、 小さなグラフ内の平均頂点次数です。J内の各頂点に対して、最大での辺を色付けします。したがって、色付けすると予想されるエッジの総数は最大でとなります。慎重に選択することで、この辺の数に近い色を塗ることができると期待しており、すべての頂点をカバーするには満たす必要がある。

これは、 を意味します。

SEARCH-LAYERが実行時間を支配すると、マージ時間を最大高速化できる可能性があります。書き込み増幅の対数的増加を考慮すると、非常に大きなインデックスの場合でも、通常は 1 つのグラフを構築する場合と比べて構築時間が 2 倍になるだけです。

この戦略のリスクは、グラフの品質が損なわれることです。最初は何も実行しないFAST-SEARCH-LAYERを試しました。これにより、特に単一のセグメントにマージするときに、レイテンシの関数としてのリコールが影響を受ける程度にグラフの品質が低下することがわかりました。次に、グラフの限定的な検索を使用して、さまざまな代替案を検討しました。結局、最も効果的な選択は最も単純なものでした。SEARCH-LAYERを使用しますが、 ef_constructionは低くします。このパラメータ化により、優れた品質のグラフを実現しながらも、マージ時間を平均で 30% 強短縮することができました。

結合セットの計算

適切な結合セットを見つけることは、HNSW グラフ カバー問題として定式化できます。貪欲ヒューリスティックは、最適なグラフカバーを近似するためのシンプルで効果的なヒューリスティックです。私たちが採用するアプローチでは、ゲインが減少する順に頂点を 1 つずつ選択してに追加します。ゲインは次のように定義されます。

ここで、 におけるベクトル の近傍の数を表し、 は 指示関数である。ゲインには、 に追加した頂点の数の変化、つまりが含まれます。これは、カバーされていない頂点を追加することで目標に近づくためです。中央のオレンジ色の頂点のゲイン計算を下の図に示します。

各頂点に対して次の状態を維持します。

1. 古くなっても、

2. そのゲイン 、

3. 内の隣接頂点の数はと表され、

4. タイブレークに使用される範囲 [0,1] 内の乱数。

結合セットを計算するための疑似コードは次のとおりです。

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

まず 1 行目から 5 行目で状態を初期化します。

メイン ループの各反復では、最初に最大ゲイン頂点 (行 8) を抽出し、同点の場合はランダムに決定します。変更を加える前に、頂点のゲインが古くなっているかどうかを確認する必要があります。特に、 に頂点を追加するたびに、他の頂点のゲインに影響を与えます。

1. すべての隣接ノードはに追加の隣接ノードを持つため、ゲインは変化する可能性がある（14行目）

2. いずれかの隣接セルが完全にカバーされている場合、その隣接セルのゲインはすべて変化する可能性があります（14～16行目）

ゲインは遅延方式で再計算されるため、頂点をに挿入する場合にのみ、その頂点のゲインを再計算します (18 ～ 20 行目)。ゲインは常に減少するだけなので、挿入すべき頂点を見逃すことは決してありません。

いつ終了するかを決定するには、 に追加した頂点の合計増加を追跡するだけでよいことに注意してください。さらに、 の場合、少なくとも 1 つの頂点のゲインはゼロではないため、常に進歩します。

成果

私たちは、サポートされている 3 つの距離メトリック (ユークリッド、コサイン、内積) をカバーする 4 つのデータセットで実験を実行しました。

1. quora-E5-small: 522931文書、384次元、コサイン類似度を使用、

2. cohere-wikipedia-v2: 100万文書、768次元、コサイン類似度を使用。

3. 要点: 100万文書、960次元、ユークリッド距離を使用、

4. cohere-wikipedia-v3: 100 万件のドキュメント、1024 次元、最大内積を使用します。

各データセットに対して、2 つの量子化レベルを評価します。

1. int8 – 次元ごとに1バイトの整数を使用し、

2. BBQ – 次元ごとに 1 ビットを使用します。

最後に、各実験について、2 つの検索深度で検索品質を評価し、インデックスを構築した後と、単一のセグメントに強制的にマージした後を調べます。

要約すると、グラフの品質を維持しながら、インデックス作成とマージの速度を一貫して大幅に向上させ、すべてのケースで検索パフォーマンスを実現できます。

実験1: int8量子化

ベースラインから候補、つまり提案された変更までの平均的な高速化は次のとおりです。

インデックス時間の高速化: 1.28

強制マージの高速化: 1.72

これは実行時間の次の内訳に対応する。

完全性のために正確な時間は

索引

マージ

データセット

ベースライン

候補者

構築

候補者

quora-E5-small

112.41秒

81.55秒

113.81秒

70.87秒

ウィキコヒアv2

158.1秒

122.95秒

425.20秒

239.28秒

要旨

141.82秒

119.26秒

536.07秒

279.05秒

ウィキコヒアv3

211.86秒

168.22秒

654.97秒

414.12秒

以下に、複数のセグメントを持つインデックス（すべてのベクトルをインデックスした後のデフォルトのマージ戦略の最終結果）と単一セグメントへの強制マージ後のインデックスの、2 つの検索深度（recall@10 と recall@100）と、単一セグメントへの強制マージ後の、候補（破線）とベースラインを比較したリコール対レイテンシのグラフを示します。曲線が高く、左に寄っているほど良好であり、これは、より低いレイテンシでより高い再現性を意味します。

ご覧のとおり、複数のセグメント インデックスの場合、候補は Cohere v3 データセットの方が優れており、他のすべてのデータセットではわずかに劣りますが、ほぼ同等です。単一セグメントに統合した後、リコール曲線はすべてのケースでほぼ同じになります。

実験2：BBQ量子化

ベースラインから候補までの平均的な高速化は次のとおりです。

インデックス時間の高速化: 1.33

強制マージの高速化: 1.34

これは実行時間の次の内訳に対応する。

完全性のために正確な時間は

索引

マージ

データセット

ベースライン

候補者

構築

候補者

quora-E5-small

70.71秒

58.25秒

59.38秒

40.15秒

ウィキコヒアv2

203.08秒

142.27秒

107.27秒

85.68秒

要旨

110.35秒

105.52秒

323.66秒

202.2秒

ウィキコヒアv3

313.43秒

190.63秒

165.98秒

159.95秒

複数のセグメント インデックスの場合、ベースラインがわずかに優れている cohere v2 を除き、ほぼすべてのデータセットで候補の方が優れています。単一セグメントインデックスの場合、リコール曲線はすべてのケースでほぼ同じです。

まとめ

このブログで説明したアルゴリズムは、今後リリースされる Lucene 10.2 およびそれに基づく Elasticsearch リリースで利用できるようになります。ユーザーは、これらの新しいバージョンで改善されたマージ パフォーマンスと短縮されたインデックス構築時間を活用できるようになります。この変更は、Lucene と Elasticsearch をベクター検索とハイブリッド検索に高速かつ効率的にするための継続的な取り組みの一環です。

検索関連性評価におけるBEIRベンチマークの理解

あらゆるシステムを改善するには、それがどの程度うまく機能しているかを測定できる必要があります。検索の観点では、BEIR（またはMTEBリーダーボードの検索セクションに相当するもの）が情報検索コミュニティの「聖杯」と考えられており、それ自体は驚くことではありません。これは、さまざまなタスクにわたる多様なデータセットを備えた、非常によく構造化されたベンチマークです。具体的には、以下の領域が対象となります。

• 引数取得（ArguAna、Touche2020）

• オープンドメインQA（HotpotQA、Natural Questions、FiQA）

• パッセージ検索（MSMARCO）

• 重複質問取得（Quora、CQADupstack）

• ファクトチェック（FEVER、Climate-FEVER、Scifact）

• バイオメディカル情報検索（TREC-COVID、NFCorpus、BioASQ）

• エンティティ検索（DBPedia）

• 引用予測（SCIDOCS）

これは、システムが返す上位結果の中で、各タスク例で最も関連性の高いドキュメントをシステムがどの程度一致させたかに関する単一の統計であるnDCG@10を提供します。人間が操作する検索システムでは、上位結果の関連性が非常に重要です。しかし、検索の評価には多くのニュアンスがあり、単一の要約統計では見逃してしまうものがあります。

BEIRデータセットの構造

各ベンチマークには3つのアーティファクトがあります。

• 取得すべきコーパスや文書

• クエリ

• クエリの関連性判断（別名 qrels）

関連性判定は、ゼロ以上のスコアとして提供されます。0以外のスコアは、ドキュメントがクエリに多少関連していることを示します。

データセット

コーパスのサイズ

テストセット内のクエリ数

肯定的にラベル付けされた#qrels

ゼロに等しい#qrels

コーパス内の#duplicates

Arguana

8,674

1,406

1,406

0

96

Climate-FEVER

5,416,593

1,535

4,681

0

0

DBPedia

4,635,922

400

15,286

28,229

0

FEVER

5,416,568

6,666

7,937

0

0

FiQA-2018

57,638

648

1,706

0

0

HotpotQA

5,233,329

7,405

14,810

0

0

Natural Questions

2,681,468

3,452

4,021

0

16,781

NFCorpus

3,633

323

12,334

0

80

Quora

522,931

10,000

15,675

0

1,092

SCIDOCS

25,657

1,000

4,928

25,000

2

Scifact

5,183

300

339

0

0

Touche2020

382,545

49

932

1,982

5,357

TREC-COVID

171,332

50

24,763

41,663

0

MSMARCO

8,841,823

6,980

7,437

0

324

CQADupstack (sum)

457,199

13,145

23,703

0

0

表1：データセットの統計。数値はデータセットのテスト部分（ MSMARCOの場合はdev ）で計算されました。

表1は、BEIRベンチマークを構成するデータセットの統計を示しています。これには、コーパス内のドキュメント数、テストデータセット内のクエリ数、qrelsファイル内の正/負（クエリ、ドキュメント）ペアの数などが含まれます。データをざっと見てみると、すぐに次のことが推測できます。

• ほとんどのデータセットには、qrelsファイル内に負の関係、つまりゼロスコアが含まれていません。これは、ドキュメントが与えられたクエリに対して明確に無関係であることを示します。

• クエリごとの平均ドキュメント関係数（#qrels/#queries）は、ArguAnaの場合1.0からTREC-COVIDの493.5まで変化しますが、大部分のケースでは値が<5です。

• 一部のデータセットでは、コーパス内に重複したドキュメントが存在するため、ドキュメントがクエリに関連していると見なされても、その重複は関連していないなど、誤った評価につながる場合があります。例えば、ArguAnaでは、クエリに関連するとマークされたドキュメントが1つしかない、重複したドキュメントペアを96件確認しました。重複も含め初期qrelsリストを「拡張」することで、 nDCG@10スコアが平均で約1%相対的に増加することが観測されました。

ArguAnaの重複ペアの例。qrelsファイルでは、（反論として）最初のものだけがクエリ「test-economy-epiasghbf-pro02a」に関連しているようです。

MTEBリーダーボード上のモデルを比較する場合、平均的な検索品質に焦点を当てたくなることがあります。これはモデル全体の品質を示す良い指標ですが、必ずしもモデルのパフォーマンスを正確に示すわけではありません。結果はデータセットごとに報告されるため、異なるデータセットが検索タスクとどれほど密接に関連しているかを理解し、最も関連性の高いものだけを使用してモデルを再スコアリングする価値があります。さらに深く掘り下げたい場合は、さまざまなデータセットコーパスとのトピックの重複を追加で確認することもできます。品質基準をトピック別に階層化することで、トピックごとの長所と短所をより細かく評価できます。

ここで重要な注意点は、ドキュメントがqrelsファイル内でマークされていない場合、デフォルトではクエリとは無関係であると見なされることです。この領域をさらに掘り下げ、「評価者が（クエリ、ドキュメント）ペアに対して、グラウンドトゥルース情報がない場合、どれくらいの頻度で提示されるか？」という問いに光を当てるための証拠を収集します。これが重要な理由は、浅いマークアップしか利用できない（したがって、すべての関連文書がそのようなラベル付けされているわけではない）場合、1つの情報検索システムが、異なる関連（しかしマークされていない）ドキュメントを単に「選択」して表面化させるため、別のシステムよりも劣っていると判断される可能性があるためです。これは高品質の評価セットを作成する際によくある時限爆弾で、特に大規模なデータセットの場合に顕著です。手動でのラベル付けは、通常、現在のシステムによって返される上位の結果に重点を置くため、盲点にある関連ドキュメントを見逃す可能性があります。したがって、通常は、より広範囲な浅いマークアップよりも、より少ないクエリのより完全なマークアップにより多くのリソースを集中させることが好ましいです。

検索関連性評価におけるBEIRベンチマークの活用

分析を開始するために、次のシナリオを実装します（ノートブックを参照）。

1. まず、各データセットのコーパスをElasticsearchインデックスにロードします。

2. テストセットの各クエリについて、BM25の上位100件の文書を取得します。

3. 取得したドキュメントを、さまざまなSOTA再ランク付けモデルを使用して再ランク付けします。

4. 最後に、ステップ2（取得後）とステップ3（リランキング後）の上位10件のドキュメントの「判定率」をレポートします。つまり、qrelsファイルにスコアがある上位ドキュメント10件の平均割合を算出します。

使用したモデルのリランキングのリストは次のとおりです。

• Cohereのrerank-english-v2.0と rerank-english-v3.0

• BGEベース

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

検索

リランキング

データセット

BM25 (%)

Cohere Rerank v2 (%)

Cohereリランク v3(%)

BGEベース (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7.54

4.87

7.87

4.52

4.53

6.84

Climate-FEVER

5.75

6.24

8.15

9.36

7.79

7.58

DBPedia

61.18

60.78

64.15

63.9

63.5

67.62

FEVER

8.89

9.97

10.08

10.19

9.88

9.88

FiQa-2018

7.02

11.02

10.77

8.43

9.1

9.44

HotpotQA

12.59

14.5

14.76

15.1

14.02

14.42

Natural Questions

5.94

8.84

8.71

8.37

8.14

8.34

NFCorpus

31.67

32.9

33.91

30.63

32.77

32.45

Quora

12.2

10.46

13.04

11.26

12.58

12.78

SCIDOCS

8.62

9.41

9.71

8.04

8.79

8.52

Scifact

9.07

9.57

9.77

9.3

9.1

9.17

Touche2020

38.78

30.41

32.24

33.06

37.96

33.67

TREC-COVID

92.4

98.4

98.2

93.8

99.6

97.4

MSMARCO

3.97

6.00

6.03

6.07

5.47

6.11

CQADupstack (avg.)

5.47

6.32

6.87

5.89

6.22

6.16

表 2：上位10件の取得/リランキングされたドキュメントに基づいて計算された（データセット、リランカー）ペアごとの判定率

表2から、TREC-COVID （カバレッジ90%超）、DBPedia （～65% ）、Touche2020 、nfcorpus （～35% ）を除き、大半のデータセットの検索後またはリランキング付け後のラベリング率は5%から10%を少し超える程度であることがわかります。これは、マークされていないドキュメントがすべて関連性があるという意味ではありませんが、それらのサブセット（特に上位に配置されたもの）が正である可能性があります。

汎用命令調整言語モデルの登場により、関連性の判断を自動化できる可能性のある強力な新しいツールが生まれました。これらの方法は通常、検索のためにオンラインで使用するには計算コストがかかりすぎますが、ここではオフライン評価に焦点を当てます。以下では、これらを使用して、BEIRデータセットの一部が浅いマークアップに悩まされているという証拠を調査します。

この仮説をさらに調査するために、MSMARCOに焦点を当て、100件のクエリのサブセットと、（Cohere v2で）リランキングされた上位5つのドキュメントのうち、現在関連性があるとマークされていないものを選択することにしました。私たちは 2 つの異なる評価方法を採用しました。まず、慎重に調整されたプロンプト（これについては後の投稿で詳説します）を使用して、最近リリースされたPhi-3-mini-4kモデルを準備し、クエリに対するドキュメントの関連性（または関連性の欠如）を予測しました。並行して、これらのケースは手動でラベル付けされ、LLMの出力と人間の判断との一致率も評価されました。全体として、以下の2つの結論が導き出されます。

• LLMの応答と人間の判断の間の一致率は約80％で、その方向性において十分な出発点であるように思われます。

• 57.6％のケース（人間の判断に基づく）で、返されたドキュメントが実際にクエリに関連していることが判明しました。言い換えれば、100件のクエリに対して107件のドキュメントに関連性があると判断されましたが、少なくとも0.576 x 5 x 100 = 288の追加のドキュメントが実際には関連しています！

以下は、MSMARCO/dev データセットから抽出された、クエリ、注釈付きの正のドキュメント（qrelsから）、不完全なマークアップによる偽陰性のドキュメントを含む例です。

例1：

例2：

このような特定のクエリを手動で評価することは、nDCG@10のような定量的尺度を補完する検索品質を理解する上で一般的に役立つ手法です。検索に変更を加えるときに常に実行する代表的なクエリのセットがあれば、統計には表示されない、パフォーマンスの変化に関する重要な定性情報が得られます。例えば、検索で返される誤った結果についてより深い洞察を得ることができます。取得した結果の中で明らかな誤りを特定したり、ドメイン固有の用語の誤解釈などの関連する誤りのクラスを特定したりすることができます。

私たちの結果は、 MSMARCO評価に関する関連研究と一致しています。例えば、Arabzadehらは同様の手順を踏んでおり、クラウドソーシングされたワーカーに選好判定を行わせています。特に、彼らは、多くの場合、リランキングモジュールによって返されたドキュメントがMSMARCO qrelsファイル内のドキュメントよりも選好されるということを示しています。もう一つの証拠は、RocketQAリランカーの著者らによるもので、リランキングされたドキュメントの70％以上が手動検査後に関連性があると判断されたと報告しています。

更新 - 9月9日：データセットの慎重な再評価の結果、関連ドキュメントの事例が15件追加で特定され、合計数は273件から288件に増加しました。

主なポイントと次のステップ

• ベンチマークやモデルの比較にとって、より優れたグラウンドトゥルースの追求は極めて重要であるため、終わりがありません。LLMは、慎重に使用し、適切な指示に従って調整すれば、いくつかの評価領域で役立つ可能性があります。

• より一般的には、ベンチマークが完璧になることは決してないことを考えると、純粋なスコアの比較から、統計的に有意な差異を捕捉するより堅牢な手法に切り替えることが望ましいかもしれません。Arabzadehらの研究はこのことを示す良い例であり、彼らは調査結果に基づいて、さまざまな実行間での有意な差（または有意でない差）を示す95%信頼区間を構築しています。付属のノートブックでは、ブートストラッピングを使用した信頼区間の実装を提供しています。

• エンドユーザーの視点からは、ベンチマークの結果を読む際にタスクの整合性を考えることが有用です。例えば、RAGパイプラインを構築し、最も一般的なユースケースがさまざまなソースから複数の情報を集めることであると知っているAIエンジニアにとっては、BEIRベンチマーク全体のグローバル平均ではなく、HotpotQAのようなマルチホップQAデータセットで検索モデルのパフォーマンスを評価する方が有意義です。

次のブログ記事では、LLMとしてのPhi-3の使用と、関連性を予測するようにチューニングする過程をさらに詳しく説明します。