RAGとは？構築前に決める評価設計
目次
はじめに
社内資料をAIに読ませたい。FAQ、議事録、マニュアル、規程、提案書、過去案件の資料。これらを検索して、根拠つきで答えてくれたら便利だ。
そこでよく出てくる言葉がRAGだ。Retrieval-Augmented Generation、つまり検索拡張生成。ざっくり言えば、LLMにいきなり答えさせるのではなく、先に関連文書を検索し、その文書を材料に回答を作る仕組みだ。
ところが、RAGは「社内文書を全部入れれば賢くなる」という魔法ではない。実際に構築しようとすると、検索で違う文書を拾う。古い規程を根拠にする。似た名前の資料を混ぜる。権限のないファイルまで回答に含めそうになる。
RAGで最初に決めるべきなのは、ベクトルDBでもチャンクサイズでもない。どの質問に、どの根拠で、どの水準なら正解とみなすかだ。
RAG とは、検索と生成を分けて見る設計
AWSのRAG解説では、RAGはLLMが応答を作る前に信頼できる外部ナレッジベースを参照する流れとして説明されている。ポイントは、モデルを再学習させるのではなく、回答時に必要な情報を取りに行くことだ。
流れはシンプルに見える。
- ユーザーが質問する
- 質問に関連する文書を検索する
- 取得した文書をLLMに渡す
- LLMが回答を作る
- 必要なら出典を返す
ただし、失敗は2種類に分かれる。
検索が外れる場合と、生成が外れる場合だ。
検索が外れると、AIは最初から違う材料で答える。生成が外れると、材料は正しいのに要約や判断を間違える。どちらもユーザーには「AIが間違えた」と見えるが、直し方は違う。
RAG とは何かを理解するときも、この分解から入る方が早い。検索の品質、根拠の渡し方、回答の制約を別々に見ないと、原因の違う失敗を同じ改善策で直そうとしてしまう。
Microsoft LearnのAzure AI SearchにおけるRAG解説でも、RAGは概念としては単純だが実装には課題があると整理されている。検索、取得、プロンプト、生成、権限、評価がつながるため、単一の機能だけを見ても品質は判断できない。
RAGの構築前に評価質問を作る
RAG構築で一番効く準備は、評価質問を先に作ることだ。
よくある進め方は逆だ。文書を集め、分割し、ベクトル化し、検索をつなぎ、チャット画面を作る。動いてから「良さそうか」を見る。
これだと、最後に感想戦になる。
「だいたい合っている」
「たまに変な回答がある」
「現場で使えるかはもう少し見たい」
この状態は危ない。RAGは、質問ごとに期待する根拠が違う。人事規程、営業資料、契約書、障害対応手順では、正解の見方がまったく違う。
先に作るべきなのは、初期PoCで30問から50問程度の評価質問だ。業務領域や文書量、情報リスクに応じて増減してよい。重要なのは、業務で本当に聞かれる質問を入れること。
- 単一文書を見れば答えられる質問
- 複数文書をまたぐ質問
- 最新版と旧版が混ざりやすい質問
- 権限がない人には答えてはいけない質問
- 情報不足なら「分からない」と返すべき質問
- 根拠文書を提示してほしい質問
- 回答より担当部署への案内が正しい質問
このセットがあると、RAGの構築は一気に現実的になる。検索エンジンを変えたとき、チャンクの切り方を変えたとき、モデルを変えたとき、同じ質問 で比べられるからだ。
SIerや情シスの提案・要件定義で使うなら、この評価質問は受け入れ条件にもなる。「この質問群で、根拠つき正答率、権限外停止率、回答修正率を満たしたら検収対象にする」と置けば、PoCの感想を検収可能な条件に変えられる。
評価は4つに分ける
LangChainのRAG評価チュートリアルでは、回答の正しさ、質問への関連性、取得文書への根拠づけ、検索結果の関連性といった観点が整理されている。実務でも、この分け方はかなり使いやすい。
RAGの評価は、最低でも4つに分ける。
1. 検索結果が合っているか
質問に対して、正しい文書が取れているかを見る。ここでは回答文を見ない。検索結果だけを見る。
たとえば「育児休業の申請期限は？」という質問なら、就業規則、人事FAQ、申請手順書の該当箇所が取れているか。古いPDFや別部署向けの文書が上位に出ていないか。
検索結果が外れているなら、プロンプトを直しても限界がある。文書の分割、メタデータ、版管理、検索方式を見直すべきだ。
2. 回答が根拠に沿っているか
検索結果は正しいのに、回答が勝手に補完することがある。
「申請期限は原則5営業日前」と資料にあるのに、「1週間前」と丸めて答える。注意書きにある例外条件を落とす。対象者の条件を短くしすぎる。
ここでは、回答が取得文書に支えられているかを見る。RAG評価のサーベイ論文でも、RAGの評価対象は検索と生成の両方に分かれ、根拠性や正確性、安全性が論点になると整理されている。
3. 質問に答えているか
根拠に沿っていても、質問に答えていない回答がある。
「この申請は誰が承認しますか」と聞いたのに、制度の概要を長く説明する。これは正確でも使いにくい。社内利用では特に、短く結論を返し、必要なら根拠を添える方がよい。
評価質問ごとに、理想回答を1文で置いておくと判断しやすい。
4. 答えてはいけない時に止まれるか
RAGは、答える能力だけでなく、止まる能力が要る。
- 権限外の文書が根拠に含まれる
- 質問が曖昧で対象部署が特定できない
- 文書同士が矛盾している
- 最新版がどれか判断できない
- 個人情報や契約条件に触れる
この場合は、無理に答えず、確認先や不足情報を返す方が安全だ。Google CloudのRAG解説のように、RAGは外部ナレッジベースとLLMを組み合わせる考え方だが、どの知識を誰に渡すかはシステム側で設計しなければならない。
文書を入れる前に、根拠の単位を決める
RAGで地味に大事なのが、根拠の単位だ。
PDFを丸ごと入れるのか、見出し単位で切るのか、条文単位で切るのか。議事録なら発言単位なのか、決定事項単位なのか。営業資料ならスライド単位なのか、ページ内のブロック単位なのか。
単位が大きすぎると、検索結果は広くなる。LLMは余計な文脈を読んで、答えをぼかす。単位が小さすぎると、必要な前後関係が落ちる。
おすすめは、評価質問から逆算することだ。
「この質問に答えるには、どの粒度の根拠が必要か」を見る。規程なら条文単位がよいかもしれない。業務手順ならステップ単位。商談メモなら決定事項と未決事項を分ける。仕様書なら画面、API、権限、 例外条件で分ける。
AIエージェントに「文脈」を渡す技術でも触れているが、AIに渡す文脈は量より構造が効く。RAGでも同じだ。文書を大量に入れる前に、根拠として取り出したい単位を決める。
権限と版管理は後回しにしない
社内RAGで一番怖いのは、精度より権限だ。
AIが正しい文書を取ったとしても、そのユーザーが読んでよい文書とは限らない。部署限定の資料、顧客別の提案書、契約条件、評価情報、採用情報。検索対象に入るだけでリスクになるものがある。
構築前に、少なくとも次のルールを決めたい。
- 文書ごとの閲覧権限を検索時に反映する
- 回答に使った根拠文書を表示する
- 旧版文書は検索対象から外すか、明示して扱う
- 未承認のドラフトは回答根拠にしない
- 退職者や外部協力者の権限変更を反映する
版管理も同じくらい大事だ。社内規程や業務手順は更新される。古い資料が検索で勝つと、RAGは堂々と古い答えを返す。これはハルシネーションではなく、検索設計の問題だ。
PoCでは 「使えた質問」より「外れた質問」を残す
RAGのPoCでは、うまく答えられた質問だけを見ると危ない。
残すべきなのは、外れた質問だ。
- 正しい文書が取れなかった
- 似た文書を取り違えた
- 回答が長すぎた
- 例外条件を落とした
- 根拠がないのに断定した
- 権限上、答えない方がよかった
このログが改善材料になる。検索の問題なのか、文書構造の問題なのか、プロンプトの問題なのか、権限設計の問題なのか。外れ方を分類できると、次の一手が見える。
AIエージェントの入力設計は何から決めるべきかと同じで、入力の質を見ないまま出力だけ直すと遠回りになる。RAGは特に、入力文書と検索結果が回答品質を強く左右する。
周辺の設計では、MCPとは何かで扱った外部ツール連携の考え方も近い。AIに道具を持たせる前に、どの情報源を使わせるか、どの操作を許すかを決める。RAGはその中でも、読む文脈と回答根拠を扱う領域だ。
RAG構築のチェックリスト
RAGを作る前に、次の問いに答えられるか確認してほしい。
- 誰が使うRAGなのか
- どの業務質問に答えるのか
- 評価質問は30問以上あるか
- 質問ごとの理想回答と根拠文書はあるか
- 検索結果だけを評価する手順はあるか
- 回答が根拠に沿っているかを見る手順はあるか
- 答えてはいけない質問のサンプルはあるか
- 文書の版管理と権限を検索時に反映できるか
- 外れた質問を改善ログとして残せるか
- 本番後に誰が評価セットを更新するか
ここまで決めると、RAGは「それっぽい社内チャット」から業務システムに近づく。
開発工程へつなぐなら、エージェント駆動開発とは何かで整理したように、人間が判断する領域とAIが実行する領域を分けておく。RAGも同じで、検索は自動化してよいが、根拠の採用や外部送信は人間の承認を残す、という線引きが必要になる。
Atsumellなら、RAGを仕様から設計する
RAGの価値は、社内文書を検索できることだけではない。人が持っていた判断の根拠を、AIが扱える形に整えることにある。
そのためには、文書を入れる前に、質問、 根拠、権限、停止条件、評価方法を仕様として書く必要がある。ここが曖昧なままRAGを作ると、デモは動く。でも、本番で使うほど不安が増える。
Atsumellでは、要件定義や業務フローをAIが読める構造に整理し、RAGやAIエージェントに渡す前提を作るところから支援している。社内検索、FAQ、問い合わせ対応、提案書検索、規程確認など、用途ごとに評価質問と根拠の単位を一緒に設計できる。
RAGを作るなら、最初の会議で聞くべき問いは「どのツールで作るか」ではない。
「どの質問に、どの根拠で、どこまで答えさせるか」だ。
