RAG

概要

RAG（Retrieval-Augmented Generation）は、生成AIが回答を作る前に外部の情報源（社内ドキュメント、FAQ、DB、Web記事など）を検索して「根拠」を集め、その根拠を参照しながら文章を生成する方式です。 LLM（エルエルエム：大規模言語モデル）の弱点である「学習後の新情報に弱い」「根拠が曖昧になりがち」を補う目的で使われます。

仕組み

1) 事前準備（インデックス作成）

• 文書を取り込み、チャンク（チャンク：文書を小さく分割した断片）に分割
• 各チャンクを埋め込み（エンベディング：文章を数値ベクトルに変換する表現）に変換
• ベクトルデータベース（ベクトルデータベース：ベクトル検索に最適化したDB）へ保存

2) 問い合わせ時（検索→生成）

• ユーザーの質問を埋め込みに変換
• 近いベクトルを検索して関連チャンクを取得（Top-kなど）
• 必要ならリランキング（リランキング：候補の再順位付け）で精度を上げる
• 取得した根拠をプロンプトに入れ、根拠に沿って回答を生成（引用・出典表示も可）

使いどころ

• 社内ナレッジ検索（規程、手順書、設計書、議事録）
• カスタマーサポートの回答支援（FAQ、マニュアル）
• 仕様・法務・コンプラの参照が必要な回答（根拠提示が重要）
• 最新情報の反映が必要な領域（リリース情報、運用手順の更新）

メリット

• 最新性：モデル再学習なしで、新しい文書を追加すれば反映できる
• 根拠性：回答に参照元を添えやすく、監査・レビューに強い
• コスト：頻繁なファインチューニングより運用しやすいことが多い
• 安全性：許可した情報源だけを参照させる設計ができる

注意点

• 検索が外れると回答も外れる（「生成」以前に「取得」がボトルネック）
• 文書の質がそのまま出力品質に影響（古い手順・誤情報の混入に注意）
• コンテキスト長の制約で、根拠を入れすぎると逆に精度が落ちることがある
• プロンプトインジェクション対策が必要（文書内の「指示文」に従わない設計）
• 機密・個人情報の取り扱い（アクセス制御、マスキング、ログ管理）

設計のコツ（実務で効くポイント）

• チャンク設計：長すぎない／短すぎない、適度なオーバーラップ、見出し単位を意識
• メタデータ活用：部署、版数、日付、製品名などでフィルタして検索ノイズを減らす
• Top-kと閾値：取り過ぎはノイズ、少なすぎは根拠不足。A/Bで調整
• リランキング：ベクトル検索の上に再順位付けを入れると「それっぽいが違う」を減らせる
• 出典提示：引用範囲・文書名・リンク・版数など、運用で使える形に整える
• キャッシュ：同じ質問・同じ検索結果を再利用してコストと遅延を削減

評価（何を測るか）

• 検索品質：Recall@k（必要根拠がk件内に入るか）、MRR（正解が上位に来るか）
• 生成品質：根拠整合性（根拠に反しないか）、出典の正確さ、回答の網羅性
• 運用品質：更新反映の速さ、誤回答の再発率、ユーザー満足度（CSAT等）

関連用語・よくある誤解

• ファインチューニングとの違い：RAGは「重み」を変えず、外部情報を参照して答える。学習で知識を埋め込むのではなく、必要なときに取りに行く発想。
• 「RAG＝検索」ではない：検索（Retrieval）と、それを使った生成（Generation）を一体で設計するのがRAG。