RAGとLLM:技術的な解説(定義、違い、ユースケース)
RAGとLLMは競合する選択肢ではありません。この概要では、それぞれの仕組み、違い、そしてLLMだけで十分な場合と検索が必要な場合を説明します。

LLMは、学習データ内のパターンから学習したパラメータを使って応答を生成します。それらのパラメータは最新情報や完全な情報を反映していない場合があるため、RAG(retrieval-augmented generation、検索拡張生成)は、外部ソースからのデータをLLMの入力コンテキストに追加することでそのプロセスを補完します。AIツールは、外部情報を取得し、LLMの生成プロセスを拡張します。
実際には、RAGかLLMかのどちらかを選ぶわけではありません。ハイブリッドアプローチか、LLMのみを使うアプローチかの違いです。
LLMが社内ドキュメント、データベース、または急速に変化する情報へのアクセスを必要とする場合、RAGは必須です。LLMのみのアプローチは、すべての入力をユーザーが提供できる特定の管理、データ処理、コンテンツ作成タスクに適しています。
RAGとLLMの違いとは?
- RAGとLLMは相補的なシステムです。RAGなしでAIモデルを使うことはできますが(その場合は既存のパラメータのみに依存します)、モデルなしでRAGシステムを使うことはできません。
- RAGは、LLMが抱える3つの主要な課題、すなわち古い情報、ハルシネーションを含む応答、第三者ソースによる検証不足を解決するために導入されました。
- RAGは、LLMを検証済みの社内ドキュメント、データベース、APIエンドポイントに接続することで、現実のビジネスシーンでAIの効果を大幅に高めます。
- 代表的なRAGのユースケースには、カスタマーサポートチャットボット、急速に変化するデータ(業界ニュースなど)に基づくクエリ、そして正確性と出典の事実確認が重要な医療や法律などの専門分野が含まれます。
- RAGには主に3種類あります。ナイーブRAG、モジュラーRAG、アドバンスドRAGです。ナイーブRAGは、わかりやすく言えば情報検索そのものであり、モジュラーRAGとアドバンスドRAGには、クエリの書き換えやチャンク最適化などの追加機能が加わります。
大規模言語モデル(LLM)とは何ですか?
LLM、すなわち大規模言語モデルは、微調整されたパラメータを使ってコンテンツを生成するシステムです。これらのパラメータは、LLMの語彙にあるすべてのトークンに割り当てられる確率を決定し、与えられたシーケンスの中で次に来る可能性が最も高いトークンを示します。
RAGがどのように機能するのか(そしてLLMとどう異なるのか)をよりよく理解するには、生成AIが基本的にどのように動作するかを見るのが役立ちます。
- トークン化:ユーザーのプロンプトはトークンに分割されます。トークンは単語、単語の一部、または1文字の場合があります。
- 埋め込み:トークンは埋め込み表現に変換されます。これはベクトルと呼ばれる数値表現(数列)であり、デコーダーを含むニューラルネットワークが処理できます。
- デコード:デコーダーの各層(LLMのニューラルネットワークの大部分を構成します)は、アテンション と呼ばれるプロセスを用いて、これらのベクトルを操作し、意味を捉えます。このプロセスにより、各トークンがシーケンス内の他のトークンとどの程度強く関連すべきかが決まります。
- スコアリング:モデルは既存の語彙内の各トークンに互換性の確率を割り当て、シーケンスの次に来る可能性が高いトークンを選択します。
重要なのは、LLMが出力できるのは既存のパラメータとコンテキストウィンドウ内のトークンに基づく内容だけだという点です。学習中、LLMは不完全なテキストの一部を埋めるように何十億回も促され、そのたびにトークンに確率を割り当てるようにパラメータが調整され、最終的にテキストを確実に補完できるようになります。
たとえば、AIモデルに「当社の2026年の返金ポリシーには何と書かれていますか?」と尋ねたとします。LLMは、サポートドキュメントで微調整されていない既存のパラメータに基づいて、次のトークンを予測することしかできません。追加のコンテキストなしでこの質問をすると、意味のある応答ができないか、誤った答えをハルシネーションしてしまいます。
検索拡張生成(RAG)とは何ですか?
RAG(retrieval-augmented generation、検索拡張生成)とは、外部システムの情報をLLMのプロンプトに含めるプロセスです。
基盤となるLLMのプロセス、つまり埋め込み化と確率的なトークン照合は、変わりません。RAGは、ユーザーのプロンプトを追加データで拡張する前処理を導入します。
RAGの仕組みの概要は次のとおりです。
- 知識の準備:知識ソースを準備します。これは、文書セット、ベクトルデータベース、知識グラフ、または(AI検索のような)ライブインデックスである場合があります。
- プロンプト入力:ユーザーが「今日はロンドンを散歩するべき?」のようなプロンプトを入力します。
- 検索:外部情報ソースは、AIツールの検索コンポーネントによって照会されます。プロンプトを埋め込み化してベクトルに変換し、その後ベクトルデータベースを照会する場合があります。あるいは、API呼び出し、キーワード一致、知識グラフの走査など、別の方法を使うこともできます。
- 挿入:この情報はユーザーの元のプロンプトに追加されます。ロンドンでの散歩についての質問の例では、ロンドンの天気情報や、人気の散歩ルートの現在の利用可否などが含まれる場合があります。
- 回答生成:LLMは、拡張されたプロンプトを使って通常どおり応答を生成します。
内部では、検索されたテキストが入力コンテキストに追加され、トークン化され、埋め込み化されます。モデルはその追加コンテキストをデコーダーで処理し、その結果、出力トークンの確率が変化します。
大まかに言えば、RAGは3つのサブタイプに分けられます。ナイーブRAGは、情報を検索してプロンプトに入力するという基本的なRAGプロセスに従います。アドバンスドRAGは、クエリの書き換えや複数回のクエリ処理などの追加機能を加えます。モジュラーRAGは、さまざまな高度な機能をコンポーネントとして扱い、必要に応じて組み合わせられるアーキテクチャを指します。
RAGとLLM:ユースケースの概要
RAGは、ユーザーが最新データにアクセスできるようにします。その結果、LLMの出力でハルシネーションや情報の抜け漏れが起こりにくくなります。出力に使われた情報の出典を確認する必要がある場合も、RAGは不可欠です。根拠のないLLMの回答には帰属表示が付かないためです。
RAGのユースケース
- 時間に敏感な情報のリクエスト:天気予報のような単純なものから、新たなニュースの詳細分析のような複雑なものまで、すぐに古くなる情報に関する問い合わせは、検証済みの第三者ソースに基づく必要があります。
- 社内ドキュメント:ユーザーが会社や製品のドキュメントに関する質問をする社内向けまたは顧客向けのAIチャットボットは、特にドキュメントが頻繁に更新される場合、RAG対応にすべきです。
- カスタマーサポート:顧客向けチャットボットは、正確な回答を提供するために、最新で詳細なサポートドキュメントへのアクセスが必要です。
- 専門分野(医療、法律、金融など):分野固有のコーパスで学習していないLLM(特に一般向けモデル)は、通常、専門的なプロンプトの微妙なニュアンスをうまく扱えません。
LLMのユースケース
- 管理業務:LLMは、最小限の遅延で基本的なタスクを完了できます。スペルチェックや要約など、外部情報を必要としない基本的な文章作成や管理業務には、RAGは不要です。
- クリエイティブ業務:短い物語や画像の生成のような一部のクリエイティブ業務では、元のプロンプトで提供された情報だけで十分です。
- 推論およびデータベースのタスク:大規模データセットを扱う場合、LLMは推論と分析機能を適用するのに外部情報へのアクセスを必要としません。
- 一般的なコーディング:コーディングのワークフローでは、非公開のコードベースやドキュメントへのアクセスが必要になる場合がありますが、LLMは、外部ソースに頼らずに、バグ修正や関数の作成といった一般的なコーディングタスクを非常に高い精度で実行できます。
RAG、長文コンテキストLLM、エージェント型AI、グラウンディングの比較
RAGとLLMの違いを考えるうえで関連する概念が3つあります。長文コンテキスト対応のLLM、エージェント型AI、そしてグラウンディングです。
長文コンテキスト対応のLLMは、RAG対応システムの代わりとして使えることもあります。一方、エージェント型AIとグラウンディングは、それらと同義であったり、併用されたりします。
長文コンテキストLLM
これらは大きなコンテキストウィンドウを持つモデルで、一部の広く利用可能な商用モデルでは最大100万トークンまで扱えます。
関連する資料がモデルのコンテキストウィンドウに収まり、テキスト形式で利用可能であるなら、LLMのみのアプローチを使うメリットもあります。検索エラーの可能性を減らし、より包括的なコンテキストを提供し、大規模なRAGアーキテクチャのセットアップの必要性をなくせます。
エージェント型AI
エージェントは、RAG機能を含む複数のツールを活用して複雑なタスクを実行するシステムです。RAGはエージェント型AIの1要素であり、エージェントはプロンプトの内容に応じて、さまざまな種類の検索方法(例:ウェブ検索とベクトル検索)を使い分けることがよくあります。
グラウンディング
グラウンディングとは、証拠やデータを用いてLLMの応答の正確性を高める、より広いプロセスを指します。RAGはグラウンディングの一形態ですが、技術文書をコンテキストウィンドウに追加することもグラウンディングに含まれます。
RAGとLLM:実例
RAGが、RAGを使わないLLM利用と比べてどのように機能するかをよりよく理解するために、Perplexityを使った簡単な実例と、ベクトルデータベースを参照する仮想的な企業向けケースを見てみましょう。
RAGと簡単なプロンプトを使ったLLMの比較
Perplexityに「今日はロンドンで散歩に行くべき?」と質問し、AIウェブ検索(RAGの一形態)をオフにしたときの出力(2文に制限)は次のとおりです。
はい、天気がある程度乾いていて時間があるなら、今日のロンドン散歩は気分転換になるでしょう。サウスバンク、リージェンツ運河、またはハイド・パークを通るルートを選び、念のため軽い防水具を持っていってください。
LLMが外部ソースを確認できる場合のプロンプトと比較してみましょう。
はい、今日はロンドンを散歩するのに良い日です。予報では、19~21°C前後の穏やかな気温で、晴れ間があり、雨の確率はごくわずかです。部分的に曇り、そよ風も吹いているため、サウスバンクのような公園や川沿いのルートを散策するのに快適です。
2つの例には共通点があります。どちらもLLMが同じ基盤のトークンスコアリングプロセスを使っているからです。ただし、2つ目の例には詳細な気象情報が含まれており、そのためはるかに有用です。
エンタープライズ向けベクトルデータベースを使ったRAGとLLM
ある銀行アプリのアプリ内チャットボットに、ユーザーが次の質問をすると想像してください。「最新の取引明細はどこでダウンロードできますか?」
このアプリを管理する銀行は、最新の製品ドキュメントの埋め込みを含むデータベースを作成し、それをチャットボットのRAGパイプラインに接続しました。ドキュメントは約1,000件のソースドキュメントで構成されており、それらはより小さなチャンクに分割され、検索のためにベクトルへ変換されています。
ユーザーのクエリは埋め込みモデルに送られ、アプリケーションはそのベクトルをデータベースに送信します。するとデータベースが関連するチャンクを返します。
埋め込みモデルは、次のようなリクエストを受け取ります。
{
"input": "Where can I download my most recent statement?"
}埋め込みモデルは、次のベクトル埋め込みを返します。
{
"embedding": [0.12, -0.44, 0.87, 0.31]
}その後、ベクトルデータベースは次のようなリクエストを受け取ります。
{
"vector": [0.12, -0.44, 0.87, 0.31],
"top_k": 5
}この(大幅に単純化した)例では、データベースがユーザーのクエリに最も関連性の高い5つのチャンクを返し、それらがアプリケーションに送られてLLMのプロンプトに含められます。
RAGとLLMのどちらを選ぶか、そしていつ組み合わせるか
LLMとRAGは相補的なシステムです。したがって、「LLMを選ぶべき場合とRAGを選ぶべき場合はいつか?」という問いの立て方は適切ではありません。むしろ、「LLMだけで十分なのはいつか、RAGが最適なのはいつか?」と考えるべきです。
RAGを有効にしないLLMを使う場合
- 選択したAIモデルのコンテキストウィンドウが大きい場合:文書をアップロードするなどして、正確な回答に必要なすべての情報やデータをプロンプトに含めやすい場合は、そうすることでレイテンシを減らし、検索に関連する問題を防げます。
- 推論およびデータ分析のワークフロー:プロンプトで与えられたデータだけを参照する分析および推論のワークフローには、RAG機能は不要です。
- コード生成:RAGは一般的なコーディング作業では通常不要ですが、以前の修正やベンダーのAPI、ドキュメントを取得するようなプロジェクト固有のタスクでは、通常利用されます。
RAGを有効にしたLLMを使う場合
- 最新情報へのアクセスが必要です:AIアプリケーションが正確な回答を生成するために最新情報の外部ソースへアクセスする必要がある場合は、必ずRAG機能を有効にしてください。
- 専門分野で作業している場合:医療、法律、教育など、正確性、詳細さ、出典確認が重要な分野では、LLMのみの利用ではしばしば不十分です。
- 出力は社内ファイルを参照する必要があります:社内向けでも顧客向けアプリでも、社内文書、データ、ブランドキット、ドキュメント、ファイルに基づいてコンテンツを生成するためにAIを使う場合、RAGによってそれらの情報にアクセスできます。
RAGとLLMは、相互に補完し合いながら進化する技術です
RAGは、AIの進化における大きな革新を示しました。これは、古い情報、限られたモデルの記憶、そして関連する学習データの不足による情報の抜け漏れという3つの大きな問題に対処します。こうした問題がしばしばハルシネーションにつながっていたのです。もちろん、LLMがこれらを完全に克服したわけではありませんが、RAGの登場によってその発生は大幅に減少しました。
RAGは静的な技術ではありません。再ランキング、検索時のレイテンシとトークン使用量、有害なデータソースに対するセキュリティ防御、複数ソースから検索したデータの統合など、さまざまな領域で改善が進むと見込まれています。LLMとエージェント型AIが発展し続けるのと同様に、それらを支えるRAGシステムも進化していきます。