RAG（Retrieval-Augmented Generation / 検索拡張生成） は、LLM に回答させる前に 外部の知識ベースから関連文書を引いてきて、プロンプトに添える 手法。モデルを再学習（ファインチューニング）せずに、社内データや最新情報を回答へ反映できる。
概要
LLM は学習時点の知識しか持たず、社内固有の情報も知らない。RAG はこの限界を「外付けの知識」で補う。
- 検索（Retrieval）：ユーザーの質問を embedding にし、知識ベースから ベクター検索 で関連文書を引く
- 拡張（Augmented）：引いた文書を「根拠（コンテキスト）」としてプロンプトに添える
- 生成（Generation）：LLM がその根拠に基づいて回答する
回答が外部文書に「接地」するため、ハルシネーション（もっともらしい嘘）を抑え、出典を示せる。ファインチューニングと違い、知識ベースを更新するだけで回答も最新化できるのが利点。
なぜ検索精度が回答品質を決めるのか
RAG の品質は 「正しい根拠を引けているか」 にほぼ依存する。検索（Retrieval）が的外れな文書を拾えば、LLM はその誤った根拠に基づいて自信たっぷりに間違える（“garbage in, garbage out”）。
したがって RAG の精度改善は、生成モデルより 検索側の作り込み が要になる。
- どんなテキストを embedding にするか（チャンク分割の粒度）
- 保存側（document）と検索側（query）で task_type を正しく使い分けているか（非対称検索）
- 類似度の閾値・上位 N 件の絞り込み
⚠️ task_type を誤ると、エラーは出ないのに検索のヒット率だけが静かに落ち、RAG 全体の回答品質が下がる。詳細は ベクター検索の落とし穴 を参照。
RAG と context engineering
引いた文書をどうプロンプトへ配置し、限られたコンテキスト窓に何を残すかは context engineering の領域。RAG は「外部知識をコンテキストに注入する」具体的な一手段といえる。
関連記事・用語
- ベクター検索の落とし穴：保存（document）と検索（query）で task_type を分けないとヒット率が落ちる — RAG の検索精度を左右する落とし穴
- embedding — RAG の検索を支えるベクトル表現
- ベクター検索 / セマンティック検索 — RAG の Retrieval を担う検索方式
- task_type — 検索精度を左右する用途別最適化
- ハルシネーション — RAG が抑制する対象
- context engineering — 引いた根拠をコンテキストへ配置する設計