fix(qc): QC-Py-31 — entrainement degenere + reference committee non reproductible depuis le code actuel #17838

Deux defauts preexistants de QC-Py-31-Transformer-Training.ipynb, mesures pendant le controle de #17836. Aucun des deux n'est cause par le correctif de determinisme de #17836, et aucun n'est corrige par lui.

1. La reference committee de main n'est pas reproductible depuis le code actuel

Le carnet de main, non modifie, execute avec QC31_FORCE_RETRAIN=1 (entrainement depuis zero), meme machine :

Ce que main execute aujourd'hui ne produit pas ce que main a commite. Les sorties commitees proviennent donc d'un etat que le code actuel ne reproduit pas (checkpoint repris, ou version anterieure du carnet).

Portee honnete de la mesure : une seule execution de controle suffit a refuter « la reference committee est ce que le code produit ». Elle n'etablit pas que main est variable d'un run a l'autre — cela demanderait n>=2 executions, qui n'ont pas ete faites. Les deux hypotheses restent ouvertes.

2. L'entrainement est degenere

Dans les trois points de mesure (sorties committee, controle, run de #17836) :

• Correlation ~ 0 : 0.0098 / -0.0144 / nan
• Direction Accuracy 56,23 % = exactement la classe majoritaire (Ecart vs classe majoritaire: -0.00 points)

Le modele n'apprend rien : il predit la classe majoritaire. Le 0.0098 de la reference committee n'est pas meilleur que le nan du run de #17836 — les deux sont une absence d'apprentissage.

Detail secondaire mesure, a ne pas surinterpreter : l'ecart nan (predictions parfaitement constantes -> ecart-type nul -> correlation indefinie, 0 quantile) contre -0.0144 (non constantes mais non correlees, 1 quantile) montre que l'ordre CUBLAS_WORKSPACE_CONFIG / import torch change bien les numeriques, assez pour faire basculer « constant » / « presque constant ». Sur un modele degenere, c'est une distinction sans difference.

Acceptance

• Determiner d'ou viennent les sorties commitees a 17 epochs (checkpoint repris ? version anterieure du carnet ? commit d'origine identifie) et le documenter dans le carnet.
• Re-executer le carnet depuis zero sur main et committer des sorties reproductibles par le code courant (H.1/C.2).
• Diagnostiquer la degenerescence : l'early stopping a patience 7 coupe a l'epoch 9 sur 25 prevus dans les deux configurations. Verifier si c'est le budget d'epochs, le taux d'apprentissage, la fenetre de validation, ou les donnees — et non un simple nan de correlation.
• Si une variabilite run-a-run est confirmee (n>=2), la quantifier et la borner ; sinon, ecrire que la trajectoire est stable et que seule la reference committee etait perimee.

Contexte

Decouvert en cherchant a attribuer l'ecart 17 vs 9 epochs observe dans #17836. Mon attribution initiale (le correctif de determinisme deplace la trajectoire) a ete refutee par ce controle : le carnet de main donne 9 epochs sans le correctif. Le detail complet est en commentaire de #17836.

Le correctif de determinisme lui-meme reste valide et independant : CUBLAS_WORKSPACE_CONFIG est lue a l'initialisation du contexte CUDA, donc posee apres import torch elle n'atteint jamais cuBLAS.

— myia-po-2026:CoursIA