F-7: RAG vs ファインチューニング vs ロングコンテキスト¶

この相反は何か¶

LLMにドメイン知識や企業固有の情報を与える手段として、検索拡張生成（RAG：外部知識を検索してプロンプトに注入する）か、ファインチューニング（FT：モデルの重みを追加学習で調整する）か、ロングコンテキスト（大きなコンテキスト窓にドキュメントをそのまま投入する）かという三者択一です。厳密には二者択一ではなく三択ですが、「知識をどの層で与えるか」という軸で排他的な選択肢を構成します。

この選択が排他的として扱われる理由は、知識の格納場所と更新サイクルが根本的に異なるためです。RAGは知識をインデックス（ベクトルDB等）に置き、推論時に検索して注入します。FTは知識をモデルの重みに焼き込み、学習時にしか更新できません。ロングコンテキストは知識をプロンプトにそのまま埋め込みます。それぞれ更新頻度・コスト構造・出典追跡性が異なるため、ユースケースに応じて主軸を1つ選ぶ必要があります。

AIエージェントにおいてこの選択が特に重要なのは、[accountability]（出典の明示が必要か）と [cost_sensitivity]（トークンコストの制約）が直接的に絡むためです。回答の根拠を示す必要がある場面ではRAGの出典追跡が不可欠であり、様式の一貫性が求められる場面ではFTの行動変容が有効です。

選択肢A：RAG（検索拡張生成）¶

外部の知識ベース（ベクトルDB、全文検索エンジン、構造化DBなど）から、クエリに関連する情報を検索し、その結果をLLMのプロンプトに注入して回答を生成します。知識はモデルの外に存在し、インデックスの更新でリアルタイムに反映されます。

RAGの最大の利点は知識の鮮度と出典追跡です。ドキュメントが更新されたらインデックスを再構築するだけで、モデルの再学習は不要です。検索結果のソースをメタデータとして保持するため、「この回答の根拠はどのドキュメントの何ページか」を提示できます。[accountability] が高い環境で特に価値があります。

コスト構造の面では、推論時に検索コストとプロンプト注入のトークンコストが加算されますが、モデルの再学習コスト（FT）と比べれば桁違いに安価です。知識ベースの規模がスケールしても、検索アルゴリズムの最適化で対応できます。

弱点は検索の品質に依存することです。関連文書が正しく検索されなければ、回答の品質は低下します。チャンクの分割方法、埋め込みモデルの選択、リランキング戦略が品質を左右し、これらのチューニングが必要です。また、検索結果をプロンプトに注入するため、コンテキスト窓を消費します。D2 コンテキスト予算配分との併用が実質的に必須です。

さらに、RAGは事実の提供には強いですが、行動様式の変容には弱いです。「常に法務文書の形式で出力する」のような様式の統一は、RAGで法務文書の例を注入しても一貫性が低く、FTの方が適しています。

選択肢B：ファインチューニング（FT）¶

ドメイン固有のデータセット（入出力のペア）でモデルの重みを追加学習し、特定の行動様式・出力形式・専門用語の使い方をモデルに「染み込ませます」。知識はモデルの重みの中に存在し、推論時にプロンプトへの注入は不要です。

FTの最大の利点は行動様式の安定的な変容です。出力の形式、口調、専門用語の使い方、特定のパターンへの反応をモデルレベルで統一できます。推論時に例示を注入する必要がないため、コンテキスト窓を節約できます。また、繰り返し同じ形式で出力する場面では、推論コストがRAGより低くなりえます（検索コストとプロンプト注入のトークンが不要なため）。

弱点は更新の困難さとコストです。知識が変わるたびにモデルを再学習する必要があり、データセットの準備・学習の実行・品質検証のサイクルに日〜週の時間がかかります。頻繁に変わる事実情報（価格、在庫、規約の改定）をFTで扱うのは現実的ではありません。

もう一つの重大な弱点は出典の不透明さです。FTされた知識は「モデルがそう知っている」状態であり、「どのドキュメントから得た知識か」を事後に追跡することが不可能です。[accountability] が高い環境では致命的です。また、FTで入れた知識がハルシネーションと区別できないため、事実性の検証が困難です。

選択肢C：ロングコンテキスト¶

大きなコンテキスト窓（100k〜2Mトークン）を持つモデルに、関連ドキュメントをそのまま投入します。検索も学習も不要で、ドキュメントをプロンプトに含めるだけです。

ロングコンテキストの利点は実装の単純さです。ベクトルDB、検索パイプライン、チャンク分割、FTのインフラがすべて不要です。ドキュメントをそのまま入れるため、チャンク分割による文脈の断絶がなく、文書全体の構造を保持したまま推論できます。

弱点はコストとスケーラビリティです。トークン課金モデルでは、投入量がそのままコストに直結します。100kトークンのドキュメントを毎回投入すれば、1リクエストあたりのコストが桁違いに膨らみます。また、知識ベースが数百〜数千ドキュメントに及ぶ場合、すべてを窓に入れることは物理的に不可能です。"Lost in the Middle"問題（窓の中盤に置かれた情報は注意が薄れる）もあり、投入量が増えるほど精度が下がるリスクがあります。

ロングコンテキストが適するのは、文書が少数（概ね1〜5件）で、文書全体の構造が重要であり、[cost_sensitivity] が低い場合です。

選定基準¶

選定は知識の性質と駆動変数の組み合わせで判定します。

知識の性質	適する手段	根拠
頻繁に変わる事実情報（FAQ、価格、在庫）	RAG	FTでは更新が追いつかない
出典の明示が必要な知識	RAG	`[accountability]` 要件
行動様式・出力形式の統一	FT	プロンプトでは一貫性が低い
専門用語や口調のカスタマイズ	FT	モデルレベルで染み込ませる
少数の小さな文書の全体理解	ロングコンテキスト	チャンク分割の損失を回避
文書構造が重要（契約書全体の解釈など）	ロングコンテキスト	構造を保持したまま推論

駆動変数による判定：

[accountability] が高い → RAG（出典追跡が可能）
[cost_sensitivity] が高い → RAG（必要な情報だけ検索して注入）またはFT（検索コスト不要）
[cost_sensitivity] が低く文書が少数 → ロングコンテキスト

デフォルトとハイブリッド¶

デフォルト：知識が変わる・出典が要る場合はRAGをデフォルトにしてください。 ほとんどの業務システムでは知識は更新されるものであり、出典を示す能力は信頼性の基盤です。RAGを基盤として構築し、必要に応じて他の手段を追加します。

ハイブリッド：様式はFT、事実はRAGの組み合わせが強力です。FTで出力形式・口調・専門用語の使い方をモデルに染み込ませ、RAGで最新の事実情報を検索して注入します。これにより、出力の一貫性（FTの利点）と知識の鮮度・出典追跡（RAGの利点）を両立できます。ロングコンテキストは、RAGのチャンク分割では失われる文脈が重要な場面で、RAGの補完として使います。

判断を誤ったときの症状¶

RAGを選ぶべきだったのにFTを選んだ場合：

知識が更新されたのに、モデルの再学習が追いつかず古い情報で回答し続けます。
「この回答の根拠は？」と問われたとき出典を示せず、信頼性が損なわれます。
FTに使ったデータセットの誤りがモデルに焼き込まれ、修正に再学習が必要です。

FTを選ぶべきだったのにRAGを選んだ場合：

出力の形式や口調が毎回微妙に異なり、ブランドの一貫性が維持できません。
RAGで注入する例示が毎回コンテキスト窓を消費し、本来の処理に使える窓が圧迫されます。
同じ様式指示をFew-shotで繰り返し投入するコストが、FTの初期コストを超えます。

ロングコンテキストを選ぶべきだったのにRAGを選んだ場合：

チャンク分割で文脈が断絶し、「前のセクションで述べた条件」のような文書内参照を解決できません。
小さな文書なのに、ベクトルDB・検索パイプラインの運用コストが見合いません。