RAG（Retrieval-Augmented Generation／検索拡張生成）は、LLMが持たない社内文書・最新情報を、検索で取り込んでから回答する構成です。本記事はハルシネーションの心理ではなく、システムのパイプライン——何を検索し、どう生成に渡すか——に焦点を当てます。試験では「正確性を100%保証する」といった言い過ぎが×になりやすい点も押さえます。
試験で問われる見方
G検定・生成AIパスポートとも、RAGは「外部情報を検索し、生成の入力に加える」という定義が骨格です。一方で「RAGがあれば検証不要」「誤情報が検索にあっても必ず正答」は×です。
RAGとは
RAGは、ユーザーの質問に対してまず関連文書を検索（Retrieval）し、得られた抜粋をプロンプトに含めたうえでLLMが回答を生成（Generation）するパターンです。モデル単体の学習データだけに頼らず、根拠のある参照を足すのが目的です。
社内FAQ、マニュアル、議事録、製品仕様など、閉じたナレッジをチャットで引けるようにする用途でよく採用されます。生成AIの業務活用では、いま最も一般的なアーキテクチャのひとつです。
処理の流れ（4ステップ）
実装の細部は製品によりますが、概念として次の流れを覚えると試験・設計の両方に使えます。
- 1. インデックス化（事前準備）
- 2. 検索（Retrieval）
-
3. 拡張（Augment）
検索結果をプロンプトに挿入。「以下の資料に基づいて答えよ」など指示とセット。
-
4. 生成（Generation）
LLMが参照文脈を踏まえて回答。出典表示を付ける製品もある。
検索が外れる（関係ない段落を拾う）と、ハルシネーションに似た誤回答が起きます。チャンク設計と検索精度が品質の鍵です。チャンク・RAG・ベクトルDBの定義すり替えに注意（HQ-0370、HQ-0371）。
導入が向く場面
| シーン | RAGが効きやすい理由 |
|---|---|
| 社内規程・手順の質問応答 | 根拠文書を明示しやすい |
| 学習データ以降の情報 | モデル再学習なしで資料を更新できる |
| 顧客サポートのナレッジ検索 | FAQ・チケット履歴を検索対象にできる |
| 開発者向けドキュメントQA | API仕様など長文をチャンク検索 |
ファインチューニングとの違い
| 比較 | RAG | ファインチューニング |
|---|---|---|
| 知識の更新 | インデックスの差し替えで比較的容易 | 再学習が必要になりがち |
| 根拠の提示 | 参照文書を示しやすい | モデル内部に埋もれやすい |
| コスト・難易度 | 検索基盤の構築が中心 | 学習データ整備・GPUコスト |
| 試験の注意 | 「検索＋生成」の説明 | 「重みの追加学習」と混同しない |
限界と運用上の注意
- 検索ミス — 関係ない段落を拾うと誤回答の元になる
- 資料の誤り — インデックスが誤情報なら出力も誤る（TF-175）
- プロンプトインジェクション — 取り込んだPDFに悪意ある指示が含まれるリスク（TF-204）
- 人の確認は依然必要 — 100%正確の保証はない（TF-0171）
AIエージェントと組み合わせると、検索・API呼び出しを自律的に繰り返す構成にも発展します。設計が複雑になるほど、ログと権限管理が重要になります。