カテゴリー: elasticsearch

search-ann-benchmarkにElasticsearch 9.2のDiskBBQを追加

ベクトル検索エンジンの性能評価ツールsearch-ann-benchmarkで、Elasticsearch 9.2で追加されたDiskBBQ（bbq_disk）インデックスタイプの評価を追加しました。

DiskBBQとは

DiskBBQは、Elasticsearch 9.2で導入された新しいベクトルインデックスタイプです。従来のBBQ（Better Binary Quantization）がメモリベースのHNSWグラフを使用するのに対し、DiskBBQはディスクベースで動作します。

これにより、メモリ使用量を抑えつつ大規模なベクトルデータを扱えるようになります。ただし、ディスクアクセスが発生するため、検索速度とのトレードオフがあります。

search-ann-benchmarkの変更内容

主な変更点は以下の3つです。

CLIオプションの追加

--quantizationオプションにbbq_diskを追加しました。これで、コマンドラインからDiskBBQを使用したベンチマークを実行できます。

search-ann-benchmark run elasticsearch \
  --target 100k-768-m32-efc200-ef100-ip \
  --version 9.2.3 \
  --quantization bbq_disk

インデックス作成ロジックの調整

DiskBBQは従来のHNSWパラメータ（m、ef_construction）をサポートしないため、インデックス作成時にこれらのパラメータを除外するように修正しました。

GitHub Actionsワークフローの追加

DiskBBQ専用のベンチマークワークフローを追加しました。Elasticsearch 9.2.3を使用して、100k、1M、5Mのデータセットに対してテストできます。

大規模データセットでの効果

DiskBBQは、メモリ使用量の削減が主な目的のため、小規模なデータセットでは従来のbbq_hnswとの差があまり出ないかもしれません。5M以上のベクトルを扱うような大規模なデータセットで、メモリ効率の違いがより明確になると思います。

    ベクトル検索エンジンの性能検証

    以前からcodelibs/search-ann-benchmarkで、VespaやElasticsearchなどのベクトル検索の性能評価を行っていましたが、notebookで管理していたため、メンテしていくのも最近辛くなり、放置してました…。

    放置しておくと、最近の動向などにもキャッチアップできなくなってくるので、今回、Claude Codeを使って、ipynbだったファイルたちを、uv管理のPythonプロジェクトとして、整理を行いました。Claude Codeで管理しやすくすることで、今後、各検索エンジンのバージョンアップにも追随しやすくなるはずです。

    そんな感じで、再運用を始めて、ベンチマーク結果を見たら、以前は、Vespaとqdrantの2強だったのが、Elasticsearchも同等の性能が出せるようになっていました。Project Panamaとかで、Elasticsearchが追いつけるのかな？とか思っていたけど、追いついたようですね。すばらしい。OpenSearchも以前より速くなった気はするけど、まだ、何か改善が必要そうな結果ではあるので、頑張って欲しいところである。

    ということで、放置していたベクトル検索の性能評価を再始動して、今後もメンテはできると思うので、興味があれば、たまに見てみてください。他にも追加できそうな検索エンジンがあれば、追加すると思います。

    ベクトル検索の性能比較一覧

    codelibs/search-ann-benchmark でANNでのベクトル検索プロダクトの性能を確認できるようにしているけど、GitHub Actionsで実行している結果をここで一覧できるようにしました。GitHub Actionsで実行した結果を一日一回収集して、そのページにまとめて簡単に確認できるようにした感じです。

    上位10件と上位100件を取得した場合の平均応答時間と精度になります。ここで言う精度というのは、近似的な近傍検索なので、上位K件が期待するものとは限らないので、厳密な距離計算をしたときに得られるK件と比較してどれだけ一致しているか？というPrecision@Kの値です。10件取得して、正解と9件しか一致していなければ、0.9のようになります。

    応答速度と精度のバランスが取れるように各種設定を調整していますが、実行しているコードはGitHubに置いてあるので、より良い値があれば、プルリクなどいただければと思います。一応、HNSWで統一してあるので、mやefなどのパラメーターは一緒にしてあります。

    Qdrantが安定して、速さを保っている感じで、ElasticsearchやOpenSearchのLucene系は着実に追い上げてきている感じです。ただ、Lucene系は取得件数が多くなると、他と比べて、応答速度の劣化が大きいです。PGVectorは量子化対応されないと、応答時間での差は埋めるのはしばらく難しい気がします。

    という感じで、ベクトル検索まわりの調査等々をしてきて、いろいろと知見はあるので、何かあれば、CodeLibs, Inc.までご相談いただければと。