RAGとは？生成AIが外部データを参照する仕組み

RAG（Retrieval-Augmented Generation、検索拡張生成）は、回答を作る前に外部の資料を検索し、見つかった部分をモデルへ渡して回答に使う仕組みです。資料をモデルへ再学習させることとは異なります。社内規程や更新されるFAQを参照したい場合に候補になりますが、検索が間違えば回答も誤るため、根拠表示と検索品質の検証が必要です。

回答ができるまでの流れ

表は横にスクロールできます

段階	システムがすること	ここで起きる失敗
1. 資料を用意	文書を取り込み、アクセス権や更新日などの属性を持たせる	古い文書、権限外資料が混ざる
2. 検索単位を作る	長い文書をchunkに分割し、検索用indexを作る	見出しと本文が分かれ、意味が欠ける
3. 質問を受ける	queryと近い資料・箇所を探す	別の意味の語や古い版が上位に来る
4. contextを作る	取得した箇所を質問と一緒にモデルへ渡す	不要な箇所で重要な情報が埋もれる
5. 回答を生成	contextに基づいて文章を作る	資料外の補完や誤読が起きる
6. 結果を確認	回答と参照資料を利用者へ示す	参照箇所と回答の対応が分からない

RAGの品質は生成モデルだけで決まりません。資料の取り込み、分割、検索、権限フィルタ、回答指示、評価方法がつながって結果を作ります。資料が検索対象に入っていても、質問に合った箇所が取得されなければ、モデルは不足したcontextから推測する可能性があります。

社内FAQの具体例

例として、社員が「出張精算の領収書はいつまでに提出するか」と尋ねる社内FAQを考えます。資料側には規程PDFと経費申請手順があり、同じ提出期限でも対象となる出張や例外が異なるとします。

検索に成功した場合、システムは期限の記載と適用条件を含む箇所を取得します。モデルへ渡す材料は、質問、取得した本文、文書名、更新日、ページや見出しなどです。望ましい回答は、期限だけを断定するのではなく「国内出張についてはこの条件。海外出張は別項目を確認」と範囲を示し、該当する規程箇所へ利用者を案内します。

検索結果に期限の数字だけが含まれ、適用条件が含まれなければ、回答はもっともらしくても誤るおそれがあります。システムは「根拠資料に条件が見つからない」として追加確認を求めるか、担当者への問い合わせを案内すべきです。RAGを組み込んだだけで正確性や出典の適切さが保証されるわけではありません。

何を評価すればよいか

表は横にスクロールできます

観察するところ	テスト方法	合格の考え方
必要な資料が検索されるか	同じ意味を別表現にした質問を用意	正しい版・権限内の箇所が上位に来る
条件が揃っているか	例外付きの質問と通常質問を分ける	回答に必要な適用条件まで取得される
回答が資料に沿うか	回答中の各主張を根拠箇所と照合	資料にない数字や条件を断定しない
分からない質問に止まれるか	資料に存在しない質問を混ぜる	不明と説明し、創作で埋めない
更新が反映されるか	新旧版を入れ替え検索結果を確認	廃止版が残る条件を把握している
権限が守られるか	権限の異なる利用者で検索	閲覧できない資料を取得しない

評価は「回答文が自然か」だけでは足りません。検索された資料の適合性と、生成文がその資料の範囲を越えていないかを別々に見ます。誤答が起きたら、まず該当文書が取り込まれたか、適切な分割になっているか、検索に出たか、フィルタで除外されていないか、回答が根拠を守ったかの順に切り分けます。

chunkと検索設計で変わること

chunkが大きすぎると、検索結果に無関係な段落まで含まれ、contextを圧迫します。小さすぎると、定義と例外、見出しと本文、条件と対象が分かれて意味が欠けることがあります。最適な長さを一律の文字数で決めず、文書構造と実際のqueryを使って評価します。

検索方式も一種類とは限りません。意味の近さを使う検索、キーワードを使う検索、属性による絞り込みなどを組み合わせる構成があります。ただし手法を増やすだけで精度が上がるとは言えません。まず実際に必要な質問、期待する根拠箇所、誤検索例を集め、変更前後を同じセットで比較します。

更新頻度の高い資料を使う場合は、同期遅延、削除済み資料の残存、同一文書の重複にも注意します。検索結果に文書ID、版、更新日時を保持すれば、利用者や運用者が古い根拠を見つけやすくなります。個人情報や機密資料を使う場合、誰の権限で検索するか、検索ログに何が保存されるかもデータフローとして設計してください。

うまく答えないときの切り分け

• 該当資料がない：取り込み対象、同期状態、ファイル形式を確認する

• 別資料が出る：検索語、属性filter、同義語、文書の見出しを見直す

• 条件が欠ける：chunk境界が例外条件を分離していないか確認する

• 古い回答になる：更新後のindex反映、旧版の削除、キャッシュを確認する

• 根拠と異なる答え：回答が引用箇所を超えて推論していないか評価する

• 権限外情報が出る：検索主体とアクセス制御、index内の権限属性を調査する

この表は原因を決めつけるものではありません。RAGの不具合をすぐモデルの性能不足とみなさず、資料、検索、権限、生成のどこで情報が変わったかを分けるための初動です。

小さく始める手順

1. 対象となる一つの業務と、参照してよい資料を決める

2. 実際の質問から、通常・言い換え・例外・資料にない質問を用意する

3. 期待する根拠箇所と、回答に含める条件を記録する

4. 文書を取り込み、検索結果と参照箇所を確認する

5. 回答の主張を根拠へ結び、見つからない場合の停止を確認する

6. 更新・削除・権限変更の反映を試す

7. 評価結果と失敗例を残し、業務へ広げる前に再測定する

最初から全社文書を投入する必要はありません。アクセス権や更新責任が曖昧な資料を広く追加すると、検索結果を追えなくなります。限定した資料群で運用・評価方法を作ってから、対象を広げるか判断します。

AIものさしの判断

RAGは、変わる資料を回答時に参照したいときの設計候補です。「RAGにすれば hallucination がなくなる」とは考えず、検索で何が見つかり、回答のどの部分がその根拠に対応するかを評価します。社内検索なら、精度だけでなく資料の権限、版管理、削除反映、引用確認を受け入れ条件に含めます。

適切な資料を検索できても、回答がその範囲を超えることはあります。回答を業務判断へ使う前に、重要な主張を参照箇所と照合できるUIと、根拠不足時に止まる経路を用意してください。資料が少ない、更新責任がない、評価用質問が作れない場合は、まず文書管理と利用条件を整えるのが先です。

出典を回答へ結び付ける

利用者に根拠を示すには、回答本文だけでなく、どの資料のどの版・箇所が使われたかを保持する必要があります。文書名だけを表示すると、同じ文書の旧版と最新版を区別できないことがあります。文書ID、更新日、見出しやページ番号を含め、クリックしたら該当箇所へ戻れる形を検討します。引用を生成文から後付けするのではなく、検索結果の識別子を回答生成まで引き継ぐ設計が安全です。

機密資料を扱う場合、検索結果がそのままモデルへ渡ることを前提に、利用者ごとのアクセス制御を確認します。共有indexに権限属性を付ける場合も、更新・削除や異動時に権限が反映されるかを試します。評価では「答えられたか」と「閲覧できる人だけに資料が出たか」を別々の合否項目にします。回答ログへ文書本文を丸ごと保存する必要があるかも見直し、保持期間と閲覧者を決めます。

回答欄に出典を付けても、その出典が回答の主張を支えているとは限りません。評価者は、回答を主張単位へ分け、根拠の段落が対象、期間、例外まで含むかを確認します。数字や期限はとくに原文へ戻します。根拠が不十分な回答を、引用が付いているという理由で自動的に正しいと判定しないでください。

初期pilotの合格条件

pilotを始める前に、利用部門と「この状態なら回答を表示する」「この状態なら確認へ戻す」を合意します。例えば、参照資料が1件だけで必要条件を含む場合は回答候補を表示し、複数の規程が矛盾するときは担当者確認へ回します。回答の正しさだけでなく、sourceが現行版か、質問者が閲覧できる資料か、更新が反映されているかを別に記録します。

最初の対象業務が複数部門へ広がると、同じ言葉でも意味や権限が異なります。pilotの範囲、利用者、資料セット、評価期間を明記し、範囲外の質問には回答を保証しないよう表示します。

利用者に見せる回答の形

回答には結論、適用条件、参照資料を分けて表示します。たとえば「通常の申請期限は○日です」と断定する前に、取得した規程が対象年度と部門に合うかを確認し、対象が一致しない場合はその旨を伝えます。回答を短くしても、判断に必要な例外や参照先を消してしまわないことが重要です。

社内FAQなら、利用者が訂正や資料更新を依頼できる経路を設けます。誤った回答を報告した人、参照した資料、修正後に同じ質問を再評価した結果を記録すると、検索設計と文書管理のどちらを直すべきか学びやすくなります。

評価セットの作り方

評価用の記録には、質問、期待する資料と見出し、検索結果上位3件、回答の根拠箇所、合否、原因を残します。例えば「出張精算の期限」なら、通常条件の質問、海外出張など例外を含む質問、資料にない制度を尋ねる質問を用意し、どの規程のどの見出しが必要かを先に決めます。回答は結論、適用対象、例外、引用先に分け、引用が数字だけでなく対象期間や条件まで支えるかを確かめます。資料に答えがない質問では、制度を創作せず「記載が見つからない」と伝え、担当窓口へ案内する状態を合格とします。

1. 検索：質問を言い換えても、現行版の該当条件が検索上位に出るか。2. 回答：期限の数字だけでなく、適用対象と例外まで根拠に含めたか。3. 根拠不足：資料にない制度・期間を尋ね、推測で埋めず停止できるか。4. 権限：閲覧権のない利用者で同じ質問をし、検索結果・回答・引用に機密資料が出ないか。5. 更新・削除：文書を改訂・撤回した後、旧版の回答が残らないか。反映までの時間と再確認方法も記録します。

結果を一つにまとめて「合格」とせず、検索、回答根拠、権限、更新反映を別々にPASS / FAILで残します。失敗時は、資料の取込み→分割→検索・filter→回答生成のどこで期待と違ったかを追います。権限外情報が出た場合は、回答文の指示だけで済ませず、利用者の権限と検索indexの結び付きを確認します。これは初動の切り分け順であり、原因を確定する前に修正箇所を決めつけません。再試験は同じ質問・資料版・利用者権限をそろえ、変更前後を比べます。

質問の種類は、通常、言い換え、条件付き、資料にない内容、閲覧権限外、改訂前後を分けます。少なくとも一つずつ用意すれば、普段の質問だけで成功率を見誤るのを避けられます。記録欄は「ケースID／利用者の権限／質問／期待する資料・見出し／実際の検索結果／回答の主張と引用／判定／再現条件」とします。例えば、閲覧権限外の質問では「回答に出なかった」だけでなく、検索結果にも文書名や断片が含まれなかったかを確認します。更新テストは改訂後の文書を検索できるかだけでなく、旧版が検索上位に残る条件も記録します。対象を増やすときは、失敗した質問を次回の固定テストへ加え、変更前後で同じ条件を再実行します。

合格基準は実行前に決めます。例えば「権限外資料を検索結果に出さない」は0件条件にし、通常質問への適合率などは、誤答時の影響と人による確認体制から部門が許容値を決めます。結果を見てから基準を緩めず、対象業務、質問セット、資料版、利用者権限、評価者も記録してください。