メインコンテンツまでスキップ

RAG(Retrieval-Augmented Generation)

Overview​

RAGは、LLMが回答を生成する前に外部知識を検索して、その結果をコンテキストとして渡す構成。
学習済みモデルだけに依存せず、社内文書や最新情報を参照できるため、回答の鮮度と根拠を補いやすい。
RAGは「ベクター化」そのもののことではなく、「ベクター化などの技術を使って外部から情報を探し出し、AIに賢く答えさせるシステム全体」を指す言葉。
ベクター化は、RAGという大きな仕組みを動かすための「一つの部品（工程）」に過ぎない。

ヒント

2023年は社内ドキュメントなどを検索して自然文での質問に対して解凍を生成するRAGが多くの企業に導入・構築された年

注記

2023年頃まではAIが一度に読み込める文字数が少なかったため、ベクター化（RAG）が必須だった。
しかし現在のGeminiは、ドキュメント丸ごと（本数冊分や大量のPDF）をそのまま1つのプロンプトに放り込んで質問しても、超高精度で回答できるようになっている。

RAGとは​

RAGは Retrieval-Augmented Generation の略で、日本語では「検索拡張生成」と呼ばれる。
大まかな流れは次の通り。

1. ユーザーが質問する
2. 質問文をもとに関連文書を検索する
3. 検索結果をLLMへ追加コンテキストとして渡す
4. LLMが参照情報を踏まえて回答を生成する

この構成により、モデルの事前学習データに含まれない情報や、頻繁に更新される情報も扱いやすくなる。

なぜRAGが必要か​

LLM単体では、次の制約がある。

  • 学習時点以降の情報を知らない
  • 社内Wikiや顧客固有データのような非公開情報を参照できない
  • もっともらしい誤答を返すことがある
  • 回答の根拠を提示しづらい

RAGはこれらを完全に解決するわけではないが、少なくとも「何を根拠に答えたか」を検索結果に寄せられる。
FAQ、社内ナレッジ検索、サポート支援、規程参照のような用途では特に有効。

基本アーキテクチャ​

RAGは大きく分けると、オフラインの知識準備と、オンラインの検索・生成に分かれる。

オフライン処理​

  • 文書を収集する
  • 前処理を行う
    • ノイズ除去
    • 見出し構造の整理
    • メタデータ付与
  • 文書をチャンクに分割する
  • ベクトル化してベクトルデータベースや検索基盤へ保存する

オンライン処理​

  • ユーザーの質問を受け取る
  • クエリをもとに関連チャンクを検索する
  • 必要に応じて再ランキングする
  • 検索結果をプロンプトへ注入する
  • LLMが最終回答を生成する

主要コンポーネント​

1. データソース​

対象となる知識そのもの。
例として、社内文書、Notion、Confluence、FAQ、API仕様書、問い合わせ履歴などがある。

2. チャンク分割​

文書をそのまま丸ごと検索すると粒度が粗くなりやすいため、一定単位に分割して扱う。
チャンクが大きすぎるとノイズが増え、小さすぎると文脈が欠ける。

3. 埋め込みモデル​

文書やクエリをベクトルに変換するモデル。
意味的に近い内容を検索するための基盤になる。

4. 検索基盤​

ベクトル検索、キーワード検索、またはその両方を組み合わせたハイブリッド検索を行う。
実運用では、完全一致が必要な固有名詞や型番を扱うために、ベクトル検索だけでなくBM25系の全文検索を併用することが多い。

5. リランカー​

一次検索の結果を、質問との関連度でもう一度並び替える層。
検索精度が重要なケースでは、最終回答の品質に強く影響する。

6. 生成モデル​

取得した文脈をもとに回答するLLM。
ここで重要なのは、モデル性能だけでなく「どういう文脈を渡したか」で回答品質が大きく変わる点。

検索方式の考え方​

RAGの性能は、生成よりも先に検索品質で頭打ちになりやすい。

  • キーワード検索
    • 正確な語句一致に強い
    • 製品名、エラーコード、社内用語に向いている
  • ベクトル検索
    • 言い換えや意味の近さに強い
    • 自然文の質問に向いている
  • ハイブリッド検索
    • 両者の長所を組み合わせる
    • 実務では最初の選択肢になりやすい

「検索できない情報」は、どれだけ高性能なLLMでも回答品質を上げられない。
そのためRAGでは、モデル選定より先にデータ整備と検索設計を詰める方が効果的なことが多い。

RAG設計で重要な論点​

チャンクサイズ​

チャンクサイズは検索精度と文脈保持のバランスに直結する。
見出しや段落など、意味的な区切りを活かして分割する方が機械的な固定長分割より扱いやすいことが多い。

メタデータ設計​

文書種別、更新日、サービス名、権限範囲などのメタデータを持たせると絞り込みや表示制御がしやすい。
特にマルチテナントや部門別データを扱う場合は必須に近い。

鮮度管理​

元データが更新されてもインデックスが古いままだと、もっともらしいが古い回答が生成される。
クロール頻度、差分更新、失効戦略まで含めて設計する必要がある。

根拠の提示​

検索結果の出典リンクや文書タイトルを回答に含めると、利用者が検証しやすい。
RAGは「正解を保証する仕組み」ではなく、「検証しやすい回答に寄せる仕組み」と捉える方が実態に近い。

評価方法​

RAGは主観評価だけだと改善しづらい。
少なくとも次の観点を分けて見るとよい。

  • 検索評価
    • 必要な文書が上位に出るか
  • 生成評価
    • 取得文脈に忠実な回答になっているか
  • 体験評価
    • レイテンシ、引用の見やすさ、再質問のしやすさ

RAGのメリット​

  • 最新情報や非公開情報を回答に反映しやすい
  • モデル再学習なしで知識を更新しやすい
  • 出典提示により説明責任を持たせやすい
  • ドメイン特化のQAを比較的短期間で作りやすい

RAGの限界​

  • 検索に失敗すると回答品質も下がる
  • 元文書が曖昧だと、その曖昧さを引き継ぐ
  • 長い文脈を詰め込みすぎるとノイズになる
  • アクセス制御や個人情報管理を誤ると危険
  • 高品質化にはデータ整備、評価基盤、運用コストが必要

向いているケース​

  • 社内ドキュメント検索
  • カスタマーサポート支援
  • 法務・規程・手順書の参照
  • 製品マニュアルやAPI仕様のQA

向いていないケース​

  • 推論そのものが主課題で、参照知識がほとんど不要なケース
  • 正式な検索基盤やナレッジ運用がまだ整っていないケース
  • リアルタイム性や厳格な正確性が要求され、生成文を挟みたくないケース

Resource​