RAG vs ファインチューニング：使い分けを実測データで比較

RAG vs ファインチューニング：使い分けを実測データで比較

RAG vs ファインチューニングに関するアドバイスのほとんどは、同一タスクで両方を測定した唯一の実験に触れません。BalaguerらによるarXiv:2401.08406（被引用数162回）は、農業分野のQAセットを両方の構成に通しました。ファインチューニングだけで精度が6ポイント以上向上し、RAGはその上にさらに5ポイントを積み上げました。同論文のTable 18によると、GPT-4は無加工で75%、ファインチューニング後81%、検索併用で86%です。では、なぜ私たちがほとんどのチームにまずRAGを勧めるのでしょうか？それは、鮮度・引用・そして以下のコスト計算が、精度1ポイントの差よりも多くのプロジェクトの命運を分けるからです。

この記事のポイント

• 知識が頻繁に変わる、あるいは回答にソース引用が必要な場合はRAGが既定の選択です。ファインチューニングは出力形式の一貫性とレイテンシで勝ちます。
• ファインチューニングのコストは前払い（学習）、RAGのコストはクエリごと（埋め込み＋追加入力トークン）で発生します。
• 同一タスクの公開エビデンス：ファインチューニングが精度+6ポイント、RAGがさらに+5ポイント、ハイブリッドは単独のどちらよりも高い結果でした。
• 学習コードを書く前に、5つのチェック（データ鮮度、教師あり例、レイテンシ、引用、チームスキル）を実施してください。

RAG vs ファインチューニング：どちらを使うべきか（結論）

知識が頻繁に変わる、あるいは回答に引用が必要な場合はRAGを選んでください。一貫した出力形式と低いレイテンシが必要で、数百件の教師あり例を持っている場合はファインチューニングを選んでください。デプロイが成熟したら両方を使います。RAGはモデルが読むコンテキストを書き換え、ファインチューニングはモデルそのものを書き換えます。ほとんどのチームが必要としているのは前者であって後者ではありません。

一言でまとめるなら：RAGはモデルが「読むもの」を変え、ファインチューニングはモデルの「あり方」を変えます。あなたのタスクが実際に必要としているのはどちらかで判断してください。

NVIDIAのRAG用語集は検索側の定義をきれいにまとめています。教科書的な定義が欲しい場合はそちらをどうぞ。ただし、定義はアーキテクチャを選んでくれません。選んでくれるのはエビデンスです。そこから始めましょう。

エビデンスは何を示しているのか？同一タスクで両方を実測

このクエリでGoogle上位5位に入っている中で、同一タスクで測定した比較はBalaguerら（2024年）だけです。被引用数162回のMicrosoft Researchの研究です。同チームは農業QAタスクをRAGパイプライン、ファインチューニング済みモデル、そして両者のハイブリッドの3構成で実行し、GPT-4に回答を採点させました。そのセットアップではファインチューニング単独がRAG単独をわずかに上回り、両者の重ね掛けはどちらか単独よりも大きな差で勝ちました。

農業分野のケーススタディ（arXiv:2401.08406）

2024年1月にAngels Balaguerと15名の共著者によって投稿されたこの研究は、農家に地域固有のインサイトを提供するには何が必要かを問うています。同パイプラインはPDFから情報を抽出し、そこから質問と回答のペアを生成し、Llama2-13B、GPT-3.5、GPT-4を検索あり・なしで評価しました。

Balaguerらは、ファインチューニングにより精度が6パーセントポイント以上向上し、RAGとの累積が可能だったと報告しています。RAGはさらに5ポイントを上乗せしました。ハイブリッドパイプラインは単独のどちらよりも高い結果でした。同論文のTable 18はGPT-4の順位を示しています：支援なし75%、RAGあり80%、ファインチューニング後81%、ファインチューニング＋RAGで86%。80%と81%がどれほど近いか注目してください。RAG単独とファインチューニング単独の差はわずか1ポイントですが、ハイブリッドは両者を5ポイント引き離しています。ある実験では、ファインチューニング済みモデルが他地域の知識を活用して地域固有の質問に回答し、回答の類似度が47%から72%へ上昇しました。

コスト面のエビデンス

Snorkel AIの公開研究（2022年11月）はコスト面をカバーしています。100クラスの法律文書分類ベンチマーク（LEDGAR、契約条項80,000件）において、ファインチューニング済みRoBERTaモデルはファインチューニング済みGPT-3と同等の精度を達成しながら、サイズは1,400倍小さく、正解ラベルの使用量は1%未満、本番推論コストはファインチューニング済みGPT-3モデルの0.1%、つまり約1,000分の1でした。総構築コスト：プログラム的ラベリングで$1,915、手動アノテーション＋GPT-3ファインチューニングで$7,418。ただし注意点として、これは分類タスクであり生成QAではないため、比率は方向性の目安として扱ってください。

私たちの見解

私たちの解釈はこうです。あのセットアップはファインチューニングにとって最も有利なケースであり、それでも1ポイント差でしか勝ちませんでした。Balaguerらは固定のPDFコーパスで学習し、同じフリーズされたコーパスで評価したため、重みが学習した内容が実験中に古くなる可能性はゼロでした。本番のナレッジベースのほとんどは、そこまでじっとしていてくれません。先週のリリースに関する質問に答えるサポートボットは、再学習サイクルのたびに6ポイントを稼ぎ直す必要がありますが、RAGに供給するインデックスは同じ日の午後に更新できます。だからこそ、私たちは精度1ポイントの優位をこの判断で最も弱いインプットとみなし、鮮度を最も強いインプットとみなしています。エビデンスが一般化できない点：Snorkelの結果は分類ベンチマークであり、どちらの研究もトーンや形式の制御はテストしていません。これは依然としてファインチューニングの最も強い根拠です。

ファインチューニングが正解であるケースは、チームが考えているより少ないものです。「ファインチューニング」と言っているプロジェクトのほとんどは、実際には「検索」を意味しています。

RAGの仕組みと、RAGが勝つ条件

RAG（検索拡張生成）は、モデルが学習時に記憶したものではなく、あなたが管理するドキュメントから回答します。Lewisらによって2020年に提案され、知識がモデルの外側に存在するためにナレッジワークの既定の選択肢となりました。インデックスを更新すれば、再学習なしで翌日からすべての回答が変わります。

パイプラインは4ステップです：

1. 取り込み。 ドキュメント（PDF、Wiki、チケット）を解析してコーパスにします。
2. チャンク分割と埋め込み。 数百トークンのチャンクに分割し、埋め込みモデルで各チャンクをベクトルに変換します。
3. 検索。 クエリ時に類似度の高い上位K個のチャンクを見つけます。SKUやエラーコードのような完全一致文字列にはキーワード検索も併用します。
4. 拡張と生成。 それらのチャンクをプロンプトに詰め込み、LLMにソース付きで回答させます。

RAGは3つの軸で勝ちます：鮮度（再学習ではなく再インデックス）、引用（すべての回答が出典チャンクを指す）、データ制御（顧客データが学習に一切入らない）。フルの構築手順を知りたい方は、RAGアプリケーションの段階的構築ガイドをどうぞ。

検索品質に関する注意点が一つあります。パイプラインの品質は、埋め込みと検索の組み合わせの品質で決まります。AnthropicのContextual Retrievalは、素の構成でtop-20検索失敗率5.7%を測定し、コンテキスト付き埋め込み＋BM25で2.9%へ、リランカー追加で1.9%へ低下することを示しました。完全一致クエリが失敗し続けるなら、ハイブリッド検索（BM25 vs ベクトル）が解決策です。

ファインチューニングが勝つ場面（そしてPEFTとは？）

ファインチューニングが勝つのは、問題がモデルの「知識」ではなく「答え方」にあるときです。一貫した出力形式、ブランドトーン、あるいは検索の往復なしでレイテンシ予算が厳しい場合。また、小規模モデルの経済性を実現するレバーでもあります。前述のSnorkelの「GPT-3同等の品質をコスト0.1%で」という結果は、誰かが大きなモデルを提供する代わりに小さなモデルをファインチューニングしたからこそ存在します。

フルファインチューニング vs PEFT（LoRA / QLoRA）

フルファインチューニングはモデルのすべての重みを更新します。高価で遅く、大規模な研究機関以外では稀です。ほぼすべてのチームは代わりにPEFT（パラメータ効率の良いファインチューニング）を採用しています。LoRA（Huら、2021年）はベースの重みを固定し、小さな低ランクアダプターを学習します。通常はパラメータ数の0.1〜1%です。QLoRAはそこに4ビット量子化を加え、13BモデルがコンシューマーGPU 1枚に収まります。関連してもう一つ知っておくべき用語：連続事前学習（continuous pretraining）。モデルが教師ありファインチューニングの前に、生のドメインコーパスで教師なしの事前学習を続ける手法です。

Hugging Face PEFTドキュメントによる最小のLoRA設定：

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

データセット準備、エポック数、評価については、ファインチューニングの段階的ガイドを参照してください。

リスクは実在します。少量データセットでの過学習（数百件の例では学習ではなく暗記になる）、陳腐化（重みは学習カットオフ時点で知識を固定する）、そしてソース帰属の欠如（ファインチューニング済みモデルは領収書を見せられません）。この3つのいずれかが致命的なら、あなたは自分自身をRAGに説得し戻したところです。

RAG vs ファインチューニング vs プロンプトエンジニアリング：他の選択肢の位置づけ

この3つはライバルではなく階段です。プロンプトエンジニアリングは指示を変え、RAGはモデルが読むコンテキストを変え、ファインチューニングは重みを変えます。OpenAI自身のファインチューニングガイドは、ファインチューニングをループの最後に置いています。まず評価、次にプロンプト、プロンプトでは足りなくなったときだけ学習です。比較的新しい2つのオプションがツールキットを補完します。

一つ、明確にしておくべき混同があります。MCPサーバーやエージェントフレームワークはオーケストレーションであって、カスタマイズではありません。これらはモデルがアクセスできるツールとソースを決めるもので、モデルの答え方を変えるものではありません。エージェントの中でRAGパイプラインを動かし、その下のモデルをファインチューニングすることも可能で、本番システムの多くは両方を行っています。オートコンプリート的な論争（「vs MCP」「vs エージェント」）はカテゴリエラーです。

RAGはファインチューニングより安いのか？実際のコストモデル

短く答えるなら：現実的なクエリ量では、イエスです。ファインチューニングの請求書は前払い（教師データ＋学習）で届き、RAGの請求書はクエリごと（埋め込み＋追加入力トークン）で届きます。OpenAIのファインチューニングドキュメントは学習をトークン単位で課金しますが、トークン代は教師あり例の人件費に比べればはした金です。以下が公開リスト価格での計算です。

損益分岐の問い：RAGの累積クエリ税がファインチューニング投資に等しくなるまで、何件のクエリが必要か？

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

月間50,000クエリなら10年以上です。ほとんどのプロダクトにとって、ファインチューニング投資はトークン節約だけでは回収できません。ファインチューニングは形式とレイテンシのために行うものであって、コストでRAGに勝つためではありません。この計算が逆転するのは、月間数百万クエリを超える場合か、検索コンテキストが非常に大きい場合です。そして非対称性に注目してください。ファインチューニングの請求書はデータドリフトによる再学習のたびに更新されますが、RAGは量×チャンクサイズに線形にスケールします。クエリごとの支出が本当の懸念なら、まずクエリあたりLLMコストの削減から始めてください。それでも学習の道を選ぶなら、小切手を切る前にファインチューニングツールを比較してください。

鮮度に関する補足：2026年7月時点で、OpenAIのファインチューニングドキュメントは、ホステッドプラットフォームが新規ユーザー向けに縮小中であり、既存ユーザーは今後数か月の学習アクセスを維持すると記載しています。これはチームがオープンモデルのPEFTや素のRAGに傾くもう一つの理由です。

選択前に確認すべき5つのチェック

学習コードを書く前に、以下の5つのイエス・ノーチェックを実施してください。回答のパターンは、どのベンチマークよりも確実にRAG・ファインチューニング・ハイブリッドのいずれかを指し示します。正直に答えてから集計してください。

1. 知識は再学習できる速度より速く変わりますか？イエス → RAG。ドキュメント更新ごとの再学習は運用計画ではありません。
2. 数百件の教師あり例がありますか？ノー → RAGかプロンプトエンジニアリング。40件の例でのファインチューニングは学習ではなく暗記です。
3. 厳しいレイテンシ予算がありますか？シビア → ファインチューニング寄り。検索の往復を省くと50〜200ms節約できます。
4. 回答に引用や監査証跡が必要ですか？イエス → RAG。ファインチューニング済みモデルはソースチャンクを指し示せません。
5. チームにMLスキルと、学習用のGPUまたはAPI予算がありますか？ノー → RAG。再構築できるインデックスは、再学習できない重みに勝ります。

1、4、5がほぼイエス → RAG。安定したドメインで2と3がほぼイエス → ファインチューニング。回答が割れる、あるいは実トラフィックのある成熟プロダクト → ハイブリッド（次のセクション）。このチェックリストの目的は、今月あなたのフィードで流行している手法ではなく、エビデンスで決めることです。

RAGとファインチューニングは併用できるか？

できます。そして成熟したデプロイでは、ハイブリッドパターンは例外ではなく標準です。ドメインの流暢さと出力形式のためにファインチューニングし（「どう答えるか」）、推論時のファクトのために検索します（「何を答えるか」）。Balaguerらは農業タスクでまさにこれを報告しています。ハイブリッドパイプラインは単独のどちらよりも高く、RAGの5ポイント上昇がファインチューニングの6ポイントの上に積み重なりました。

私たちが推奨する成熟への道筋：プロンプトエンジニアリングから始め、回答に非公開データや最新データが必要になった時点でRAGを加え、形式の不一致やレイテンシが本番で痛み始めてから初めてファインチューニングを加えてください。いきなりファインチューニングに飛ぶと、検索がすでに問題を解決しているかどうかわかる前に学習コストを支払うことになります。

ハイブリッドパターンは妥協ではありません。成熟したデプロイでは既定の選択肢です。形式のためにファインチューニングし、ファクトのために検索する。

採用候補をどう評価するか？

勝者の選び方はデータベースの選び方と同じです。バイブではなく、あなたのワークロードで測定してください。レシピは1段落に収まり、実際に意思決定を左右する4つの数字をカバーします。

• ホールドアウト質問セット。 実際のユーザー質問100〜300件。合成質問は不可、学習やインデックス作成時に見たものも絶対に不可。
• Faithfulnessと回答の正確さ。 Faithfulnessは回答が検索コンテキストに根拠づいているかを問い、回答の正確さは実際に正しいかを問います。RAGASが普及させたこのペアは、ハルシネーションと検索ミスの両方を捕捉します。
• p95レイテンシ（平均ではなく）。検索は往復を加えます。テールを測定してください。
• 1,000クエリあたりコスト（トークン＋インフラ）。推測ではなく実測。
• ドリフト時に再実行。 新しいドキュメント、新しいモデルスナップショット、新しい四半期：セットを再実行してください。

ツールを含む指標の詳細な内訳は、LLM評価ガイドにあります。

著者について

Mert BaturはTechsy.ioの共同創業者です。同社ではB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを提供しています。Techsyチームが実際に本番で使っているLLMツールスタックについて執筆しています。LinkedInでつながってください。

よくある質問

RAGとファインチューニングは併用できますか？

できます。出力形式とドメインの流暢さのためにファインチューニングし、推論時のファクトのために検索を維持してください。Balaguerらは農業QAタスクでこのハイブリッドを測定し、単独のどちらよりも高い結果で、精度向上が積み重なることを確認しました。成熟した本番システムのほとんどはここに落ち着きます。「どう答えるか」は重み、「何を答えるか」は検索です。

ファインチューニングを使うべきでないのはどんなときですか？

知識が再学習速度より速く変わる場合、教師あり例が数百件未満の場合、回答に引用や監査証跡が必要な場合、あるいはデータドリフト時の再学習予算がない場合は、ファインチューニングをスキップしてください。この4つの条件はアーリーステージのプロダクトのほとんどに当てはまります。だからこそ、最初の一手は通常RAGが正解です。

ファインチューニングは廃れましたか？

いいえ。ただし領土は縮小しました。長いコンテキストウィンドウと安価なRAGが、2023年にはファインチューニングを必要としていたユースケースを吸収しました。残っているものは本物です。厳密な出力形式、ブランドトーン、検索往復なしのレイテンシ予算、そして小規模モデルの経済性です。問題がモデルの「知識」ではなく「答え方」にあるなら、ファインチューニングは今も有効なツールです。

RAGとファインチューニングの使い分けは？

回答が非公開知識や頻繁に更新される知識に依存する場合、あるいは引用が必要な場合はRAGを使ってください。一貫した形式・トーン・レイテンシが必要で、十分な教師あり例がある場合はファインチューニングを使ってください。プロダクトが成熟したら両方を使ってください。迷ったらRAGから始めてください。学習実行よりも元に戻すのが安いです。

RAGはファインチューニングより安いですか？

前払いでは、イエスです。RAGのコストはクエリごと（埋め込み＋追加入力トークン）ですが、ファインチューニングは学習と教師データに一度課金され、その後は再学習のたびに更新されます。公開リスト価格では、私たちの試算例で損益分岐点が約640万クエリにあり、典型的なクエリ量ではプロダクトの寿命を通じてRAGの方が安く済みます。

ハルシネーション対策にはRAGの方が有効ですか？

多くの場合有効ですが、無料ではありません。RAGは回答を検索チャンクに根拠づけるため、ソースの引用と失敗の監査が可能です。ただし、悪い検索は回答を汚染します。Anthropicは素の構成でtop-20検索失敗率5.7%を測定し、コンテキスト付き検索＋リランキングで1.9%まで削減しました。一方、ファインチューニングはエラーを追跡不能な形で重みに焼き込む可能性があります。

RAG・ファインチューニング・プロンプトエンジニアリングの違いは？

プロンプトエンジニアリングは送る指示を変えます。RAGはモデルがクエリ時に読むコンテキストを変えます。ファインチューニングはモデルの重みを変えます。それぞれが前者より大きな介入です。まずプロンプトを試み、知識がボトルネックになったら検索を加え、形式・トーン・レイテンシがまだ痛いときだけ学習してください。

RAGとファインチューニングの性能はどう評価しますか？

実際のユーザー質問100〜300件のホールドアウトセットを構築し、両方のアプローチを採点してください。Faithfulness（根拠づいているか）、回答の正確さ（正しいか）、p95レイテンシ、1,000クエリあたりコストです。ドキュメントやモデルスナップショットが変わるたびにセットを再実行してください。合成質問は両方のシステムを良く見せるだけです。実際の質問だけが両者を分けます。

未知の知識へのマルチホップ質問にはどちらが向きますか？

RAGです。ただし、より良い検索とセットで。この結論は仕組みが決めています。ファインチューニング済みモデルは重みが吸収したものについてしか推論できないため、一度も見ていない知識は、どれだけ上手に学習しても到達不能です。検索はクエリ時に欠けたピースを手渡します。落とし穴は、検索1パスですべてのホップを集められることは稀だという点です。そのため、単発の上位K件検索ではなく、クエリ分解や反復検索＋リランカーを計画してください。

まとめ

曖昧さを排した要約です：

• RAGは、変わる知識と引用付き回答のための既定の選択肢です。ファインチューニングは形式・トーン・レイテンシのスペシャリストです。
• 同一タスクのエビデンス（Balaguerら）はファインチューニングに+6ポイント、RAGにさらに+5ポイントを与え、ハイブリッドが3者中最良でした。私たちの「RAGから始めよ」という助言はそのスコアボードではなく、鮮度・引用・コストに基づいています。
• コスト計算は現実的なクエリ量でRAG有利に着地します。私たちの試算例では損益分岐点は約640万クエリでした。
• 習慣ではなく、5つのチェックで決めてください。

RAGを選びましたか？パイプライン周辺のスタックについては、RAGツールランキングを参照してください。