RAGは、質問に関連する情報を検索し、その情報を生成AIへ渡して回答を作る構成です。「ラグ」と読み、日本語では検索拡張生成などと呼ばれます。社内規程やマニュアルを根拠に回答させたいときに検討する方式ですが、資料を入れれば必ず正しく答える仕組みではありません。
導入前に見たいのは、検索する資料、閲覧できる人、回答の根拠を確認する方法です。ここでは、通常の検索や資料の直接入力と比べながら、RAGが必要かを判断する材料を整理します。
「検索してから生成する」の二段階
NRIはRAGを、関連資料の検索と、検索結果を質問とともに大規模言語モデルへ渡す生成の二段階で説明しています。NRI「RAG」
例えば「出張後の書類はどこへ提出するか」という質問を受けたとします。説明用の流れは次のとおりです。
- 質問に関係する社内案内を検索する。
- 見つかった箇所と質問を、回答を作るモデルへ渡す。
- モデルが提出先や条件を文章にまとめる。
- 利用者が根拠の案内を開いて確認する。
最後の根拠表示は導入時に確認したい設計項目です。RAGという名称だけで、参照先の表示や権限制御まで備わっているとは判断できません。また、検索結果を渡すことと、モデル自体を追加学習させることは区別します。
検索・資料の直接入力・RAGを使い分ける
選び方は、資料の量だけでなく「誰が資料を探すか」と「回答文が必要か」で考えられます。次は用途を整理するための比較です。製品の性能評価ではありません。
| 使い方 | 資料を選ぶ役割 | 向いている場面の例 | 確認する点 |
|---|---|---|---|
| 文書検索 | 利用者が検索結果から選ぶ | 原文をそのまま読みたい | 目的の文書に到達できるか |
| 資料を直接AIへ渡す | 利用者が毎回指定する | 対象が決まった短い資料の整理 | 入力可能な範囲と資料の版 |
| RAG | 検索処理が質問に応じて候補を選ぶ | 複数の文書から関連箇所を探して回答したい | 検索の適合、権限、回答と原文の一致 |
一つの案内文をたまに確認する用途なら、検索しやすい場所に原文を置く方法で足りるかもしれません。繰り返し探す負担と、RAGの文書整備・評価・運用の負担を比べることを勧めます。
回答がおかしいときは、検索と生成を分けて見る
前の例で、廃止済みの提出先が回答された場合を考えます。検索で旧版を選んだのか、正しい新版を渡したのに条件を落としたのかでは、直す対象が違います。
| 観測した状態 | 最初に確かめるもの |
|---|---|
| 関係する資料が見つからない | 資料が検索対象に入っているか、質問と文書の用語が対応するか |
| 別部門や旧版の資料が選ばれる | 適用部門、版、有効期間などの絞り込み |
| 資料は正しいが回答が違う | モデルへ渡った箇所と回答の条件・省略 |
| 根拠がないのに断定する | 資料不足のときに回答を控える動作 |
MicrosoftもRAGの課題として、質問の理解、複数情報源、入力できる情報量、アクセス制御などを挙げています。Microsoft Learn「RAGの課題」
RAGでも回答は生成処理を通ります。NISTが指摘する、もっともらしい誤りを生成するリスクを念頭に、根拠の有無と、その内容を正しく伝えているかを別々に確かめてください。NIST「Generative AI Profile」2.2
社内文書では、閲覧権限を検索にもつなぐ
全員向けの案内と、特定部門しか読めない資料を同じ検索対象にするなら、誰が何を取得できるかの設計が必要です。Microsoftの資料でも、利用者やエージェントが許可された情報だけを取得する必要性を説明しています。Microsoft Learn「Security and governance」
「回答に出さないよう指示した」だけを確認済みの根拠にしないでください。導入評価では、権限の異なる利用者で、検索候補、回答、根拠リンクのそれぞれを確かめる方針を立てます。これは運用上の提案であり、特定製品の設定手順ではありません。
導入前には、答えられる質問と答えない質問を用意する
まず一つの業務に絞り、原本の管理者が分かる資料を用意します。そのうえで、資料内に答えがある質問、条件が足りない質問、資料に答えがない質問を比べます。機能が動くことだけでなく、最後の二つをどう扱うかまで確認するためです。
原本の版や管理者が不明なら、先に文書整理を進めます。導入後の改訂や削除の反映は、RAGの文書更新で詳しく扱っています。
導入判断には「どの質問に、どの資料を根拠に、誰へ答えるか」を一文で書いてみてください。そこが定まれば、必要な検索と回答の範囲を絞れます。業務への適用については、テクノヴァースへのお問い合わせからご相談ください。