RAGの歴史

約10分

RAGがなぜ必要になったのか、過去の検索・QA技術とどうつながるのかを理解したい方

RAGとはと LLMとは？の基礎

RAGは突然生まれた技術ではありません。検索エンジン、質問応答、知識ベース、ニューラル検索、LLMの発展が重なって、2020年代に「LLMに外部知識を読ませる標準的な設計」として広まりました。

RAG以前: 検索と生成は別々だった

RAG以前から、コンピュータは大量の文書から必要な情報を探していました。代表例が検索エンジンです。

古典的な検索では、ユーザーの検索語と文書内の単語の一致度を見ます。BM25のようなキーワード検索は、エラーコード、製品名、法令番号、固有名詞に強く、今でも実務RAGで重要です。

一方で、古典的な検索には限界があります。

検索語と文書の言い回しが違うと見つけにくい
検索結果を読んで答えを組み立てるのは人間の仕事
複数資料を横断して要約・比較するのが難しい

つまり、RAG以前の検索は「資料を見つける」技術であり、「資料を根拠に自然文で答える」技術ではありませんでした。

オープンドメインQAの時代

RAGにつながる重要な流れが、オープンドメインQAです。これは、Wikipediaなどの大規模文書集合から答えを探し、質問に短く答える研究領域です。

典型的には、次の2段階で動きます。

Retrieverが質問に関係する文書や段落を探す
Readerがその段落から答えの文字列を抽出する

この構成は、現在のRAGにかなり近い考え方です。ただし、当時の多くのQAシステムは「答えの抜き出し」が中心でした。たとえば「日本の首都はどこですか？」に対して「東京」と答えるのは得意でも、複数資料を統合して説明文を生成するのは苦手でした。

2018-2020年: ニューラル検索と生成モデルが接近した

Transformer、BERT、GPT系モデルの発展により、検索と生成の両方が大きく変わりました。

検索側では、文や段落をベクトルに変換し、意味の近さで検索する密ベクトル検索が広まりました。質問と文書の表現が完全一致しなくても、「意味が近い」文書を取り出せるようになりました。

生成側では、事前学習済みの言語モデルが長い回答を自然に生成できるようになりました。しかし、モデルの内部知識だけに頼ると、次の問題が残りました。

学習後の新しい情報を知らない
非公開文書を知らない
根拠を示せない
知らないことをもっともらしく答える

この問題意識が、RAGの中心にあります。

2020年: RAG原論文が形にしたこと

2020年の論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」は、RAGを現在の意味で広めた代表的な研究です。この論文では、事前学習済みのseq2seqモデルを「パラメトリックメモリ」、Wikipediaの密ベクトルインデックスを「ノンパラメトリックメモリ」として組み合わせました。[1]

重要なのは、知識をすべてモデルの重みに閉じ込めるのではなく、外部インデックスから取り出せるようにした点です。

graph LR
    Q["質問"] --> R["ニューラル検索"]
    R --> W["Wikipedia由来の文書"]
    W --> G["生成モデル"]
    Q --> G
    G --> A["回答"]

この考え方により、RAGは次の価値を持つようになりました。

価値	意味
更新しやすい	モデルを再学習しなくても文書インデックスを更新できる
根拠を示しやすい	どの文書を参照したかを表示できる
専門知識を足せる	社内文書、マニュアル、論文などを追加できる
生成に強い	抽出だけでなく、説明・要約・比較ができる

2022-2023年: LLMアプリケーションの標準部品になった

ChatGPT以後、RAGは研究手法から実務アプリケーションの標準部品になりました。

社内チャットbot、FAQ検索、サポート自動化、契約書検索、技術文書検索などで、「LLMに独自文書を参照させる」需要が急増したためです。

この時期の典型的な構成は、次のようなものでした。

graph TD
    D["文書"] --> C["チャンク分割"]
    C --> E["埋め込み"]
    E --> V["ベクトルDB"]
    Q["質問"] --> QE["質問を埋め込み"]
    QE --> V
    V --> K["top-kチャンク"]
    K --> P["プロンプト"]
    P --> L["LLM"]

ただし、単純な「ベクトルDB + top-k + LLM」には弱点もありました。

検索語、型番、コード名の完全一致に弱い
チャンクが小さすぎると文脈が欠ける
チャンクが大きすぎるとノイズが増える
top-kに不要な文書が混ざる
検索結果が悪いと、回答も悪くなる
権限管理や古い文書の扱いを間違えると危険

ここからAdvanced RAGが必要になりました。

2023-2024年: Advanced RAGの時代

Advanced RAGは、単純な検索パイプラインを補強する実務的な工夫の総称です。

技術	目的
ハイブリッド検索	ベクトル検索とキーワード検索を組み合わせる
クエリ書き換え	ユーザー質問を検索しやすい形にする
リランク	検索候補を質問への関連度で並べ直す
文脈圧縮	LLMに渡す前に不要な部分を削る
階層検索	詳細チャンクと要約チャンクを使い分ける
検索品質評価	検索結果が使えるかを判定する

Self-RAGは、検索が必要か、取得した根拠が有用か、生成結果が根拠に合っているかをモデルに自己評価させる方向を示しました。[2] CRAGは、検索結果の品質を評価し、不十分ならWeb検索や知識精製などの補正行動を取る設計を示しました。[3] RAPTORは、文書を再帰的に要約して木構造にし、細部と全体像の両方を検索する方向を示しました。[4]

これらの研究から見える教訓は、「RAGは検索したら終わりではない」ということです。検索前、検索中、検索後、生成後のすべてに設計余地があります。

2024年: Graph RAGと全体質問

従来のRAGは、特定の答えがどこかのチャンクに書かれている質問に強い設計でした。

しかし、次のような質問は苦手です。

この大量の議事録全体で、主要な論点は何ですか？
顧客問い合わせ全体から、製品改善テーマを分類してください
この組織のリスク構造を全体像として説明してください

このような質問は、特定の1チャンクを見つけるだけでは答えにくい「全体把握」の問題です。GraphRAGは、文書からエンティティや関係を抽出し、グラフとコミュニティ要約を作ることで、コーパス全体に対する質問に答えやすくする考え方を示しました。[5]

Graph RAGの重要性は、RAGが「検索」だけでなく「知識構造化」と結びつき始めた点にあります。

2025-2026年: Agentic RAGとコードRAG

2025年以降、RAGはエージェントと強く結びついています。

従来のRAGでは、開発者が検索手順を固定します。

質問 → クエリ変換 → 検索 → リランク → 生成

Agentic RAGでは、エージェントが状況に応じて次の行動を選びます。

質問を分解する
必要な情報源を選ぶ
キーワード検索と意味検索を使い分ける
足りなければ再検索する
根拠を読み込む
矛盾を検証する
回答する

また、コーディングエージェントの台頭により、RAGは自然文文書だけでなく、リポジトリ全体を理解するための技術にもなっています。コードでは、単純な文字数チャンクでは関数、クラス、型、テスト、依存関係が壊れます。そのため、ASTベースの構造化チャンク、シンボル検索、テスト実行ログ、過去の修正履歴などが重要になります。

歴史から見たRAGの本質

RAGの歴史を一言でまとめると、「LLMに何を覚えさせるか」から「LLMが必要な情報へどうアクセスし、どう検証するか」への移行です。

時期	中心課題	RAGへの意味
検索エンジン	文書を見つける	キーワード検索とランキングの土台
オープンドメインQA	文書から答えを抜き出す	Retriever + Readerの構成
RAG原論文	検索と生成を結合する	外部知識を生成に使う
LLMアプリ期	社内文書を参照する	ベクトルDB型RAGの普及
Advanced RAG	検索失敗とノイズを減らす	ハイブリッド検索、リランク、評価
Graph / Agentic RAG	複雑な調査と全体把握	検索計画、再検索、検証、構造化
コードRAG	リポジトリを理解する	構文、依存関係、テスト、履歴の活用

まとめ

RAGは検索、QA、ニューラル検索、生成モデルの流れから生まれた
2020年のRAG原論文は、モデル内部知識と外部メモリを組み合わせる設計を示した
2023年以降、単純なベクトル検索では不十分になり、Advanced RAGが重要になった
Graph RAG、Agentic RAG、コードRAGは、RAGを「検索パイプライン」から「知識アクセスと検証の設計」へ広げている

参考文献

クイズ

RAGアーキテクチャパターン

RAGとは