RAGの文書を更新したら何を直す？古い断片・削除・閲覧権限を残さない運用
RAGの試作が最初は正しく答え、数週間後に古い答えを返すことがある。モデルが変わっていなくても、元文書の改訂や削除が検索索引へ反映されていなければ起きる。回答が引用した資料を開くと新しい規程になっているのに、検索された断片だけが旧版のまま残る場合は、プロンプトより先に文書の同期を調べたい。
例えば、架空の規程で「申請は原則3日前」と書かれていた箇所が「原則5日前」に変わったとする。新しい文書だけを索引に追加し、古い断片を消さなければ、検索結果に両方が並びうる。これは説明用の例であり、実在する規程やサービスの観測結果ではない。
原本と検索索引を区別する
原本は利用者が管理する文書であり、検索索引はそれを分割・変換した検索用の複製だ。文書を一つ直すと、その文書から作った複数の断片、埋め込み、見出しや版のメタデータも更新対象になる。LlamaIndexのDocument Managementは、文書IDを指定した更新・削除・再取り込みを扱う。どの断片がどの原本から作られたかを追えるIDを持つことが、削除漏れを防ぐ出発点になる。
索引へ追加する処理だけでは「原本から消えた文書」を検出できないことがある。Azure AI SearchのIndexer資料も、通常の更新処理だけでは孤立した索引内文書が自動で消えるとは限らないと説明している。利用する検索基盤の削除検知と削除手順を確認し、原本側の削除や移動を索引へ伝える必要がある。
版を切り替える順序を決める
変更前に文書ID、版、更新日時、権限情報を記録する。変更された文書を再分割し、新しい断片が検索できることを確かめる。その後、旧版の断片を検索対象から外す。更新の途中で新旧両方が利用者へ見える時間を許すのか、版ごとの索引を用意して切り替えるのかは、求める正確さと停止時間で決める。どの基盤でも自動的に一瞬で切り替わると仮定しない。
特に注意したいのは、本文だけを差し替えて検索用の埋め込みを作り直さない状態だ。文書が変われば、検索に使う表現も変わりうる。分割方法や埋め込みモデルを変えた場合は、対象範囲の断片を再生成し、旧方式の断片が混在していないかを確かめる。
閲覧権限も検索時に効かせる
文書を読む権限がなくなった利用者へ、古い検索結果だけが表示されてはならない。Azure AI Searchのセキュリティ資料は、文書ごとの権限情報を索引へ持ち込み、検索時に利用者の権限で結果を制限する方式を説明している。ただし製品ごとに利用可能な仕組みや条件は異なる。アプリで自前のメタデータ絞り込みを実装するなら、その絞り込みが検索の全経路に適用されることを確認する。
権限を取り消したテスト利用者で、検索結果、回答本文、引用先のどこにも対象文書が出ないか試す。回答生成後に画面上の引用だけを隠しても、モデルへ渡す文脈に秘密文書が含まれていれば手遅れだ。権限変更を索引へ反映するまでの遅延も測り、求める保護水準を満たせない場合は原本側の権限を検索時に再確認する設計を検討する。
更新後は以前の質問をもう一度流す
更新が成功したというAPI応答だけで完了にしない。改訂した内容を問う質問、旧版なら答えが変わる質問、削除した文書でしか答えられなかった質問を実際に流す。検索結果の文書IDと版、生成へ渡した断片、最終回答と引用を一緒に見る。削除した文書を問われたら、根拠がないことを示せるかも確認する。
検索評価と回答評価で使った質問集合を保存しておけば、更新前後を比較できる。ただし版が変われば期待する答えも変わるため、評価データの正解も改訂しなければならない。文書を更新する作業は、索引、権限、引用、評価データを同じ版へそろえる作業でもある。