Repository navigation
Conversation
…vs 3,1-4,0 s mesures)
Cellules c.0 et c.3 annoncent '~6 s par epoch' sur GPU ; les sorties
commitees affichent 3,1-4,0 s par epoch (c.14, c.18). Correctif
qualitatif ('quelques secondes par epoch') : pas de nombre realigne
byte-surgical sur un carnet re-executable (C.4). Markdown-only, code
byte-identique, diff = 2 lignes.
Sondes mecaniques famille FineTuning : c.6142423841 (saine, 0 defaut
C.1/C.2/path/outil sur 14 carnets).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
github-actions
Bot
added
the
consecutive-code-cells
|
Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit |
|
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 |
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
Golden-Set Execution (H.7 P3)✅ 9/9 notebooks passed (certified reproducible)
Pinned lockfile: |
Notebook outputs-required (H.4 schema): PASS (every code cell carries an
|
|
No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml). Detector: |
clusterManager-Myia
left a comment
clusterManager-Myia
left a comment
There was a problem hiding this comment.
VERDICT: LGTM (vérifié: diff cellulaire base↔head re-dérivé localement sur les 2 notebooks extraits — exactement 2 cellules markdown touchées ; les 6 durées d'epoch committées relues une à une dans les outputs du head : 3,7/3,1/3,9/4,0/3,8/3,8 s)
[NanoClaw] structural review (notebook .ipynb unique, +2/−2 — protocole v2 : extraction complète base et head, jamais le JSON brut ; diff cellulaire re-dérivé, 30 cellules des deux côtés, aucun déplacement).
La fix est exactement ce que le titre annonce, et rien d'autre. Deux cellules markdown, une ligne chacune :
- MD[0] (en-tête) : « les durées affichées sont mesurées sur GPU, ~6 s par epoch » → « …, quelques secondes par epoch ».
- MD[3] (lecture de l'environnement) : « (~6 s par epoch sur RTX 3090, …) » → « (quelques secondes par epoch sur RTX 3090, …) ».
Le claim retiré était bien périmé, et je l'ai re-mesuré dans les outputs committés : les 6 epochs des cellules d'entraînement affichent 3,7 / 3,1 (modèle de base), 3,9 / 4,0 (LoRA), 3,8 / 3,8 (full) — fourchette [3,1 ; 4,0] s, exactement la fourchette citée dans le titre de la PR. Le « ~6 s » ne correspond à aucune mesure présente : retrait justifié.
Le remplacement « quelques secondes » est le bon choix éditorial : une fourchette chiffrée écrite en dur (3,1-4,0 s) redeviendrait périmée à la prochaine variation de machine/charge — la formulation qualitative reste soutenable tant que les epochs restent de cet ordre, et la cellule MD[3] dit déjà que les valeurs mesurées (exactitudes, normes, dérive) sont celles du run, liste dans laquelle les durées n'entrent pas. Aucune occurrence résiduelle de « ~6 s » nulle part dans le head (grep sur l'extraction complète).
Cohérence de voisinage vérifiée : les claims chiffrés adjacents non touchés (device cuda RTX 3090, ~30 min de durée pédagogique, CPU suffit) restent soutenus par les outputs (stream d'environnement cell 2).
Série FT audit v2.1 (#19451) : même discipline que #20487 — retrait d'un claim non soutenable, ancrage vérifiable dans ce qui est committé. Rien à demander.
…poch en qualitatif La PR #20535 (constat du 13/10) remplace le realignement chiffre "~4 s par epoch, mesure 3,1-4,0 s" par une formulation qualitative "quelques secondes par epoch". Motif (C.4, et verdict NanoClaw sur #20535) : un nombre de timing ecrit en dur sur un carnet re-executable localement (CPU suffit) redevient perime a la prochaine variation de machine ou de charge -- c'est exactement la classe de derive que l'audit corrige. La fourchette mesuree reste lisible dans les sorties commitees des cellules d'entrainement. Le finding F2 de cette PR (trois -> neuf ordres de grandeur, controle float64 sur c.22) est conserve tel quel. Markdown-only : aucune cellule code touchee, outputs et execution_count 1-11 inchanges (exception C.2). See #19451 (partition de #17073) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Fermee au profit de #20489 — un carnet, une PRCette PR et #20489 auditent le meme carnet ( Le constat de cette PR-ci est le plus robuste sur la forme du correctif : formulation qualitative « quelques secondes par epoch » plutot qu'un nombre realigne. Il a donc ete porte dans #20489 (commit Le reviewer tiers de cette PR (clusterManager-Myia, 2026-10-13T09:50:28Z) avait deja valide explicitement ce choix qualitatif, en notant qu'une fourchette chiffree ecrite en dur redeviendrait perimee a la prochaine variation de machine ou de charge ; cet argument est repris dans le body de #20489. La branche Suite : #20489. |
… grandeur float64 regroundes sur les sorties (#20489) * Fix(finetuning,#17073): FT-00a audit -- durees par epoch (~6s -> ~4s) et ordres de grandeur float64 (3 -> 9) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> * Fix(finetuning,#17073): FT-00a -- port du constat #20535, duree par epoch en qualitatif La PR #20535 (constat du 13/10) remplace le realignement chiffre "~4 s par epoch, mesure 3,1-4,0 s" par une formulation qualitative "quelques secondes par epoch". Motif (C.4, et verdict NanoClaw sur #20535) : un nombre de timing ecrit en dur sur un carnet re-executable localement (CPU suffit) redevient perime a la prochaine variation de machine ou de charge -- c'est exactement la classe de derive que l'audit corrige. La fourchette mesuree reste lisible dans les sorties commitees des cellules d'entrainement. Le finding F2 de cette PR (trois -> neuf ordres de grandeur, controle float64 sur c.22) est conserve tel quel. Markdown-only : aucune cellule code touchee, outputs et execution_count 1-11 inchanges (exception C.2). See #19451 (partition de #17073) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
2 participants
Grain: MED/genai — lane myia-po-2025:CoursIA — prev: DEEP/notebook-python #20533
Résumé
Audit v2.1 du carnet FT-00a (famille FineTuning, partition See #19451 — partition de #17073). Premier carnet de la famille après les sondes mécaniques (c.6142423841 : 14 carnets sains au plan mécanique, 0 défaut C.1/C.2/path/outil) — la famille passe directement aux audits qualitatifs.
Finding unique (classe B — compte périmé contredit par la mesure du carnet lui-même)
3.7s/3.1spar epoch ; c.18 :3.9/4.0/3.8/3.8sLa valeur « ~6 s » date d'un run antérieur ; le run committé (le même qui produit toutes les autres valeurs du carnet) tourne à 3,1-4,0 s par epoch.
Correctif — formulation qualitative, pas un nombre réaligné
Choix C.4 : un nombre de timing sur un carnet re-exécutable localement (CPU suffit) doit venir d'une re-exécution fraîche, jamais d'un alignement byte-surgical du markdown. Une re-exécution complète pour realigner une durée indicative (l'information de transport est « GPU = rapide, CPU = plus lent ») serait disproportionnée et réintroduirait le même drift au run suivant. La formulation qualitative est drift-proof et honnête : « quelques secondes » couvre 3-4 s mesurés.
8/9 autres claims quantitatives vérifiées EXACTES contre les sorties
40,8 % (2088/5120) · 2 088 = 4×(512+10) · 29 066 params · 0.8325 / 0.0363 · ||ΔW|| 46 % · table LoRA r=4 (0.7351 / 3752 / 11,43 %) vs full 2 couches (0.8242 / 24266 / 83,49 %) · « 6,5× le budget » (24266/3752 = 6,47) · « 83 % du modèle » (83,49 %). Aucune autre divergence.
Validation
nbformat.readOK (30 cellules)check_prose_quantitative_claims.py --diff origin/main...HEAD:[OK] aucun compteur quantitatif en proseSee #19451 (partition de #17073)
🤖 Generated with Claude Code