ベクトルデータベースでは、同じ埋め込みであっても、新しく構築された近似検索構造に再編成されるため、コンパクション後に異なる近傍ベクトルが返されることがあります。
ローカルRAGサーバーでは、この変化が不審に見えることがあります。意図的に文書を再埋め込みしていないのに、メンテナンス後に使い慣れたクエリから返される上位k件のリストが少し変わるためです。ここで重要なのは、ベクトルの値と、それらを検索するANNインデックスを区別することです。コンパクションによって前者を維持したまま、後者を再構築することがあります。
コンパクションによって複数の検索セグメントが新しいインデックスに置き換えられることがある
ベクトルデータベースでは、文書の挿入、更新、削除に伴って、個別のセグメントが蓄積されることがよくあります。コンパクションはこれらの断片を統合し、検索対象となる構造を減らすとともに、不要なデータを削減します。
Qdrantでは、コレクション全体を常に固定された1つのグラフとして扱うのではなく、セグメントの数とサイズを対象とするオプティマイザーが提供されています。コンパクションによって、より大きく最適化されたセグメントが作成されると、論理的なベクトルが変わっていなくても、物理的な検索構造が再構築されることがあります。
この区別は、プライベートRAGインデックスにおいて重要です。メンテナンスの前後で埋め込みの数値が完全に同一でも、それらを接続する近似検索グラフは異なる可能性があります。
近似最近傍検索はグラフのトポロジーに依存する
HNSWは、クエリをすべてのベクトルと比較するわけではありません。階層型グラフを移動し、有望な接続を限られた範囲でたどるため、グラフ内でどの経路を進むかによって調査される候補が変わります。
Elasticsearchは、セグメントのマージに伴ってHNSWグラフの再計算が必要になる場合があると説明しています。構築順序、削除状態、グラフのヒューリスティックがエッジに影響するため、再構築されたグラフでは同じベクトル同士の接続が異なることがあります。
2つの候補の距離が非常に近い場合、トポロジーのわずかな変化によって、一方が候補集合に入る一方、もう一方が一度も探索されないことがあります。その結果、埋め込みモデルを変更していなくても、近似最近傍の結果が変わります。
検索パラメーターによって、新しいグラフをどの程度探索するかが決まる
コンパクション後、データベースは複数の小さなグラフではなく、1つの大きなグラフを検索するようになることがあります。そのため、設定された検索予算が変わっていないように見えても、同じ上位k件のリクエストが異なる候補空間をたどる可能性があります。
Weaviateは、HNSWのef検索品質のトレードオフを説明しています。一般に、候補リストを大きくすると再現率は向上しますが、処理量も増えます。順位の境界付近では、検索量が少ないほど、グラフの構築方法による結果の変動が大きくなります。
有効な診断方法は、小規模なテストセットで、近似検索の結果を高いef値の検索または厳密検索と比較することです。厳密検索の近傍が安定しているのにANNの近傍だけが変化する場合、コンパクションによって変わったのはベクトルではなく検索経路です。
削除と更新によって、再構築後に残るノードが変わる
コンパクション前には、削除または置き換えられたレコードが、トゥームストーンやセグメント単位の管理情報とともに物理的に残っていることがあります。検索時には除外されますが、過去に存在していたことが、それ以前に構築されたグラフに影響している可能性があります。
Milvusは、HNSWが生のベクトルに加えて明示的なグラフ構造を保持すると説明しています。不要なレコードを削除した後に再構築すると、残ったデータだけを基にグラフが作成されます。
その結果、家庭内の文書自体は一度も編集していなくても、その周辺の局所的な接続が変わることがあります。あるメモに近いブリッジノードが追加されたり失われたりすることで、ANNの探索が最初に到達する領域が変わる可能性があります。
距離が変わらなくても、同順位や僅差の順位は入れ替わることがある
多くのプライベートなコーパスには、重複に近いデータが含まれています。たとえば、同じマニュアルの複数版、バージョン違いのファイル、写真のキャプション、コピーされたメモ、同じ定型文を含むチャンクなどです。これらのコサイン類似度や内積スコアは、ほとんど区別できないほど近くなることがあります。
PineconeのHNSW解説は、グラフの探索によって調査対象のベクトルが制限される仕組みを示しています。2つの項目が境界付近にある場合、候補経路や同順位の処理順が変わるだけで、意味上の大きな違いがないまま返される上位k件が変わる可能性があります。
したがって、アプリケーションでは、近傍順位が7位か8位かを永続的な同一性の根拠として扱うべきではありません。安定した文書IDを保存し、決定的な動作が必要な場合は実際の距離を比較してください。
厳密検索は、データのドリフトとANNのドリフトを切り分ける境界となる
最も明確な切り分け方法は、再現可能な小規模のクエリセットを用意し、メンテナンス前に埋め込み、距離指標、厳密検索の上位k件、近似検索の上位k件、インデックス設定、データベースのバージョンを記録しておくことです。
ZimaSpaceによるプライベート検索における埋め込みとドメインの変化の解説は、別の障害クラスを扱っています。これはベクトル空間そのものが変化するケースです。コンパクションは、その空間を維持したまま近似検索の結果を変える可能性があるため、別途診断する必要があります。
ZimaSpaceの文書検索とRAGのワークフローのガイドは、そのアプリケーション上の背景を説明しています。ANN層を近似検索として扱う場合でも、文書の同一性を安定させ、評価を行うことが重要です。
厳密検索の結果が変化した場合は、ベクトル、フィルター、正規化、距離指標、データのバージョンを確認してください。厳密検索の結果が変わらずANNの結果だけが変化する場合、原因はインデックスの再構築、検索量、同順位の処理、またはセグメントの配置にあります。
したがって、近似インデックスにおいて、コンパクション後も近傍順位がバイト単位で完全に同一になることは期待できません。決定的な順位付けには、より厳密な検索、またはアプリケーション側での同順位処理ルールが必要です。
よくある質問
コンパクションによって埋め込みベクトルは変わりますか?
通常は変わりません。一般的なコンパクションやセグメントのマージでは、ストレージとインデックスが再編成されます。アプリケーションが再埋め込み、再量子化、再正規化、その他の方法でベクトル値を書き換えない限り、埋め込みは変化しません。
コンパクション後に厳密な最近傍が変わることはありますか?
残っているベクトル、距離指標、数値表現が変わっていなければ、同じであるはずです。ただし、スコアが完全に同じ場合や、浮動小数点の実装上の細かな違いがある場合は例外です。
HNSWを再構築すれば、以前と完全に同じ順位を再現できますか?
必ずしも再現できるとは限りません。HNSWは近似手法であり、グラフの構築は挿入順、ランダム化、削除、実装上の細部に左右されることがあります。完全に同じ順位を得るには、全件比較などの網羅的かつ決定的な検索が必要です。
テック&AIハブ
もっと読む

Home Assistantにおけるランタイム状態と永続状態:再起動後も維持すべきものは?
Home Assistantはすべてのライブ値を永続化するわけではありません。設定、レジストリ、選択された復元状態、履歴、デプロイデータは、再起動時にそれぞれ異なる役割を果たします。

Home Assistantはローカルセッションとリモートセッションをどのように認証しますか?
ローカルおよびリモートのHome Assistantセッションでは、同じサーバー側のIDモデルを使用します。リモートアクセスによって変わるのは経路とTLSの境界であり、トークンフローの中核ではありません。

Recorderデータが増えると、なぜHome Assistantの履歴クエリは遅くなるのですか?
レコーダーの成長に伴い、要求された範囲に含まれる行数が増えたり、キャッシュミスが増加したり、ストレージやインデックス処理が遅くなったりすると、履歴クエリのコストが上昇する可能性があります。

