RAG構成完全解説

RAGの射程と、微調整では届かない領域

RAG（Retrieval Augmented Generation）は、LLMが学習していない社内知や最新情報を検索で注入し、根拠付きで答えるための設計です。ChatGPTやClaude、Geminiのような汎用LLMは強力ですが、社内規程や最新商品仕様は「知らない」ままです。モデル微調整でも更新追従や権限制御は苦手で、以下の条件ならRAGを主軸に据える判断が堅実です。

• 更新頻度が高い（週次以上）かつ改訂履歴を残したい
• 部門・顧客ごとのアクセス制御が必要
• 回答に根拠URLや原文スニペットを必ず付けたい
• ドメインが広く、微調整データの継続準備が難しい

一方、フォーマットが固定で評価軸が明快（請求書読み取り、特定テンプレ生成など）は微調整/ツール利用が有利です。現実はハイブリッドで、RAGをベースに一部スキルを関数/ツールやCopilot的補助と組み合わせる構成が落とし所になります。

設計の要点：取り込み→索引→検索/再ランク→生成

取り込みと前処理（Ingest）

ソースはDrive/Box、Wiki、PDF、チケット、DB。改訂検知はWebhookか差分ジョブで実装し、ドキュメントIDとバージョンを付与します。テキスト化はOCR/レイアウト保持を選び、数式や表は「テキスト化の劣化」を許容するか画像スニペット添付で補います。

• チャンク設計：200〜500トークン、10〜20％オーバーラップが出発点
• メタデータ：部門、機密区分、更新日、ソースURL、言語
• 正規化：見出しを保持、箇条書きはプレーン化しすぎない

索引と埋め込み

埋め込みは多言語対応とコストのバランスを見ます。768次元クラスは安価で十分なことが多いです。索引は以下の使い分けが現実的です。

• 〜10万チャンク：単一ベクタ索引（FAISSなど）で十分
• 100万チャンク超：シャーディング＋メタデータフィルタ、更新はバッチ投入
• 法務/監査要件が厳しい：PIIマスキングやフィールド別暗号化を ingest 時に適用

検索と再ランキング

まずはハイブリッド検索が定石です。キーワード（BM25）で固有名詞に強く、ベクタでパラフレーズに強い。両者をスコア正規化して合算、上位30〜100件を抽出し、再ランカーでTop-k（5〜10件）に絞ります。再ランカーはクロスエンコーダ型（bge-reranker等）が効果的で、平均的にF1が+5〜15pt伸びます。遅延は+150〜300ms程度を見込み、対話全体で2.5秒以内を目安にします。

プロンプトと生成

プロンプトは「根拠外の創作を禁止」「引用は段落単位」「日本語で要約、数値は改変しない」などの規律を明示。抜粋の前後文脈を含めると幻覚が減ります。Top-k=8で長すぎる場合は、事前要約（passage-level）を挟むとトークン節約と品質を両立できます。モデルは用途で使い分けます。和文長文要約や丁寧な口調はClaudeが安定、ファクト重視の短文抽出はGeminiも良く、社内PoCはChatGPTで迅速に試すなど、複数モデル同居が実運用向きです。

品質・コスト・安全性の運用術

評価指標とガードレール

• Retrieval Hit率：正解文書がTop-20に含まれる割合（80％↑を目標）
• MRR/Recall@k：オフラインでクエリセットを定期評価
• Groundedness/引用一致率：回答文と引用の整合（人手サンプルで監査）
• 拒否適性：未検出時に「分かりません」と返せる率

プロンプト側では「引用が0件なら回答しない」「信頼度スコアが閾値未満ならサマリではなく原文提示」をルール化。回答キャッシュは「正規化クエリ＋採用チャンクID」のキーで保存し、根拠のバージョンが変わったら自動無効化します。

レイテンシとコスト配分

• 予算の目安：トークン費60％、検索/再ランク25％、埋め込み/索引維持15％
• 段階検索：軽量ベクタ→必要時のみ再ランカー→長文生成の順でコスト節約
• 事前埋め込み：夜間バッチ＋イベントドリブンの併用でスパイクを回避

権限・監査・テナント分離

各チャンクにACLを持たせ、検索時点でフィルタするのが基本です。生成後にマスクする後処理だけでは漏洩リスクがあります。監査ログは「ユーザID、クエリ、採用チャンクIDとバージョン、モデル、プロンプト、出力ハッシュ」を保存。テナントは索引を物理分離するか、最小でも暗号鍵を分けます。

身近な企業活用例：失敗から立て直したRAG

目的はヘルプセンターと過去チケットからの自動回答。最初はFAQ全文をプロンプトに貼り付け、ChatGPTで応答させましたが、トークン超過と幻覚が多発。平均応答4.8秒、一次解決率は58％で伸び悩みました。

改善ではRAGを導入。PDFとチケットを300トークンでチャンク化、部門とプラン別のメタデータを付与。ハイブリッド検索＋再ランクでTop-6を抽出し、引用必須プロンプトに変更。更新はWebhookで差分取り込み、Copilot風のエージェントUIに「根拠リンク」を常表示しました。さらにエスカレーション条件を「引用0件」「類似度中央値0.2未満」に明示。

結果、平均応答2.1秒、一次解決率は76％へ。誤回答は「旧バージョン参照」由来だったため、チャンクにバージョンと有効期限を付与し、期限切れは検索対象外に。最後にGeminiで短い要約を書かせ、Claudeで礼儀正しい最終文面に整える二段生成でCS満足度を底上げしました。

運用の肝はダッシュボード化でした。Hit率、引用一致率、拒否適性を週次で可視化し、閾値割れは即座にクエリテンプレ修正か再ランカー更新へ。属人化を避け、手順書と評価データをリポジトリ管理したことで改善が継続しました。

まとめ：RAGは「情報と運用」の設計問題

RAGはモデル選びだけでなく、取り込み、索引、検索、再ランク、プロンプト、評価、権限、監査の総合設計です。意思決定の勘所は「どの指標を、どの遅延/コストで満たすか」。ハイブリッド検索＋再ランクを基線に、Top-kやチャンク設計、拒否戦略、キャッシュを数値で詰めると再現よく伸びます。複数モデル（ChatGPT/Claude/Gemini）の併用とテナント分離を前提に、監査可能なパイプラインを持つと、生成AIプラットフォーム事業としての拡張性と安全性が両立します。