RAGとは何か｜仕組み・向き不向き・導入判断の考え方

「社内の規程やマニュアルをAIに読み込ませて、質問に答えられるようにしたい」。この要望に対する現在の代表的な答えがRAG(Retrieval-Augmented Generation、検索拡張生成)です。ただし、RAGは万能の魔法ではなく、得意な質問と苦手な質問がはっきり分かれる技術です。この記事では、仕組みをエンジニア以外にも分かる粒度で説明したうえで、向き不向きと導入判断の考え方を整理します。

RAGの仕組み：検索してから生成する#

LLM単体に「わが社の経費精算の上限は?」と聞いても、社内規程を知らないため答えられないか、もっともらしい誤答を返します。RAGはこの問題を、回答の直前に関連文書を検索して渡すことで解決します。

利用者の質問
  -> 1. 検索: 質問と関連が深い文書の断片を社内データから探す
  -> 2. 組み立て: 見つけた断片を質問と一緒にプロンプトへ挿入する
  -> 3. 生成: LLMが「渡された文書に基づいて」回答を作る
  -> 回答と根拠(どの文書を参照したか)を返す

モデル自体は何も覚えていません。試験会場に毎回カンニングペーパーを持ち込ませるようなもので、ペーパーに書いてあることしか正しく答えられない代わりに、文書を差し替えれば知識を即日更新できます。

検索部分が精度を決める#

RAGの回答品質は、LLMの賢さよりも「正しい文書の断片を検索で引き当てられるか」に大きく左右されます。検索には、キーワード一致に加えて、文章の意味の近さで探すベクトル検索(埋め込み検索)がよく使われます。文書を適切な長さに区切る(チャンク分割)、タイトルや部署名などのメタデータを付ける、キーワード検索と併用するといった地道な工夫が、精度改善の中心になります。

向いている用途・向かない用途#

苦手な質問に共通するのは「文書の一部ではなく全体を見る必要がある」ことです。検索は関連の強い断片を数件〜数十件返す仕組みなので、全件を対象にした集計や網羅列挙は原理的に不得意です。この種の要件には、データベースや全文処理など従来型の仕組みを組み合わせるほうが適しています。

導入判断のポイント#

RAGの実装方式(検索の種類・チャンク分割・再ランキングなど)は各社の開発者向けドキュメントで解説が公開されています。実装前にOpenAIやAnthropicなどの公式ドキュメントで現行の推奨構成を確認してください。

自前構築か、既製サービスか#

RAGは自前で組むこともできますが、近年は文書をアップロードするだけで検索と生成を面倒見てくれる既製機能・サービスも増えています。まず既製サービスで小さく検証し、検索精度のチューニングやアクセス権限の細かい制御が必要になった段階で自前構築を検討する、という順序が失敗しにくい進め方です。自前構築の場合も、埋め込みモデルやベクトルデータベースの選定は変わり得るため、コンポーネントを差し替えられる構成にしておくことをおすすめします。

よくある質問#

まとめ#

RAGは「AIに社内知識を答えさせる」ための現実的な出発点ですが、精度の大半は検索と文書整備という地味な部分で決まります。検索や生成を自律的に組み合わせて動くAIエージェントの考え方も、次の一歩としてあわせて押さえておくと設計の見通しが良くなります。