building-finetuning-datasets

ファインチューニング用データセットの構築

ファインチューニングの成否を決めるのは、そのデータセットです。ハイパーパラメーターは学習が収束するかどうかを決めますが、データセットはモデルがどのようなものになるかを決めます。期待外れに終わるファインチューニングの多くは、誤った内容を学習させるデータを使い、設定自体は正しく行われています。

大きな問題の原因となる失敗は主に2つあり、どちらもサンプルを1つ生成する前に対処できます。検索で扱うべき事実を学習させてしまうことと、モデルが他のすべての面で悪化したことを検知する手段がないことです。

ゲート 1：これは知識の問題ですか？

目標に「Xについて知っているようにする」という内容が含まれている場合（製品名、手順書の事実、最新の在庫、ポリシーの詳細など）、その部分は検索の問題であり、ファインチューニングは適切な手段ではありません。

モデルは事前学習で事実を獲得し、ファインチューニングでは、すでに持っている知識の使い方を学びます。実際に新しい事実を含むサンプルは、既存の知識と一致するサンプルよりもはるかにゆっくりと学習されます。そして、ようやく学習されると、モデルがハルシネーションを起こす傾向が線形に高まります（Gekhman et al.、EMNLP 2024、クローズドブックQAで測定）。この増加率は、新たに教えた項目だけでなく、評価全体にわたって測定されます。そのため、事実性全般に悪影響が及び、新しい事実を定着させるために学習を続けるほど、その悪影響は大きくなります。

先に進む前に、依頼内容を明確に分けてください。

目標の一部	対応先
事実、文書、エンティティ、変化する情報全般	RAG
形式、構成、組織内のスタイル、口調	ファインチューニング
タスクの手順、ツール呼び出しの構文、推論スタイル	ファインチューニング
検索したコンテキストに対するドメイン語彙や質問の形式	ファインチューニング。ただし、推論時には引き続き事実を検索

どの部分をどこに振り分けたかを明示してください。1つのことを依頼するユーザーは、通常、その両方の解決を望んでいます。検索部分を暗黙のうちに学習データへ取り込んではいけません。

ゲート 2：どの手法を使いますか？

学習段階とパラメーター予算は、それぞれ独立して選択します。決める前に references/choosing-technique.md を読んでください。プロンプト／RAG／デコーディングの代替手段、継続事前学習とSFTと選好最適化とRLの比較、DPO／KTO／ORPO／SimPOの選択、フルFTとLoRAとQLoRAの比較、必要な学習段階の順序について説明しています。

簡単に言うと、正しい出力を書けるならSFTです。2つの出力のどちらが優れているかしか判断できないなら、選好最適化です。スクリプトで正しさを検証でき、SFTが頭打ちになっているなら、RLです。パラメーター予算のデフォルトはLoRA、VRAMに制約がある場合はQLoRAです。

ゲート 3：ベースモデルはすでにそれを実行できますか？

能力や振る舞いに関するデータを生成する前に、ベースモデルでその能力や振る舞いをテストしてください。対象とするケースをいくつか選び、数十件ほど試し、測定可能な失敗が確認できたものだけを残します。これは、ゲート 1 の知識に関するルールを一般化したものです。ファインチューニングは、モデルが誤るものに対して行うものであり、モデルがすでに処理できるデータで学習させても、中立ではありません。

このコストは実際に発生し、記録されています。

• 労力の浪費。 あるチームが振る舞いのデータセットを構築する際、ベースモデルをテストしたところ、ある振る舞い全体について、再現性のある失敗パターンがないまま約 94% の精度で処理できることがわかりました。そのチームは、何も学習させない 150 件のデータを削除しました。
• 実際に起きる性能低下。 同じ限定的な振る舞いのファインチューニングでは、約 750 件のデータを使った結果、4 つの推論ベンチマークで汎用能力の測定可能な低下が起きました（小学校レベルの算数で約 10〜16 ポイント低下）。ベンチマーク一式が実行されるまで誰も気づきませんでした。評価用の分割データがなかったためです。追加するデータはどれも、別の領域の能力を損なう可能性があります。何も教えないデータは、見返りなしにそのコストを発生させます。

したがって、テストは任意の念入りな確認ではなく、データセットに何を含めるかを決めるためのものです。失敗が確認されたケースを残し、判断が曖昧なケースは再サンプリングしてください（3 回中 1 回の拒否はサンプリングノイズであり、失敗ではありません。単発の拒否評価の精度は約 92% にすぎません。Larsen et al. 2025）。ベースモデルがすでに処理できるものは削除してください。確認されたカテゴリは二値ではなく、割合（「3 回中 2 回」「3 回中 3 回」）で報告してください。「3 回中 2 回」の確認は要注意項目であって、解決済みではありません。純粋なノイズでも約 26% の確率で確認されるためです。また、次の学習実行後に再度テストすべきカテゴリでもあります。

成果物

ファインチューニング用データセットは、単なるサンプルのファイルではありません。8つの要素で構成され、どれか1つでも欠けている引き渡し物は評価も再現もできません。以下の順序で用意してください。この順序が方法そのものです。

1. eval/ — 最初に作成する保留評価スイート。 実例のみを使い、生成前に確保します。3つのサブセットがあります。task（対象の振る舞いを示す保留実例）、retention（ベースモデルがすでに合格する一般能力のプローブ）、behavior（維持すべき拒否、安全性、トーンの不変要素）。
2. baseline.json — 3つすべてのサブセットで採点したベースモデルの結果。 トレーニング開始前に用意します。これがなければ分母がなく、「よさそう」という感想は結果になりません。
3. taxonomy.md — データがカバーすべき軸と、各セルの目標件数。 多様性は条件として与える内容を変えることで生まれるため、生成前に軸を明文化し、フィルタリング後に再集計する必要があります。空のセルは次の生成ラウンドの対象であり、許容できる結果ではありません。
4. train.jsonl / val.jsonl / test.jsonl をメッセージ形式で作成し、ソース文書単位で分割します。これにより、合成された兄弟データが分割をまたぐのを防ぎます。3つのレベルすべて（完全一致、近似重複、意味的重複）で重複を排除し、報告する予定のすべての評価セットとの混入も除去します。
5. リプレイ用ミックス — タスクデータと一般的な指示データを明示した比率で混ぜ合わせ、モデルがすでに持っている能力を失わないようにします。
6. 検証済みのフォーマット契約 — データセット形式に合う損失マスキングフラグ（メッセージ形式ならassistant_only_loss、プロンプト／補完形式ならcompletion_only_loss）、チャットテンプレートが実際に出力するEOSトークン、そしてトレーニングバッチを1つデコードしてその両方を確認した結果を記します。誤ったフラグを使うとユーザーのターンで学習し、誤ったEOSを使うとモデルが停止しなくなります。どちらも損失曲線の悪化には表れないため、これは習慣ではなく確認済み成果物として扱います。
7. card.md — 来歴情報。 シードソース、生成モデルとバージョン、生成プロンプト、フィルターとしきい値、重複排除と混入除去の方法、taxonomyのセルごとの件数、ライセンスと利用条件を記します。
8. config.yaml — トレーニング設定。 過学習の進行中に確認できるよう、評価曲線を有効にします。

評価セットを先に作成することで、データセットが生成モデルの出力内容に合わせて最適化されるのを防げます。

文章成果物はすべて、まず骨組みを作り、編集ごとに1つのセクションを仕上げてください。 1回のツール呼び出しで出力できるのは、およそ1,000トークンまでです。計画書、taxonomy、cardはいずれもそれを超えるため、一度に書き込もうとすると文字列の途中で切れて呼び出しが失敗します。まず見出しと各見出しの下に1行の仮文を置いてファイルを作り、その後、編集ごとに仮文を1つずつ置き換えてください。この方法に切り替えるのではなく、最初からこう進めましょう。骨組みを作る手間はかからず、どちらの方法でも必要な編集回数は同じです。

手作業ではなく、スクリプトで生成する

パイプラインを書くのはあなたですが、データを書くのはパイプラインです。 JSONL ファイルにトレーニング例を一つずつ自分で書き出す方法は、必要な例がどれほど少なくても、この作業には適していません。

• スケールしません。 1例あたり約800トークンの例が300件あれば、どのエージェントが出力できる量をはるかに超えており、データセットを作成できたと思い込んでいるうちに、ファイルが途中で切れてしまいます。
• 再現できません。 再生成できないデータセットは、修正もできません。スクリプトにシード、固定した生成モデル、バージョン管理されたプロンプトを組み合わせれば、欠陥を見つけたときに再実行できます。
• 生成のループは、本当にループです。 タクソノミーのセルに向けて生成 → 検証 → フィルタリング → 重複排除 → カバレッジを再集計 → 不足しているセルに向けて生成。このサイクルは何度も繰り返されるため、手作業ではできません。
• フィルタリングには、いずれにせよコードが必要です。 MinHash による近似重複検出、埋め込みの最近傍しきい値、n-gram による汚染除去は、目視でできる作業ではありません。

そのため、手作業で作成する成果物は 入力 です。つまり、タクソノミー、生成プロンプト、シード例、フィルタリングのしきい値です。それ以降のものは、何かを実行して生成します。

このスキルに含まれる scripts/generate.py と scripts/curate.py は、実用的なリファレンスパイプラインです。タクソノミーに基づく生成と再開機能に加え、重複排除、汚染除去、カバレッジレポートを備えています。内容を確認して、タスクに合わせてプロンプトとタクソノミーを調整し、実行してください。これは出発点であり、フレームワークではありません。パイプラインをゼロから書くより、これらを拡張することをおすすめします。

作業の順序

digraph finetune_data {
    rankdir=TB;
    "Split knowledge from behavior" [shape=box];
    "Behavior part non-empty?" [shape=diamond];
    "Route to RAG; stop" [shape=doublecircle];
    "Choose stage + parameter budget" [shape=box];
    "Write eval suite from real data" [shape=box];
    "Score base model -> baseline.json" [shape=box];
    "Define taxonomy of axes to cover" [shape=box];
    "Generate wide" [shape=box];
    "Verify, filter, dedup, decontaminate" [shape=box];
    "Coverage gaps remain?" [shape=diamond];
    "Blend replay data" [shape=box];
    "Train with eval curve" [shape=box];
    "Gates pass vs baseline?" [shape=diamond];
    "Ship with card.md" [shape=doublecircle];
    "Diagnose: data or config?" [shape=box];

    "Split knowledge from behavior" -> "Behavior part non-empty?";
    "Behavior part non-empty?" -> "Route to RAG; stop" [label="no"];
    "Behavior part non-empty?" -> "Choose stage + parameter budget" [label="yes"];
    "Choose stage + parameter budget" -> "Write eval suite from real data";
    "Write eval suite from real data" -> "Score base model -> baseline.json";
    "Score base model -> baseline.json" -> "Define taxonomy of axes to cover";
    "Define taxonomy of axes to cover" -> "Generate wide";
    "Generate wide" -> "Verify, filter, dedup, decontaminate";
    "Verify, filter, dedup, decontaminate" -> "Coverage gaps remain?";
    "Coverage gaps remain?" -> "Generate wide" [label="yes, target the empty cells"];
    "Coverage gaps remain?" -> "Blend replay data" [label="no"];
    "Blend replay data" -> "Train with eval curve";
    "Train with eval curve" -> "Gates pass vs baseline?";
    "Gates pass vs baseline?" -> "Ship with card.md" [label="yes"];
    "Gates pass vs baseline?" -> "Diagnose: data or config?" [label="no"];
    "Diagnose: data or config?" -> "Generate wide";
}

カバレッジの不足を受けて戻るこのループは、ほとんどのパイプラインで省かれるステップです。生成は安価で、フィルタリングはデータを減らすため、幅広く生成してから絞り込みます。その後、空になったタクソノミーのセルを確認し、同じ条件なしのループを再実行して同じ傾向のデータを得るのではなく、不足しているセルに 特化して 生成します。

数量より品質を、数値で判断する

固定予算 の範囲内では、厳選された数百件は、フィルタリングされていない数万件よりも 一般的な指示への追従とスタイル において優れています。これは LIMA（厳選した1,000件が5万件と競合）、AlpaGasus、LIMO（推論トレース817件）を通じて一貫して得られた結果です。これらの論文が測定したのはこの点であり、ベースモデルの事前傾向を覆す 場合（安全性による拒否や、強いデフォルト動作など）には当てはまりません。その場合、振る舞いには最低限の 件数 と、データ全体に占める最低限の 割合 の両方が必要です。また、少数のシナリオを言い換えたバリエーションばかり集めるのは、「少ないほどよい」にとって最も不利な条件です。品質優先の結論に飛びつく前に、自分がどちらの条件に当てはまるかを判断してください。一般的な範囲は次のとおりです。

目標	例の数
形式／構造の変換	100–1,000
スタイル、トーン、話し方	500–2,000
分類／抽出	クラスあたり50–500
一般的な指示への追従	1,000–10,000
推論の蒸留	検証済みトレース800–10,000件

実行結果が期待を下回ったとき、データを倍に増やすのはたいてい誤った反応です。特に、追加する行がすでにあるシナリオの言い換えである場合は、明確に誤りです。更新予算が固定されているとき、少数のデータを繰り返すと、スケールアップと同じように世界知識の忘却が起きます。また、狭く反復的なデータセットは、モード崩壊を招く条件です。保持の改善に役立つデータ面での対策は、対象の振る舞いを増やすことではなく、新しい一般的なリプレイデータを追加することです。次の順番で確認してください。まず LR（保持側で最初に確認）、次に対象のモジュール、その次に多様性、最後にミックスです。

劣化ゲート

ファインチューニングを成功と判断する前に、baseline.json に対してこれらを実行してください。それぞれが文書化された失敗モードに対応しており、タスク指標を満たしながらこれらに失敗することが、問題のあるモデルがリリースされる最も一般的な原因です。

ゲート	チェック項目	失敗した場合の対応
タスク	保留しておいた実例で目標指標が改善している	ファインチューニングの効果がありませんでした — LR とターゲットモジュールを確認してください
保持	ベースモデルがすでに合格していた能力について、実行ごとのノイズを上回っている（n において ≥1 SE）	いくつかのベンチマークで数ポイント低下するのは LoRA-SFT でよくある結果であり、「壊滅的」ではありません（文献でいう壊滅的な状態とは、SLIM の MMLU→0.00 のように、ベンチマークのスコアがほぼ 0 になることです）。次の順に対処してください：LR を下げる（保持側の調整については lora-configuration.md を参照）し、リプレイミックスを追加する — これらはエビデンスに裏付けられた調整方法です — 次に検証用分割と小さな lora_dropout を追加して低コストで過学習を抑え、その後エポック数を減らします
事実性	ハルシネーション率がベースモデルを上回っていない	未知の事実を学習させてしまいました — それらは RAG に移してください
安全性	拒否動作が維持されている	完全に無害なデータだけでも安全性のアラインメントは劣化します（Qi et al., ICLR 2024） — ミックスに安全性の例を追加してください
形式	出力が終了し、解析できる	EOS またはチャットテンプレートの問題であり、データの問題ではありません
多様性	出力が一つの言い回しに偏っていない	過学習です — エポック数を減らす、LR を下げる、または alpha を 0.5 倍にしてください

タスク指標だけを測定すると、ある項目で 10 ポイント改善する一方、ほかのすべてで 15 ポイント悪化したモデルがリリースされてしまいます。

参考資料とスクリプト

必要な参考資料だけを読み、5 つすべてを読み込まないでください。

ファイル	内容
references/choosing-technique.md	RAG／プロンプトの代替手法、CPT と SFT と DPO と RL の比較、DPO／KTO／ORPO／SimPO、フルファインチューニングと LoRA と QLoRA、段階の順序
references/synthetic-generation.md	品質・多様性・複雑さのトレードオフ、Self-Instruct、Evol-Instruct、Magpie、ペルソナ、文書に基づく QA、セルフチャット、軌跡、蒸留、検証と評価者のバイアス、モデル崩壊、ライセンス
references/data-quality.md	評価セットの構築、規模、重複排除のレベル、汚染除去、バランス、ベースモデルの事前分布を上書きするためのミックス比率、メッセージ形式、損失マスキング、EOS、チャットテンプレート、分割の漏洩、データセットカード
references/lora-configuration.md	ランク、alpha、ターゲットモジュール、LR、スケジュール、パッキング、回帰対策としてのドロップアウト／検証、rsLoRA／DoRA／LoRA+／PiSSA、設定例、症状と調整項目の対応表、マージ
references/avoiding-degradation.md	忘却のメカニズム、リプレイの比率とソース、未知の知識と未知の能力の検出、安全性の回帰、過学習と崩壊の兆候、ゲートのしきい値

scripts/ は実行可能なリファレンスパイプラインです — 書き直さず、調整して使ってください：

スクリプト	内容
scripts/generate.py	あらゆる OpenAI 互換エンドポイントに対する分類体系主導の生成を行い、中断後の再開に対応し、各行の来歴を記録します
scripts/curate.py	不正なデータの削除 → 完全一致／近似重複の排除 → 評価ファイルに対する汚染除去 → セルごとのカバレッジレポート（標準ライブラリのみ）

よくある間違い

間違い	問題点
事実を注入するためのファインチューニング	学習に時間がかかり、学習させるほど幻覚が直線的に増加します
alpha = 0.5r	逆です。alpha = 2r（または r）を使い、alpha/r を 1 以上に保ちます
アテンションのみを対象にする	MLP 層がより高ランクの更新を担います。すべての線形層を対象にしてください
拡張後に分割する	合成データの兄弟サンプルが訓練用とテスト用にまたがり、スコアが実態を反映しなくなります
ベースモデルの測定を行わない	分母がなく、性能低下を把握できません
リプレイデータを混ぜない	モデルはタスクを習得する一方で、それ以外の能力を失います
多様性を高めるために温度を上げる	多様性はサンプリングノイズではなく、ペルソナや分類体系のカテゴリなど、条件付けを変えることで得られます
検証されていない LLM 評価者を信頼する	位置、冗長さ、自己／親近性への選好バイアスは、評価すべきものとは異なるものを測定します。コードの品質については、決定論的なチェック（構文、実行、スキーマ）が検証済みの評価層です。評価者による順位付けは参考情報であり、合否判定のゲートではありません
完全一致のみを重複排除する	合成データのパイプラインでは、完全一致のハッシュでは見つからない、意味的に近い重複データが過剰に生成されます
小規模なデータセットをパッキングする	数百行程度ではスループット向上の効果がなく、複数ターンのデータでは相互汚染のリスクもあります。無効のままにしてください
ベースモデルがすでに合格する範囲を学習させる	せいぜい行数の無駄ですが、追加した行によって別の能力が損なわれる可能性もあります
検証用分割を設けない	評価損失の曲線がなければ、モデルのリリースまで性能低下を把握できません
教師モデルの利用規約を無視する	大手 API プロバイダーは、自社の出力を使った学習を制限しています。これは開発ではなく、リリースを妨げます