RAGデータの鮮度とは、更新、削除、アクセス変更を含めて、検索システムが現在の承認済み情報源を反映する能力です。新しい文書を定期的にアップロードするだけでは、仕事の一部にすぎません。古いチャンク、キャッシュされた回答、失敗した削除経路が、引き続きアシスタントの回答に影響する可能性があります。
鮮度を、情報源から回答までの観測可能な約束として定義し、更新、撤回、権限変更の明確な経路を設けます。文書の識別と版の証拠を保持し、索引と情報源を照合し、廃止した内容が現れなくなることをテストします。最近の取込み時刻だけでは、現在有効で許可された回答を証明できません。
社内アシスタントが供給会社の手順について答える場面を考えます。運用部門は文書を置き換えましたが、アシスタントは旧版のチャンクを取得します。その回答は流暢で、古いチャンクを正確に引用していても、担当者を誤った手順に導きます。
このガイドは初回導入後の検索データの保守を扱います。当社のRAGの解説 は全体の方法を紹介しています。ここで決めるのは、既存の知識を使う業務をどう信頼できる状態に保つかです。
情報源ごとにRAGデータの鮮度を定義する
どの変更が重要か、業務がどれくらい早い反映を必要とするか確認します。過去の手引き、現在の在庫記録、撤回した方針には、同じ更新要件を適用できません。古い情報の影響が違う場合は期待する動作を分けます。
正式な情報源と承認する人を特定します。共有フォルダーには下書き、重複、保管資料が混在します。最近変わったすべてを取り込んでも、担当者が従う版は決まりません。内容の正当な根拠には、索引のルールになる前に業務ルールが必要です。
| 情報源の変更 | 定義するシステム動作 | 確認する証拠 |
|---|---|---|
| 承認済みの改訂 | 関連する索引内容を置換または更新 | 情報源と索引の版の参照 |
| 文書の撤回 | 検索対象から除外 | 管理された検索テストでの不在 |
| 権限変更 | 新しいアクセス境界を適用 | 影響するユーザーでの結果 |
| ファイルの移動や改名 | 識別を保持または意図的に変更 | 安定した対応付けとリンクの照合 |
| 取込み失敗 | 古い状態や利用不能を表示 | 責任者のいる警告と最後の確認済み版 |
情報源API、索引処理、運用要件を理解する前に、一律の鮮度間隔を約束しないでください。供給者の提案には、測定できること、遅延の原因、更新待ちの間のアシスタントの動作を示すべきです。
文書とチャンクの間で識別を保持する
情報源が対応する場合、通常の更新でも維持される安定した識別を元記録に与えます。版、検索位置、チャンクとの関係を保持します。改名、コピー、同じ場所での置換がある場合、ファイル名だけでは不十分です。
MicrosoftのAzure AI Searchインデクサー概要 は、インデクサーをデータソースから取り込む構成要素として説明しています。選ぶコネクターの実際の変更追跡動作を読みます。定期実行は仕組みであり、すべての情報源操作を検出した証拠ではありません。
情報源からチャンクへの対応付けを調べられるようにします。段落が変わると、どの以前のチャンクが古くなったかをシステムが知る必要があります。新しいチャンクを追加して古いものを廃止しないと、個々の埋込みが技術上有効でも、矛盾した証拠が生じます。
派生フィールドの作成方法を記録します。テキスト抽出、正規化、分割は索引された意味を変え得ます。処理の更新後に回答が誤った場合、運用者は情報源の改訂と抽出や検索の変更を区別できるべきです。
削除を独立したライフサイクルとして扱う
ファイルがストレージから消えると索引上の表現も自動的に消えるとは仮定しないでください。Microsoftの変更と削除の検出ガイダンス は、ストレージのインデクサーで更新追跡と削除検出を明確に区別し、対応する削除戦略を説明しています。
実装の詳細は基盤によりますが、受入れの質問は共通です。承認済みの撤回後も、アシスタントは旧資料を取得できるでしょうか。元フォルダーを見るだけでなく、関連する索引、派生チャンク、回答キャッシュをテストします。
中断した削除の後で照合する
後続の状態を確認するまで撤回の記録を保持します。インデクサーが削除マーカーを見る前に元オブジェクトを永久削除すると、依存していた信号が失われる可能性があります。選ぶ提供元の対応ライフサイクルを使い、最終状態を検証します。
一対多の変換を設計に含めます。一つの文書が複数のチャンクや記録を作る場合があります。削除経路は派生オブジェクトも扱う必要があります。親のメタデータ行を削除して検索可能な子を残すのは、受け入れられる撤回ではありません。
検索時に権限変更を適用する
新しい内容でも、要求するユーザーには不適切な内容かもしれません。現在のユーザーと組織の権限をどこで強制するか特定します。元の権限をメタデータに一度コピーしても、後の所属変更が検索境界に反映される証拠にはなりません。
OWASPの認可ガイダンス は、要求ごとのアクセス確認を推奨します。その原則を検索と回答のリンクに適用します。引用は、ユーザーに閲覧権限がない文書の題名や抜粋を明かしてはいけません。
| 検索の層 | テストする変更 | 受入れの質問 |
|---|---|---|
| 情報源コネクター | ユーザーやグループの所属変更 | 取込みは意図した範囲を保つか |
| 検索クエリ | ユーザーの文書アクセス喪失 | 文書を結果から除外するか |
| 回答キャッシュ | 過去の回答に制限付き文章がある | 後の要求にキャッシュした開示を返すか |
| 引用リンク | 情報源の場所変更 | 正しい許可された版へ到達するか |
当社の社内AIアシスタントガイド は従業員業務の全体を扱います。鮮度の保守はその権限モデルに合わせるべきで、より広い権限の別経路を作るべきではありません。
古い証拠を運用者に見せる
最後の確認済み情報源の版と、取込み処理が到達した位置を記録します。情報源の取得、抽出、索引、検索検証を分けます。取得は成功しても改訂した内容の索引に失敗する場合があるため、一つの最終実行時刻は誤解を招きます。
合意した情報源の期待に基づいて警告を選びます。変わっていない保管文書は、古いというだけで警告は不要です。業務手順の更新失敗は、少し前に索引更新が成功していても調査が必要かもしれません。
現在の証拠を確認できない場合は、適切な不確実な状態をユーザーに示します。責任者への確認を求めたり、撤回された情報源からの回答を拒否したりできます。検索結果があるというだけで、古い文章を自信を持って提示しないでください。
ログを必要に見合った範囲にします。元の識別子、版、処理の結果は、すべての機密文書を一般の計測システムへコピーしなくても調査を支えます。取得する内容のアクセスと保存期間は別に合意します。
管理した文書で全ライフサイクルをテストする
識別しやすい記述と意図的に異なる版を持つ、小さな管理対象の資料群を作ります。更新、撤回、権限変更の前後に同じ関連質問をします。最終回答とともに取得した証拠も確認します。
失敗や遅延の処理を含めます。段階の途中で管理した更新を停止し、その後の再開と照合を示します。想定コネクターが対応する改名、置換、重複情報源の事例をテストします。期待する識別の判断を記録します。
当社のAIエージェント評価ガイド は、有用な回答と受け入れた結果の証明を分ける方法を説明します。ここでは古くなった検索資料の廃止と、要求ユーザーの現在のアクセスの強制を含めて受け入れます。新しそうな文章を作るだけでは不十分です。
ライフサイクルのテスト用資料を回帰事例として保持します。抽出、分割、索引、キャッシュの変更後に再確認します。新しい検索モデルは回答の関連性を改善しながら、隠れていた古い記録の問題を露呈する可能性があります。
修復と処理基盤の置換を比較する
まずライフサイクルの不具合の位置を調べます。削除処理の欠落、識別の不安定さ、誤ったキャッシュ範囲は、限定した修復で対応できる場合があります。新しいベクトルデータベースは、不明確な情報源の権限や撤回を記録しない取込みを修正しません。
| 作業単位 | 成果物 | 範囲を決める要素 |
|---|---|---|
| ライフサイクル監査 | 情報源から索引への識別と失敗の図 | コネクターの数と動作 |
| 更新と削除の修復 | 再現できる後続状態の変更 | 派生チャンクと提供元の仕様 |
| 権限検証 | 現在のユーザー範囲の検索証拠 | 情報源の所属とキャッシュ設計 |
| 運用 | 照合と責任者のいる警告 | 必要な鮮度の期待 |
| 引継ぎ | ライフサイクルの資料と文書 | 情報源と処理の変更頻度 |
これらの結果に結び付いたGBPの提案を求めます。初期修復と、取込み、保存、検索、継続保守の費用を分けます。文書数だけに基づく価格は、正しい文書を最新かつ許可された状態に保つという難しい部分を省く場合があります。
当社のAI連携の限定範囲の試行 は、古い回答の例と正式な情報源から始められます。アシスタントが見落とした更新や撤回をお送りください 。範囲の明確な調査と受入れ可能なライフサイクル修復をご相談いただけます。
よくある質問
RAGデータの鮮度とは何ですか? 現在の承認済み資料と、検索や回答に使える証拠の関係です。最新の取込み実行日だけでなく、更新、撤回、識別変更、権限も含みます。
再索引すると削除文書も自動的に消えますか? 必ずしもそうではありません。選ぶコネクターの削除動作を確認し、親記録と派生チャンクの両方を検証します。明示的な削除戦略が必要な基盤もあります。
毎回すべての文書を再度埋め込むべきですか? それは共通の要件ではありません。適切な場合に安定した情報源の識別と変更追跡を使い、結果の状態を照合します。重要なのは、最新で完全かつ許可された検索証拠です。
システムにはどれくらいの鮮度が必要ですか? 情報源と影響によって定義します。撤回された業務指示は、過去の保管資料とは違う扱いが必要かもしれません。期待する更新動作と、満たせない場合の代替を示します。
回答キャッシュは古い結果を作りますか? はい。最新の索引が古い回答キャッシュを自動的に無効化するとは限りません。キャッシュと情報源の版、撤回、ユーザー権限の関係をテストします。アクセス取消し後の動作も含めます。
ファイルの改名が重要なのはなぜですか? コネクターが使う識別や場所を変える可能性があるからです。そうでなければ重複を作ったり、以前のチャンクとの対応を失ったりします。改名が同じ元記録を保持するか定義し、提供元の実際の動作をテストします。
新しいベクトルデータベースが必要ですか? 自動的に必要になるわけではありません。まずライフサイクルの欠陥を探します。限定した更新、削除、キャッシュの問題は、既存の処理で直せる場合があります。置換は同じ鮮度と責任要件に照らして正当化すべきです。
保守の供給者は何を引き渡すべきですか? 情報源の対応付け、ライフサイクルのルール、照合手順、管理された回帰テスト文書、更新、撤回、権限テストの証拠です。既知のコネクター制約と、未解決の失敗の責任者も含めます。