TL;DR ( 忙しい人のための3行まとめ )
- RAG ( 検索拡張生成 ) は「教科書を持ち込んで試験を受ける」こと。最新情報や事実確認に強い。
- Fine-tuning ( ファインチューニング ) は「猛勉強して脳の構造を変える」こと。口調、形式、専門的な推論パターンの固定に強い。
- 「自社データを覚えさせたい」なら、まずは RAG から始めるのが鉄則。いきなり
Fine-tuningは事故の元。
Introduction
「 ChatGPT に社内マニュアルを全部覚えさせたいから、ファインチューニングしようと思うんだけど」
もしあなたの同僚がこう言ったら、全力で止めてください。これは、生成AI導入における 最も古典的かつ致命的な勘違い です。
多くのエンジニアやPMが「知識の注入」＝「学習 ( Training )」と考えがちですが、LLM ( 大規模言語モデル ) においてそれは効率的ではありません。
2025年現在、知識の参照には RAG、振る舞いの矯正には Fine-tuning、そしてその両者を組み合わせる Hybrid アプローチが主流です。
本記事では、両者の決定的な違いをエンジニアリング視点で解剖し、あなたのプロジェクトがどちらを選ぶべきかの「明確な判断基準」を提示します。
Comparison: The Chef Metaphor ( 料理人の比喩 )
技術的な詳細に入る前に、直感的な比喩で両者を理解しましょう。
ここに「優秀なフランス料理のシェフ ( = Pre-trained LLM )」がいます。
1. RAG ( Retrieval-Augmented Generation )
シェフに「和食のレシピ本」を渡すアプローチです。
- 動作: シェフは注文が入るたびにレシピ本 ( 外部DB ) をパラパラとめくり、そこに書かれた通りに調理します。
- メリット: レシピ本を差し替えれば、明日からイタリアンも作れます。最新の流行メニューにも即座に対応可能です。
- デメリット: いちいち本を読む時間がかかります ( レイテンシ増 )。
2. Fine-tuning
シェフを「和食の専門学校」に送り込み、数ヶ月間再教育するアプローチです。
- 動作: シェフは何も見ずに、体得した技術で完璧な天ぷらを揚げます。
- メリット: 動作が速く、和食特有の「阿吽の呼吸」や「盛り付けの作法」まで完璧に身につきます。
- デメリット: 専門学校に通う費用 ( コスト ) が莫大です。また、メニューが変わるたびに再教育が必要です。
Detailed Breakdown ( 詳細比較 )
エンジニアが気にするべき4つの軸で比較します。
| 比較軸 | RAG ( 外部知識参照 ) | Fine-tuning ( 追加学習 ) |
|---|---|---|
| 知識の更新 | 容易 ( データを足すだけ ) | 困難 ( 再学習が必要 ) |
| ハルシネーション | 抑制しやすい ( 根拠を提示可能 ) | 依然としてリスクあり ( 記憶違いを起こす ) |
| 得意タスク | 具体的な事実検索、最新情報の回答 | 口調の統一、特定フォーマット ( JSON等 ) の出力、独特な推論 |
| 初期コスト | 低 ( ベクトルDB構築のみ ) | 高 ( データセット作成 + GPUコスト ) |
| ランニングコスト | 高 ( 入力トークンが増えるため ) | 低 ( プロンプトが短くて済む ) |
💡 意外な落とし穴：コストの逆転現象
「RAGの方が安い」と一般に言われますが、大規模運用時は注意が必要です。
RAG は毎回大量のドキュメントをプロンプトに含めるため、入力トークン課金 が嵩みます。一方、Fine-tuning 済みのモデルは「質問」だけで答えられるため、トークン消費は最小限です。
月間数百万リクエストを超えるようなケースでは、Fine-tuning の方がトータルコストが安くなる分岐点が存在します。
Use Cases ( ケース別判断フロー )
どちらを採用すべきか迷ったときは、以下のフローチャートに従ってください。
Case 1: RAG を選ぶべきシーン
- 情報の鮮度が命: ニュース、株価、社内の日報、製品在庫など、分単位・日単位で変わる情報。
- 根拠の提示が必要: 「マニュアルの〇ページに書いてあります」という引用が必要な場合。
- データ量が膨大: 数GB〜TB級のドキュメントは、学習データに収まりきりません。
Case 2: Fine-tuning を選ぶべきシーン
- 特定の「キャラ」になりきらせたい: 語尾が「〜だにゃ」の猫型bot、特定の作家風の文章生成など。
-
複雑な出力形式の厳守: 特殊な
JSONスキーマや、独自のプログラミング言語を出力させたい場合。 - プロンプトエンジニアリングの限界: 長すぎる指示 ( System Prompt ) を短縮し、レイテンシを下げたい場合。
Implementation Focus: Data Preparation
前回の記事で RAG の実装は紹介したので、ここでは Fine-tuning の難しさ を実感してもらうために、必要なデータ形式の違いを解説します。
RAG の場合：ドキュメントを突っ込むだけ
PDF や Markdown をそのまま読ませれば、ライブラリが勝手に分割・ベクトル化してくれます。
# RAGならこれだけ
loader = PyPDFLoader("manual.pdf")
documents = loader.load()
# あとはVectorDBに入れるだけ...
Fine-tuning の場合：高品質な Q&A ペアの量産が必要
OpenAI の gpt-4o-mini 等をファインチューニングする場合、以下のような JSONL 形式のデータを 数百〜数千件 用意する必要があります。
単なるテキストではなく、「理想的な会話例」を作成する工数は甚大です。
{"messages": [{"role": "system", "content": "あなたは弊社のカスタマーサポートAIです。"}, {"role": "user", "content": "返品はできますか？"}, {"role": "assistant", "content": "はい、商品到着後30日以内であれば、未使用品に限り返品を承っております。手続きはマイページから可能です。"}]}
{"messages": [{"role": "system", "content": "あなたは弊社のカスタマーサポートAIです。"}, {"role": "user", "content": "ログインできません。"}, {"role": "assistant", "content": "ご不便をおかけし申し訳ございません。パスワードの再設定はお済みでしょうか？ こちらのリンクから..."}]}
... (これをあと500個作成)
この「データ作成コスト ( Data Curation Cost )」こそが、Fine-tuning 最大の壁です。ゴミデータで学習させると、モデルの性能はベースモデルより悪化します ( これを Model Collapse と呼びます )。
Conclusion
結論：「まずは RAG、必要なら Hybrid」
2025年の開発現場における定石は以下の通りです。
- まず RAG でシステムを構築する ( 9割のユースケースはこれで解決します )。
- プロンプトだけでは回答の口調や形式が安定しない場合、あるいはコスト削減が必要な段階で、軽量モデルの Fine-tuning を検討する。
- 最終的に、Fine-tuning したモデルで RAG を行う Hybrid 構成にする。
「覚えさせる」のではなく「探させる」。このパラダイムシフトを受け入れることが、成功への第一歩です。
References
⚠️ 本記事に関する注意
- 本記事は執筆時点の情報に基づき作成しています。
- AI 技術は発展が速いため、仕様や挙動が変更される可能性があります。