finetuning-method-selection

ファインチューニング手法の選択

これはファインチューニングのライフサイクルにおけるルータースキルです。そもそもファインチューニングが適切な手段なのかどうかを判断し、適切であれば、どの手法とどのベースモデルのサイズクラスを選ぶべきかを決定します。このプラグイン内の他のすべてのスキルは、このルーティングがすでに済んでいることを前提としています。lora-qlora-recipes、preference-optimization、grpo-rlvr-training を開く前に、まずここから始めてください。

このスキルを使う場面

• フレームワークやベースモデルを選ぶ前に、あらゆるファインチューニングの取り組みを始めるとき。
• RAG やプロンプトエンジニアリングのほうが、トレーニングよりも低コストで問題を解決できるかどうかが不明なとき。
• 同じ基盤タスクに対して、選好最適化（DPO 系）と強化学習手法（GRPO/RLVR）のどちらを選ぶかを決めるとき。
• 実行を確定する前に、候補となるモデルと手法の組み合わせの規模を見積もるとき。

クイックリファレンス

状況	ルート
事実が頻繁に変わる（価格、ドキュメント、ニュース）	RAG、ファインチューニングではない
望ましい挙動がまだ固まっていない	プロンプトエンジニアリング
安定したドメイン知識、テキストが ≥500MB	CPT の後に SFT — 「まずオフランプを確認」を参照
入力と出力の実例がある	SFT — lora-qlora-recipes を参照
選好ペアまたは高評価/低評価がある	DPO/ORPO/KTO — preference-optimization を参照
検証可能な合否シグナルがある	GRPO+RLVR — grpo-rlvr-training を参照
評価ハーネスがまだない	停止 — eval-harness-first を参照

まずオフランプを確認

「これをファインチューニングして」と聞こえるリクエストのほとんどは、別の方法のほうがより良く、より安く対応できます。トレーニング実行を開く前に、これらのオフランプを確認してください。

• 知識に縛られ、変動しやすい（ギャップが変化する事実にある — 価格、ドキュメント、最新の出来事）：ファインチューニングではなく RAG にルーティングします。ファインチューニングされたモデルはスナップショットを焼き込みますが、変動しやすい事実はすぐに古くなります。
• 挙動に縛られ、移り変わる（望ましい挙動がまだ固まっていない、またはリクエストごとに変わる）：プロンプトエンジニアリングにルーティングします。ファインチューニングは挙動を固定します。まだ安定していない挙動を固定しないでください。
• 安定した、密度の高いドメイン知識：ここで継続事前学習（CPT）が登場し、ドメインテキストがどれだけ存在するかで規模が決まります。

ドメインテキストの量	ルート
<10MB	RAG のみ
10MB〜500MB	RAG + ファインチューニング
500MB〜10GB	CPT の後に SFT
>10GB	CPT が必須

CPT の学習率 ≈ 事前学習 LR の 10%。CPT はこのプラグインではガイダンスのみです。規模の見積もりと LR のガイダンスはここにありますが、このプラグインは CPT 実行を行いません。

手法ルーター

オフランプが除外されたら、これが完全な決定木です（このプラグインの基になっている研究からの引用そのまま）：

New FACTS?  volatile → RAG | stable+dense → CPT (LR ~10% of pretrain) → SFT
New BEHAVIOR? shifting → prompt-engineering | stable:
  demos → SFT (LoRA/QLoRA, all-linear, α=2r)
  preference pairs → DPO (SimPO if length-bias, ORPO if memory-bound)
  unpaired 👍/👎 → KTO
  verifiable success → RLVR + GRPO (DAPO/GSPO/Dr.GRPO per failure mode)
Deploy: FP8 (Hopper+) | NVFP4 (Blackwell scale) | AWQ (older) | GGUF+imatrix (edge)
BEFORE ANY OF THIS: the eval harness must exist first.

ツリーを上から下へ読んでください。まず「新しい事実か、新しい挙動か」に答え、次に手元のデータ形状（実例、選好ペア、高評価/低評価、または検証可能な成功/失敗）に一致する分岐をたどります。データ形状が手法を選ぶのであって、その逆ではありません。

ルーティングの実例

• 「ユーザーはアシスタントに、当社のサポートマクロに正確に従ってほしいと考えています。」 挙動が安定しており、トランスクリプトから実証できる → 実例 → SFT。
• 「レビュアーの高評価/低評価による良回答/悪回答のペアがあり、ペアにはなっていません。」 → ペアになっていないシグナル → KTO であり、DPO ではありません（DPO にはペアになった選好が必要です）。
• 「モデルはこれらの数学の問題の一部をすでに解くことができ、正しさを自動で採点できます。」 → 検証可能な成功シグナル → GRPO+RLVR、ただしモデルが少なくとも時々は成功することを確認した後のみ（下記の「ルーティングの重要な事実」を参照）。
• 「モデルに今週の価格ページを知ってほしいと考えています。」 → 変動しやすい事実 → RAG、トレーニング実行はまったく行いません。

ルーティングの重要な事実

• 損失関数の選択は効果が小さい。 240 回の H100 実行による研究では、手法の選択による差は約 1 パーセントポイントであるのに対し、モデルの規模による差は約 50 ポイントであり、20 種類の DPO バリアントのうちバニラ DPO を上回ったものはゼロでした。ルーティングの判断を DPO バリアントの選択に悩むことに費やさず、データの形状と規模を正しくすることに費やしてください。
• DPO は好みのため、GRPO+RLVR は推論のため。 主観的な判断（トーン、スタイル、「どちらの回答がより良いか」）をエンコードする選好ペアは DPO にルーティングします。検証可能な合否シグナルを持つタスク（数学、コード、ツール呼び出し）は代わりに GRPO+RLVR にルーティングします。
• RL は決して成功しないモデルの解決策ではありません。 GRPO やその他の RL 手法は既存の能力を研ぎ澄ますものであり、ゼロから能力を教えるものではありません。モデルがまだタスクや出力形式を理解していない場合は、まず SFT を実行してください。モデルが少なくとも時々成功するようになってから、初めて RL を取り入れてください。

よくあるルーティングの誤り

• 毎週変わる事実を修正するためにファインチューニングに手を伸ばす — それは RAG の問題であり、ファインチューニングはソースデータよりも速く陳腐化するだけです。
• 実際のボトルネックがデータ品質なのかモデルの規模なのかを確認する前に DPO バリアントを選ぶ — バリアントの選択は約 1pp のレバーであり、約 50pp のレバーではありません。
• すべてのロールアウトで失敗するモデルに対して RL 実行を開始する — まず SFT にルーティングして、RL が研ぎ澄ます対象を持つようにしてください。
• 「モデルが私たちのドメインを知らない」場合のデフォルトとして CPT を扱う — まずデータ量のしきい値を確認してください。500MB 未満では、RAG または RAG+ファインチューニングの方が CPT 実行よりも速く反復できます。

モデル選択

ベースモデルの選択は、まずサイズクラス、次にファミリーであり、すぐに陳腐化します — そのため、それはちょうど 1 か所、references/model-catalog.md に置かれています。このファイルは、このプラグイン（および DGX Spark 運用プラグイン）においてベースモデルのファミリーを名指しする唯一の場所です。このスキルも references/memory-math.md も、それを名指ししません。どちらもモデルをサイズクラスのみで記述します（たとえば、「8B クラスの LoRA」であり、モデル名ではありません）。

カタログは意図的に日付が付けられています — モデルのランキングは四半期ごとに変わります。カタログには「最終検証」日と更新チェックリストがあります。ある行を信頼する前に、その日付を確認してください。古い場合は、そこからモデルを推奨する前にカタログの更新チェックリストを実施してください。

カタログと手法スキルが矛盾する場合の優先順位： カタログの行ごとの Notes 列は、ハードウェア／サイズクラスの実現可能性を示すものであり、手法の推奨ではありません — lora-qlora-recipes の LoRA vs QLoRA vs Full FT の表（タスクの形状によってルーティングされる）が実際の手法の選択を規定します。

メモリの実現可能性

手法を確定する前に、それを見積もってください：総メモリ ≈ パラメータ数 × dtype バイト数 + オプティマイザ状態 + 勾配 + アクティベーション。選択した dtype と手法（フルファインチューニング、LoRA、または QLoRA）について各項を計算してください — 計算用ワークシートとサイズクラスの例は references/memory-math.md にあります。

特に DGX Spark では、ユニファイドメモリの挙動が素朴な見積もりを崩します（一時的なロードのピーク、nvidia-smi の過少報告、長時間実行時の熱スロットリング）。dgx-spark-ops プラグインがインストールされたら、Spark 固有の実現可能性の判断はここで再導出するのではなく、その spark-memory-thermal-ops スキルに委ねてください。

関連スキル

このスキルが手法を選択したら、それを実行するスキルに引き継いでください：

• lora-qlora-recipes — LoRA/QLoRA による SFT
• preference-optimization — DPO、ORPO、KTO
• grpo-rlvr-training — 検証可能な報酬を用いた GRPO

eval ハーネスが存在する前に手法が選択されることはありません — eval-harness-first を参照してください。