Retrieval-augmented generation(検索拡張生成)は、本番運用のAIアプリがプライベートなデータや頻繁に更新されるデータから質問に答える際に、実際に使われているアーキテクチャです。本ガイドでは、RAGとは何か、ファインチューニングに勝つのはどんなときか(負けないのはどんなときか)、パイプラインの各段階がどう動くか、プロトタイプから本番の間にチームを脱線させるミスとは何かを順を追って説明します。最後には、すべての要素に関する具体的なメンタルモデルと、あるシステムがどこで壊れそうかを見抜く判断力が身についているはずです。
Retrieval-Augmented Generationとは実際に何か
ごく簡単に言えば、RAGは問い合わせを2つのフェーズに分割します。外部の知識ストアから関連するコンテキストを検索(retrieve)し、そのコンテキストを条件としてLLMが回答を生成(generate)する。LLMは独自のデータを暗記する必要がなく、推論時にそれを読みます。まるで人間の分析者がレポートを書く前に文書を調べるのと同じです。Lewisら(2020年)がこの用語を提案し、知識集約的なタスクにおいてハルシネーション率が大幅に低下することを示しました。
プライベートデータにとってなぜ重要か
汎用LLMは、社内の契約や先週火曜時点の商品カタログ、企業のサポートチケットについて何も知りません。ファインチューニングで知識の一部を注入することはできますが、学習中にほとんど登場しなかった事実については依然としてハルシネーションを起こし、データが変わるたびに再学習が必要です。RAGはナレッジを外部かつライブに保つことで、両方の問題を回避します。
基本ループ
ユーザーが問い合わせを送ります。システムが問い合わせをエンベディングベクトルに変換し、ベクトルストアから意味的に最も類似した上位k件のチャンクを検索します。それらのチャンクが元の問い合わせとともにプロンプトに挿入されます。LLMは取得したテキストに基づいて回答を合成します。これがループです。本番システムに現れる複雑さは、これら4ステップのいずれかを発展させたものにほかなりません。
RAG vs. ファインチューニング: 適切な道具の選び方
これはチームがもっとも頻繁に悩む問いであり、正直に言えば両者は異なる問題を解決します。ファインチューニングはモデルの推論・応答のしかた ― 文体、ドメイン語彙、出力形式 ― を変えます。RAGは推論時にモデルがどの事実へアクセスできるかを変えます。両者は代替手段ではなく、多くの成熟したシステムでは両方を使います。
RAGが勝つとき
ナレッジベースが頻繁に変わる場合(毎週のプロダクトアップデート、新しい法廷提出書類、進化するサポートドキュメント)にはRAGを使ってください。出典の提示が必要な場合にもRAGが有効です。回答とともにソースチャンクを返せるため、システムを監査可能にします。データ量が大きく多様である場合にも向いています。ベクトルストアは何百万ものドキュメントを、ファインチューニングの繰り返し実行よりはるかに安価にスケールできます。IngestAIのようなツールはこのシナリオのために作られており、企業チームが独自のインフラを一から構築せずに既存のドキュメントリポジトリにRAGパイプラインを接続できます。
ファインチューニングが勝つとき
モデルに特定の出力スキーマを確実に遵守させたり、技術的な方言を流暢に話させたり、ドメイン固有の推論パターンに従わせたい場合にはファインチューニングが優れています。ICD-10コードを正確で構造化された形式で出力する必要がある医療コーディングアシスタントはファインチューニングの恩恵を受けます。毎日更新される50,000ページのナレッジベースから質問に答える必要のあるカスタマーサポートボットはそうではありません。それはRAGの仕事です。
RAGパイプラインの構築: ステージごとに
本番RAGでの失敗の多くは、モデルの失敗ではなくパイプラインの失敗です。質の低いチャンクを与えられた最先端LLMよりも、適切に検索されたコンテキストを与えられた普通のLLMのほうが勝ります。エンジニアリングの時間は検索側に注いでください。
チャンキング: 見落とされがちな基礎
チャンキングとは、ソースドキュメントを、エンベディングが意味を持つ程度に小さく、しかし一貫したコンテキストを保てる程度に大きい単位に分割することです。固定サイズのチャンキング(例: 512トークン、オーバーラップ50トークン)が出発点ですが、セクションの境界でひどく破綻します。意味的チャンキング ― 段落区切り、見出し構造、文境界検出で分割する ― は意味をよりよく保ちます。PDFやスプレッドシートのような構造化ドキュメントには、レイアウト認識を内蔵してマルチフォーマットなドキュメント取り込みを処理するAnaraのようなツールを検討してください。経験則: チャンクサイズはコーパス内の自己完結した事実や議論の粒度とおおよそ一致させるべきです。
エンベディング: テキストを検索可能な形に変換する
エンベディングモデルは各チャンク(および各問い合わせ)を密ベクトルに変換します。問い合わせとチャンクの意味的類似度は、そのベクトル空間における距離計算になります。MTEBリーダーボードは、Retrievalベンチマークでエンベディングモデルを比較するための標準的なリファレンスです。OpenAIのtext-embedding-3-large、CohereのEmbed v3、bge-large-en-v1.5のようなオープンウェイトのモデルは、いずれもレイテンシとコストの制約に応じて優れた性能を発揮します。重要なのは、インデックス作成時と問い合わせ時で同じエンベディングモデルを使うことです。ミスマッチは静かに検索を壊します。
ベクトルストア: インデックスが置かれる場所
ベクトルストアはエンベディングを保持し、近似最近傍(ANN)クエリを高速に処理します。Pinecone、Weaviate、Qdrant、pgvector、ChromaDBが一般的な選択肢です。数十万チャンク未満の小規模コーパスなら、既存のPostgresインスタンス上のpgvectorで十分なことが多く、運用オーバーヘッドを避けられます。大規模になると、HNSWインデックスとフィルタリング機能を備えた専用のベクトルデータベースがその複雑さに見合う価値を発揮します。常に元のチャンクテキストをエンベディングと一緒に保存してください。最终のプロンプトを組み立てる際に必要になります。
リランキング: 取得した集合の再スコアリング
ANN検索は候補を高速に取得しますが不正確です。リランカー ― 通常はCohere RerankやファインチューニングされたBERTバリアントのようなクロスエンコーダモデル ― が、取得した各チャンクを問い合わせに対してより慎重にスコアリングし、集合を並び替えます。この2段階アプローチ(高速なANN検索 + 遅いクロスエンコーダによるリランキング)は、本番運用では単一段階の検索を一貫して上回ります。性能向上は、長くニュアンスのある問い合わせでとくに顕著です。リランキングはレイテンシを追加しますが(通常30〜100ms)、品質改善はほとんどの顧客向けアプリケーションにおいてその価値があります。
LLMによる合成: コンテキストを回答に変える
最終ステージはプロンプトの構築と生成です。リランキングされた上位k件のチャンクをコンテキストとして渡し、ユーザーの問い合わせを含め、コンテキストが不十分な場合の扱い方に関する明示的な指示を追加します ― 「回答が提供された文書にない場合は、その旨を述べる」は任意ではなく、構造的に必要な記述です。プロンプトの長さは重要です。128kのコンテキストウィンドウに20チャンク詰め込めば、Liuら(2023年)が文書化したlost-in-the-middle現象により、LLMが中間に埋もれた事実を見落とす可能性があります。20個の緩く関連するチャンクより、3〜5個の高い関連性を持つチャンクのほうが優れていることがしばしばあります。
本番RAGを破滅させる一般的な落とし穴
プロトタイプのRAGは構築が簡単です。本番のRAGは前提が崩れる場所です。以下に繰り返し現れる失敗パターンを挙げます。
クエリとドキュメントのミスマッチ
エンベディングはあるテキスト分布に基づいて学習されています。ドキュメントが高度に技術的で、ユーザーがカジュアルな質問をする場合(またはその逆)、エンベディング空間がその橋渡しをうまくできないことがあります。HyDE(Hypothetical Document Embeddings) ― 仮の回答を先に生成し、それをエンベディングする ― はひとつの緩和策です。LLMで問いを複数のバリエーションに書き換えるクエリ拡張も別の手段です。どちらもレイテンシと複雑性を増やすので、どちらかを追加する前に、まず検索が実際のボトルネックであることをプロファイリングで確認してください。
ドキュメントは更新されます。インデックス作成パイプラインがドキュメントのバージョンを追跡し、変更されたチャンクを再エンベディングしていないと、ベクトルストアが真実の源から乖離します。ドキュメントレベルの変更検出(ハッシュ比較、Webhookトリガー、定期的な差分検出)を初日からパイプラインに組み込んでください。ローンチ後の後付けは苦痛を伴います。最高のドキュメント管理AIツールのまとめで取り上げているようなAI搭載のドキュメント管理ツールは、取り込みとバージョニングをカスタムビルドではなくサービスとして扱える場所です。
検索品質評価の軽視
チームはRAGシステム全体を(最終的な回答が正しいように見えるかで)評価するだけで、検索品質を独立して測定することはありません。これではデバッグが不可能になります。既知の関連チャンクを持つ質問からなる検索評価セットを構築してください。recall@kとMean Reciprocal Rankをシップ前に測定します。検索品質が低ければ、合成ステージでのプロンプトエンジニアリングでどうにかなる問題ではありません。
過度なチャンキングと不十分なチャンキング
小さすぎるチャンクは事実を意味づける周囲のコンテキストを削ぎ取ります。大きすぎるチャンクはエンベディング信号を希薄化し、プロンプトを肥大化させます。普遍的に正しいチャンクサイズというものは存在しません ― それはドキュメント構造に依存します。別のデータセット向けに書かれたチュートリアルのデフォルトをコピーするのではなく、実際のコーパスでオフライン実験を実行してください。
セキュリティとデータ漏洩
マルチテナントシステムでは、ユーザーの問い合わせはアクセス権限のあるドキュメントだけを検索できなければなりません。ベクトルストアのメタデータフィルタが標準的なメカニズムです ― すべてのチャンクがテナントや権限タグを持ち、すべての問い合わせにフィルタ句を含める必要があります。検索レイヤーでこれを強制しないと、プロンプトインジェクション攻撃や悪意のあるクエリによって他ユーザーのプライベートデータが表出する可能性があります。これは仮説上のエッジケースではなく、文書化された攻撃クラスです。埋め込みAIで本番アプリを構築しており、AIコンポーネント周辺の堅牢なアクセス制御パターンが必要であれば、Retool AIレビューでエンタープライズグレードのアプリプラットフォームが権限処理をどのように扱っているかが解説されています。
RAGシステム全体をエンドツーエンドで評価する
評価はほとんどのチームが投資不足になる領域です。有用なフレームワークは品質を3要素に分解します。検索の忠実度(retrieval faithfulness)(正しいチャンクを surfacedしたか?)、回答の忠実度(answer faithfulness)(生成された回答が取得したコンテキストに基づき、ハルシネーションを起こしていないか?)、回答の関連性(answer relevance)(ユーザーが尋ねたことに実際に答えているか?)。RAGASのようなフレームワークはこれら3つすべてに対する自動メトリクスを提供します。自動メトリクスが見逃す失敗モード ― 特にトーン、完全性、技術ドメインにおけるエッジケース ― を捉えるには人手評価が依然として不可欠です。
グラウンドトゥルース用テストセットの構築
コアなユースケースをカバーする50〜100個の質問-回答ペアから始めてください。敵対的な例も含めてください。コーパスにない質問(システムは棄権すべき)、複数のドキュメントにまたがる質問(システムは統合しなければならない)、曖昧なクエリなどです。このサイズのテストセットは、大きなアノテーションバジェットを必要とせずに、ほとんどの退行をキャッチします。レビュー対象としてフラグ付けされた実際のユーザークエリを使って時間をかけて拡張してください。最高のノートテイキング・ナレッジAIツールの解説で触れているようなノートテイキング・ナレッジ管理ツールは、専用の社内ツールなしに評価データセットを整理・アノテーションするのに役立ちます。
知っておきたいアーキテクチャパターン
基本的なパイプラインに加えて、いくつかのパターンが本格的な本番システムで標準になっています。
ハイブリッド検索
純粋なベクトル検索は、BM25(スパース検索)がうまく処理する正確なキーワードマッチを取り逃します。ハイブリッド検索は両方を並行して実行し、Reciprocal Rank Fusionを使って結果をマージします。この組み合わせは、製品名、コード、固有名詞を含むドメイン固有のクエリにおいて、どちらかのアプローチ単独を一貫して上回ります。
Agentic RAG
Agenticなセットアップでは、LLMが検索するかどうか、どのクエリを発行するか、取得したコンテキストが十分かどうか、追加検索ステップが必要かどうかを判断します。これは「契約のペナルティ条項についてどう書いてあったか、そしてそれは業界標準とどう比較されるか?」のような、複数ステップを踏まなければならない質問 ― シングルショットの検索ではきれいに答えられない質問 ― を扱います。トレードオフはレイテンシと複雑性です。Agentic RAGは推論集約型のユースケースには投資する価値がありますが、シンプルなQ&Aには過剰です。
キャッシュ
セマンティックキャッシュは、最近のクエリと回答のペアを保存し、意味的に類似した受信クエリに対してキャッシュされた結果を返します。これは、多くのユーザーが同等の質問をする高ボリュームシステムにおいて、レイテンシとコストを劇的に削減します。検索パイプラインの後ではなく前に、レイヤーとして実装してください ― キャッシュヒット時にはパイプライン全体をスキップしたいからです。
Retrieval-augmented generationは、研究的好奇心から、プライベートまたは動的なデータで確実に動作する必要があるあらゆるAIアプリケーションにとっての必須要件へと移行しました。パイプラインは習得可能であり、ツールは成熟しており、失敗モードは十分に文書化されています ― つまり、今の難しさの大部分は研究の新規性よりもエンジニアリング規律にあります。チャンキングを正しく行い、検索を独立して評価し、ベクトルレイヤーへのアクセス制御を強制すれば、ローンチ後に多くのチームを振り出しに戻す間違いを避けられるでしょう。
