Validation du pipeline EAGLE3

Vérifier qu'une exécution du pipeline EAGLE3 s'est déroulée correctement et répond aux critères de qualité.

Step 0 — Identifier l'expérience

Trouver le répertoire d'expérience le plus récent (ou demander le chemin à l'utilisateur) :

ls -td experiments/cicd/cicd_* | head -5

Chaque répertoire d'expérience contient un sous-répertoire par task (numérotés 0–3), chacun contenant un fichier log dont le nom varie selon le mode de lancement (Slurm : sbatch_*.out, Docker local : *.log).

Step 1 — Vérifier les résultats des tasks

Parcourir les fichiers log en général et lire la fin de chacun :

find experiments/<exp_id>/ -type f \( -name '*.out' -o -name '*.log' \) | sort | while read -r f; do
  echo "=== $f ==="; tail -50 "$f"; echo
done

Les 4 tasks doivent se terminer sans erreur. Chercher :

• exit code: 0 ou pas d'erreur — succès
• DUE TO TIME LIMIT — timeout
• FAILED / signal / exception traceback — échec

Si une task a échoué, suggérer d'exécuter /eagle3-triage à la place.

Step 2 — Vérifier l'existence des artefacts

Vérifier que chaque étape a produit la sortie attendue (les artefacts se trouvent sur le cluster à /scratchspace/). Confirmer via les messages de log :

Step 3 — Vérifier le taux d'acceptation

Dans le log de task_3, trouver :

Average Acceptance Length {'accept': X, 'count': Y, 'ratio': Z.ZZ}

Le champ ratio est le taux d'acceptation (AR).

Si le log affiche AR ... < lower bound, l'exécution a déjà déclenché un échec de seuil (exit code 1).

Step 4 — Vérifier la qualité de l'entraînement

Dans le log de task_2, chercher :

• Perte d'entraînement finale — doit être décroissante, pas NaN
• Validation AR pendant l'entraînement (si training.ar_validate_steps était défini)
• Nombre d'étapes d'entraînement — confirme la durée complète de l'entraînement

Step 5 — Produire un rapport de validation

## Rapport de validation du pipeline EAGLE3

**Expérience :** <exp_dir>
**Modèle :** <model_name>
**Date :** <date>
**Config du pipeline :** <yaml_path>

### Statut des étapes
| Étape | Task | Statut | Notes |
|-------|------|--------|-------|
| 0 | Synthèse de données | PASS/FAIL/TIMEOUT | N samples générés |
| 1 | Dump d'états cachés | PASS/FAIL | N fichiers .pt |
| 2 | Entraînement + export | PASS/FAIL | Perte finale : X.XX |
| 3 | Benchmark | PASS/FAIL | AR : X.XX |

### Taux d'acceptation
- AR MT-Bench : X.XX (seuil : >= 2.1) — PASS/FAIL

### Résumé de l'entraînement
- Perte finale : X.XX
- Étapes d'entraînement : N
- AR pendant l'entraînement : X.XX (si validé)

### Résultat global : PASS / FAIL
<résumé d'une ligne>

Step 6 — Suggérer les prochaines étapes

Si PASS :

• Enregistrer le résultat vérifié (et le chemin du checkpoint) dans le suivi de triage interne de l'équipe
• Ce modèle est maintenant candidat pour être ajouté comme exemple de launcher dans une PR dédiée

Si FAIL :

• Identifier quelle étape ou métrique a échoué
• Suggérer d'exécuter /eagle3-triage pour diagnostiquer
• Pour un AR faible, diagnostiquer la cause spécifique à partir de l'exécution (courbe de perte d'entraînement, volume/qualité des données, capacité draft-head, hyperparamètres) et suggérer des corrections ciblées sur ce scénario — un AR faible peut avoir de nombreuses causes, donc éviter une checklist générique.