この記事で分かること／分からないこと
- 分かること: 出典提示が幻覚対策と権限設計という別々の目的を持つこと
- 分かること: 出典の見せ方に段階的な選択肢があること
- 分からないこと: どの見せ方が最も適切かを一律に決める基準（対象文書や組織の権限体系によって変わる）
- 分からないこと: 自社の社内文書RAGでの実測データ（自社データはまだ無い）
出典提示は幻覚対策であって権限対策ではない
回答に出典を添えるという設計は、根拠の無い主張を防ぐ実務として広く使われており、出典提示の設計とその限界の記事で扱ったように、自社でも機械照合(Layer1)を通す上で根拠の提示は有効に働く。しかしこの実務は「回答に根拠があるか」を扱う仕組みであって、「その根拠の出典名を、今この読み手に見せてよいか」は別の判断である。出典を示すことは、根拠のある回答を作るという目的には資するが、権限設計の目的とは一致しない場合がある。
出典そのものが機密である場合
文書の本文以上に、その文書のタイトルやファイルパス、作成部署の名前自体が機密情報である場合がある。進行中の案件の名称、評価や係争に関わる文書の分類、特定のプロジェクトの存在そのものを示すファイル名などがこれにあたる。このような場合、本文の内容を要約・言い換えの形で慎重に扱っていても、出典として文書名をそのまま提示してしまえば、それだけで「そのような文書が存在する」という情報が権限の無い読み手に伝わってしまう。出典を示すという行為自体が、「文書の内容を知らせない」という目的に反することがある。
「示す/示さない」の間にある選択肢
出典の扱いには、全部を示すか、まったく示さないかの二択だけではなく、その間に複数の選択肢がある。たとえば、文書のタイトルは示さずに、権限のある人だけが遡れる形の識別子だけを示す、社内の担当部署名だけを示して文書名は示さない、出典の存在自体を示さず本文の裏付けのみを検査対象にする、といった設計が考えられる。どの選択肢を取るべきかは、対象文書の性質や利用者の権限体系によって変わるため、ここでは一律の正解を示さない。どの設計を選んでも、選んだ理由と、その選択で守れる範囲・守れない範囲を、事後に確認できる形で記録しておく必要がある。この記録の設計は監査ログの記事で扱っている。
grounding-gateは出典の露出を見ていない
自社実装の機械照合(実体: services/verifier/src/grounding-gate.ts)は、回答中の事実主張を根拠集合と照合し、裏付けの無い主張を検出する仕組みである。この検査は、出典として提示された文書名やパスそのものが、権限のない読み手に見せてよい情報かどうかを判定していない。根拠が正しく提示されていることと、その根拠の出典名を見せてよいことは、別の軸にある判断であり、grounding-gateの合格は後者を保証しない。
よくある質問
Q1. 出典を示すことがなぜ漏れになるのか
文書の本文以上に、タイトルやファイルパス、作成部署名自体が機密である場合、出典を提示するだけで文書の存在という情報が権限の無い読み手に伝わってしまうため。
Q2. 出典を隠すとハルシネーション対策と矛盾しないか
矛盾しうる。出典提示は根拠のある回答を作るための実務として有効だが、権限設計の目的とは別の軸にあるため、両立させる設計を個別に考える必要がある。
Q3. 出典の一部だけ見せるという設計は有効か
選択肢の一つとして考えられる。文書名の代わりに識別子や部署名だけを示すなど、示す範囲を段階的に調整する設計があり得るが、どれが適切かは対象文書の性質による。
Q4. grounding-gateは出典表示の権限を検査しているか
していない。検査しているのは主張に根拠があるかどうかであり、その出典名を読み手に見せてよいかどうかは別に判定する必要がある。
出典の扱いは、根拠を示すという実務と権限設計という別の目的が交差する論点である。索引や生成物からの削除をどこまで行うかは削除要求への対応の記事で扱っている。複数サービスの比較はRAGサービス比較15選を参照してほしい。社内文書RAGの権限設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: 出典提示の設計とその限界
- 関連記事: 削除要求への対応
- 関連記事: 要約が権限の境界を溶かす