ファインチューニング vs RAG：用途に応じてどちらを選ぶべきか ?

#なぜこの質問が繰り返し出てくるのか

Ollama をインストールし、7Bまたは14Bのモデルを選択しました。次に、そのモデルにあなたのドメインを「認識」させたいと考えています：社内ドキュメント、業界用語、判例の決定、サポートチケット。2つの道が開かれます——ファインチューニングまたはRAG——そしてコミュニティでは、これらが互換可能な代替手段であるかのように語られることが多いです。しかし、そうではありません。

落とし穴は、ファインチューニングには「本物のAI」というイメージがあり、モデルが専門家になると想像してしまうことです。RAGは間に合わせの仕組み、つまり自動化された「コピー＆ペースト」のように見えます。しかし、産業界の実態は逆です。RAGは企業での用途の80％で標準的な手法となっており、ファインチューニングは、RAGでは得られないものをもたらす特定の問題に限って使われています。

#2つのアプローチを1分で解説

#RAG（検索拡張生成、Retrieval-Augmented Generation）

RAGは、ドキュメント（PDF、Markdown、データベース、コード）をベクトルデータベース（Chroma、Qdrant、Weaviate）にインデックス化します。質問を受けると、システムは意味的な類似性に基づいて関連する箇所を検索し、プロンプトに組み込みます。LLMはそれらをもとに回答を生成します。モデル自体は汎用のままで、コンテキストが専門化されます。

どのような変更が生じるか

モデルはあなたのデータを引用し、回答のソースを示し、トレーニング時に得られなかった知識にアクセスできます。

変化しない点

回答のスタイル、トーン、特定のフォーマットで論理的思考を行う能力、非常に専門的な技術用語の使用。

ドキュメント追加の限界費用

数秒です。新しい文書をインデックスに登録するだけで済みます。

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

ファインチューニングでは、モデルに行わせたい処理を代表する入力と出力のペアからなるデータセットで、モデルを再学習します（LoRAを使う場合は重みの一部を再学習します）。知識と振る舞いは、モデルの重みに取り込まれます。

どのような変更が生じるか

デフォルトの動作：文体、出力形式、慣例、業務分野の専門用語の深い理解、暗黙の推論。

うまく変えられないこと

最新の事実情報へのアクセス — 3月にお使いの業務手順でファインチューニングしたモデルは、4月に作成された手順については何も知りません。

ドキュメント追加の限界費用

データセットに大きな更新があるたびに、新たに一通りの学習を実行します。

#意思決定マトリクス

「ケースバイケース」ではなく、実際に判断を分ける基準を、行ごとに示します。

頻繁に変化する事実に基づく知識

RAG。データセットが更新された時点で、ファインチューニングの内容は古くなります。製品ドキュメント、問い合わせチケットのデータベース、FAQ、判例はいずれもこのカテゴリに属します。

特定のスタイル、トーン、出力形式

ファインチューニング。プロンプトにどれだけ例を入れても、厳密なJSON形式、企業向けの文体、レポートの構成を定着させるために適切に作られた500組の学習データの代わりにはなりません。

極めて専門的な業界用語

ファインチューニングです。特に、事前学習でその言語が十分にカバーされていない場合（フランス語の法律用語、医療用語、方言など）に適しています。モデルがそもそも用語を理解していない場合、RAGだけでは不十分です。

トレーサビリティとソースの引用

RAG。"文書 X の Y 段落に基づいて"と表示できます。ファインチューニングされたモデルでは、主張の出所を証明することは不可能です。

共有RAMに一切置けない、極めて機密性の高いデータ

重みをローカルに保存したファインチューニング。RAGではリクエストのたびに文章の該当箇所をコンテキストに入れる必要があるため、共有インフラでは問題になる可能性があります。

200ms未満で迅速な応答（チャットボット、インラインエージェント）

ファインチューニング。RAGでは検索に100〜500ミリ秒がかかり、さらに長いコンテキストを処理する必要があります。リアルタイム性が重要な用途では、これが負担になります。

膨大な知識量（10万ページ超）

RAGです。10万件の文書でファインチューニングを行うのは現実的ではありません。仮に行ったとしても、モデルは細部についてハルシネーションを起こします。

高品質なトレーニングデータセットが利用可能

整備された入力・出力のペアが少なくとも500～1000組なければ、ファインチューニングは改善につながるよりも、モデルを劣化させる結果になりがちです。まずはRAGから始めてください。

#5つの典型的な使用例

#1. 製品ドキュメントに基づくサポート用チャットボット

判定

迷わず RAG です。

なぜ

ドキュメントは絶えず変わります（新機能、修正、非推奨化）。ファインチューニングしたモデルは3週間で古くなってしまうでしょう。また、顧客が求めているのは、根拠の分からない断言ではなく、出典を示した回答（「マニュアルの X 節を参照」）です。

典型的なスタック

Ollama（8 GBに収めるならQwen 3.5 9B、16 GBでより洗練されたフランス語を求めるならMistral Small 24B）+ Qdrant/Chroma + nomic-embed-text + Open WebUIまたはAnythingLLM。

#2. 構造化情報抽出機能（請求書、履歴書、契約書）

判定

ファインチューニング、またはJSONモードを使った高度なプロンプト設計。

なぜ

出力形式は毎回厳密に同じでなければなりません（同じフィールド、同じ型、同じデフォルト値）。よく書かれたプロンプトでも5%のケースでは形式がずれ、それによってパイプラインが破綻します。アノテーション付きの800件の例で学習させたLoRAなら、この問題を根本的に解決できます。

典型的なスタック

UnslothまたはAxolotlで学習し、GGUF形式でエクスポートして、Ollamaでデプロイします。文書の種類に関する「知識」ベースが変化する場合は、軽量なRAGと組み合わせることもできます。

#3. フランスの判例に基づく法務アシスタント

判定

ハイブリッド — RAGをまず実施し、語彙が不足している場合はその後でファインチューニングを行う。

なぜ

判例コーパスは膨大で、毎月変化します（最新の判決を反映するには RAG が必須です）。しかし、ほとんどのオープンウェイトモデルでは、フランス語の法律用語が十分にカバーされていません。そこで、軽量なファインチューニング（法律に関する質問・回答の例2,000〜3,000件を使った LoRA）を行うと、RAG が働く前の段階で用語の理解が大幅に向上します。

典型的なスタック

情報源としてLégifrance/Doctrine → Qdrant + BGEリランカー → フランス語の法律用語でLoRAファインチューニングした14BのLLM。

#4. 内部コードベースに適したコード生成ツール

判定

RAG（リポジトリ内のファイルの読み込み）を使い、非常に特殊なケースを除いてファインチューニングは行わない。

なぜ

コードベースは日々変化します。ファインチューニングしたモデルは、スプリントのたびに古くなってしまいます。最も優れたコーディングアシスタント（Continue.dev、Aider）は、ASTまたはコードの埋め込みを使うRAGを通じて、関連ファイルを動的に読み込みます。

典型的なスタック

Continue.dev + Qwen3-Coder 30B-A3B（qwen3-coder:30b、MoE、コンテキスト長 256k、アクティブなパラメータが 3B なので高速）、または Ollama 経由の Devstral 24B。検索機能はプラグインに組み込まれています。

#5. 自社独自の文章スタイル（ニュースレター、レポート、商品紹介ページ）

判定

純粋なファインチューニングです

なぜ

コンテンツは毎回新しく作るため、「検索して取り出す」ものはありません。それでも、トーン、構成、文のリズム、読者への呼びかけに使う「vous」、小見出しの使い方は、すべて一貫している必要があります。こうした特徴をうまく学習させられるのが、まさにファインチューニングです。

典型的なスタック

200〜500本の質の高い記事 → AlpacaまたはChatML形式 → UnslothでQwen 3.5 9BをQLoRAでファインチューニング → GGUFにエクスポートし、補足のシステムプロンプトを含むOllamaのModelfileを作成。

#両方のアプローチにおける隠れたコスト

公開されている比較は、しばしば「4時間の学習に使うGPUの費用」だけにとどまります。実際の運用は、どちらの方式でももっと厳しいものです。

#RAGの隠れたコスト

チャンキングの品質

文書の分割方法がすべてを左右します。分割が不適切だと、検索で文脈を欠いた断片が返され、LLMがハルシネーションを起こし、その理由も誰にも分かりません。「PDFをChromaに入れるだけ」で済むことはまれです。多くの場合はセクション単位の分割が必要で、スキャン文書ではOCRによる前処理が必要になることもあります。

累積遅延

クエリの埋め込み＋ベクトル検索＋（任意）リランカー＋LLM に渡すコンテキストの増加。最適化が不十分な環境では、処理時間が 400 ms（LLM 単体）から 2〜3 秒（RAG 全体）に延びることがあります。設計段階から、この遅延を見込んでおく必要があります。

データベースの保守

文書が削除されたらインデックスからも削除し、更新されたら再インデックスする必要があります。外部ソース（ウェブ、API）には、更新用のジョブを用意すること。システムが変化し続けるほど、作業も増えます。

埋め込みモデルの品質

フランス語では、デフォルトの埋め込みモデル（text-embedding-ada系）の性能は今ひとつです。nomic-embed-text、BGE-M3、Solonを使うと差が出ますが、そのためには選択肢を知っておく必要があります。

#ファインチューニングの隠れたコスト

データセットの準備

これが作業全体の80％を占めます。データを収集し、クリーニングし、指示／回答のペアに整形し、重複を除去し、クラスのバランスを調整すること。4週間のファインチューニングプロジェクトなら、データ準備に3週間、学習に1週間を見込んでください。

性能低下のリスク

調整が不適切なファインチューニングは、モデルの汎用的な能力を低下させます（「破滅的忘却」、catastrophic forgetting）。モデルは対象のタスクには強くなる一方、それ以外ではまったく役に立たなくなります。ファインチューニングの前後に、汎用ベンチマークでテストする必要があります。

各バージョンごとに再トレーニング

データセットは時間が経つにつれて拡充されます。各リリースでは GPU で 2〜12 時間の再実行、再検証、再デプロイが必要です。データセットとチェックポイントのバージョン管理は必須となっています

トレーニング用ハードウェア

7BモデルのQ4版で推論するには5GBのVRAMが必要ですが、学習には、QLoRAでも最低12～16GBが必要です。ファインチューニングを始めるためのハードウェア要件は、推論よりも高くなります。

#ハイブリッドアプローチ：RAG + ファインチューニング

最も効果的なアーキテクチャは、どちらか一方を選ぶのではなく、両者を組み合わせます。ファインチューニングは、モデルが利用者の専門分野についてどのように語るかを定め、RAGは、その時点でモデルが知っておくべき情報にアクセスできるようにします。

スタイルと形式に合わせてファインチューニングする

200〜1,000件の例によって、文体（企業向け、技術系、法律系）、回答形式（JSON、構造化されたMarkdown）、そして回答の姿勢（必ず出典を示し、決して情報を捏造しない）を定着させます。

事実ベースの知識に対するRAG（Retrieval-Augmented Generation）

ドキュメント、チケットのデータベース、判例、コードベースなど、内容が変化し、検索して見つけられ、引用もできる必要がある情報すべて。

システムプロンプト内のガードレール

システムプロンプトで、RAGのコンテキストが空か矛盾している場合は回答を拒否するようモデルに念押しします。ハルシネーションを抑えるために不可欠です。

#3つの質問で迅速な判断

1. 01
   質問 1 — データは月に一度以上変更されますか？

   はいの場合は、RAGが必須です。ファインチューニングでそのペースに追いつこうとすると、運用が悪夢のように困難になります。
2. 02
   質問2 — 人間が確認した質の高い入力／出力ペアが、少なくとも500組ありますか？

   そうでない場合は、まずRAGから始めてください。間に合わせで作った100件の例でファインチューニングすると、モデルの性能が低下します。例を蓄積していく予定なら、先にRAGを導入し、そのログを活用してデータセットを構築してください。
3. 03
   質問3 — 問題は「何かを知っていること」か、「特定の方法で回答すること」か？

   知識の取得 → RAG。特定の方式で回答させる → ファインチューニング。両方 → ハイブリッド。これが最もシンプルな分類法であり、10 回中 9 回は正しいです。

#避けるべき一般的な誤り

"事実を学習するためのファインチューニング"

最もよくある間違いです。ファインチューニング済みモデルは知識ベースではありません。学習で見た例をもとに補間しますが、具体的な詳細（数値、日付、参照情報）については、RAGよりもはるかに多くハルシネーションを起こします。

10,000チャンクを超えるコーパスでの「リランカーなしのRAG」

ベクトル検索だけでは、多くの結果を拾えても、必ずしも関連性の高い結果を得られるとは限りません。上位20件にクロスエンコーダー型のリランカー（BGE、mxbai）を適用すると、品質が大きく変わります。追加の処理時間は50〜100msです。

RAGと長文コンテキストを混同する

「とりあえず文書を丸ごとプロンプトに入れよう」。有用な内容が8kトークンを超えると、品質が大幅に低下します（中央部分の情報が見落とされる「lost in the middle」）。一定の量を超えると、適切にチャンク分割されたRAGのほうが、単純に長いコンテキストへ詰め込む方法より優れています。

すでにアライメント済みのモデルを、アライメントされていないデータセットでファインチューニングする

「instruct」モデルを、プロンプトの構造が一致しない例でファインチューニングすると、アライメントが崩れ、モデルの挙動がおかしくなります。モデルのテンプレート（ChatML、Alpaca、Mistral、Llama-3 chat）には必ず従ってください。

判断するために公開ベンチマークを求める

一般的なベンチマークでは、ご自身の用途にRAGとファインチューニングのどちらが適しているかは分かりません。代表的な質問を30〜50問用意して内部評価を行い、本格運用に移る前に測定してください。

#さらに詳しく

決定後は、対応するガイドが実装の具体的な手順を説明し、注意点や最適化方法も含みます。

コードを書かずにRAGを実装

Open WebUIまたはAnythingLLMを使えば、Pythonのコードを書かずに数時間で文書を対象としたRAGを構築できます。本格運用に移行する前に、アプローチの妥当性を検証するのに役立ちます。

ローカルでのLoRA／QLoRAのファインチューニング

専用ガイドではUnsloth、データセットフォーマット、LoRAとQLoRAの選択、およびOllama用のGGUFエクスポートが取り上げられています。7BモデルにはRTX 3090が十分です。

既存のRAGを最適化

リランカー、BM25とベクトルのハイブリッド検索、チャンキング戦略——これら3つの要素が、RAGを「動作する」レベルから「本番環境対応」レベルへと引き上げます。