Elasticsearch 8.0で近似最近傍探索を導入

テキスト、画像、イベントなど、あらゆる種類のコンテンツをベクトルとして表現できる新世代のMachine Learningモデルの登場により、ベクトル検索への関心が急激に高まっています。「埋め込みモデル」と呼ばれることが多いこれらの強力な表現は、表面的な特性を超えた方法で2つのコンテンツ間の類似性を捉えることができます。

k近傍法（kNN）検索するアルゴリズムは、データセット内でクエリベクトルに最も類似したベクトルを検索します。これらのベクトル表現と組み合わせることで、kNN検索するは検索における新たな可能性を切り拓きます：

• 質問の答えが含まれている可能性が高いパッセージの検索
• 大規模なデータセットにおけるニア重複画像の検出
• 指定した曲に似た曲を検索する

ベクトル検索は、用語ベースのスコアリングのような従来の技術と並び、検索ツールボックスの重要なコンポーネントになろうとしています。

Elasticsearchでは現在、dense_vectorフィールドタイプを通じてベクトルを格納し、それを使用してドキュメントスコアを計算することをサポートしています。これにより、ユーザーはすべてのドキュメントをスキャンして正確なkNN検索を実行できるようになります。Elasticsearch 8.0では、この機能を基盤として、高速な近似最近傍（ANN）検索をサポートしています。これははるかに拡張性の高いアプローチであり、大規模なデータセット上でベクトル検索を効率的に実行できます。

ElasticsearchにおけるANN

近似最近傍を検索するとは何ですか？

低次元ベクトルにおけるkNNには、KD木のような確立されたデータ構造が存在します。実際、ElasticsearchはKD木を組み込んでおり、地理空間データや数値データの検索をサポートしています。しかし、テキストや画像向けの最新の埋め込みモデルは、通常100～1000要素、あるいはそれ以上の高次元ベクトルを生成します。これらのベクトル表現には特有の課題があります。高次元空間において最近傍を効率的に見つけることは非常に困難であるためです。

この困難に直面した場合、最近傍アルゴリズムは通常、速度を向上させるために完璧な正解率を犠牲にします。これらの近似最近傍（ANN）アルゴリズムは、必ずしも真のk個の最近傍ベクトルを返すとは限りません。しかし、それらは効率的に実行され、優れたパフォーマンスを維持しながら、大規模なデータセットに合わせてスケーリングします。

ANNアルゴリズムの選択

ANNアルゴリズムの設計は学術研究の活発な分野であり、選択肢となる有望なアルゴリズムが数多く存在します。これらは多くの場合、検索するスピード、実装の複雑さ、インデキシングコストの面で異なるトレードオフを伴います。幸いなことに、主要なアルゴリズムをいくつかのデータセットでテストし、比較結果を公開しているann-benchmarksという優れたオープンソースプロジェクトが存在します。

Elasticsearch 8.0は、Hierarchical Navigable Small Worldグラフ（HNSW）と呼ばれるANNアルゴリズムを使用しており、ベクトルを相互の類似性に基づいてグラフに整理します。HNSWは、さまざまなann-benchmarksデータセット全体で強力な検索パフォーマンスを示しており、独自のテストでも良好な結果が得られました。HNSWのもう1つの利点は、業界で広く使用されており、いくつかの異なるシステムに実装されていることです。オリジナルの学術論文に加えて、アルゴリズムの詳細を学習するための役立つリソースが多数あります。ElasticsearchのANNは現在HNSWに基づいていますが、この特徴は将来的に異なるアプローチを組み込めるよう柔軟に設計されています。

コードを見せてください！

ANN検索するためにベクトルをインデックス化するには、index: trueを設定し、比較に使用する類似性メトリックを指定する必要があります。

この例では、ANN検索は厳密なアプローチよりも桁違いに高速です。その再現率は約95％であるため、平均して10個の真の最近傍点のうち9個以上を見つけることができます。

Elasticsearchのナイトリーベンチマークで、kNN検索のパフォーマンスを確認できます。これらのベンチマークは、Elasticsearchのベンチマークツールであるes-rally、具体的には新しいdense_vector Rallyトラックによって実行されています。アルゴリズムの精度を追跡することも重要であるため、レイテンシに加えて再現率もレポートできるようにRallyを拡張する予定です。現在、これらのベンチマークでは数百万のベクトルからなるデータセットをテストしていますが、インデックス時間を長くしたりハードウェアリソースを追加したりすることで、ANN検索はこれを超えて確実にスケールさせることができます。

Apache Lucene搭載

Elasticsearchのコア検索機能の多くは、Apache Software Foundationが管理するオープンソースプロジェクトであるLuceneライブラリによって支えられています。Elasticsearch ANNも例外ではなく、数値ベクトルの格納と検索を行うためのLuceneの画期的な新しい特徴を基盤として構築されています。この特徴は、異なる組織の複数の開発者が協力した素晴らしい成果です。大胆な提案として始まり、すぐに実用的（かつ高速）な実装へと発展しました。次に、APIの設計と特徴の拡充という課題に取り組みました。

それ以来、Luceneコミュニティは協力し続け、この特徴を推進してきました。数名の開発者が関心を持ち、名称の再設計からアルゴリズムの更新、パフォーマンスの向上などに貢献しました。Luceneのベクトル検索機能は、皆さんの尽力のおかげで急速に拡大しています。

実りあるコラボレーションに加え、LuceneでANNを開発することには、他にも大きなメリットがあります。Luceneの実装は、既存の機能と正しく統合されるよう低レベルで設計されており、これによりANN検索は他のElasticsearchの特徴とシームレスに連携できるようになります。外部のANNライブラリに依存していた場合、このような深い統合は実際には不可能だったでしょう。例えば、Lucene ANNはグラフを検索する際に「トゥームストーン」をスキップすることで、削除されたドキュメントを透過的に処理します。また、Luceneのすべてのデータ互換性保証を遵守しているため、アップグレード後もベクトルデータが確実に機能します。最後に、Elasticsearchと同様にJavaで記述された実装であるため、セキュリティを確保し、メモリー管理を簡素化することができます。

さっそく活用しましょう

8.0では、効率的なANN検索のための_knn_searchエンドポイントが「テクニカルプレビュー」としてリリースされます。ANN検索することはElasticだけでなく業界全体にとっても比較的新しいトピックであり、その動作についてはまだ多くの重要な課題が残されています。ベクトル類似性スコアと従来のBM25スコアを組み合わせる最適な方法は何ですか？kNN検索することはページネーションをサポートすべきでしょうか？ANNを独自の実験的エンドポイントとして開発することで、その動作を迅速に反復・テストできるようになります。これらの疑問に対する確実な回答が得られ次第、最終的にANNを検索する APIに統合する予定です。（_knn_searchはまだGAではありませんが、dense_vectorフィールドタイプは7.6でGAとなり、引き続き安定したAPIを提供しています。）

サポートを予定している主要な機能には、フィルター付きANNや、ANNの結果を従来のクエリの結果と組み合わせる「ハイブリッド」検索などがあります。HNSWグラフの構築は負荷の高いオペレーションとなる可能性があるため、インデキシング速度の向上にも取り組んでいます。私たちはこのリリースを始まりに過ぎないと考えており、今後のリリースでANN検索することがさらに改善されることを楽しみにしています。皆様からのフィードバックは非常に貴重であり、特徴の方向性を形作るうえで役立ちます。GitHub や Discussフォーラム（および Lucene）での皆様からのフィードバックをお待ちしております！

Elastic Cloudコンソールにログインするか、14日間の無料トライアルに登録して、Elastic CloudでANN検索をお試しください。