Repository navigation
Fix(finetuning,#17073): audit FT-00a -- durees par epoch et ordres de grandeur float64 regroundes sur les sorties - #20489
Conversation
… et ordres de grandeur float64 (3 -> 9) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Notebook outputs-required (H.4 schema): PASS (every code cell carries an
|
|
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 |
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
Golden-Set Execution (H.7 P3)✅ 9/9 notebooks passed (certified reproducible)
Pinned lockfile: |
|
No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml). Detector: |
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
…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>
|
[ADJOINT PREFLIGHT] Verification du champ domain (lecture C.5 contre le head ba93414, notebook FT-00a) :
|
myia-ai-01
left a comment
There was a problem hiding this comment.
Revue coordinateur à la tête exacte. Uniquement du markdown, aucune source de code touchée. « Quelques secondes par epoch » correspond aux sorties (3,1 à 4,0 s par epoch, cellules 7eb76d45 et 28aba3d4) ; l'ancien ~6 s était faux. « Près de neuf ordres de grandeur » correspond au contrôle float64 (1,9e-06 contre 3,1e-15, cellule 0ae9d3b8) ; l'ancien « trois » était faux. Carnet : séquence 1..11, 0 erreur. Approuvé.
Grain: MED/genai — lane myia-po-2025:CoursIA — prev: MED/genai #20488
Fix des 2 findings de l'audit v2.1 (partition #19451, campagne #17073) sur
MyIA.AI.Notebooks/GenAI/FineTuning/FT-00a-LoRA-from-scratch-Python.ipynb— les deux sont des claims quantitatives contredites par les sorties committées. Markdown-only (aucune cellule code touchée → pas de re-exécution, exception C.2).Findings
F1 — durée par epoch (c.0 + c.3)
La carte d'en-tête annonce « les durées affichées sont mesurées sur GPU, ~6 s par epoch » et la section 3 répète « ~6 s par epoch sur RTX 3090 ». Les sorties committées montrent 6 lignes epoch toutes entre 3,1 et 4,0 s (3,7/3,1 en entraînement de base, 3,9/4,0 en LoRA, 3,8/3,8 en full). Le « ~6 s » date manifestement d'un run antérieur (dataloader ou machine différente). Fix : formulation qualitative « quelques secondes par epoch » aux deux endroits — portee de #20535 (constat du 13/10), qui ecarte le realignement chiffre « ~4 s / mesure 3,1-4,0 s » : 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, soit exactement la classe de derive que l'audit corrige (C.4). La fourchette mesuree reste lisible dans les sorties commitees des cellules d'entrainement.
F2 — ordres de grandeur du contrôle float64 (c.22)
La lecture dit : « la même comparaison en double précision tombe de près de trois ordres de grandeur plus bas ». Les sorties committées :
drift32 = 1.907e-06,drift64 = 3.109e-15— ratio 6,1×10⁸, soit 8,8 ordres de grandeur (cohérent avec le rapport des epsilons float32/float64 ≈ 5,5×10⁸, que la cellule imprime elle-même : « epsilon ~2e-16 »). « Trois » est faux d'un facteur ~10⁶. Fix : « près de neuf ordres de grandeur ».Preuves
Vérifiés OK sans finding (lecture intégrale, 30 cellules)
Toute l'arithmétique recoupe : 512×10=5 120 et 4×(512+10)=2 088 (40,8 %) ✓ ; 2 088 = r(d+k) mesuré ✓ ; 7 218 totaux (28,93 %) ✓ ; 0,2 % du delta à 4096×4096 ✓ ; 29 066 paramètres du CNN (160+4 640+18 496+5 770) ✓ ; budgets conv3 (1 152+256) et fc (2 344) = 3 752/32 818 (11,43 %) ✓ ; full 24 266/29 066 (83,49 %) ✓ ; « 6,5 fois plus » (6,47) ✓ ; exactitudes 0,8325/0,0363/0,7351/0,8242 toutes citées fidèlement (~0,83, ~0,04 sous le hasard 0,10, ~0,74, ~0,82) ✓ ; ||ΔW||/||W|| = 46 % ↔ « la moitié » ✓ ; ε float32 1,2e-7 et float64 ~2e-16 ✓ ; GPT-2 124 M ✓ ; exercices 1/2/3 stubs conformes C.1 (
result = None # TODO etudiant+ print).Fusion de doublon (13/10)
#20535 auditait le meme carnet et le meme finding F1, avec un constat plus robuste sur la forme du correctif : qualitatif plutot que chiffre. Son constat a ete porte ici (commit
ba93414ccd, deux cellules markdown, markdown-only) et #20535 est fermee au profit de cette PR — un carnet, une PR. Le reviewer tiers de #20535 (clusterManager-Myia, 2026-10-13T09:50:28Z) valide explicitement le choix qualitatif, en notant qu'une fourchette chiffree ecrite en dur redeviendrait perimee.See #19451 (partition de #17073)
🤖 Generated with Claude Code