ファインチューニングとRAGの使い分け｜LLMをカスタマイズする2つの道の選び方

LLMを自社の業務に寄せたいと考えたとき、多くの人が最初に思い浮かべるのが「ファインチューニング(追加学習)」です。しかし実務では、ファインチューニングにたどり着く前に検討すべき選択肢があり、そもそもRAG(外部知識を検索して与える方式)とファインチューニングは解決する問題が異なります。この記事では、両者が何をするものかを公式ドキュメントで確認したうえで、どちらをどんな場面で選ぶか、そして両方を組み合わせる現実的な設計までを整理します。結論を先に言えば、多くの場合はまず安い方法から試し、必要な部分だけ重い方法に進むのが堅実です。

LLMを自社用途に寄せる3つの階層#

まず全体像を押さえます。汎用のLLMを自分たちの用途に近づける手段は、大きく3つの階層に分けて考えると整理しやすくなります。手前の階層ほど手軽で安く、奥に進むほど効果は大きい一方でコストと運用負荷が増えます。

1つ目はプロンプト設計とfew-shot、つまり指示文の工夫や数個の例示、コンテキストへの情報付与です。コードもモデルも触らずに始められ、最も安く速く試せます。2つ目がRAGで、外部の知識ベースから関連情報を検索し、その内容をプロンプトに付け足してから回答させます。3つ目がファインチューニングで、モデルの重み自体を追加のデータで学習させ、振る舞いそのものを変えます。

RAGとファインチューニングは何をするものか#

同じ「カスタマイズ」でも、RAGとファインチューニングは解決する問題が違います。ここを取り違えると、向かない手段に労力を注いでしまいます。それぞれが何をするものかを、公式ドキュメントの説明に沿って確認します。

RAG(検索して与える)#

RAGは、質問に関連する情報を知識ベースから検索し、その内容をプロンプトに付け加えてからモデルに回答させる方式です。Google CloudのRAG Engineの解説でも、私的な情報でLLMのコンテキストを補うことで、モデルがより正確に答え、ハルシネーションを減らせると位置づけられています。モデルの重みは変えず、渡す情報を差し替えることで挙動を変えるのが特徴です。知識を更新したいときは、モデルを学習し直すのではなく、知識ベースの中身を入れ替えれば済みます。

一方でRAGの品質は、検索がどれだけ的確に関連情報を引けるか、文書をどう分割(チャンク化)するかに大きく左右されます。Anthropicは、素朴なチャンク化では各断片が元の文脈を失い、必要な情報を検索できなくなる問題を指摘し、各断片に対して、その断片が文書全体の中でどう位置づくかを説明する短い文脈情報(チャンク固有の説明)を付与してから埋め込み・索引化するContextual Retrievalという手法を紹介しています。RAGは「入れれば効く」ものではなく、検索設計そのものが品質を決めます。

ファインチューニング(重みを追加学習)#

ファインチューニングは、目的のタスクに沿った入出力の例を集め、そのデータでモデルを追加学習させて振る舞いを固定する方式です。OpenAIの教師ありファインチューニングの解説でも、期待する応答の例を集めて学習させることで、プロンプトに毎回長い指示や多数の例を入れなくても、望む形式や文体で応答するようモデルを寄せられる、という位置づけが示されています。Google CloudのチューニングのドキュメントやOpenAIのベストプラクティスでも、プロンプトだけでは安定しない挙動を固定したい場合の手段として説明されています。

使い分けの原則#

両者の性質が分かると、選び方の軸が見えてきます。判断の中心になるのは「扱う情報が変動するか」と「固定したいのは知識か振る舞いか」の2点です。

変動する知識、最新情報、そして回答の根拠(出典)を示す必要がある用途は、一般にRAGが向きます。社内規程や商品カタログ、サポート履歴のように更新が入る情報を扱い、どの文書に基づいて答えたかを提示したい場合です。知識ベースを差し替えれば内容を更新でき、参照元をたどれるのが強みです。

これに対して、安定した振る舞い、決まった出力形式、特定の文体や専門表現を毎回ぶれずに再現したい用途は、ファインチューニングが向きます。たとえば決まったJSON形式で必ず返す、自社のトーンで文章を書く、特定の分類ルールで判定する、といった「型」を固定したい場合です。プロンプトでも近づけられますが、指示が長大になりがちで、それでもぶれる部分をファインチューニングで安定させる、という使い方になります。

コストとトラフィックの観点#

コストの観点でも、両者の損益分岐は用途によって変わります。ここは一般論として押さえ、具体的な金額は変動前提で各社の最新の料金を確認してください。

RAGは、検索した文書をプロンプトに毎回付け足すため、1回あたりの入力トークンが増えがちです。低〜中トラフィックであれば、初期構築が比較的軽く、知識の更新も容易なRAGが扱いやすい傾向があります。一方、大量のリクエストを低レイテンシで安定してさばく必要がある用途では、毎回長いコンテキストを渡すRAGのトークン負荷が積み重なります。この場合、振る舞いを学習させたファインチューニング済みの小型モデルなら、短いプロンプトで済み、1リクエストの単価やレイテンシで有利になり得ます。

RAGとファインチューニングを組み合わせる#

実務では「どちらか一方」ではなく、両方を組み合わせる構成が有効な場面が多くあります。役割が違うので、競合ではなく補完関係として設計できます。

この順序なら、重い手段に進む前に安い手段で解決できないかを毎回確かめられ、投資が無駄になりにくくなります。RAGで知識の鮮度を保ちつつ、ファインチューニングで振る舞いを安定させる組み合わせは、両者の弱点を補い合う構成として理にかなっています。

見落としがちな落とし穴#

最後に、どちらの手段でもつまずきやすい点を整理します。事前に知っておくと、期待値のずれを避けられます。

ファインチューニングは、知識の最新化には向きません。学習した時点の内容で固定されるため、頻繁に変わる情報を覚えさせる用途には不向きです。また、ハルシネーションを消す魔法でもありません。振る舞いを寄せることはできても、事実の誤りが原理的にゼロになるわけではなく、事実確認は別途必要です。そして品質はデータ品質に強く依存します。OpenAIのベストプラクティスでも、少数でも質の高い例から始め、評価を用意して効果を測ることが重要とされています。質の低い例を大量に学習させると、かえって挙動が乱れます。

RAGの落とし穴は、検索品質とチャンク設計に集約されます。関連文書を的確に引けなければ、いくら賢いモデルでも正しく答えられません。断片が文脈を失うと検索も回答も劣化するため、分割の仕方や検索方式の工夫が要ります。どちらの手段も、評価(eval)を用意して効果を数値で測る前提を欠くと、良くなったのか悪くなったのかが分からないまま運用してしまいます。

本記事のRAGおよびファインチューニングの定義と位置づけは、OpenAI(教師ありファインチューニング、ベストプラクティス)、Google Cloud(RAG Engine概要、チューニング入門)、Anthropic(Contextual Retrieval)の公式ドキュメントで確認できた範囲に基づく一般的な整理です。各社の機能名・対応モデル・料金・仕様は時点で変動します。導入前には必ず各サービスの公式の最新情報をご確認ください。

よくある質問#

まとめ#

ファインチューニングとRAGは、どちらが優れているかを競う関係ではなく、解決する問題が違う道具です。変わり続ける知識と出典はRAGに任せ、ぶれてほしくない振る舞いはファインチューニングで固める。そのうえで、まず安い手段から試し、効果を評価で確かめながら必要な範囲だけ重い手段に進む。この段取りを踏めば、宣伝文句や流行に流されず、自社の用途に本当に効くカスタマイズを、無理のないコストで積み上げられます。