Elasticsearchは死んだ、レキシカル検索万歳

Engineering

December 17, 2024

James Luan

今や誰もが、ハイブリッド検索がRAG（Retrieval-Augmented Generation）検索の品質を向上させたことを知っている。密な埋め込み検索は、クエリと文書間の深い意味的関係を捕らえる上で素晴らしい能力を示しているが、まだ顕著な限界がある。これには、説明可能性の欠如や、ロングテールのクエリや希少な用語に対する最適なパフォーマンスなどがある。

多くのRAGアプリケーションは、事前に訓練されたモデルにはドメイン固有の知識が欠けていることが多いため、苦戦している。シナリオによっては、単純なBM25キーワードマッチがこれらの洗練されたモデルを凌駕することもある。そこでハイブリッド検索がそのギャップを埋め、密なベクトル検索の意味理解とキーワードマッチングの精度を組み合わせます。

ハイブリッド検索が本番で複雑な理由

LangChainや LlamaIndexのようなフレームワークでは、概念実証のハイブリッド検索を簡単に構築することができますが、膨大なデータセットでの実運用へのスケーリングは困難です。従来のアーキテクチャでは、ベクターデータベースと検索エンジンを別々に構築する必要があり、いくつかの重要な課題がありました：

高いインフラ維持コストと運用の複雑さ
複数のシステムにまたがるデータの冗長性
困難なデータの一貫性管理
システム間の複雑なセキュリティとアクセス制御

システムの複雑さとコストを削減しながら、字句検索と意味検索をサポートする統一されたソリューションが求められている。

Elasticsearchの問題点

Elasticsearchは、過去10年間で最も影響力のあるオープンソースの検索プロジェクトの1つです。Apache Luceneをベースに構築され、その高いパフォーマンス、スケーラビリティ、分散アーキテクチャによって人気を博した。バージョン8.0でベクトルANN検索が追加されましたが、実運用ではいくつかの重大な課題に直面しています：

高い更新コストとインデックス作成コストElasticsearch のアーキテクチャは、書き込み操作、インデックス構築、クエリを完全に分離していません。そのため、書き込み操作、特に一括更新において、CPUとI/Oのオーバーヘッドが大きくなります。インデックスの作成とクエリの間のリソースの競合はパフォーマンスに影響し、高頻度の更新シナリオでは大きなボトルネックとなります。

劣悪なリアルタイム・パフォーマンス：ほぼリアルタイム」の検索エンジンであるElasticsearchは、データの可視性に顕著なレイテンシーをもたらします。このレイテンシは、高頻度のインタラクションや動的な意思決定が必要なAgentシステムなどのAIアプリケーションで特に問題となります。

困難なシャード管理：Elasticsearch は分散アーキテクチャのためにシャーディングを使用していますが、シャード管理には大きな課題があります。動的なシャーディングのサポートがないため、小さなデータセットではシャードの数が多すぎるとパフォーマンスが低下し、大きなデータセットではシャードの数が少なすぎるとスケーラビリティが制限され、データの分散が不均一になるというジレンマが生じます。

非クラウドネイティブ・アーキテクチャー：クラウドネイティブアーキテクチャが普及する前に開発されたElasticsearchの設計は、ストレージとコンピートを密に結合しており、パブリッククラウドやKubernetesのような最新のインフラとの統合を制限しています。リソースの拡張には、ストレージとコンピュート両方を同時に増やす必要があり、柔軟性が低下します。マルチレプリカ・シナリオでは、各シャードが独立してインデックスを構築する必要があり、計算コストが増加し、リソース効率が低下する。

ベクトル検索のパフォーマンスの低下Elasticsearch 8.0ではベクトルANN検索が導入されましたが、そのパフォーマンスはMilvusのような専用ベクトルエンジンに大きく遅れをとっています。Luceneカーネルをベースとしたインデックス構造は高次元のデータに対して非効率的であり、大規模なベクトル検索要件に苦戦しています。スカラーフィルタリングやマルチテナンシーを含む複雑なシナリオでは特にパフォーマンスが不安定になり、高負荷や多様なビジネスニーズをサポートすることが困難になる。

過剰なリソース消費：Elasticsearchは、特に大規模なデータを処理する際に、メモリとCPUに非常に大きな負荷をかけます。JVMに依存しているため、頻繁なヒープサイズの調整やガベージコレクションのチューニングが必要となり、メモリ効率に深刻な影響を与えます。ベクトル検索操作にはSIMDに最適化された集中的な計算が必要ですが、JVM環境は理想的とは言い難いものです。

これらの基本的な制限は、組織がAIインフラストラクチャを拡張するにつれてますます問題となり、Elasticsearchを高いパフォーマンスと信頼性を必要とする最新のAIアプリケーションにとって特に困難なものにしています。

Sparse-BM25の導入：レキシカルサーチの再構築

Milvus 2.5では、バージョン2.4で導入されたハイブリッド検索機能をベースに、Sparse-BM25によるネイティブなレキシカル検索のサポートが導入されました。この革新的なアプローチには、以下の主要コンポーネントが含まれます：

Tantivyによる高度なトークン化と前処理
分散語彙および用語頻度管理
コーパスTFとクエリTF-IDFによるスパースベクトル生成
WANDアルゴリズムによる転置インデックスのサポート（Block-Max WANDとグラフインデックスのサポートを開発中）

Elasticsearchと比較して、Milvusはアルゴリズムの柔軟性において大きなアドバンテージがある。ベクトル距離ベースの類似度計算により、"End-to-End Query Term Weighting "研究に基づくTW-BERT（Term Weighting BERT）の実装を含む、より洗練されたマッチングが可能です。このアプローチは、ドメイン内テストとドメイン外テストの両方で優れた性能を実証している。

もう一つの重要な利点は、コスト効率である。Milvusは転置インデックスと高密度埋め込み圧縮の両方を活用することで、1%未満の想起低下で5倍の性能向上を達成している。テールタームの刈り込みとベクトルの量子化により、メモリ使用量は50%以上削減された。

長いクエリの最適化は、特に強みとして際立っている。従来のWANDアルゴリズムが長いクエリで苦戦するところ、Milvusはスパース埋め込みとグラフインデックスを組み合わせることで優れており、高次元のスパースベクトル検索シナリオで10倍の性能向上を実現している。

Milvus: RAGのための究極のベクトルデータベース

Milvusは、その包括的な機能セットにより、RAGアプリケーションのための最高の選択肢です。主な利点は以下の通りです：

動的スキーマ機能と強力なフィルタリングオプションによる豊富なメタデータのサポート
コレクション、パーティション、パーティションキーによる柔軟な分離が可能なエンタープライズグレードのマルチテナンシー
メモリからS3までの多階層ストレージによる業界初のディスクベクトルインデックスのサポート
10Mから1B以上のベクターへのシームレスなスケーリングをサポートするクラウドネイティブなスケーラビリティ
グループ化、範囲指定、ハイブリッド検索を含む包括的な検索機能
LangChain、LlamaIndex、Dify、その他のAIツールとの深いエコシステム統合

このシステムの多様な検索機能は、グループ化、範囲指定、ハイブリッド検索の手法を網羅しています。LangChain、LlamaIndex、Difyのようなツールとの深い統合、および多数のAI製品のサポートにより、Milvusは最新のAIインフラストラクチャのエコシステムの中心に位置しています。

今後の展望

AIがPOCから本番へと移行する中、Milvusは進化を続けています。私たちは、検索品質を向上させながら、ベクトル検索をよりアクセスしやすく、費用対効果の高いものにすることに注力しています。新興企業であれ、大企業であれ、MilvusはAIアプリケーション開発の技術的障壁を軽減します。

このアクセシビリティとイノベーションへのコミットメントにより、私たちはまた新たな大きな一歩を踏み出しました。当社のオープンソース・ソリューションは、世界中の何千ものアプリケーションの基盤として機能し続けていますが、多くの組織が、運用のオーバーヘッドを排除するフルマネージド・ソリューションを必要としていることを認識しています。