ベクトル検索でのフィルタリングの仕組みを理解すると、パフォーマンスとリコールのトレードオフのバランスをとるのに役立ちます。また、フィルタリングの使用時にベクトル検索のパフォーマンスを高めるために使用される最適化のいくつかを知ることもできます。

なぜフィルタリングするのですか?

ベクトル検索は、大規模なデータセット内で関連情報を検索する方法に革命をもたらし、クエリと意味的に類似する項目を発見できるようになりました。

ただし、類似アイテムを見つけるだけでは十分ではありません。多くの場合、特定の基準や属性に基づいて検索結果を絞り込む必要があります。

電子商取引ストアで商品を検索していると想像してください。純粋なベクター検索では視覚的に類似したアイテムが表示される場合がありますが、価格帯、ブランド、在庫状況、または顧客評価でフィルタリングすることもできます。フィルタリングがなければ、類似した製品が大量に表示され、探しているものを正確に見つけることが難しくなります。

フィルタリングにより、検索結果を正確に制御できるようになり、取得された項目が意味的に一致するだけでなく、必要な要件をすべて満たすことが保証されます。これにより、より正確で効率的、そしてユーザーフレンドリーな検索エクスペリエンスが実現します。

Elasticsearch と Apache Lucene が優れているのはこの点です。さまざまなデータ タイプにわたって効果的なフィルタリングを使用することが、他のベクター データベースとの主な違いの 1 つです。

正確なベクトル検索のためのフィルタリング

正確なベクトル検索を実行するには、主に 2 つの方法があります。

• dense_vector フィールドにflatインデックス タイプを使用します。これにより、 knn検索では近似検索ではなく正確な検索が使用されるようになります。

• ベクトル関数を使用してスコアを計算するscript_score クエリを使用します。これはどのインデックス タイプでも使用できます。

正確なベクトル検索を実行すると、すべてのベクトルがクエリと比較されます。このシナリオでは、フィルターを通過するベクトルのみを比較する必要があるため、フィルタリングによってパフォーマンスが向上します。

いずれにしてもすべてのベクトルが考慮されるため、結果の品質には影響しません。興味のない結果を事前にフィルタリングするだけで、操作の数を減らすことができます。

これは非常に重要です。適用したフィルターによって少数のドキュメントが生成される場合、近似検索ではなく正確な検索を実行するとパフォーマンスが向上する可能性があるためです。

経験則としては、フィルターを通過するドキュメントが 10,000 個未満の場合は完全一致検索を使用します。BBQインデックスは比較が非常に高速なので、ベース インデックスが 10 万未満の場合は、完全一致検索を使用するのが合理的です。詳細については、このブログ投稿をご覧ください。

フィルターが常に非常に制限的である場合は、HNSW ベースのインデックス タイプではなくflatインデックス タイプを使用して、近似検索ではなく完全検索に重点を置いたインデックス作成を検討してください。詳細については、 index_options のプロパティを参照してください。

近似ベクトル検索のためのフィルタリング

近似ベクトル検索を実行する場合、結果の精度とパフォーマンスをトレードオフします。HNSW のようなベクトル検索データ構造は、数百万のベクトルのおおよその最近傍を効率的に検索します。計算コストのかかるベクトル比較を最小限に抑えて、最も類似したベクトルを取得することに重点を置いています。

つまり、他のフィルタリング属性はベクター データの一部ではないということです。さまざまなデータ タイプには、用語辞書、投稿リスト、ドキュメント値など、検索やフィルタリングに効率的な独自のインデックス構造があります。

これらのデータ構造はベクトル検索メカニズムとは別であるため、ベクトル検索にフィルタリングをどのように適用すればよいでしょうか?フィルターには、ベクター検索の後にフィルターを適用する (ポストフィルタリング) か、ベクター検索の前にフィルターを適用する (プレフィルタリング) という 2 つのオプションがあります。

それぞれの選択肢には長所と短所があります。詳しく見ていきましょう！

ポストフィルタリング

ポストフィルタリングは、ベクトル検索が完了した後にフィルターを適用します。これは、最も類似した上位 k 個のベクトル結果が見つかった後にフィルターが適用されることを意味します。

明らかに、結果にフィルターを適用した後、 k 件未満の結果が返される可能性があります。もちろん、ベクトル検索 (より高い k 値) からより多くの結果を取得できますが、フィルターを適用した後に k 以上の結果が得られるかどうかはわかりません。

ポストフィルタリングの利点は、ベクトル検索の実行時の動作を変更しないことです。つまり、ベクトル検索はフィルタリングを認識しません。ただし、取得される結果の最終的な数は変わります。

以下は、 knn クエリを使用したポストフィルタリングの例です。フィルタリング句が knn クエリとは別であることを確認します。

post-filterを使用した knn 検索では、ポストフィルタリングも利用できます。

knn 検索では明示的なポストフィルター セクションを使用する必要があることに注意してください。ポストフィルターを使用しない場合、knn 検索はポストフィルターを実行する代わりに、最近傍の結果を他のクエリまたはフィルターと組み合わせます。

プレフィルタリング

ベクトル検索の前にフィルターを適用すると、まずフィルターを満たすドキュメントが取得され、次にその情報がベクトル検索に渡されます。

Lucene はBitSetsを使用して、フィルター条件を満たすドキュメントを効率的に保存します。次に、ベクトル検索は条件を満たすドキュメントを考慮して、HNSW グラフを走査します。候補を結果に追加する前に、それが有効なドキュメントの BitSet に含まれているかどうかを確認します。

ただし、有効なドキュメントでない場合でも、候補を調査してクエリと比較する必要があります。HNSW の有効性は、グラフ内のベクトル間の接続に依存します。つまり、候補の探索を停止すると、その近傍もスキップされる可能性があることを意味します。

ガソリンスタンドに行くために車を運転するのを想像してください。ガソリンスタンドのない道路を無視すると、目的地にたどり着く可能性は低くなります。他の道はあなたにとって必要なものではないかもしれませんが、目的地まであなたを繋いでくれます。HNSW グラフ上のベクトルも同様です。

したがって、プレフィルタリングを適用すると、フィルタを適用しない場合よりもパフォーマンスが低下します。検索で訪れるすべてのベクトルに対して作業を実行し、フィルターに一致しないベクトルを破棄する必要があります。私たちは、トップ k の結果を得るために、より多くの作業とより多くの時間をかけています。

以下は、Elasticsearch クエリ DSL での事前フィルタリングの例です。フィルタリング句が knn セクションの一部になっていることを確認します。

事前フィルタリングは、 knn 検索とknn クエリの両方で利用できます。

プレフィルタリングの最適化

プレフィルタリングのパフォーマンスを確保するために適用できる最適化がいくつかあります。

フィルターの制限が厳しい場合は、完全一致検索に切り替えることができます。比較するベクトルが少ない場合は、フィルターを満たす少数のドキュメントに対して正確な検索を実行する方が高速です。

これは、 Luceneおよび Elasticsearch で自動的に適用される最適化です。

別の最適化方法では、フィルターの条件を満たさないベクトルを無視します。代わりに、このメソッドは、フィルターを通過するフィルター処理されたベクトルの近傍をチェックします。このアプローチでは、フィルタリングされたベクトルは考慮されず、現在のパスに接続されたベクトルの探索が継続されるため、比較の回数が効果的に削減されます。

このアルゴリズムは ACORN-1 であり、そのプロセスについてはこちらのブログ記事で詳しく説明されています。

ドキュメントレベルのセキュリティを使用したフィルタリング

ドキュメント レベル セキュリティ (DLS)は、ユーザー ロールが取得できるドキュメントを指定する Elasticsearch 機能です。

DLS はクエリを使用して実行されます。ロールにはインデックスに関連付けられたクエリを持たせることができ、これにより、そのロールに属するユーザーがインデックスから取得できるドキュメントを効果的に制限できます。

ロール クエリは、それに一致するドキュメントを取得するためのフィルターとして使用され、BitSet としてキャッシュされます。この BitSet は、基盤となる Lucene リーダーをラップするために使用されるため、クエリから返されたドキュメントのみがライブであると見なされます。つまり、それらのドキュメントはインデックス上に存在し、削除されていません。

knn クエリを実行するためにリーダーからライブ ドキュメントが取得されるため、ユーザーが利用できるドキュメントのみが考慮されます。プレフィルターがある場合は、DLS ドキュメントがそれに追加されます。

つまり、DLS フィルタリングは、近似ベクトル検索のプレフィルタとして機能し、同じパフォーマンスへの影響と最適化を実現します。

完全一致検索を使用した DLS には、任意のフィルターを適用する場合と同じ利点があります。つまり、DLS から取得されるドキュメントが少ないほど、完全一致検索のパフォーマンスが向上します。DLS によって返されるドキュメントの数も考慮してください。DLS ロールの制限が非常に厳しい場合は、近似検索ではなく完全検索の使用を検討してください。

ベンチマーク

Elasticsearch では、ベクトル検索フィルタリングが効率的であることを確認したいと考えています。当社には、さまざまなフィルタリングを使用して近似ベクトル検索を実行するベクトル フィルタリング用の特定のベンチマークがあり、ベクトル検索で関連する結果を可能な限り高速に取得し続けることができるようにします。

ACORN-1 が導入されたときの改善点を確認します。ベクトルの 2% のみがフィルターを通過するテストでは、クエリの待機時間は元の期間の 55% に短縮されます。

まとめ

フィルタリングは検索の不可欠な部分です。ベクトル検索でフィルタリングのパフォーマンスを確保し、トレードオフと最適化を理解することが、効率的で正確な検索の成否を左右します。

フィルタリングはベクトル検索のパフォーマンスに影響します。

• フィルタリングを使用すると、正確な検索が高速になります。フィルタリングが十分に制限されている場合は、近似検索ではなく完全検索の使用を検討する必要があります。これは Elasticsearch での自動最適化です。

• 事前フィルタリングを使用すると近似検索が遅くなります。事前フィルタリングを使用すると、検索速度は遅くなりますが、フィルターに一致する上位 k 件の結果を取得できます。

• ポストフィルタリングでは、フィルターの適用時にフィルターによってフィルタリングされる可能性があるため、必ずしも上位 k 件の結果が取得されるわけではありません。

フィルタリングをお楽しみください！

なぜ複数のグラフを使用するのかと疑問に思うかもしれません。これは、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 をベクター検索とハイブリッド検索に高速かつ効率的にするための継続的な取り組みの一環です。

並行性のバグをデバッグするのは簡単ではありませんが、ここで取り上げます。CMU の PASTA ラボによる決定論的同時実行テスト フレームワークである Fray は、不安定な障害を確実に再現可能な障害に変えます。Fray の巧妙なシャドウ ロック設計と正確なスレッド制御のおかげで、私たちは厄介な Lucene のバグを追跡し、ついにそれを撲滅することができました。この投稿では、オープンソースのヒーローとツールが、並行処理のデバッグの負担を軽減し、ソフトウェアの世界を大きく改善している仕組みについて説明します。

並行性バグ：ソフトウェアエンジニアの悩みの種

同時実行バグは最悪です。修正が難しいだけでなく、確実に故障させること自体が最も難しい部分です。このテストの失敗TestIDVersionPostingsFormat#testGlobalVersionsを例に挙げます。これは複数のドキュメント書き込みおよび更新スレッドを生成し、Lucene の楽観的同時実行モデルに挑戦します。このテストでは、楽観的同時実行制御における競合状態が明らかになりました。つまり、ドキュメント操作は、一連の操作の中で最新のものであると誤って主張する可能性があります😱。つまり、特定の状況では、楽観的同時実行制約により失敗するはずの更新または削除操作が実際には成功する可能性があります。

Java スタック トレースが嫌いな方には申し訳ありません。注意: 削除は必ずしも「削除」を意味するわけではありません。Lucene のセグメントは読み取り専用であるため、ドキュメントの「更新」を示すこともできます。

Apache Lucene は、 DocumentsWriterクラスを通じてドキュメントを書き込む各スレッドを管理します。このクラスはドキュメント書き込み用のスレッドを作成または再利用し、各書き込みアクションはDocumentsWriterPerThread (DWPT) クラス内でその情報を制御します。さらに、ライターはDocumentsWriterDeleteQueue (DWDQ) で削除されたドキュメントを追跡します。これらの構造は、すべてのドキュメント変更アクションをメモリ内に保持し、定期的にフラッシュしてメモリ内のリソースを解放し、構造をディスクに保持します。

スレッドのブロックを防ぎ、並行システムでの高いスループットを確保するために、Apache Lucene は非常に重要なセクションのみで同期を試みます。これは実際には良いことですが、他の並行システムと同様に、問題が存在します。

偽りの希望

最初の調査で、適切に同期されていない重要なセクションがいくつか見つかりました。特定のDocumentsWriterDeleteQueueに対するすべてのやり取りは、それを囲むDocumentsWriterによって制御されます。したがって、個々のメソッドはDocumentsWriterDeleteQueue内で適切に同期されない可能性がありますが、そのメソッドの世界へのアクセスは適切に同期されます (または同期される必要があります)。(所有権とアクセスがどのように混乱するかについては深く考えないことにします。これは、多くの貢献者によって書かれた長期にわたるプロジェクトです。少しは余裕を持ってください。

しかし、フラッシュ中に同期されていない場所が 1 か所見つかりました。

これらのアクションは、単一のアトミック操作に同期されません。つまり、 newQueueが作成されてからgetMaxSeqNoが呼び出されるまでの間に、 documentsWriterクラス内のシーケンス番号を増分する他のコードが実行された可能性があります。バグを見つけました!

しかし、ほとんどの複雑なバグと同様に、根本原因を見つけるのは簡単ではありませんでした。その時、英雄が登場した。

戦いの英雄

私たちのヒーロー、PASTA ラボのAo Liと彼の同僚の登場です。フレイでどうやって彼らが危機を救ったのか、彼に説明してもらいましょう。

Fray は、カーネギーメロン大学のPASTA ラボの研究者によって開発された決定論的並行性テスト フレームワークです。Fray 構築の背後にある動機は、学界と業界の間にある顕著なギャップに起因しています。決定論的並行性テストは学術研究において 20 年以上にわたって広範に研究されてきましたが、実践者は並行プログラムをテストするために、信頼性が低く不安定であると広く認識されている方法であるストレス テストに依然頼っています。したがって、私たちは、一般性と実用性を主な目標として、決定論的な同時実行テスト フレームワークを設計および実装したいと考えました。

核となるアイデア

Fray は、本質的に、シンプルでありながら強力な原則である「順次実行」を活用します。Java の並行性モデルは重要な特性を提供します。プログラムにデータ競合がない場合、すべての実行は順次一貫しているように見えます。これは、プログラムの動作を一連のプログラム ステートメントとして表現できることを意味します。

Fray は、ターゲット プログラムを順次実行することで動作します。各ステップで、1 つを除くすべてのスレッドを一時停止し、スレッドのスケジュールを正確に制御できるようにします。同時実行をシミュレートするためにスレッドはランダムに選択されますが、選択内容は後続の確定的な再生のために記録されます。実行を最適化するために、Fray は、スレッドがロックやアトミック/揮発性アクセスなどの同期命令を実行しようとしているときにのみコンテキストスイッチを実行します。データ競合の自由に関する優れた特性は、この限定されたコンテキスト切り替えが、あらゆるスレッドインターリーブによるすべての観察可能な動作を調査するのに十分であるということです (私たちの論文には証明の概要があります)。

課題: スレッドのスケジュール制御

中心となるアイデアはシンプルに見えますが、Fray の実装には大きな課題がありました。スレッドのスケジュールを制御するには、Fray は各アプリケーション スレッドの実行を管理する必要があります。一見すると、同時実行プリミティブをカスタマイズされた実装に置き換えるという単純なことのように思えるかもしれません。ただし、JVM での同時実行制御は複雑であり、バイトコード命令、高レベルライブラリ、ネイティブメソッドが混在します。

これはウサギの穴であることが判明しました:

• たとえば、すべてのMONITORENTER命令には、同じメソッド内に対応するMONITOREXITが必要です。Fray がMONITORENTERスタブ/モックへのメソッド呼び出しに置き換える場合は、 MONITOREXIT置き換える必要があります。

• object.wait/notifyを使用するコードでは、 MONITORENTERが置き換えられる場合、対応するobject.waitも置き換えられる必要があります。この置換チェーンはobject.notify以降まで拡張されます。

• JVM は、ネイティブ コード内で特定の並行性関連のメソッド (たとえば、スレッドが終了するとobject.notify ) を呼び出します。これらの操作を置き換えるには、JVM 自体を変更する必要があります。

• クラス ローダーやガベージ コレクション (GC) スレッドなどの JVM 機能でも、同時実行プリミティブが使用されます。これらのプリミティブを変更すると、JVM 機能との不一致が生じる可能性があります。

• JDK で並行性プリミティブを置き換えると、初期化フェーズで JVM がクラッシュすることがよくあります。

これらの課題により、並行性プリミティブを包括的に置き換えることは不可能であることが明らかになりました。

私たちの解決策：シャドウロック設計

これらの課題に対処するために、Fray は、同時実行プリミティブを置き換えることなくスレッド実行を調整するための新しいシャドウ ロック メカニズムを使用します。シャドウ ロックは、スレッドの実行をガイドする仲介者として機能します。たとえば、ロックを取得する前に、アプリケーション スレッドは対応するシャドウ ロックと対話する必要があります。シャドウ ロックは、スレッドがロックを取得できるかどうかを決定します。スレッドが続行できない場合、シャドウ ロックによってそのスレッドがブロックされ、他のスレッドの実行が許可されるため、デッドロックが回避され、同時実行が制御されます。この設計により、Fray は並行性セマンティクスの正確性を維持しながら、スレッドインターリーブを透過的に制御できます。各同時実行プリミティブは、健全性と完全性を確保するために、シャドウ ロック フレームワーク内で慎重にモデル化されます。より詳しい技術的な詳細については、当社の論文をご覧ください。

さらに、この設計は将来を見据えたものとなっています。同時実行プリミティブの周囲にシャドウ ロックのインストルメンテーションのみを必要とするため、新しいバージョンの JVM との互換性が確保されます。これは、JVM の並行性プリミティブのインターフェースが比較的安定しており、長年にわたって変更されていないため実現可能です。

テストの乱闘

Fray を構築した後、次のステップは評価でした。幸いなことに、Apache Lucene などの多くのアプリケーションには、すでに同時実行テストが含まれています。このような同時実行テストは、複数のスレッドを生成し、何らかの作業を実行し、その後 (通常は) それらのスレッドが終了するまで待機し、何らかのプロパティをアサートする通常の JUnit テストです。ほとんどの場合、これらのテストは 1 つのインターリーブのみを実行するため合格します。さらに悪いことに、前述のように、一部のテストは CI/CD 環境でたまにしか失敗しないため、これらの失敗をデバッグするのは非常に困難です。同じテストを Fray で実行したところ、多数のバグが発見されました。特に、Fray は、このブログの焦点であるTestIDVersionPostingsFormat.testGlobalVersionsを含め、信頼できる再現がないため未修正のまま残っていた、以前に報告されたバグを再発見しました。幸いなことに、Fray を使用すると、それらを確定的に再生して開発者に詳細な情報を提供できるため、問題を確実に再現して修正することができます。

フレイの次のステップ

Elastic の開発者から、Fray が並行性バグのデバッグに役立ったという話を聞き、大変嬉しく思っています。私たちは、より多くの開発者が Fray を利用できるようにするために、引き続き取り組んでいきます。

私たちの短期的な目標には、乱数ジェネレータやobject.hashcodeの使用など、他の非決定論的な操作が存在する場合でも、スケジュールを決定論的に再生する Fray の機能を強化することが含まれます。また、Fray の使いやすさを向上させ、開発者が手動介入なしに既存の同時実行テストを分析およびデバッグできるようにすることを目指しています。最も重要なことは、プログラム内の同時実行の問題のデバッグやテストで課題に直面している場合は、ぜひご連絡ください。遠慮なく、 Fray Github リポジトリに問題を投稿してください。

同時実行バグを修正する時間

Ao Li と PASTA ラボのおかげで、このテストが確実に失敗するインスタンスができました。ついにこの問題を解決できます。重要な問題は、 DocumentsWriterPerThreadPoolスレッドとリソースの再利用をどのように許可するかにありました。

ここでは、世代 0 の初期削除キューを参照して各スレッドが作成されていることがわかります。

その後、フラッシュ時にキューの前進が発生し、キュー内の前の 7 つのアクションが正しく確認されます。

しかし、すべてのスレッドがフラッシュを完了する前に、2 つのスレッドが追加のドキュメントに再利用されます。

これにより、 seqNoはフラッシュ時に7と計算された想定最大値を超えて増加します。セグメント_3とnumDocsInRAMが追加されていることに注意してください。 _0

その結果、Lucene はフラッシュ中のドキュメント アクションのシーケンスを誤って考慮し、このテストの失敗が発生します。

すべての適切なバグ修正と同様に、実際の修正は約10 行のコードです。しかし、実際に理解するまでに 2 人のエンジニアが数日かかりました。

すべてのヒーローがマントを着ているわけではない

はい、決まり文句ですが、それは真実です。

並行プログラムのデバッグは非常に重要です。これらの扱いにくい同時実行バグをデバッグして解決するには、膨大な時間がかかります。Rust のような新しい言語には、このような競合状態を防ぐためのメカニズムが組み込まれていますが、世の中のソフトウェアの大部分はすでに作成されており、しかもRust以外の言語で書かれています。Java は、何年も経った今でも、最も使用されている言語の 1 つです。JVM ベースの言語でのデバッグを改善することで、ソフトウェア エンジニアリングの世界がより良くなります。また、一部の人々がコードは大規模言語モデルによって記述されると考えていることを考えると、エンジニアとしての私たちの仕事は、最終的には自分自身の悪いコードだけでなく、悪い LLM コードをデバッグすることだけになるかもしれません。しかし、ソフトウェア エンジニアリングの将来がどうであろうと、並行プログラムのデバッグはソフトウェアの保守と構築にとって重要なままです。

これをさらに素晴らしいものにしてくれた PASTA ラボの Ao Li 氏と同僚の皆さんに感謝します。

Luceneとコミュニティ

プロジェクトの強さは、それをサポートするコミュニティの強さによって決まります。20 年以上の開発期間を経ても、Lucene プロジェクトは、熱心で活動的な貢献者のおかげで、活気に満ち、成長し続けています。

2024 年、Lucene プロジェクトでは 98 人の貢献者から 2,000 件を超えるコミットと、約 800 件のプル リクエストが行われました。新しいコミッターや PMC メンバーがプロジェクトに参加し、プロジェクトの成功に貢献しているため、貢献者の数は増え続けています。

ルーシーン10

2024 年には、ほぼ 3 年ぶりのメジャー リリースである Lucene 10 がリリースされ、185 人の貢献者から 2,000 件を超えるコミットが行われました。Lucene が採用している開発モデルでは、マイナー リリースで多くの改善や機能を提供できますが、メジャー リリースではより大きな機能や最新化を導入する機会が与えられます。たとえば、Lucene 10 には少なくとも Java 21 が必要です。最小 Java バージョンを上げると、Lucene は最新の Java が提供する改善点を引き続き活用できるようになります。

Lucene 10 の主な焦点は、それが実行されるハードウェアをより有効に活用することです。主なハイライトのいくつかを簡単に見てみましょう。

• 検索の並列化の強化- 検索実行は既にセグメント間で並列化されていますが、セグメント内での並列化がさらに進みました。これにより、ディスク上の表現と実行パフォーマンスが分離され、単一のセグメントでも最新システムのコア数のメリットを享受できるようになります。

• より優れた I/O 並列処理- Lucene が使用する単純な同期 I/O モデルが、プリフェッチ ステージによって強化されました。これにより、呼び出しスレッドをブロックせずに、インデックス ファイルの領域が近い将来必要になることを OS に通知します。

• スパース インデックスによる CPU とストレージの効率向上- Lucene 10 では、スパース インデックス (他のデータ ストアでは主キー インデックスまたはゾーン インデックスと呼ばれることもあります) のサポートが導入されています。

Lucene 10 の詳細については、Lucene 10 に関する専用記事をご覧ください。

ルーシーンの研究と革新

2024 年、Lucene では、特に機械学習の統合、ベクトル検索、大規模データセットの最適化の分野で研究とイノベーションが急増し、10 件の個別の研究論文と出版物が参照されています。主要な研究分野と開発には次のようなものがあります。

• ベクター検索と埋め込みのサポート- Lucene は、ベクターベースの検索のための強力でスケーラブルなソリューションを提供し、大規模なセマンティック検索を可能にします。Lucene の堅牢なインデックス作成および検索インフラストラクチャを活用することで、ユーザーは従来のテキスト検索の長所と最新のベクター検索の高度な機能を組み合わせることができ、Lucene は幅広い検索および情報取得タスクに対応する包括的なソリューションになります。

• ハイブリッド検索モデル- 研究では、従来のキーワードベースの検索と最新のベクターベースの検索を組み合わせた、ハイブリッド検索技術についても詳しく調べられています。Lucene は、用語ベースのインデックスと高密度のベクトル表現を統合することで、従来の検索エンジンの精度とセマンティック検索の柔軟性の間のギャップを埋め、より正確で文脈的に関連性の高い検索結果を提供できます。

2024 年に進行中の研究活動は、特に AI、セマンティック検索、ビッグデータ アプリケーションの分野における、最新の検索テクノロジーの進化するニーズに対する Lucene の適応性を実証しています。このプロジェクトは、従来の検索ユースケースと最先端の検索ユースケースの両方に対応する強力で柔軟性が高く効率的なプラットフォームとして成長を続けています。

2024年のLuceneリリース

正確な反映ではありませんが、リリースの膨大な量は、コミュニティの継続的な献身とエネルギーを浮き彫りにしています。これらのアップデートには、ベクトル検索のパフォーマンスと効率の大幅な強化、madvise のサポート、ポスティング リストのデコードの最適化、SIMD によるさらなる速度向上などが含まれています。

リリースの全リストは次のとおりです。

• 10.1.0（2024年12月20日）

• 9.12.1 (2024年12月13日)

• 10.0.0 (2024年10月14日)

• 9.12.0 (2024年9月28日)

• 8.11.4 (2024年9月24日)

• 9.11.1 (2024-06-27)

• 9.11.0 (2024-06-06)

• 9.10.0（2024年2月20日）

• 8.11.3 (2024年2月8日)

• 9.9.2 (2024年1月29日)

詳細情報とリリース ノートについては、 Lucene Coreページをご覧ください。さらに、同等のPyLuceneリリースもあります。

まとめ

Lucene は成熟するにつれ、熱心で活気のあるコミュニティのおかげで繁栄し続けています。これまで見てきたように、2024 年は信じられないほど生産性の高い年であり、私たちは 2025 年にもたらされる刺激的な発展に期待を寄せています。

このブログはいつもと違います。新しい機能の説明やチュートリアルではありません。これは、記述に 3 日かかった 1 行のコードです。Apache Lucene インデックスの潜在的な破損を修正します。皆さんが理解して頂けるよう、いくつかのポイントを挙げておきます。

• 十分な時間と適切なツールがあれば、すべての不安定なテストは再現可能である

• 堅牢なシステムには、多層的なテストが重要です。ただし、テストのレベルが上がるにつれて、デバッグと再現がますます難しくなります。

• Sleepは優れたデバッガーです

Elasticsearchのテスト方法

Elastic では、Elasticsearch コードベースに対して実行されるテストが多数あります。シンプルで集中的な機能テストもあれば、単一ノードの「ハッピーパス」統合テスト、さらには障害シナリオですべてが正しく動作することを確認するためにクラスターを破壊しようとするテストもあります。テストが継続的に失敗する場合は、エンジニアまたはツール自動化によって github の問題が作成され、特定のチームが調査できるようにフラグが付けられます。この特定のバグは、最後の種類のテストによって発見されました。これらのテストは扱いが難しいため、何度も実行しないと再現できないこともあります。

このテストは実際に何をテストしているのでしょうか?

この特定のテストは興味深いものです。特定のマッピングを作成し、それをプライマリ シャードに適用します。次にレプリカを作成しようとします。主な違いは、レプリカがドキュメントを解析しようとすると、テストによって例外が挿入され、その結果、予期しない (しかし予想どおりの) 方法で回復が失敗するという点です。

すべては期待通りに機能していましたが、1つ大きな問題がありました。テストのクリーンアップ中に一貫性を検証したところ、このテストで問題が発生しました。

このテストは予想どおりに失敗しました。整合性チェック中に、複製された Lucene セグメント ファイルとプライマリ Lucene セグメント ファイルがすべて整合性があることを確認します。つまり、破損しておらず、完全に複製されています。部分的なデータや破損したデータが存在することは、何かが完全に機能しなくなるよりもはるかに悪い状況です。以下は、失敗の恐ろしい短縮版スタック トレースです。

何らかの理由で、強制レプリケーションの失敗中に、レプリケートされたシャードが破損してしまいました。エラーの重要な部分を平易な英語で説明しましょう。

Lucene はセグメント ベースのアーキテクチャです。つまり、各セグメントは独自の読み取り専用ファイルを認識して管理します。この特定のセグメントは、すべてが正常であることを確認するために、 SegmentCoreReadersを介して検証されていました。各コア リーダーには、特定のセグメントに存在するフィールド タイプとファイルを示すメタデータが保存されています。ただし、 Lucene90PointsFormatを検証するときに、特定の予期されたファイルが見つかりませんでした。セグメント_0.cfsファイルでは、 kdiと呼ばれるポイント形式ファイルが予期されていました。cfs 「複合ファイル システム」を表します。Lucene は、より効率的なレプリケーションとリソース利用のために、すべてのフィールド タイプとすべての小さなファイルを 1 つの大きなファイルに結合することがあります。実際、ポイント ファイル拡張子kdd 、 kdi 、 kdmの 3 つすべてが欠落していました。Lucene セグメントがポイント ファイルを見つけることを期待しているのに、それが見つからないという状況に陥るのはなぜでしょうか。恐ろしい破損バグのようです。

あらゆるバグ修正の最初のステップは、それを再現すること

この特定のバグの障害を再現するのは非常に困難でした。Elasticsearch のランダム値テストを活用しながら、すべての障害を調査できるように、すべての障害に (できれば) 再現可能なランダム シードを提供するようにしています。そうですね、これは競合状態によって引き起こされる障害を除くすべての障害に対してうまく機能します。

何度試しても、特定のシードはローカルで失敗を繰り返すことはありませんでした。しかし、テストを実行して、より再現性の高い失敗へと導く方法はあります。

私たちの特定のテスト スイートでは、 -Dtests.itersパラメータを使用して、同じコマンドで特定のテストを複数回実行できます。しかし、これだけでは十分ではなく、実行スレッドが切り替わっていることを確認し、競合状態が発生する可能性を高める必要がありました。システムのもう一つの問題は、テストの実行に非常に長い時間がかかり、テスト ランナーがタイムアウトになることでした。最終的に、私は次の悪夢のような bash を使用してテストを繰り返し実行しました。

ストレスが溜まります。これにより、CPU コアを大量に消費するプロセスをすばやく開始できます。失敗するテストを何度も繰り返し実行しながら、ランダムに stress-ng をスパムすることで、最終的に失敗を再現することができました。一歩近づく。システムに負荷をかけるには、別のターミナル ウィンドウを開いて次のコマンドを実行します。

バグの発見

バグを明らかにするテストの失敗がほぼ再現可能になったので、今度は原因を探してみましょう。この特定のテストが奇妙である理由は、Lucene がポイント値を期待しているにもかかわらず、テストによってポイント値が直接追加されないためにエラーがスローされる点です。テキスト値のみ。このため、楽観的同時実行制御フィールド_seq_noと_primary_termの最近の変更点を確認することを検討することにしました。これらは両方ともポイントとしてインデックス化され、すべての Elasticsearch ドキュメントに存在します。

確かにコミットによって_seq_noマッパーが変更されました。はい！原因はきっとこれだ！しかし、私の興奮は長くは続かなかった。これにより、ドキュメントにフィールドが追加される順序のみが変更されました。この変更の前は、 _seq_noフィールドがドキュメントの最後に追加されていました。その後、最初に追加されました。Lucene ドキュメントにフィールドを追加する順序がこの失敗の原因となるはずはありません...

はい、フィールドの追加順序を変更すると、エラーが発生しました。これは驚くべきことで、Lucene 自体のバグであることが判明しました。解析されるフィールドの順序を変更しても、ドキュメントの解析動作は変更されません。

Luceneのバグ

実際、Lucene のバグは次の条件に焦点を当てていました。

• ポイント値フィールドのインデックス作成（例：_seq_no ）

• 分析中にテキストフィールドのインデックスを作成しようとしています

• この奇妙な状態では、テキストインデックス分析例外を経験したライターからニアリアルタイムリーダーを開きます。

しかし、どんなに方法を試しても、完全に再現することはできませんでした。Lucene コードベース全体にデバッグ用の一時停止ポイントを直接追加しました。例外パス中にランダムにリーダーを開こうとしました。この障害が発生した正確なパスを見つけようとして、何メガバイトものログを印刷することさえしました。どうしてもできなかったんです。私は一日中戦って負け続けました。

それから私は眠りました。

翌日、元のスタック トレースを再度読み直して、次の行を発見しました。

これまでの再現の試みにおいて、私は保持マージポリシーを具体的に設定したことはありません。SoftDeletesRetentionMergePolicyは Elasticsearch によって使用され、レプリカ内の削除を正確に複製し、ドキュメントが実際に削除されるタイミングをすべての同時実行制御が管理できるようにします。それ以外の場合、Lucene は完全な制御権を持ち、マージ時にそれらを削除します。

このポリシーを追加し、上記の最も基本的な手順を再現すると、障害はすぐに再現されました。

Lucene でバグを発見してこれほどうれしかったことはありません。

Elasticsearch では競合状態として現れましたが、すべての条件が満たされると、Lucene で繰り返し失敗するテストを書くのは簡単でした。

結局、すべてのバグと同様に、たった 1 行のコードで修正されました。たった 1 行のコードのために、数日間の作業が必要でした。

しかし、それは価値がありました。

終わりではない

私と一緒にこのワイルドな旅を楽しんでいただけたら嬉しいです！ソフトウェア、特にElasticsearchやApache 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

1

1

1

Elasticsearch-8.14.0@lucene-int8_hnsw

1

0.986667

1

OpenSearch-2.14.0@lucene-hnsw

1

1

1

OpenSearch-2.14.0@faiss

1

1

1

OpenSearch-2.14.0@faiss-sq_fp16

1

1

1

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は、検索における次のイノベーションの波を支える態勢が整っています。

HNSW はベクトルを保存および検索するための強力かつ柔軟な方法ですが、高速に実行するには大量のメモリが必要です。たとえば、768 次元の 1MM float32 ベクトルをクエリするには、およその RAM が必要です。大量のベクトルを検索し始めると、コストが高くなります。メモリ使用量を約削減する方法の 1 つは、バイト量子化を使用することです。Lucene と Elasticsearch は以前からベクトルのインデックス作成をサポートしてきましたが、これらのベクトルの構築はユーザーの責任でした。Lucene にスカラー量子化が導入されたため、この状況は変わりつつあります。

スカラー量子化101

すべての量子化手法は、生データの非可逆変換であると見なされます。つまり、スペースの都合上、一部の情報が失われます。スカラー量子化の詳細な説明については、 「スカラー量子化 101」を参照してください。大まかに言えば、スカラー量子化は非可逆圧縮技術です。簡単な計算により、リコールにほとんど影響を与えずに、大幅にスペースを節約できます。

建築を探る

Elasticsearch の使用に慣れている方は、これらの概念にすでに馴染みがあるかもしれませんが、ここでは検索対象ドキュメントの配布について簡単に概要を説明します。

各 Elasticsearch インデックスは複数のシャードで構成されます。各シャードは 1 つのノードにのみ割り当てることができますが、インデックスごとに複数のシャードを割り当てることで、ノード間で並列計算が可能になります。

各シャードは単一のLucene インデックスとして構成されます。Lucene インデックスは複数の読み取り専用セグメントで構成されます。インデックス作成中、ドキュメントはバッファリングされ、定期的に読み取り専用セグメントにフラッシュされます。特定の条件が満たされると、これらのセグメントをバックグラウンドでより大きなセグメントにマージできます。これらはすべて構成可能であり、独自の複雑さを伴います。ただし、セグメントとマージについて話すときは、読み取り専用の Lucene セグメントと、これらのセグメントの定期的な自動マージについて話しています。ここでは、セグメントのマージと設計上の決定について詳しく説明します。

Luceneにおけるセグメントごとの量子化

Lucene のすべてのセグメントには、個々のベクトル、HNSW グラフ インデックス、量子化されたベクトル、および計算された分位数が保存されます。簡潔にするために、Lucene が量子化されたベクトルと生のベクトルを保存する方法に焦点を当てます。すべてのセグメントについて、 ファイル内の生のベクトル、 内の量子化されたベクトルと単一の補正乗数浮動小数点数、およびファイル内の量子化に関するメタデータを追跡します。

図 1: 生のベクター保存ファイルの簡略化されたレイアウト。 値は 4 バイトなので、 dimension量子化しているため、これらは HNSW 検索中に読み込まれません。これらは、特に要求された場合にのみ使用されます（例：再スコアリングによるブルートフォースセカンダリ、またはセグメントマージ中の再量子化に使用します。

図2: の簡略化されたレイアウトファイル。のスペースを占有し、検索中にメモリにロードされます。バイトは、スコアリングを調整して精度と再現性を向上させるために使用される補正乗数浮動小数点数を表します。

図 3: メタデータ ファイルの簡略化されたレイアウト。ここで、このセグメントの計算された分位数とともに、量子化とベクトル構成を追跡します。

したがって、各セグメントについて、量子化されたベクトルだけでなく、これらの量子化されたベクトルの作成に使用された分位数と元の生のベクトルも保存します。しかし、なぜ生のベクトルを保存しておくのでしょうか?

あなたとともに成長する量子化

Lucene は定期的にセグメントを読み取り専用にフラッシュするため、各セグメントにはすべてのデータの部分的なビューのみが表示されます。つまり、計算された四分位数は、データ全体のそのサンプル セットにのみ直接適用されます。さて、サンプルがコーパス全体を適切に代表しているのであれば、これは大した問題ではありません。しかし、Lucene ではさまざまな方法でインデックスを並べ替えることができます。したがって、セグメントごとの分位数計算にバイアスを追加する方法でソートされたデータをインデックス化することができます。また、いつでも好きなときにデータをフラッシュできます。サンプル セットは、たとえ 1 つのベクトルだけでも非常に小さい可能性があります。さらにもう一つの問題は、マージがいつ発生するかを制御できることです。Elasticsearch ではデフォルトと定期的なマージが設定されていますが、 _force_merge API を介していつでもマージを要求できます。では、どうすれば、優れた再現性をもたらす適切な量子化を実現しながら、こうした柔軟性をすべて実現できるのでしょうか?

Lucene のベクトル量子化は時間の経過とともに自動的に調整されます。Lucene は読み取り専用セグメント アーキテクチャで設計されているため、各セグメントのデータが変更されていないことが保証され、コード内で更新できるタイミングが明確に区別されます。つまり、セグメントのマージ中に、必要に応じて分位数を調整し、ベクトルを再量子化できる可能性があります。

図 4: 異なる分位数を持つ 3 つのセグメントの例。

しかし、再量子化はコストがかかるのではないですか?多少のオーバーヘッドはありますが、Lucene は分位数をインテリジェントに処理し、必要な場合にのみ完全に再量子化します。図 4 のセグメントを例に挙げてみましょう。セグメントとにそれぞれドキュメントを割り当て、セグメントにはドキュメントのみを割り当てます。Lucene は、四分位数の加重平均を取得し、その結果として得られる結合された四分位数がセグメントの元の四分位数に十分近い場合、そのセグメントを再量子化する必要がなく、新しく結合された四分位数を利用します。

図 5: セグメントとにドキュメントがあり、セグメントにはドキュメントしかない場合の結合された分位数の例。

図5に示されている状況では、結果として得られる統合された分位数は、 との元の分位数と非常に類似していることがわかります。したがって、ベクトルを量子化する必要性は認められません。セグメントは、逸脱しすぎているようです。その結果、 のベクトルは、新しく結合された分位値で再量子化されます。

実際、結合された四分位数が元の四分位数と大幅に異なる極端なケースもあります。この場合、各セグメントからサンプルを取得し、四分位数を完全に再計算します。

量子化性能と数値

それで、それは高速であり、良好なリコールを提供し続けるのでしょうか?c3-standard-8 GCP インスタンスで実験を実行すると、次の数値が収集されました。との公平な比較を確実にするために、生のベクトルをメモリ内に保持するのに十分な大きさのインスタンスを使用しました。最大内積を使用してCohere Wikiベクトルをインデックスしました。

図 6: 量子化ベクトルと生のベクトルの Recall@10。量子化ベクトルの検索パフォーマンスは生のベクトルよりも大幅に高速で、さらに 5 つのベクトルを集めるだけでリコールをすぐに回復できます。これはで確認できます。

図6にそのストーリーを示します。予想通り、再現率の違いはありますが、それは大きな差ではありません。そして、さらに 5 つのベクトルを集めるだけで、再現率の差は消えます。これらすべてを、セグメントのマージが高速化し、 ベクトルの 1/4 のメモリで実現します。

まとめ

Lucene は、難しい問題に対する独自のソリューションを提供します。量子化には「トレーニング」や「最適化」のステップは必要ありません。Lucene では、問題なく動作します。データがシフトした場合にベクトル インデックスを「再トレーニング」する必要があることを心配する必要はありません。Lucene は重要な変更を検出し、データの存続期間中これを自動的に処理します。この機能が Elasticsearch に導入されるのを楽しみにしてください。

背景

Elasticsearch を開発しているときに、解決するための単純なアプローチや確立されたアプローチがない重要な問題に遭遇することがあります。「うーん、これについて言及している学術論文はあるのだろうか？」と疑問に思うのは当然です。時には、学術的な仕事がインスピレーションの源となることもあります。新しいアルゴリズムやデータ構造を提案する論文に出会うと、「これはとても便利だろう！」と思うでしょう。Elasticsearch と Apache Lucene が学術研究にどのように組み込まれているか、いくつかの例を次に示します。

• カーディナリティ集計 のための HyperLogLog++

• 適応型レプリカ選択 のための C3アルゴリズム

• Lucene における最近傍ベクトル検索のための階層的ナビゲート可能スモールワールドグラフ (HNSW)

• 機械学習の分類を改善する ための MIC統計

• Lucene でトップヒット検索を高速化 する ブロック最大 WAND

• ... その他 多数

学術論文は、データ集約型システムを開発するエンジニアにとって貴重なリソースです。しかし、それらを実装するのは困難で、エラーが発生しやすくなります。アルゴリズムの説明は複雑であることが多く、重要な実用的な詳細が省略されています。そして、テストは本当に難しいです。たとえば、出力がデータセットに大きく依存する機械学習アルゴリズムを徹底的にテストするにはどうすればよいでしょうか。

ソフトウェアの依存関係と同じように論文を評価する

新しいソフトウェア依存関係を追加するには、慎重な評価が必要です。他のパッケージが正しくなかったり、速度が遅かったり、安全でなかったりする場合は、プロジェクトも同様になる可能性があります。依存関係を導入する前に、開発者は必ずその品質を評価します。

実装を検討している学術論文にも同じことが当てはまります。アルゴリズムが論文で発表されているので、そのアルゴリズムは正しく、パフォーマンスも優れているに違いないと思われるかもしれません。しかし、査読プロセスに合格したとしても、学術論文には問題がある可能性があります。おそらく、正しさの証明は現実的ではない仮定に依存しているのでしょう。あるいは、「実験」セクションではベースラインよりもはるかに優れたパフォーマンスが示されていますが、これは特定のデータセットにのみ当てはまります。たとえ論文の質が優れていたとしても、そのアプローチがプロジェクトに適していない可能性があります。

学術論文に「依存」するかどうかを考えるときは、ソフトウェア パッケージの場合と同じ質問をすると役立ちます。

• ライブラリは広く使用され、「実戦テスト済み」ですか?→ 他のパッケージでもこの論文は実装されていますか? また、うまく機能しましたか?

• パフォーマンスベンチマークは利用可能ですか?これらは正確かつ公平と思われますか?→論文には現実的な実験が含まれていますか？それらはうまく設計されていますか?

• パフォーマンスの改善は複雑さを正当化するほど大きいですか?→ この論文は強力なベースラインアプローチに匹敵しますか?このベースラインをどれだけ上回るのでしょうか?

• このアプローチは当社のシステムとうまく統合されるでしょうか?→ アルゴリズムの前提とトレードオフは、私たちのユースケースに適合していますか?

どういうわけか、ソフトウェア パッケージが競合製品とのパフォーマンス比較を公開すると、そのパッケージが常に最速であると出てきます。第三者がベンチマークを設計した場合、よりバランスが取れる可能性があります。同じ現象が学術論文にも当てはまります。アルゴリズムが元の論文だけでなく、他の論文でも強力なベースラインとして優れたパフォーマンスを示している場合、そのアルゴリズムは信頼できる可能性が非常に高くなります。

テストを創造的に行う

学術論文のアルゴリズムは、私たちが日常的に目にするタイプのアルゴリズムよりも動作が洗練されていることがよくあります。おそらく、これは精度と引き換えに速度を向上させる近似アルゴリズムです。あるいは、大規模なデータセットを取り込み、（場合によっては予期しない）出力を生成する機械学習の手法である可能性もあります。アルゴリズムの動作を単純な方法で特徴付けることができない場合、これらのアルゴリズムのテストをどのように記述できるでしょうか?

不変量に焦点を当てる

ユニット テストを設計するときは、例に基づいて考えるのがよくあります。つまり、アルゴリズムにこの例の入力を与えると、その出力が得られるはずです。残念ながら、ほとんどの数学アルゴリズムでは、例に基づくテストではその動作を十分にカバーできません。

Elasticsearch が検索リクエストをどのノードが処理すべきかを判断するために使用する C3 アルゴリズムを考えてみましょう。ノードの以前のサービスと応答時間、およびキュー サイズを組み込んだ微妙な計算式を使用して各ノードをランク付けします。いくつかの例をテストしても、式を正しく理解できたかどうかは実際には確認できません。一歩下がって不変条件のテストについて考えてみると役に立ちます。サービス時間が長くなると、ノードのランクは下がりますか?キューのサイズが 0 の場合、論文で主張されているように、ランクは応答時間によって決定されますか?

不変条件に焦点を当てると、次のような多くの一般的なケースで役立ちます。

• このメソッドは順序に依存しないものになるのでしょうか?もしそうなら、入力データを異なる順序で渡すと同じ出力が得られるはずです。

• アルゴリズムの何らかのステップでクラス確率が生成されますか?もしそうなら、これらの確率の合計は 1 になるはずです。

• 関数は原点を中心に対称ですか?もしそうなら、入力の符号を反転すると、出力の符号も単に反転するはずです。

C3 を初めて実装したとき、式にバグがあり、応答時間の代わりに応答時間の逆数を誤って使用していました。つまり、より遅いノードの方が上位にランク付けされる可能性があるということです。問題を修正する際には、将来のミスを防ぐために不変チェックを追加するようにしました。

リファレンス実装と比較する

論文とともに、著者らはアルゴリズムの実装も公開したようです。(論文に実験が含まれている場合は特にこの可能性が高くなります。多くのジャーナルでは、著者が結果を再現するためのコードを投稿することを求めているためです。)このリファレンス実装に対してアプローチをテストし、アルゴリズムの重要な詳細を見逃していないことを確認できます。

最近傍検索用の Lucene HNSW 実装を開発する際に、論文の著者による参照ライブラリに対してテストを行いました。同じデータセットに対して Lucene とライブラリの両方を実行し、結果の精度と実行された計算の数を比較しました。これらの数値がほぼ一致する場合、Lucene がアルゴリズムを忠実に実装していることがわかります。

アルゴリズムをシステムに組み込む場合、複数のコアに拡張したり、パフォーマンスを向上させるためにヒューリスティックを追加したりするなど、変更や拡張を行う必要があることがよくあります。最初に「バニラ」バージョンを実装し、リファレンスに対してテストしてから、段階的な変更を加えるのが最適です。そうすれば、カスタマイズを行う前に、すべての重要な部分を確実にキャプチャできます。

既存のアルゴリズムとの決闘

最後のセクションでは、テスト不変条件の別のアイデアとして、アルゴリズムの出力を、より単純で理解しやすいアルゴリズムの出力と比較する方法について説明します。例として、上位の結果に表示されないドキュメントをスキップすることでドキュメントの検索を高速化する、Lucene の block-max WAND アルゴリズムを考えてみましょう。block-max WAND があらゆるケースでどのように動作するかを正確に説明することは困難ですが、これを適用しても上位の結果は変わらないはずです。したがって、テストではランダムな検索クエリをいくつか生成し、それらを WAND 最適化ありとなしの両方で実行して、結果が常に一致することを確認できます。

これらのテストの重要な側面は、比較を実行するためのランダムな入力を生成することです。これにより、思いもよらなかったケースを練習したり、予期しない問題を明らかにしたりすることができます。たとえば、Lucene の BM25F スコアリングのランダム化比較テストは、微妙なエッジ ケースのバグを検出するのに役立ちました。アルゴリズムにランダムな入力を与えるという考え方には、コンピューター セキュリティの一般的なテスト手法であるファジングの概念との密接な関係があります。

Elasticsearch と Lucene では、このテスト手法が頻繁に使用されます。2 つのアルゴリズム (TestDuelingAnalyzers、testDuelTermsQuery...) 間の「決闘」について言及しているテストを見ると、この戦略が実行中であることがわかります。

論文の用語を使用する

他の開発者があなたのコードで作業する場合、詳細を理解するために論文を参照する必要があります。Elasticsearch の HyperLogLog++ 実装に関するコメントは、次のようにうまく表現しています。「論文を読まずにこのクラスが何をするかを理解しようとするのは冒険的だと見なされます。」このメソッドのコメントも良い例を示しています。学術論文へのリンクが含まれており、元々説明されていたアルゴリズムにどのような変更が加えられたかが強調されています。

開発者は紙に基づいてコードを理解するので、まったく同じ用語を使用すると便利です。数学表記は簡潔なので、通常は「適切なスタイル」とは見なされない名前になることもありますが、論文の文脈では非常に明確になります。学術論文の数式は、Elasticsearch でrS や muBarSInverseのような難解な変数名に遭遇する数少ない例の 1 つです。

著者が推奨する論文の読み方は、大きなコーヒーを飲みながら読むことです。

著者にメールを送ることができます

難しい論文に取り組むとき、誤解しているのか、それとも単なるタイプミスなのかわからず、数式について頭を悩ませるのに何時間も費やすことがあります。これがオープンソース プロジェクトであれば、GitHub または StackOverflow で質問することができます。しかし、学術論文はどこで入手できるのでしょうか?著者は忙しそうなので、あなたのメールにイライラするかもしれません。

それどころか、多くの学者は自分のアイデアが実践されていると聞くことを喜び、メールで質問に喜んで答えてくれます。彼らが精通している製品に取り組んでいる場合は、そのアプリケーションが彼らの Web サイトに掲載される可能性もあります。

また、ソフトウェア開発で使用したのと同じツールの多くを使用して、研究者が論文を公開して議論する傾向も高まっています。論文にソフトウェア パッケージが付属している場合は、 Github でよくある質問への回答が見つかることがあります。「理論計算機科学」や「Cross Validated」などの Stack Exchange コミュニティにも、人気のある論文に関する詳細な議論が含まれています。一部の会議では、すべての論文レビューをオンラインで公開し始めています。これらのレビューには著者との双方向の議論が含まれており、アプローチに関する役立つ洞察が得られる可能性があります。

つづく

この投稿では、学術論文の選び方の基本に焦点を当て、

正しく実装しますが、アルゴリズムを実際に展開するすべての側面をカバーしているわけではありません。たとえば、アルゴリズムが複雑なシステムの 1 つのコンポーネントにすぎない場合、そのコンポーネントへの変更がエンドツーエンドの改善につながることをどのように保証すればよいでしょうか。また、アルゴリズムを統合するために、元の論文でカバーされていない大幅な変更や拡張が必要な場合はどうなるでしょうか?これらは重要なトピックであり、今後の投稿でさらに詳しく共有したいと考えています。