社内検索にRAGを導入する判断基準｜資料と回答の確認から始める

社内検索にRAGを導入するかは、自然な文章で答えたいという希望だけでなく、必要な資料を適切に取り出せるか、根拠を確認できるかで判断します。RAGは検索した資料を生成AIの回答材料として使う方式ですが、誤った資料の参照や解釈を防ぐ保証はありません。まず、今の検索で何に困るかを整理してください。

社内検索の課題を分ける

資料の場所が分からない、名称が揃っていない、最新版が分からない、複数の資料を読まないと答えられないなど、検索の困りごとは異なります。保存場所や版管理が原因なら、整理や既存検索の改善が先に必要な場合があります。生成AIを追加すれば元資料の問題も解消する、と考えないことが大切です。

導入対象には、繰り返し聞かれる質問と、それへ答える資料を対応させます。資料に答えがない質問まで含めると、回答の正しさを評価できません。根拠を持つ回答が必要なのか、資料候補が見つかればよいのかも分けて検討します。後者なら既存検索で足りる可能性があります。

資料が文字として取得できるか、表や図に必要な情報があるか、同じ内容の古い版が残っていないかを確認します。見た目で読める文書でも、検索処理が見出しや表の関係を正しく扱えるとは限りません。実際の資料を使い、必要な部分が取り出されるかを確かめます。

資料の管理者、更新の通知、廃止の扱いも必要です。古い手順が検索対象に残ると、自然な文章で誤った案内が作られる可能性があります。更新日時だけでは最新版を判断できない文書もあるため、有効な版を識別する情報や管理のルールを整えます。

人が閲覧できない資料を、回答経由で知ることがないようにする必要があります。検索結果の一覧を隠すだけではなく、回答を作る材料として取得されないかを確認します。利用者の権限、部署をまたぐ共有、異動時の変更など、自社のアクセス管理に合うかを検証してください。

答えが資料にない場合は、推測で案内するより確認できないことを示す設計が適します。参照元の文書名や該当箇所を確認できると、人が業務で採用する前に検証しやすくなります。ただし、参照元が表示されても、その文書が回答の全主張を裏付けているかは別途確認が必要です。

社内申請の案内を対象とする想定例では、「通常の申請手順」「例外条件に当たる申請」「古い手順と異なる質問」「本人に権限がない情報」「資料に書かれていない相談」を用意します。正しく答えられる質問だけでなく、答えないほうがよい質問も試すことが要点です。

評価表には、期待する根拠、取得された資料、回答の一致、根拠にない補足、確認が必要な点を記録します。文章の読みやすさと業務上の正確さを分けて見ます。質問の言い換えや誤字を含め、普段の利用者が使う表現でも必要な資料に届くか確かめます。

回答が誤った場合は、必要な資料が取得されなかったのか、取得後の解釈を誤ったのかを分けます。前者なら資料の分け方、検索語、資料の形式などを見直します。後者なら回答の条件や出力方法を検討します。原因を見ずに指示文だけを増やすと複雑化しやすくなります。

評価に使った質問だけへ合わせ込むと、未知の質問への弱さが残ります。業務で質問を受ける人から追加例を集め、まだ試していない質問も使います。問い合わせ履歴に機密情報がある場合は、検証用に適切に加工し、その利用条件を確認してください。

導入後には資料の更新、権限の管理、誤回答の確認、サービス変更への対応が必要です。回答を作る費用だけでなく、検証や文書整理の作業も見積もります。利用者が迷ったときに誰へ相談するか、誤りをどう報告するかを決めないと、使われない仕組みになりやすくなります。

重要な判断を伴う業務では、回答をそのまま結論にせず、元資料や担当者で確かめる導線を設けます。試行で得た結果を踏まえ、対象を広げる、資料候補の提示にとどめる、既存検索を改善するという選択肢を比較します。RAGの採用自体を目的にしないことが大切です。

文書を入れればすぐ正しく答えますか。資料の品質、取得方法、質問の範囲で結果は変わります。実際の業務質問を使った検証が必要です。

資料が少なくても使えますか。量だけでは決まりません。複数資料を横断する必要があるか、既存検索より確認しやすくなるか、運用負担を含めて判断します。