RAG（Retrieval-Augmented Generation：検索拡張生成）とは、大規模言語モデルに回答の前に資料を調べさせる技術です。モデルは回答を生成する前に、外部のナレッジベースから質問に関連する内容を検索し、その内容を根拠として回答を書きます。LLMの2つの持病――学習データに期限があること、知らないことを堂々と作り話してしまうこと（ハルシネーション）――に直接対処し、「記憶を頼りに答える」から「調べながら答える」へと変えるものです。
3つのステップ
フローは名前の通り3ステップだけです。
- 検索（Retrieval）：ユーザーの質問をベクトルに変換し、ベクトルデータベースや文書庫から意味的に最も関連するテキスト断片を探します。
- 拡張（Augmented）：見つかった断片を質問と一緒にプロンプトに組み込みます。いわば「持ち込み可の試験の参考資料」をモデルに渡すイメージです。
- 生成（Generation）：モデルはその資料をもとに回答を組み立てます。優れた実装では各文の出典も示され、検証できます。
境界を押さえておきましょう。RAGが入れ替えるのは「参考資料」であり、モデルの重みには触れません。性能の上限は、検索で拾ってきた断片の質で決まります。
RAGとファインチューニングの違い
一言で言えば、RAGはモデルの参考資料を入れ替え、ファインチューニングはモデルそのものを作り替える手法です。
- 社内文書や非公開データ、時事性の高い情報を扱わせたい → RAG：資料はいつでも更新でき、コストは低く、回答の根拠をたどれます。
- 口調や出力形式を変えたい、特定分野の専門家らしく推論させたい → ファインチューニング：能力を重みに書き込みます。
よくある誤解は、RAGを「貧者のファインチューニング」と見ることです。RAGはモデルを学習させず、振る舞いの問題は解決できません。逆にファインチューニングも知識の鮮度問題は解決できません――学習が終わった翌日には、新しい知識がまた古くなっているからです。低コストなファインチューニングの方法はLoRAファインチューニングとは？少ない予算でも専用モデルを訓練できる理由をご覧ください。
RAGとプロンプトエンジニアリングの違い
プロンプトエンジニアリングが「どう尋ねるか」の問題なら、RAGは「何を資料に尋ねるか」の問題です。
練り上げたプロンプトは、モデルが既有の知識をうまく引き出し、指定の形式で出力する助けになりますが、モデルが知らない事実を生み出すことはできません。RAGは事実をモデルの口元まで運びます。実務では両者を組み合わせるのが常套手段です。RAGが資料を提供し、プロンプトがルールを定める――「提供された資料だけを根拠に答え、資料になければ知らないと明言し、情報ごとに出典を示す」という具合です。
よくある3つの誤解
誤解1：RAGとはモデルにネット検索させること。 ネット検索はRAGの一形態にすぎません（検索対象がインターネット全体の場合）。企業でよく使われるRAGの検索対象は、社内ナレッジベースや問い合わせ履歴、製品ドキュメントです。RAGの本質は「検索＋生成」という構成であり、「ネット接続」という動作ではありません。
誤解2：RAGを使えばハルシネーションはなくなる。 減らせるだけで、根絶はできません。検索で拾った断片が的外れだったり、モデルが資料を誤読したりすれば、やはり間違えます。RAGの真価は、間違いを検証可能にすることです――回答に出典が付くので、どの資料に問題があったかを特定できます。
誤解3：RAGとファインチューニングはどちらが上か。 次元の違う話です。一方は「知識をどこから得るか」、もう一方は「能力をどう形作るか」を扱います。本番環境では両者を併用するのが一般的です。振る舞いの型はファインチューニングで決め、最新の知識はRAGでつなぐ、という具合です。
向いている場面
企業のナレッジベースQ&A（カスタマーサポートや社内Wikiの自動応答）、長文ドキュメントのアシスタント（数百ページの契約書・マニュアル・論文への質問）、そして「間違えたときの代償が大きく、出典の確認が必須」な場面です。複数文書にまたがる全体的な問い（例：「これらの決算資料が共通して示す傾向は？」）を扱いたい場合は、派生形のGraphRAGもご覧ください。
