なぜファインチューニングが必要なのか
プロンプトエンジニアリングでは限界がある。KGAのクライアント案件で、特定業界の専門用語を含む文書分類タスクがあった。few-shot promptingで最適化しても精度は74%止まり。LoRAでfine-tuningした結果、93%に跳ね上がった。この19ポイントの差がビジネス上の要件を満たすかどうかの分岐点だった。
ファインチューニングが有効なケース。特定ドメインの専門知識が必要、出力フォーマットの厳密な制御が必要、レイテンシ制約で小型モデルを使いたい、APIコスト削減のため小型モデルで品質を確保したい。逆に汎用的な質問応答や一般的な文書生成なら、大型モデルのプロンプトエンジニアリングの方がコスパが良いケースが多い。
LoRAの仕組みを正確に理解する
Low-Rank Adaptation (LoRA)は、事前学習済みモデルのweightを凍結し、低ランクの行列ペア（A, B）を追加して学習する手法だ。元のweight行列W (d x d)に対し、W + BA (BA: d x r、r x d、r << d)で近似する。rank rが小さいほどパラメータ数が少なくなり、学習が高速になる。
- Bモデルの場合、full fine-tuningでは70億パラメータ全てを更新するが、LoRA (rank 64)では約1.7億パラメータ（元の2.4%）のみ更新する。メモリ使用量はfull fine-tuningの約4分の1で済み、A100 1枚で実行可能だ。
QLoRA: さらなるメモリ効率化
QLoRAはLoRAの発展形で、ベースモデルを4bit量子化した上でLoRA学習を行う。これによりメモリ使用量がさらに半減し、7BモデルがRTX 3090/4090（24GB VRAM）で学習可能になる。
具体的なメモリ使用量の比較（7Bモデル）。Full fine-tuning FP16: 約56GB。LoRA rank 64 FP16: 約28GB。QLoRA rank 64 4bit: 約12GB。QLoRA rank 32 4bit: 約10GB。
品質への影響はどうか。KGAの検証では、full fine-tuningと比較してLoRAは品質の98%を維持、QLoRAは96%を維持した。この2-4%の品質差は多くのユースケースで許容範囲内だ。
データセット準備: 最重要ステップ
ファインチューニングの成否はデータセットの品質で90%決まる。KGAが蓄積したデータセット準備のベストプラクティスを共有する。
データ量の目安。分類タスク: 500-2000サンプル。テキスト生成: 1000-5000サンプル。会話: 2000-10000ターン。ドメイン知識注入: 3000-10000サンプル。
データ品質のチェックリスト。人間がレビューして正解ラベルの正確性を確認（最低でもサンプルの10%を手動チェック）。入力の多様性を確保（同じパターンの繰り返しを避ける）。出力の一貫性を確保（同種の質問に対して回答スタイルが統一されているか）。ノイズデータの除去（OCRエラー、文字化け、不完全な文）。
フォーマットはAlpaca形式（instruction, input, output）が標準的で、最も多くのフレームワークでサポートされている。ChatML形式（system, user, assistant）は会話型タスクに適している。
ハイパーパラメータの最適値
KGAが100回以上の実験で蓄積した、実践的なハイパーパラメータ設定を共有する。
LoRA rank: 32-64（小型タスクなら16でも可。128以上はoverfittingリスク）。LoRA alpha: rankの2倍（rank 64ならalpha 128）。LoRA target modules: q_proj, k_proj, v_proj, o_proj（attention層のみ。FFN層を含めると学習時間が1.5倍になるが、品質向上は2-3%程度）。Learning rate: 2e-4 - 5e-4（QLoRAの場合。full LoRAなら1e-4 - 3e-4）。Batch size: 4-8（gradient accumulation stepsで実効batch sizeを32-64に）。Epochs: 2-4（3が最もバランス良い。5以上はoverfitting確実）。Warmup ratio: 0.05-0.1。
評価手法: 学習したモデルをどう評価するか
学習曲線（training loss）だけ見て安心するのは危険だ。KGAでは以下の3段階評価を必ず実施する。
定量評価: テストセット（学習データの15-20%をhold-out）でのメトリクス測定。分類ならF1スコア、生成ならBLEU/ROUGE/BERTScore。LLM-as-a-Judge: Claude 4でテストセットの出力を5段階評価。「正確性」「関連性」「流暢さ」「指示遵守」の4軸。人間評価: ドメイン専門家による抜き取り検査（テストセットの20%）。
この3段階評価で全指標が閾値を超えた場合のみ、本番デプロイを承認する。KGAの経験では、定量評価とLLM-as-a-Judgeが良好でも、人間評価で問題が見つかるケースが15%程度ある。特にドメイン固有のニュアンス（業界特有の表現、暗黙の慣習）の評価は人間にしかできない。
実践Tips
学習フレームワークはunslothが圧倒的に推奨。HuggingFaceのtransformers + peftと比較して2-3倍高速で、メモリ使用量も30%削減。Llama、Qwen、Mistral、Gemmaの主要モデルに対応。もう一つ重要なTipsは、base modelではなくinstruction-tuned modelからfine-tuningすること。base modelからの場合、指示遵守能力をゼロから学習する必要があり、データ量が3-5倍必要になる。