localaiforum
ログイン
ガイド › モデルの活用

LoRAとQLoRAによるファインチューニング

ファインチューニングが調整するのは挙動であって知識ではない。モデルが内容を知っているのに間違ったダンスを踊るとき——間違った出力形式、間違ったトーン、間違ったドメイン方言、間違った拒否較正——が正しい道具。「私の文書を知っている」のための道具としては間違い。それは検索:RAG。

ファインチューニングするかしないか

目的 手を伸ばす先
自分の文書からの質問応答 RAG
常に正確な独自JSON/XML形式を出力 LoRA——またはグラマー制約付きデコーディング
一貫したハウススタイルで書く LoRA
正当なドメインリクエストの拒否を止める LoRA、注意深いデータで
ドメインの方言を流暢に話す LoRA、その上にRAG
より良く推論する より大きくより良いベースモデル——チューニングはIQを足さない

プロンプトやスキーマでできるなら、そちらを優先。毎回の呼び出しに同じ300トークンの指示を貼っている自分に気づいたときにチューニングを。

LoRAを1段落で

ベースの全重みを凍結。各ターゲット重み行列に、2つの小さな学習可能行列——A(r×d)とB(d×r)——を追加し、それだけを学習。更新は低ランク。

W' = W + (alpha / r) · B·A      # Aはr×d、Bはd×r、ランク r << d

具体例:d = 4096の行列をランクr = 16で扱うには、密な4096² ≈ 1680万の代わりに2 × 4096 × 16 = 13.1万のアダプタパラメータで足りる——その行列の0.8%。7〜8Bモデル全体で、アダプタは合計約4,000万〜8,000万パラメータ。ベースの0.5〜1%、数百MB。スタイルと形式を強く動かすには十分な容量。それらの挙動が強く低ランクな方向に住んでいるから。

QLoRA:コンシューマカード1枚

QLoRAは学習中、凍結ベースを4ビット(NF4)に量子化して保ち、アダプタを16ビットで走らせる。現在のスタックでの動く数値:7〜8Bモデルは24GB GPU 1枚でQLoRA学習が可能。3Bは8GBで快適に学習。勾配チェックポイントとページドオプティマイザはツールが処理する——あなたが供給するのは予算の計算:VRAM計算。

データがすべてに勝る

高品質なペア500〜5,000が、スクレイピングした10万ペアに毎回勝る。重要なルール。

  • **1つの一貫した形式。**サーブに使うまさにそのチャットテンプレートを使うこと——学習/サーブのテンプレ不一致が実行全体を無にする。
  • **量より質。**各ペアは、モデルから受け入れられる出力であるべき。重複除去。怠惰な例を捨てる。
  • **カバー範囲。**モデルに断ってほしいケースや特別に扱うケースを含める——さもないと新しい挙動をすべてに過剰一般化する。
  • **汚染チェック。**評価質問が学習データに現れないことを確認——さもないと暗記を採点している。
  • **ホールドアウト評価セット。**決して学習しない50〜100例。前後で採点。

ペアの姿(大半のツールが消費するmessages形式)。

{"messages": [{"role": "system", "content": "You are a 1998-era equipment manual assistant."},
              {"role": "user", "content": "How do I reset the service counter?"},
              {"role": "assistant", "content": "Press MENU and hold for 3 seconds..."}]}

ツール

ツール 選ぶ理由
Unsloth 最速の単一GPUトレーナ、無料のコミュニティノートブック——簡単な始まり
Axolotl 設定駆動、広いデータセット形式対応、再現可能なレシピ
LLaMA-Factory GUI+CLI、強力な多言語データセットエコシステム

執筆時点で3つすべてが活発にメンテナンスされている:unsloth、axolotl、llama-factory。

実際に重要なハイパーパラメータ

影響の順に。

  • 学習率——QLoRAでは1e-4〜2e-4が正気の帯。高すぎがお粥の通常原因。
  • エポック——1〜3。多いところからイエスマンが来る。
  • ランク/アルファ——r 8〜32にalpha 16〜32で大半の挙動調整をカバー。ドメイン重心のシフトには大きいランクを。
  • コンテキスト長——トレーナのデフォルトではなく、最長の実際の例に設定。
  • バッチサイズ——カード1枚のQLoRAでは1〜8が普通。品質でなくスループットのノブ。

実行が失望に終わったら、まずデータ、次に学習率、最後にランクを直す。

時間とコスト

2,000ペア、3エポック、7〜8BモデルのQLoRA:RTX 3090/4090級カード1枚で1〜3時間を期待。それはAPI請求でなく電気代で、反復は最悪でも一晩。だからローカルファインチューニングは調達プロセスではなく趣味。

反復の予算を組むこと。最初の実行がデータの問題を教え、2回目が手元に残るもの。

出荷前に評価

30〜50プロンプトの固定スイート——ホールドアウトセットを含む——を前後で実行し、出力を並べてdiff。それから汎用チャットのリグレッション確認。古典的失敗は、ドメイン調整モデルがすべてにバグ報告形式で答えること。汎用品質が下がったら、エポックを減らすか学習率を下げるか、10〜30%の汎用指示データを実行に混ぜる。

損失曲線は発散の発見用であって採点用ではない。学習損失は落ちて平坦になるべき。裁定者は評価スイート。

エクスポートとサーブ

学習済みアダプタからの2つの道。

  • マージ:LoRAをベースにfp16で統合し、llama.cpp用にGGUFへ変換——フォーラムフレンドリーな成果物。1ファイル、任意のエンジン:モデルフォーマット、量子化。
  • アダプタを分離:transformers/vLLMは実行時にベース+アダプタをロードする——反復はより安く、エンジン固有。

失敗モード

  • 過学習/「イエスマン」——プロンプトを反響し、すべてに同意。学習損失は低く評価は悪化。修正:エポック減、低いLR、より多様なデータ。
  • 破滅的忘却——ドメインスキル上昇、汎用能力下降。修正:汎用データを混ぜる。LRを下げる。
  • テンプレドリフト——あるチャットテンプレートで学習し、別のものサーブ。症状はトラブルシューティングの古典。

SFTの後のDPO

形式は正しいが選好がずれているとき——冗長すぎ、トーンが違う、拒否すぎ——選好ペア(chosen対rejected応答)への小さなDPO実行が、もう一度のSFTなしに挙動を調整する。安く、安定し、SFT→DPOレシピの標準第2段階。

関連: RAG · モデルフォーマット · 量子化 · VRAM計算