RAG：検索でLLMに最新の知識を持たせる

横にスクロール

どんなパターンか

大規模言語モデル（LLM）が持つ知識は、学習を終えた時点で凍結される。学習データに含まれない社内規程や最新のニュース、特定製品の仕様などは、そのままでは答えられない。それでも無理に答えさせると、モデルはもっともらしいが事実に反する内容、いわゆるハルシネーションを平然と生成してしまう。かといって知識が変わるたびにモデルを学習し直すのは、費用も時間もかかりすぎる。

RAG（Retrieval-Augmented Generation・検索拡張生成）は、この弱点を「検索」で補うパターンだ。質問が来たら、まず関連しそうな文書を外部の知識源から検索し、その中身をプロンプトの文脈に貼り付けてからLLMに回答させる。モデル自身のあいまいな記憶ではなく、目の前に差し出した資料を根拠に答えさせる。閉じた試験を、資料持ち込み可の試験に変える発想である。

この切り替えが生む効用は三つある。第一に知識の鮮度で、索引を入れ替えれば最新情報にすぐ追従できる。第二にハルシネーションの低減で、答えの拠りどころを実在の文書に縛れる。第三に出典の提示で、どの資料のどこを使ったかを回答に添えられるため、利用者が裏を取れる。たとえば「返品は何日以内か」という問いに対し、RAGは返品規程の該当箇所を検索して文脈に入れ、その条文を引用しながら答える。モデルが規程を暗記している必要はなく、規程が改定されても差し替えた文書がそのまま新しい答えの根拠になる。

外部の知識をその場で引いてくるという点で、RAGは会話の履歴を蓄えるメモリのパターンと役割が違い、互いを補い合う。メモリが「この対話で何を話したか」を覚えるのに対し、RAGは「世界のどこかにある正しい情報」を必要なときだけ取りに行く。埋め込みやベクトル表現といったLLMの基礎はAI側でも扱う。

仕組み

RAGは大きく2つのフェーズに分かれる。あらかじめ知識を検索可能な形に整えておく「取り込み（インデックス作成）」と、質問のたびに走る「検索して生成」である。前者は文書が増えたときに回すバッチ処理、後者は問い合わせごとのリアルタイム処理、と役割がはっきり分かれている。

取り込み（インデックス作成）

まず、元となる文書を「チャンク」と呼ぶ小さな断片に分割する。長い文書をまるごと扱うと、検索で必要な一節だけを取り出せないためだ。次に、各チャンクを埋め込みモデルに通し、その意味を数百〜数千次元のベクトルへ変換する。埋め込みの肝は、意味が近い文どうしはベクトルの距離も近くなるという性質にある。近さの測り方にはコサイン類似度がよく使われ、二つのベクトルの向きがどれだけ揃っているかで意味の近さを判断する。最後に、このベクトルを元テキストや出典情報と一緒にベクトルDBへ格納する。

格納したベクトルは、検索時に総当たりで比較すると遅いため、ベクトルDBは近似最近傍探索（ANN）という索引を張り、わずかな精度と引き換えに高速な検索を可能にする。文書が数百万件に増えても実用的な速さを保てるのが、この索引の効きどころだ。ここまでを事前に済ませておけば、あとは問い合わせのたびに引くだけで済む。

チャンクの粒度は品質を大きく左右する設計判断だ。小さく刻めば一件が指す内容が絞られて検索は的確になるが、前後の文脈が分断されて意味が通らなくなる。大きくまとめれば文脈は保てるが、一件に無関係な話題が混じり、検索のノイズになる。

実務では、段落や見出しといった意味の切れ目で区切り、隣り合うチャンクを少しずつ重ねる（オーバーラップ）ことで、境界で文脈が切れる問題を和らげることが多い。あわせて、章タイトルや更新日などのメタデータをチャンクに付けておくと、後で絞り込みや出典表示に使える。

検索して生成

質問が届いたら、そのクエリも取り込み時とまったく同じ埋め込みモデルでベクトル化する。検索の当たりをよくするため、あいまいな質問を具体的な語に言い換えたり、複数の言い回しへ展開してから埋め込むこともある。そしてベクトルDBの中から、クエリのベクトルに近いチャンクを近傍検索で引いてくる。まず上位数十件を粗く広めに集め、次に、より精密なモデルでクエリとの関連度を測り直して並べ替える。この二段目を「リランク」と呼ぶ。近傍検索は速いが大雑把なので、リランクで本当に効くものを上位へ押し上げると精度が上がる。ただしリランクは候補を一件ずつ丁寧に評価するぶん遅く、コストも増える。速さと精度の綱引きであり、何件を粗く集めて何件に絞るかは調整のしどころだ。

選ばれた上位のチャンクは、そのまま無制限に詰め込めるわけではない。LLMが一度に読める文脈の量には上限があるため、通常は数件だけを選んで、質問と一緒にプロンプトへ注入する。そのうえで「以下の資料だけを根拠に答え、書かれていなければ分からないと答えよ」と指示すると、資料から外れた作文を抑えられる。関連度の高いチャンクを文脈の目立つ位置に置くと、モデルが拾いやすくなる。回答には、使ったチャンクの出典を添えられるので、利用者はその場で原典を確認できる。

使いどころと注意

RAGが向くのは、社内文書の質問応答、カスタマーサポート、頻繁に更新される情報の参照など、正しさと出典が問われる場面だ。逆に、雑談や一般常識だけで完結する用途では、検索の手間が見合わないこともある。

最大の落とし穴は、回答品質が検索品質でほぼ決まることだ。関係ないチャンクを引いてくれば、どれほど優秀なLLMでもその誤った資料に引きずられる。検索が外れる典型的な原因は、チャンク設計のまずさ、埋め込みモデルと対象領域の相性、そして索引の古さである。文書を更新したのに索引を作り直さなければ、古い情報を自信たっぷりに答えてしまう。

固有名詞や型番のような、意味の近さだけでは当てにくい語も苦手だ。こうした語は、ベクトル検索とキーワード検索を組み合わせる「ハイブリッド検索」で補うとよい。また、複数の文書にまたがって推論が必要な問いは一度の検索では拾いきれないことがあり、質問を言い換えて検索し直す工夫が要る。社内利用では、利用者が見てよい文書だけを検索対象に絞る権限フィルタも欠かせない。

検索の当たり外れは、想定質問に対して正解チャンクをどれだけ引けたかという再現率や、回答が資料に忠実かどうかで継続的に計測し、チャンクサイズや取得件数を調整していく。検索を測らずにモデルだけ替えても、品質はなかなか上がらない。まずは検索が当たっているかを数字で見える化し、外しているならチャンク設計や索引の側から直すのが、遠回りに見えて近道だ。

まとめ

RAGは、LLMの凍結された知識を外部検索で補い、鮮度・正確さ・出典を同時に手に入れるパターンだ。仕組みは、文書をベクトル化して索引に載せる取り込みと、クエリで近傍検索してリランクし文脈へ注入する生成の2フェーズからなる。要は、チャンク設計と検索品質という地味な土台こそが回答の良し悪しを決める。ほかの構成法はAIエージェント設計パターンから辿れる。