Rufat Nuriyev 更新

RAG とは

ナレッジベースとAIチャットを備えたノートパソコン

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

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. データ準備（オフライン）

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

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 が向かないケース

RAG は技術的な複雑さと運用負荷を伴うため、常に導入すべきとは限りません。

  • ナレッジベースが小さくほとんど変わらない - system prompt に一度貼り付けるだけで済み、検索やベクトルDBは不要。
  • パイプラインを維持するリソースがない - ドキュメント変更のたびにインデックスを更新し、検索品質を監視する必要がある。専任チームや委託先がなければ、システムはすぐ陳腐化し誤答が増える。
  • 精度の保証が必要 - 計算や法的な文言など誤りが許されないタスクには、決定的なシステムと人によるレビューの方がモデル生成より信頼できる。
  • ドキュメント検索ではなくアクションが目的 - チケット作成やレコード更新など、RAG単体では対応できず tools/MCP が必要（詳細は下記）。

導入前に、ドキュメント量・更新頻度・インデックスの管理担当を見積もっておくと、RAG が見合うか、もっと簡単な方法で十分かが判断できます。

まとめ

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

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

開発、AI導入、サイト保守など、ご案件に合わせたサポートが必要な場合 - お問い合わせください。

よくある質問

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 が一般的 - ドキュメントは境界外に出ず、パイプライン構成はクラウドと同じです。

この記事の用語

RAG — Retrieval-Augmented Generation — 検索拡張生成

retrieval — finding relevant context before generation — 生成前に関連文脈を取り出すこと

LLM — Large Language Model — 大規模言語モデル

Confluence — Atlassian wiki for team documentation — チーム文書向けAtlassian Wiki

chunking — splitting documents into retrieval-friendly pieces — 検索しやすい単位への文書分割

embedding — numeric vector that captures text meaning — 文の意味を数値化したベクトル

vector store — database optimized for similarity search over embeddings — 埋め込みの類似検索向けデータベース

Pinecone — managed vector database for similarity search — 類似検索向けマネージドベクトルDB

pgvector — PostgreSQL extension for vector search — PostgreSQL向けベクトル検索拡張

vector db — database for similarity search over embeddings — 埋め込みの類似検索向けデータベース

reranking — reordering search results by relevance — 検索結果を関連度順に並べ替えること

Qdrant — vector database for similarity search — 類似検索向けベクトルデータベース

Chroma — open-source embedding database for RAG apps — RAG向けオープンソース埋め込みDB

LlamaIndex — framework for connecting LLMs to private data — LLMを社内データに接続するフレームワーク

top-k — keep only the k most likely next tokens when sampling — サンプリングで上位k個のトークンだけ残す方式

LangChain — framework for building LLM applications — LLMアプリ構築用フレームワーク

LangGraph — framework for stateful AI agent workflows — 状態を持つAIエージェント工作流のフレームワーク

system prompt — hidden instructions that steer the model for a task — モデルの振る舞いを決める非表示の指示

ANN — Approximate Nearest Neighbor — ベクトル空間での近似最近傍探索

runbook — step-by-step playbook for incidents and operations — 障害対応・運用の手順書

vector search — finding nearest neighbors in embedding space — 埋め込み空間で近傍を探す検索

cross-encoder — rerank model that scores query and document together — クエリと文書をまとめて採点する再順位付けモデル

faithfulness — how well an answer sticks to the retrieved sources — 回答が取得ソースにどれだけ忠実か

tool calling — model invoking external tools or APIs — モデルが外部ツールやAPIを呼び出すこと

reranker — model that reorders search hits by relevance — 関連度で検索結果を並べ替えるモデル

MCP — Model Context Protocol — モデルコンテキストプロトコル

ETL — Extract, Transform, Load — 抽出・変換・ロード

SKU — Stock Keeping Unit — 在庫管理単位

pipeline — sequence of processing stages

baseline — reference measurement before changes

self-hosted — software you run on your own servers — 自前サーバーで運用するソフトウェア

GPT — Generative Pre-trained Transformer — 生成系言語モデルの系列

CRM — Customer Relationship Management — 顧客関係管理

Ollama — tool to run local open-weight LLMs on your machine — 手元でオープンウェイトLLMを動かすツール

GPU — Graphics Processing Unit — グラフィックス処理装置

お問い合わせ