ChatGPTに社内の仕様書について聞いても、「その資料は持っていません」と返ってきます。
最新のニュースを尋ねても、学習した時点で知識が止まっています。
この「モデルの外にある知識をどう渡すか」という問題に、いま定番の答えになっているのがRAGです。
名前は聞くけれど仕組みは曖昧、という人向けに、RAGが中で何をしているのかを一度整理しておきます。
RAGとは何か
RAGはRetrieval-Augmented Generation（検索拡張生成）の略です。
ひとことで言えば、質問に関係する文書をその場で検索し、見つけた内容をプロンプトに足してから答えさせる仕組みのことです。
モデルそのものを作り替えるのではなく、回答の材料を外から差し込むイメージですね。
2020年にPatrick Lewisらが発表した論文で提案され、いまでは社内チャットボットや検索アシスタントの土台として広く使われているのです。
なぜRAGが必要なのか
理由は大きく三つあり、どれも LLM だけでは足りない部分を外から補うものです。
学習した知識は途中で止まっている
LLMが答えられるのは、学習を終えた時点までの知識に限られます。
昨日リリースされた製品も、社内にしかない議事録も、モデルは当然知りません。
RAGなら外部の最新データや非公開の文書を検索して渡せるので、この空白を埋められます。
もっともらしい嘘を減らせる
根拠を持たないLLMは、知らないことでも自信たっぷりに作文してしまいます。
これがハルシネーションと呼ばれる現象です。
検索で見つけた実際の文書を根拠として与えると、でたらめな生成をかなり抑えられます。
根拠となる出典を示せる
RAGは「どの文書を根拠にしたか」を回答に添えられるのも大きな強みです。
利用者が元資料をたどれるぶん、業務で使うときの信頼性が一段上がりますね。
出典を返す仕組みそのものと、付いた出典をどこまで信じてよいかは、グラウンディングの記事で整理しました。
RAGの基本的な流れ
処理そのものは、分解すると5つのステップに収まります。
1. 社内文書やWebページを、小さな断片（チャンク）に分ける
2. 各チャンクをベクトル（埋め込み）へ変換して保存しておく
3. 質問もベクトルに変換し、意味が近いチャンクを検索する
4. 上位の数件を取り出してプロンプトに連結する
5. LLMがその文脈を根拠に回答を生成する肝は3つ目の「意味が近い文書を探す」ところで、ここは単語の一致ではなくベクトルの近さで検索します。
だからこそ、言い回しが違っても意味の近い資料を拾ってこられるわけです。
ファインチューニングとの違い
外部の知識を扱う方法として、RAGはよくファインチューニングと比較されます。
ファインチューニングはモデル自体を追加学習させ、口調や専門分野の癖を染み込ませる手法です。
対してRAGはモデルには触れず、参照する知識を外付けで差し替える手法です。
頻繁に更新される情報や社外秘の資料を扱いたいときは、RAGのほうが小回りが利くと私は感じています。
RAGでつまずきやすいところ
便利な一方で、回答の精度は検索の質にほぼ引きずられるのです。
見当違いの文書を拾えば、その分だけ答えもずれていきます。
文書をどの大きさで区切るか（チャンク設計）や何件渡すかで結果が大きく変わるため、ここは地道な調整が必要です。
意味の近さで文書を拾う土台になっているのが、エンベディングという変換です。
最後に
RAGをぐるっと眺めて腑に落ちたのは、「AIに賢くなってもらう」より「AIに良い資料を渡す」発想だということでした。
モデルの性能そのものを追いかけなくても、渡す知識を整えるだけで回答はぐっと実用的になります。
外部ツールとLLMをつなぐという意味では、先日書いたMCPとも地続きの話なので、あわせて読むと輪郭がはっきりしてきます。
以上です。
コメントを残す