ローカルRAGのフォルダーを追加・更新するときの運用方法

ローカルRAGを使い続けると、最初に索引を作ることよりも、元文書を変更した後に検索側へ何が反映されたのか分からなくなることが問題になりやすい。

最初に「人が管理する元文書フォルダーが正本で、RAGの索引はそこから作り直せる派生物」と決めておくと整理しやすい。

図を拡大して見る

図: 処理や設定の流れを1枚に整理。実際の操作条件は本文で確認する。

正本を一つに決める

たとえば社内PDFをRAGへ入れるなら、次の二つを同じものとして扱わない。

元文書フォルダー = 人が管理する原本
RAGの索引        = 文書解析・分割・埋め込みから作る検索用データ

索引側を直接編集して正本にすると、後で索引を作り直したときに変更理由を追いにくくなる。

原本の追加・更新・削除は元文書フォルダーで管理し、索引は必要なら再生成できる状態を保つ。

「追加」と「内容更新」を別々に試す

まず新しいファイルを一つ追加し、RAGへ取り込む。そのファイルにしかない固有語で検索し、見つかるか確認する。

次に同じファイルの本文を一箇所だけ変更し、古い文章と新しい文章のどちらが検索されるかを見る。

重要なのは、フォルダーへ保存しただけでRAGの索引が自動更新されるとは限らないことだ。

利用するソフトが監視・同期機能を明示していないなら、再取り込みや索引の作り直しが必要か確認する。

名前変更と削除は古いデータが残っていないか見る

ファイル名の変更や削除では、古い分割データが索引へ残っていても気付きにくい。

1. sample-a.pdfを取り込む
2. sample-b.pdfへ名前を変える
3. 古いファイル名・古い固有語で検索する
4. 新しいファイル名・新しい固有語で検索する
5. 出典表示がどちらを指すか確認する

削除でも同じように、原本を消した後で古い内容が検索結果へ残っていないかを見る。

文書解析や埋め込みを変えたら索引の前提も変わる

Ollamaの公式資料では、埋め込みを意味検索やRAGの構成要素として扱っている。

埋め込みモデルを変えると、文書や質問を表す数値も変わる。文書側と検索側で同じ前提を使う必要がある。

文書解析方法、分割サイズ、重なり幅、埋め込みモデルなどを変えた場合は、古い索引へ一部だけ足すのではなく、どこまで作り直すかを明示する方が確認しやすい。

文書解析のバージョン:
分割設定:
埋め込みモデル / リビジョン:
元文書の時点:
索引を作成した日時:

バックアップするものも分ける

元文書フォルダーは、失うと困る正本として優先的にバックアップする。

RAGの索引も復旧時間を短くするため保存する価値はあるが、「元文書から再生成できるもの」なのかを先に決めておく。

Open WebUIのようにアップロード文書やベクトルDBが永続データへ入るソフトでは、アプリ全体の保存先とバックアップも別に確認する。

更新できたことと、回答が正しいことを分ける

ファイル更新が索引へ反映されたことと、LLMが正しい回答を返すことは別の問題だ。

RAGの仕組みから整理したい場合は、ローカルRAGとは？追加学習との違いへ進める。更新後の回答が正しい根拠を使っているかは、RAGの出典が主張を本当に支えるか確認する方法で別に確認できる。