RAGとは？資料を探してから答える仕組みを図解

RAGの基本処理は「探す → 渡す → 答える」

RAG（Retrieval-Augmented Generation：検索拡張生成）は、質問に関連する社内ドキュメントなどの外部資料を検索し、そのテキストをモデルの入力に加えて回答を生成させる手法です。

たとえば社内備品の貸出ルールを案内する場合、まず質問に該当する社内規程をシステムが探し出し、「以下の規則に基づいて回答してください」という指示とともにモデルへ渡します。検索された資料はあくまで各リクエストの一時的な入力情報であり、資料を追加するたびにモデル自体のパラメータを再学習させる仕組みとは異なります。

資料検索の流れをデモで確認する

次のデモには、架空の社内貸出ルールが3件登録されています。質問を切り替えることで、検索によって取得された資料と、それをもとに組み立てられた回答例を確認できます。

リストから「タブレットは借りられる？」を選択すると、一致する資料が見つからない状態が再現されます。このような場面では、他の備品の規定を勝手に当てはめて推測するのではなく、「該当する資料がないため回答できない」と明示することが重要です。

検索の精度が回答の品質を左右する

資料をモデルに渡す構成を作っても、適切な資料を取り出せなければ正しい回答は得られません。まず注視すべきなのは、検索処理が必要十分な情報を過不足なくヒットさせているかという点です。

実際のシステムでは、キーワードによる全文検索や、意味の類似度を計算するベクトル検索、あるいはそれらを組み合わせたハイブリッド検索が用いられます。どの検索手法を採用するかを検討する前に、想定される質問パターンと、その根拠となる正解ドキュメントのペアを用意しておくと、検索精度の良し悪しを客観的に評価できます。

• 「PC」「パソコン」「ノート端末」といった表記の違いを拾えるか。
• 古い規則と新しい規則が両方あるとき、対象の日付を区別できるか。
• 見出しだけを取り出して、直後の例外条件を落としていないか。

ドキュメントを短く分割して保存すると検索のヒット率は上がりやすくなりますが、一方で前後の文脈や適用条件が途切れてしまうリスクが生じます。質問に対して取得されたテキストを実際に読み、回答作成に必要な文脈がしっかり収まっているかを点検しましょう。

「検索の失敗」と「生成の失敗」を切り分ける

AIの回答に食い違いが生じた場合、慌ててプロンプトの調整だけに走るのではなく、まずは検索結果のログを調べます。回答の根拠となる記述がモデルに渡っていなければ、モデル側で正しい答えを出しようがないためです。

たとえば検索結果に「貸出期間は7日。ただし研修用途は14日」と記載されているにもかかわらず、研修に関する質問に対して「7日」と出力された場合は、生成フェーズで条件の読み落としが発生したと判断できます。同じ資料を入力としてプロンプトの表現を変え、現象が再現するかどうかを検証していきます。

まずは少数の資料と質問で検証を始める

最初から社内の全ドキュメントを一括で登録するのではなく、まずは代表的な質問10件程度と、それに対応する根拠資料を手元に揃えてスタートすると、ボトルネックの特定が格段にスムーズになります。生成された回答に加えて、実際にヒットしたドキュメントや根拠の該当箇所、回答不能となった質問の記録も残しておきましょう。

社内文書を扱うにあたっては、検索のヒット範囲と各ユーザーの閲覧権限の連動設計も欠かせません。画面上で表示を伏せるだけでは不十分であり、権限のない機密資料がプロンプトへ組み込まれた時点で情報漏えいのリスクが生じます。アクセス権を持つユーザーに対してのみ該当文書を渡す制御が、安全な運用の大前提です。