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

約10分

RAGを実務で設計したい方、どの構成から始めるべきか判断したい方

RAGは「ベクトル検索してLLMに渡す」だけではありません。扱う文書量、質問の複雑さ、権限、更新頻度、必要な根拠の厳密さによって、適したアーキテクチャは変わります。[1]

全体像

RAGアーキテクチャは、複雑さによって大きく次のように分けられます。

パターン	特徴	向いている用途
Naive RAG	1回検索して、その結果で回答する	小規模FAQ、プロトタイプ
Advanced RAG	検索前後に補正を入れる	社内文書検索、サポートbot
Modular RAG	検索、圧縮、再検索、検証を部品化する	本番LLMアプリ
Graph RAG	文書からエンティティ・関係・要約を作る	全体傾向、関係性、組織知識
Multimodal RAG	テキスト以外も検索対象にする	PDF、図表、画像、動画、音声
Agentic RAG	エージェントが検索行動を計画する	複雑な調査、コード理解、複数ステップ業務

このページではAgentic RAG以外の基本パターンを扱います。Agentic RAGは別ページで詳しく説明します。

Naive RAG

Naive RAGは、もっとも基本的なRAGです。

graph LR
    Q["質問"] --> E["質問を埋め込み"]
    E --> V["ベクトルDB検索"]
    V --> C["上位チャンク"]
    C --> P["プロンプトに挿入"]
    P --> L["LLM回答"]

長所

実装が簡単
プロトタイプを作りやすい
小規模で整った文書なら十分に動く
RAGの基本構造を学びやすい

弱点

検索クエリが悪いと失敗する
型番、固有名詞、エラーコードを取り逃すことがある
top-kに不要な文書が混ざる
検索結果が不足していても、そのまま回答してしまう
文書の権限や鮮度を扱いにくい

Naive RAGは「最初の一歩」としては有効ですが、本番運用ではすぐに限界が見えます。

Advanced RAG

Advanced RAGは、Naive RAGに補正処理を追加した構成です。

graph TD
    Q["質問"] --> QR["クエリ書き換え"]
    QR --> H["ハイブリッド検索"]
    H --> R["リランク"]
    R --> CC["文脈圧縮"]
    CC --> G["根拠付き生成"]
    G --> A["回答と引用"]

検索前の改善

検索前には、ユーザーの質問を検索しやすくします。

改善	内容
クエリ書き換え	会話履歴を使って省略された主語を補う
複数クエリ生成	1つの質問から複数の検索語を作る
HyDE	仮の回答文を作り、それを検索クエリとして使う
メタデータ推定	言語、製品、日付、部署などの検索条件を推定する

検索中の改善

検索中には、検索方式を組み合わせます。

検索方式	強いもの	弱いもの
ベクトル検索	意味の近さ、言い換え	正確な文字列一致
キーワード検索	型番、固有名詞、エラーコード	意味的な言い換え
ハイブリッド検索	両方の補完	スコア調整が必要
メタデータ検索	権限、日付、言語、カテゴリ	メタデータ整備が必要

実務では、ベクトル検索だけでなくBM25などのキーワード検索を組み合わせることが多くなります。

検索後の改善

検索後には、LLMへ渡す根拠を絞ります。

改善	内容
リランク	検索候補を質問への関連度で並べ直す
重複除去	同じ内容のチャンクを減らす
文脈圧縮	不要な文章を削り、根拠だけ残す
根拠評価	取得結果で答えられるか判定する

検索結果をそのまま詰め込むと、LLMがノイズに引っ張られます。RAGでは「たくさん渡す」より「必要な根拠を渡す」ことが重要です。

Modular RAG

Modular RAGは、RAGを固定パイプラインではなく、交換可能な部品の組み合わせとして設計します。

graph TD
    Q["質問"] --> Router["ルーター"]
    Router --> SearchA["製品文書検索"]
    Router --> SearchB["FAQ検索"]
    Router --> SearchC["チケット検索"]
    SearchA --> Merge["候補統合"]
    SearchB --> Merge
    SearchC --> Merge
    Merge --> Eval["根拠評価"]
    Eval -->|十分| Gen["回答生成"]
    Eval -->|不足| Retry["再検索または聞き返し"]

Modular RAGでは、次のような部品を分けます。

クエリ書き換え
情報源ルーティング
検索器
リランカー
文脈圧縮器
根拠評価器
生成器
引用整形
ガードレール

この構成は、本番運用で強みがあります。品質が悪いときに「検索器が悪いのか」「リランカーが悪いのか」「生成プロンプトが悪いのか」を切り分けやすいためです。

Graph RAG

Graph RAGは、文書を単なるチャンク集合ではなく、エンティティと関係のネットワークとして扱います。[3]

graph TD
    D["文書群"] --> EX["エンティティ・関係抽出"]
    EX --> KG["知識グラフ"]
    KG --> CS["コミュニティ要約"]
    Q["質問"] --> RET["関連ノード・要約検索"]
    CS --> RET
    KG --> RET
    RET --> A["全体像を回答"]

Graph RAGが向いているのは、次のような質問です。

この文書群の主要テーマは何ですか？
顧客要望はどの製品領域に集中していますか？
どの部署とどのリスクが関係していますか？
複数の議事録から、意思決定の流れを整理してください

従来のRAGは「答えが書かれている箇所を探す」ことに強い一方、Graph RAGは「文書群全体の構造を読む」ことに向きます。[3]

注意点

Graph RAGは強力ですが、初期構築コストが高くなります。

エンティティ抽出の品質管理が必要
グラフ更新の仕組みが必要
誤った関係抽出が回答に影響する
単純なFAQには過剰設計になりやすい

最初からGraph RAGを選ぶのではなく、全体把握や関係性の質問が本当に多いかを確認してから導入します。

Multimodal RAG

Multimodal RAGは、テキスト以外の情報も検索対象にします。

対象	例	設計ポイント
PDF	契約書、論文、仕様書	レイアウト、表、脚注を保持する
表	CSV、スプレッドシート	行列構造と単位を保持する
画像	図、スクリーンショット	OCRと画像理解を組み合わせる
音声	会議録、通話	文字起こしと話者情報を扱う
動画	講義、操作録画	時刻情報と場面単位の検索が必要

実務では、PDFを単純にテキスト抽出するだけでは不十分な場合があります。表の列関係、図のキャプション、ページ番号、見出し階層が失われると、根拠の意味が変わるためです。[4]

どの構成を選ぶか

最初から複雑なRAGを作る必要はありません。次の順番で拡張すると、失敗原因を切り分けやすくなります。

Naive RAGで最小構成を作る
検索失敗が多ければハイブリッド検索を入れる
ノイズが多ければリランカーを入れる
長文文書が多ければ階層チャンクや文脈圧縮を入れる [2]
全体質問が多ければGraph RAGを検討する [3]
複数ステップ調査が多ければAgentic RAGを検討する

実務アーキテクチャの最小推奨形

業務で使うなら、最初から次の要素は入れておくのが安全です。

要素	理由
メタデータ	権限、日付、言語、文書種別で絞り込むため
ハイブリッド検索	固有名詞と意味検索の両方に対応するため
リランク	LLMに渡す根拠の品質を上げるため
引用	ユーザーが回答を検証できるようにするため
検索失敗時の拒否	根拠がないのに答えないため
評価セット	改善が本当に効いたか測るため

まとめ

Naive RAGは学習とプロトタイプに向くが、本番では弱点が出やすい
Advanced RAGは、検索前・検索中・検索後の補正で実務品質を上げる
Modular RAGは、本番運用で原因切り分けと部品交換をしやすい
Graph RAGは、文書群全体のテーマや関係性を問う質問に向く [3]
Multimodal RAGでは、PDF、表、画像などの構造を落とさないことが重要 [4]

参考文献

クイズ

Agentic RAGとは

RAGの歴史