社内資料をAIに読ませたいと考えたら、最初に資料の整理から始めます。古い版、閲覧権限が異なる文書、根拠が不明なメモを一緒に渡すと、読みやすい回答が出ても、どの資料に基づくか判断しにくくなります。
RAGは質問に関連する資料を検索し、その内容を回答の材料として渡す仕組みです。資料を登録しただけで、最新性や権限、回答の正確さが自動的に整うわけではありません。
まず答えてほしい質問を集める
「社内のことを何でも答える」では範囲が広すぎます。たとえば「申請の提出先」「出張精算の必要書類」「手続きの締切」のように、資料で答えを確認できる質問を並べます。
各質問について、正しい答えの根拠になる文書とページ、答えがない場合の案内先を残します。答えが資料にない問いは、不足を示して人へ戻す対象にします。
登録候補の資料台帳を作る
次は架空の台帳例です。具体的な社内規程ではありません。
| 資料ID | 文書 | 版・更新日 | 管理担当 | 閲覧範囲 | 状態 |
|---|---|---|---|---|---|
| DOC-A | 申請ガイド | 確認が必要 | 総務担当 | 全社員 | 登録保留 |
| DOC-B | 部門用手順 | 確認が必要 | 部門担当 | 部門内 | 登録保留 |
元ファイルの場所、公開承認、次の見直し日、旧版を外す手順も加えます。表の「登録可」は、ファイルをアップロードしたことではなく、登録条件を確認したこととして扱います。
読める形と根拠へ戻れる形を確認する
PDFを開けることと、文章や表を正しく抽出できることは別です。見出し、表の列、脚注、ページ番号を確認します。画像中心の資料は文字認識の結果も点検し、数字や否定表現が落ちていないかを確かめます。
OpenAIの検索機能の資料では、vector storeを用いて資料を検索する仕組みが説明されています。検索で取り出す断片には、元の資料ID、版、ページなど、回答から根拠へ戻れる情報を対応させます。
断片だけでは意味が逆になる文章にも注意します。「原則として必要。ただし次の場合は不要」の後半が離れると、判断を誤る可能性があります。細かく分割すれば必ず良くなるわけではありません。
資料の権限を検索側でも守る
元の資料の権限が、別の検索基盤へ自動で引き継がれるとは限りません。誰が質問したか、どの資料を検索対象にしてよいかをアプリ側で確認できる設計が必要です。
閲覧権限の異なる資料を扱うなら、登録先の分離や検索時の絞り込みなどを検討し、権限のない資料が結果に出ないことをテストします。回答画面だけで隠しても、検索結果やログに本文が出ていれば不十分です。
外部へ資料を保存する前に、契約、データ保持、削除の条件も確認します。OpenAIのデータ管理資料では、API機能ごとの保存状態や制御を確認できます。
小さな評価セットを作ってから広げる
最初の評価には、回答がある質問、答えがない質問、古い版と混同しやすい質問、権限で回答を分ける質問を含めます。記録する項目は次の形にします。
質問:
質問者が閲覧できる資料の範囲:
期待する資料ID / 版 / ページ:
期待する回答の要点:
答えがない場合の対応:
検索結果に必要な資料が含まれたか:
回答が根拠の範囲を越えていないか:
権限外の情報が出ていないか:
人の確認結果:
検索で必要な資料が出ない失敗と、資料は出たのに回答が誤る失敗を分けます。登録量を増やす前に、どちらの問題かを確認してください。
長い資料の扱いは長文要約のプロンプト、抽出漏れの見つけ方はデータ欠損を確認する手順も参考になります。
