RAG(検索拡張生成)のアーキテクチャは、単純な「検索して生成する」Naive RAGから、複数の拡張技術を組み合わせたAdvanced RAG、そしてモジュール単位で柔軟に組み替えるModular RAGへと進化しています。本記事では3世代のアーキテクチャそれぞれの設計思想と実装上のポイント、選定フレームワークまでを体系的に解説します。最小構成から始めて必要に応じて拡張するのが鉄則であり、最初から過度に複雑な設計を目指す必要はありません。

RAGアーキテクチャの3世代

RAGの設計思想はここ数年で急速に体系化が進み、現在では「3世代モデル」として整理されることが一般的です。第1世代のNaive RAGは、ユーザーのクエリを直接ベクトル検索にかけ、取得した結果をLLMに渡すだけのシンプルな構造です。第2世代のAdvanced RAGは、検索前・検索中・検索後の各段階に様々な最適化処理を挟み込むことで、精度と応答品質を向上させます。第3世代のModular RAGは、各機能を独立したモジュールとして設計し、用途に応じて自在に組み替える柔軟性を持たせたアプローチです。

この進化は、RAGの実運用で明らかになった課題に対する現場の解答でもあります。3世代それぞれの特徴を理解し、自社の要件に合った世代を選ぶことが、RAGプロジェクトの成否を分ける重要な意思決定となります。

【RAGアーキテクチャ3世代の比較】

第1世代: Naive RAG
  [クエリ] --> [ベクトル検索] --> [LLM生成] --> [回答]

第2世代: Advanced RAG
  [クエリ]
      |
      v
  [Pre-Retrieval: クエリ拡張 / HyDE]
      |
      v
  [Retrieval: ハイブリッド検索]
      |
      v
  [Post-Retrieval: リランク / 圧縮]
      |
      v
  [LLM生成] --> [回答]

第3世代: Modular RAG
  [Router] --+--> [Search Module]
             +--> [Rerank Module]
             +--> [Memory Module]
             +--> [Generate Module]
             +--> [Evaluate Module]
  ※ 各モジュールが独立、組替え可能

Naive RAG――最小構成の基本アーキテクチャ

Naive RAGはRAGの原型となるアーキテクチャで、実装の簡単さが最大の魅力です。構成要素は「チャンキング済み文書のベクトル化」「ベクトルDBへの格納」「クエリのベクトル化による類似検索」「検索結果をプロンプトに埋め込んでLLMで生成」の4ステップのみ。LangChainやLlamaIndexなら数十行のコードで動き始めます。

しかしシンプルさゆえの限界もあります。第一に、ユーザーの質問表現と文書表現のギャップを吸収できず、本来ヒットすべき文書が検索上位に来ないことがあります。第二に、チャンク品質が検索結果に直結するため、粗いチャンキングでは無関係な情報が混入しやすくなります。第三に、取得した複数のチャンクをLLMが十分に活用できず、重要情報がコンテキストの後半に埋もれて「Lost in the Middle」と呼ばれる現象を引き起こすこともあります。

# Naive RAGの最小実装
from langchain_community.document_loaders import DirectoryLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA

loader = DirectoryLoader("./docs", glob="**/*.md")
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(docs)

vectordb = Chroma.from_documents(chunks, OpenAIEmbeddings())
retriever = vectordb.as_retriever(search_kwargs={"k": 4})

qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o", temperature=0),
    retriever=retriever
)
print(qa.invoke("稟議の承認ルートを教えて")["result"])

Advanced RAG――精度を飛躍させる拡張パターン

Advanced RAGは、Naive RAGの各ステップに前後処理を差し込むことで精度を引き上げるアーキテクチャです。改善ポイントは大きく3箇所に分類できます。

Pre-Retrieval段階では、検索を行う前にクエリそのものを強化します。代表的な手法として、同義語や言い換えでクエリを複数生成するクエリ拡張、LLMで仮の回答を生成してから検索するHyDE、ユーザー意図を先にLLMに解釈させるクエリ分解などがあります。Retrieval段階では、ベクトル検索に加えてキーワード検索(BM25など)を組み合わせるハイブリッド検索、階層的な文書構造を活用するペアレントチャイルド検索、メタデータでフィルタする手法が有効です。

Post-Retrieval段階では、取得済みチャンクの扱いを洗練させます。クロスエンコーダを用いたリランキングで上位の関連性を引き上げ、コンテキスト圧縮で無関係な文を除去し、並び替えで重要情報をプロンプトの先頭や末尾に配置します。これらの処理を組み合わせることで、同じLLMと同じ文書でも回答精度が大きく変わります。

段階テクニック効果実装難易度適した課題
Pre-Retrievalクエリ拡張検索ヒット率の向上低表記ゆれの多い文書群
Pre-RetrievalHyDEクエリと文書の表現ギャップ解消中質問が抽象的
Pre-Retrievalクエリ分解複合的な質問への対応中複数観点の質問
Retrievalハイブリッド検索固有名詞検索の強化中製品名・型番検索
Retrievalメタデータフィルタ誤ヒットの削減低文書種別が多岐
Post-Retrievalリランキング上位精度の向上中候補数が多い
Post-Retrievalコンテキスト圧縮ノイズ除去・コスト削減中長文チャンク
Post-Retrieval並び替えLost in the Middleの緩和低多数チャンク投入時
# リランキングを組み込んだAdvanced RAGの例
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import CohereRerank
from langchain.chains import RetrievalQA

vectordb = Chroma(
    persist_directory="./chroma_db",
    embedding_function=OpenAIEmbeddings()
)

# 1段目: ベクトル検索で20件広めに取得
base_retriever = vectordb.as_retriever(search_kwargs={"k": 20})

# 2段目: Cohere Rerankで上位4件に絞り込み
compressor = CohereRerank(top_n=4, model="rerank-multilingual-v3.0")
retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=base_retriever
)

qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o", temperature=0),
    retriever=retriever,
    return_source_documents=True
)

result = qa.invoke("育児休業の申請期限について教えて")
print(result["result"])

Modular RAG――柔軟に組み替えるアーキテクチャ

Modular RAGは、RAGの構成要素を「検索」「生成」「ルーティング」「メモリ」「評価」といった独立したモジュールとして設計する思想です。Advanced RAGが固定パイプラインを強化するのに対し、Modular RAGはパイプライン自体を動的に組み替えられる点が本質的な違いです。

例えば、ユーザーの質問が単純な事実確認ならベクトル検索モジュールだけで完結させ、複雑な集計が必要ならSQLクエリ実行モジュールを呼び出す、というように質問の性質に応じて処理経路を切り替えられます。この考え方を突き詰めると、LLM自身が「どのモジュールをどの順序で呼ぶか」を判断するAgentic RAG(B-14参照)にたどり着きます。Modular RAGはAgentic RAGへの橋渡しとなる重要な設計思想です。

【Modular RAGのモジュール構成】

                [User Query]
                     |
                     v
            [Router / Planner]
                     |
         +-----------+-----------+
         |           |           |
         v           v           v
    [Keyword     [Vector      [SQL
     Search]      Search]     Query]
         |           |           |
         +-----+-----+-----+-----+
               |           |
               v           v
         [Rerank]     [Memory]
               |           |
               +-----+-----+
                     |
                     v
             [Generate Module]
                     |
                     v
             [Evaluate Module]
                     |
                     v
                 [Response]

※ 各モジュールはプラグイン方式で差し替え可能

アーキテクチャ選定のフレームワーク

3世代のアーキテクチャから自社に合うものを選ぶには、データ量、精度要件、開発リソース、レイテンシ要件の4軸で整理するのが実務的です。以下のマトリクスを出発点として、段階的に進化させるロードマップを描くと良いでしょう。

要件Naive RAGAdvanced RAGModular RAG
データ量〜数千件数千〜数十万件数十万件以上
精度要件中高非常に高い
開発リソース1〜2名 / 1〜2週2〜4名 / 1〜2ヶ月3〜5名 / 2〜4ヶ月
レイテンシ要件秒単位数秒許容用途次第(可変)
拡張性低中高
向いているフェーズPoC社内本番エンタープライズ
【アーキテクチャ選定の判断ツリー】

Q1. まず動くプロトタイプが必要？
├── Yes → Naive RAGで開始
│           └── Q2. PoCで十分な精度が出た？
│                 ├── Yes → 本番化(必要なら最低限の強化)
│                 └── No  → Advanced RAGへ
│
└── No  → Q3. 複数の検索源を統合する必要がある？
            ├── Yes → Modular RAG / Agentic RAGを検討
            └── No  → Advanced RAG(リランク + ハイブリッド検索)

重要なのは「最初からModular RAGを目指さない」ことです。多くのプロジェクトはAdvanced RAGで必要十分であり、過剰な設計は開発コストとメンテナンス負荷を膨らませるだけで終わります。データと使われ方が成熟した段階で、次の世代への移行を検討しましょう。

まとめ――「最小構成で始めて段階的に進化させる」が鉄則

  • RAGアーキテクチャは Naive → Advanced → Modular の3世代で進化している
  • Advanced RAGはPre-Retrieval / Retrieval / Post-Retrievalの3段階で強化する
  • Modular RAGは機能をモジュール化し、Agentic RAGへの橋渡しとなる
  • 選定は要件から逆算し、最小構成から段階的に進化させるのが王道

DE-STKではRAGアーキテクチャの現状評価から次世代構成への移行支援まで、実装と運用の両面でサポートしています。現行RAGの改善余地を可視化するアーキテクチャレビューもご相談ください。

よくある質問(FAQ)

Q. Naive RAGとAdvanced RAGの違いは何ですか?

Naive RAGはシンプルな「検索→生成」のパイプラインで、Advanced RAGはクエリ拡張、リランキング、コンテキスト圧縮などの技術を追加して検索精度と回答品質を向上させたアーキテクチャです。Advanced RAGは処理ステップが増える代わりに、Naive RAGが苦手とする表現のゆれや固有名詞の検索にも対応しやすくなります。

Q. RAGのアーキテクチャはどこから始めるべきですか?

まずNaive RAGで最小構成のプロトタイプを構築し、精度評価を行った上で、不足している部分にAdvanced RAGのテクニックを段階的に追加するアプローチが推奨されます。最初から複雑なアーキテクチャを組むと、どの改善が効いたのかを特定しづらくなり、長期的な改善サイクルが回りにくくなる点に注意してください。

Q. Modular RAGとは何ですか?

検索、生成、ルーティングなどの各機能をモジュールとして独立設計し、柔軟に組み合わせるRAGアーキテクチャです。AIエージェントと組み合わせたAgentic RAGもこの延長線上にあり、複雑なクエリに対して自律的に検索戦略を決定できます。モジュール化により改善サイクルが高速化する反面、設計・運用の複雑度も上がるため、本格的なプロダクション利用を前提とした構成です。