社内文書検索やRAGは、検索・生成・根拠表示・権限を分けて評価する

社内文書検索やRAGを検討するとき、「AIが質問に答えてくれるか」に注目しがちです。しかし、業務で使うRAGは一つのAI機能ではありません。

文書取り込み、分割、検索、生成、参照元表示、権限、更新、ログ、評価を組み合わせた業務システムです。

RAGを分解する

RAGはおおまかに次の処理で構成されます。

原本ファイル
  ↓ 抽出
テキスト
  ↓ 分割・メタデータ付与
チャンク
  ↓ インデックス作成
検索基盤
  ↓ 質問時検索
関連文書候補
  ↓ 生成モデル
回答案
  ↓
参照元表示・人の確認

このどこか一つが弱いと、回答の見た目は自然でも、業務では使いにくくなります。

キーワード一致や形態素解析を使う検索です。規程番号、製品名、担当者名、明確な用語を探す場合に強いです。

メリットは、結果の理由を説明しやすいことです。デメリットは、言い換えや曖昧な質問に弱いことです。

文の意味の近さを使う検索です。質問文と文書の表現が違っても、近い内容を探せる可能性があります。

メリットは、自然文の質問に強いことです。デメリットは、なぜその文書が出たのか説明しにくく、古い文書や類似文書が混ざると誤りやすいことです。

全文検索とベクトル検索を組み合わせます。社内文書検索ではこの構成が現実的なことが多いです。

たとえば、部署、文書種別、更新日、権限で絞り込み、その範囲で全文検索とベクトル検索を使います。

RAGの評価では、回答が自然かどうかだけを見ない方がよいです。

参照元を表示できても、必要な文書を検索できたこと、最新版を選べたこと、回答案が原文に忠実であることは保証されません。

社内文書検索で重要なのは、検索対象にしてよい文書と、その文書を見てよい人を分けることです。

よくある危険な設計は、全社の共有フォルダを一括で取り込み、検索結果だけ利用者に見せ分ける構成です。生成モデルへ渡す前の検索段階で権限を反映しないと、本来見られない情報が回答に混ざる可能性があります。

最低限、次を文書メタデータとして持ちます。

検索時には、利用者の所属や権限に応じて検索対象を絞ります。

RAGでは、原本ファイル、抽出テキスト、チャンク、ベクトル、質問文、回答案、ログが発生します。

外部AI APIを使う場合、質問文や検索結果をどこまで外部へ送るかを確認します。ローカルLLMや社内環境で閉じる場合、運用負荷、性能、モデル更新、保守をどう担うかを確認します。

どちらが正解というより、扱う文書の機密度、利用者数、回答速度、コスト、保守体制で選びます。

最初は対象文書と質問を絞ります。

この段階で評価するのは「全社導入できるか」ではなく、「文書の状態、検索方式、権限設計、更新運用を整えれば使える見込みがあるか」です。

RAGは、担当者の知識を置き換えるものではありません。必要な文書へ早く戻り、同じ材料を見ながら判断するための検索基盤です。