「社内ドキュメントを検索して答えてくれるAIが欲しい」——この相談が、いま最も増えています。汎用のチャットAIは一般知識には強い一方、自社の規程やマニュアルには答えられず、出典も示せません。これを解決するのが RAG（Retrieval-Augmented Generation／検索拡張生成）です。
RAGの基本：検索してから答える
RAGは、その名のとおり「検索（Retrieval）」と「生成（Generation）」を組み合わせた仕組みです。質問が来たら、まず社内ドキュメントの中から関連する箇所を検索し、その内容を根拠としてLLMに渡し、回答を作らせます。
ポイントは、LLM自身に知識を覚え込ませる（ファインチューニング）のではなく、**回答のたびに必要な情報を“外から渡す”**という発想です。これにより、ドキュメントを更新すれば回答も最新になります。
仕組みは大きく4ステップ
- 取り込み（Ingestion）：ドキュメントを意味のまとまりで分割（チャンク化）する
- ベクトル化（Embedding）：各チャンクを意味を表すベクトルに変換し、ベクトルDBに格納する
- 検索（Retrieval）：質問もベクトル化し、近い意味のチャンクを取り出す
- 生成（Generation）：取り出したチャンクを根拠としてLLMに渡し、出典付きで回答する
質問 → ベクトル化 → ベクトルDBを検索 → 関連チャンク取得
→ LLMへ「この資料を根拠に答えて」と渡す → 出典付き回答
精度を決めるのは「検索」
RAGで最初に作り込むべきは、実はLLMではなく検索の品質です。関係のないチャンクばかり拾えば、いくら賢いLLMでも正しく答えられません。逆に、的確なチャンクを渡せれば、回答の質は一気に上がります。
そのため実装では「チャンクの分割方法」「埋め込みモデルの選定」「検索件数の調整」に最も時間をかけます。ここが RAG の腕の見せどころです。
ハルシネーションへの備え
業務でAIを使う最大の不安は「それらしい嘘」を返すことです。RAGでは、回答に出典（どのドキュメントの何ページか）を添える設計にすることで、利用者が根拠を確認できます。「答え＋根拠」をセットで返すことが、本番投入の前提になります。
まとめ
- RAGは「検索してから答える」仕組みで、ドキュメント更新に追従できる
- 精度を左右するのはLLMより検索の品質
- 出典提示でハルシネーションに備えると、業務で使える
「自社のドキュメントで試したい」という段階から、設計・実装まで伴走できます。