RAGとは？Retrieval-Augmented Generationの解説

Aisha Washington
6月5日
読了時間: 13分

更新日：6月17日

Retrieval-Augmented Generation (RAG) は、応答を生成する前にナレッジベースから関連文書を取得し、モデルの記憶ではなく実際のソースに基づいて回答を生成するAI技術です。モデルの重みに焼き付けられたパターンに依存するのではなく、RAGは実際のテキストを取得し、応答を作成する際の証拠として使用します。その結果、トレーニング中に見たことのない文書についても、参照できる引用付きで質問に答えられるAIが実現します。

大規模言語モデルには根本的な盲点があります。それは、実際に知っていることと自信を持ってでっち上げていることの区別ができないことです。2024年のMIT Technology Reviewの調査によると、ハルシネーションは、AIハルシネーションの原因モデルが事実ではなく統計的パターンを学習する方法に根ざしており、モデルが最近の出来事、専有データ、またはトレーニング分布外のニッチなドメインについてクエリされた場合に問題は激化します。Retrieval-augmented generationは、この構造的な欠陥への直接的な対応として登場しました。RAGは、取得したソーステキストに生成をアンカーすることで、失敗モードを自信のある作り話から正直な「ドキュメントが見つかりません」にシフトさせます。

主なポイント

RAGは1文でどのように機能するか: RAGは、クエリ時に関連するドキュメントチャンクを取得し、それを言語モデルにフィードして、ソースに裏付けられた、根拠のある回答を生成します。
RAG vs. ファインチューニング: ファインチューニングは知識をモデルの重みに永続的に焼き付けますが、RAGはクエリ時に知識を動的に取得します。これらは異なる問題を解決し、知識集約型のタスクではほぼ常にRetrieval augmented generationが求められます。
RAG が適切な選択肢となる場合:RAG は、ナレッジベースが頻繁に変更される場合、回答が監査可能である必要がある場合、またはトレーニングデータに入力できないプライベートドキュメントを扱う場合に最適です。
ローカル RAG とは:ローカル RAG は、リトリーバルパイプラインを完全にオンデバイスで実行するため、ドキュメントはマシンから離れることはありません。これは、個人的なメモ、医療記録、法的ファイル、またはクラウドサービスにアップロードしたくないあらゆるコンテキストにとって重要です。

以下のセクションでは、リトリーバル拡張生成がどのように機能するか、ファインチューニングやベクトルデータベースと比較してどう違うか、そしてツールが実際に正しく実装されているかどうかをどのように評価するかを説明します。自分のドキュメントで実際に試したい場合は、remio を無料でお試しください。

リトリーバル拡張生成が実際に行うこと

リトリーバル拡張生成は 2 段階のアーキテクチャです。ナレッジベースから最も関連性の高い箇所を見つけるリトリーバル段階と、それらの箇所を根拠のあるコンテキストとして使用するジェネレーション段階です。言語モデルは決して単なる記憶から操作するのではなく、証拠から操作します。この分離が、RAG をトレーニング中に学習したパターンのみに依存する標準的なチャットボットとは根本的に異なる点です。また、モデルがアクセスできる知識はトレーニング時に固定されるのではなく、ドキュメントストアを変更することで継続的に更新できることも意味します。

このアーキテクチャは、リトリーバルまたはジェネレーションのいずれか単独では実現できない 3 つの明確な機能を提供します。

根拠: すべての回答は、ナレッジベースの特定の箇所にまでたどることができます。プロンプト自体には取得されたテキストのみが含まれているため、モデルはソースが裏付けない事実を発明することはできません。根拠は、RAGを事実に関する質問に対して信頼できるものにするメカニズムです。
動的な知識: ナレッジベースはモデルの重みとは別のストレージレイヤーです。更新するということは、モデルを再トレーニングするのではなく、ドキュメントを追加または編集することを意味します。法務チームは、今朝新しい規制を追加し、エンジニアリング作業なしで、午後にすぐにアクセスできるようにすることができます。
ソースの追跡可能性: 取得されたチャンクは明示的にプロンプトに入るため、システムはどのドキュメントが各回答を生成したかを知っています。これにより、取得拡張生成は監査対象環境に適しています。コンプライアンスチーム、医療記録、カスタマーサポート、または回答に引用を伴う必要があるあらゆる場所で使用できます。

3段階パイプライン: RAGはどのように回答を生成するか

Lewisらによって、彼らの2020年のNeurIPSの論文で紹介されたオリジナルの取得拡張生成アーキテクチャは、ほとんどの実装が今日でも従っている3段階のパイプラインを確立しました。各段階には独自の役割があり、いずれかの段階での失敗は最終的な回答の品質を低下させます。各ステップの仕組みを理解することは、取得拡張生成が成功する場所と、まだ不十分な場所を明確にするのに役立ちます。また、システムが不十分な回答を生成した場合に、パイプラインのどの部分を改善すべきかを示します。

ステップ 1: チャンキングとインデックス作成、ナレッジベースの準備

クエリが到着する前に、検索用にドキュメントを準備する必要があります。ドキュメントの取り込みプロセスでは、生のテキストをチャンク（通常は 200 ～ 500 トークン）に分割します。これは、意味的な一貫性を保ちつつ、複数のチャンクを単一のプロンプトに収めるのに十分な小ささになるように選択されます。次に、各チャンクはベクトル埋め込み（その意味の高次元数値表現）に変換され、元のテキストと共にベクトルデータベースに保存されます。

この前処理ステップは、ユーザーが質問する前にオフラインで行われます。結果として、キーワードの一致ではなく、意味的な類似性によって各チャンクを検索できるインデックスが作成されます。チャンキングの品質は検索精度に直接影響します。不適切に分割されたドキュメントは、無関係なトピックが混在するチャンクを生成し、クエリ時にノイズが多く関連性の低い一致を返します。

ステップ 2: 検索、適切なチャンクの特定

ユーザーがクエリを送信すると、システムはインデックス作成中に適用されたのと同じ埋め込みモデルを使用して、そのクエリをベクトル埋め込みに変換します。次に、クエリベクトルとインデックス内のすべてのチャンクベクトルとの間の類似性スコアを計算し、渡すための上位 k 個の最も意味的に類似したチャンクを返します。

これは、司書があなたの質問を聞き、書架に入って、コレクション全体を記憶から読み上げるのではなく、最も関連性の高い 5 冊の本を持ってくるようなものです。検索ステップではキーワードの重複は必要ありません。意味が一致します。「契約更新が却下された理由」に関するクエリは、単語が共有されていなくても、「契約終了条項」に関する一節を提示できます。

ステップ 3: 拡張生成、証拠に基づいた回答

取得されたチャンクと元のクエリは、拡張プロンプトに連結されます。モデルは証拠と質問を一緒に確認します。次に、言語モデルは、トレーニングメモリから自由に発明するのではなく、ソーステキストによって制約された、その結合された入力を使用して応答を生成します。

1 つの制限は直接認識に値します。生成された回答の品質は、検索の品質に完全に依存します。関連ドキュメントがインデックス化されなかった場合、またはチャンキングによって重要な箇所が断片化された場合、取得されたチャンクに必要なものが含まれていないため、モデルは依然として不正確な回答を生成する可能性があります。検索拡張生成は、ナレッジベース内の質問に対する幻覚を大幅に減らしますが、ナレッジベースで回答できない質問のエラーを排除するわけではありません。

RAG vs. ファインチューニング: 2 つの異なる問題

RAGはクエリ時に知識を取得し、ファインチューニングは知識をモデルの重みに焼き込みます。これらは同じタスクに対する競合するアプローチではなく、根本的に異なる問題を解決するため、どちらを選択するかは実際の問題の種類を理解する必要があります。

知識の鮮度

RAG：ドキュメントの追加または編集により知識ベースを更新します。変更は即座に利用可能になり、モデルの変更は不要です。
ファインチューニング：新しい知識には新しいトレーニング実行が必要であり、データセットのサイズとハードウェアによっては数時間から数日かかる場合があります。

コスト

RAG：コストは主にストレージと検索インフラストラクチャによって決まります。ベクトルデータベースはほとんどのスケールで安価であり、インデックス作成後のGPUコンピューティングは不要です。
ファインチューニング：かなりのGPUトレーニングコンピューティングが必要です。2024年のarXivの分析によると、LLMファインチューニングのコスト 7Bパラメータモデルの場合、実行あたり1,000ドルから12,000ドルに達する可能性があり、モデルサイズとともに急激に増加します。

透明性

RAG: すべての回答のソースはプロンプトで明示されています。どのドキュメントがどの応答を生成したかをログに記録し、特定のエラーを特定のチャンクにまで追跡できます。
ファインチューニング: 知識は数十億のモデルの重みに分散されています。特定の出力にどのトレーニング例が影響したかを監査するメカニズムはありません。

最適な用途

RAG: 動的、プライベート、または検証可能な知識。頻繁に変更される情報。コンプライアンスが重視される環境。個人のドキュメントライブラリ。
ファインチューニング: モデルの出力スタイル、トーン、またはフォーマットを固定ドメインに適応させる。事実の鮮度よりも行動の一貫性が重要なタスク。

個人のナレッジベース、エンタープライズドキュメントリポジトリ、リアルタイム情報検索には、Retrieval Augmented Generation (RAG) がほぼ常に正しいアーキテクチャです。モデルをファインチューニングして会議のメモを記憶させるのは、遅く、はるかに高価で、再トレーニングなしでは更新不可能になります。知識が頻繁に変更される場合、RAG は、継続的なエンジニアリングコストなしで追いつくことができる唯一のアプローチです。

RAG vs. ベクトルデータベース: 同じものではありません

ベクトルデータベースは埋め込みを格納し、類似性検索をサポートします。RAG は、ベクトルデータベースを複数のコンポーネントの 1 つとして使用する完全なアーキテクチャです。この 2 つを混同することは、この分野に新しい開発者の間で最も一般的な誤解の 1 つであり、実際に機能するシステムを構築しようとしている人にとって、その混乱は実用的な結果をもたらします。

その区別は具体的です。ベクトルデータベースは、「このクエリに最も類似しているチャンクはどれか？」という質問に答えます。Retrieval Augmented Generation は、その回答を中間ステップとして使用し、取得したチャンクを言語モデルにルーティングして、自然言語の応答を合成します。ベクトルデータベースを持つことは、検索能力を提供します。RAG を持つことは、その検索レイヤー上に構築された完全な質疑応答パイプラインを提供します。

有用な例え: ベクトルデータベースは、図書館の書架とカタログシステムです。RAG は、司書が本を見つけ、関連セクションを読み、平易な言葉で回答を説明する、完全な図書館サービスです。テキストを生成することなく、ベクトルデータベースを構築およびクエリできます。検索レイヤーなしでは RAG システムを実行できませんが、検索だけでは RAG ではありません。

実際的な意味合い：製品が「ベクトル検索を使用する」や「ドキュメントを埋め込む」と主張する場合、取得したコンテキストから回答も生成するかどうかを尋ねてください。ベクトル検索は関連するパッセージのリストを返しますが、検索拡張生成システムはそれらのパッセージを使用して直接的な応答を構成します。両者は関連していますが、抽象化のレベルが異なり、一方が他方を意味するわけではありません。

RAGの実践、remioがパーソナルRAGを構築する方法

ほとんどのRAGデプロイメントはエンタープライズサーバー上で実行され、管理のために専用のインフラストラクチャとITの監督が必要です。remioは、同じ検索拡張生成アーキテクチャをパーソナルデバイスにもたらします。その際、1つの意図的な設計上の決定があります。すべての検索はローカルで実行され、データはマシンから決して離れません。検索拡張生成の価値は、単に根拠のある回答だけでなく、共有された公開コーパスではなく、あなた自身の履歴からの根拠のある回答です。

remioに質問すると、インターネットではなく、会議、ドキュメント、ブラウジング履歴を検索し、あなた自身の過去からの回答を提示します。検索パイプラインは、あなたのパーソナルコンテキストから構築されたローカルベクトルインデックスに対して実行されます。クラウドを介さず、データのアップロードもなく、あなたのノートが他人のクエリに表示される可能性のある共有モデルもありません。プライバシー保証は構造的なものであり、ポリシーの問題ではありません。

このアーキテクチャは、プライバシーが重要な資料（面接メモ、顧客契約、医療記録、個人的な研究など）にとって最も重要です。ホストされたサービスではなくローカルベクトルストアを選択すると、プロバイダーが侵害された場合でも、ドキュメントが公開されることはありません。なぜなら個人の知識検索, remio は、クラウドインフラストラクチャや運用に必要な IT チームを必要とせずに、個人の蓄積されたコンテキストにスケーリングできる方法で検索拡張生成を適用します。

検索拡張生成に関するよくある質問

Q: RAG はセマンティック検索と同じですか？

A:セマンティック検索は、クエリに最も類似したドキュメントを見つけ、読めるように表示します。RAGはさらに一歩進んで、それらのドキュメントを取り込み、それらから直接自然言語の回答を合成します。セマンティック検索は証拠を返しますが、Retrieval-Augmented Generation（RAG）はそれを解釈し、応答を構成します。

Q:RAGは機能するためにファインチューニングが必要ですか？

A:いいえ。Retrieval-Augmented Generation（RAG）は、クエリ時に知識を取得し、それをプロンプトコンテキストとして言語モデルに渡します。モデルの重みは変更されません。標準的な事前学習済みベースモデルが生成レイヤーとして機能し、これがRAGがほとんどのユースケースでファインチューニングよりも迅速かつ安価にデプロイできる理由の1つです。

Q:RAGベースのツールを使用している場合、私のデータは安全ですか？

A:デプロイメントアーキテクチャに完全に依存します。ローカルRAGは、すべてのドキュメントと埋め込みをオンデバイスに保持します。外部サーバーには何も到達しません。クラウドRAGは、ドキュメントをホストされたサービスに送信して埋め込みを生成し、検索を実行します。プライバシーへの影響は大きく異なり、機密性の高い個人データまたは専門データにとっては、その違いが重要になります。RAGベースの製品を評価する際は、埋め込みがどこに保存されているか、そしてどちらの当事者がそれを制御しているかを明確に質問してください。

Q: RAGは、チャットにドキュメントを貼り付けるのとどう違うのですか？

A: チャットウィンドウにドキュメントを貼り付けると、コンテキストウィンドウのサイズとデータの公開という2つの厳しい制限に直面します。たとえ大きなコンテキストウィンドウでも、おそらく75,000語しか保持できず、ドキュメント全体がモデルプロバイダーのサーバーに送信されます。RAGは、クエリ時に関連するチャンクのみを取得し、あらゆるサイズのナレッジベースに拡張でき、ローカルデプロイメントではソースマテリアルを完全にプライベートに保ちます。数ページを超えるものについては、取得拡張生成（retrieval-augmented generation）が唯一実用的なアーキテクチャです。