埋め込みドリフトと再インデックス

モデルを差し替えると、なぜ既存ベクトルは使えなくなるのか

HNSW と IVF-PQ の記事では「近いベクトルをどう速く見つけるか」という索引アルゴリズムを扱いました。ここで扱うのは一段手前の問題です。索引の中身であるベクトルそのものが、埋め込みモデルの更新によって古くなるという、ベクトルDB運用に特有のライフサイクル課題です。

埋め込みモデルは、テキストや画像を実数ベクトルへ写す関数です。同じ次元数（例えば1536次元）であっても、モデルが変われば学習時の目的関数・学習データ・座標の取り方が変わるため、新旧モデルが出力するベクトル空間は原則として非互換です。具体的には次の三つが崩れます。

• 距離の絶対値に意味がない: 旧モデルでのコサイン類似度0.8と新モデルでの0.8は、同じ「近さ」を意味しない。
• 軸の対応が取れない: 次元ごとの意味が学習ごとに変わるため、旧ベクトルの成分を新ベクトルの成分と単純比較できない。
• クラスタ構造が変わる: 旧モデルで近かった概念同士が、新モデルでは遠くなることがある（逆もある）。

したがって、クエリだけ新モデルで埋め込み直し、既存の旧ベクトル索引と突き合わせる、という運用は原理的に破綻します。クエリベクトルと索引ベクトルが異なる空間に属するため、距離計算そのものが無意味な数値を返すからです。これは索引アルゴリズム（HNSWかIVF-PQか）とは独立した問題で、索引を差し替えずにモデルだけ差し替えると必ず精度が崩れるという点が運用上の急所です。

埋め込みドリフト：モデルを変えなくても近さは崩れる

モデルの差し替えがなくても、コーパス（登録されるドキュメント集合）の分布が時間とともに変化すると、相対的な近さの分布が変わることがあります。これを**埋め込みドリフト（embedding drift）**と呼びます。例えば新しい専門用語や新製品名が大量に追加されると、モデルが学習時に見ていない語彙の埋め込みが不安定になり、既存語彙との相対距離が意図とずれていきます。

ドリフトはモデル自体のバグではなく、モデルが学習した分布と実運用の分布との乖離が原因なので、再インデックス（全件再計算）では直りません。対処は主に二つです。

• 定量的な監視: 定期的にゴールドスタンダードのクエリ集合（正解が分かっている検索ペア）で recall やランキング相関を計測し、閾値を割ったらアラートする。
• モデルの再学習・差し替え判断: ドリフトが許容範囲を超えたら、モデル更新のプロジェクトとして扱い、後述の再インデックス手順に入る。

無停止re-indexingの基本設計：シャドーインデックス＋デュアルライト

数百万〜数十億件のベクトルを抱えるサービスでは、全件再埋め込み・再構築に数時間〜数日かかることも珍しくありません。その間サービスを止められないため、旧索引で検索を提供し続けながら、裏で新索引を作り、条件が整ってから切り替える段階的な戦略を取ります。

再インデックスの段階（概念）
  Phase 1: シャドー構築
    新モデルで全既存ドキュメントをバックフィル埋め込み → 新索引Bを構築
    索引A（旧）は引き続き本番トラフィックに応答
  Phase 2: デュアルライト
    新規/更新書き込みを A・B 両方へ反映（アプリ層 or CDC 経由）
    Bのバックフィルが追いつくまで両索引を同期させ続ける
  Phase 3: 影評価（シャドーイング）
    本番クエリのコピーをBにも投げ、Aの結果とオフラインで比較
    recall・ランキング相関が基準を満たすか検証
  Phase 4: 段階的カットオーバー
    読み出しトラフィックをA→Bへ 1% → 10% → 50% → 100% と段階的に付け替え
    メトリクス悪化時は即座にAへフォールバック（Bはまだ削除しない）
  Phase 5: 廃止
    100%移行後、一定期間の保持を経てAを退役

この構造は、オンラインスキーマ変更の「新テーブルを裏で構築し、トリガーやCDCで同期しつつ段階的に切り替える」設計思想と同型です。違いは、スキーマ変更が構造（列・型）の移行であるのに対し、埋め込み再インデックスは値そのものの意味空間の移行である点です。旧テーブルと新テーブルは行単位で1対1比較できますが、旧ベクトルと新ベクトルは直接比較できないため、Phase 3の「影評価」はスキーマ変更よりも重要度が増します。値の同一性ではなく、検索結果という間接指標でしか正しさを確認できないからです。

デュアルライトの整合性維持には、レプリケーションの同期/非同期と同じトレードオフが現れます。書き込みをA・B双方に同期反映すれば取りこぼしは起きませんが書き込みレイテンシが増え、非同期（キュー経由）にすればレイテンシは抑えられる代わりに一時的な不整合（Bへの反映遅延）が生じます。バックフィル中に発生した更新を取りこぼさないよう、多くの実装ではCDC（変更データキャプチャ）でAへの書き込みログを尾行し、Bへ再生する方式を取ります。

切り替え判定はオフライン評価で定量化する

カットオーバーの可否を勘に頼らないために、Phase 3のシャドー評価では次のような指標を使います。

ここで「新モデルの方が指標が良い」ことと「無停止で安全に切り替えられる」ことは別問題である点に注意します。前者はモデル選定の話、後者は運用の話であり、本記事が扱うのは後者です。

まとめ