ドキュメントのバージョン管理によって、RAGの回答を最新ファイルに紐づける仕組みとは？

ドキュメントのバージョン管理は、インデックス化されたすべてのチャンクを安定したドキュメント識別子と明示的な改訂状態に関連付けることで、RAGの回答を最新に保ちます。

家庭内のナレッジベースには、古い賃貸契約書、改訂された保険証券、更新済みのルーターガイド、編集されたプロジェクト計画書、アーカイブ済みの家事手順書が同時に保存されている場合があります。古い改訂版も新しいファイルと同じ程度にクエリへ適合する可能性があるため、意味的類似度だけでは、現在どれが正式な最新版なのかを判断できません。バージョン管理によってライフサイクル情報が追加され、回答モデルが根拠を見る前に検索処理で適切な版を適用できるようになります。

安定したドキュメント識別子は、ファイル名の変更や改訂後も維持される必要がある

最初に必要なのは、「これはどのドキュメントか」と「これはそのドキュメントのどの改訂版か」を分けることです。ユーザーはファイルの名前変更、移動、コピー、置換を行うため、パスやファイル名だけでは不安定です。

安定したポイント識別子とペイロードには、親ドキュメントID、改訂ID、チャンク位置、現在の状態を示すフィールドを保持できます。これにより、ファイルパス自体を唯一の識別キーにする必要がなくなります。

ファイルが編集された場合、パイプラインはそれを無関係な別ソースとして扱うのではなく、同じドキュメントファミリー内の新しい改訂版として作成または認識する必要があります。

この識別レイヤーにより、アーカイブファイルをコピーした際、パス名が変わったというだけで、知らないうちに2つ目の「現行」ドキュメントになってしまうことも防げます。

改訂メタデータによって、検索に現行状態のフィルターを適用できる

各チャンクには、改訂番号、コンテンツハッシュ、取り込み時刻、適用日、ソースパス、親ドキュメントID、active、superseded、draft、archivedなどの状態を示すメタデータを継承させることができます。

ソースの鮮度と置き換え状態を追跡することが重要なのは、新しい改訂版が正式な現行版になった後でも、古い文章が現行状態に関するクエリと高い類似度を示す可能性があるためです。

現行状態に関するクエリでは、ベクトル類似度を計算する前、または最終候補を受け入れる前に、activeな改訂版だけに絞り込めます。履歴に関するクエリでは、指定された日付や改訂版まで意図的にフィルターを広げることができます。

新しいチャンクは、1つの一貫した改訂版として有効化する必要がある

大きなファイルは通常、多数のチャンクに分割されるため、更新によって1つのベクトルではなく、レコードの集合が作成されます。これらのチャンクを1つずつ公開すると、一部の文章が新しく、ほかが古いままになる混在状態が発生する可能性があります。

段階的な埋め込み更新では、変更されていないレコードを保持しながら、変更されたソースコンテンツに関連付けられた派生チャンクを置き換えたり削除したりできます。これにより、改訂版の切り替えを1つのドキュメントファミリー内に限定できます。

より安全なバージョン移行では、新しいファミリーを構築し、想定されるチャンクとメタデータを検証してから、取り込みが成功した後にのみactiveな改訂版を切り替えます。

OCR、チャンク分割、埋め込み、ベクトル挿入の途中で処理に失敗した場合でも、以前の完全な改訂版をactiveなままにして、混在したドキュメントを公開しないようにできます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

置き換えられたチャンクは、デフォルト検索から除外すべきだが、必ずしも削除する必要はない

履歴を保持しておくと、監査、変更内容の比較、あるいはポリシーが昨年どのように記載されていたかを確認する際に役立ちます。問題は古いチャンクが存在することではなく、現行の根拠と同じ条件で競合させてしまうことです。

ソースを考慮したRAGレコードでは、ベクトルをドキュメントレベルのメタデータに関連付けることで、元のソースとの関係を失わずに改訂版を管理できます。

置き換えられた改訂版は、アーカイブ用フィルターを使えば検索可能な状態で保持しつつ、通常の現行状態に関する質問からは除外できます。この分離により、追跡可能性を維持しながら、ほぼ同一の文章のうちどれを信頼すべきかを回答モデルに判断させずに済みます。

引用には、検索で使用したものと同じバージョン識別子が必要

検索で現行のチャンクを選択しても、引用の表示時にファイル名、パス、またはドキュメントファミリーだけからリンクを再構成しているなら、バージョン管理は不完全です。

検索で現行のチャンクが見つかった場合でも、引用レイヤーがファイル名やパスだけのような弱い識別子から参照先を再構成すると、引用メタデータが検索状態からずれる可能性があります。

引用レコードには、改訂ID、ソースパスまたは変更できないオブジェクト参照、ページまたはチャンクの位置、検索時に使用したものと同じ現行／履歴状態を保持させる必要があります。

これにより、ユーザーは回答の根拠となった正確な改訂版を確認できます。引用された根拠と文章が一致しなくなった新しいファイルを開いてしまうこともありません。

バージョン管理は、信頼できる変更検知に依存する

ソースの変更を取り込みパイプラインが検知しない場合や、更新に失敗した後も古いレコードがactiveなまま残り続ける場合、バージョン対応スキーマは役に立ちません。

RAGパイプラインの取り込みの一貫性は、バージョン対応検索の前提条件です。インデックスは、完全かつ正確に取り込まれていない改訂版を選択できないためです。

ファイルウォッチャー、定期的な照合、コンテンツハッシュ、データベースの変更ストリーム、明示的なアップロードイベントは、いずれもバージョンのライフサイクルに情報を提供できます。バージョン管理レイヤーは、その後どの改訂版を現行にするかを決定します。

現行の回答が信頼できる状態であり続けるのは、検知、取り込み、有効化、検索、引用のすべてが、同じドキュメント識別子と改訂版の契約を使用している場合に限られます。

FAQ

ファイルの更新日時だけでRAGのバージョンを定義できますか？

いいえ。コピーや復元の操作で更新日時が変わることがあり、どのコンテンツやチャンクの集合が正式な現行版になったのかを特定できません。安定したドキュメントIDと明示的な改訂メタデータを組み合わせる方が安全です。

古いドキュメントのバージョンは、ベクトルデータベースから削除すべきですか？

必ずしも削除する必要はありません。デフォルト検索から除外し、引用で改訂版の識別情報を明確に保持できるなら、履歴や監査のために利用可能な状態で残せます。

更新がまったく検知されない場合、バージョン管理で古い回答を防げますか？

いいえ。バージョン管理が制御できるのは、把握されている改訂版だけです。検知されなかった編集、削除、取り込みジョブの失敗を発見するには、別途、変更検知と照合の仕組みが必要です。