この記事で分かること／分からないこと
- 分かること: 削除要求が原本・索引・生成物・会話ログという複数の場所に及ぶ構造
- 分かること: 索引からの削除だけでは生成物や過去の回答文が残る理由
- 分からないこと: 削除要求への対応にかかる日数や法令上の期限の基準
- 分からないこと: 自社の社内文書RAGでの実測データ（自社データはまだ無い）
削除要求は1か所では終わらない
社内文書RAGにおいて、ある文書についての削除要求が来たとき、「削除した」と言うためには、その文書に関わる情報がどこに、いくつ存在しているかをまず把握する必要がある。自社の実装(実体: docs/STORAGE_AND_BILLING.md)では、投入した原本、検索・生成のために作られた生成物(根拠の全集合や質問のバリエーションなど)、実行時に毎回参照する確定配信用の索引が、それぞれ別の場所に分けて置かれている。この構造は、実行時の参照を索引だけに絞ることで運用コストを抑えるための設計判断だが、同時に、「どこか1か所を消せば全部消える」という単純な削除にはならない構造でもある。
索引を消しても生成物には残る
実行時に毎回参照されるのは索引であるため、索引から対象の記述を消せば、それ以降の検索や回答にはその内容が使われなくなる。しかし、索引とは別に保存されている生成物、たとえば過去にビルド時点で作られた根拠の全集合や、想定質問のバリエーションには、削除前の内容がそのまま残っていることがある。索引の役割は「これから何を使って答えるか」を決めることであり、過去に作られた生成物の中身を遡って書き換えるものではない。索引を消したことをもって「削除が完了した」と扱うと、生成物の側に元の内容が残ったままになる。
過去の回答と会話ログという第三の場所
索引と生成物に加えて、過去に実際に配信された回答の文面や、それを記録した会話ログにも、削除対象の内容が文として残っている可能性がある。これは索引や生成物とは別の場所であり、索引側の対応だけでは扱えない。ある文書について削除要求を受けたとき、その文書の内容が過去にどのような回答文として配信されたかを把握するには、誰が何を引いたかを記録した監査ログが手がかりになる。この記録の設計については監査ログの記事で扱っている。
削除の範囲を先に決めておく
原本・生成物・索引・会話ログ・監査ログのうち、削除要求に対してどこまでを対象にするかは、要求を受けてから都度判断するのではなく、あらかじめ運用として決めておく必要がある。たとえば、索引からの削除だけを「削除」と呼ぶのか、生成物や過去の回答文の書き換え・再生成までを含めるのかによって、対応にかかる作業も、削除完了と言える範囲も大きく変わる。この記事では、対応にかかる日数や法令上の期限といった基準までは扱わない。扱っているのは、削除要求が実際にはどこに及ぶ問題であるかという、構造の整理である。
よくある質問
Q1. 索引から消せば削除は完了したと言えるか
言えない。索引を消せば以降の検索や回答には使われなくなるが、別の場所に保存されている生成物や、過去に配信済みの回答文には、削除前の内容が残っている場合がある。
Q2. 生成物に元の内容が残るとはどういうことか
索引とは別に、根拠の全集合や質問のバリエーションといった生成物が保存されており、索引の削除はこれらの生成物の中身を遡って書き換えるものではないため、元の内容が残ったままになりうる。
Q3. 過去の会話ログはどう扱うべきか
会話ログには過去に配信された回答文が記録されており、削除対象の内容が含まれている可能性がある。削除の範囲にログを含めるかどうかを、要求を受ける前に決めておく必要がある。
Q4. 削除の範囲をどう決めればよいか
原本・生成物・索引・会話ログ・監査ログのうち、どこまでを削除の対象とするかを運用としてあらかじめ定めておく必要がある。この記事では対応日数や法令上の期限の基準までは扱わない。
削除要求への対応は、索引という1か所を見るだけでは足りない構造になっている。出典の見せ方という別の論点は引用表示という論点の記事で、複数のやり取りを事後に追跡する仕組みは監査ログの記事で扱っている。複数サービスの比較はRAGサービス比較15選を参照してほしい。社内文書RAGの権限設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: 出典提示の設計とその限界
- 関連記事: 監査ログの設計
- 関連記事: 出典を示すこと自体が漏れになる