RAGとは？LLMの弱点を補う検索拡張生成の仕組みをわかりやすく解説

生成AIを業務に導入しようとすると、すぐに2つの壁に突き当たります。「自社の社内文書や最新情報を知らない」こと、そして「知らないことでも、もっともらしい誤った回答を作ってしまう」ことです。この課題への代表的な対処法として広く使われているのが RAG（Retrieval-Augmented Generation、検索拡張生成） です。

社内チャットボットやドキュメント検索AIの製品説明で必ずと言ってよいほど登場する用語ですが、仕組みはシンプルです。この記事では、AWSの公式解説と起源となった研究論文をもとに、RAGとは何か・なぜ必要か・どう動くのかを、AIの専門家ではない方にも分かるように整理します。

RAGとは何か

AWSの解説によると、検索拡張生成（RAG）は「大規模な言語モデルの出力を最適化するプロセス」であり、モデルが「応答を生成する前に、トレーニングデータソース以外の信頼できる知識ベースを参照します」¹。

噛み砕いて言えば、AIに回答させる前に、関連する資料を検索して手渡してから答えさせる仕組みです。人間にたとえると、記憶だけで質問に答えるのではなく、まず資料棚から関連文書を取り出し、それを読みながら答える——この「資料を取り出して（Retrieval）、回答を補強して（Augmented）、生成する（Generation）」という流れがRAGの名前の由来です。

RAGという用語の起源は、2020年に発表された研究論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」（筆頭著者: Patrick Lewis）にあります²。この論文は、学習済みモデルが内部に持つ知識（パラメトリック記憶）と、Wikipediaの文書索引のような外部知識（ノンパラメトリック記憶）を組み合わせて文章を生成する手法を提案しました²。現在では論文の特定の手法に限らず、検索で生成AIを補強するアプローチ全般を指す言葉として定着しています。

なぜRAGが必要なのか：LLMの4つの課題

大規模言語モデル（LLM）は学習した時点の知識しか持たないため、そのまま業務に使うといくつかの問題が生じます。AWSはLLMの既知の課題として、「答えがないのに虚偽の情報を提示すること」、「古くなった、または一般的な情報を提示する」こと、「権限のないソースからの回答の作成」、そして「用語の混乱により、異なるトレーニングソースが同じ用語を使用して異なる内容について話すため、回答が不正確になる」ことを挙げています¹。

1つ目はいわゆるハルシネーション（もっともらしい誤情報）の問題です。2つ目は知識の鮮度の問題で、たとえば昨日改定された社内規程をAIは知りません。3つ目と4つ目は、回答の根拠が信頼できる情報源に基づいているかという問題です。RAGはこれらに対して、信頼できる知識ベースを検索し、その内容に基づいて回答させるというアプローチで対処します。

RAGの仕組み：4つのステップ

RAGの処理は大きく4つのステップで構成されます。AWSの解説に沿って見ていきましょう¹。

ステップ1: 外部データの準備。まず、社内文書やデータベースなどの情報をAIが検索できる形に変換しておきます。ここでは「埋め込み言語モデルと呼ばれる別のAI技術では、データを数値表現に変換してベクトルデータベースに格納します」¹。文章を「意味を表す数値の並び（ベクトル）」に変換しておくことで、キーワードの一致ではなく意味の近さで文書を探せるようになります。

ステップ2: 関連情報の検索。利用者が質問すると、「ユーザークエリはベクトル表現に変換され、ベクトルデータベースと照合されます」¹。質問文と意味的に近い文書が、関連資料として取り出されます。

ステップ3: プロンプトの拡張。RAGシステムは「取得した関連データをコンテキストに追加することで、ユーザー入力を強化します」¹。つまり、利用者の質問に検索結果を添えてLLMに渡し、この資料に基づいて答えるよう回答を生成させます。

ステップ4: データの更新。知識ベースを最新に保つため、「ドキュメントを非同期で更新し、ドキュメントの埋め込み表現を更新します」¹。文書が変わるたびにAIモデル自体を作り直す必要はなく、データベース側を更新するだけで済みます。

RAGのメリット：再学習より速く、安く、確かめやすく

LLMに新しい知識を持たせる方法としては、モデル自体を追加学習させる方法（ファインチューニングや再トレーニング）もあります。しかしAWSが指摘するように、基盤モデルの再トレーニングは「計算コストと財務コストが高くなります」¹。RAGはモデルに手を加えず外付けの知識ベースで補うため、より低コストに導入できます。

このほかAWSは、RAGのメリットとして「最新の研究、統計、またはニュースを生成モデルに提供できます」という情報の鮮度、「ソース属性を使用して正確な情報を提示できます」という出典の明示、そして「情報ソースを制御および変更して、変化する要件に適応させることができます」という開発者側の制御性を挙げています¹。回答に「この社内規程のこの箇所に基づく」という形で出典を付けられることは、業務利用での検証のしやすさに直結します。

導入時に知っておきたい注意点

一方で、RAGは万能ではありません。仕組み上、回答の質は検索で取り出される資料の質に左右されるため、知識ベースに古い文書や誤った文書が混ざっていれば、それに基づいた回答が返ると考えられます。文書の整備・更新（前述のステップ4）まで含めて運用を設計することが、導入成功の鍵になります。

また、検索した資料はLLMに渡すプロンプトに追加されるため、一度に渡せる資料の量は、モデルが一度に処理できるテキスト量（コンテキストウィンドウ）の制約を受けます。この概念はコンテキストウィンドウの解説記事で詳しく説明しています。さらに近年では、RAGの中核である「検索（retrieval）」は、自律的にタスクを進めるAIエージェントの構成要素としても使われています。エージェントの仕組みと生成AIとの違いはAIエージェントの解説記事で整理していますので、あわせてどうぞ。