Hugging FaceがMultiVectorEncoderを追加。AI検索は全文要約から付せん照合へ

厚い資料を一枚に丸めない

厚い資料を一枚のメモにしたら、何が消えるでしょうか。まず、細かな条件が消えます。

AI検索でも同じことが起きます。Hugging Faceは2026年8月18日、Sentence Transformers v6.0にMultiVectorEncoderを追加したと発表しました。

これは、文書を一枚のメモへ圧縮しすぎないための更新です。検索AIが細部を持ったまま探せるようになります。

付せんが一語ずつ答えを探す

Dense embedding（文書を1本の数値表現にする方式）は、文章を384、768、1024個ほどの数字へまとめます。これは速くて扱いやすい方法です。

ただ、要約がうまいほど、細かな条件は混ざります。製品コード、姓、条文番号のような小さな違いが薄くなります。

Multi-vector（1文書を複数の数値表現で持つ方式）は、トークン（単語に近い細かな単位）ごとにベクトルを残します。文書に付せんを貼るように、場所ごとの手がかりを残します。

採点にはMaxSim（質問の各語に一番近い文書部分を足す方式）を使います。細部の条件が、平均の中に沈みにくくなります。

たとえば、緑のソファ、木の脚、丸いクッションという条件があります。一本の要約では、色も脚も形も混ざります。

Multi-vectorなら、色、脚、形が別々に証拠を探せます。検索は、全体の雰囲気だけで決まりません。

よく当たる検索ほど荷物が増える

この方式の代金は、サービス料金ではありません。保存容量と処理の重さです。

発表のNatural Questions例では、4,874 passagesから608,414個のtoken vectorが作られました。平均では1 passageあたり124.8個です。

MiniLMのdense索引は7.5MBでした。Multi-vectorのLateOnは311.5MBです。

ただし、token pooling（似たトークンをまとめる圧縮）も用意されています。pool_factor 2では、608,414個が305,438個になりました。

全部を読むより、候補だけを読む

実務では、全部を精密に読まなくても成り立ちます。発表は、候補を絞ってから詳しく見る形も示しています。

先に通常のdense検索で候補を集めます。その後にMultiVectorEncoderが上位50件を再採点します。

これはcross-encoder（質問と文書を同時に読む高精度方式）の役割に近いです。Multi-vectorは、候補ごとの計算を軽くできます。

入口は速く、最後の判定は細かい。この組み合わせが、現場の検索システムに入りやすい形です。

画像も音声も、同じ考えで探す

広がりは文章だけではありません。ColPali-styleのvisual document retrieval（画像の文書を検索する方式）にも同じAPIが使われます。

ページ画像は、URL、ローカルパス、PIL画像として渡せます。OCR（画像内の文字を読み取る処理）を挟まずに探せます。

発表の画像例では、1ページが755個のtoken vectorになりました。質問側は25個です。

Sentence Transformersは、checkpoint（学習済みモデルの保存物）次第でテキスト、画像、音声、動画を扱えます。資料の種類が混ざる場面に向いた発想です。

公開された範囲

ここには価格がありません。料金は発表に書かれていません。

このニュースの読みどころは、AIが答える前の土台です。探し方が変わると、AI回答の外れ方も変わります。