RAG と Fine-tuning の選択基準:業務ドメイン特化のコスト構造と運用トレードオフ

両者が扱う問題の違い

RAG は、質問に対する回答生成の際に、ベクトルデータベースから関連文書を検索し、その文書を LLM のコンテキストに含めて生成する。この構造の強みは、外部知識ソースが更新されれば、モデルを再学習することなく最新情報を反映できる点にある。企業ドキュメント・製品マニュアル・社内 Wiki のような、頻繁に更新されるコンテンツに対して直感的にフィットする。

Fine-tuning は、事前学習済みモデルに対して、対象ドメインのデータで追加学習を施し、モデルの内部パラメータを更新する。ドメイン特有の言語表現・出力形式・スタイルを、モデルが「暗黙的に」学ぶ効果がある。Anthropic や OpenAI が公開する Fine-tuning 実装のドキュメントも、この効果を明示的に挙げている。

もっとも、両者を排他的な選択肢として扱うのは実務的でない。多くの本番システムでは、Fine-tuning したモデルの上に RAG レイヤーを組み合わせるハイブリッド構成が採用されている。「どちらか」ではなく「どちらを主軸にどう組み合わせるか」が問いになる。

RAG が有利な状況

RAG は次のような状況で明確に有利である。第 1 に、参照する知識の更新頻度が高い場合。製品カタログ・法令・社内ポリシーなど、月単位以上の頻度で更新される情報を扱う場合、Fine-tuning での毎回の再学習は非現実的である。第 2 に、監査要件で「回答の根拠を提示できる」ことが求められる場合。RAG は参照した文書を出力とともに提示でき、監査可能性が高い。EU AI Act の運用ルールが日本企業に与える実務的影響で扱う説明可能性の要件でも、この特性は重要な利点になる。

第 3 に、対象ドメインの学習データが十分に集まらない場合。Fine-tuning で意味のある効果を得るには、通常、数千〜数万件のドメイン固有データが必要とされる。この規模を確保できない中小規模の業務ドメインでは、RAG のほうが投資対効果で優れることが多い。

Fine-tuning が有利な状況

一方、Fine-tuning が明確に有利な状況もある。第 1 に、業界特有の言い回し・略語・形式が多用される領域——医療記録・法律文書・金融レポート——で、そもそものモデル出力をドメイン標準に近づけたい場合。プロンプトによる制御では届かない微細な言語スタイルを、Fine-tuning は内在化させる。

第 2 に、レイテンシ・コストの観点。RAG は毎回のリクエストで検索処理が入り、コンテキストが長くなるため、推論トークン数が増える。LLM 推論の本番運用で扱うように、コンテキスト長は推論コストと KV キャッシュ消費に直接影響する。高頻度の反復リクエストが発生するユースケースでは、Fine-tuning のほうが総保有コストで有利になる場合がある。

ただし、Fine-tuning は、モデルが「なぜその出力をしたか」の説明が RAG より弱くなる。監査要件の厳しい業種では、この点が判断材料として重い。

運用フェーズでの見落とし

初期評価では Fine-tuning のメリットが目立ちやすいが、運用フェーズで RAG に切り替える事例が観察されている。原因の 1 つは、業務データの更新頻度が導入当初の想定より高かった点である。「年 1 回の再学習で済む」と見積もっていた組織が、実際には四半期ごとの再学習を要求され、その工数と、モデル評価のコストが継続的な負担になる。

もう 1 つの原因は、Fine-tuning の効果測定の難しさである。「以前の出力より良くなった」を客観指標で示すのは、ドメイン特化になるほど困難で、業務側の主観的な評価に依存しやすい。もっとも、RAG も評価の難しさから完全に解放されるわけではなく、検索精度と生成品質の分離評価が別の課題になる。

実務的な選定プロセス

選定を単純化すると、以下の順序が実務的である。第 1 に、対象データの更新頻度が四半期以下であれば、まず RAG を検討する。第 2 に、ドメイン特有の表現・形式の一致度が業務価値に直結する場合、Fine-tuning の追加を検討する。第 3 に、両者のハイブリッド構成 (Fine-tuned モデル + RAG) を、コストと運用能力が許す範囲で最終形として想定する。

この判断は、API 層の設計と切り離せない。生成結果を業務システムに組み込むには、GraphQL Federation と REST API ゲートウェイの選択基準で扱うようなインターフェース設計が並行して必要になる。データフローを含めた全体像で選定を判断する姿勢が、後の運用フェーズでの手戻りを防ぐ。

結論:排他ではなく組み合わせの設計

「RAG か Fine-tuning か」という二分法の議論は、実務的にはあまり生産的でない。両者は異なる問題を解いており、多くの本番システムは両者を組み合わせて運用している。判断すべきは、自社の業務ドメインで、更新頻度・データ規模・監査要件のバランスがどこにあるかであり、その分析結果が選定を自然に導く。