RAGは『LLMに自前データを参照させる』仕組み
RAG（Retrieval-Augmented Generation）は、LLMが回答する前に関連文書を検索して文脈に加えることで、社内情報・最新情報・専門知識を踏まえた回答を可能にする技術です。社内文書AI・サポートBot・専門領域QA等で広く採用されています。本記事では、RAGの基本構成、ベクター検索の選び方、評価、運用の注意点を編集部の視点で整理します。ツールの仕様は変化するため、最新は公式情報をご確認ください。
RAGの基本構成
(1) ドキュメント取り込み（インジェスト）：PDF・Markdown・HTMLからテキストを抽出。(2) チャンク分割：適切な長さに分割（500〜1000トークン目安）。(3) ベクトル化（埋め込み）：Embeddingモデルで意味ベクトルに変換。(4) ベクター検索：質問と類似する文書を取得。(5) LLMで回答生成：検索結果を文脈に入れて回答。生成AIを活用した学習法 もご参考に。
ベクターDBの選び方
(1) マネージド型：Pinecone・Weaviate Cloud等。運用が楽。(2) セルフホスト：Qdrant・Weaviate・Milvus。自由度が高い。(3) 既存DB拡張：PostgreSQL（pgvector）・OpenSearch。導入が楽。(4) 規模感：数千文書ならpgvector、数十万以上なら専用DB。(5) 機能：フィルタ検索・メタデータ管理の必要性で選ぶ。SaaS MVPの作り方 もご参考に。
段階的な立ち上げの手順
(1) 第1段階：プロトタイプ：10〜100文書・pgvector・GPT/Claude APIで動かす。(2) 第2段階：精度検証：想定質問を50〜100個用意し、回答品質を評価。(3) 第3段階：チャンク・検索の調整：チャンクサイズ・k値・ハイブリッド検索の導入。(4) 第4段階：本番投入：監視・ログ・フィードバック収集を組み込む。(5) 第5段階：改善ループ：ユーザーフィードバックで継続的に磨く。「いきなり完璧」は不要。動くものを早く作り改善が王道です。エージェント型コーディングツール も実装加速に活用できます。
精度を上げる工夫
(1) ハイブリッド検索：ベクター検索＋キーワード検索（BM25等）を併用。(2) リランカー：検索結果を再順位付けして精度向上。(3) クエリ書き換え：質問を検索に適した形に変換。(4) マルチクエリ：1質問から複数クエリを生成して網羅。(5) メタデータフィルタ：部署・日付等で対象を絞る。「単純なベクター検索だけ」では精度が頭打ちになることが多く、組み合わせが効きます。
評価方法
(1) 想定質問セットを作る：実利用想定の質問50〜200個。(2) 正解と評価軸を明示：「正確性」「網羅性」「根拠提示」等。(3) LLMによる自動評価：RAGの定番。専門家評価との一致度も確認。(4) 人手評価の併用：最後は人の目で確認。(5) 継続的なモニタリング：実運用での品質を計測。DS/MLE/DAの違い もご参考に。
運用上の注意点
(1) 機密情報の扱い：アクセス制御・暗号化を組み込む。(2) ハルシネーション対策：根拠提示・「分からない」と言える設計。(3) コスト管理：Embedding・LLM API呼び出しの予算管理。(4) 更新頻度：新文書の取り込み・古い文書の削除。(5) ユーザー体験：返答時間・ストリーミング・引用表示。セキュリティエンジニアへの転身ガイド、SREへの転身ガイド もご参考に。
失敗しがちなパターン
(1) 評価せずに本番投入：「動いた」と「使える」は別。(2) チャンク設計が雑：意味の単位を無視すると検索精度が下がる。(3) 1質問1回答を想定しすぎ：対話・追加質問への設計を入れる。(4) ベクター検索だけに頼る：キーワードでしか引けない質問もある。(5) コスト超過：監視せずに気付くと大幅赤字に。対策は、(1)評価セット必須、(2)チャンク設計の見直し、(3)ハイブリッド検索、(4)コスト監視、です。IT・Web業界の職種完全マップ も合わせてご活用ください。