mcpField
C
checkpoint-promotion

checkpoint-promotion

github.com/wshobsonテスト・品質41.9k2.7k 回インストール2 週間前に更新
リポジトリ

checkpoint-promotion について

学習済みチェックポイントをリリースできるか判定するファインチューニング用スキルです。データ品質、能力ドリフト、ペア評価、カナリア展開を審査し、PROMOTE または REJECT のレポートを作成します。

主な機能

  1. 014段階の昇格ゲート
  2. 02データ漏えいとラベルノイズの確認
  3. 03能力ドリフトとペア評価の検証
  4. 04ドリフト閾値と再実行条件の定義
  5. 05判定レポートと優先修正案の作成

活用シーン

  1. 01チェックポイントのエクスポート可否の判定
  2. 02学習データ漏えいや能力低下の検出
  3. 03過剰なドリフトに対する初回修正案の選定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/wshobson/agents --skill checkpoint-promotion

インストール後、Claude Code で/checkpoint-promotionを入力して読み込まれたか確認します。

同梱ファイルreferences/gate-templates.md

詳細

チェックポイントのプロモーション

プラグイン全体におけるフェーズ 5 のゲートです。クリーンに学習し、タスク指標を上回ったチェックポイントでも、以下の 4 つのステージをすべてクリアしなければ出荷されません。eval-harness-first がここで再実行されるスイートを構築しました——このスキルは、そのスイートのベースラインが何かを決定する場所です。

入力: 学習済みチェックポイント、eval-harness-first からの eval/baseline-<model>.json、および凍結された eval/drift-suite.yaml。 出力形式: promotion-report.md——4 ステージのエビデンスに加え、/finetune フェーズ 5 と /promote-checkpoint が直接消費する最終的な PROMOTE または REJECT の判定。

4 ステージゲート

各ステージは次のステージをゲートします——ステージ 2 での失敗は、ステージ 3 が実行されないことを意味します。ステージ 2 と 3 は 1 回の高コストな推論パスを共有するため、それらを同時に実行し、判定時にゲート順序を適用することは決定論的なアリーナで認められます(直列化しても節約にはなりません)。ジャッジベースのアリーナでは、依然として最初にステージ 2 を待つべきです——そこにこそ実際の節約があります。

  1. データ品質ゲート。 いかなる評価もチェックポイントに触れる前に: 学習セットを重複排除し、eval ゴールデンのリーク(trace-to-training-data の Hygiene セクションが防ぐために存在する、まさにその失敗)をチェックし、ラベルノイズをスキャンします。リークしたゴールデンで学習されたチェックポイントは、それ以降のすべてのステージを無効にします。
  2. ホールドアウト + 凍結された能力ドリフトスイート。 eval-harness-first の eval/drift-suite.yaml——MMLU/GSM8K/IFEval に加え 200~500 件のドメイン隣接項目——をチェックポイントに対して再実行し、以下のドリフトバジェット表に従ってベンチマークごとに baseline-<model>.json と差分を取ります。
  3. ベースとのペアアリーナ。 位置ランダム化ジャッジ、チェックポイント対ベースモデル、同じプロンプト——または、ハーネス内のすべてのグレーダーが決定論的である場合(LLM ジャッジなし、位置ランダム化はそこでは該当なし)は references/gate-templates.md の決定論的ペア比較バリアントを使用します。ホールドアウトでの勝利がライブアリーナで敗北するなら出荷されません——ステージ 2 の数値とステージ 3 の判断は一致しなければなりません。凍結されたゴールデンでの勝利とペア比較での敗北は、説明し消すべき不一致ではなく、実際のシグナルです。
  4. カナリア。 本番トラフィックに到達するあらゆるチェックポイントに対する、自動ロールバック付きの 5~10% の層化ロールアウト。ローカルのみのユーザーはステージ 3 で停止します——ローカルデプロイのためにステージ 4 をスキップすることは、近道ではなく正しい停止点です。
ドリフトバジェット
ドリフト (pts)判定
≤1ノイズ——続行
2–5決定する前にシード変動で再実行
>5ハード失敗——タスク利得による例外なし

5pt の行は他の行に関係なく支配します: ターゲットタスクで 8 ポイント獲得し、汎用能力で 6 ポイント失ったチェックポイントは、依然としてここで失敗します——タスクの改善がドリフトバジェット違反を買い戻すことは決してありません。

項目数は便宜ではなくバジェットから導出されます: 5pt ハード失敗閾値の半分未満の半幅に対する厳密な n は、典型的な精度(p≈0.7)で約 1,300 です。n=200 は実用的な下限です(同じ p で ±6pt の半幅、n=50 で ±13pt)——すべての判定に半幅を報告し、それより小さいマージンは PASS/ハード失敗ではなく REJECT (uncertain) として扱ってください。完全な計算と 5 回実行の警告例: references/gate-templates.md。

RERUN は判定ではありません。 2–5pt のドリフトは、シード変動の再実行が完了した後にのみ PROMOTE または REJECT を生み出します——PROMOTE は ≤1pt(ノイズ)に戻ることを必要とします。依然として >1pt の再実行は——2–5pt 帯でも >5pt 違反でも同様に——ステージ 2 をハード REJECT に解決します。ステージ 2 がまだ RERUN を示している状態で、判定セクションに到達するレポートはあってはなりません。

破滅的忘却

管理されていない LoRA ファインチューニングは 実際の汎用能力を失い、 それを捉えるのがステージ 2 です:

  • 管理なしで約 43% の知識喪失 — リプレイなし、正則化なし。
  • 基本的な管理で約 10% — 何らかのリプレイ、または保守的な LR。
  • リプレイ + EWC で約 3% — 規律あるケース。
  • 汎用データのリプレイミックス 10~30% が標準的な緩和策 — 対象タスクのデータだけでなく 汎用ドメインのデータを トレーニングに混ぜます。

チェックポイントがステージ 2 の 5 ポイント超のハード不合格に達した場合、 このエスカレーションラダーを順番に進めます — このスキルと references/gate-templates.md の両方が指し示す唯一の正典的な順序です:

  1. リプレイミックスの割合を調整する — 行を追加するのではなく、入れ替える (追加すると、割合と 合計オプティマイザステップが 交絡します)。少量実行規模(<~100 ステップ)では用量は単調ではありません — 入れ替えた後は必ずドリフトを再確認します。
  2. 学習率を下げる。
  3. エポックを減らす。
  4. より小さな LoRA ランク — lora-qlora-recipes と preference-optimization が トレーニング実行向けに調整するのと同じ ランク/LR のレバーを、 ここでは逆方向に適用します。

この順序はデフォルトであり、 法則ではありません:単一の ビフォー/アフターの実行ペアから得られる 是正ガイダンスは仮説です — いずれかのレバーが 反転を生じたら低信頼度とラベル付けし、 次の段を盲信するよりも シード変動の反復を優先してください。 ドリフト違反を解消しても 成功基準の指標が目標を下回るレバーは、 ラダーを降り続ける理由ではなく、 人間が判断すべき両面のトレードオフです。 両方の注意点の背後にある完全な 推論と 5 回実行の軌跡: references/gate-templates.md。

ドリフトスイートの 指示の再利用を開示してください。 リプレイ行が ドリフトハーネスの正確な 指示表現をコピーしている場合(単に ソース項目が重複していないだけでなく)、その ベンチマークのリプレイ後のスコアは 上限になります — 予算ぎりぎりの合格を クリーンとして扱う前に、 指示に慣れているとフラグを立てるか、 言い換えで再プローブしてください。

判定

promotion-report.md は 4 つのステージすべてを セクションとして扱い、 必ず終端の判定で終わらなければなりません:PROMOTE または REJECT、 それを生み出したエビデンス、 そして判定が REJECT の場合には 正確に 1 つの最優先の是正策。 テンプレート:references/gate-templates.md。 他のスキルが解析する終端の契約:

## Verdict

REJECT

Evidence: domain-adjacent drift
suite dropped 6.2pt (threshold:
>5pt hard fail) despite +8pt on
the target task.

Top remediation: swap the
replay-mix fraction from 10%
toward 20%, holding step count
constant.
  • REJECT は結果であり、 エラーではありません。 ステージ 2 の ドリフト予算または ステージ 3 のアリーナ比較に失敗したチェックポイントは、 その役割を果たしたのです。REJECT を このスキルの再実行が必要な失敗した実行として 扱わないでください。それは機能するゲートの 正しい出力です。
  • メニューではなく、 1 つの是正策。 エビデンスのセクションは 観察されたすべてを列挙してかまいませんが、 判定のセクションは上記のエスカレーションラダーに従い、 単一の最も効果の高い修正を挙げます。 3 つの可能な修正の間で どっちつかずのレポートは、 このスキルが存在する理由である 優先順位付けを行っていません。
  • 自動再トレーニングはなし。 この スキルは判定とレポートを 生み出すのであり、再トリガーされた トレーニング実行ではありません。REJECT は 是正策を finetuning-method-selection または 関連するトレーニングスキルにおける 人間の判断に戻します。

関連スキル

  • eval-harness-first — この スキルが再実行して差分を取る ドリフトスイートとベースラインを所有します。 baseline-<model>.json がなければ ゲートする対象が何もありません。
  • quantized-export — PROMOTE 判定の後に唯一有効な次のステップ。
  • preference-optimization と lora-qlora-recipes — 破滅的忘却の エスカレーションパスにおける LR とランクのレバーを所有します。 このスキルは違反を診断し、 それらのスキルはそれを引き起こした 設定を所有します。
  • dataset-curation — エスカレーションラダーの 最初の段が適用するリプレイミックスの 構築レシピを所有します。

4 つのステージすべて、ドリフトスイートの スコアリング表、ペアアリーナプロトコル(項目 数、位置のランダム化、勝率しきい値)、 リプレイミックス設定の例を含む完全な promotion-report.md テンプレート: references/gate-templates.md。

コメント