Hugging Faceがマルチベクトル追加学習を解説。AI検索の勝負は「うちの言葉」へ

AI検索は、うちの言葉で強くなります

社内検索で、正しい文書が出てこないことはありませんか。言葉は近いのに、AIが別の資料を選ぶ場面です。

一言で言えば、AI検索の勝負はうちの言葉に寄せる力です。Hugging Faceの今回の記事は、そのための学習手順を示しています。

発表の中心は、Sentence Transformers（AI検索用の文章表現モデルを扱うPythonライブラリ）v6.0のMultiVectorEncoderです。MultiVectorEncoderは、文章を単語ごとの意味表現で扱う検索モデルです。

これは、AIチャットそのものの新機能ではありません。AIが答える前に、どの文書を読むかを決める検索の技術です。

会社ごとの言葉は、汎用モデルだけでは拾いきれません

Hugging Faceの記事は、分野ごとに語彙、質問の書き方、関連性の考え方が違うと説明しています。Web検索、法務調査、コード検索、科学文献レビューでは正解の探し方が違います。

この差は、非エンジニアの仕事にもそのまま出ます。部署ごとの略語、製品名、社内規程の言い回しは、外の世界の一般的な言葉と一致しません。

・医療文書では、専門用語の近さが大切です。

・法律文書では、似た表現の差が大切です。

・コード検索では、関数名と説明の対応が大切です。

・社内文書では、部署だけで通じる略語が大切です。

ひとつの要約ではなく、細かな照合で探します

dense embedding（文章全体を1つの数字の並びにする方式）は、文書を大きく要約します。速く扱いやすい一方で、細かな手がかりは平均化されます。

Multi-vector model（単語ごとの意味表現を残す検索モデル）は、質問と文書を細かく比べます。記事では、MaxSim（質問側の各語に近い文書側の語を探す計算）でスコアを出すと説明されています。

この違いは、長い文書で大きくなります。記事では、古典的なColBERTのチェックポイントが180または300トークンで文書を切る例が出ています。

多くのdense modelも、256または512トークンで切るとされています。医療評価の文章は平均941トークンで、文書の後半を捨てると検索精度に響きます。

公式記事の実験は、手元の専門データで勝つ話です

記事では、mLateOn-medicalという医療検索向けモデルが紹介されています。これは単一のRTX 3090で14.5時間学習されたモデルです。

学習例では、tomaarsen/miriad-4.4M-splitから1,000,000件の医療質問と文章のペアを使っています。MIRIADの文章は、平均941トークンだと説明されています。

評価では、1,000件の医療質問が200,000件の文章から正しい文章を探します。結果として、mLateOn-medicalはNDCG0.9139でした。

汎用のmLateOnは0.8520、Qwen3-Embedding-4Bは0.7817です。大きな汎用モデルより、その分野で鍛えた検索モデルが強い場面があります。

データの置き場所は、Hubでも手元でも構いません

今回の記事は、学習の部品を一式で扱っています。モデル、データセット、損失関数、学習設定、評価器、trainer classを組み合わせます。

Hugging FaceのDatasets公式ドキュメントでは、load_datasetがHub上のデータセットを読み込めるとされています。ローカルのCSV、JSON、Parquetなども扱えます。

Dataset.from_dictは、列ごとのリストを持つ辞書からDatasetを作れます。ただし、そのDatasetはメモリ上にあり、容量を減らしたい場合はディスクへ保存して読み直す説明があります。

画面の裏側で、AIの信頼感が変わります

非エンジニアが直接触るのは、検索モデルの設定画面ではありません。触るのは、社内チャット、FAQ、ナレッジ検索、調査補助の画面です。

その裏側で検索が弱いと、AIはもっともらしく別の資料を読んでしまいます。検索が強くなると、答えの根拠が仕事の文書に近づきます。

もちろん、マルチベクトル検索は軽いだけの技術ではありません。記事では、200,000件の長い文章で生の埋め込みが約45GBになる例が出ています。

一方で、1-bit PLAIDでは3.37GBまで小さくなる例も示されています。精度と容量の両方を見る設計が、実用では大切になります。

AI検索の次の進化は、派手な会話能力だけではありません。社内の言葉をどれだけ落とさず拾えるかが、毎日の仕事の信頼感を変えていきます。