LLMをファインチューニングする方法【代わりにRAGやプロンプトを使うべきケース】
このガイドでは、LLMをファインチューニングする方法をステップごとに説明し、フルファインチューニングとLoRAおよびQLoRAを比較するとともに、モデルの出力を改善するうえでプロンプトやRAGのほうが適しているケースを紹介します。

大規模言語モデル(LLM)のファインチューニングとは、事前学習済みのLLMを小規模なタスク特化型データセットで追加学習し、プロンプトだけでは得られない出力を引き出すことです。
ファインチューニングでは、求める振る舞いを示す入力と出力のペアの例を集め、モデルの重みをそれに近づける学習パスを実行し、その結果を元のモデルの出力と比較して確認します。LoRAのようなパラメータ効率の高い手法を使えば、単一のGPUで実行できるほど低コストで済みます。
LLMの出力に満足できない場合は、まずプロンプトと検索拡張生成(RAG)を改善しましょう。ファインチューニングはLLMの振る舞いを変えるものです。最新の情報や独自の情報をLLMに使わせたい場合は、通常、プロンプトとRAGのほうが適しています。
この記事では、LLMをファインチューニングする手順、主なファインチューニング手法(LoRAとQLoRA)、そしてプロセスを失敗させかねない課題やミスについて、順を追って解説します。
LLMのファインチューニングとは何か、LLMの事前学習とどう違うのか
LLMの事前学習は、膨大なコーパスを使ってモデルの汎用的な言語能力をゼロから構築するものです。一方、LLMのファインチューニングは、事前学習済みのモデルを小規模なデータセットで特定の用途向けに調整するものです。
LLMの事前学習は、ベースモデルを生み出すための、リソースを大量に消費するフェーズです。モデルは幅広いテキストコーパスから学習し、一般的な文法、事実、推論能力を身につけますが、特定のタスクに特化しているわけではありません。
LLMのファインチューニングでは、厳選された小規模なデータセットでベースモデルの学習を継続し、特定のタスクやユースケースで望ましい出力を生成できるようにします。たとえば、一貫したフォーマット、ブランドらしい語り口やトーン、ドメイン固有のパターン、確実なツール呼び出しや関数呼び出しなどです。
LLMをファインチューニングすべきとき、代わりにプロンプトやRAGを使うべきとき
LLMのパフォーマンスを向上させるには、プロンプト -> RAG -> ファインチューニングの順に段階を踏んでいきましょう。
より詳細な指示でプロンプトを改善し、RAGを使って最新の情報をモデルに与えましょう。ファインチューニングは、プロンプトと検索の改善で成果が出ない場合にのみ使用します。
アプローチ | 変わるもの | 適したケース | 主な制約 |
プロンプトエンジニアリング | 送信するリクエスト | 振る舞いが理想に近く、スピードと元に戻しやすさを重視したい場合 | ベースモデルが持つ既存の能力が上限になる |
RAG | 推論時にモデルが参照する情報 | 事実が頻繁に変わり、LLMに最新の情報を参照させる必要がある場合 | 検索によるレイテンシとインフラが追加される。振る舞いは変わらない |
LLMのファインチューニング | モデルの重み(モデル内部のパラメータ) | 大規模な運用で一貫した振る舞い、フォーマット、トーンが必要な場合、またはすべての呼び出しでプロンプトを短くしたい場合 | 初期コストがかかる、重みに組み込まれた知識が古くなる、事前学習で獲得した振る舞いを忘れるリスクがある |
プロンプトの改善がファインチューニングに勝るとき、それだけでは不十分なとき
プロンプトの工夫は、最も手早く低コストな手段です。多くの場合、より正確で詳細なプロンプトによって、望みどおりに振る舞いを変えられます。
しかし、プロンプトが長くなると処理が遅くなってコストもかさみ、モデルが持つ既存の限界を超えることもできません。
プロンプトによる改善が限界に達している可能性を示すサイン:
- 新たなエッジケースで出力が崩れ続ける:たとえば、JSONが必要なのにモデルが文章で返したり、トーンが外れたりして、新しいケースが出るたびにプロンプトを修正している。
- システムプロンプトが肥大化し続ける:プロンプトが数百行から数千行に及び、管理が難しくなっている。
- 呼び出しのたびにコストがかかる:リクエストごとにプロンプトが再送信・再処理されるため、トークンコストとレイテンシが増えていく。
- 変更しても効果が出なくなる:新しい指示を加えても出力が改善しない。
それでも、まずは低コストなプロンプトレベルの対策を試しましょう。フューショット例でモデルにパターン(入力と出力のペア)を示す、プロンプトチェーンで難しいタスクを小さなステップに分割する、関数呼び出しのフックで正確な検索や計算を外部に任せる、といった方法があります。
モデルのファインチューニングよりもRAGが適しているとき
RAGはLLMが知っている内容を変え、LLMのファインチューニングはその振る舞いを変えます。足りないのが知識、特に頻繁に変わる知識や自社のドキュメントにある知識であれば、RAGが答えです。足りないのが振る舞いであれば、ファインチューニングしましょう。
ファインチューニングでもモデルの知識は変化しますが、取り込んだ事実は学習時点で固定されるため、変化の速い分野ではすぐに古くなってしまいます。また、情報はモデルの重みに組み込まれるため、その出典は記録されません。
検索レイヤーが使用するソースドキュメントを更新するほうが迅速かつ低コストで、使用した正確な出典を引用することもできます。そのため、根拠を示せる最新の情報が必要な場合に適しています。
RAGの欠点は何でしょうか? 構築と保守が必要なレイヤーが1つ増え、レイテンシも増加することです。
実際には、両方が必要になることも少なくありません。本番環境のシステムでは、ファインチューニング済みモデルとRAGを組み合わせ、前者には一貫した振る舞いを、後者には最新の事実の提供を担わせています。
ファインチューニングでよくある落とし穴、リスク、課題
ファインチューニングが適切な手段である場合でも、コストとリスクが伴います:
- コストと時間:クリーンで代表性のある学習データの収集・整理にも、学習用のコンピューティングにも多額の費用がかかります。
- 破滅的忘却:限られたデータセットで学習すると、モデルが汎用的なスキルを失い、新たな失敗パターンを抱え込んで、ベースモデルでは起こらなかったエラーを起こすことがあります。
- 過学習:データが少なすぎたり反復が多すぎたりすると、モデルはパターンを学習せずに学習例を丸暗記してしまうため、学習サンプルでは高い性能を示しても、実際の入力では性能が低くなります。
- 情報の鮮度低下:重みに組み込まれた知識はすぐに古くなるため、新しいデータで再学習する必要があります。
- 陳腐化:より強力なモデルがリリースされると、何も手を加えなくても自社のファインチューニング済みモデルを上回ることが多く、作業をやり直す必要が生じます。
- 評価と再現の難しさ:ファインチューニング済みモデルがベースモデルより優れていることを証明するのは困難です。また、同じ設定でGPU学習を2回実行しても、わずかに異なるモデルができることがあります。
- データガバナンス:独自データや機密データで学習すると、プライバシーやライセンスの問題が生じます。モデルが後になって学習データの断片を出力してしまう可能性もあります。
主なファインチューニング手法
LLMのファインチューニングの主な種類は、モデルをどの程度変更するかによって異なります。フルファインチューニングはモデル全体を再学習するのに対し、LoRAやQLoRAなどのパラメータ効率の高いファインチューニング(PEFT)手法は一部の重みのみを更新します。PEFT手法に必要なメモリはフルファインチューニングのごく一部で済み、適切に設定すれば同等の結果を得られます。
フルファインチューニングでは、モデルのすべての重みを更新します。最もコストがかかり、破滅的忘却のリスクも最も高くなります。振る舞いを大きく変える必要があり、それを支えるデータとコンピューティングリソースがある場合に限って使いましょう。
もう1つの選択肢が、パラメータ効率の高いファインチューニング(PEFT)です。これは、モデルの大部分を凍結し、少数のパラメータのみを学習する手法の総称です。ベースモデルはそのまま維持されるため、メモリ使用量がはるかに少なく、忘却も起こりにくくなります。
ランクが低い場合、PEFTの学習量はフルファインチューニングに及びませんが、ランクを上げて学習率を調整すれば、インストラクションチューニングのタスクではその差の大部分を埋められます。
PEFT手法には次のようなものがあります:
- LoRA(Low-Rank Adaptation):一般的な出発点となる手法です。元の重みを凍結し、追加した少数のアダプターパラメータ(多くの場合、全体の1%未満)のみを学習するため、コンシューマー向けGPU 1基で実行できます。
- QLoRA(Quantized Low-Rank Adaptation):LoRAを適用する前にベースモデルを4ビット精度に圧縮する手法で、単一のGPUで大規模モデルをファインチューニングできます。
手法 | 更新対象 | 必要なハードウェア | 適したケース |
フルファインチューニング | モデルのすべての重み | 7Bクラスのモデルで1台のマルチGPUノード、それより大きなモデルではさらに多くのリソースが必要 | 振る舞いを大きく変える必要があり、データとコンピューティングリソースがある場合 |
LoRA(PEFT) | 追加した少数のアダプターの重み | コンシューマー向けGPU 1基 | まず試すべき標準的な選択肢 |
QLoRA(PEFT) | 4ビットに圧縮したベースモデル上のLoRAアダプター | 非常に大規模なモデルでもGPU 1基で対応可能 | メモリが不足しているが、大規模なベースモデルを使いたい場合 |
これらに加えて、RLHF(Reinforcement Learning from Human Feedback:人間のフィードバックによる強化学習)から、Direct Preference Optimization(DPO)やOdds Ratio Preference Optimization(ORPO)などの軽量な代替手法まで、インストラクションチューニングや選好チューニングの手法を用いて、モデルの指示への従い方や人間の選好との整合性を調整します。
LLMをファインチューニングする手順
LLMのファインチューニングが適切だと判断したら、次のワークフローに沿って進めましょう。
ステップ1:タスクと成功の測定方法を定義する
LLMにどのような振る舞いを求めるのか、そしてそれが実現できたことをどう判断するのかを決めます。
ファインチューニング済みモデルに任せたい具体的な作業を明確にします。たとえば、サポートチケットの分類、決まったフォーマットでの契約書の要約、自社のスタイルに沿ったコード生成などです。
次に、成功の基準を定義します。一般的な選択肢には次のようなものがあります:
- 出力の妥当性:たとえば、結果が有効なJSONとして解析できるか、必要なMarkdown構造に合致しているか。
- 自動スコア:生成されたテキストを参照回答と比較するBLEUやROUGEなどの指標や、ラベル付きセットでのタスク精度を使用します。
- 人による評価:トーンや有用性など、スクリプトではうまく評価できない品質を対象とした、スコア形式または合否形式の評価基準。
- 難しい入力への信頼性:ベースモデルがつまずいた特殊な入力に対応できるか。
ステップ2:データセットを準備する
ファインチューニングの成否はデータの品質で決まります。そのため、適切なファインチューニング用データセットの収集に力を注ぎましょう。
データは、JSONL形式で指示と応答のペアとして整形します。各行には、入力(および必要なコンテキスト)と、返してほしい正確な出力を含めます。
たとえば、汎用的な指示データセットであるAlpaca-cleanedやDatabricksのDolly、あるいは77のインテントにラベル付けされた13,000件以上の実際のサポート問い合わせを含むタスク特化型のbanking77などの公開データセットを参考にしてください。
特定のタスクに絞る場合、クリーンで多様な例が数百から数千件あれば振る舞いを変えられます。ただし、例がエッジケースを含めて実際の本番環境の入力を反映しており、一貫した形式で整えられていることが条件です。
まだ入力と出力のペアがない場合は、サポートチケットとその最適な返信、ドキュメントとその要約など、手元にあるデータからセットを作成しましょう。
出力しかない場合は、より強力なモデルを使ってそれぞれの出力に対するもっともらしい入力を生成するか、少数のシードセットを手作業で作成し、より大規模な「教師」モデルで拡張したうえで、最良のペアを残します。
最後に、データを学習用、検証用、テスト用のセットに分割し、モデルがまだ見ていない例で測定できるようにします。
ステップ3:ベースモデルと手法を選ぶ
まずは、パラメータ数が30億~70億の小規模なオープンソースモデルと、LoRAやQLoRAなどのパラメータ効率の高いファインチューニング手法から始めましょう。
Llama、Mistral、Qwenなどのオープンなモデルファミリーは、自社でホストできる強力なベースとなり、PEFT手法を使えばハードウェアのハードルも低く抑えられます。QLoRAはベースモデルを4ビットに量子化するため、7Bモデルのファインチューニングに必要なのは16~24GBのコンシューマー向けGPUだけです。同じモデルをフルファインチューニングすると、その何倍ものメモリが必要になります。
ステップ4:学習のハイパーパラメータを設定する
主なLLMファインチューニングのパラメータと、推奨される初期値の範囲は次のとおりです:
- 学習率は、重みを更新する際の各ステップの大きさを制御します。Bidermanらによる2024年の研究では、LoRAの最適な学習率はフルファインチューニングのおよそ10倍で、フルファインチューニングの一般的な値が1e-5~5e-5であるのに対し、LoRAでは5e-5~5e-4であることがわかりました。この研究では、1e-5から5e-4までの範囲を探索し、安定して学習できる最も高い値を使うことを推奨しています。
- バッチサイズは、モデルが重みを1回更新するまでに学習するサンプル数です。GPUが1基の場合は、デバイスあたりのバッチを1~8と小さく設定し、勾配累積を使って実効バッチサイズを約16~64にします。
- エポック数は、モデルがデータセット全体を何回学習するかを表します。特定のタスクを実行するようにモデルをトレーニングする場合は1~3が目安ですが、LoRAではそれ以上必要になることがよくあります。
- LoRAランク(r)は、アダプターの容量、つまりどれだけ学習できるかを決めます。単純なタスクでは8~32から始め、難しいタスクでは引き上げます。前述のBidermanらによるLoRAの研究では、7Bモデルをコードでインストラクションチューニングした場合、フルファインチューニングに匹敵する性能を得るにはランク256が必要でしたが、数学ではランク64でもそれに近い結果が得られました。
- 最大シーケンス長は、トレーニングで処理される入力の最大長です。これを超える入力は切り捨てられるため、モデルのコンテキストウィンドウの範囲内で、最も長いサンプルをカバーできる値に設定します。
- ウォームアップとスケジュールは、トレーニングの過程で学習率をどのように引き上げ、変化させるかを制御します。短いウォームアップとコサイン減衰が一般的なデフォルトです。ただし、Parejaらによる小規模モデルの研究では、ウォームアップをなくしても最終スコアは低下しませんでした。
これらは固定の設定ではなく、スイープの出発点として扱ってください。
ステップ5:トレーニングして損失を監視する
トレーニング中は、トレーニング損失と検証損失の曲線を確認して、うまく機能しているかどうかを確かめます。
損失は、モデルの出力がサンプルからどれだけ離れているかを示す指標で、トレーニングが進むにつれて滑らかに低下するはずです。トレーニング損失は、モデルが学習するデータに対する損失です。検証損失は、ホールドアウトしたサンプルに対する損失です。
トレーニング損失と検証損失がともに低下していれば、モデルは汎化を学習しています。トレーニング損失が下がり続ける一方で検証損失が横ばいになったり上昇したりする場合、モデルはパターンを学習せず、トレーニングセットを暗記しています(過学習)。
ステップ6:評価してからデプロイする
トレーニング損失が低くても出力が正しいとは限らないため、ステップ1で設定した基準でファインチューニング済みモデルを評価します。
評価に合格したら、次の2つの方法でデプロイできます。
- ベースモデルの上にアダプターを載せて提供し、実行時に両方を読み込みます。この方法なら、アダプターを差し替えられます。
- アダプターをベースモデルの重みにマージして、ホスティングしやすい単一のスタンドアロンモデルを作成します。
Perplexityを使ってLLMが最新情報にアクセスできるようにする
モデルの動作をニーズに合わせて調整したい場合は、ファインチューニングが適しています。
モデルに最新情報、特に変化の速い情報が必要な場合は、RAGまたは信頼できるサードパーティの検索ツールが必要です。
カスタムの検索スタックは、社内Wiki、カスタマーサポートの履歴、契約書、製品ドキュメントなどの独自データセットに最適です。
活用したい知識が公開されている場合、独自の検索レイヤーを構築する必要はありません。Perplexityは、ライブのWebインデックスから、クリック可能なインライン引用付きの回答を返すアンサーエンジンです。PerplexityのAgent APIは、Webに基づく引用付きの回答を1回の呼び出しで提供するため、アプリで最新の情報源を活用できます。
LLMのファインチューニングに関するよくある質問
LLMは無料でファインチューニングできますか?
はい、小規模なオープンLLMであれば無料でファインチューニングできます。たとえば、Google Colabの無料枠では3B~8BのモデルでQLoRAを実行できるだけのGPUを利用でき、特定のタスクに絞ったトレーニングには十分です。無料枠で対応できる以上のメモリ、より長時間の実行、より大きなベースモデルが必要になると、費用が発生し始めます。
自前のGPUが必要ですか?それともクラウドでファインチューニングできますか?
LLMをファインチューニングするためにGPUを所有する必要はありません。マネージドサービスやGPUクラウドプロバイダーではハードウェアを時間単位でレンタルできるため、レンタルしたGPU 1基で小規模モデルのQLoRAを実行できます。GPUの購入が割に合うのは、頻繁にファインチューニングする場合や、すべてのデータを自社のマシンに保持する必要がある場合だけです。
LLMのファインチューニングにはどのくらい時間がかかりますか?
小規模なLLMの場合、データセットのサイズやハードウェアによって、数分から数時間で完了することがあります。たとえばOumiは、自社のホスト型プラットフォームで0.8Bモデルのフルファインチューニングを1時間強で完了しました。
モデルが大きい場合やサンプルが数万件に及ぶ場合は、1日以上かかることもあります。EmburseによるLoRAの実行では、40GBのGPU 1基を使用し、7Bモデルで5,000件のサンプルに8時間、50,000件に約30時間かかりました。
データの変化に合わせて、ファインチューニング済みモデルを更新し続けることはできますか?
新しいデータで再度ファインチューニングすることはできますが、そのたびに計算コストがかかり、破滅的忘却のリスクもあります。頻繁に変化する知識には、再トレーニングせずにソースドキュメントを更新するだけで済むRAGのほうが、通常は適しています。