← 記事一覧へ

RAG とは

RAG（Retrieval-Augmented Generation、検索拡張生成）は、言語モデルが回答する前にナレッジベースから関連する断片を検索し、そのうえでテキストを生成する手法です。すべてのドキュメントをモデルの重みに「覚えさせたり」、コンテキストに丸ごと載せたりする代わりに、必要な部分を探してプロンプトに差し込みます。以下では RAG の意味、パイプラインの仕組み、本番で使うべき場面を説明します。

平易な定義

Retrieval-Augmented Generation は2段階で成り立ちます：

  1. Retrieval（検索） - ユーザーの質問に対し、コーパス（wiki、PDF、チケット、コード、規程）から最も適したテキスト断片を見つける。
  2. Generation（生成） - LLM が検索結果をコンテキストとして受け取り、それに基づいて回答を組み立てる。

この用語は Lewis ら（2020）以降に定着し、企業向けチャットボット、サポート、社内アシスタントの標準になりました。RAG はモデルを置き換えません - 学習に含まれていない、または昨日更新された最新データでモデルを補強します。

RAG の動き：典型的なパイプライン

┌──────────┐    ┌─────────────┐    ┌──────────────┐    ┌─────────┐
│ドキュメント│───▶│ Chunking +  │───▶│ Vector DB    │    │         │
│ (PDF, MD)│    │ Embeddings  │    │ (インデックス)│    │   LLM   │
└──────────┘    └─────────────┘    └──────┬───────┘    │         │
                                          │            │         │
質問 ──▶ Embedding ──▶ Top-K ──▶ Prompt + コンテキスト ──▶ 回答

1. データ準備（オフライン）

  • 取り込み - PDF、HTML、Markdown、Confluence、Notion、リポジトリのパース。
  • Chunking - 256-1024 トークン程度に分割（オーバーラップ付き）し、段落境界で意味が切れないようにする。
  • Embedding - 各 chunk を埋め込みモデルでベクトル化（OpenAI text-embedding-3、Cohere、オープンソース BGE、E5）。
  • インデックス - ベクトルを vector store に保存：Pinecone、Weaviate、Qdrant、pgvector、Chroma、Milvus。

この段階はドキュメント追加・更新時に実行され、ユーザーごとのリクエストではありません。

2. クエリ（オンライン）

  1. ユーザーの質問も同じエンコーダで埋め込む。
  2. vector DB が Top-K の近傍 chunk を返す（通常 K = 3-10）。
  3. 任意で reranking - 第2モデルがコサイン類似度だけより精度よく関連度で並べ替え。
  4. 見つかった断片を system/user プロンプトに入れ、「コンテキストのみに基づいて答えよ」と指示。
  5. LLM が回答を生成；引用（chunk id やソースページ）を付けることも多い。

RAG の品質の約80%は retrieval で決まります。正しい断片が Top-K に入らなければ、モデルは幻覚するか、正直に「わかりません」と答えます。

主要コンポーネント

コンポーネント 役割 例
埋め込みモデル テキスト → 意味検索用ベクトル text-embedding-3-large、bge-m3、voyage-3
ベクトルDB 保存と高速 ANN 検索 Qdrant、Pinecone、pgvector、Weaviate
Chunking 戦略 粒度とノイズのバランス 固定長、意味分割、見出し単位
LLM 推論付き最終回答 GPT-5.6、Claude Fable 5、Gemini 3.1、ローカルモデル
オーケストレータ 段階の接続、キャッシュ、ログ LangChain、LlamaIndex、Haystack、自前実装

2026年時点で LlamaIndex、LangGraph などのフレームワークや Cursor @Codebase、Notion AI、Glean 型の企業システムが内部で RAG を実装していますが、デバッグとチューニングには基本パイプラインの理解が必要です。

実務での用途

  • サポートと FAQ - 記事ベースと過去チケットから回答、手動検索不要。
  • 社内 wiki - 「有休の取り方」「インシデント runbook はどこ」。
  • 法務・コンプライアンス - 契約・規程検索と条項参照。
  • コードアシスタント - リポジトリの意味検索（ファイル索引 + 埋め込み）、IDE のフルコンテキストを補完。
  • ドキュメント分析 - レポート、調査、会議文字起こしへの質問。

共通パターン：コーパスが大きい、更新が頻繁、出典が必要 - チャットにファイルを一度上げるより RAG が向きます。

RAG vs ファインチューニング vs 長コンテキスト

手法 向く場面 限界
RAG 最新ドキュメント、透明な出典、再学習なし更新 検索品質に依存
ファインチューニング 文体、形式、ドメイン用語、安定知識 データ変更時の更新コスト
長コンテキスト 1セッションで文書やコードベース全体 コスト、レイテンシ、「lost in the middle」

これらは排他的ではありません。2026年の典型：コーパス検索は RAG + 少数の完全ファイルは長コンテキスト + 軽い FT または system prompt でトーン統一。

限界とよくある問題

RAG は知識へのアクセスを解決しますが、次は解決しません：

  • 事実の正確性の保証（モデルがコンテキストを無視する可能性）
  • 複雑な多段階アクション（tools / MCP が必要）
  • インデックスの自動更新（ドキュメント変更時の ETL）

典型的な失敗：

  • Chunking が不適切 - 表が半分に切れる、見出しのない数式。
  • K が不適切 - chunk 不足 → 事実漏れ；過多 → プロンプトがノイズだらけ。
  • 古いインデックス - ドキュメント更新後、embedding 未再計算。
  • ハイブリッド検索未設定 - 純粋な意味検索が SKU、ID、日付を外す；ハイブリッド（BM25 + ベクトル）が有効。

本番では retrieval ヒット率の監視、chunk サイズの A/B、人間フィードバック、「信頼度低ければ答えない」ガードレールを追加。

RAG システムの改善

  1. メタデータ - 部門タグ、日付、版；vector search 前のフィルタ。
  2. ハイブリッド検索 - キーワード（BM25）+ 意味；技術ドキュメント向け。
  3. Reranker - 初回 Top-20 の後 cross-encoder で最終 Top-5。
  4. クエリ変換 - 言い換え、マルチクエリ、HyDE（仮想ドキュメント）。
  5. Graph RAG - フラット chunk の上に関連エンティティ（人、プロジェクト、依存）。
  6. 評価 - 質問と正解のデータセット；faithfulness、context recall（RAGAS、DeepEval）。

まずは単純な pipeline（chunk → embed → Top-5 → GPT）で baseline を測り、メトリクスが上がる部分だけ複雑化を足す。

RAG とエージェントエコシステム

RAG は MCP や tool calling と組み合わされることが多いです。RAG がドキュメントから知識を取り、tools がアクション（チケット作成、残高照会）を実行。Cursor の意味索引 @Codebase はプロジェクトファイルに対する RAG の一種；エンタープライズでは Confluence、Slack、CRM に同じパターンを拡張します。

層 役割
RAG 「ドキュメントに何と書いてあるか」
MCP / tools 「システムの今の状態は？ 実行せよ」
LLM 回答の統合とステップ計画

まとめ

RAG は再学習なしで LLM を自社データに接続する標準手法です。ドキュメントを索引し、質問ごとに関連断片を取り出し、モデルがそれに grounded した回答を返します。Chroma + OpenAI の試作から、ハイブリッド検索・reranking・品質監視付きクラスタまでスケールします。

最初のプロジェクトでは、1つのコーパス（例：50ページの FAQ）を選び、chunking と Top-K を調整し、正しい段落がコンテキストに入るか測ってください - それが成功の最大の予測因子です。

よくある質問

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

ファインチューニングはサンプルでモデル重みを変えます - 文体、形式、安定パターン向け。RAGは重みに触れず、リクエストごとに索引から最新断片を引きます。毎週変わるドキュメントは再学習より RAG（再索引）の方が更新しやすい。手順を「暗記」させたいなら FT、鮮度と出典が重要なら RAG。

100万トークンコンテキストがあれば RAG は不要？

長コンテキスト（Claude、Gemini、GPT-5.6 の 1M+ トークン）は1セッションに大量テキストを載せられますが、巨大コーパスの RAG 代替にはなりません。100 GB の PDF はプロンプトに入らず、コストとレイテンシは線形に増えます。RAG は関連部分を選びます；長コンテキストは retrieval 後の少数の完全ファイルや IDE のリポジトリコード向け。実務では両方を併用します。

RAG 用のベクトルDBはどれを選ぶ？

規模とインフラ次第。pgvector - 既存 PostgreSQL、数百万ベクトルまで。Qdrant、Weaviate、Milvus - 成長期の self-hosted / managed。Pinecone - クラスタ運用なしの managed。Chroma - 試作の迅速開始。重要なのは embedding 品質、chunking、監視；多くの本番系は Chroma から pgvector や Qdrant に移行し、アプリロジックはそのままです。

RAG が誤回答を返すのはなぜ？

主因：(1) retrieval ミス - 正しい chunk が Top-K 外；(2) コンテキスト無視 で「記憶」から補完；(3) 古い索引；(4) 矛盾する chunk。ハイブリッド・reranker、厳格プロンプト（「コンテキストに無ければ知らないと言う」）、出典引用、eval セットで改善。

ローカルモデルで RAG は組める？

はい。 埋め込み（bge-m3、nomic-embed）と LLM（Ollama の Llama、Qwen、Mistral）はオフライン可；vector store もローカルに。制約は限られたハードでの品質；GPU/RAM に合わせてモデルサイズを選ぶ。機密データ（医療、金融、公共）ではローカル RAG が一般的 - ドキュメントは境界外に出ず、パイプライン構成はクラウドと同じです。

お問い合わせ