MultiVectorEncoder とは:マルチベクトル検索の索引は何倍になるか

この記事は海外の一次情報をAIエージェントが調査・検証して整理したもので、実際に試した体験談ではありません。

結論:「約42倍」の比較相手は DenseOn ではない

Hugging Face 公式ブログ『Multi-Vector (Late Interaction) Embedding Models with Sentence Transformers』(2026年8月18日、著者 Tom Aarsen・Antoine Chaffin・Raphael Sourty)の実測によると、Natural Questions の4,874パッセージをマルチベクトルの lightonai/LateOn で符号化した非圧縮インデックスは311.5MB、dense の all-MiniLM-L6-v2 は7.5MB、その比が「約42倍」です。

同じブログの精度比較は、比べている相手が別のモデルです。以下の数値はすべて Hugging Face と LightOn による発表であり、第三者による再現は2026年8月24日時点で確認できていません。

比較の種類	比べている2つ	原典の数値
精度(NanoBEIR平均NDCG@10)	LateOn 対 DenseOn	0.6868 対 0.6764
インデックスサイズ	LateOn 対 all-MiniLM-L6-v2	311.5MB 対 7.5MB

原典のインデックスサイズ表に DenseOn の行はありません。したがって「精度0.0104のためにストレージ42倍を払う」という形の比較は、原典には存在しない読み方になります。

Sentence Transformers v6.0 の MultiVectorEncoder とは

sentence-transformers v6.0.0 のリリースは2026年8月18日です(GitHub と PyPI の記録が同日で一致)。開発チームの説明では、MultiVectorEncoder は SentenceTransformer / CrossEncoder / SparseEncoder に次ぐ4番目のモデルクラスで、PyLate と Stanford-NLP ColBERT のチェックポイントはそのまま読み込めるとされています。

精度の数値は2つの別々の表から来ている

モデル	出典の表	NanoBEIR平均NDCG@10
lightonai/LateOn	LateOn対DenseOn比較表	0.6868
lightonai/DenseOn	LateOn対DenseOn比較表	0.6764
lightonai/GTE-ModernColBERT-v1	対応モデル一覧	0.6720
lightonai/colbertv2.0	対応モデル一覧	0.6201
colbert-ir/colbertv2.0	対応モデル一覧	0.6053

指標はいずれも13データセットの NanoBEIR 平均 NDCG@10 で同じですが、上2行と下3行は別の表です。LateOn と DenseOn は学習データもバックボーン(ModernBERT)もパラメータ数(149M)も揃えた対で、違いはベクトルをトークンごとに残すか文書ごとに畳むかだけだと原典は説明しており、13データセット中9で late interaction 側が上回ったとしています。なお colbertv2.0 は colbert-ir/ と lightonai/ の2リポジトリが別の行として載っているため、リポジトリ名まで書かないと取り違えます。原典自身が、NanoBEIR は小さなベンチマークであり自分のデータでの評価の代わりにはならないと注記しています。

インデックスサイズは何MBになるか

原典が示した Natural Questions 4,874パッセージの float32 インデックスは次のとおりです。LateOn では608,414本のトークンベクトルが生成され、1パッセージ平均は124.8本と記載されています。

表現	ベクトル数	次元	float32サイズ
Dense, all-MiniLM-L6-v2	4,874	384	7.5MB
Dense, gte-modernbert-base	4,874	768	15.0MB
Multi-vector, LateOn	608,414	128	311.5MB

圧縮後のサイズは一次資料どうしで食い違っている

同じ608,414ベクトルを fast-plaid(PLAID)形式で保持したときのサイズは、公式ブログでは92MB、同日公開の v6.0.0 リリースノートでは88MBです。2026年8月24日時点でどちらかを訂正した公式の記述は確認できません。PLAID はベクトルそのものではなく重心IDと量子化された残差を持つ形式で、311.5MBがおよそ3.4〜3.5分の1(90MB前後)まで落ちる点は両文書とも同じですが、見積もりに使える単一の確定値はない、というのが現状です。

pool_factor ごとの削減率と、その品質コスト

削減の手段は HierarchicalTokenPooling です。原典の説明では、クラスタリングにコサイン類似度の Ward 法を用い、各クラスタをその平均ベクトルで代表させることで、残るベクトルはおおよそ 1/pool_factor 本になります。適用先は既定で文書側のみ、608,414本の処理時間は約6秒と記載されています。

pool_factor	トークンベクトル数	削減	float32インデックス
1(オフ)	608,414	1.00倍	311.5MB
2	305,438	1.99倍	156.4MB
3	204,407	2.98倍	104.7MB
4	153,936	3.95倍	78.8MB

品質側の数値は出どころが違います。100.6%(pool_factor=2)と99.0%(pool_factor=3)という未プーリング比の検索性能は、原典が引用している元論文(arXiv:2409.14683v1)の BEIR での測定値であり、上の表と同じ Natural Questions で測り直したものではありません。原典も、コストはコーパス依存であるため係数を決める前に評価器で測るよう促しています。

ベクトルDBの参考計測値

同じ4,874文書・608,414トークンベクトルを投入したときの時間として、原典は次の値を挙げています。1台のマシン(RTX 3090 / i7-13700K)でコードに書かれた以上のチューニングをしていない参考値であり、製品間のベンチマークではないと原典自身が断っています。

実装	取り込み	クエリ
fast-plaid	5秒(索引作成)	11ms
Qdrant	26.3秒	18ms
Weaviate	41秒	17ms
Vespa	約80秒	約75ms(初回約115ms)

Qdrant の18msには原典自身が但し書きを付けています。4,874文書での全走査は厳密だがこの値は外挿できない(that doesn’t extrapolate)というもので、あわせて Qdrant 側が全走査ではなく数百件の再ランク付けに使うことを勧めている点も紹介されています。大規模コーパスの応答時間の根拠にはできません。

注意点:値がモデルごとに違う仕様

項目	原典の記述
document_length	上限を超えた部分は索引に入らない。LateOn は300で、662トークンのパッセージは273ベクトルになる
モデル別の上限	colbert-ir/colbertv2.0 は180、lightonai/GTE-ModernColBERT-v1 はクエリ48・文書300
attend=False	colbert-ir/colbertv2.0 や answerdotai/answerai-colbert-small-v1 は読み込み時に Flash Attention を拒否するため `"sdpa"` を使う
MaxSim のスコア	クエリトークン数にわたる和のため、処理方式が違うモデル間ではスコアを比較できない
保存互換	一方向。PyLate・Stanford-NLP ColBERT・colpali-engine のチェックポイントは読み込めるが、`MultiVectorEncoder.save_pretrained` の出力はそのいずれでも読み込めない。ただし colpali-engine 独自形式は、読み込む前にリポジトリ側へ設定の追加が必要と原典は述べている

原典は、境界のあるスケールが必要なら similarity_fn_name="meanmaxsim"([-1, 1] の平均コサイン類似度)を使えると述べており、document_length の上限を1回の呼び出しで引き上げる手段も併記しています。

同じ系列のモデルは日本語ラベルを学習に使っていない多言語検索モデルの記事で、公開ベンチマークの数値がそのまま実力比較にならない論点はNIST の隔離データ評価 AITE の記事で整理しています。本記事の数値と引用は2026年8月24日に原典で照合しました。