- マルチベクターはトークン単位で検索し、高精度になる一方インデックスが大きい
- 教師なしチェックポイントの方が完成済みよりドメイン適応しやすい
- 1枚のRTX 3090で14.5時間の訓練により医療検索で最高精度を達成
マルチベクターモデルとは
デンス埋め込みモデルは文書全体を1つのベクトルに圧縮し、類似度はドット積で計算します。一方、マルチベクターモデル（ColBERT形式）は、トークンごとに小さなベクトルを保持し、クエリの各トークンが文書中の最も近いトークンを探してスコアを合計するMaxSim演算を使います。この仕組みにより、1つのベクトルに平均化されがちな細かい情報が保たれ、検索精度が高くなる傾向があります。ただし、インデックスサイズが大きくなるという代償があります。
従来のモデルの多くは短い文書を想定しており、文書を180〜512トークンで切り捨てることが一般的です。医療データのように平均941トークンある文書では、この切り捨てが最大0.24 NDCG@10の精度低下を引き起こすと報告されています。自前でモデルを訓練すれば、データに合わせて文書長を設定できます。
訓練の構成要素
マルチベクターモデルの訓練には、モデル、データセット、損失関数、訓練引数、評価器、トレーナーが必要です。Sentence TransformersのMultiVectorEncoderクラスを使うと、既存のモデルを読み込んでそのまま微調整できます。たとえば、lightonai/mLateOn-unsupervisedを指定し、プロセッサーの最大長を8192トークンに設定するなどの調整が可能です。
データセットはHugging Face HubのDatasets形式で用意します。記事ではMIRIADから生成された440万件の医療質問と回答を含むデータセットを使っています。質問と、その回答を含むパッセージのペア（クエリ、関連文書）という単純な形式だけで十分な効果が得られるとしています。
損失関数はデータセットの形式と一致する必要があります。記事では具体的な損失関数の名前は挙げていませんが、Loss Overviewの表を参照するように述べています。訓練には、MultiVectorEncoderTrainerが使われます。
出発点の選び方
注目すべきは、ファインチューニングの出発点です。記事では「教師なしチェックポイント」と「完成済みチェックポイント」を比較した結果、教師なしチェックポイントの方が新しいドメインに適応しやすいと報告しています。教師なしチェックポイントは、大規模な対照事前学習は終えているが、一般的な検索向けの教師あり微調整は行われていないため、ドメイン適応の妨げになる一般調整をやり直す必要がないためと考えられます。
一方、完成済みのチェックポイントから続けて訓練すると、学習率を変えても性能が上がらないか、むしろ下がる場合があったとのことです。また、強力なデンス埋め込みのバックボーンに新しいプロジェクションをランダム初期化して追加する方法もあり、わずか2.5万組の訓練データで既存チェックポイントに近い性能に達したとしています。
実験結果と注意点
記事では、この手法で訓練したモデル（multi-vector-encoder/mLateOn-medical）が、医療検索評価で見つけたすべての一般目的検索モデル（デンス、スパース、語彙、マルチベクター）を上回ったとしています。訓練時間は1枚のRTX 3090で14.5時間でした。このように、コンシューマー向けGPUでもドメイン特化の検索モデルを短時間で構築できることを示しています。
注意点として、マルチベクターモデルはインデックスが大きくなります。また、句読点をスキップする設定にすることで、インデックスサイズを9.6%削減できたという実験結果もあります。モデルやデータセットの選定、評価指標の設定には注意が必要です。
| 項目 | デンス埋め込み | マルチベクター |
|---|---|---|
| ベクトルの単位 | 文書全体で1つ | トークンごとに1つ |
| スコア計算 | ドット積 | MaxSim（最大値の合計） |
| 検索精度 | 圧縮による情報損失があり得る | 細かな一致を保てる傾向 |
| インデックスサイズ | 小さい | 大きい |
Token-level matching preserves exactly the fine-grained signals that a single vector has to average away, which usually means stronger retrieval, at the cost of a bigger index.
トークンレベルのマッチングは、単一ベクトルが平均化してしまう細かいシグナルを正確に保持するため、通常はより強力な検索を実現しますが、より大きなインデックスというコストが伴います。
今後の見通し
今後は、ドメイン特化の検索モデルを内製する流れが広がるとみられます。特に、RAG（検索拡張生成）の精度向上が求められる企業にとって、この手法は有力な選択肢となるでしょう。ただし、マルチベクターモデルのインデックスサイズが大きい点や、GPUリソースと学習時間の見積もりは課題として残ります。どの程度のデータ量で効果が得られるか、日本語を含む他の言語やドメインでの再現性が明らかになれば、より実用的な判断ができるようになると考えられます。
日本の開発者・IT企業にとっての意味
日本のIT企業にとって、この記事はドメイン特化型の検索・RAGシステムを自前で構築するハードルが下がったことを意味します。医療、法律、社内文書など、専門領域の日本語データで検索精度を高めたい場合、従来は外部のAPIや高価なGPUクラスタが必要と考えられることが多いでしょう。しかし、1枚のコンシューマーGPUで14.5時間という短時間の訓練で、一般目的モデルを上回るモデルが作れる可能性が示されました。これは、機密データを外部に出したくない企業にとっても、内製モデルの運用が現実的になることを示しています。一方で、マルチベクターモデルはインデックスが大きく、推論コストにも影響するため、導入時には運用設計が重要になります。また、教師なしチェックポイントの活用という知見は、モデル選定の指針として有用です。
気になる点
- マルチベクターモデルのファインチューニングにはどのくらいのデータが必要ですか？
- 記事ではMIRIADデータセットから作った440万件のペアを使用していますが、モデルは比較的少ないデータでも良好に反応すると述べています。具体的な最小データ数は明示されていません。
- 既存のモデルをそのまま使えますか？
- はい。MultiVectorEncoderクラスを使って、公開済みのモデル（例：lightonai/mLateOn-unsupervised）を読み込み、ドメインデータで微調整できます。ただし、ドキュメント長の上限に注意し、必要に応じて解除してください。
- 日本語の検索にも応用できますか？
- 原文では日本語について言及されていませんが、トークン単位のアーキテクチャは言語に依存しないと考えられます。日本語言語モデルをバックボーンにすれば応用可能とみられます。具体的な実績は不明です。
用語解説
- マルチベクターモデル
- テキストをトークンごとのベクトルで表現する埋め込みモデル。ColBERTに代表される。
- MaxSim
- クエリの各トークンが文書中の最も類似するトークンを選び、そのスコアを合計する演算。
- デンス埋め込み
- テキスト全体を1つのベクトルに圧縮する埋め込み方式。
- ファインチューニング
- 事前学習済みモデルを特定のタスクやドメイン向けに追加学習すること。
出典
Training and Finetuning Multi-Vector Embedding Models with Sentence Transformers
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する