コンテンツへスキップ
リソース/技術ガイド
技術的ディープダイブ

AI スキル & ファインチューニングガイド

AI モデルに新しいスキルを教えるための完全ガイド:教師ありファインチューニング(SFT)、LoRA/QLoRA、RLHF、DPO、GRPO、モデル蒸留、モデルマージ、評価。コンセプトから本番まで — 各ステップに動作するコード付き。

11セクション
読了45分
本番対応のコード
2026年3月

ファインチューニングの全体像

事前学習はモデルに世界に関する広範な知識を与えるが、与えるスキルは一つだけ:次の token を予測することだ。モデルは Wikipedia、コード、書籍、ウェブを見てきた — しかし、役に立つこと、指示に従うこと、危険な要求を拒否することは知らない。ファインチューニングは、事前学習の後にこれらの振る舞いを教えるプロセスである。

業界は、すべての主要なフロンティアモデル(GPT-4o、Claude Opus 4.6、Llama 4、Gemini 2.5)が従う標準的な学習の梯子へと収束した。各段階は前の段階の上に築かれる — SFT を飛ばして RLHF に直接進むことはできない。

学習の梯子

graph LR
  A[Raw Text Corpus] -->|Pretraining cross-entropy| B[Base Model]
  B -->|Supervised Fine-Tuning| C[Instruction-Following Model]
  C -->|RLHF / DPO / GRPO| D[Aligned Model]
  D -->|Evaluation & Red-teaming| E[Production Model]

事前学習

巨大なコーパスでの自己教師あり次 token 予測。世界知識を符号化する。

SFT

指示-応答ペアでの教師ありファインチューニング。モデルに役立つことを教える。

嗜好アライメント

人間の嗜好データでの RLHF、DPO、または GRPO。出力を安全で好ましいものにする。

評価

自動ベンチマーク + レッドチーミング。出荷前に回帰を捕捉する。

ファインチューニング vs プロンプトエンジニアリング
プロンプトエンジニアリングは振る舞いを条件付きにする(プロンプトがそう指示したときにのみ現れる)。ファインチューニングは振る舞いをデフォルトにする — モデルは指示されなくても一貫してそれを示す。規模が大きくなると、この信頼性の違いは重要である。

教師ありファインチューニング(SFT)

SFT は、会話コンテキストが与えられたときにアシスタントの token を予測するようモデルを学習させる。重要な詳細は loss masking である:交差エントロピー損失はアシスタントの token のみで計算され、システムプロンプトやユーザーのターンでは計算されない。これにより、モデルが会話のユーザー側を「学習」するのを防ぐ。

データ形式

三つの形式が SFT の全体像を支配している。ChatML は曖昧さのない特殊 token のおかげで最も広く採用されている。

text (ChatML format)
<|im_start|>system
You are a helpful AI assistant specialized in European AI regulation.
<|im_end|>
<|im_start|>user
What are the key obligations under the EU AI Act for high-risk systems?
<|im_end|>
<|im_start|>assistant
High-risk AI systems under the EU AI Act (in force August 2024) must comply with...
<|im_end|>

主要なハイパーパラメータ

パラメータ典型値備考
Learning rate2e-5事前学習より低め;コサイン減衰
Epochs2–3エポック数が多いほど → 小規模データセットでの過学習
Batch size (effective)64–128GPU メモリが小さい場合は勾配累積を使用
Warmup ratio0.1LR ウォームアップにステップの10%
Max sequence length2048–8192推論コンテキストウィンドウに合わせる

trl の SFTTrainer による SFT

python
from transformers import AutoModelForCausalLM, AutoTokenizer
from trl import SFTConfig, SFTTrainer
from datasets import load_dataset
import torch

model_name = "meta-llama/Llama-4-Scout-17B-16E-Instruct"  # 2026: Llama 4 Scout replaces Llama 3.1 8B
model = AutoModelForCausalLM.from_pretrained(
    model_name, torch_dtype=torch.bfloat16, device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained(model_name)

dataset = load_dataset("HuggingFaceH4/ultrachat_200k", split="train_sft")

sft_config = SFTConfig(
    output_dir="./sft-llama-4-scout",
    num_train_epochs=3,
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    learning_rate=2e-5,
    lr_scheduler_type="cosine",
    warmup_ratio=0.1,
    logging_steps=10,
    save_strategy="epoch",
    bf16=True,
)

trainer = SFTTrainer(
    model=model,
    args=sft_config,
    train_dataset=dataset,
    processing_class=tokenizer,
)
trainer.train()
trainer.save_model()
データの質は量に勝る
高品質で多様な1,000件の指示-応答ペアは、ノイズの多い100,000件の例を一貫して上回る。上位の指示チューニングデータセット(Alpaca 52K、WizardLM 196K、OpenHermes 1M、UltraChat 200K)が成功するのは、生の規模ではなくキュレーションのおかげである。

パラメータ効率的なファインチューニング:LoRA

フルファインチューニングは 7B モデルの全 ~70億パラメータを変更する。bfloat16 ではパラメータの保存だけで14 GB、さらに勾配とオプティマイザの状態が加わる。LoRA(Low-Rank Adaptation、Hu et al. 2021)は重要な経験的観察を活用する:ファインチューニング中の重みの変化は低ランクである。

完全な重み更新 ΔW ∈ ℝ^(d×k) を学習する代わりに、LoRA は二つの小さな行列を学習する:A ∈ ℝ^(d×r) と B ∈ ℝ^(r×k)、ここで r ≪ min(d, k)。推論時、アダプタは折り戻される:W′ = W + αAB/r。マージされると、推論のオーバーヘッドはゼロになる。

r = 4
最小限の適応(トーン、スタイル)
~21M (0.3%)
r = 8
デフォルト — バランスの取れた品質
~42M (0.6%)
r = 16
より多くの容量、ドメインタスク
~83M (1.0%)
r = 64
フルファインチューニングに近い品質
~335M (4.1%)
Alpha/ランク比
出発点として lora_alpha = 2 × r を保つ(例:r=16、alpha=32)。これはアダプタの実効学習率を制御する。alpha が高いほど適応が強くなる;高すぎると不安定になる。

PEFT による LoRA

python
from peft import LoraConfig, TaskType, get_peft_model

config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,
    lora_alpha=32,
    lora_dropout=0.05,
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],
    bias="none",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: 83,886,080 || all params: 8,030,261,248 || trainable%: 1.044

# After training, merge adapter back into the base weights
merged = model.merge_and_unload()
merged.save_pretrained("./my-lora-merged")

LoRA vs フルファインチューニングの比較

手法学習可能パラメータGPU RAM (8B)品質学習速度
Full Fine-Tuning7B (100%)~80 GB最良最も遅い
LoRA r=4~21M (0.3%)~16 GB良好高速
LoRA r=16~83M (1.0%)~18 GB非常に良好高速
LoRA r=64~335M (4.1%)~24 GBフル FT に近い中程度
DoRA:重み分解型 LoRA
DoRA(Liu et al. 2024)は重み更新を大きさと方向の成分に分解し、それぞれに別々の学習率を適用する。追加の推論コストなしに、標準的な LoRA より一貫して1〜2% 良いベンチマークスコアを達成する。PEFT では LoraConfig の use_dora=True で利用できる。

QLoRA:4ビットファインチューニング

LoRA を使っても、bfloat16 で読み込んだベースモデルは 8B モデルで16 GB を必要とし — コンシューマー GPU の予算を超える。QLoRA(Dettmers et al. 2023)は、凍結したベースモデルを4ビット NormalFloat(NF4)に量子化し、LoRA アダプタを bfloat16 精度で学習することでこれを解決する。

NF4 量子化

NormalFloat4 は正規分布するニューラルネットワークの重みに対して情報理論的に最適である。int4 や fp4 より誤差が小さい。

ページド・オプティマイザ

GPU メモリが一杯になると、オプティマイザの状態が自動的に CPU RAM へページングされ、学習中の OOM クラッシュを防ぐ。

二重量子化

量子化定数そのものを量子化し、パラメータあたり追加で約0.5ビットを節約する。

ハードウェア要件

モデルFP16 VRAMQLoRA VRAM最小 GPU
Llama 4 Scout (17B)34 GB10 GBRTX 4090 24GB
Llama 4 Maverick (70B-class)140 GB40 GB2× A100 40GB
Llama 4 Behemoth (frontier)800+ GB~200 GB8× H100 80GB

bitsandbytes による QLoRA

python
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
import torch

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-4-Maverick-17B-128E-Instruct",  # 2026: Llama 4 Maverick replaces Llama 3.1 70B
    quantization_config=bnb_config,
    device_map="auto",
)
# Now apply LoRA to the 4-bit model — same LoraConfig + get_peft_model as before
シングル GPU ワークロードのための Unsloth
Unsloth は QLoRA 用のカスタム CUDA カーネルを提供し、標準的な bitsandbytes の QLoRA より2倍高速な学習と50% 少ない VRAM を達成する。Llama 4、Llama 3、Mistral、Qwen、Gemma の各ファミリーをサポートし、シングル GPU のファインチューニングでは定番の選択肢である。

アライメント:RLHF

人間のフィードバックからの強化学習(RLHF)は、GPT-3 を InstructGPT に、そして最終的に GPT-4o に変えたブレークスルーだった。これはモデルの振る舞いを人間の嗜好に整合させる — 単なる指示の遵守ではなく、出力を真に好ましく、安全で、役立つものにする。

三段階のパイプライン

Stage 1

SFT ウォームアップ

高品質な指示遵守デモのキュレーションされたセットでベースモデルをファインチューニングする。これにより RLHF が改善する出発点となるポリシーが作られる。

Stage 2

報酬モデルの学習

ペアごとの人間の嗜好で分類器を学習する:同じプロンプトに対する二つの補完(y_w、y_l)のうち、どちらが良いか? 損失:log σ(r(x, y_w) − r(x, y_l))。

Stage 3

PPO 最適化

Proximal Policy Optimization を用いて、SFT ポリシーに近いまま報酬モデルのスコアを最大化する(KL ダイバージェンスのペナルティが報酬ハッキングを防ぐ)。

RLHF パイプライン図

graph LR
  A[Base Model] -->|SFT on demos| B[SFT Model]
  B -->|Sample completions| C[Completion Pairs]
  C -->|Human labelers rank| D[Preference Dataset]
  D -->|Train| E[Reward Model]
  B -->|Initialize policy| F[Policy Model]
  F -->|Rollout + PPO| G[RL Optimization]
  E -->|Score rollouts| G
  G -->|Converged| H[RLHF Model]
PPO の複雑さ
PPO を用いる RLHF は四つのモデルを同時に必要とする:ポリシー、参照ポリシー(凍結された SFT モデル)、報酬モデル、価値モデルである。これにより RLHF はメモリ集約的になり、安定化が悪名高く難しい。報酬ハッキング(ポリシーが実際には良くないのに高スコアを得る方法を見つけること)は根強い課題である。これが DPO が広く好まれるようになった理由だ。

アライメント:DPO と GRPO

DPO(Direct Preference Optimization)(Rafailov et al. 2023)は報酬モデルを完全に排除する。最適な RLHF ポリシーが嗜好データの関数として直接表現できることを数学的に示し、三段階のパイプラインを単一のファインチューニングステップへと折りたたんだ。

DPO 損失は、SFT モデルを凍結された参照として用い、嗜好ペア(prompt、chosen、rejected)でポリシーを直接最適化する。PPO もなく、報酬モデルもなく、報酬モデル用の学習データの個別収集もない。

trl の DPOTrainer による DPO

python
from trl import DPOConfig, DPOTrainer
from datasets import load_dataset

# Dataset needs: prompt, chosen, rejected columns
dataset = load_dataset("HuggingFaceH4/ultrafeedback_binarized", split="train_prefs")

dpo_config = DPOConfig(
    output_dir="./dpo-output",
    num_train_epochs=3,
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    learning_rate=5e-7,   # much smaller than SFT lr
    beta=0.1,             # KL penalty coefficient
    bf16=True,
)

trainer = DPOTrainer(
    model=sft_model,          # your SFT fine-tuned model
    ref_model=sft_ref_model,  # frozen reference
    args=dpo_config,
    train_dataset=dataset,
    processing_class=tokenizer,
)
trainer.train()

GRPO:DeepSeek のアプローチ

Group Relative Policy Optimization(GRPO)(DeepSeek-R1 で使用)は参照モデルを排除する。各プロンプトについて複数の出力をサンプリングし、グループの平均報酬をアドバンテージ推定のベースラインとして用いる。これは PPO より安価で(価値モデルが不要)、正しさをプログラム的に検証できる推論タスクに適している。

GRPO の主要な利点:
参照モデル不要 + グループ相対報酬 = 検証可能なタスク(数学、コード、構造化出力)のための効率的な学習。

アライメント手法の比較

手法計算量安定性データ要件備考
RLHF (PPO)非常に高い低い人間のランキング4モデルがメモリ上;報酬ハッキングのリスク
DPO低い高い嗜好ペア報酬モデルなし;よりシンプルなパイプライン
GRPO中程度中程度ロールアウトサンプル参照モデルなし;推論に適する
SimPO低い高い嗜好ペア参照モデルなし;平均対数確率の報酬

モデル蒸留

知識蒸留は、小さな「生徒」モデルを大きな「教師」モデルを模倣するよう学習させる。重要な洞察は、教師が one-hot ラベルではなく語彙上のソフトな確率分布(logits)を提供することだ。これらのソフトターゲットははるかに多くの情報を符号化する — どの token が正解と意味的に類似しているかを明らかにし、生徒により豊かな学習信号を与える。

結合された損失:L = α × L_CE(ハードラベル) + (1 − α) × L_KL(生徒の logits ‖ 教師の logits)。温度スケーリング T > 1 は教師の分布を滑らかにし、確率質量をより多くの token に広げ、ソフトラベルをさらに情報量の多いものにする。

蒸留パイプライン

graph TB
  A["Large Teacher (70B)"] -->|"Generate on training data"| B[Soft Logits]
  C[Input Prompt] --> A
  C --> D["Small Student (7B)"]
  B -->|KL Loss| D
  E[Ground Truth] -->|CE Loss| D
  D -->|Both losses| F[Distilled Student]

応答蒸留

生徒が教師の出力を模倣する — 教師の補完を生成し、それを再現するよう生徒を学習させる。DeepSeek-R1-Distill が推論トレースを転移するために使用。

特徴蒸留

教師と生徒の層の間で中間表現(隠れ状態、attention パターン)を一致させる。表面的な出力だけでなく、構造的な知識を転移する。

投機的デコーディング

小さなドラフトモデルが token 列を提案し、大きなモデルがそれらを並列に検証する。品質を損なうことなく2〜4倍の推論高速化を達成する。

オンポリシー蒸留

生徒が token を生成し、教師がそれを採点する。オフライン蒸留でよく見られる露出バイアス(学習と評価の分布のミスマッチ)を回避する。

現実世界の蒸留の例
  • Phi-3 / Phi-4(Microsoft):キュレーションされた合成データで GPT-4 から蒸留
  • Gemma 2(Google):Gemini Ultra から蒸留;9B がはるかに大きなモデルに匹敵
  • DeepSeek-R1-Distill:R1 からの推論トレースを 7B / 14B の Qwen2.5 モデルに蒸留

モデルマージ

モデルマージは、追加の学習を一切行わずに、複数のファインチューニング済みチェックポイントを単一のモデルに結合する。安価で高速、そして専門的なスキル — コード、数学、指示遵守 — を一つのデプロイ可能なモデルに統合するのに驚くほど効果的である。マージされたモデルは HuggingFace Open LLM Leaderboard の上位に頻繁に登場する。

SLERP球面線形補間

重み空間における二つのモデルチェックポイント間の滑らかな補間。重みを超球面上の点として扱う。密接に関連した二つのモデルをブレンドするのに最適。

Task Arithmeticファインチューニング差分の加算/減算

各ファインチューニング済みモデルについて ΔW = W_FT − W_base を計算し、差分を加算する。能力を合成したり、望ましくない振る舞いを減算したりできる。

TIES-MergingTrim, Elect Signs, Merge

モデル間の競合を解決する:大きさの小さいパラメータをトリミングし、各重みについて支配的な符号を選出し、その後マージする。3つ以上のモデルをきれいに扱う。

DAREDrop and Rescale

ファインチューニングの重み差分をランダムに(確率 p で)ドロップし、生き残ったものをリスケールしてノルムを保つ。モデル間の干渉を低減する。

MergeKit 設定(TIES)

yaml
# mergekit config.yaml
models:
  - model: meta-llama/Llama-4-Scout-17B-16E
    parameters:
      weight: 0.4
  - model: ./llama-4-scout-code-finetuned
    parameters:
      weight: 0.3
  - model: ./llama-4-scout-math-finetuned
    parameters:
      weight: 0.3
merge_method: ties
base_model: meta-llama/Llama-4-Scout-17B-16E
parameters:
  density: 0.7
  normalize: true
bash
mergekit-yaml config.yaml ./merged-model --cuda
Frankenmerge(層のスタッキング)
より急進的な手法:異なるモデルチェックポイントから異なる層をスタックする — 例えばモデル A から層0〜16、モデル B から層17〜32。学習を必要とせず、驚くべき能力を生み出すことがあるが、良い層の組み合わせを見つけるには実験が必要だ。MergeKit は passthrough マージ手法でこれをサポートする。

データセットの準備

データセットの質は、ファインチューニングの成功における単一で最も重要な要因である — モデルアーキテクチャ、学習時間、オプティマイザの選択よりも重要だ。キュレーションが不十分なデータセットは、他のすべてに関わらず悪い結果を保証する。

人間が執筆最高
最も高価

専門家が執筆した例;最高の信号対雑音比。重要な振る舞いに使用される。

GPT-4 / Claude が生成高い
中程度

フロンティアモデルによる合成生成。ドメインのカバレッジを大規模に立ち上げるのに適する。

Evol-Instruct / Magpie良好
低い

シード指示をより難しく多様なバリアントへと進化させる。WizardLM や OpenHermes で使用。

インターネットからフィルタリングばらつきあり
最も安価

積極的な品質フィルタリングを要する:重複除去、長さフィルタ、パープレキシティフィルタ、安全性フィルタ。

ShareGPT データ形式

json
{
  "conversations": [
    {"from": "system", "value": "You are an expert in EU AI regulation."},
    {"from": "human", "value": "Explain the risk categories in the EU AI Act."},
    {"from": "gpt", "value": "The EU AI Act categorizes AI systems into four risk levels..."}
  ]
}

大規模な合成データ生成

python
from openai import OpenAI  # or use Mistral/Llama locally

client = OpenAI()

def generate_training_example(topic: str, difficulty: str) -> dict:
    prompt = (
        f"Generate a challenging {difficulty}-level question about {topic} "
        "and a comprehensive expert answer."
    )
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.8,
    )
    content = response.choices[0].message.content
    # Parse and structure output (question/answer split)...
    return {"instruction": topic, "response": content}

推奨される指示の多様性の分布

質問応答
30%
執筆と要約
20%
コード生成とデバッグ
20%
分析と推論
15%
その他(翻訳、抽出など)
15%
データ汚染
テストセットの汚染はファインチューニングにおける評価問題の第1位だ。評価ベンチマーク(MT-Bench、HumanEval、MMLU)のいずれかが学習データに現れると、スコアは水増しされ無意味になる。学習前には必ず、学習セットと評価ベンチマークの間で n-gram の重複チェックを実行すること。

評価と反復

ファインチューニングのループは:学習 → ホールドアウトでの評価 → 失敗モードの診断 → データの改善 → 再学習。良い評価こそが、試行錯誤を体系的な改善へと変えるものだ。

MT-Bench

総合品質

8カテゴリ(執筆、数学、コーディングなど)にわたる80問のマルチターンベンチマーク。GPT-4 が各応答を1〜10で採点する。

AlpacaEval

指示遵守

GPT-4o が判定する、参照モデル(GPT-4o)に対するモデルの勝率。指示遵守の品質の高速な自動評価。

IFEval

形式準拠

検証可能な制約(例:「100語未満で応答する」)に対する指示遵守の精度。厳格版と緩和版の採点バリアントがある。

HumanEval / MBPP

コード生成

コード生成ベンチマーク。Pass@k 指標:k 回の試行で解決された問題の割合。グラウンドトゥルースの実行可能なテストケース。

LLM-as-Judge パターン

python
import json
from openai import OpenAI

client = OpenAI()

def evaluate_response(question: str, answer: str, judge_model: str = "gpt-4o") -> dict:
    prompt = f"""Rate the following AI assistant response on a scale of 1-10.

Question: {question}
Answer: {answer}

Evaluate: helpfulness (1-10), factuality (1-10), safety (1-10).
Return JSON: {{"helpfulness": N, "factuality": N, "safety": N, "rationale": "..."}}"""

    response = client.chat.completions.create(
        model=judge_model,
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"},
    )
    return json.loads(response.choices[0].message.content)
よくある評価の落とし穴
  • 長さバイアス:LLM の判定者は品質に関わらず長い応答を好む傾向がある。判定者を較正すること。
  • おべっか:モデルは自分の出力を高く採点する。別のモデルを判定者として使うか、人間による検証を行うこと。
  • 汚染:学習セット内のベンチマークデータはスコアを水増しする。常に重複を確認すること。
  • 単一指標の罠:一つの指標を最適化すると、しばしば他を損なう。バランスの取れたスコアカードを追跡すること。

実験トラッキングのテンプレート

Runベースモデル手法データセットMT-BenchAlpacaEval Win%備考
v1Llama-4-ScoutSFTUltraChat 200K7.470%ベースライン
v2Llama-4-ScoutSFT+DPO+ UltraFeedback8.076%+DPO で安全性が向上
v3Llama-4-ScoutSFT+DPO (r=16)+ UltraFeedback8.177%LoRA r=16 vs フル FT

ファインチューニング vs RAG vs プロンプトエンジニアリングの使い分け

ファインチューニングは強力だが、常に正しいツールとは限らない。決定は、何を変えようとしているか — 知識、振る舞い、形式、嗜好 — による。間違った選択は、数週間のエンジニアリングと計算資源を浪費する。

シナリオ最良のアプローチ理由
社内文書に回答を根拠づける必要があるRAG知識は変わりうる;FT は容易に更新できない
一貫したトーン/スタイルが欲しいSFTトーンは形式であり、知識ではない
ドメイン固有の用語の使用SFT + 少量データデフォルトの振る舞いを安価に変更する
特定の出力形式を扱う必要があるSFTスキーマ遵守は習得されるスキルである
有害な出力を減らすDPO / RLHF嗜好アライメントが直接これを狙う
推論能力が必要GRPO または R1 から蒸留推論パターンは学習可能である
新しい事実知識を追加するRAG(FT ではない)FT は記憶するが、出典を引用できない
大規模に API コストを削減する小さなモデルをファインチューニング狭いタスクで大規模モデルの品質に匹敵させる
プロトタイプ / 迅速な実験まずプロンプトエンジニアリング学習コストゼロ;まずコンセプトを検証する

LLM の階段

一番下から始めること。現在のレベルが本当に不十分なときにのみ登ること — 各段はコスト、複雑さ、レイテンシを加える。

1
プロンプトエンジニアリング
無料、即時、学習コストゼロ
2
Few-shot の例
コンテキストに例を追加する
3
RAG
取得した文書に回答を根拠づける
4
SFT
形式、スタイル、ドメイン知識を教える
5
DPO / RLHF
嗜好と安全性に整合させる
6
蒸留
タスク特化の小さなモデルに圧縮する

ファインチューニングすべきとき

  • 大規模で一貫したトーン/形式
  • ドメイン用語がデフォルトでなければならない
  • 特定の出力スキーマが必要
  • 狭いタスクでの API コスト削減
  • 嗜好/安全性のアライメントが必要

RAG を使うべきとき

  • 知識が頻繁に変わる
  • 回答に出典/ソースが必要
  • プライベート/独自の知識ベース
  • 大規模な文書コーパス(>1M tokens)
  • 再学習なしで更新する必要がある

ファインチューニングを避けるべきとき

  • 新しい事実知識を追加する(RAG を使う)
  • 迅速なプロトタイプまたは PoC 段階
  • 非常に小さいデータセット(<100例)
  • GPU 予算がない
  • プロンプティングで既に目標を達成している
ファインチューニングの準備はできましたか?

カスタム AI モデルを構築する

ドメイン特化のアシスタント、嗜好に整合したモデル、蒸留された本番デプロイのいずれが必要でも — 私たちのチームはそれらを構築し出荷してきました。あなたのユースケースについて話しましょう。

その他のガイド
AI スキル & ファインチューニングガイド:SFT、LoRA、RLHF、DPO とモデル蒸留 | Hyperion Consulting