Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 既定値が変わったという事実から
HNSWの本当のコストは計算ではなくRAMだ
BBQはRaBitQから何を持ってきて何を捨てたか
- 32倍が32倍ではない理由
DiskBBQが実際にすること
正直な限界 — 95%の壁、そしてライセンス
ベンチマーク戦争 — そして眠っていたディスク
- この事件から持ち帰るべきこと
だからいつ使い、いつ使うべきでないか
おわりに
参考資料

はじめに — 既定値が変わったという事実から

ベクトル検索の話は、たいてい埋め込みモデルやRAGパイプラインから始まります。本稿はその下の層、インデックスそのものについての話です。そして出発点は論争ではなく、ただの一つの事実です — Elasticsearchのベクトルフィールドの既定インデックスタイプが変わりました。

dense_vector公式リファレンスの既定値表はこう流れます。

9.0 — floatベクトルは全部int8_hnsw。
9.1以降 — 384次元以上はbbq_hnsw、384次元未満はint8_hnsw。
9.4以降およびServerless — ドキュメントの文をそのまま移すと、floatまたはbfloat16ベクトルを索引する際、「現在のライセンスで利用可能な場合、既定のインデックスタイプはbbq_disk」です。

バージョンの日付をつけると、この移行がどれほど速いかが見えます。9.1は2025-07-23、9.2は2025-10-21、9.4.0は2026-05-05に出ました(endoflife.dateとelastic/elasticsearchのリリースタグによる。本稿執筆時点の2026年7月現在、最新リリースは9.4.3です)。つまり1年足らずの間に、既定値はスカラー量子化グラフ → 二値量子化グラフ → グラフですらないディスクインデックスへと二度移り変わりました。

最後の段階が重要です。bbq_diskはHNSWではありません。IVF(転置ファイルインデックス)系であり、検索構造がRAMではなくディスクに住みます。ほぼ20年続いた「近似最近傍検索 = グラフインデックス」という常識を、少なくとも既定値の座については覆したわけです。なぜそうなったのか、そしてその代償は何なのかが本稿の内容です。

HNSWの本当のコストは計算ではなくRAMだ

HNSWの魅力は明らかです。データに対して対数スケールで拡張する、速く計算効率の良いアルゴリズムです。DiskBBQ紹介記事(Benjamin Trent、John Wagster、Ignacio Vera Sequeiros、2025-10-23)の最初の段落も「We absolutely love HNSW」から始まります。

ところが同じ記事がすぐに代償を指摘します。HNSWがきちんと動くにはすべてのベクトルがRAMになければなりません。量子化でこのコストを下げ続けてきましたが、ベクトルがメモリの外へ押し出された瞬間に性能が急落する問題は残ります。さらに、あまり知られていない二つ目のコストがあります — 索引を作るには既存のHNSWグラフを探索する必要があるため、RAMコストは検索時だけでなく索引時にもそのまま発生します。

ここでのキーワードは「急落」です。性能が緩やかに悪化するのではなく、崖から落ちます。Elasticがこれを数字で示したのが低メモリベンチマーク(John Wagster、2025-10-23)です。

測定条件 — ベンダー自己測定です。 100万ベクトル、既定のマージポリシーで約12セグメント、両方式ともBBQ 1ビット量子化を適用、両設定をrecall約0.89に合わせています。Elasticsearch内蔵のKnnIndexTesterユーティリティをDockerコンテナに隔離し、swapを切ったうえでコンテナ全体のメモリを制限する方式です。表記はコンテナRAM / JVMヒープです。

RAM / ヒープ	DiskBBQ 遅延	HNSW BBQ 遅延
101m / 10m	15.83ms	実行不可
150m / 100m	12.13ms	289.7ms
250m / 150m	7.46ms	26.81ms
350m / 250m	3.65ms	7.7ms
450m / 350m	2.38ms	3.06ms
550m / 450m	2.41ms	3.14ms

550m帯では両者はほぼ同じです(2.41対3.14)。メモリが潤沢ならこの論争自体が成り立たないということです。しかし下に行くほど差が開きます。250mで3.6倍、150mでは24倍の差が出ます。Elasticの表現では、DiskBBQは緩やかに劣化する(degrades gracefully)のに対し、HNSW BBQはメモリが極端に制限されるとそのまま崩壊します(falls apart)。

索引の側はもっと劇的です。同じ記事の索引時間表では、HNSW BBQは1g / 850m以下の帯でまったく完了できませんでした(550m、750m、1gの三帯すべて測定値なし)。DiskBBQは同じ1g / 850mで82,397msで索引を終えました。これが先に述べた「索引時にもグラフを探索する必要がある」という性質の実物です。

底がどこかも興味深い点です。著者はヒープを10MBまで下げて測定しましたが、それより下ではlog4jの初期化が失敗し、それ以上は下げられなかったといいます。コンテナ全体では101MBで動作し、それより下ではOSがSIGKILL(exit 137)を送ります。参考までに、同じopenjdk:24-jdk-slim-bookwormコンテナでHelloWorldを一行動かすだけでも50MBが必要です。つまりDiskBBQは100万ベクトルを、実質60MB程度の余裕空間で15.83msに応答したことになります。

このベンチマークが語らないこと。 正直に言うと、この記事はどのデータセットを使ったか、何次元かを本文で明示していません。100万ベクトルという一つの規模、一台のマシンでの測定であり、recallも0.89という一点に固定されています。方向性(HNSWにはメモリ崖があり、IVFにはない)はアルゴリズムの構造から出てくるものなので信頼できますが、この表の絶対値をあなたのコーパスにそのまま持ち込んではいけません。

BBQはRaBitQから何を持ってきて何を捨てたか

bbq_diskのBBQから整理する必要があります。ここが本稿でもっとも知られていない部分です。

BBQ(Better Binary Quantization)はElasticsearch 8.16とLuceneに導入されました(Benjamin Trent、2024-11-11)。その記事は出所を明確にしています — シンガポールの南洋理工大学(NTU)の研究陣が提案したRaBitQという手法から得た知見をもとに開発した、と。

RaBitQ論文(Jianyang Gao、Cheng Long、SIGMOD 2024)の核心的な主張はこうです。D次元ベクトルをDビット文字列に量子化しつつ、明確な理論的誤差限界を保証すること。論文の問題意識は、PQ(直積量子化)系が経験的にはうまくいくものの理論的誤差限界がなく、実データセットで失敗しうるという点でした。つまりRaBitQのセールスポイントは圧縮率ではなく保証です。

ここで重要な箇所。ElasticのBBQ記事は、原著者の提案との違いを自ら列挙しています。その二番目の項目をそのまま移すと — コードブックを無作為回転(random rotation)しないため、推定量がアルゴリズムの複数回の呼び出しにわたって不偏(unbiased)である性質を持たないと書かれています。

これが意味するのは、RaBitQが理論的保証を得る機構こそがまさにその無作為回転であり、BBQはHNSWとの単純な統合と速い索引作成のためにそれを外した、ということです。列挙された違いは五つです。

中心点(centroid)を一つだけ使用 — HNSWと単純に統合し、索引を速くするため。
コードブックを無作為回転しない → 推定量の不偏性を失う。
再点数付け(rescoring)が推定量子化誤差に依存しない。
再点数付けをグラフ索引探索中に行わず、初期推定ベクトル計算の後に回す。
内積(dot product)を完全に実装・サポート。原著者はユークリッド距離のみに集中しており、内積は言及されただけで実装・測定はされていない。ベクトルの大きさが重要になるmax-inner-productもサポート。

つまりBBQはRaBitQではありません。 論文の理論的保証をエンジニアリング上の利便性と引き換えにした派生物です。この事実自体は欠点ではありません — Elasticがこれを自らブログに書き残している点は、むしろ評価に値します。ただし「RaBitQベースだから理論的誤差限界がある」という形でBBQを紹介する二次資料に出会ったら、それは誤った説明です。

そして面白い後日談があります。9.4でpreconditionというパラメータが追加されましたが、リファレンス文書の説明はこうです — trueにすると、索引されたベクトルを無作為直交射影(random orthogonal projection)で変換し、ベクトル成分が正規分布に従わない場合に精度改善に役立つことがある。既定値はfalseで、フィールド作成後は変更できません。2024年に外された無作為回転が、2026年にオプトインのスイッチとして戻ってきたわけです。

32倍が32倍ではない理由

圧縮率についても一度正直に見ておきましょう。BBQリファレンス文書は、BBQがfloat32の次元をビットに変えて各ベクトルを32倍に圧縮する一方で、ベクトルごとに14バイトの補正データが追加で付くと記しています。

計算してみると、1024次元ベクトルで1024ビットは128バイト、これに補正14バイトを足すと142バイトです。元は4096バイトなので、実際の比率は約29倍です。実際にJina v5埋め込み測定記事(Jeffrey Rengifo、2026-07-10)の表がちょうどこの数字を使っています — bbqは次元あたり約0.14バイト、1024次元で142バイト、約29倍。

さらに重要なのはディスクは減らないという点です。同じJina記事は、二つのインデックスのディスク使用量がほぼ同じだったと報告しています。量子化ベクトルを載せても、原ベクトルは再点数付け用にそのまま残るからです。dense_vector文書も、量子化・原本を一緒に保存するオーバーヘッドでディスクがint8は約25%、int4は約12.5%、bbqは約3.1%増えると記しています。32倍はRAMの話であって、ストレージの話ではありません。

Jina記事の見出し数字も条件をつけて読む必要があります。recall@10がfloat32基準線に対して0.994に保たれたといいますが(ベンダー自己測定、5言語の多言語ニュースコーパス、jina-embeddings-v5-text-small、1024次元)、記事自身がその理由を明かしています — Jina v5が量子化認識学習(quantization-aware training)を経たモデルだからです。つまり1ビット量子化に合わせて訓練されたモデルの数字であって、どんな埋め込みモデルにも移植できる結果ではありません。そしてメモリが12.71MBから0.44MBに減ったという数値の絶対規模を見てください。12MBはデモサイズです。

DiskBBQが実際にすること

次はディスク側です。DiskBBQはIVFインデックスの進化形で、動作はこうです。

階層的K-meansでベクトルを小さなクラスターに分割します。文書によればcluster_sizeの既定値はクラスターあたり384ベクトルで、64から65536の間で調整できます。小さいほど精度が上がり性能が落ちます。
クエリが来ると代表中心点からまず探し、階層の多層構造を活用して最大2層の中心点だけを探索し、探索空間を制限します。
選ばれたクラスター内のベクトルをバルクスコアリングします。ベクトルがBBQで細かく圧縮されているので、一度に複数ブロックをメモリに載せて速くスコアを付けられ、この演算の大半はオフヒープで行われます。
ベクトルを複数の中心点に重複割り当てします。GoogleのSOAR(Spilling with Orthogonality-Amplified Residuals)の変種を使い、ベクトルが二つのクラスターの境界にあるとき特に役立ちます。ベクトルが非常に強く圧縮されているのでディスクオーバーヘッドはわずかで、代わりに探索すべき中心点の数が減ります。

クエリ時点のつまみはvisit_percentageです。シャードあたり訪問するベクトルの割合を決め、下げるとメモリと遅延が減り、上げるとrecallが上がります。マッピング側default_visit_percentageの既定値は、文書によれば100万ベクトルあたりシャードごとに約1%の水準です。

量子化は非対称です。基本的に索引ベクトルは1ビット、クエリベクトルは4ビットで量子化します。クエリ側によりビットを使うのは、保存コストが増えないまま検索品質が大きく上がるからです。9.4からbbq_diskに限り、索引ベクトルのbitsを1(既定)、2、4、7に変更でき、オーバーサンプリング係数が自動的に付いてきます — 1ビットなら3.0倍、2ビットなら1.5倍、4ビットと7ビットならオーバーサンプリングなし。これは再索引なしにいつでも変更できます。

メモリが十分な場合の比較も同じ紹介記事にあります。ベンダー自己測定、100万ベクトルが全部メモリに収まる条件です。

方式	索引時間	遅延	recall
HNSW BBQ	1,054,319ms	約3.4ms	92%
DiskBBQ	94,075ms	約4.0ms	91%

読み方はこうです。HNSWにもっとも有利な条件(全部RAMにある)でも遅延差は3.4対4.0とさほど大きくないのに、索引は11倍以上の差が出ます。グラフを構築するコストはそれだけ高いのです。Elasticも「あらゆる状況で100%追いついたわけではない」と記しています。

正直な限界 — 95%の壁、そしてライセンス

ここが本稿でもっとも重要な節です。

第一に、recallの天井があります。 BBQリファレンス文書の文をそのまま移すと、DiskBBQは通常約95%までのrecall水準でよく動作します。例外的に高いrecall(99%以上)が必要な場合には多くのクラスターを訪問する必要があり、これは性能に悪影響を与えることがあります。そうした場合はメモリ状況によってbbq_hnswのようなHNSW系のほうが良いとされます。

紹介ブログも同じことをもっと直截に言っています。非常に高いrecallが必要で、オフヒープメモリが潤沢か、そのコストを払う意志があり、索引更新が稀であれば — 量子化を伴ったHNSWが依然として最善である可能性が高い。逆に95%以下のrecallで十分で、コストに敏感で、それでも速い検索を望むならDiskBBQが答えになりうる。

これはアルゴリズムの構造から来る限界なので、チューニングでなくせる種類のものではありません。IVFはクラスター単位で枝刈りをし、最後の数%のrecallを得るには結局枝刈りをあきらめてどんどん多くのクラスターを開かなければなりません。その地点でIVFの利点は消えます。

第二に、既定値がライセンスに紐づいています。 dense_vector文書はbbq_diskがEnterpriseサブスクリプションを必要とすると明記しています。そして9.4の既定値の文には「現在のライセンスで利用可能な場合」という条件が付いています。

実務的にこの文の重みを見ておきましょう。同じマッピングJSONが、ライセンス等級によって異なるインデックスタイプを作ります。 index_optionsを省略したまま9.4クラスター二台に同じ定義を載せると、Enterprise側はディスクIVFを、それより下の等級はbbq_hnswを作ります。メモリプロファイルも、recall特性も、索引速度も異なるインデックスができるのに、マッピングは同じ見た目です。開発環境と本番環境でライセンスが違うと性能が再現されない理由は、ここに隠れていることがあります。既定値に頼らずindex_options.typeを明示するのが安全です。

第三に、細かいが実在する制約群。 bbq_diskはelement_typeがfloatまたはbfloat16の場合のみサポートします。byteとbitは対象外で、これらのタイプはすべてのバージョンで量子化なしのhnswが既定です。preconditionはフィールド作成後に変更できません。そして384次元未満のデータセットは精度が出にくく補正係数のオーバーヘッド比率が大きくなりうる、というのがBBQ文書の警告です(ただしe5-smallのような低次元でもうまく動いたプロダクション事例を見たとも付け加えています)。

参考までに、文書上auto_calibrateという機能が9.5 GAとして予告されています。マージ時点でセグメントごとに最大17,000ベクトルをサンプリングし、k=10で90% recall目標を満たす最も安い設定(量子化エンコーディング5種、再順位付け深さ倍率6種、プリコンディショニング適用/未適用)を自動的に選ぶ方式です。ただし本稿執筆時点の最新リリースは9.4.3なので、これはまだ文書だけにある予告編として読むべきです。

ベンチマーク戦争 — そして眠っていたディスク

次は2026年夏の出来事です。この話が面白いのは結論よりも方法論のためです。

発端はElasticが2026-06-24に出した記事(Sachin Frayne)の主張でした — ネットワーク接続ストレージ(NAS)でDiskBBQがQdrantより最大7倍高いスループットを出す。recall 0.93〜0.97の区間で差が一貫しており、recallが上がるほど広がるという主張で、原因として再点数付け中の原ベクトルのランダムディスク読み取りを指摘しました。このメカニズムを覚えておいてください。後で撤回されるのがまさにこの部分です。

Qdrantは自分側の数字と説明で反論しました。io_uringベースの非同期ディスクスコアラーがあり、Elasticsearchはメモリをより多く食うという指摘でした。

そして2026-07-13、Elasticのジム・フェレンツィ(Jim Ferenczi)が反論への反論を出しましたが、これは普通のベンダー反撃文ではありません。記事のルールをこう宣言します — すべての主張には数字とメカニズムが伴わなければならず、なければ載せない。 そしてその物差しを自分の元記事にも当てはめます。

Qdrantの設定をそのまま自分のクラスターに立て(2100万ベクトル、3 × m6g.large = 2 vCPU / 8GB、AWS、固定1万クエリ、recall@100)、結果を再現したうえですべての数字を原因まで追跡しました。結論から言うとこうです。

1. io_uringは何もしていませんでした。 まず面白い発見があります。Dockerで Qdrantを動かすと、io_uringがそもそも初期化されていませんでした — 既定のseccompプロファイルがio_uringシステムコールを塞ぎ、静かに同期読み取りにフォールバックしていたのです(ログ: failed to initialize io_uring instance: Operation not permitted)。seccompを緩めてきちんと有効化してから再測定した結果はこうです。

非同期スコアラー事実上オフ(同期フォールバック): ef=50で31.6 QPS
非同期スコアラーオン(io_uring動作確認済み): ef=50で35.8 QPS

13%の差であり、記事の表現ではそれすら実行間ノイズの範囲内です。結果全体の手柄とされた機能をオンにしてみたら、ベンチマークをもう一度回した程度しか動かなかったという話です。

2. 理由はディスクを一度も読んでいなかったからです。 これがこの記事の白眉です。スループット測定区間の間、三ノードのブロックデバイスをiostatで見張った結果、読み取りスループットは0 MB/s、0 IOPSを保ち、CPUは60〜70%で、同時実行数を上げると100%まで上がりました。ボトルネックは量子化距離計算とグラフ巡回を行うCPUでした。

なぜディスクを読まなかったのか。封筒裏の計算が答えをくれます。再点数付けはクエリごとに上位100候補を読み、768次元float32ベクトルは3,072バイトですが、ページ整列がされていないため実質8KBページ読み取りに近くなります。すると総作業集合は100個 × 1万クエリ × 8KB = クラスター全体で8GB、ノードあたり2.7GBです。8GBノードのページキャッシュに余裕で収まります。しかも測定ハーネスは1万クエリでrecallパスを一回全部回したあと、同じ1万クエリでスループットを測ります。記事の表現どおり、測定は構造的にすでに温まっています(warm by construction)。

3. 数字を実際に動かしたのはセグメント数でした。 Elasticの最初の再現は128セグメントとなり、期待の半分ほどのスループットでした。Qdrantが公開した結果JSONには67セグメントと記されていました。セグメントを併合して合わせると、三つの指標が一緒に動きました。

セグメント	recall@100	QPS	平均遅延
128(並列ロード、Elastic最初の試み)	0.9745	35.8	112ms
66(Qdrantに合わせて併合)	0.9531	53.3	75ms
67(Qdrant公開値)	0.9596	67.2	59.5ms

この表の読み方が重要です。セグメントが減るとrecallが下がります。クエリごとに調べる候補の総量が減るためです。同時にスループットは上がります。クエリがすべてのセグメントのグラフへファンアウトするため、セグメントが二倍ならクエリごとの作業もほぼ二倍になるからです。つまりElasticの最初の試みでrecallが高く出たのは、チューニングが良かったからではなく、セグメントが多かったからでした。

ところがセグメントを少なく作る方法は単一スレッドでゆっくりロードすることです。速いクエリを遅いロードで買っているわけです。そしてこれこそがIVFとHNSWが本当に分かれる地点だと記事は指摘します。HNSWグラフ構築は高価で(2 vCPUノードでef_construct=256のとき約1.6時間、CPU 100%張り付き)クエリコストがセグメント数に敏感な一方、bbq_diskの背後にあるIVFレイアウトは構築が安く、セグメント数にはるかに鈍感です。記事の表現では「ベンチマークトリックではなく、正直に述べられたIVF対HNSWのトレードオフ」です。

4. そして自分のコストも数えます。 Elastic側の遅延のかなりの部分は、ベクトル検索ではなく応答を組み立てるフェッチ段階でした。現在_idが_source・本文・ベクトルと同じストアドフィールドの列に住んでいるため、idを一つ取得するためにその圧縮ブロック全体を解凍器に通します。idをその列から分離して測定すると、Qdrantの低セグメントスループット帯にそのまま上がりました。記事の文をそのまま移すと — その格差は文書検索であって、ベクトル検索ではありません。

訪問%	recall@100	QPS(既定)	QPS(id分離)
1	0.894	44	89
2	0.939	39	73
3	0.956	35	56
5	0.970	31	40

recall約0.96でidを分離したElasticsearchは約56 QPSとなり、同じハードウェアでQdrantの53〜67と同じ帯に座ります。

5. 最後に、自分の元記事の7倍を撤回します。 正確には数字ではなくメカニズムを撤回します。7倍という数値はその設定では本当ですが、元記事がその数字に付けた説明(再点数付け中の原ベクトルのランダムディスク読み取りがQdrantのボトルネックで、NASがそれを悪化させた)は同じ算数を通らないというのです。1ラウンド目のノードはRAMが26GBで、今回の8GBノードより余裕があったので、8GBでディスクが遊んでいたなら26GBでもほぼ確実に遊んでいたはずだ、という論理です。では1ラウンド目のQdrantがなぜ0.97 recallで4.5 QPSにとどまったのかは? 記事は分からないと認め、仮説だけを添えます(2ビット量子化でオーバーサンプリングを1に固定していたため、recallを上げるつまみはefしかなく、非常に大きなef自体がクエリを高くつけていた)。

この事件から持ち帰るべきこと

もっとも重要な文は結論部にあります。2100万ベクトルを8GBノードに載せると、どの設計であれ全部RAMに収まってしまい、だからこのベンチマークは二つの設計を区別できません。 面白い変数を定数に固定したまま測定していたわけです。

つまりディスクベースのインデックスを、ディスクが要らない規模で測定したベンチマークだったということです。Qdrantの設定は4ビットベクトルをalways_ramに固定し、HNSWグラフをRAMに置きますが、2100万ベクトルでノードあたり約3.6GBです(計算: 4ビット量子化384バイト/ベクトル=2.69GB、m=16のHNSWグラフ136バイト/ベクトル=0.95GB、合計520バイト/ベクトル=3.64GB。実測の常駐メモリは3.4〜3.9GBで、推定値にほぼ正確に座りました)。8GBノードに3.6GBなら余裕があります。bbq_diskが設計された領域は量子化ベクトルと検索構造がページキャッシュを超える瞬間なのに、両記事のどちらもそこを測定していません。Elasticはこれを認め、インデックスがRAMに収まらない規模のベンチマークを作っているところだと記しています。

そしてこの記事自体も依然としてベンダー自己測定です。方法論は異例なほど正直ですが、結論は依然として「速い既定経路ではElasticsearchが索引も検索もより速い」です。Qdrant側の再現はQdrantの再現スクリプトを使ったと明かしていますが、相手エンジンのチューニングは自分のエンジンのチューニングより浅くなりがちです。4 vCPU / 16GB帯は「両エンジンを一緒に持ち上げて同じ傾向を示すだけで、洞察なしにコストだけ増える」という理由で意図的に回さなかったと述べていますが、合理的な判断である一方、検証されていない主張であるのも事実です。

それでもこの記事が残した教訓は、ベンダー所属とは無関係に有効です。記事自身の要請をそのまま移すと — ベンチマークがきれいな倍数を差し出すとき、その話を信じる前にすべての数字を原因まで追いかけよ。半分は温まったキャッシュか、セグメント数だ。

だからいつ使い、いつ使うべきでないか

bbq_diskが値を持つ場合

量子化ベクトルと検索構造を合わせたサイズが、ノードのRAM・ページキャッシュを超える規模である。これが唯一の本当に重要な条件です。超えないならこの論争はあなたのものではありません。
recall 95%以下で製品要件が満たされる。
索引・更新が頻繁である。HNSWのグラフ構築コストとセグメント感度が痛い点です。
コストに敏感である。RAMはベクトル検索でもっとも高価な資源です。
埋め込み次元が384以上である。

HNSW系にとどまるべき場合

recall 99%以上が必要である。文書が直接ほかの方式を勧めています。
遅延が極端にタイトである。
インデックスが楽にRAMに収まり、そのRAMをすでに持っているか買う意志がある。
索引がほとんど更新されない。グラフ構築コストを一度だけ払えばよいからです。
Enterpriseサブスクリプションがない。この場合、選択肢自体がありません。
byteやbitのelement typeが必要である。bbq_diskは対応していません。

もう一つ。フィルタリングされたベクトル検索が主なワークロードなら、別の軸を見る必要があります。Elasticsearch 9.1はフィルタをHNSWグラフ巡回に直接統合するACORN-1アルゴリズムを導入し(2024年発表の学術論文に基づく)、Elasticは典型的には5倍の速度向上を報告しています — これはHNSW側の話です。フィルタ選択度が低いワークロードでIVF系がどう振る舞うかは、これらの記事が扱わないテーマであり、自分で測る必要があります。

おわりに

まとめるとこうです。Elasticsearchは2026年5月の9.4で、floatベクトルの既定インデックスをディスクベースのIVFに変えました。この決定の背後には一つの判断があります — ベクトル検索で本当に高価な資源はCPUではなくRAMであり、HNSWはRAMが足りないとき緩やかに悪化するのではなく崖から落ちる、というものです。

代償は明確です。recall 95%前後の天井があり、それはIVFの構造から来るのでチューニングではなくせません。そしてその既定値はEnterpriseライセンスの後ろにあり、同じマッピングがライセンスによって異なるインデックスを作ります。

BBQ自体も正直に見る必要があります。RaBitQ論文の知見から生まれましたが、論文のセールスポイントだった理論的誤差限界を得る無作為回転を外して始まりました(そして9.4でオプトインとして一部戻しました)。32倍圧縮はRAMの話であり、ディスクはむしろ3.1%増えます。

最後に、2026年夏のベンチマーク公方が残したものがもっとも実用的です。ディスクベースのインデックスを自慢するベンチマークで、ディスクは0 IOPSで眠っており、非同期I/Oは13%しか動かず、真犯人はセグメント数と_idフェッチでした。そしてElastic自らが認めたとおり、二つの設計が分かれる地点を測定したベンチマークはまだ誰も書いていません。

だから結論はいつも同じ場所に戻ります。あなたのインデックスがRAMに収まるかどうかからまず測ってください。収まるなら、この記事の大部分はあなたの問題ではありません。収まらなくなり始めたとき — そのときがディスクインデックスを取り出す時点であり、そのときも他人のベンチマークではなく、あなたのコーパスとあなたのrecall目標で測るべきです。