9月29日、Java Code Geeksが「LLM Fine-Tuning: SFT, LoRA, QLoRA, RAG and Prompting」と題した記事を公開した。LLMを実業務に組み込もうとしたとき、「プロンプトを工夫するだけでいいのか、外部知識を与えるべきか、それともモデル自体を再学習させるべきか」という判断を誤り、数週間・数万円単位のコストをかけてファインチューニングしたあとで「プロンプトで十分だった」と気づく——これがLLMエンジニアリングでよく起きる非効率のパターンだ。本記事はこの3択を「飛びつく前に順序立てて考える」という観点で整理している。
まず「ファインチューニングは最後の手段」と覚える
記事が最初に強調するのは、ファインチューニングの前にプロンプティングを試せという点だ。
プロンプティングとはモデルに推論時（inference time）に指示を与える方法で、モデル自体は変わらない。たとえば以下のような指示文を渡すだけで、かなりの挙動制御が可能だ。
あなたはカスタマーサポートエージェントです。注文状況を確認する前に必ず注文番号を確認してください。支払いが確認されるまで返金処理を行わないでください。
プロンプトを変えるだけで済むなら、学習パイプラインを組む必要はない。
RAG（Retrieval-Augmented Generation）は、外部ドキュメントをリアルタイムで検索してモデルのコンテキストに注入する手法だ。社内規程や製品仕様書のように頻繁に更新される情報を扱う場合に適している。モデルを再学習しなくても、ナレッジベースを更新するだけで最新情報を反映できる。
この3手法の役割を整理すると次のとおりだ。
| 手法 | 何が変わるか | 主な用途 |
|---|---|---|
| プロンプティング | モデルへの指示 | 役割・フォーマット・簡単な挙動制御 |
| RAG | 実行時に与える情報 | 外部ドキュメントの参照・最新情報の取得 |
| ファインチューニング | モデルの学習済み挙動 | 繰り返し求められる一貫した挙動の習得 |
「最初からファインチューニングに飛びつく」のが、LLMエンジニアリングにおいてよくある非効率の原因だ。
SFT・LoRA・QLoRAの違いを整理する
SFT（Supervised Fine-Tuning）
SFTは、入力と期待される出力のペアを用意してモデルを追加学習させる手法だ。たとえば注文管理エージェントなら、以下のような例を多数用意する。
{
"instruction": "注文7281をキャンセルしてください。",
"tool": "cancel_order",
"arguments": {
"order_id": "7281"
}
}
SFTはツール選択・引数フォーマット・ワークフローの一貫性など、エージェントに「決まった動作パターン」を身につけさせるのに有効だ。記事ではデータセットの品質が最重要と指摘している。成功例だけでなく、エッジケース・無効なリクエスト・ツール失敗・エスカレーションすべき状況なども含める必要がある。
最も単純なSFTの実装はフルファインチューニング（モデルの全パラメータを更新）だが、数十億パラメータのモデルでは膨大なメモリと計算資源を要する。そこで登場するのがPEFT（Parameter-Efficient Fine-Tuning）の考え方で、代表的な実装がLoRAだ。
LoRA（Low-Rank Adaptation）
LoRAは、2021年にEdward J. Huらが発表した論文（arxiv: 2106.09685）で提案された手法だ。元のモデルの重みを凍結（freeze）したまま、Transformerの各層に小さな「アダプター行列」を追加して学習する。
数式で表すと、元の重み行列Wに対して以下の更新を行う。
W' = W + B × A
AとBは元の行列よりはるかにランクが小さい（つまりパラメータ数が少ない）行列だ。これにより、学習対象のパラメータ数を大幅に削減できる。
LoRAの実用上の利点として記事が挙げているのは次の2点だ。
- 同一のベースモデルに対して、タスクごとに異なるアダプターを用意できる（カスタマーサポート用・法律相談用・コード生成用など）
- アダプターのファイルサイズはベースモデルより格段に小さいため、保存・共有・管理が容易
実装にはHugging Face PEFTライブラリが広く使われている。
QLoRA（Quantized LoRA）
QLoRAは、Tim Dettmersらが2023年に発表した論文（arxiv: 2305.14314）で提案された手法で、LoRAと量子化（quantization）を組み合わせる。
仕組みは以下のとおりだ。
大規模事前学習済みモデル
↓
4ビット量子化
↓
凍結されたベースモデル ＋ LoRAアダプター
↓
アダプターのみ学習
量子化とは、数値を表現するビット数を減らすことでモデルのメモリフットプリントを圧縮する技術だ。QLoRAではベースモデルを4ビット精度で読み込むことでメモリ消費を抑えつつ、LoRAアダプター部分は通常精度で学習する。
記事ではQLoRAを構成する3つの要素技術も言及されている。それぞれの役割を簡単に補足する。
- 4ビットNormalFloat（NF4）：通常の整数量子化ではなく、正規分布に最適化された独自の4ビットデータ型を使うことで、精度劣化を抑えながらメモリを削減する
- ダブル量子化：量子化に使う定数（スケール因子）自体をさらに量子化することで、追加的なメモリ削減を実現する
- ページドオプティマイザー：勾配チェックポイント処理中に発生するメモリスパイクをNVIDIA統合メモリ機能で吸収し、OOM（Out of Memory）エラーを回避する仕組み
3手法を比較すると次のとおりだ。
| 手法 | ベースモデルの精度 | 学習対象 | 主な目的 |
|---|---|---|---|
| フルファインチューニング | 通常精度 | ほぼ全パラメータ | 最大の柔軟性（高コスト） |
| LoRA | 通常精度 | 小さなアダプター | パラメータ効率の改善 |
| QLoRA | 4ビット量子化 | 小さなアダプター | メモリ使用量の削減 |
QLoRAはLoRAの「代替」ではなく、量子化によってメモリ制約の厳しい環境でLoRAを使えるようにする拡張だ。
使い分けの判断軸
記事の核心は「3つの手法は競合しない」という整理にある。多くの場合、最初はプロンプティングで試し、外部情報が必要ならRAGを追加し、それでも一貫した挙動が得られない場合にのみファインチューニングを検討するという順序が合理的だ。
判断の流れを整理すると次のようになる。
- まずプロンプティングで解決を試みる — 役割定義・出力フォーマット指定・few-shotサンプル提示など、推論時の指示だけで目的の挙動が得られるかを検証する
- 動的な外部情報が必要ならRAGを追加する — 頻繁に更新されるドキュメントや、モデルのコンテキスト長に収まらない大規模ナレッジベースを扱う場合に有効
- それでも不十分な場合にファインチューニングを検討する — ツールの呼び出しパターン・出力フォーマット・ドメイン固有の用語など、「モデルに繰り返し学ばせたい特定の挙動パターン」が明確に定義できているかを確認してから着手する
ファインチューニングに進む場合、GPUメモリに余裕があればLoRA、コンシューマーGPUや限られたクラウド予算での実行を想定するならQLoRAが選択肢となる。いずれの場合も、SFT用データセットの品質——特に失敗ケースや境界値ケースの網羅——が最終的な精度を左右する点は変わらない。
詳細はLLM Fine-Tuning: SFT, LoRA, QLoRA, RAG and Promptingを参照していただきたい。
