RAG
Retrieval-Augmented Generation ・ らぐ
外部の資料を検索してLLMに渡し、学習データにない情報や最新の情報に基づいて答えさせる構成。
✦ 30秒で試す — 航海賢いAIに資料を渡したのに、資料どおりに間違える1文ずつに切ると、検索は正解の文を？予想してみる概要
RAG（Retrieval-Augmented Generation、検索拡張生成）は、LLM に質問を渡す前に、関係する情報を外部の知識源から検索し、その内容をプロンプトに添えて答えさせる構成です。モデル自体を作り変えるのではなく、「答えに必要な資料を、その場で手渡す」ことで、学習データに含まれない情報に基づいた回答を可能にします。試験にたとえるなら、暗記だけで挑む持ち込み不可の試験を、資料持ち込み可のオープンブック試験に変える発想です。
「社内規程について答えるチャットボット」「製品マニュアルに基づくサポート AI」「自社のデータベースを参照するアシスタント」— 業務で LLM を使おうとすると、ほぼ必ず「モデルがうちの情報を知らない」という壁に当たります。RAG はこの壁を越えるためのいちばん標準的な構成で、LLM アプリの定番の型として広く使われています。
なぜ生まれたか
LLM の知識には2つの根本的な制約があります。1つは時間の制約で、モデルが知っているのは学習データを集めた時点（カットオフ）までの情報だけです。もう1つは範囲の制約で、社内文書・非公開のデータ・個々の顧客の情報など、学習データに入っていない情報は原理的に知りようがありません。さらに厄介なことに、LLM は知らないことを「知らない」と言わず、それらしい誤り（ハルシネーション）を流暢に生成してしまいます。
この問題をモデルの再学習で解こうとすると、情報が更新されるたびに膨大な計算の費用をかけて学習し直すことになり、現実的ではありません。そこで「知識はモデルの外に置き、必要なときに検索して渡せばよい」という転回が生まれました。2020年、Facebook AI Research（現 Meta）の Lewis らが、検索器と生成モデルを組み合わせたこの方式を Retrieval-Augmented Generation と名づけて発表し、ChatGPT 以降の LLM ブームの中で、外部の知識と LLM をつなぐ実用の構成として一気に広まりました。知識の更新が「再学習」ではなく「文書の差し替え」で済むこと、回答の根拠を出典として示せることが、この構成の決定的な強みです。
詳細
2つのフェーズ — 事前の準備と、質問ごとの検索・生成
RAG の処理は大きく2つのフェーズに分かれます。前段の「インデックス構築」では、まず知識源となる文書（社内 Wiki、PDF、マニュアルなど）を、数百〜千字程度の「チャンク」と呼ばれる断片に分けます。次に各チャンクを埋め込みモデルに通して、意味を表す数百〜数千次元のベクトルに変え、ベクトルデータベースに格納します。これで「意味の近い文書を数値の計算で探せる」検索の土台ができます。2つのフェーズは、ベクトルデータベースを介してつながっています。
後段の「検索・生成」が、ユーザーの質問が来るたびに動く本番の流れです。
質問文を、文書と同じ埋め込みモデルでベクトルに変え、ベクトルデータベースで類似度の高いチャンクを上位 k 件取り出します。そして「以下の資料に基づいて質問に答えてください」という指示とともに、取り出したチャンクと質問を1つのプロンプトに組み立てて LLM へ送ります。この組み立て方の設計はプロンプトエンジニアリングの領分で、「資料にない場合は分からないと答える」「根拠の番号を添える」といった指示を加えるのが定石です。
検索が外れれば、生成も外れる
RAG の回答の品質は、LLM より検索の質で決まることが多い、というのが実務の実感です。LLM は枠に入った資料しか読まないので、正解の書かれたチャンクを検索が拾えなければ、どれだけ優秀なモデルでも正しく答えられません。下の部品で確かめてください。意味の近さでチャンクを並べた地図の上で、質問の点をドラッグします。近い上位 k 件がプロンプトの枠に入り、回答はその資料だけから作られます。正解のチャンクが円の外に出たとき、チャンクの粒度を変えたときに、答えがどう変わるかを見てください。
金の「質問」の点をドラッグしてください。点に近い上位 3 件のチャンクがプロンプトの枠に入り、回答はその資料だけから作られます。正解の資料を円の外へ出すと何が起きるでしょう。
チャンクの粒度は、部品で見たとおりのトレードオフです。細かすぎると、「日当は1日3,000円」という文から「出張」という語が切り離されるように文脈が切れ、そのチャンクは質問から遠い場所に置かれてしまいます。大きすぎると、1つのチャンクに多くの話題が混ざって意味がぼやけ、枠には無関係な文が大量に入ります。見出しや段落の単位で区切る、隣のチャンクと前後を少し重ねて（オーバーラップ）文の途中で切れても文脈が残るようにする、チャンクに章の見出しを添えてから埋め込む、といった工夫が定番です。
精度を上げる仕組み — ハイブリッド検索とリランキング
ベクトルによる類似検索は「意味の近さ」には強い一方、型番や固有名詞、条文の番号のような完全一致には弱い性質があります。そこで、従来型のキーワード検索（全文検索、BM25 など）と組み合わせる「ハイブリッド検索」がよく使われます。
もう1つの定番が「リランキング（並べ直し）」です。ベクトル検索では、質問と文書を別々にベクトルにしてから近さを測ります（バイエンコーダ）。速い代わりに、質問と文書の細かな対応は見ていません。そこで、まずベクトル検索で候補を多めに（たとえば50件）取り、次に質問と文書を1組ずつまとめてモデルに読ませて関連度を採点する「クロスエンコーダ」で並べ直し、上位の数件だけを LLM に渡します。1組ずつ読むので遅いものの精度が高く、「広く速く拾ってから、狭く丁寧に選ぶ」二段構えになります。
評価は「検索」と「生成」を分けて測る
RAG がうまく答えないとき、原因は検索か生成のどちらかにあります。だから評価も分けて測ります。検索の側は「正解の資料を上位 k 件に拾えたか」（再現率）で、生成の側は「回答が渡した資料に忠実か」（忠実性。資料にないことを足していないか）と「質問に答えているか」で測ります。部品で、正解が円の外に出たときの回答は、資料には忠実なのに答えは外れでした。忠実性だけを見ていると、この失敗は見えません。質問と正解の資料の組を評価用に用意しておき、チャンクの粒度や k、埋め込みモデルを変えるたびに再現率を測り直すのが、改善の近道です。
落とし穴 — RAG は万能薬ではない
検索が外れると、LLM は手元の不十分な資料から無理に答えを組み立て、結局ハルシネーションが起きることがあります。RAG はハルシネーションを減らしますが、ゼロにはしません。渡した資料を無視したり、微妙に歪めて要約したりすることもあるので、出典を示して利用者が確かめられる設計が大切です。古い版の規程のように、誤った資料が検索対象に残っていれば、答えもそれに引きずられます。また、検索対象に機密文書を含めるなら、「誰がどの文書を検索してよいか」という認可の制御を検索の段階で行わないと、権限のない情報が回答に混ざる事故につながります。
LLM を自社向けにするもう1つの手段がファインチューニングですが、両者は解く問題が違います。「最新の情報や社内の知識を答えさせたい」という知識の注入は RAG の領分で、「口調・出力の形式・専門のタスクの振る舞いを身につけさせたい」という適応はファインチューニングの領分です（使い分けの詳細はファインチューニングの記事で扱います）。
試問
社内規程をチャンク（検索の単位になる断片）に分け、意味の近いものほど近くに置いた地図です。金の点は質問「出張の日当はいくら？」で、点に近い上位 k 件のチャンクがプロンプトの枠に入り、LLM はその資料だけを読んで答えます。質問の意味は変えられないので点は動かせませんが、チャンクの粒度（1文ずつ・段落・章ごと）と k（1〜3件）は選べます。
質問「出張の日当はいくら？」の点は、質問の意味で決まるので動かせません。チャンクの粒度と上位 k 件を切り替えて、枠に入る資料と回答がどう変わるかを見てください。