Repository navigation
fix(notebook,#19624): Lab5 Track1 -- etape ML non degeneree (jeu riche + baseline majoritaire) - #19672
Conversation
…e + baseline) L'etape « Machine Learning » du Lab 5 s'entrainait sur les 7 lignes de `transactions.csv` : le split laissait 4 exemples d'entrainement et 2 de test, et la precision affichee (1.00) ne mesurait rien. Voie 3 de l'issue : `transactions.csv` reste le fil des etapes data (nettoyage, visualisations, Exercice 2), et **la seule etape ML** bascule sur le jeu « wine » de scikit-learn (178 echantillons, 13 variables numeriques, 3 classes). Le vocabulaire du carnet est preserve (`categorie` reste le nom de la cible), et les noms consommes en aval (`model`, `y_test`, `y_pred`, `X_train`, `y_train`) sont inchanges : les Exercices 2 et 3 ne sont pas reecrits. Ajouts au-dela de la bascule : - comparaison a la **baseline majoritaire** : c'est elle qui rend le score interpretable (0.981 contre 0.389, ecart +0.593), la ou une precision seule peut ne refleter que des classes desequilibrees ; - `StandardScaler` en amont du classifieur : les 13 variables ont des echelles incomparables (proline ~centaines, hue ~unites) et un ajustement sans standardisation laissait un `ConvergenceWarning` dans la sortie committee -- une sortie qu'on ne peut pas interpreter ; - `stratify=y` au split, pour conserver la proportion des trois classes ; - Exercices 1 (partie binaire) et 4 re-ancres sur le jeu riche : laisser une courbe ROC tracee sur 2 points de test aurait reconduit le meme defaut. Cellules touchees : 14, 15, 17, 18, 22, 27, 28. Re-execution (C.2) : `py -3.13 -m papermill -k python313`, `--cwd` du carnet. `metadata.kernelspec` restaure a celui de la base (`python3`) : la 3.13.13 est le meme major.minor que la base (3.13.12), le nom est une declaration de portabilite, pas un fait d'execution. Gardes passees sur la tete : C.2 conforme, sequence d'execution CLEAN (1..N), source parse 0 finding, 0 fuite de chemin machine, chaine de navigation `0 NEW finding`, positionnement des interpretations OK. See #19624 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…19672) main avait recu #19625 (Lab5 : nav/H1 au canon, exercices avant Conclusion, lecture ancoree, accents) sur LE MEME carnet que cette branche reecrit. Resolution cellule par cellule -- l'ordre et la structure viennent de main (le reordonnancement pedagogique de #19625 est une decision deliberee, on ne la defait pas), le contenu de mes 7 cellules est substitue dessus : - 18 cellules identiques, 6 changees par main seul (prises), 5 par moi seul (gardes) ; - `5e3a09e6` (interpretation du score) -- les DEUX cotes avaient diagnostique le meme defaut : main ecrivait « ici 1.00, mefiez-vous, transactions.csv est minuscule », devenu FAUX apres la bascule (le score est desormais 0.981 contre une baseline de 0.389). Composition : mon interpretation contre la baseline (vraie) + la lecon de methode de main, qui reste vraie : « un score ne se lit qu'avec le volume de test qui le porte » ; - `e9fe6ce9` (Exercice 4) -- texte de main (accents, bloc Reference Fawcett) avec mon re-ancrage (`alcool_eleve` sur `df_ml`) applique par-dessus. Re-execution complete post-fusion (C.2) : py -3.13 -m papermill -k python313, --cwd du carnet ; 10 cellules code, sequence CLEAN 1..10, sorties coherentes (124/54, precision 0.981, baseline 0.389, ecart +0.593). prose-counts-guard (bloquant, #17636) attrapait trois « N lignes » chiffres : les comptes decrivent un fichier de DONNEES pedagogique, pas un artefact du depot -- passes en lettres (« sept lignes »), mention redondante de la cellule de code supprimee. Rejeu --strict : rc=0. Gardes passees sur la tete fusionnee : C.2 conforme, sequence CLEAN, source parse 0 finding, 0 fuite de chemin machine, nav-chain 0 NEW finding, positionnement des interpretations OK. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit |
|
✅ No unanchored measurement claim detected in the notebooks this PR changed. Scope = notebooks CHANGED in this PR, not the whole corpus. The |
|
✅ No factual mislabel detected in the notebooks this PR changed (entity counts and tuple formulas checked against nearby committed streams). Scope = notebooks CHANGED in this PR, not the whole corpus. The |
|
No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml). Detector: |
Golden-Set Execution (H.7 P3)✅ 9/9 notebooks passed (certified reproducible)
Pinned lockfile: |
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
Notebook outputs-required (H.4 schema): PASS (every code cell carries an
|
|
[ADJOINT PREFLIGHT] |
Grain: DEEP/notebook-python — lane myia-po-2026:CoursIA — prev: LIGHT/docs #19542
Le défaut
L'étape « Machine Learning » du Lab 5 (
Track1-LangChain/Day3-Data-Agents/Labs/Lab5-Viz-ML) s'entraînait sur les 7 lignes detransactions.csv:Sur deux exemples de test, la précision ne peut valoir que
0.00,0.50ou1.00: aucune de ces valeurs ne mesure quoi que ce soit. Le moteur SOTA (régression logistique) y équivalait à une baseline triviale — c'est exactement le cas dégénéré que vise le critère de richesse de problème.Ce que fait la PR
Voie 3 de l'issue (arbitrage déclaré au claim) :
transactions.csvreste le fil des étapes data (nettoyage, visualisations, Exercice 2), et la seule étape ML bascule sur le jeuwinedescikit-learn— 178 échantillons, 13 variables numériques, 3 classes.Le vocabulaire du carnet est préservé (
categoriereste le nom de la cible) et les noms consommés en aval (model,y_test,y_pred,X_train,y_train,accuracy) sont inchangés : les Exercices 2 et 3 ne sont pas réécrits.Le fichier CSV n'a pas été élargi : sa saleté (valeur manquante, date entre guillemets) est le matériel d'exercice du Lab 4, et l'élargir aurait cassé le laboratoire précédent.
Après (exécuté, sortie committée)
Trois ajouts au-delà de la bascule
StandardScalerdans unPipeline. Les 13 variables s'expriment dans des unités incomparables (proline ~centaines, hue ~unités) : un ajustement sans standardisation laissait unConvergenceWarningdans la sortie committée — une sortie qu'on ne peut pas interpréter. Corrigé par la cause, pas par un scrub.stratify=yau split, pour conserver la proportion des trois classes dans les deux ensembles.Cohérence des exercices
Laisser une courbe ROC tracée sur 2 points de test (Exercice 4) aurait reconduit le même défaut dans la même section. Les Exercices 1 (partie binaire) et 4 sont donc ré-ancrés sur le jeu riche : cible binaire
alcool_eleve(teneur en alcool au-dessus de la médiane), même geste « seuil sur une variable numérique → classification binaire → ROC ». Les cellules restent des stubs (None # TODO etudiant) : C.1 est respectée.Fusion avec #19625 (main avait touché le même carnet)
maina reçu #19625 (nav/H1 au canon, exercices avant Conclusion, lecture ancrée, accents) sur ce même carnet pendant que cette branche le réécrivait — conflit réel. Résolution cellule par cellule, pas ligne à ligne :transactions.csvest minuscule », devenu faux après la bascule. Composition retenue : mon interprétation contre la baseline (vraie) plus la leçon de méthode de main, qui reste vraie (« un score ne se lit qu'avec le volume de test qui le porte ») ;alcool_elevesurdf_ml) appliqué par-dessus ;Aucune des contributions de #19625 n'est perdue : ses 6 cellules modifiées, sa cellule ajoutée et son réordonnancement sont dans la tête fusionnée.
Diff
Un seul fichier, 2 commits (le correctif, puis la fusion de main) :
Mes cellules dans l'ordre fusionné : 14, 15, 17, 18, 20, 25, 26 (les indices de la première version, avant le réordonnancement de #19625, étaient 14, 15, 17, 18, 22, 27, 28).
Preuves d'exécution et gardes
Ré-exécution réelle (C.2) :
py -3.13 -m papermill -k python313,--cwddu dossier du carnet (le CSV est résolu depuisPath.cwd()), refaite après la fusion.metadata.kernelspecest restauré à celui de la base (python3) : 3.13.13 est le même major.minor que la base (3.13.12), et le nom du kernelspec est une déclaration de portabilité du carnet, pas un fait d'exécution — l'exécuter sous le kernelpython3local (Python 3.11) aurait produit une dérive de version.check_c2_compliance.py1/1 notebooks compliantcheck_exec_sequence.pyfully executed: 1,CLEAN (1..N): 1, 0 DIRTYcheck_cell_source_parses.pyfindings: 0check_kernel_drift.py origin/mainOK: 0 regressioncheck_output_failure_text.py origin/main0 regressedcheck_output_collapse.py/check_source_collapse.py(advisory)0 flaggedcheck_prose_quantitative_claims.py --strictrc=0check_notebook_nav_chain.py --checkOK: 0 NEW finding vs baselinecheck_interp_positioning.py --checkOK: no new misplaced interp cells00Tous ces gardes ont été passés après la ré-exécution post-fusion, sur la tête committée.
Note sur
prose-counts-guard(bloquant, #17636) : il attrape tout « N lignes » en chiffres. Mes trois occurrences décrivaient la taille d'un fichier de données pédagogique (transactions.csv), pas un compte d'artefact du dépôt — elles sont passées en lettres (« sept lignes ») et la mention redondante de la cellule de code a été supprimée. L'information reste au lecteur ; le rejeu--strictrendrc=0.Hors périmètre
Le fichier CSV du Lab 4, les notebooks voisins du Track 1 et le contrat de données des Exercices 2-3 sont inchangés.
See #19624
🤖 Generated with Claude Code