ファインチューニングとRAGの違いは？FDEが現場で選ぶ判断基準と使い分け
- 学習データでモデルの重みを更新する
- 出力形式・口調・タスク手順の固定に強い
- 知識を更新するには再学習が必要
- 回答の根拠となる文書を示しにくい
- 検索した外部文書をプロンプトに渡す
- モデルの重みは変更しない
- 文書を差し替えるだけで知識を更新できる
- 参照した文書を出典として提示できる
- 1. プロンプトで検証指示文と少数の例示だけで要件を満たせるかを最初に確かめる
- 2. 知識不足ならRAG社内文書や最新情報が必要なら検索基盤を作り、根拠付きで回答させる
- 3. 振る舞い不足なら微調整出力形式や判断基準が安定しない場合に限ってファインチューニングを検討する
- 4. 評価セットで比較業務で使う問いの評価セットを作り、構成ごとの精度とコストを比べる
ファインチューニングとRAGの違いは？
RAGは外部の知識を検索して回答時に渡す仕組みで、ファインチューニングはモデル自体を追加学習させる手法です。
ファインチューニングとRAG（Retrieval-Augmented Generation：検索拡張生成）は、どちらも大規模言語モデル（LLM）を業務に合わせるための手法です。ただし、手を入れる場所がまったく違います。RAGはモデルの外側に知識を置き、ファインチューニングはモデルの内側の重みを変えます。この違いを押さえておくと、FDE（Forward Deployed Engineer）が顧客の現場で提案を組み立てるときの土台になります。
仕組みの違い：知識を「渡す」か「覚えさせる」か
RAGは質問のたびに関連文書を検索してプロンプトに入れ、ファインチューニングは学習データでモデルの振る舞いを変えます。
RAGは2020年にMeta AI（当時Facebook AI Research）のLewisらが論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で提案した考え方です。現在の実装では、次の流れが一般的です。
- 社内文書やマニュアルを適切な長さに分割（チャンク化）する
- 埋め込みモデルでベクトルに変換し、ベクトルDBや検索エンジンに登録する
- ユーザーの質問に近い文書を検索する
- 検索結果をプロンプトに入れ、LLMに回答を生成させる
一方のファインチューニングでは、入力と期待する出力のペアを数百〜数千件ほど用意し、モデルの重みを追加学習で更新します。2021年にMicrosoftのHuらが提案したLoRA（Low-Rank Adaptation）のように、更新するパラメータを絞って計算コストを下げる手法が普及したことで、以前より手が届きやすくなりました。
コスト・更新頻度・説明可能性の比較
知識の更新しやすさと出典の示しやすさではRAGが勝り、出力の一貫性と推論時の効率ではファインチューニングが勝ります。
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 変えるもの | モデルに渡す入力（コンテキスト） | モデルの重み（振る舞い） |
| 知識の更新 | 文書を差し替えればすぐ反映される | 再学習が必要 |
| 出典の提示 | 検索した文書を根拠として示せる | 根拠を示すのは難しい |
| 得意なこと | 事実の参照、最新情報、社内規程 | 出力形式、口調、分類・抽出の型 |
| 初期コスト | 検索基盤の構築と文書整備 | 学習データの作成と学習の実行 |
| 推論時コスト | 入力トークンが増えやすい | プロンプトを短くできる場合がある |
| 主なリスク | 検索漏れ、古い文書の混入 | 過学習、学習データ由来の誤りの定着 |
実務の感覚としては、「モデルに新しい事実を覚えさせたい」という要望の多くは、実際にはRAGで解決できる課題です。MicrosoftのOvadiaらによる2023年の研究「Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs」でも、新しい知識を取り込ませる用途ではRAGのほうが安定して良い結果を出したと報告されています。
RAGとファインチューニングはどう使い分ける？
知識の鮮度と出典が重要ならRAG、出力形式や判断の型をそろえたいならファインチューニングを選ぶのが基本です。
使い分けの判断軸はシンプルで、「足りないのは知識か、振る舞いか」です。顧客から聞く課題をこの2つに分けるだけで、議論の方向がかなりはっきりします。
RAGを選ぶべき条件
扱う情報が頻繁に変わる場合や、回答の根拠を示す必要がある場合は、まずRAGを選ぶのが妥当です。
- 社内規程、製品仕様、FAQなど、月単位・週単位で更新される情報を扱う
- 金融・医療・公共分野など、回答の出典を監査や説明に使う必要がある
- 部署や役職によって閲覧できる文書が違い、アクセス制御が必要になる
- 対象の文書が大量にあり、すべてをモデルに学習させるのが現実的でない
アクセス制御はFDEの現場でとくに重要な論点です。ファインチューニングでモデルに入った知識は、権限ごとに出し分けることができません。検索の段階で権限フィルタをかけられるRAGのほうが、企業のガバナンス要件に合わせやすい構成です。
ファインチューニングを選ぶべき条件
出力形式の厳密さや業界特有の文体・分類ルールを安定して守らせたい場合は、ファインチューニングが有効です。
- 帳票や構造化データ（JSONなど）を決まった形式で出力させ続けたい
- 問い合わせの分類やエンティティ抽出など、繰り返し行うタスクの精度を上げたい
- 専門分野の言い回しや社内の文書スタイルに合わせたい
- 長いプロンプトで指示している内容をモデルに覚えさせ、推論コストや応答速度を改善したい
ただし、プロンプトの改善や少数の例示（few-shot）で十分に解決するケースも少なくありません。ファインチューニングは学習データの品質管理やモデルの更新運用まで含めて負担になるため、他の手段を試したうえで選ぶ位置づけと考えるのが無難です。
迷ったときの判断フロー
プロンプト改善→RAG→ファインチューニングの順に試し、各段階で評価データを使って効果を確かめるのが安全です。
- 課題を分ける：誤答の原因が「知識不足」なのか「形式・振る舞いの不安定さ」なのかを分類する
- プロンプトで試す：指示の明確化とfew-shotで改善するかを確認する
- 知識不足ならRAG：検索精度（必要な文書が上位に入っているか）を先に測る
- 振る舞いの問題ならファインチューニングを検討：学習データを集められるか、継続して保守できるかを確認する
- 評価セットで比較する：同じ評価データで改善前後を数値で比べる
両者を組み合わせるべきケースは？
社内知識の参照と、業界特有の出力形式や用語の遵守を同時に求められる場合は、組み合わせが有力な選択肢です。
RAGとファインチューニングは対立するものではありません。知識はRAGで渡し、振る舞いはファインチューニングで整える、という役割分担ができます。2024年にUC BerkeleyのZhangらが発表したRAFT（Retrieval Augmented Fine Tuning）は、検索された文書にノイズが混ざっていても適切な根拠を選んで回答できるよう、モデルを学習させる手法です。両者を組み合わせる方向の研究も進んでいます。
組み合わせが効く典型パターン
検索結果の読み取り方や回答形式までそろえたい業務では、RAGに軽いファインチューニングを加える構成が効きます。
| パターン | RAGの役割 | ファインチューニングの役割 |
|---|---|---|
| 社内ヘルプデスク | 最新の規程や手順書を検索する | 回答テンプレートと敬語のトーンをそろえる |
| 保守・点検レポート作成 | 過去の点検記録や設備仕様を参照する | 報告書のフォーマットと専門用語を守らせる |
| 契約書レビュー支援 | 社内基準や過去の条項例を検索する | リスク分類のラベル付けルールを学習させる |
| 業界特化の検索アシスタント | 業界の資料や社内ナレッジを取り込む | 検索結果から根拠を選び引用する振る舞いを強化する |
組み合わせる前に確認したいこと
組み合わせは効果が大きい分、運用負荷も倍増するため、評価・保守体制が用意できるかを先に確認する必要があります。
- 評価データがあるか：RAG単体と組み合わせ構成を比べられる評価セットを用意できるか
- 更新サイクルが合っているか：文書の更新とモデルの再学習を、それぞれ誰がどの頻度で行うか
- 原因を切り分けられるか：誤答が検索の失敗なのか生成の失敗なのかを、ログから区別できるか
- モデル更新に追従できるか：ベースモデルが新しくなったとき、再学習をやり直す前提で計画しているか
最後の点は見落とされがちです。ベースモデルの世代交代が速い現在は、苦労してファインチューニングしたモデルが、次世代モデルとプロンプトの組み合わせに追い抜かれることも珍しくありません。投資判断では、この陳腐化のリスクも考えておきたいところです。
FDEは顧客現場でどう判断し実装する？
FDEはまずプロンプトとRAGで最小構成を作り、評価データで不足を特定してから学習に進む順序で判断します。
FDEの価値は、技術的に正しい選択をすることだけでなく、顧客の業務・データ・組織の制約に合わせて「動くもの」を早く届けることにあります。Palantirが提供するAIPは、LLMをOntology（業務データを意味づけしたモデル）に接続して使う考え方をとっています。これはモデルに知識を覚えさせるより、信頼できるデータに根拠を置く（グラウンディングする）発想で、RAG的なアプローチに近いものです。
初期フェーズで何を見極めるか
最初に見極めるべきなのは技術選定ではなく、データの所在と品質、そして「正解」を誰が判定できるかです。
初期のヒアリングでは、次の項目を確認しておくと、後の選択がぶれにくくなります。
| 確認項目 | 具体的に聞くこと | 判断への影響 |
|---|---|---|
| データの所在 | 文書はどのシステムに、どの形式で保存されているか | RAGの取り込み設計 |
| 更新頻度 | 規程やマニュアルはどの頻度で改訂されるか | RAGが優先になるか |
| 権限要件 | 部署・役職ごとに閲覧範囲が違うか | 検索時のフィルタ設計 |
| 正解の定義 | 回答の良し悪しを誰がどう判定するか | 評価セットの作り方 |
| 出力の形式 | 下流のシステムやワークフローに求められる形式は何か | ファインチューニングを検討するか |
現場の実感として、プロジェクトがつまずく原因はモデル選定よりも、文書がPDFのスキャン画像しかない、担当者ごとに版が違うといった、データ側の問題であることが多い印象です。
評価設計とPoCから本番への移行
PoCの段階で業務担当者と評価セットを作っておくことが、本番移行とファインチューニング判断の両方を左右します。
- 評価セットの作成：実際の問い合わせや業務事例から、質問と期待する回答のペアを集める
- ベースラインの測定：プロンプトだけの構成で正答率や形式の遵守率を記録する
- RAGの導入と測定：検索の再現率と回答品質を分けて評価する
- 残った誤りの分類：知識不足なのか、形式・判断の誤りなのかを分ける
- ファインチューニングの判断：振る舞いの誤りが多く、学習データを継続して用意できる場合に限って進める
評価セットは、一度作れば終わりではありません。本番運用で見つかった誤答を追加し続けることで、モデルやRAGの構成を変えたときの回帰テストとしても使えます。
意思決定者に説明するときのポイント
経営層や事業責任者には、精度の話より「更新・統制・コスト」の3点で選択肢を比べて示すと合意を得やすくなります。
- 更新：情報が変わったとき、誰がどれくらいの手間で反映できるか
- 統制：回答の根拠を示せるか、権限ごとの出し分けができるか
- コスト：初期構築費だけでなく、再学習や文書の保守を含めた運用コストはどうか
FDE導入を検討している企業の側から見ると、「ファインチューニングで自社専用AIを作りたい」という要望の背景には、競合との差別化や社内の知見を残したいという意図があることが多いようです。FDEはその意図をくみ取ったうえで、まずRAGで素早く価値を出し、データと評価の基盤が整った段階で学習を検討する道筋を示す。この段階的な提案が、顧客の信頼につながりやすいと考えられます。
参考文献・出典
- Lewis, P. et al. (2020). “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” NeurIPS 2020. arXiv:2005.11401
- Hu, E. J. et al. (2021). “LoRA: Low-Rank Adaptation of Large Language Models.” arXiv:2106.09685
- Ovadia, O. et al. (2023). “Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs.” arXiv:2312.05934
- Gao, Y. et al. (2023). “Retrieval-Augmented Generation for Large Language Models: A Survey.” arXiv:2312.10997
- Zhang, T. et al. (2024). “RAFT: Adapting Language Model to Domain Specific RAG.” arXiv:2403.10131
※本記事の現場実務に関するコメントは、公開前に監修者が確認・承認します。
