Skip to main content

RAG（Retrieval-Augmented Generation）とは

注：この文書は英語の原文からの自動翻訳です。

RAG（Retrieval-Augmented Generation）とは

オープンブック試験を受ける学生を想像してください。すべての質問に記憶だけで答える代わりに、学生は教科書をめくり、最も関連するページを見つけ、それを読み、覚えていた知識と新しく調べた事実を組み合わせて答えを書きます。Retrieval-Augmented Generation（RAG） は、大規模言語モデルに対して同じように働きます。モデルはトレーニング中に記憶したことだけに頼るのではなく — まず外部の 知識ベース を検索し、最も関連する文書を取得し、それらを応答を生成する際の追加のコンテキストとして使います。

この技術が重要なのは、最も強力な LLM でさえ知識のカットオフ日を持ち、「ハルシネーション」（もっともらしいが誤った言明を生成すること）を起こし得て、専門領域の知識を欠く場合があるからです。RAG は、質問に答えるたびにモデルへ最新の、領域特化の、検証可能なソースへのアクセスを与えることで、これら 3 つの弱点を一度に解決します。

要約： RAG は、検索システムと LLM を組み合わせるアーキテクチャパターンです。別個のモデルタイプではありません — 外部の知識とコンテキストを扱う方法です。

仕組み

RAG パイプラインは明確な 5 ステップの順序に従います。各ステップを理解することで、RAG を主張するプロジェクトが本当に機能する検索層を持つのか、単に標準的な LLM 呼び出しを包んでいるだけなのかを評価できます。

ステップ 1 — ユーザークエリ

プロセスは、ユーザーが質問、コマンド、またはプロンプトを送信したときに始まります。このクエリは、それ以降のすべての出発点です。例えば、ユーザーはこう尋ねるかもしれません：「先月の Ethereum における主要なガバナンス提案は何でしたか？」 システムは LLM の記憶だけから答えようとはせず — 代わりにクエリを検索の指示として扱います。

ステップ 2 — クエリの埋め込み

生のテキストクエリは、埋め込み（embedding） と呼ばれる数値表現 — クエリの意味的意味を捉える数値のベクトル — に変換されます。このステップは、専用の埋め込みモデル（OpenAI の text-embedding-ada-002 や、E5 や BGE のようなオープンソースの代替など）を使います。得られたベクトルにより、システムは セマンティック検索 — 厳密なキーワード一致ではなく意味によって文書を見つけること — を実行できます。

ステップ 3 — 知識ベースからの取得

クエリの埋め込みは、文書、パッセージ、データチャンクの事前計算された埋め込みを保持する ベクトルデータベース（ベクトルストアとも呼ばれる）と照合されます。データベースは、意味的に最も類似した上位 k 件のアイテムを返します。一般的なベクトルデータベースには Pinecone、Weaviate、Qdrant、Milvus、Chroma があります。

取得の品質はいくつかの要因に依存します。

  • チャンキング戦略 — 元の文書をどのように小さな断片に分割したか。チャンクが大きすぎると関連性が薄まり、小さすぎるとコンテキストが失われます。適切なチャンクサイズを見つけることは、RAG パイプラインで最も影響の大きいエンジニアリング上の判断の一つです。
  • 埋め込みモデル — 意味がベクトルにどれだけ正確に捉えられるか。弱い埋め込みモデルは、データベースにかかわらず弱い取得につながります。
  • 関連性ランキング — 検索が本当に関連する結果を返すのか、それとも表面的に類似しているだけのものを返すのか。一部のシステムは、cross-encoder を用いて初期結果を再スコアリングする 再ランキングステップ を追加します。

ステップ 4 — コンテキストの注入

取得された文書は、ユーザーの元のクエリと組み合わされ、LLM に送られる単一のプロンプト（「拡張プロンプト」と呼ばれることもある）になります。このプロンプトは通常、提供されたコンテキストを使って質問に答えること、そしてコンテキストに十分な情報が含まれていないときはそれを示すことをモデルに指示します。

ステップ 5 — LLM の生成と出力

LLM は拡張プロンプトを読み、事前学習された知識と取得された証拠の両方に基づいた応答を生成します。よく設計された RAG システムには、答えの一部を特定のソース文書に紐づける 引用層 も含まれることがあり、ユーザーが主張を検証する手段を与えます。

段階 入力 出力 主要なコンポーネント
クエリ ユーザーのテキスト 生のクエリ ユーザーインターフェース
埋め込み 生のクエリ クエリベクトル 埋め込みモデル
取得 クエリベクトル 関連する文書 ベクトルデータベース
コンテキスト注入 クエリ + 文書 拡張プロンプト プロンプトテンプレート
生成 拡張プロンプト 最終的な答え LLM

RAG が重要な理由

RAG は、単体の LLM のよく知られた 3 つの制限に対処します。

  • ハルシネーション。 LLM は自信に満ちているが誤った答えを生成し得ます。RAG は応答を実際の文書に基づかせることでこれを減らします。モデルが特定のパッセージを参照できるとき、捏造のリスクは大幅に下がります。
  • 古い知識。 事前学習されたモデルは知識のカットオフ日を持ちます。RAG は新鮮で継続的に更新されるデータへのアクセスを可能にします — 外部データベースは毎日、あるいはリアルタイムで更新できます。
  • 領域特化性。 狭い領域のために LLM をファインチューニングするのは高価で時間がかかります。RAG は汎用モデルが再トレーニングなしに専門の知識ベースを扱えるようにし、領域特化アプリケーションのデプロイをより速く安価にします。

RAG 対 ファインチューニング

RAG と ファインチューニング はともに、特定のタスクにおける LLM のパフォーマンス向上を目指しますが、根本的に異なる方法で機能します。

側面 RAG ファインチューニング
知識が追加されるとき 推論時（クエリごと） トレーニング時（一度、その後は静的）
更新のコスト 低い — 知識ベースを更新する 高い — モデルを再トレーニングまたは再ファインチューニングする
知識の鮮度 ほぼリアルタイムになり得る トレーニングのカットオフで凍結される
トレーニングインフラを要するか いいえ はい（GPU、データセット、トレーニングパイプライン）
最も適した用途 事実の想起、ドキュメント Q&A スタイル、トーン、形式、狭いタスクの最適化
監査可能性 高い — 取得されたソースをログに残せる 低い — 知識が重みに埋め込まれる

実務では、多くの本番システムが両方を組み合わせます：ファインチューニングされたモデルが適切なトーンとタスクの挙動を提供し、RAG が最新の事実的根拠を供給します。

高度な RAG パターン

上で説明した基本的な 5 ステップのパイプラインは、ナイーブ RAG と呼ばれることがあります。技術が成熟するにつれ、エンジニアはより洗練された変種を開発してきました。

  • マルチステップ（反復）RAG。 一度だけ取得する代わりに、システムは取得し、中間的な答えを生成し、知識のギャップを特定し、洗練されたクエリで再び取得し、答えが十分に完全になるまで繰り返します。このアプローチは、単一の取得パスでは答えられない複雑な質問を扱います。
  • エージェント型 RAG。 取得ステップが AI エージェント フレームワークの内側に包まれます。エージェントは、いつ取得するか、どの知識ベースを照会するか、クエリを再定式化するか、そして最終的な答えを生成するのに十分なコンテキストがいつ得られたかを決定します。このパターンは RAG と自律エージェントの境界を曖昧にします。
  • ハイブリッド検索。 同じ取得ステップで、ベクトルベースのセマンティック検索を従来のキーワード検索（BM25）と組み合わせます。ハイブリッド検索は意味ベースと用語ベースの両方の一致を捉え、特定の専門用語や固有名詞を含むクエリの再現率を改善します。
  • グラフ RAG。 平坦な文書チャンクの代わりに、知識ベースが 知識グラフ — エンティティと関係 — として構造化されます。取得は、ベクトル類似度に代えて（または加えて）グラフのエッジをたどり、構造化データ上のマルチホップ推論を可能にします。 これらのパターンは評価にとって重要です：反復的な取得を伴うグラフ RAG パイプラインを記述するプロジェクトは、単に「RAG を使う」と言うプロジェクトよりも具体的で（偽装しにくい）主張をしています。

RAG の現実世界の例

RAG は理論的な概念ではありません — 今日最も広く使われている AI 製品のいくつかを支えています。

  • Bing Chat（Microsoft Copilot）。 Bing Chat に質問すると、ウェブを検索し、関連するページを取得し、それらのページを LLM の答えのコンテキストとして使います。応答に見られるインライン引用は、取得ステップの直接の結果です。
  • Perplexity。 Perplexity は RAG アーキテクチャを中心に構築されています：すべてのユーザークエリがウェブ検索をトリガーし、結果が LLM に与えられ、答えには番号付きのソース参照が含まれます。ユーザーは各主張を検証するためにクリックして辿れます。
  • エンタープライズの知識アシスタント。 企業は内部の RAG システムを使って、従業員が人事ポリシー、エンジニアリングのドキュメント、法的契約を自然言語で照会できるようにします。取得層はオープンなウェブではなく、企業内部の文書ストアを検索します。 これらの例は、RAG が主流の技術であることを示しています。クリプト AI プロジェクトが「RAG を使う」と言うとき、問いは RAG が本物の技術かどうかではなく、そのプロジェクトの具体的な実装が健全かどうかです：どんなデータが取得されるか、どうインデックス化されるか、取得の品質が測定されているか。

クリプト AI プロジェクトで RAG が現れる理由

多くのクリプト AI プロジェクトは、アーキテクチャで RAG を使う、または使うと主張します。一般的なユースケースには次のものがあります。

  • ドキュメントアシスタント — プロトコルのドキュメント、ホワイトペーパー、ガバナンス提案を取得して、プロトコルのルールやパラメータに関するユーザーの質問に答える。
  • クリプトインテリジェンスツール — リアルタイムの市場データ、オンチェーンのイベント、ニュース記事を引き出して、分析サマリーやアラートを生成する。
  • エージェント向けの知識ベース — AI エージェント が行動する前に照会できる構造化されたリポジトリを構築し、判断が最新のデータに基づくことを保証する。
  • オンチェーンデータのグラウンディング — 取得層をブロックチェーンのインデクサに接続し、LLM がトレーニング時のスナップショットではなく現在の情報でウォレット残高、取引履歴、スマートコントラクトの状態に関する質問に答えられるようにする。

RAG パターンに関わる DecAIHub のプロジェクトカードの典型的な AI コンポーネントの値には、次のものがあります："3D AI agents (RAG/memory/LLM catalog)"、"AI summaries + crypto intelligence terminal"、"AgentData (real-time data streams for AI agents)"。

RAG はモデルではない

よくある誤解は、RAG を AI モデルの一種として扱うことです。そうではありません。RAG は アーキテクチャパターン — 検索システム を LLM と組み合わせる方法 — です。RAG パイプライン内のモデルは、GPT、DeepSeek、Mistral、その他いかなる LLM でもあり得ます。取得コンポーネントは、ベクトルデータベース、検索 API、または構造化された知識グラフであり得ます。

「RAG を使う」と言うことは、システムがどう構成されているかを教えてくれます。それは、どのモデルが使われているか、それが専有かどうか、取得の品質がどれほど良いかを教えてはくれません。2 つのプロジェクトがともに RAG を主張しながら、まったく異なる洗練度を持ち得ます — 一方は丁寧にキュレーションされた知識ベースとカスタムの埋め込みを持ち、他方はめったに関連する文書を返さない急ごしらえのプロトタイプです。

RAG が証明しないこと

  • RAG を使うことは、基盤となる LLM が専有またはファインチューニングされていることを 証明しません。プロジェクトはサードパーティの API を呼び出しているかもしれません。
  • RAG パイプラインを構築することは、取得の品質が高いことを 証明しません。品質は知識ベース、チャンキング戦略、埋め込みモデル、検索の関連性に依存します。
  • RAG アーキテクチャを持つことは、答えが正確であることを 証明しません。貧弱な取得は無関係なコンテキストを与え得て、LLM は依然としてハルシネーションを起こすかもしれません。
  • ランディングページで RAG に言及することは、システムが実際に取得を実行することを 証明しません。Tier-1 エビデンス — コード、アーキテクチャ図、デモログ — がなければ、その主張は未検証のままです。 RAG を主張するクリプト AI プロジェクトを評価するときは、具体性を探してください：どんな知識ベースが検索されるか、どんな埋め込みモデルが使われるか、関連性がどう測定されるか、そして何らかの 品質メトリクス が公開されているか。

DecAIHub のプロジェクトカードでどこに現れるか

RAG は通常、AI component フィールドで — 直接、または取得＋生成のパイプラインを示唆する記述を通じて — 参照されます。AI_1 フラグは、AI コンポーネントが十分な具体性で記述されているかを確認します。単に「RAG」と書くだけでは不十分です。カードは、何が、どこから、どんな目的で取得されるかを説明すべきです。

混同しないでください

  • LLM — RAG パイプライン内部の生成エンジンです。RAG はその上に取得を追加します。
  • トレーニング — RAG は推論時のパターンです。モデルを再トレーニングせず、取得されたコンテキストでプロンプトを拡張します。
  • AI エージェント — エージェントは RAG をツールの一つとして使うかもしれませんが、RAG だけでシステムがエージェントになるわけではありません。
  • ファインチューニング — ファインチューニングはトレーニング段階でモデルの重みを調整します。RAG はモデルを変更せずに推論時に外部の知識を注入します。
  • 検索／知識層 — 取得コンポーネントは RAG の半分です。RAG は純粋な取得の上に生成ステップを追加します。

よくある質問

RAG とファインチューニングの違いは何ですか？

ファインチューニング は、専門のデータセットでトレーニングすることでモデルの重みを恒久的に変更します。新しい知識がモデル自体の一部になります。RAG はモデルに手を加えず、代わりにクエリ時に関連する文書を供給します。ファインチューニングはモデルに新しいスタイルやタスク形式を教えるのに適しており、RAG は答えを新鮮で検証可能な事実に基づかせるのに適しています。多くの本番システムは両方を使います — ファインチューニングされたモデルがトーンと形式を扱い、RAG が最新の事実的根拠を提供します。

RAG は LLM をより正確にしますか？

RAG は、モデルの出力を取得された証拠に基づかせることでハルシネーションを大幅に減らせます。しかし、正確さは取得の品質に依存します。検索システムが無関係または古い文書を返すと、LLM は自信を持って誤った答えを生成し得ます — 今度は誤った証拠に裏付けられて。RAG は正確さの上限を引き上げますが、それを保証はしません。取得の精度（precision）と再現率（recall）を測定することは、真剣な RAG のデプロイすべてにとって不可欠です。

ベクトルデータベースとは何ですか？

ベクトルデータベース は、高次元の数値ベクトル（埋め込み）を保持し検索するために設計された専用のデータストアです。クエリの埋め込みが送信されると、データベースは類似度検索を — 通常は HNSW や IVF のようなアルゴリズムを用いて — 実行し、最も近い一致ベクトルを見つけます。これにより、セマンティック検索 — 厳密なキーワード一致ではなく意味によって文書を見つけること — が可能になります。一般的なベクトルデータベースには Pinecone、Weaviate、Qdrant、Milvus、Chroma があります。

RAG はクリプト AI プロジェクトでどう使われますか？

クリプト AI プロジェクトは、RAG を使って LLM をブロックチェーン固有のデータと接続します：プロトコルのドキュメント、ガバナンス提案、オンチェーンの取引履歴、リアルタイムの価格フィード、スマートコントラクトのソースコード。取得層はこれらの専門のソースを検索し、LLM が古いトレーニング知識に頼る代わりに現在のデータで領域特化の質問に答えられるようにします。そうしたシステムの品質は大きく異なります — よくインデックス化されキュレーションされた知識ベースから、有用なコンテキストをほとんど取得しない最小限の構成まで。

RAG はオンチェーンデータで機能しますか？

はい。RAG パイプラインの取得層は、ブロックチェーンのインデクサ、サブグラフ、オンチェーン分析 API に接続できます。ユーザーがウォレット残高、取引履歴、スマートコントラクトの状態について尋ねると、取得システムは関連するオンチェーンデータをフェッチし、LLM が人間が読める説明を生成します。主な課題は、遅延（ブロックチェーンのクエリは遅いことがある）、データの整形（生のオンチェーンデータは埋め込みのためにパースしチャンク化する必要がある）、そして鮮度（インデックスは現在のチェーンの状態を反映するのに十分な頻度で更新されなければならない）です。

関連ページ

外部リンク

  • Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv, 2020. https://arxiv.org/abs/2005.11401
  • Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv, 2024. https://arxiv.org/abs/2312.10997
  • AWS. "What is RAG?" https://aws.amazon.com/what-is/retrieval-augmented-generation/
  • Pinecone. "Retrieval-Augmented Generation (RAG)." https://www.pinecone.io/learn/retrieval-augmented-generation/
  • Microsoft. "Retrieval-Augmented Generation (RAG) in Azure AI Search." https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview

No comments to display

Back to top