LLM自体の性能が飛躍的に向上した今、RAGに求められることとは

本記事では、RAG（Retrieval-Augmented Generation）の仕組みと役割、そして今もなお注目されている理由を紹介します。
最近のLLMは大幅に進化し、昔と比べて多くの問いに正確に答えられるようになってきました。そのため「本当にRAGは必要なのか？」という声も出ています。

それでも、外部の知識を取り込むことで補えることがまだ多くあります。この記事では、RAGの基本的な考え方を振り返りながら、現在の課題と今後に向けて期待される改善の方向をわかりやすく整理します。

背景

RAGとは、ユーザーが質問をすると、まず外部のデータベースから関連する情報を検索し、その検索結果をLLMに渡すことで、より正確で最新の回答を生成させる技術です。仕組みはシンプルです。たとえば「昨日発表された新しい法規制について教えて」と尋ねたとします。LLMは過去のデータで学習しているため、昨日の出来事は知りません。しかし最新のニュース記事や公式文書を検索し、その内容をLLMに読ませてから回答を作る仕組みを作ることは可能で、そうした「検索＋生成」をRAGと言います。

RAGの研究は、この数年で大きく進化しました。初期のRAGは「検索して、結果をそのまま渡す」だけのシンプルなものでした。しかし現在では、たとえばユーザーの質問を分析して検索に最適なキーワードに言い換える技術がでてきたり、また、単なるキーワード検索ではなく質問の意味を深く理解した検索も可能になったりしてきました。

ところが、ここにきて興味深い問題が浮上しています。最新のLLMは、以前のモデルと比べて格段に賢くなっており、RAGなしでも多くの質問に正確に答えられるようになってきたのです。すると当然、「そもそもRAGは本当に必要なのか？」という疑問が生まれます。

実際、RAGにも課題があります。例えば、LLMがすでに知っていることと知らないことの境界線が曖昧なため、必要ない場面でも検索してしまうことなどがあります。

それでも、RAGが今でも欠かせない場面はたくさんあります。一例として、企業の社内文書や個人のメモなど、外部に公開されていない情報を扱う際には重宝します。

こうした状況を踏まえて、RAGの現状と課題を包括的に見直した調査を取り上げます。RAGが抱える弱点を明らかにしながら、同時に、進化し続けるLLMを補完するうえでRAGが今でも果たせる独自の役割を深堀りしていきます。

RAGの構成と主要なしくみ

まず、RAGがどのようなパーツでできていて、それぞれがどんな役割を持っているのかを改めて確認します。

RAGは「検索して、それをもとにLLMが答える」という仕組み。では、具体的にどんなパーツがそれを支えているのでしょうか。RAGが目指すゴールを確認し、そのあとで4つの大事なしくみに分けて説明します。

RAGの目標

RAGの目的は「必要な情報をしっかり拾い上げつつ、余計なものは混ぜないこと」と定義できます。

言いかえると、「見逃しを減らしたいけど、ノイズも減らしたい」ということです。これを専門的には「網羅性（recall）」と「関連性（precision）」といいます。この2つはどちらかを高めるともう一方が下がりやすく、両立がむずかしいとされます。RAGでは、このバランスを取ることが設計上の大きな課題とされています。

4つの基本モジュール

RAGは次の4つのパートに分かれています。

• インデックス（データに目印をつけて整理する）
• 検索（ユーザーの質問に合うデータを探す）
• 生成（探した情報をもとにLLMが回答する）
• オーケストレーション（全体の流れをうまく調整する）

順番に見ていきましょう。

インデックス（索引をつくる）

まず行うのは、大量の文書を検索しやすい形にしておく作業です。

たとえば、長い文章を短く区切ったり（これを「チャンク」と呼びます）、それぞれを数値に変えて似ているもの同士を比べやすくしたりします。この数値化のことを「埋め込み（embedding）」といいます。

ただし、こうしたやり方には限界もあります。文書を細かく分けると、全体の流れが失われやすいですし、数値化されたベクトルだけでは因果関係などの複雑な意味をとらえるのが難しい場合があります。

そのため、意味や関係性をネットワークの形で表す「知識グラフ（knowledge graph）」を使う方法も注目されています。

検索（情報を取り出す）

次のステップで働くのは、ユーザーの質問に合う情報をデータベースから探してくる「検索」です。

まず最初に、質問をそのまま使うのではなく、「検索に適した言葉」に書きかえます。たとえば、質問の中のあいまいな表現をわかりやすくしたり、長い質問を2つに分けたりすることもあります。

そのあと、候補になりそうな文書をいったん広く集めます。このとき、まずはざっくりと探せる「BM25」のような速い方法で候補を集めて、あとからより深い意味を比べて精度を上げていく、という段階的なやり方がよく使われます。

さらに、得られた文書を並びかえたり、いらない部分を削ったりして、LLMに渡す前に整えます。これは、LLMが扱える情報の量に限りがあるため、重要な部分だけをうまく選ぶ必要があるからです。

（補足としてBM25とは、文書の中にどれだけたくさん、そしてどれだけ珍しい単語があるかを使って、重要そうな文書を見つける昔ながらの検索方法です）

生成（回答をつくる）

さらに、探してきた情報をもとにLLMが実際に文章を生成します。

ここでは「プロンプトの設計」がとても大事になります。たとえば、どの情報をどの順番で渡すか、どんな指示を与えるかで、LLMの出力が大きく変わってしまうためです。

ただし、どんなプロンプトが一番良いかという正解はまだ見つかっていません。

また、探してきた情報に矛盾があるとき、LLMがどちらを信じるかも課題になります。モデルがもともと覚えていることと外部の情報が食いちがったときに、どう対応するかを工夫する必要があります。場合によっては、不要な文書を無視するようにLLMを再調整することもあります。

オーケストレーション（全体の流れを調整する）

最後に、これまで紹介した3つのパートをどんな順番でどう使うかを判断する「オーケストレーション」も重要な要素です。

たとえば、簡単な質問なら検索を飛ばしてLLMに直接答えさせるという選択もありえます。一方で、込み入った質問であれば、複数の情報を集めて何度も推論させるような処理が必要になることもあります。こうした柔軟な切り替えをするのが、オーケストレーションの役目です。

RAGが今かかえている課題と、今後どんな工夫をすべきか

RAGをもっと信頼できる仕組みにするために乗り越えるべきポイント、それに向けた道筋を示します。

検索するかどうかの判断がむずかしい

今のRAGでは、基本的に「とりあえず検索してから答える」という流れになっています。しかし最近のLLMは、内部にある知識だけでも多くの質問に正しく答えられるようになっています。

つまり、「この質問には本当に検索が必要なのか？」という判断がとても重要になってきています。そこで、モデルがどのくらい自信を持っているかを測って、検索が必要なときだけRAGを使うのは一つの方法です。

この「自信のなさ」を測るやり方には、いくつかの考え方があります。たとえば、質問の意味があいまいなとき、モデルの予測がバラバラなとき、あるいは答えの確からしさが低いときなどです。

検索すべき情報をどう選ぶか

RAGは、事実を調べる質問には強いですが、複雑な推論や深い理解が必要な質問には弱さがあります。

たとえば、ただ似ている文を引っ張ってくるだけでは、質問の意図にうまく合わないことがあります。そうした場面では、質問を分けたり、仮の答えを立ててみたり、手順を踏んで検索する工夫が必要になります。

そこで知識グラフを使った整理方法や、検索を何段階かに分けて行う方法、さらには「エージェント型」が有用になります。「エージェント型」は、LLMが自分で検索をくり返したり、外部のツールを使ったりするやり方です。

ただし、こうした方法にも問題はあります。計算の負担が大きくなったり、見つけた情報にノイズが混じりやすくなったりします。時間が関係する情報（たとえば「今年の法改正」など）を扱うのもまだ苦手です。

取り込んだ情報は本当に信頼できるか

RAGは、外から情報を集めてLLMに読ませることで、より正確な答えを出そうとします。でも、その外部情報そのものに間違いがあったらどうでしょうか。

実際、誤った情報や信頼できないソースを引いてきてしまうこともあります。それをLLMがそのまま信じてしまうと、逆に誤った出力をしてしまうおそれがあります。

そこで、「信頼できるデータを選ぶしくみ」が今後とても大事になります。たとえば、どのデータをどこから引いてくるかを事前に選別したり、ソースごとの信頼度を評価したりすることが必要です。

外部情報がLLMにどう影響しているかが見えにくい

RAGでは、検索してきた情報をLLMに渡して答えを出してもらいます。しかし、その情報がLLMの中でどのように処理されているのかは、まだよく分かっていません。

たとえば、正しい情報を渡しても、LLMがそれをうまく使えなかったり、逆に間違った情報を信じてしまったりすることもあります。

こうしたふるまいをもっとよく理解するためには、LLMが何に注目しているかを調べたり、どの情報が出力に影響しているかをたどる手法が必要になります。分析は「注意重み」や「因果的追跡」といった技術で行いますが、いずれもLLMの中のふるまいを可視化するための方法です。

RAGと長文コンテキスト型のモデルをどう使い分けるか

最近は、より長い文章を一度に処理できるLLMも登場しています。これなら、文書を細かく分けたりせず、そのまま渡して考えさせることも可能になります。

ただし、長文を読ませるやり方にも問題はあります。たくさんの情報を一度に扱うと、無関係なノイズが混ざりやすくなったり、計算に時間がかかりすぎたりします。

RAGと長文コンテキスト型のモデルは、それぞれの得意・不得意をふまえて使い分けるのが良いと考えられています。たとえば、答えが文書全体に広がっているような質問では長文コンテキスト型が向いていて、逆にピンポイントな証拠が必要なときはRAGのほうが適しているという考え方です。

両方のよさを活かしたハイブリッドな設計も今後のテーマになるとされています。

RAGが活きる場面とは

最後に、RAGがどのような場面で使われているのか、また今後どんな使い方が広がりそうかについて見ていきます。

LLMの性能が高くなってきているとはいえ、RAGには今も意味のある役割があります。実際にどんな用途で活用されているかを3つのタイプに分けて説明しています。

専門的な知識が必要な場面

まず挙げられているのは、専門的な情報が求められる場面です。たとえば、医療や薬学、法律など、間違いが許されない領域では、モデルが覚えている情報だけでは足りないことがあります。

このようなとき、RAGを使って信頼できる外部データベースから根拠を引っぱってくることで、より確実な答えが出せるようになります。

たとえば薬の投与量を判断するような質問では、最新のデータを引いてそれをもとに答えることが大切になります。RAGはそうした「根拠に基づいた出力」を支える仕組みとして役立ちます。

社内データや個人情報を扱う場面

次に、社内文書や個人メモなど、外に公開されていない情報を扱うときも、RAGは重要な働きをします。

LLMは一般的な知識には強くても、企業ごとの事情や個人の過去のやりとりまでは知りません。そこで、RAGがそれらの情報を検索してモデルに渡すことで、その人や組織に合った応答を返せるようになります。

たとえば、ユーザーとの会話の履歴を検索対象にすれば、前に話した内容をふまえた一貫性のある返答ができるようになります。これは、長いやりとりの中でも流れを見失わずに答えるために有効です。

情報の変化が早い場面

ニュースや金融、法律の改正など、日々状況が変わる分野でも、RAGは活躍します。

こうした分野では、モデルを毎回再学習するのは現実的ではありません。そのかわり、RAGが外部の最新情報を引いてきて、それをモデルに読ませることで、すぐに新しい内容に対応できます。

たとえば、「今日の株価の動きを説明して」と聞かれたとき、RAGがニュースサイトや証券レポートを探しに行って、それをもとにLLMが回答するという流れが可能になります。

まとめ

本記事では、RAGのしくみや利点、いま注目されている課題や今後の方向性を紹介しました。

読者の皆様の中にはRAGを活用されている方も多いと思いますが、一方でまだ自らそうした仕組みを作る機会はなかなかないという方もいらっしゃることでしょう。

LLM自体の性能が上がり続ける中でも、今まさにコンテキストエンジニアリングが重要と言われています。RAGはコンテキストエンジニアリングの基礎要素とも言える技術。今後も体系的にキャッチアップが必要な分野ですね。