1つのプライベート検索システムで複数の埋め込みモデルを共存させることはできますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Can Multiple Embedding Models Coexist in One Private Search System?

はい。1つのプライベート検索システムで、複数のモデルの埋め込みを同時に保存およびクエリできます。安全な方法は、各埋め込みモデルを、明示的な次元数、距離メトリック、バージョン、インデックス設定を持つ独自のベクトル空間として扱うことです。互換性のないベクトルを1つの匿名列に混在させ、比較可能だと想定してはいけません。

複数のモデルは、移行、多言語検索、画像とテキストの組み合わせによる検索、ドメイン特化埋め込み、A/Bテストに役立ちます。複雑になるのは、これらの空間全体で結果を組み合わせる必要がある場合です。

なぜ複数の埋め込みモデルを保持するのか？

理由	例
モデル移行	新しいベクトルのバックフィル中も古いエンコーダーを稼働させる
多言語検索	一般英語モデル + 多言語モデル
異なるモダリティ	テキスト埋め込み + 画像埋め込み
ドメイン特化	一般ドキュメント + コード埋め込み
品質テスト	本番モデルを置き換える前のA/B検索
遅延インタラクション	高密度リトリーバー + ColBERT形式の再ランキング

プライベートなナレッジベースは進化します。選択した最初の埋め込みモデルにすべてのドキュメントを永久に固定すると、アップグレードが不必要に困難になります。

異なるモデルは異なるベクトル空間を生成する

2つのモデルがどちらも768次元のベクトルを出力していても、互換性がない場合があります。各座標は、そのベクトルを生成したモデルとの相対関係においてのみ意味を持ちます。

ドキュメントA
  |
  +-- Model v1 -> vector_v1 [768]
  |
  +-- Model v2 -> vector_v2 [1024]
  |
  +-- 画像モデル -> vector_image [512]

Model v2で生成されたクエリは、v2空間を検索する必要があります。APIが次元数を受け付けたとしても、Model v1のベクトルと直接比較することに意味はありません。

Qdrantの最新の名前付きベクトルのドキュメントでは、同じポイント内に異なるサイズや型の複数のベクトルを、それぞれ別個の名前付きベクトル空間として保存できることが明示的にサポートされています。

ベクトル名だけでなく、モデルレジストリを使用する

すべての埋め込みを再現できる十分なメタデータを記録する：

埋め込み空間：text_v2
モデルID：example/model-name
モデルリビジョン：sha-or-version
ベクトル次元：1024
メトリック：コサイン
正規化済み：true
チャンク分割ポリシー：semantic-v3
作成日時：2026-09-03

チャンク分割もレジストリに含めるべきです。埋め込みモデルとドキュメントの分割方法の両方を変更すると、検索結果が変わる理由が2つになります。パイプラインのバージョンを明示しておけば、比較とロールバックが可能になります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

同じコレクション内の名前付きベクトルと個別のコレクションのどちらを選ぶべきか？

どちらの設計も適切になり得ます。

設計	適する状況	トレードオフ
同じオブジェクト上の名前付きベクトル	モデル間で同じドキュメント／ペイロードを使用する	オブジェクト／インデックスのフットプリントが大きい
個別のコレクション	スキーマ、ライフサイクル、規模、または権限が異なる	同期作業が増える
1つのPostgresテーブル + model_id	SQL中心のスタック	インデックスは正しくスコープを設定する必要があります

Weaviateのコレクションのドキュメントも、オブジェクトごとに複数の名前付きベクトル空間をサポートしており、それぞれに独自のベクトライザーとインデックス設定を持たせられます。

権限が異なる場合（たとえば、家族向けドキュメントと仕事用ドキュメント）、すべての表現を1つのオブジェクトに格納するよりも、コレクションを分けたほうがすっきりする場合があります。

Pgvectorは異なる次元数を保存できますか？

はい。Pgvectorのドキュメントでは、model_idを持つ汎用的なvector列を示し、特定の次元数の行に対して式インデックスと部分インデックスを使用しています。

原則は同じです。データモデル内でモデルの識別情報を保持し、互換性のある行だけを対象にANNインデックスを構築します。

モデル間で生の類似度スコアを比較しない

これは最も見落としやすい問題です。モデルAのコサイン類似度0.78が、必ずしもモデルBの0.78と同じ品質を意味するわけではありません。スコア分布は、モデルの学習、正規化、距離指標、ドメイン、インデックスの挙動によって異なります。

2つの埋め込みモデルから1つの結果リストを作成したい場合は、まず個別に検索します。

クエリ
  |
  +-- モデルA -> 上位20件の結果 + 順位
  |
  +-- モデルB -> 上位20件の結果 + 順位
                      |
                      融合
               融合／リランカー
                      |
                      融合
                  最終的な上位10件

より安全な組み合わせ方法には、ランク融合、データに合わせて調整したモデル固有のスコア正規化、または検索後に候補テキストを評価するクロスエンコーダー／リランカーがあります。

Weaviateのマルチターゲット検索のドキュメントでは、正規化／重み付けした組み合わせなどの結合戦略が紹介されています。これは、異なるスペース間のフュージョンに、単純な生スコアの並べ替えではなく、明示的な戦略が必要な理由を示しています。

ダウンタイムなしで新しい埋め込みモデルに移行するには？

最初に古い埋め込みを削除しないでください。並行移行を使用します。

新しいモデルとベクトルスペースを登録する。
新しく取り込んだドキュメントに対して新しい埋め込みを生成する。
古いドキュメントをバッチでバックフィルする。
両方のスペースに対してシャドー検索を実行する。
実際の質問で再現率とタスク成功率を比較する。
デフォルトのクエリスペースを切り替える。
ロールバック期間中は古いベクトルを保持する。
確信が持てるようになってから削除する。

Weaviateは、新しい名前付きベクトルを追加しても、既存のオブジェクトが自動的に再ベクトル化されるわけではないと説明しています。この動作は覚えておくと便利です。「スキーマが新しいモデルをサポートすること」と「すべての古いデータに新しいベクトルがあること」は、別々のマイルストーンだからです。

複数の埋め込みは、予想以上の速さでストレージを増加させる

追加のベクトル表現ごとに、別の密配列と別のANNインデックスが追加される可能性があります。そのため、2つ目の埋め込みモデルを追加すると、元のドキュメントは1回だけ保存されているにもかかわらず、データベースのベクトル／インデックス部分がほぼ倍増することがあります。

見積もり：

ベクトルのバイト数 ≒
  ドキュメントチャンク
  ×次元数
  ×要素あたりのバイト数
  ×埋め込みスペースの数

＋ANNインデックスのオーバーヘッド
＋メタデータ／ペイロードインデックス

量子化や半精度インデックスによって容量を削減できますが、すべてのモデルに圧縮を適用する前に、検索品質をテストしてください。

これはローカルナレッジベースのアーキテクチャの問題に戻ります。埋め込みは置き換え可能な派生データである一方、元のドキュメントとメタデータは、再構築を可能にする永続的な資産です。

クエリルートごとに異なるモデルを使用する

すべての質問で、すべてのベクトルスペースを検索する必要はありません。必要に応じて振り分けます。

クエリ	埋め込みスペース
英語のホームマニュアル	general_text_v2
中国語＋英語のメモ	multilingual_v1
ソースコードに関する質問	code_v1
類似した写真を探す	image_v1
不明／広範な検索	2つのスペース＋ランクフュージョン

小さなクエリ分類器で適切なスペースを選択でき、曖昧な検索では2つの表現に分けて検索し、結果を統合できます。

フュージョンの前に権限を適用する必要がある

すべてのベクトル空間から権限のない候補を取得し、最終的なリランカーがそれらを隠してくれることを期待してはいけません。機密性の高いチャンクが候補集合、ログ、またはリランカーのプロンプトに入らないよう、各検索段階でユーザーとドキュメントの権限を適用してください。

プライベートNAS検索では、モデル移行後も同じアクセス制御ルールを維持する必要があります。新しいインデックスは、ドキュメントの権限メタデータを引き継ぐべきであり、一時的に保護されていないコピーになってはいけません。

プライベートAIアシスタントガイドでは、より大きな背景を説明しています。ベクトル検索が役立つのは、ファイルストアと同じプライベートデータの境界を尊重する場合に限られます。

複数埋め込みQAチェックリスト

すべての埋め込み空間に、一意のモデル/バージョンIDを付与してください。
次元数、正規化、距離メトリックを記録してください。
チャンク分割と前処理にバージョンを付けて管理してください。
あるモデルのベクトルを、別のモデルのインデックスに対して検索しないでください。
キャリブレーションなしに、異なる空間の生のスコアを直接比較しないでください。
すべての検索経路で権限を適用してください。
デフォルトを変更する前に、新しいベクトルをバックフィルしてください。
実際の質問と、関連性が既知のドキュメントで評価してください。
ロールバック期間中は、以前のインデックスを保持してください。
追加のベクトルとインデックスを、ディスク/RAMの容量計画に含めてください。

よくある質問

1つのデータベースで、2つの埋め込みモデルに異なる次元を使用できますか？

はい。データベースが、互換性のある次元ごとに個別の名前付きベクトル空間、コレクション、またはインデックスをサポートしていれば可能です。Qdrant、Weaviate、pgvectorはいずれも、このためのパターンを提供しています。

古いドキュメントを再埋め込みせずに埋め込みモデルを切り替えられますか？

新しいモデルのベクトル空間で古いドキュメントを検索したいのであれば、保持する必要はありません。新しいクエリベクトルは、別のモデルが生成した埋め込みとは互換性がありません。

古い埋め込みを永久に保持すべきですか？

いいえ。評価とロールバックのために保持してください。新しいモデルの検証と移行が完了したら、不要なベクトルを削除することで、ストレージ容量とインデックスメモリを大幅に節約できます。

最終判定

ベクトル空間を明示的に管理すれば、複数の埋め込みモデルを1つのプライベート検索システム内で問題なく共存させられます。モデルとパイプラインのメタデータを保存し、一致するエンコーダーで各空間を検索し、結果を意図的に統合し、並行してバックフィルすることで移行します。危険なのは「複数のモデルを使うこと」ではありません。どのモデルがどのベクトルを生成したかを見失い、すべての類似度スコアが同じ意味を持つかのように扱うことです。