Chapter 11

第11章: 外の知識を呼んでくる — RAG

ChatGPT に聞く。

「今日の東京の天気は？」

返ってくる答え：

「私はリアルタイムの情報にアクセスできないため、現在の天気をお答えできません。天気予報サイトをご確認ください。」

別の質問：

「私の会社の有給休暇申請のルールは？」

返ってくる答え：

「申し訳ありません、あなたの会社の社内規程は把握していません。総務部にお問い合わせください。」

これらは LLM の 本質的な弱点 だ。 LLM は学習時点のデータで凍結されているし、社内文書のような 非公開情報 は最初から知らない。

ところが現代の AI システム ── Perplexity、ChatGPT のブラウジング、社内チャットボット ── は、これらを しれっと答える。 裏側で何が起きているか？ それが本章のテーマ ── RAG (Retrieval-Augmented Generation) だ。

11.1 LLM の根本的な弱点

第9〜10章で、LLM がいかに強力かを見てきた。 だが、その内部構造を思い出すと、明らかに 苦手なこと がある：

LLM の苦手なこと

  1. 学習時点より新しい情報を知らない
    GPT-4 が 2023 年のデータで学習されたなら、2024 年の出来事はそのままでは知らない
  2. 学習データに含まれていない情報を知らない
    特定の企業の社内文書、特定のユーザーの個人ファイル、極めてニッチな専門知識など
  3. 「うろ覚え」になりやすい
    学んだ知識を パラメータの中 に圧縮しているので、細かい数字や固有名詞を誤って覚える

LLM の知識は、学習時にパラメータに焼き付けた「内蔵知識」しかない。 ニュースや社内情報は、後から焼き付け直さない限り、絶対に取り込まれない。 そして焼き付け直し（再学習）は 数百万〜億単位 の計算コストがかかるので、毎日できない。

これを 別の手段 で補う必要がある。 そこで生まれたのが、検索と生成を組み合わせる発想だ。

11.2 「外から取ってくる」という発想

人間のアナロジーで考えると分かりやすい。

物知りな弁護士でも、すべての判例を頭に入れているわけではない。 新しい案件が来たら、まず 法律データベースで関連判例を検索 し、その内容を踏まえて答える。 頭の知識 + 必要に応じた検索 で、最新かつ詳細な答えを返している。

LLM にも同じことをさせよう ── これが RAG の発想だ。

RAG (Retrieval-Augmented Generation) の発想

質問が来たら、まず 関連する情報を外部データベースから検索 し、 検索結果を LLM のプロンプトに 追加情報として渡して、それを踏まえて回答させる。

「検索（Retrieval）で補強された（Augmented）生成（Generation）」── 名前そのままだ。 LLM 自身の内蔵知識だけでは答えられない情報を、検索で外から呼んできて使う。

11.3 RAG の動作 ── 4 ステップで眺める

具体的に、RAG はどう動くか。 ユーザーが「今日の東京の天気は？」と聞いた場面で見てみる。

① ユーザー質問「今日の東京の天気は？」② 検索関連情報を取ってくる③ プロンプト合成質問 + 検索結果④ LLM回答生成検索対象ウェブ / 社内文書/ ナレッジベース/ ファイル群「検索」が裏で走り、LLM は質問だけでなく検索結果も受け取って回答する
図 11.1 — RAG の動作。質問 → 検索 → プロンプト合成 → LLM 生成、の 4 ステップ。

ステップ ①: 質問が来る

ユーザーから「今日の東京の天気は？」が来る。

ステップ ②: 検索

天気予報 API や、信頼できる気象情報サイトを検索し、関連情報の塊 を取ってくる：

[検索結果]
2026 年 5 月 17 日 東京の天気: 晴れ。最高気温 26 度、最低気温 18 度。
午後から薄曇り。湿度 60%。

ステップ ③: プロンプト合成

検索結果をユーザーの質問と組み合わせて、LLM に渡すプロンプトを作る：

以下は検索結果です：
[2026 年 5 月 17 日 東京の天気: 晴れ。最高気温 26 度...]

ユーザーの質問：今日の東京の天気は？

検索結果を踏まえて、ユーザーに分かりやすく答えてください。

ステップ ④: LLM が回答

LLM はプロンプトに含まれた検索結果を読んで、ユーザーに答える：

「今日の東京は晴れの予報です。最高気温は 26 度、最低気温は 18 度。午後から薄曇りになる見込みで、湿度は 60% です。」

LLM 自体は「今日の天気」を覚えていないが、プロンプトに含まれた情報を読んで答えている。 事前学習時に焼き付けた知識を更新する必要は、ない。

11.4 「ベクトル検索」が RAG の中核

「検索」と一言で言ったが、RAG が広く使われるようになった最大の理由は、ベクトル検索（vector search / semantic search） という新しい検索手法が成熟したことだ。

従来の検索：キーワード一致

Google 検索の初期や、社内文書検索の多くは、キーワードの一致 に基づいていた：

ベクトル検索：意味の近さで探す

第2〜3章で見た 埋め込みベクトル の発想を、文や文書レベルに拡張する：

ベクトル検索の仕掛け

  1. 文書側: 社内の全文書を、それぞれベクトル（数千次元の点）に変換しておく
  2. 質問側: ユーザー質問が来たら、同じやり方でベクトルに変換
  3. 検索: 質問ベクトルに 近い文書ベクトル を探す

「近い」= 意味的に関連が深い、と解釈できる。 キーワードが一致しなくても、意味が似ていれば ヒットする。

これにより、たとえば社内文書検索で：

キーワード一致だと「有休」「申請」が一部しか合わないので難しいが、意味的には完全に同じ話。 ベクトル検索なら、両者は近い領域に置かれているので、ちゃんとヒットする。

この 「意味の近さで探す」 という能力が、RAG を実用レベルに押し上げた。

11.5 RAG が活躍する場面

RAG は、LLM の弱点を補う様々な場面 で広く使われている：

用途RAG の使い方
Perplexity / Bing Chat / Google AI Overviewウェブ検索結果を取ってきて、LLM が要約・回答
社内チャットボット社内文書を検索し、LLM が社員の質問に答える
カスタマーサポート Bot製品マニュアル・FAQ を検索し、顧客の質問に答える
コードベース Q&Aリポジトリ内のコードを検索し、開発者の質問に答える
医療・法律の意思決定支援信頼できる文献を検索し、専門家の判断を補助

RAG が広まった理由は、コスト面でも明確だ：

このコスト感が、企業の AI 導入を一気に現実的にした。

11.6 RAG の課題

RAG は強力だが、簡単に作って簡単に動くわけでもない。 実装してみると、いくつかの典型的な落とし穴がある。

課題①: 検索の質が出力の質を決める

RAG では、検索結果が間違っていれば、LLM の出力も間違える。 ベクトル検索は「意味の近さ」を見るが、近いだけで 回答に直接関係ない文書 も拾ってきてしまうことがある。

例：「有給休暇の申請期限」を聞いたのに、検索が「年末年始の休暇カレンダー」を返してきたら、LLM は混乱した答えを返す。

検索結果のキュレーション（reranker などの仕組みで、検索結果を再ランクし直す）が、近年の RAG 実装の重要トピックになっている。

課題②: 検索範囲とプロンプト長の制約

LLM のコンテキスト長には限界がある（第1章参照）。 社内文書が 100 万件あるとき、ベクトル検索で 上位 5〜10 件 を抜き出してプロンプトに含めるが、本当に答えに必要な情報が上位に来るとは限らない。

長文 LLM（Claude Opus の 100 万トークン、Gemini の 200 万トークンなど）の登場は、この問題を緩和しつつある。

課題③: 「検索しても見つからない」の判定

「答えに関連する情報が、そもそも社内文書に存在しない」という場面も多い。 こうした場合、LLM が 「データベースに該当情報がありません」と素直に答える ように、プロンプトで仕込まなければならない。 これを怠ると、LLM は 次章で扱うハルシネーション を起こす。

「RAG を作るのは簡単、でも実用レベルに磨くのは難しい」──
これが本書執筆現在の実務側の合言葉だ。
検索、プロンプト合成、再ランキング、ハルシネーション対策 ── すべてを地道に詰めることで、ようやく信頼できる RAG システムが完成する。

11.7 RAG の発展形

RAG は静的な検索だけにとどまらない。近年は様々な発展形が出ている：

発展形概要
Multi-hop RAG質問に答えるのに複数回検索が必要なケース。1 回目の検索結果を見て、2 回目以降の検索を組み立てる
Hybrid Searchキーワード検索とベクトル検索を組み合わせる。両者の良いとこ取り
GraphRAG文書間の関係をグラフ構造で持ち、構造を辿って関連情報を取る
Long-context LLM のみ「検索せず、全部 LLM に投げる」── 100 万トークン LLM の登場で、これが現実的になりつつある

特に最後の 「Long-context LLM だけで十分なのでは？」 という議論は、本書執筆現在も活発だ。 RAG vs Long-context は、しばらく両方が共存しながら使い分けられる構図になりそうだ。

11.8 この章の振り返り

次章では、もう 1 つの大きな広がり ── 画像・音声・動画も同じ枠で扱う マルチモーダル LLM の話に進む。