RAGを使った回答で情報の鮮度を確認するときは、原本文書を更新したことと、検索対象や回答へ反映されたことを分けて見ます。ファイルを新しくしただけで、古い版が検索候補から消えたとは限りません。
この記事では、社内文書を検索して回答に利用する仕組みを運用する担当者向けに、改訂、削除、参照権限の変更で確認したい項目を整理します。特定製品の設定手順や、導入済みシステムの検証報告ではありません。
原本・索引・回答の三つを区別する
ここではRAGを、関連する情報を検索し、その情報を回答生成へ利用する構成として扱います。確認対象は大きく次の三つです。具体的な処理や更新方法は、利用している製品と構成で異なります。
| 確認対象 | 確かめたいこと |
|---|---|
| 原本文書 | 正しい版か、適用日と管理者が分かるか |
| 検索対象・索引 | 新版が入り、不要な旧版が残っていないか |
| 回答 | 意図した資料を根拠にし、適用条件を説明しているか |
原本が正しくても、検索対象の更新が失敗していれば古い情報を使う可能性があります。検索結果が正しくても、回答が条件を落としていれば別の修正が必要です。どこまで確認したかを分けることで、調査先を絞れます。
更新と削除は、別の確認項目にする
製品例として、Azure AI SearchのAzure Storage向けインデクサーの説明では、変更検出と削除検出を区別しています。原本側での削除を、そのまま検索文書の削除として追跡するわけではないため、削除検出の方針が必要です。Azure AI Searchの変更・削除検出
この仕様をすべてのRAG製品へ当てはめるのではなく、自分たちの構成で、改訂と削除がそれぞれどう伝わるかを確認します。同期処理が成功したという記録だけで、旧版の除外まで終わったと判断しないでください。
- 新しい文書を追加した場合、いつ検索対象になるか
- 同じ文書を改訂した場合、版を何で識別するか
- 文書を削除・廃止した場合、検索候補からどう除外するか
- 文書名や保存場所が変わった場合、同じ文書として追えるか
- 閲覧できる人が変わった場合、参照制御へどう反映するか
仮例：社内手続きの案内を改訂する
架空の社内手続きで、申請先が変わり、新しい案内文を公開したとします。ここでは実際の規程や実装を使わず、確認の流れだけを示します。
まず、原本の管理者に新版と適用日を確認します。次に検索対象へ反映されたことを確認し、新しい申請先を尋ねる質問で、回答の根拠と参照版を確認します。
ただし、新版が一度返っただけでは、旧版が除外されたことまでは分かりません。旧案内を参照しやすい言い回しや、以前の文書名で確認するケースも用意し、現在有効な案内へつながるかを見ます。
| 確認 | 記録する材料 |
|---|---|
| 原本の改訂 | 文書ID、版、適用日、管理者 |
| 索引への反映 | 対象版、処理結果、反映を確認した時刻 |
| 旧版の扱い | 廃止対象、検索結果での確認 |
| 回答の確認 | 質問、引用先、回答中の条件 |
過去の規程を調べる用途があるなら、旧版を一律に消すのではなく、現行版と過去版を区別する設計を確認します。保存すべき文書の判断と、通常の回答に使う文書の判断は分けてください。
権限変更を、鮮度の問題と混同しない
文書が最新でも、利用者に見せてよい情報とは限りません。検索や回答の経路で、利用者の参照権限がどう扱われるかを確認します。管理者のアカウントで成功した確認だけを、すべての利用者の確認へ広げないようにします。
権限を変更した場合は、認められた確認用の利用者や環境で、許可される範囲と許可されない範囲を分けて確認します。この記事は権限設定の変更を勧めるものではなく、変更後の確認対象を整理するものです。
更新失敗時の担当と再確認条件を決める
更新処理が止まったとき、原本管理者、検索基盤の担当、回答機能の担当の誰へ連絡するかを決めます。古い情報を案内し続ける影響が大きい用途では、回答を控える、原本の確認へ案内するなどの扱いも事前に合意します。
まず、最近改訂した文書を一つ選び、原本の版、検索対象の版、回答の引用先を同じ記録へ並べてください。文書を入れる作業の完了ではなく、利用者が意図した情報へたどれることを確認の終点にします。