RAGとは？社内資料を検索して答える仕組みと導入前の確認点

RAGは、質問に関係する情報を検索し、その情報を生成AIに渡して回答を作る方法です。Retrieval-Augmented Generationの略で、日本語では「検索拡張生成」と呼ばれます。社内の手順書やFAQなどを回答の材料にしたいときに検討されます。AWSのRAG解説

例えば「見積書を送る前に、誰の確認が必要か」という質問に、一般的な営業手順ではなく、自社の承認ルールを使って答える仕組みです。ただし、資料を接続しただけで、必ず正しい回答になるわけではありません。

検索してから回答するまでの流れ

RAGを社内業務で使う流れを、次の五段階に分けて考えます。

長い資料は、段落や節などの小さな単位に分けて検索に使う場合があります。この単位をチャンクと呼びます。単語で探す検索のほか、文章の意味を数値の並びに変換して近い内容を探すベクトル検索や、両方を組み合わせる方法があります。RAGにベクトル検索が必須という意味ではありません。

検索用のデータを取り込む場所はインデックスと呼ばれます。分割時に本文と但し書きが離れると、条件を取りこぼす原因になります。MicrosoftのRAG解説

「必要な情報を見つけること」と「見つけた情報から答えること」は別の工程です。正しい資料が検索結果に入っていなければ、回答文の書き方だけを変えても解決しない場合があります。

RAGは、更新のたびにモデルを再学習させることと同じではありません。ただし、新しい資料を保存した後、検索対象へいつ反映されるかは、システムの更新方式で変わります。RAGと追加学習を組み合わせる構成もあります。

営業担当者向けのRAGを考えます。資料には「標準の見積書は営業責任者が確認する」「値引きを含む場合は管理担当にも確認する」と書かれているものとします。

質問が「値引きのない標準見積書は、誰に見てもらえばよいか」なら、営業責任者という答えと、根拠の箇所を示せるかを確認します。

一方、「特別な値引きを今日中に承認できるか」という質問には、資料だけで可否や期日を決められません。「営業責任者に加え、管理担当の確認も必要。今日中に対応可能かは記載なし」と返し、所定の窓口へつなぐ設計にします。

この例で確かめたいのは、流暢な文章ではなく、条件の違いと資料にない情報を区別できることです。

更新日が新しい資料が、いつでも正しいとは限りません。顧客別の例外や、未承認の案もあります。最初に業務の責任者が検索対象を確認してください。具体的な準備は社内資料をAIで検索するための手順で扱っています。

ログインして誰かを確かめることが認証、その人に何の情報を見せてよいか決めることが認可です。社内のアカウントでログインできても、検索結果が適切に絞られているとは限りません。

元資料の閲覧権限が、検索用のデータへ自動で引き継がれるかは、接続方法と設定で変わります。資料を取り込む方式なら、分割した各データにも権限情報が必要か、検索時に利用者の権限で絞れるかを確認します。元の資料へ直接検索する方式でも、利用者の権限が接続先にどう渡るかを確認します。

試験には、部署や顧客の異なるアカウントを使います。回答本文だけでなく、検索結果の断片、引用、資料名、出典リンクに権限外の情報が出ないかを見ます。異動や閲覧権限の取消し、資料削除のあとに、検索用データや一時保存にも変更が反映されるかまで確認してください。

「出典リンクが付いた」は確認の入口です。リンク先の文章を読み、その条件が質問に当てはまるかまで確かめます。

答えがある質問、資料に答えがない質問、権限の範囲外の質問を用意します。さらに、古い呼び方や曖昧な表現でも試すと、利用者の質問と資料の言葉の違いが見えます。

記録は「質問／利用者の権限／検索された資料／回答／人の判定／修正する工程」の形で残します。資料を継続して管理する方法は社内FAQの作成と更新ルールにつなげて考えます。

会話の窓口として使う場合の方式選びは、AIチャットボットの基本へ進めます。

RAGを検討するなら、社員が繰り返し聞く質問と、答えが書かれた資料を一組用意してください。社内検索の導入を相談するときも、この組があると必要な準備を具体化できます。