部分的なファイル更新によって、ローカルRAGインデックスに古い内容が残るのはなぜですか？
部分的なファイル更新では、新しいチャンクを挿入する際に、古いファイルバージョンから派生したすべてのインデックス済みフラグメントを無効化しないと、古いRAGパッセージが残ります。
ローカルナレッジベースで、ファイルごとに1つのベクトルしか保存しないケースはほとんどありません。テキストを抽出し、ファイルをチャンクに分割し、埋め込みを生成してメタデータを付与し、解析結果や検索結果をキャッシュする場合もあります。1つの段落を編集すると、それ以降のチャンク境界がずれ、ハッシュが変わり、古いテキストが削除され、新しいチャンクIDが作成されることがあります。更新処理が変更または新たに検出された部分だけを処理すると、元ファイル自体は正しく見えても、置き換え後のコンテンツと並んで古いパッセージが検索可能なまま残ることがあります。
1つのソースファイルが複数の独立したインデックスレコードになる
取り込みパイプラインが複数のチャンク、ページレコード、要約、埋め込みを保存する場合、ドキュメントの更新は1つのデータベース行を更新するだけでは済みません。
OptyxStackは、部分的な置換によって、同じドキュメントファミリーに属する古いチャンクと新しいチャンクが混在する可能性を説明しています。
新しいパッセージのインデックス作成には成功しても、別の識別子を持つ古いパッセージが、ベクトルデータベース上では有効なまま残ることがあります。
小さな編集でも、その後のすべてのチャンク境界がずれる可能性がある
冒頭付近に1つの段落を追加すると、固定サイズまたはオーバーラップ方式のチャンク分割で使用されるトークン位置が変わります。ソーステキスト自体を直接編集していなくても、その後の複数のチャンクに新しいコンテンツが含まれる可能性があります。
Extendは、ドキュメントや更新の間でチャンク分割とメタデータの前提が変化した際に、取り込みのずれがどのように現れるかを説明しています。
目に見えて編集された範囲だけを再埋め込みする更新処理では、境界やオーバーラップが変化した下流のチャンクを見落とす可能性があります。抽出やチャンク分割によって新しいレイアウトが生成される場合、安定したソースオフセットだけでは不十分です。
ドキュメントバージョンの識別情報で、派生したすべてのレコードをグループ化する必要があります。そうすれば、必要に応じて古いファミリー全体をパイプラインで置き換えられます。
挿入処理は削除処理よりもテストされていることが多い
取り込みジョブでは、新しいチャンクが作成されたことを自然に確認します。一方で、ソースから削除されたチャンクが検索できなくなったことまでは検証しない場合があります。
Ranjan Kumarによるインデックスの陳腐化ギャップの分析では、挿入、更新、削除の各イベントを、それぞれ伝播が必要な個別の変更として扱っています。
更新ワーカーがアップサートだけを実行し、削除済みを示すトゥームストーンや古いチャンクの一覧を持っていない場合、名前を変更したセクションや削除した段落がいつまでも残る可能性があります。
削除処理をテストするには、更新経路を実行するたびに、削除したコンテンツに固有のフレーズを検索してみてください。
ジョブが成功しても、インデックスが部分的にしか更新されないことがある
解析、チャンク分割、埋め込み、削除、挿入、メタデータ書き込み、キャッシュ無効化は、別々のステップとして実行される場合があります。別のワーカーが失敗する前に、一部の処理だけが成功することもあります。
Jamie Maguireは、取り込みジョブが成功したように見える、または部分的に完了しているにもかかわらず、検索インデックスが古いままになる運用上のギャップについて説明しています。
最終的なステータスを1つだけ記録すると、どのファイルバージョン、チャンク数、埋め込みセットが実際にクエリ可能になったのかが分からなくなることがあります。ステージごとの完了状況と、最後に完全にコミットされたドキュメントバージョンを記録してください。
インデックスの断片化によって、競合するバージョンが競い合う
古いパッセージと新しいパッセージが同じファイル名やドキュメントIDを共有していると、同じクエリに対して両方が関連性の高い結果として表示される可能性があります。
LlamaIndexの障害チェックリストでは、ソース更新後に矛盾した検索結果や古いデータが生じる原因として、インデックスの断片化を挙げています。
古い表現のほうが語彙上の一致度が高い、またはチャンクが短く整理されているという理由で、回答モデルが古い内容を選ぶことがあります。鮮度のメタデータも、検索器や再ランキング処理が実際に利用しなければ役に立ちません。
重複排除では、ベクトル類似度だけでなく、ソースバージョンとコンテンツの同一性を比較する必要があります。
新しいドキュメントバージョンを有効にする前にインデックスを調整する
ローカルパイプラインでは、ウォッチャーイベントやアップサート成功数だけを信頼するのではなく、ソースファイルと、インデックス内のドキュメントファミリー、チャンクハッシュ、バージョン、削除マーカーを定期的に比較する必要があります。
Oracleのインデックスずれに関するガイドでは、取り込み後に更新・削除されたコンテンツを検証できるよう、ソースとインデックスの調整を推奨しています。
新しいドキュメントバージョンの下で置き換え用チャンクを作成し、その数、メタデータ、検索動作を検証してから、以前のファミリーを廃止する前にアクティブバージョンを切り替えてください。これにより、削除または埋め込み処理が途中で終わった状態で、2つのバージョンが同じように最新として公開されるのを防げます。
ZimaSpaceのバックグラウンドインデックス作成の記事では、変更検出が、より大きな抽出・データベースパイプラインの一部にすぎない理由を説明しています。
最も安全な更新が、必ずしも最も小さな更新とは限りません。家庭内で使う短いファイルであれば、脆弱なチャンク単位のパッチを試みるより、ドキュメントファミリー全体を置き換えるほうが簡単で信頼性も高い場合があります。
よくある質問
ファイルの変更時刻を変更すると、すべてのチャンクが更新されますか？
いいえ。ウォッチャーがファイルを検出しても、取り込みコードが古いバージョンから派生したすべてのレコードを特定し、置き換え、無効化する必要があります。
ベクトル類似度によって、古いチャンクを自動的に除外できますか？
いいえ。古いパッセージと新しいパッセージが、どちらも意味的に関連する可能性があります。類似度だけでは、どのバージョンが最新かは判断できません。
常にインデックス全体を再構築する必要がありますか？
いいえ。ドキュメントファミリーの置き換えと調整によって、増分処理を維持できます。ただし、削除とバージョンの処理経路は、挿入と同じくらい慎重にテストする必要があります。
おすすめ商品
テック＆AIハブ
もっと読む
時系列のダウンサンプリングはスマートホームの異常検知にどのような影響を与えるか？
バケット幅、集計、アンチエイリアシング、欠損データ、イベント期間、マルチスケール保持によって、スマートホームの異常検出再現率がどのように変化するかをご覧ください。
占有グリッドは弱いスマートホーム信号をどのように統合するのか？
空間セル、センサーモデル、対数オッズ更新、減衰、相関した証拠、しきい値が、弱いホームセンサー信号を在室推定に変える仕組みを学びましょう。
測光正規化はプライベートな顔クラスタリングにどのような影響を与えるか？
照明補正によって、顔の切り出し画像、埋め込み、クラスタ間距離、しきい値、過剰正規化、プライベート写真検索の評価がどのように変わるかをご覧ください。
