Promotion de Checkpoint

La porte Phase 5 pour l'ensemble du plugin : un checkpoint qui s'entraîne proprement et bat sa métrique de tâche ne se déploie toujours pas sans passer les quatre étapes ci-dessous. eval-harness-first a construit la suite qui s'exécute ici — cette skill est l'endroit où la baseline de cette suite décide quelque chose.

Entrée : un checkpoint entraîné, eval/baseline-<model>.json issu de eval-harness-first, et le eval/drift-suite.yaml gelé. Format de sortie : promotion-report.md — les preuves des quatre étapes plus un verdict terminal PROMOTE ou REJECT que /finetune Phase 5 et /promote-checkpoint consomment directement.

La Porte à Quatre Étapes

Chaque étape bloque la suivante — un échec à l'étape 2 signifie que l'étape 3 ne s'exécute pas. Les étapes 2 et 3 partagent une passe d'inférence coûteuse unique, donc les exécuter concurremment et appliquer l'ordre de la porte au moment du verdict est autorisé sur une arena déterministe (rien de gagné en sérialisant) ; une arena basée sur un juge devrait tout de même attendre l'étape 2 en premier — c'est là que se trouvent les vraies économies.

1. Porte de qualité des données. Avant que toute évaluation ne touche le checkpoint : dédupliquer l'ensemble d'entraînement, vérifier la fuite de goldens d'éval (l'échec exact que la section Hygiène de trace-to-training-data existe pour prévenir), et scanner le bruit d'étiquetage. Un checkpoint entraîné sur des goldens fuites invalide chaque étape ultérieure.
2. Suite de dérive de capacité retenue + gelée. Réexécuter eval/drift-suite.yaml de eval-harness-first — MMLU/GSM8K/IFEval plus 200–500 éléments adjacent au domaine — contre le checkpoint et comparer à baseline-<model>.json par benchmark par rapport au tableau Drift Budget ci-dessous.
3. Arena appairée vs. base. Juge randomisé en position, checkpoint vs. modèle de base, mêmes prompts — ou la variante de comparaison appairée déterministe dans references/gate-templates.md quand chaque grader de la harness est déterministe (pas de juge LLM ; randomisation de position sans objet là). Une victoire retenue qui perd l'arena live ne se déploie pas — les chiffres de l'étape 2 et les jugements de l'étape 3 doivent s'accorder ; une victoire sur des goldens gelés et une perte en comparaison appairée est un vrai signal, pas une discordance à expliquer.
4. Canary. Déploiement stratifié de 5–10% avec auto-rollback pour tout checkpoint atteignant le trafic de production. Les utilisateurs locaux uniquement s'arrêtent à l'étape 3 — ignorer l'étape 4 pour un déploiement local est le point d'arrêt correct, pas un raccourci.

Budget de Dérive

La ligne >5pt gouverne indépendamment des autres : un checkpoint qui a gagné 8 points sur la tâche cible et a perdu 6 points de capacité générale échoue toujours ici — l'amélioration de tâche n'achète jamais une violation du budget de dérive.

Le nombre d'éléments dérive du budget, pas de la commodité : le n strict pour une demi-largeur inférieure à la moitié du seuil de rupture dure de 5pt est ~1 300 à la précision typique (p≈0,7) ; n=200 est un plancher pragmatique (±6pt demi-largeur à ce même p, n=50 ±13pt) — rapporter la demi-largeur à chaque verdict, et traiter une marge plus petite que elle comme REJECT (uncertain), pas PASS/ÉCHEC DUR. Maths complets et exemple précautionnaire à 5 exécutions : references/gate-templates.md.

RERUN n'est pas un verdict. Une dérive de 2–5pt produit uniquement PROMOTE ou REJECT après que la réexécution à variation de seed soit terminée — PROMOTE nécessite d'atterrir de nouveau à ≤1pt (bruit) ; toute réexécution encore >1pt — bande de 2–5pt ou violation >5pt également — résout l'étape 2 à un REJECT dur. Aucun rapport ne peut atteindre la section Verdict avec l'étape 2 affichant toujours RERUN.

Oubli Catégorique

Le fine-tuning LoRA non géré perd une vraie capacité générale, et l'étape 2 c'est ce qui l'attrape :

• ~43% perte de connaissances non gérée — pas de rejeu, pas de régularisation.
• ~10% avec gestion basique — un certain rejeu ou un LR conservateur.
• ~3% avec rejeu + EWC — le cas discipliné.
• Le mélange de rejeu de données générales de 10–30% est la mitigation standard — mélanger les données du domaine général dans l'entraînement plutôt que les données de tâche cible seules.

Si un checkpoint atteint l'échec dur >5pt à l'étape 2, travaillez cette escalade de rung dans l'ordre — l'ordre canonique unique auquel cette skill et references/gate-templates.md pointent :

1. Ajuster la fraction du mélange de rejeu — permuter les lignes, ne pas les ajouter (l'ajout confond fraction avec les étapes d'optimiseur totales). La dose n'est pas monotone à petite échelle (<~100 étapes) — re-vérifier la dérive après tout permutation.
2. Baisser le taux d'apprentissage.
3. Moins d'epochs.
4. Un rang LoRA plus petit — les mêmes leviers de rang/LR que lora-qlora-recipes et preference-optimization ajustent pour l'exécution d'entraînement, appliqués ici en inverse.

Cet ordre est un défaut, pas une loi : les conseils de remédiation d'une paire de résultats avant/après uniques sont une hypothèse — l'étiqueter faible confiance une fois que tout levier produit une inversion, et préférer une répétition de variation de seed plutôt que de faire confiance au prochain rung aveuglément. Un levier qui efface la violation de dérive mais abaisse une métrique de critère de succès en-dessous de la cible est un compromis bilatéral pour un humain, pas une raison de continuer à descendre l'échelle. Raisonnement complet et trajectoire à 5 exécutions derrière les deux avertissements : references/gate-templates.md.

Divulguer la réutilisation des instructions de la suite de dérive. Une ligne de rejeu copiant l'expression d'instruction exacte de la harness de dérive (pas seulement des éléments de source disjoints) rend le score post-rejeu de ce benchmark une limite supérieure — le signaler comme instruction-familier, ou ré-sonder avec une paraphrase, avant de traiter un passage près du budget comme propre.

Le Verdict

promotion-report.md couvre les quatre étapes en tant que sections et doit se terminer par un verdict terminal : PROMOTE ou REJECT, la preuve qui l'a produit, et exactement une remédiation supérieure quand le verdict est REJECT. Template : references/gate-templates.md. Le contrat terminal que d'autres skills analysent :

## 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 est un résultat, pas une erreur. Un checkpoint qui échoue le budget de dérive de l'étape 2 ou la comparaison d'arena de l'étape 3 a fait son travail. Ne traitez pas un REJECT comme une exécution échouée nécessitant une réexécution de cette skill ; c'est la sortie correcte d'une porte fonctionnelle.
• Une remédiation, pas un menu. Les sections de preuve peuvent lister tout ce qui a été observé ; la section verdict nomme le correctif unique le plus pertinent selon l'escalade ci-dessus. Un rapport qui balance à travers trois corrections possibles n'a pas fait la priorisation que cette skill existe pour faire.
• Pas de réentraînement automatique. Cette skill produit un verdict et un rapport, pas une exécution d'entraînement re-déclenchée. Un REJECT redonne la remédiation à une décision humaine à finetuning-method-selection ou à la skill d'entraînement pertinente.

Skills Associées

• eval-harness-first — possède la suite de dérive et la baseline que cette skill réexécute et compare ; pas de baseline-<model>.json signifie rien à bloquer.
• quantized-export — la seule étape valide suivante après un verdict PROMOTE.
• preference-optimization et lora-qlora-recipes — possèdent les leviers LR et rang dans le chemin d'escalade d'oubli catégorique ; cette skill diagnostique la violation, ces skills possèdent la config qui l'a causée.
• dataset-curation — possède la recette de construction du mélange de rejeu que le premier rung de l'escalade applique.

Template complet promotion-report.md avec les quatre étapes, le tableau de scoring de la suite de dérive, le protocole d'arena appairée (nombre d'éléments, randomisation de position, seuil de taux de victoire), et un exemple de configuration du mélange de rejeu : references/gate-templates.md.