社内規程をAIに読み込ませたのに、存在しない制度を自信ありげに答える。資料を追加したのに、欲しい段落を見つけられない。こうした違和感があると、モデルをもっと高性能にすれば直ると思いがちです。しかし、回答前に正しい根拠を探せていないことが原因なら、必要なのはモデル交換ではなく検索の設計です。
RAGは、質問に関係する情報を外部データから検索し、その情報を質問と一緒にモデルへ渡して回答させる仕組みです。先に結論を言うと、RAGの品質は「生成」より前の、文書の準備、検索、権限、評価で大きく決まります。まず三つの処理から見ていきます。
最初に結論
RAGはRetrieval-Augmented Generation、つまり検索拡張生成の略です。利用者の質問を受けたら、社内文書やデータベースから関連箇所を検索し、その根拠をプロンプトへ加えてLLMに回答させます。モデル自体へ最新情報を学習し直す方式ではないため、文書更新を反映しやすく、出典も示しやすい一方、検索で正しい情報を取れなければ回答も改善しません。導入では検索精度と回答精度を分けて評価します。
この記事のポイント
- ・RAGは検索、拡張、生成の三段階で、モデルの再学習とは別の方式
- ・文書を置くだけでは不十分で、分割、メタデータ、検索方法、アクセス権が品質を左右する
- ・ベクトル検索だけに決め打ちせず、キーワードや属性を組み合わせた検索も検討する
- ・答えられないときに推測せず、根拠不足として返す挙動まで設計する
対象：生成AIへ社内文書や最新情報を参照させたい事業責任者、企画、情シス、データ担当者
1. RAGは検索・拡張・生成の三段階
最初のRetrievalでは、質問に関係する文書の一部を探します。次のAugmentationでは、見つけた文章、文書名、日付などを質問へ追加します。最後のGenerationで、LLMが渡された根拠を使って回答を組み立てます。RAGの原著論文も、外部の検索可能な知識と生成モデルを組み合わせる考え方を示しました。
就業規則への質問なら、「育児休業は何日か」という問いに対し、規程の該当条文を探し、その条文を付けて回答させます。LLMが記憶だけで答えるのではなく、現在有効な社内文書へ接地させるのが目的です。ただし、検索結果が旧規程なら、流暢でも誤答になります。
- 検索する：質問を使い、文書インデックスから関連する箇所を取得します。
- 根拠を加える：取得した文章、出典、有効日などを質問と一緒にモデルへ渡します。
- 回答を生成する：根拠の範囲で回答し、参照した文書を利用者へ示します。
- 不足時は保留する：十分な根拠がない場合は推測せず、担当部署や原文確認へ戻します。
2. 文書分割と検索方法が回答の前提になる
長いPDFを一つの塊で登録すると、必要な一文を探しにくくなります。そこで見出しや段落など意味のまとまりで分割し、検索しやすいインデックスを作ります。分割片には文書名、版、有効日、部署、公開範囲といったメタデータを付けます。これにより「人事部の現行規程だけ」のように絞れます。
意味が近い文章を探すベクトル検索は便利ですが、社員番号、商品コード、制度名の完全一致にはキーワード検索が強いことがあります。二つを合わせるハイブリッド検索や、最初の候補を別モデルで並べ替える再ランキングも選択肢です。先にデータの性質を見て、検索方式を決めます。
| 要素 | 役割 | 失敗例 | 改善の方向 |
|---|---|---|---|
| 文書分割 | 検索する意味単位を作る | 条文の途中で切れ、条件が欠ける | 見出し構造と意味のまとまりで分ける |
| メタデータ | 版・日付・権限で絞る | 廃止済み資料が上位になる | 有効期間と管理部署を付ける |
| 検索 | 質問に近い候補を取る | 固有コードを意味検索で落とす | キーワードとベクトルを併用する |
| 生成 | 根拠から読みやすく答える | 根拠外を補ってしまう | 引用と回答不能条件を指示する |
3. 通常のLLM・ファインチューニングとの違い
通常のLLMへの質問は、モデルが学習時に得た知識と、その場で渡した文章を使います。RAGは質問ごとに外部データを検索します。規程、価格、製品仕様のように更新される事実や、公開されていない社内文書を扱うときに候補になります。
ファインチューニングは、例を使ってモデルの応答形式や特定タスクへの振る舞いを調整する方式です。最新の文書内容をそのまま覚えさせ、変更のたびに更新する用途とは相性がよくありません。答え方を整えるのか、参照する事実を追加するのかを分けると選びやすくなります。
| 方式 | 主に変えるもの | 向く目的 | 注意点 |
|---|---|---|---|
| プロンプト | その場の指示と少量の情報 | 回答形式、条件、短い資料 | 長い・頻繁に変わる知識は入れにくい |
| RAG | 回答前に参照する外部情報 | 社内文書、最新情報、出典付き回答 | 検索失敗と権限漏れを評価する必要 |
| ファインチューニング | モデルの振る舞いや出力傾向 | 定型表現、分類、専門的な応答パターン | 事実更新の仕組みとは分けて考える |
4. 50問の正解セットから小さく始める
最初に全社文書を投入すると、どの資料が原因で誤ったか追えません。一つの部署、一種類の文書、一つの質問目的へ絞ります。たとえば経費規程なら、実際によく聞かれる質問、正しい回答、根拠条文、答えられない質問を合わせて50問程度の評価セットを作ります。件数は目的に応じて増減します。
まず検索結果に正しい条文が含まれたかを見て、その後に回答が条文を正しく使ったかを確認します。検索と生成を分ければ、文書分割を直すべきか、プロンプトを直すべきか判断できます。公開前には、権限のない利用者が機密文書を検索できないこともテストします。
- 用途を一つ決める：対象利用者、質問、参照文書、回答不能条件を定義します。
- 原文を整える：最新版、重複、見出し、表、権限、管理者を確認します。
- 検索を作る：分割、メタデータ、キーワード・ベクトル検索を試します。
- 二段階で評価する：正しい根拠を取れたか、根拠から正しく答えたかを別々に採点します。
- 運用を決める：文書更新、再インデックス、問い合わせ、障害時の停止手順を用意します。
5. RAGでも誤答はなくならない
RAGは誤答を減らす手段ですが、正しさを保証する仕組みではありません。質問と異なる文書を取得する、表の条件を欠落させる、複数文書の矛盾を見落とす、根拠にない内容をモデルが補う、といった失敗があります。複雑な文書比較や規程遵守の最終判定は、単純なRAGだけに任せない方が安全です。
回答には文書名と該当箇所を示し、利用者が原文へ戻れるようにします。検索スコアが低い、文書が古い、根拠同士が矛盾するときは「分からない」と返す条件を設けます。導入効果は回答数ではなく、正しい自己解決、担当者への適切な引き継ぎ、誤答の種類で確認してください。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv（2020-05-22）（最終確認：2026-08-07）：RAGを提案した原著論文
- Azure AI Searchでのレトリーバル拡張生成（RAG） — Microsoft Learn（2026-01-15）（最終確認：2026-08-07）
- 生成AI活用におけるRAG導入のポイント — NTT DATA（2025-03-03）（最終確認：2026-08-07）
- 検索拡張生成（RAG）とは何ですか？ — AWS（最終確認：2026-08-07）
よくある質問
RAGを使えばハルシネーションはなくなりますか？
なくなりません。正しい根拠を検索できない、古い文書を取る、根拠外を補う失敗は残ります。検索と回答を別々に評価し、根拠不足なら回答しない条件と原文リンクを用意します。
RAGにはベクトルデータベースが必須ですか？
必須ではありません。文書量や質問によってはキーワード検索や既存の検索基盤で始められます。意味検索が必要な場合も、固有名詞に強いキーワード検索との併用を検討します。
RAGとファインチューニングはどちらを選べばよいですか？
最新・非公開の事実を参照させたいならRAG、出力形式や特定タスクの振る舞いを調整したいならファインチューニングが候補です。併用もできますが、まず目的を分けてください。
まとめと次の一歩
RAGの成否はモデル名より、原文の管理と検索評価で決まります。検索できなかった問題と、根拠は取れたのに答えを誤った問題を分けることで、直すべき場所が文書・検索・生成のどこか判断できます。