▼ この記事の内容
結論要約：RAGは、質問に関係する文書を検索し、その抜粋をLLMへ渡して回答を作る構成です。回答が不適切なときは、検索候補、取得した文書の版、LLMへ渡した文脈、回答と根拠の一致を分けて確認します。
RAGは、質問に関係する文書を検索し、その抜粋をLLMへ渡して回答を作る構成です。LLMそのものが常に検索するわけではなく、検索と文脈の組み立てはアプリケーション側の設計に含まれます。
回答が不適切なときは、モデルだけを替える前に、検索候補、取得した文書の版、LLMへ渡した文脈、回答と根拠の一致を分けて確認します。この記事では、架空の社内規程を題材に、その確認箇所を追います。
表内の「デモ機貸出規程」は説明のための架空例です。
LLMに検索結果を渡して回答するRAGの仕組み
LLMは入力された質問や文書から文章を生成します。RAGでは、その入力を作る前に関連文書を検索し、質問と検索結果を合わせてLLMへ渡します。検索対象の文書、検索方法、回答で参照箇所を示すかどうかは、個別のシステム設計で決まります。
LLM単体とRAGで参照する情報を比べる
違いは、回答時に使う入力にあります。LLM単体でも人が文書を入力すればその内容を踏まえられますが、RAGは質問に応じてシステムが候補を取得し、回答用の文脈を作る工程を加えます。
| 比較項目 | LLM単体 | RAGを組み込んだ構成 |
|---|---|---|
| 回答時の入力 | 質問と人が渡した文書 | 質問とシステムが取得した抜粋 |
| 検索 | 入力前に人が選ぶ | 質問ごとに候補を取得する設計にできる |
| 更新の確認箇所 | 入力した資料 | 文書・索引・取得した版 |
| 共通する役割 | 入力をもとに文章を生成する | |
検索結果を渡しても、回答の正確さや最新性が自動で保証されるわけではありません。どの抜粋を取得したかを確認できるようにしておくと、回答の確認先をたどれます。AWSのRAG解説も、検索した外部データを生成時の文脈に加える構成として説明しています。
参考：RAG とは何ですか?｜AWS
再学習や長い文脈入力との役割の違い
RAGは、質問に応じて外部情報を取得し、回答生成の入力へ加える構成として使われます。検索を実行する条件や頻度は、アプリケーション側の設計で決まります。モデルの振る舞いを追加学習で調整する方法とは役割が異なります。また、長い文書を一度に入力できても、関連箇所を探すことや、現行版だけを選ぶことが自動で済むわけではありません。AWSのRAG解説では、再学習ではなく外部情報を生成時の入力へ加える構成として説明されています。
参考：RAG とは何ですか?｜AWS
少数の資料を人が選んで要約するだけなら、検索機能を設けずに入力する選択もあります。更新頻度、文書量、質問ごとに資料を選ぶ担当者がいるかを見て、検索が必要な範囲を決めます。
一つの質問で検索から回答生成までを追う
RAGでは、質問前の文書準備と、質問後の検索・文脈組立・生成を区別します。ここでは「デモ機は何日借りられるか。延長できるか」という架空の質問を使います。
文書を分割し出典と版を索引に残す
索引を作る工程では、文書を検索しやすい単位に分け、文書ID、版、適用日、閲覧条件などの情報を対応づけます。分割の大きさに万能な値はなく、質問と原文を行き来できる単位で設計します。
| 索引に残す項目 | 架空の記入例 | 確認する理由 |
|---|---|---|
| 親文書・版 | D101 v2「デモ機貸出規程」 | 旧版と区別する |
| 抜粋ID | c201：標準貸出は7日 | 回答の根拠へ戻る |
| 抜粋ID | c202：延長は担当承認後に確定 | 条件を別に確認する |
| 閲覧属性 | 営業一般はD101のみ | 取得対象を制限する |
Microsoft LearnのRAGと索引の解説では、文書のチャンク化や検索用の索引をRAGの構成要素として扱っています。検索方式や保存先は用途で選ぶため、特定のデータベースを必須とはみなしません。
参考：Retrieval augmented generation (RAG) and indexes in Azure AI Search｜Microsoft Learn
質問に関連する文書候補を検索する
検索では、質問に関係しそうな抜粋を候補として取り出します。型番や制度名のような一致語を探す方法、意味の近さを使う方法、両方を組み合わせる方法があります。候補の関連度は、回答の正しさや閲覧権限を示すものではありません。検索方式や索引の設計によって確認点が異なることは、Microsoft LearnのRAGと索引の解説でも説明されています。
参考：Retrieval augmented generation (RAG) and indexes in Azure AI Search｜Microsoft Learn
この質問ならc201とc202が候補になります。D102「個別契約A」は、個別契約を扱う権限がない利用者には候補へ出さない条件を、検索前または検索時に適用します。
質問と根拠を文脈に入れて回答を生成する
アプリケーションは、質問と取得した抜粋をLLMへ渡します。この時点で、検索結果にあった情報が実際に文脈へ入ったか、どの版を使ったかを記録できるようにすると確認しやすくなります。
| 入力・出力 | 架空の記入例 |
|---|---|
| 質問 | デモ機は何日借りられる？ 延長できる？ |
| 渡す根拠 | c201、c202、D101 v2 節2 |
| 回答例 | 標準貸出は7日です。延長は担当承認が必要で、延長日数は資料から確定できません。 |
| 保留する内容 | 延長も7日、と推測して補わない |
Microsoft Architecture Centerの設計・評価ガイドは、取得、文脈の組立、生成を分け、検索と回答を別々に評価する観点を示しています。資料にない日数は、もっともらしい補足ではなく未確認として扱います。
参考：Design and develop a RAG solution｜Microsoft Learn
根拠があっても誤る原因を工程別に整理する
回答が期待と異なる場合、根拠が存在することだけでは原因を決められません。検索に出なかったのか、出たが文脈から落ちたのか、文脈にあったのに回答が根拠から外れたのかを分けます。Microsoft Architecture Centerの設計・評価ガイドも、検索・文脈組立・生成を分けて評価する観点を示しています。
参考：Design and develop a RAG solution｜Microsoft Architecture Center
検索漏れと古い版の取得を切り分ける
まず、期待する抜粋が候補に入ったか、取得した親文書と版は何か、権限や日付のフィルタで除外されていないかを確認します。元文書を更新しても、索引の更新が別工程なら旧版が残ることがあります。
| 観察した状態 | 最初に見る箇所 | 確定しないこと |
|---|---|---|
| c202が候補にない | 検索条件、分割、索引登録 | モデルの原因とは限らない |
| D101 v1が取得された | 更新時刻、版フィルタ、索引更新 | 原文更新だけで解決したとは限らない |
| 権限外D102が候補にある | 利用者属性と検索条件 | 画面で隠せば安全とは限らない |
この記録を確認せずにモデルを変更すると、どの工程を直したのか分からなくなります。原因は仮説として残し、再現した入力と取得結果を照合して判断します。
文脈不足と根拠にない生成を切り分ける
候補に根拠があっても、LLMへ渡す文脈に含まれていなければ回答には使えません。反対に、文脈に承認条件があるのに「必ず延長できる」と答えた場合は、回答と根拠を照合する段階を確認します。RAGでは検索結果の選定から回答生成までを分けて評価する考え方があり、Microsoft Architecture Centerの設計・評価ガイドも工程ごとの確認を扱っています。
参考：Design and develop a RAG solution｜Microsoft Architecture Center
出典へのリンクが表示されるだけでは、回答全体が正しいとは判断できません。根拠にない条件、矛盾する文書、質問に必要な前提が欠ける場合は、回答を保留し、文書オーナーまたは担当者へ追加確認を戻します。
権限と更新を含めてRAGの動作を確認する
RAGの確認は、正答らしい文章を一度返せたかでは終わりません。誰がどの文書を取得できるか、更新後の版を参照したか、根拠がない質問を保留できたかを、質問ごとに見ます。
利用者に見せてよい文書だけを取得する
ログインしていることと、検索結果に文書単位の権限が反映されていることは別です。回答を作った後で隠すのではなく、検索対象を決める時点で閲覧条件を扱えるか確認します。
| 利用者の条件 | 取得してよい架空文書 | 確認する結果 |
|---|---|---|
| 営業一般 | 公開範囲のD101 | D102が候補にない |
| 個別契約の担当者 | 権限確認済みのD101、D102 | 契約条件の根拠をたどれる |
| 未認証 | 業務文書を検索しない | 検索要求を保留する |
Microsoft Learnの「Retrieval augmented generation (RAG) and indexes in Azure AI Search」解説では、検索時にセキュリティ条件を扱う設計例が説明されています。ここでの表は特定サービスの設定手順や実稼働結果ではなく、確認すべき入力条件を示すものです。
参考：Retrieval augmented generation (RAG) and indexes in Azure AI Search｜Microsoft Learn
検索結果と回答を分けて評価する
確認用の質問には、答えが資料にあるものだけでなく、資料にないもの、旧版を前提にしたもの、曖昧なものも含めます。質問数の固定値ではなく、利用場面で起こりうる判断をカバーできるかで選びます。検索結果の取得と回答の評価を分け、質問の種類や評価観点を設計することは、Microsoft Architecture CenterのRAG評価ガイドでも扱われています。
参考：Design and develop a RAG solution｜Microsoft Architecture Center
| 架空の質問 | 取得結果で確かめる点 | 回答で確かめる点 |
|---|---|---|
| 標準日数は？ | D101 v2・c201 | 7日と根拠を対応させる |
| 延長日数は？ | c202に日数がない | 追加確認へ戻す |
| 個別契約額は？ | 権限別のD102取得 | 権限外なら保留する |
| 以前は14日だった？ | 旧版ではなく現行版 | 現行条件と版を示す |
| あれ、延長は？ | 対象を特定する追加質問 | 曖昧なまま断定しない |
検索で必要な根拠を取得できたかと、回答がその根拠の範囲に収まったかは別の確認対象です。この区別があると、更新・検索・生成のどこへ修正を戻すかを決めやすくなります。
RAGを使う範囲と人に戻す条件を決める
RAGは、複数の文書から根拠を探し、更新や権限を確認しながら答える用途に向きます。一方、固定された回答だけで足りる用途や、原文が確認できない判断は、別の方法または人の確認へ戻します。
文書検索が必要な用途と固定回答で足りる用途を分ける
営業時間や申請窓口のように回答が固定され、変更の経路も明確な質問は、固定FAQで管理しやすい場合があります。特定の資料を一時的に要約したいだけなら、人が資料を選んでLLMへ入力する方法もあります。
複数文書をまたぐ質問、文書の版や閲覧条件で答えが変わる質問では、検索対象と根拠の確認を設計する余地があります。FAQとRAGの使い分けも、回答の固定度と参照情報の扱いを比較する際の補足になります。
営業AI・営業DX FAQシステム比較は機能数より回答根拠と更新運用で失敗を防ぐ
RAGの基本概念を先に確認したい場合は、AI RAGの基礎も参照してください。営業資料や商談準備での使い方は、RAGを営業で使う実務手順で扱っています。
営業AI・営業DX AIで使うRAGとは？社内資料を検索して回答に活用する仕組みと確認方法
営業AI・営業DX RAGを営業で活用する方法｜効く業務の見極めと失敗しない始め方
原文がない質問は追加確認に戻す
根拠文書がない質問、文書間で矛盾する質問、利用者に見せてよいか判断できない質問は、生成で埋めない条件を先に決めます。回答画面には、確認する担当、必要な文書、再確認のきっかけを示せるようにします。
この条件はRAGを使わない理由ではありません。答えられる範囲と人に戻す範囲を分けることで、根拠のない回答を業務判断に使わないための境界になります。
まとめ
RAGは、関連文書を検索し、その抜粋をLLMの回答生成に渡す構成です。LLM単体との違いは、回答時の入力へ検索工程を加える点にあります。
不適切な回答を確認するときは、検索候補、取得した版、文脈への組立、回答と根拠の一致を分けます。資料にない内容や権限を確認できない内容は、推測せず追加確認へ戻す条件を決めておくと、改善箇所を特定できます。
