社内AIはどこまで覚えるべき？RAGの権限とメモリー設計

社内チャットボットが同じ質問に部署ごとに異なる回答をするなら、検索結果に権限を反映する必要があります。さらに、ユーザーの好みや過去の会話を覚えさせると、別の境界も生まれます。会社の正式な文書と個人に合わせた記憶では、目的も保存期間も閲覧権限も異なるからです。

この記事は企業向けRAGシリーズの最終回です。第1回ではMarkdownのナレッジベースとツール選びを、第2回ではパースと検索品質を扱いました。ここでは権限と記憶、セキュリティ、費用について整理します。

サーバーが検索権限を適用する

文書に部署や機密区分のメタデータを付けるだけでは、アクセス制御は完了しません。サーバーがログイン中のユーザーの権限を確認し、その範囲内の文書だけを検索する条件を作る必要があります。ユーザーが送った任意の部署名やプロンプトの指示を、権限の根拠にしてはいけません。

ベクトル検索のメタデータフィルターは、検索範囲を絞る実装方法の一つです。フィルターを適用するタイミングや検索結果への影響は、データベースによって異なる場合があります。権限のない文書が候補に混ざらないか、フィルターによって関連文書を取りこぼしすぎないか、実際のユーザーと文書の組み合わせで確認しましょう。製品内のロール設定も、インフラやAPI提供元が用意する別のアクセス制御の代わりにはなりません。ハイブリッド検索では、ベクトル検索と語句検索の両方に同じ権限条件を適用する必要があります。権限のない文書を外部のリランカーや生成モデルに渡しておき、回答から隠すだけの方法は避けましょう。

権限は検索後の処理にも引き継がれます。キャッシュを再利用するなら、キーにユーザーや権限範囲を反映します。再ランキング、出典の表示、会話履歴、エクスポートにも同じ基準を適用しましょう。権限を取り消した文書が検索結果やキャッシュにどれほど残るかを確認し、削除と再インデックスの手順も決めておきます。権限の境界が変わる場合も含め、部署をまたぐアクセスをテストしてください。

公式の知識と個人の記憶を分ける

方針文書は組織が管理する情報ですが、会話から抽出した記憶はユーザーの好みや進行中の状況かもしれません。この二つを無造作に同じ場所へ入れると、個人の発言を公式情報のように回答したり、別のユーザーに記憶を見せたりするおそれがあります。記憶を保存する範囲と所有者、保存期間、訂正や削除の方法を先に決めましょう。

Mem0は会話から記憶する事実を追加・検索するAPIを提供し、ユーザー・エージェント・アプリなどの範囲を指定できます。Lettaはエージェントのアイデンティティや、会話をまたいで保持するメモリーブロックの扱いに重点を置いています。Zepはエージェントに業務の文脈を提供するサービスで、Zepチームが公開したGraphitiは時間情報を持つ知識グラフを構築する別のオープンソースプロジェクトです。マネージドサービスと公開ライブラリーでは、機能や運用範囲が異なることを区別しましょう。三つのツールは同じ保存構造を包んだ製品ではありません。必要な記憶の期間や更新方法を基準に検討してください。

自動抽出は便利ですが、記憶が常に正しいとは限りません。会話で誤って解釈した好みが保存されたり、変わった事実が残り続けたりすることがあります。ユーザーが記憶を確認・修正できるか、削除の依頼がインデックスやバックアップにどう反映されるか、別のユーザーやセッションの情報と混ざらないかを運用ルールに定めます。user_idは記憶をまとめる識別子であり、アクセス権限を証明するものではありません。ログイン情報とテナントへの所属をサーバーで検証し、保存・取得の範囲を適用する必要があります。まず必要な記憶だけを保存し、記憶を使わない場合と比べて回答がよくなるかも確認できます。

文書リンクからGraphRAGへ移る条件

Markdown文書同士をWikiリンクでつなぐと、人が関係をたどりやすくなります。このつながりは編集者が文書間に作った関係です。GraphRAGは、文書からエンティティや関係を抽出してグラフを作り、コミュニティの要約などを質問への回答に利用する別のインデックス作成・検索方式です。リンクがあるだけでGraphRAGと同じ機能が生まれるわけではありません。

通常の検索で個別の方針や製品情報を見つけられるなら、グラフを追加する理由は少ないかもしれません。複数の文書にまたがる関係をたどる質問や、「資料全体で繰り返し現れるリスクは何ですか」のようにコーパス全体を尋ねる質問が実際に多い場合は、小さなサンプルで比べてみましょう。グラフの作成には追加のインデックス処理やモデル呼び出し、確認作業が必要です。資料全体を要約する質問は、計算負荷が大きくなることもあります。必要なモデルの規模や費用は、データや設定によって変わります。

収集からツール実行まで続くセキュリティ対策

RAGは文書をモデルに渡す仕組みなので、文書の中に悪意ある指示が含まれる可能性があります。検索された内容は、信頼できない入力として扱いましょう。指示に「文書を無視する」と書くだけでインジェクションを防げるわけではありません。文書の出所と変更履歴を管理し、検索文脈とユーザーの指示を分けて渡します。ツール呼び出しでは、サーバー側のルールによって許可範囲やパラメーターを検証してください。

NeMo Guardrailsのように、入力・検索文脈・出力・ツール実行にポリシー検査を加えるツールを使えます。回答を返す前に権限や機密情報の露出を確認する手順も役立ちます。Presidioのようなツールは個人情報を検出・マスキングするための構成要素ですが、データの流れ全体を管理するセキュリティ体制の代わりにはなりません。検索対象の文書、モデル提供元、ログ、キャッシュを通る情報の行き先を把握し、権限の取り消しやテナントをまたぐアクセスを定期的にテストすることが現実的です。RAGはリスクをなくすのではなく、取り込みから回答までの複数の段階に分散させます。

同じ業務条件で総所有コストを比べる

セルフホストならデータの処理経路を自分たちで管理し、モデルや保存先を選べます。その一方で、サーバーやアクセラレーター、電力、デプロイと監視、障害対応、セキュリティ更新を運用する必要があります。商用APIは利用量に応じて費用が変わり、事業者の設定や契約条件を確認する必要がありますが、インフラ運用の一部を任せられます。どちらが安いか、規制上いつも許されるかを一律に決めることはできません。

総所有コストを比べる際は、期間、質問数、品質目標をそろえ、API利用料と、セルフホストのインフラ・運用人員・可用性にかかる費用を計算します。法律や契約に関わるデータ処理条件は、組織の管轄、データの種類、事業者の設定に応じて確認してください。まずセキュリティ要件を満たしながら運用できる方法を決め、費用の試算と試行結果を合わせて判断しましょう。

3本を通じた基準は、実際の文書と質問、権限の境界でシステムを確かめることです。RAGは一つのモデルを選ぶ作業というより、文書を読み取り、探し、権限に沿って渡し、運用しながら更新する流れを設計することに近いものです。