RAG

Retrieval-Augmented Generation

ai data beginner

AIに答えさせる前に、関連する資料を検索して渡し、その内容にもとづいて回答させる仕組みのこと。

概要（サマリー）

RAG（ラグ）とは、AIに答えさせる前に、関連する資料を検索して渡し、その内容にもとづいて回答させる仕組みのことである。「Retrieval-Augmented Generation」の頭文字で、日本語では検索拡張生成と訳される。

閉じた試験を、参考書持ち込み可の試験に変えるようなものだと考えるとよい。LLMは学習した範囲の知識しか持っておらず、社内規程や最新の仕様書のような「学習していない情報」は知らない。RAGは、質問が来たらまず資料棚から関係しそうなページを探し出し、「これを読んだうえで答えて」とAIに渡す。

この一手間があるだけで、AIは知らないはずの情報にも正確に答えられるようになり、根拠のない作り話も減る。

詳細解説

RAGが必要になる理由

生成AIには、構造上どうしても避けられない弱点がある。

学習した時点までの知識しか持たない。それ以降に起きたことは知らない
社内文書や個人のメモなど、公開されていない情報は当然知らない
知らないことを聞かれても、それらしい答えを作ってしまう（ハルシネーション）
どこから得た情報なのかを示せない。根拠を確認できない

RAGはこの4つをまとめて緩和する。手元の資料を根拠として渡すので、最新情報にも社内情報にも答えられ、「資料に書いていない」と言わせることもでき、出典も示せる。

処理の流れ

RAGは大きく「検索」と「生成」の2段階に分かれる。

事前準備: 手元の文書を適当な長さに分割し、それぞれをエンベディングで数値の並び（ベクトル）に変換してベクトルデータベースに保存しておく
検索: 質問が来たら、質問文も同じ方法でベクトルに変換し、意味が近い文書の断片を数件取り出す
生成: 取り出した断片を質問文と一緒にプロンプトへ入れ、「この資料にもとづいて答えて」とAIに渡す
回答: AIが資料の内容を踏まえた回答を返す

重要なのは、AIそのものは何も変わっていないという点である。変えているのは「渡す材料」だけだ。だから資料を差し替えれば、その瞬間から新しい情報で答えるようになる。

プロンプトの組み立て方

3番目の段階で実際に組み立てられるプロンプトは、概ね次のような形になる。

以下の資料だけを根拠として、質問に答えてください。
資料に書かれていないことは「資料に記載がありません」と答えてください。

# 資料
[1] 有給休暇は入社6か月後から10日付与される。（就業規則 第32条）
[2] 有給の申請は取得予定日の3営業日前までに行う。（就業規則 第33条）

# 質問
入社してすぐ有給は取れますか？

「資料だけを根拠にする」「書かれていなければそう答える」と明示している点がポイントである。この一文がないと、AIは資料を無視して自分の記憶から答えてしまうことがある。

なぜ「意味が近い」文書を探せるのか

普通の検索は文字が一致するかどうかで探す。そのため「有給」で検索しても「年次有給休暇」しか書かれていない文書は見つけにくいし、「休みを取りたい」という質問文では1件も引っかからないことがある。

RAGでは、文章を意味の座標に変換してから探す。「休みを取りたい」と「有給休暇の申請」は文字は違うが意味の座標が近いので、きちんと見つけられる。この「意味で探す」部分を支えているのがエンベディングとベクトルデータベースであり、RAGの心臓部にあたる。

ファインチューニングとの使い分け

AIに独自の知識を持たせる方法として、ファインチューニングと比較されることが多い。役割がまったく違う。

	RAG	ファインチューニング
変えるもの	渡す資料	モデルそのもの
向いていること	知識を与える	話し方・形式を覚えさせる
情報の更新	資料を差し替えるだけ	学習をやり直す
コスト	低い	高い
出典の提示	できる	できない

「何を知っているか」を変えたいならRAG、「どう振る舞うか」を変えたいならファインチューニング、と覚えるとよい。実務では、まずRAGで足りないかを試すのが定石である。両方を組み合わせることもある。

つまずきやすい点

RAGは仕組みが単純に見えるが、精度を出すには調整が要る。

分割の仕方: 文書を細かく切りすぎると文脈が失われ、大きく切りすぎると余計な情報が混ざる。見出し単位で切る、前後を少し重ねて切る、といった工夫をする
取り出す件数: 少なすぎると根拠が足りず、多すぎるとAIが重要な部分を見落とす。3〜5件から始めて調整することが多い
検索で拾えなければ終わり: 検索段階で正しい資料を拾えなければ、どれだけ賢いAIでも正しく答えられない。RAGの精度は生成ではなく検索で決まる
元の資料が間違っていれば、間違ったまま答える。資料の鮮度と正確さの管理が前提になる

身近なRAGの例

特別な仕組みに聞こえるが、実際にはよく使われている。

NotebookLM: 自分がアップロードした資料だけを根拠に答えるサービス。RAGの分かりやすい実例である
社内FAQチャットボット: 就業規則やマニュアルを検索して答える
AIコーディングツール: プロジェクト内のコードを検索し、関係するファイルを読んでから提案する

3つ目は特に身近だろう。Claude Codeのようなツールが巨大なコードベースの中から関係するファイルだけを見つけて読むのも、考え方としてはRAGに近い。

AIコーディングとの関係

AIコーディングを使ううえで、RAGの考え方は2つの意味で役に立つ。

1つ目は、自分でRAGを作る場合。 AIに「RAGを実装して」とだけ頼むと、ライブラリの選定から分割方法までAI任せになり、あとから調整しづらい構成が出てくる。次を具体的に伝えるとよい。

資料の種類と量（PDFが50本、Markdownが200ファイル、など）
分割の方針（見出し単位か、文字数か）
使いたいベクトルデータベース
取り出す件数と、資料にない場合の答え方

2つ目は、AIコーディングツール自体の挙動を理解する場合。 ツールがプロジェクト内を検索して関係ファイルを読むとき、拾えなかったファイルの内容はAIに見えていない。「なぜかこのファイルの規約を無視する」という現象は、AIが怠けているのではなくそのファイルが検索で拾われていないことが原因のことが多い。関係するファイルを明示的に指定すれば解決する。

RAGを知っていると、この「見えていないだけ」という状況に気づけるようになる。

よくある勘違い

RAGを使えばAIは賢くなる？

賢くはならない。RAGが変えるのは「AIが手元に持っている資料」だけで、AIの推論能力そのものは1ミリも変わらない。資料を読んで理解する力が足りないモデルにRAGを付けても、的外れな答えが返ってくる。

RAGを使えばハルシネーションはなくなる？

大きく減らせるが、ゼロにはならない。資料に書かれていない部分をAIが補ってしまう、複数の資料を混同する、といったことは起こりうる。出典を必ず表示させ、人が確認できる形にしておくことが大切である。

資料をすべてプロンプトに入れればRAGは不要？

資料が数ページなら、そのまま全部渡すほうが確実で簡単である。RAGが必要になるのは、資料が多すぎて一度に渡しきれないときだ。ただし全部渡せる場合でも、無関係な情報が多いと精度が落ちること、渡す量に応じて費用がかかることは意識しておきたい。

RAG = ベクトル検索？

ベクトル検索はRAGでよく使われる手段のひとつにすぎない。従来のキーワード検索でも、データベースへの問い合わせでも、社内APIの呼び出しでも、「検索して渡す」形なら考え方はRAGである。実務では、キーワード検索とベクトル検索を併用することも多い。

まとめ

RAGは、関連資料を検索してAIに渡し、その内容にもとづいて答えさせる仕組みである
AIそのものは変えず、渡す材料だけを変えるので、資料を差し替えれば情報も更新される
学習していない情報に答えられ、ハルシネーションを減らし、出典も示せる
知識を与えたいならRAG、振る舞いを変えたいならファインチューニングと使い分ける
精度は生成側ではなく検索側で決まる。分割の仕方と取り出す件数の調整が要になる

情報ソース

より詳しくAIに聞いてみよう

RAGとは何かを、身近なたとえを使って初心者向けに説明してください。
RAGとファインチューニングの違いを、どちらを選ぶべきかの判断基準つきで整理してください。
RAGで文書を分割するとき、精度が上がる分割方法の考え方を教えてください。
RAGを導入しても回答精度が上がらないとき、どこから調べればよいですか。
AIコーディングツールが特定のファイルの規約を無視するとき、RAGの観点からどう対処すればよいですか。