RAG（検索拡張生成）とは何か、いつ必要か
RAG は自社の文書を重みに焼き込まず、質問の時点でモデルに手渡す。パイプラインの仕組み、RAG の失敗のほとんどが «検索» の失敗である理由、そしてより単純な方法が勝つ場面。
ひとことで言うと
検索拡張生成（RAG）とは何か？
検索拡張生成とは、質問に関連する箇所を自社の文書から探し出し、それをモデルのプロンプトに入れて、その内容にもとづいて答えさせる方式である。モデルの重みは変わらない。知識はリクエスト時にコンテキストとして届く。
要点
- RAG は検索とプロンプティングの組み合わせだ。検索が誤った箇所を返せば、どんなモデルでも答えは救えない。
- ベクトル類似度だけでは固有名詞・コード・厳密な語句に弱い — キーワードとベクトルを併用するハイブリッドが実務の既定値。
- 即座に反映される。文書を直せば次の回答が変わる。ファインチューニングにはできない。
- 引用が肝心だ。根拠箇所にリンクする回答は監査できる。
言語モデルは学習データにあったものしか知らない。自社の契約条項も、前四半期の数字も、昨日提出された障害報告書も知らない。検索拡張生成は、何も再学習せずにその隙間を埋める標準的な方法である。
パイプラインの全体
RAG は二つの局面に分かれる。最初は事前に済ませておく。
索引づくり（オフライン）
- 文書を集める。
- 数百〜数千トークン程度の箇所に チャンキング する。
- 各チャンクの 埋め込み を計算する — 似た意味の文が近くに置かれる空間の座標ベクトルだ。
- ベクトル・原文・メタデータ（出典、節、日付、権限）を索引に保存する。
回答（リクエストごと）
- 利用者の質問を同じ方法で埋め込む。
- 最も近いチャンクを 検索 する — キーワード検索と併用することが多い。
- 必要なら小さいモデルで 再ランキング する。ベクトル距離より的確に関連度を点数化できる。
- プロンプトを組み立てる：指示、取得した箇所、質問。
- 各主張がどの箇所に由来するかを引用させて回答を生成する。
これで全部だ。巧みさは «生成» ではなく «検索» に入る。
RAG の失敗の大半は検索の失敗
RAG が誤答すると、反射的にモデルを疑いたくなる。ほとんど常に検索が原因だ。
他をいじる前にこの確認をしてほしい。失敗した質問について、実際に取得された箇所を取り出し、注意深い人間ならその箇所だけで正答できたか を問う。できないなら、モデルには最初から機会がなかった。
多い順におおよその原因は次のとおり。
- 語彙の不一致。 利用者は「解約」と尋ね、契約書には「解除」と書いてある。ベクトル検索はそれなりに扱え、純粋なキーワード検索は扱えない。
- 厳密な識別子。 利用者が
INV-2024-8871を尋ねる。ベクトル検索が 苦手 な領域だ — 識別子の埋め込みにはほとんど意味が乗らない。キーワード検索は即座に見つける。ハイブリッド検索 が要る最も強い理由である。 - チャンク境界の失敗。 定義が一方のチャンクに、例外が次のチャンクにあり、片方しか取得されなかった。
- メタデータフィルタの欠落。 利用者に閲覧権限のない文書や、失効した版から答えが出た。権限と有効期間のフィルタは類似度の «後» ではなく «前» に掛ける。
- 取得件数が少なすぎる。 3 件だけ取るのは効率的で脆い。20 件取り、再ランキングし、上位 5 件を残す。
RAG が誤った道具になる場合
RAG は無料ではない。維持すべき索引、監視すべき検索品質、全リクエストに乗る遅延が付いてくる。次の場合は飛ばしてよい。
- コーパスが小さい。 知識ベース全体が 20 ページなら、システムプロンプトに入れてキャッシュすればよい。
- 文書についての質問ではない。 「先月の遅延出荷は何件か」といった集計は SQL の仕事だ。ベクトル索引ではなくクエリツールを渡す。
- 事実ではなく文体の問題。 社内のトーンで書かせるのはプロンプティングかファインチューニングの領域である。
知っておく価値のある中間の道もある。エージェント的検索 — モデルに検索ツールを与え、自分でクエリを立て、結果を見て磨かせるやり方だ。リクエスト数は増えるが、一回の検索では取りこぼす多段の問い（「2024 年と 2025 年の方針を比較して」）を扱える。
回答を信頼できるものにする
三つの実践がほとんどの仕事をする。
引用を要求する。 各主張に出典 ID を付けさせ、リンクとして描画する。利用者は確認でき、こちらは «引用された箇所が本当にその文を支えているか» を測れる。
「わからない」を許す。 明示的に指示する — 取得した箇所に答がなければ、わからないと言え。 この一文がないと、親切なモデルは一般知識で空白を埋める。正しいかもしれないし、誤りかもしれないし、まったく別の会社の話かもしれない。
検索を単独で評価する。 質問と正解箇所の組を作り、recall@k を追う。この数値は回答の «読み心地» と無関係に検索が良くなっているかを教えてくれる。最終回答だけを目で見るチームは、目隠しでチューニングしている。
良い状態とはこういうものだ
成熟した RAG システムは、ある特定の意味で «退屈» である。自社の文書から答え、その文書にリンクし、見つからなければ見つからないと言い、昨日と今日で挙動が同じだ。そこに至る道はほとんどが検索エンジニアリング — チャンキング、ハイブリッド、再ランキング、フィルタ — であり、言語モデルは最後の最も小さい一歩を担う。
一週間をどこに使うか選ぶなら、検索に使うべきだ。
よくある質問
- RAG はファインチューニングより優れているか？
- 解く問題が違う。RAG はモデルが持たない事実を供給し、ファインチューニングは形式・語調・狭い技能を教える。「自社データを知らない」なら RAG である。
- コンテキストウィンドウが非常に大きければ RAG は不要になるか？
- 圧力は減るが必要は消えない。毎回コーパス全体を送るのは高く遅く、極端に長い入力では精度も落ちる。検索はリクエストを小さく的確に保つ。
- RAG を入れたのに幻覚が出るのはなぜか？
- たいていは検索が有用な箇所を返せなかったのにモデルが答えてしまったからだ。明示的な指示と点検で直る — 取得した箇所に答がなければ «わからない» と言わせる。
- チャンキングはなぜ重要か？
- 索引前に文書を分割する方法だからだ。小さすぎると周辺の文脈を失い、大きすぎると一致が薄まる。文字数で切るより、見出しや節といった構造で分ける方がたいてい良い。