Skip to content

Plan — deliverable HP swap (artefact de clôture S04)

VALIDÉ opérateur (2026-06-03) — design §9 PRÉ-ENREGISTRÉ avant validation. Linké depuis le hub S04 ; deliverable de clôture (Tested → Closed). Exécution : step 1-2 faits (§9.1), step 3 (A puis B) en cours. Contexte : verdict S04 = B_SYSTEMATIC_OVERFIT / B_DEFAULTS_OVERFIT (= H₀(B) RÉFUTÉ, expérience §7). Le plan S04 (L16) impose sur refute un deliverable concret : « recommended HP swap » (config plus douce remplaçant les défauts HPO prod sur-ajustés). Ce plan = comment le produire + le valider.

0. Objectif

Produire une config LGB plus douce recommandée (par axe) qui généralise mieux que les défauts HPO prod, étayée + validée, comme artefact de clôture S04. Sortie acceptable aussi = un négatif honnête (« aucun swap mono-axe ne généralise » / « gagne en val-AUC mais pas en f1_buy ») — ça ferme S04 quand même, avec routing différent.

1. Source de données — la trajectoire AUC-par-point

Le run 5-axes (manual__2026-06-03T08:02:10) a balayé 5 axes × 5 points × 5 seeds. La trajectoire est dans le verdict cellule : metrics.<axis>.auc_by_seed_by_point (+ sweep_points, deltas_vs_default_per_point).

Chemin État
/tmp/s18-diagnostic/... (write_s42_verdict) éphémère, parti
XCom discriminate_cell (return asdict(verdict), note=returned_via_xcom) à récupérer en 1er (Airflow metadata DB / API, run …08:02)
Re-run court (fold-3, 5 axes, grids complets) dumpant durablement fallback si XCom tronqué/purgé

⚠️ Vérifier la non-troncature XCom : le metrics complet (5×5×5 AUCs × 5 cellules) peut dépasser la taille XCom → si tronqué, fallback re-run.

2. Dérivation de la recommandation (par axe)

Pour chaque axe : agréger auc_by_seed_by_point sur 5 cellules × 5 seeds → AUC val moyenne + CI bootstrap par point (n=25/point). Localiser l'optimum dans la direction « plus douce » sur la trajectoire 5 points complète (pas seulement l'endpoint décisionnel extrême — c'est l'objet des 4 points non-décisionnels, plan §2 « optimum-localization »).

Caveats à intégrer (pas à masquer) : - Balayage one-at-a-time ≠ optimum joint : s42 bouge un axe à la fois. Combiner les optima par-axe = une hypothèse de config à valider conjointement, pas une config prouvée. - Hétérogénéité par crypto = à TESTER, pas à noter : ARBUSDC déclenche sur learning_rate, les 4 autres sur num_leaves. Défaut = config globale defi_top5 (n=25/point plus serré, surface ops réduite, et un split per-asset sur fold-3 sur-ajusterait encore plus le fold). Mais : (a) la validation §3 rapporte les deltas par crypto, pas seulement le pooled ; (b) règle pré-engagée : si ARBUSDC régresse en f1_buy sous la config globale → carve-out ou flag explicite. Le choix global/per-asset devient data-driven depuis le multi-fold, pas pré-tranché. Note : l'hétérogénéité elle-même est dérivée de fold-3 → hard-coder un split per-asset figerait un finding mono-fold (autre raison de ne pas sur-structurer). - Écart de métrique : s42 optimise la val-AUC. La cible de décision = f1_buy / Sortino (policy projet ; optimiser la val-AUC reviendrait à optimiser le proxy que le diagnostic vient d'incriminer). Mais garder l'AUC en readout SECONDAIRE (mécanistique) : le diagnostic B porte sur l'AUC, donc mesurer les deux rend le négatif interprétable — distingue « le swap n'a pas réduit l'over-fit AUC » de « il l'a réduit mais ça ne transfère pas en f1_buy ». ⚠️ f1_buy dépend de theta (calibré OOS, ADR-15) → la métrique de décision embarque la variance de calibration de seuil : à noter pour qu'un négatif ne soit pas imputé à tort au swap.

3. Validation (avant de recommander)

  • ADR-14 multi-fold, folds DISJOINTS : la reco est dérivée de fold-3 → la valider sur des folds disjoints (ne pas double-compter fold-3 dans le verdict — sinon circularité). Idéal ≥3 ; réalité n_folds=3 = 2 OOS max → déviation documentée, cf. §9.2/§9.3.
  • Stabilité de l'optimum (pas seulement « fold-3 gagne ailleurs ») : vérifier que la localisation de l'optimum par axe est stable fold-à-fold. Si l'optimum dérive d'un fold à l'autre, même une config globale « gagnante » en pooled est fragile — et c'est l'info qui compte pour un « lead not ship » (ADR-2).
  • ADR-15 : theta calibré OOS (cf. §2 — la variance de calibration entre dans la métrique de décision).
  • Run de contrôle : config recommandée vs défauts prod sur folds tenus → métrique de décision = Δf1_buy / ΔSortino (CI exclut 0), + readout secondaire ΔAUC (≥ +0.02 attendu si le swap réduit l'over-fit). Deltas rapportés par crypto (breakout), pas seulement pooled (§2).
  • Confound non démêlable (à dire noir sur blanc) : un run combiné (config jointe multi-axes) qui échoue ne permet pas de distinguer « les interactions joint ≠ marginales » (les optima par-axe ne se combinent pas) d'« le swap n'aide pas » (pas de gain réel). Démêler exigerait un design factoriel coûteux, hors scope de ce lead. Acceptable pour un lead, mais le négatif est alors « inconclusif sur la cause », pas « swap réfuté » — la gate opérateur doit le savoir.
  • Négatif honnête : si la reco ne généralise pas multi-fold ou n'améliore pas f1_buy → deliverable = « pas de swap mono-axe généralisant » (ou « inconclusif joint-vs-marginal », cf. ci-dessus) → S04 clôt quand même (documenté), route vers C-blocks/autres.

4. Conformité ADR & chemin d'application

  • ADR-2 : la reco = un lead, pas un ship. Aucune promotion auto.
  • ADR-90 / ADR-59 / ADR-56 : les défauts HPO prod vivent en PG ftf_config via CVN_HPO_<MODEL>_<TF>_<PARAM>, éditables Console UNIQUEMENT. Le swap validé est appliqué par l'opérateur via Console, gated par un flag CVN_* + facteur FTF A/B (ADR-56). Ce deliverable produit la reco ; l'opérateur applique.
  • ADR-70 : MLOps readiness (touche les HP de training).

5. Artefact de clôture (ce qui ferme S04)

Un doc de recommandation : la config plus douce (par axe), l'évidence trajectoire (courbes AUC + CI), le résultat de validation multi-fold, le check f1_buy, le cadrage ADR-2 « lead not ship », le chemin Console-apply. Linké depuis le hub S04.

Gate Tested → Closed : cet artefact + le run de validation + la décision de gate opérateur (lock / keep_available / abandon, ADR-79).

6. Risques

Risque Mitigation
XCom tronqué (source) re-run court fallback (§1)
one-at-a-time ≠ joint (interactions) valider la config combinée conjointement (§3)
optimum fold-3 sur-ajuste le fold validation multi-fold ADR-14 (§3)
AUC↑ ≠ f1_buy↑ valider la métrique aval (§3)
A6 (s18_status=FAIL) borne « fidélité baseline prod » orthogonal (S09) ; ne bloque pas le contraste relatif gentler-vs-default

7. Étapes (ordonnées)

  1. Récupérer la trajectoire (XCom du run …08:02 ; sinon re-run court durable).
  2. Agrégation par-axe + localisation d'optimum → config draft (+ caveats §2).
  3. Run de validation multi-fold + f1_buy (config recommandée vs défauts).
  4. Synthétiser le doc de recommandation + chemin Console-apply (ADR-2/56/59/90).
  5. Décision de gate opérateur → S04 Closed.

8. Critères de succès

  • Reco dérivée de données réelles (pas inventée), caveats explicites.
  • Validée multi-fold disjoint (2 OOS max à n_folds=3, déviation ADR-14 documentée §9) sur la métrique de décision f1_buy/Sortino (+ AUC en readout secondaire), pas seulement val-AUC fold-3. Optimum stable fold-à-fold vérifié (§9.3 A).
  • Deltas par crypto rapportés ; règle de carve-out ARBUSDC pré-engagée (§2).
  • Chemin d'application = Console + flag CVN_* + A/B FTF (jamais un ship direct, ADR-2).
  • Limite assumée du lead : le run combiné ne démêle pas « interactions joint ≠ marginales » d'« swap n'aide pas » (§3) → un négatif est « inconclusif sur la cause », pas « swap réfuté ». La gate opérateur statue en connaissance de cette limite (un design factoriel pour démêler serait une Story de suivi, pas ce deliverable).
  • Ou négatif honnête documenté. Dans les trois cas (gagne / négatif-net / inconclusif-cause) : S04 fermable proprement avec routing distinct.

9. Résultats step 2 (fold-3) + design pré-enregistré step 3

Step 1 (récupération trajectoire XCom du run manual__2026-06-03T08:02:10) + step 2 (agrégation) faits read-only, sans re-run. Ce qui suit est pré-enregistré avant toute validation (discipline anti-flexibilité d'analyse).

9.1 Résultats step 2 — agrégation fold-3 (pooled n=25 × 5 cryptos, + CI apparié)

Axe Défaut Optimum ΔAUC CI95 apparié Robustesse cross-crypto Décision
learning_rate 0.1 0.025 +0.0193 [+0.0153, +0.0232] SIG 4/5 sur 0.025 cœur
num_leaves 31 8 +0.0128 [+0.0080, +0.0176] SIG 5/5 sur 8 cœur
min_child_samples 20 80 +0.0065 [+0.0023, +0.0107] SIG 3/5 sur 80 (faible) hors-cœur (candidat sweep futur)
lambda_l2 0.0 100 +0.0043 [−0.0024, +0.0111] ns hétérogène exclu (bruit)
min_gain_to_split 0.0 0.1 +0.0012 [−0.0029, +0.0053] ns éclaté exclu (bruit)
  • CI apparié (différence opt−défaut par paire crypto×seed) = stat correcte ; resserre vs la combinaison naïve de deux CI point-par-point (~±0.013).
  • Config cœur recommandée (draft fold-3) : learning_rate: 0.025 + num_leaves: 8, 3 autres au défaut. mcs=80 paired-SIG mais 3/5 + borne basse frôle 0 → hors-cœur (charger un 3e levier multiplie la dimension d'interaction à valider sur 2 OOS folds pour un gain marginal).
  • best_iter (cap 300) : aucune saturation — défaut=16, lr=0.025→42 (max 95), nl=8→15 (max 40). Les leviers poussent best_iter en sens opposés (lr ralentit, nl plafonne la capacité) → la protection anti-underfit du joint = le plafond de capacité de nl=8, pas une marge de rounds. n_fit_rounds=300 gardé.
  • Corroboration statut-B indépendante : best_iter=16 au défaut sur 300 dispo → les défauts sur-ajustent dès ~16 rounds ; les configs douces repoussent ce point.
  • Attente honnête : deltas argmax-sélectionnés sur fold-3 = optimistes (winner's curse) → régression vers la moyenne attendue sur folds disjoints. Et l'AUC n'est pas la métrique de décision.

9.2 Fenêtres calendaires PRÉ-ENREGISTRÉES (pas les index)

⚠️ _generate_folds() calcule les fenêtres depuis now (1er du mois), sans override de date → un index de fold n'a de sens qu'au mois de calcul. On pré-enregistre donc les fenêtres calendaires (auditables quel que soit le mois de relecture) :

Rôle Fenêtre test calendaire
Dérivation (ancre in-sample) [2025-12-01, 2026-02-01)
OOS #1 (après la dérivation) [2026-02-01, 2026-04-01)
OOS #2 (avant la dérivation) [2025-10-01, 2025-12-01)

Les 2 OOS encadrent temporellement la dérivation (un après, un avant) = dispersion correcte vu la contrainte. s42 folds {2,3,4} et FTF folds {2,3,4} sont calendairement IDENTIQUES (même _generate_folds, même anchor, FTF prod = n_folds=3 aussi — pas 5) → FTF-fold-3 ≡ ancre de dérivation.

Limite documentée : non-reproductibilité cross-mois des index (folds now-relatifs). Affecte tout artefact référençant un index de fold, y compris le verdict S04. → candidat follow-up infra : paramétrer l'anchor dans AblationRunner (orthogonal, à la A6/S09, hors scope de ce lead). B doit tourner en juin 2026 pour l'alignement.

9.3 Design pré-enregistré

A · Stabilité optimum (AUC) — DAG s42, pré-filtre cheap, A6-robuste - Runs : s42 sur fenêtres OOS #1 + #2 (fold_id 2 & 4 en juin), defi_top5, skip_phase_a=false+use_pin=true, axes_subset = learning_rate,num_leaves (les axes de la gate ; les 3 bruités optionnels), grids complets, 5 seeds, n_fit_rounds=300. - Critère : l'optimum reste-t-il à lr=0.025 / nl=8 sur {dérivation, OOS#1, OOS#2} ? Dérive ⇒ config fragile (ADR-2 lead) ⇒ ne pas brûler le compute B. - s18_status=FAIL attendu (A6) → n'invalide pas A (contraste intra-run, A6-robuste).

B · Transfert f1_buy/Sortino — FTF natif, A6-ORTHOGONAL, conditionné à A - Vecteur : framework FTF A/B (vrai funnel backtest sur données réelles → indépendant du replay s42). Facteur isolant exactement {lr=0.025, nl=8} (rien d'autre ne co-varie). - OOS = fenêtres FTF calendairement disjointes de la dérivation = OOS#1 + OOS#2 ; ancre = FTF-fold-3 (≡ dérivation) → contrôle selection-overfit (f1_buy ancre ≫ OOS ⇒ selection-overfit). - Métrique de décision = Δf1_buy / ΔSortino (theta calibré OOS, ADR-15) ; AUC en readout secondaire ; pas de gate AUC dur. - Belt best_iter_joint < cap ici (le joint {lr,nl} n'existe ni en fold-3 ni dans A — 1re éval = le bras A/B de B ; l'ancre fold-3 donne le baseline joint in-sample, pas de gap).

Critères de lecture PRÉ-ENREGISTRÉS (asymétrie + 10 cellules) - Asymétrie à 2 OOS : un positif n'est PAS « validé » → « lead prometteur, à confirmer sur historique plus large avant ship ». Un négatif est concluant (tue/borne le swap). La gate opérateur lit dans ce cadre (un +Δf1_buy sur 2 folds ≠ feu vert). - Consistance sur 10 cellules (fold × crypto), pas 2 chiffres poolés : 2 OOS × 5 cryptos = 10 observations f1_buy → récupère de la puissance. Caveat : les 10 ne sont pas indépendantes (cryptos corrélées, fenêtres adjacentes) → lecture en consistance, pas n=10 pour un CI. C'est là que se lit la règle carve-out ARBUSDC (§2). - ADR-14 : déviation documentée — 2 OOS max à n_folds=3, ≥3-disjoints inatteignable, élargir le walk-forward hors scope (re-définirait les splits → re-dérivation). Couverture complète {dérivation, OOS#1, OOS#2}.

Séquence : commit (pré-enregistration) → A → si l'optimum tient → B → décision de gate opérateur → S04 Closed.