7月16日、n8nが「Fine-Tuning vs. RAG: When to Use Each for Production LLMs」と題した記事を公開した。本番LLMシステムの設計において「RAGにするか、ファインチューニングにするか」という判断は避けて通れないが、記事はその選択を「モデルが知識にアクセスできていないのか、それとも知識はあるのに挙動が悪いのか」という一問に集約する。判断基準の明快さが際立つ内容であり、ファインチューニングの利用が業界全体で縮小傾向にある現状を踏まえた実践的な指針が示されている。
RAGとファインチューニングの本質的な違い
RAG（Retrieval-Augmented Generation）は、モデルの重みを変えず、推論時に外部ソース（ベクターDB、ドキュメント等）から関連情報を取得してプロンプトに組み込む手法だ。知識がモデルの外にあるため、再学習なしにデータを更新できる。
ファインチューニングは、追加の学習データでモデルの重みそのものを更新する。特定のトーンや出力フォーマット、ドメイン固有の推論パターンをモデルに「覚えさせる」ことができる。
現在、ファインチューニングの利用はRAGと比較して減少傾向にある。背景には、長コンテキストLLMの普及、トークンコストの低下、そしてフロンティアモデルがファインチューニングを非サポートにする動きがある。元記事によると、OpenAIも一部のホスト型モデル（text-davinci-003等、順次廃止が進んでいるレガシーモデル群）でファインチューニング機能を廃止しつつあり、この傾向は今後も続く可能性が高いと指摘されている。
どちらを選ぶか：根本原因で判断する
記事が提示する最もシンプルな判断基準は次のとおりだ。
- モデルが必要な情報にアクセスできていない → RAGが先手
- 情報はあるのに出力が不安定・低品質 → ファインチューニングを検討
この問いに答えるだけで、多くのケースでは方向性が定まる。
RAGを選ぶ場面
- 製品ドキュメント、ポリシー、価格情報など頻繁に変わる知識を扱う
- 回答の出典を追跡できる必要がある
- 知識ベースが大きく、すべてをモデルに埋め込むのが非現実的
- Few-shotプロンプティングで挙動制御が可能なコスト構造である
RAGでよくある失敗パターンとして、検索精度の低さが挙げられる。クエリとドキュメントのベクター空間がずれていたり、チャンクサイズが不適切だったりすると、正しい情報が取得できずに回答品質が落ちる。この場合、ファインチューニングに切り替える前に、リランキングやハイブリッド検索（スパース＋デンスベクター）の導入で改善できることが多い。
ファインチューニングを選ぶ場面
- 特定のフォーマットやブランドトーンへの一貫した準拠が必要
- 医療・金融など、ベースモデルが苦手とする専門タスクに取り組む
- 主に小規模なオープンウェイトLLMを使う場面（GPT-4等のフロンティアモデルは非対応が増えている）
ファインチューニングの大きな難所は学習データの準備だ。出力品質を上げるには、ターゲットとなる挙動を的確に表現した高品質なサンプルが数百〜数千件必要になる。ラベル付けの一貫性が低いデータや、エッジケースが偏ったデータセットは、モデルの出力品質を下げるリスクすらある。「ファインチューニングすれば改善する」と安易に期待する前に、データ収集・品質検証のコストを見積もっておくことが重要だ。
コストとレイテンシのトレードオフ
RAGのコストは実行時に集中する。エンベディング生成、ベクターDBへの格納、クエリのたびの検索ステップが加わる。高品質な検索を実現するには、スパースベクターとデンスベクターの組み合わせやリランキングなど、追加のエンジニアリングが必要になる場合もある。
ファインチューニングのコストはデータ準備と学習フェーズに前倒しされる。一方、一度ファインチューニングされた小規模LLMは、外部コンテキストなしに応答できるため、推論時のオーバーヘッドを削減できる。低レイテンシが求められるエッジ環境やオフライン環境では、この特性が優位に働く。
両者を組み合わせるハイブリッド構成
RAGとファインチューニングは排他的ではなく、組み合わせることで相乗効果が得られる。
記事ではカスタマーサポートアシスタントを例に挙げている。自社ホスティングのファインチューニング済みモデルがコミュニケーションスタイルとサポートプロセスを学習し、RAGパイプラインが最新の製品ドキュメントやトラブルシューティングガイドを実行時に取得する構成だ。
この設計の考え方として記事が示すのが、「安定コンテンツ」はファインチューニング、「動的知識」はRAGという役割分担だ。毎回同じコンテキストをプロンプトに追加するコストを削減しながら、最新情報へのアクセスは維持できる。
さらに最新の研究では、RAFT（Retrieval-Augmented Fine-Tuning）というアプローチも登場している。取得済みコンテキストを含む例でモデルをファインチューニングし、外部情報の使い方そのものをモデルに学習させる手法だ（arXiv:2403.10131）。RAGの「検索精度」とファインチューニングの「推論品質」を同時に引き上げようとする試みとして注目されている。
実装の判断軸まとめ
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 知識の更新 | リアルタイムで容易 | 再学習が必要 |
| コスト発生タイミング | 実行時 | 学習時に前倒し |
| フロンティアモデルとの相性 | 良好 | サポート縮小傾向 |
| 向いている問題 | 知識アクセス不足 | 挙動・スタイル制御 |
| データ準備の難度 | 中（チャンク設計・検索チューニング） | 高（大量の高品質サンプルが必要） |
多くのチームがまずRAGから始めるのは、更新とデバッグが容易だからだ。ファインチューニングはセルフホストインフラで特定の挙動が必要になった段階で追加を検討するのが現実的なパターンとなっている。判断に迷ったときは冒頭の一問に立ち返るとよい。「知識の問題か、挙動の問題か」 — この問いが設計の出発点になる。
詳細はFine-Tuning vs. RAG: When to Use Each for Production LLMsを参照していただきたい。
