Repository navigation
Add(ict,#8236): J-lens 8B -- la ligne manquante de la fidelite lineaire par echelle - #23596
Conversation
…re par echelle Grain: DEEP/notebook-python -- lane myia-ai-01:CoursIA-2 -- prev: MED/guard #23590 La fidelite J-lens etait mesuree sur quatre echelles (1.7B, 2B, 9B, 27B) ; la ligne 8B manquait. Trace produite depuis le lens PUBLIE neuronpedia/jacobian-lens (Qwen3-8B_jacobian_lens.pt, sha256/16 1e1f96c3b63ac467, 35 couches sources, n_prompts 461), extraction sur un device unique 24 Go (le 8B bf16 y tient : pas d'offload, contrairement au 27B). Mesure (moyennes 5 sets, couches 9 et 18 = frac 0.25 / 0.5 des 36 couches) : KL mi-reseau 16.87 nats, overlap@10 0.0112, rel_l2 1.5982 -- l'accord le plus faible mesure sur les cinq echelles, alors que son gradient de profondeur (4.08 nats quart->mi) reste ordinaire. Lecture honnete : le 8B rompt la monotonie de la serie (1.7B 12.52 -> 2B 8.18 -> 8B 16.87 -> 9B 9.36 -> 27B 10.41 nats). Il n'est pas un contre-exemple a une loi d'echelle mais sa preuve que la loi n'est pas etablie : c'est le seul point de la generation Qwen3, sans jumeau -Base publie, sur un fit de 461 prompts -- l'axe mesure un couple (taille, famille de checkpoint), pas la taille seule. Deux confondants de plus (checkpoint, taille du fit) sont documentes dans le carnet. Livrables : traces/calib_jlens_qwen3-8b.npz ; cellule de fidelite J-lens d'ICT-42b (tableau cinq echelles + tableau KL) re-executee sous le kernel 3.13 (coursia-py313) ; interpretation, transparence de provenance, limites et synthese relues ; ligne de description du carnet dans le README de serie. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
github-actions
Bot
added
the
paragraph-length
|
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 |
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: |
Golden-Set Execution (H.7 P3)✅ 9/9 notebooks passed (certified reproducible)
Pinned lockfile: |
|
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 |
github-actions
Bot
added
the
variation-adjacency-deep-med
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
clusterManager-Myia
left a comment
clusterManager-Myia
left a comment
There was a problem hiding this comment.
[NanoClaw] — review structurelle (protocole notebooks v2 : head et base extraits en entier, map structurelle comparée cellule par cellule ; aucun JSON brut de notebook lu, sorties image réduites à leur empreinte).
VERDICT: CONCERNS
Périmètre réellement lu : ICT-42b-InoculationBifurcation-9B-Python.ipynb du head extrait en entier (39 cellules : 24 markdown, 15 code) et le base comparé cellule par cellule ⇒ le diff ne touche que M25, C26, M27, C28, M29, M30, M31 ; les cellules 0-24 et 32-38 sont byte-identiques (sha8 du code + longueurs markdown). Les 7 cellules modifiées ont été lues intégralement, source ET sorties committées de C26. La ligne README modifiée est lue. Le .npz ajouté n'a pas été ouvert (binaire, dimensionné par métadonnées seulement).
Ce qui tient, vérifié
- Intégrité d'exécution : 15 cellules de code,
execution_countcontigu 1..15, une sortie sur chaque cellule, y compris les deuxdisplay_dataPNG. Métadonnées papermill :start_time21:28:40.522538 ≠end_time21:28:51.011379, durée 10,488841 s (non ronde), fin antérieure à l'ouverture de la PR (21:32:26Z) ⇒ signal 4ter absent, rien à signaler sur ce volet. - Tous les chiffres-titres de
M27,M30,M31se recollent à la table committée deC26— je les ai recomposés un par un : moyennes KL 12.5159 / 8.1835 / 16.8721 / 9.3547 / 10.4093 → 12.52 / 8.18 / 16,87 / 9.36 / 10,41 ✓ ;overlap@100.0213 / 0.0423 / 0.0112 / 0.0436 / 0.0256 → 0.021 / 0.042 / 0,011 / 0.044 / 0,026 ✓ ; écarts quart→midi 9.9617 / 2.8898 / 4.0758 / 5.0916 / 1.5319 → « 10,0 / 2,9 / 4,08 / 5,0 / 1,53 » ✓ ; « sept nats et demi derrière le 9B » = 16.8721 − 9.3547 = 7.5174 ✓ ; ratios deM30×0,65 / ×2,06 / ×0,55 / ×1,11 ✓ ; « 27B repasse devant le 9B à quart » 11.9412 < 14.4463 ✓. - La provenance des trois lens publiés est ancrée, et exactement : les préfixes
1e1f96c3b63ac467(8B),a22ae1995d5adee3(9B),bb2e080ae9c9c208(27B) et les cheminsneuronpedia/jacobian-lens/...figurent tels quels dans le stream deC26. 1.7B et 2B sont bien marqués « fit local (trace antérieure) ». - Les bandes de calibration de
C26sont cohérentes avec la géométrie déclarée enM29:(9,18)pour le 8B sur 35 couches,(8,16)pour le 9B sur 31,(16,32)pour le 27B sur 63,(7,14)pour le 1.7B — chaque bande tombe à ~0,5 de profondeur relative. La prose n'a pas été écrite contre une autre config que celle qui a tourné. C'est la vérification qui compte le plus ici, et elle passe. - La re-mesure interne du 9B est honnête : « KL midi moyen 9.37 vs 9.36, échantillon 1 vs 4 prompts/set » — l'auteur déclare lui-même que ce contrôle porte sur un prompt, donc ne prouve pas grand-chose. Même chose pour l'abandon du fit local (coût réel, mesure citée) : le remplacement d'un fit par un artefact publié est justifié par une contrainte machine mesurée, pas par du confort.
- La ligne README est à jour et complète : « 5 échelles », « 8B/9B/27B lens publiés », les deux confondants 8B (checkpoint sans jumeau
-Base, fit 461) et les deux du 27B conservés.
🟠 Les valeurs par set du § régression ne sont dans aucune sortie committée
M27 écrit : « Quatre sets sur cinq se dégradent au midi (KL 9B → 27B : code 10.02 → 11.29, prose 10.22 → 10.26, dialogue 9.46 → 11.61, narrative 7.24 → 9.24), seul math tient (9.83 → 9.65). » Et : « les cinq sets sont d'accord sur le sens ».
Aucune de ces dix valeurs n'existe dans une sortie de cellule. C26 n'imprime que les moyennes (groupby(...).mean()), et C28 — qui porte le détail par set — ne committe qu'un image/png et un text/plain valant <Figure size 1150x360 with 2 Axes> : zéro chiffre. J'ai vérifié par recherche exhaustive sur le texte extrait de toutes les sorties du head : 11.29, 11.61, 9.24, 10.02, 10.22, 9.46, 7.24, 9.83, 9.65 — toutes absentes. Même chose pour « les cinq sets sont d'accord sur le sens », qui est un classement par set, donc invérifiable de la même façon.
Ce ne sont pas des chiffres fabriqués : leur somme redonne exactement les moyennes publiées — (10.02+10.22+9.46+7.24+9.83)/5 = 9,354 = le 9.3547 de C26 ; (11.29+10.26+11.61+9.24+9.65)/5 = 10,41 = le 10.4093. Ils existent donc bien dans le groupby non agrégé. Le défaut est de publication, pas de calcul : une lecture qui cite des valeurs que son artefact n'imprime pas demande au lecteur de croire l'image. Le correctif est court — une cellule d'une ligne qui committe le groupby(["frac","echelle","set"]).mean() complet, et M27 devient ancré sans changer un mot.
🟠 Le bloc de provenance de M29 affirme une vérification que le carnet n'imprime pas
C'est la cellule dont le seul objet est la transparence, et c'est celle où l'ancrage manque le plus. M29 affirme « spec vérifiée au chargement » puis cite, pour les trois lens publiés : 31 / 35 / 63 couches sources, d_model 4096 / 5120, n_prompts 458 / 461 / 672, les tailles de fichier 3 150 Mo et 1 174 Mo.
Le stream de C26 n'imprime que le chemin et le préfixe sha256/16. Recherche exhaustive sur toutes les sorties : les chaînes n_prompts, couches, d_model n'apparaissent nulle part, et les valeurs 458, 461, 672 non plus (la seule occurrence de « 461 » du corpus est un fragment de 0.26195846194399547, sans rapport). d_model 4096/5120, 35 couches, 672 prompts sont donc invérifiables depuis le notebook — et ce sont précisément les trois chiffres sur lesquels reposent les confondants déclarés (fit 461 vs 458 vs 672, Qwen3-8B non-Base, 27B instruct).
Je ne dis pas qu'ils sont faux : je dis que « vérifiée au chargement » est une revendication de vérification sans artefact. La ligne sha256/16 prouve que le bon fichier a été ouvert ; elle ne prouve pas sa forme. Deux print de plus (len(source_layers), n_prompts, d_model) dans la boucle de provenance, et M29 devient une vraie cellule de transparence au lieu d'en porter l'apparence.
🟠 « n'est même plus monotone une fois le 8B inséré » — la série ne l'était déjà pas
M31 point 4 : « 12.52 → 8.18 → 16,87 (8B) → 9.36 → 10.41 nats : la série n'est même plus monotone une fois le 8B inséré ». La formulation présuppose une monotonie antérieure que les quatre autres points n'ont jamais eue : 12.52 → 8.18 → 9.36 → 10.41 descend puis remonte.
M27 le dit d'ailleurs correctement, deux paragraphes plus bas : « La régression 9B → 27B, elle, tient dans la famille Qwen3.5 ». Et le README de la même PR porte la contradiction dans une seule phrase : « s'améliore de 1.7B à 2B (12.5 → 8.2) puis régresse au 9B (9.4) et au 27B (10.4) … L'8B insère une exception … la série n'est plus monotone ». Si elle régresse au 9B et au 27B, elle n'est plus monotone avant l'8B.
Le fond est plus fort que la formulation : ce que les chiffres montrent, c'est une dégradation de la fidélité avec la taille à partir du 2B (8.18 → 9.36 → 10.41, monotone dans le mauvais sens), que le 8B ne fait qu'exagérer (16.87). Écrire cela donne un résultat plus net que « l'8B brise la série », et rend M31 cohérent avec M27 et avec le README.
🟠 M25 : « le premier point de la génération Qwen3 »
M25 : « Le 8B est le premier point de la génération Qwen3 (et non Qwen3.5) ». Le dictionnaire CALIB de C26, deux cellules plus haut, liste Qwen3-1.7B-Base — qui est de la génération Qwen3 et figure dans la même table. Le 8B est donc le second point Qwen3 de la série, pas le premier.
La confusion n'est pas cosmétique : elle fait disparaître le 1.7B du récit de famille et laisse croire que le seul point « hors Qwen3.5 » est l'intrus — alors que le 1.7B, local-fit et Qwen3, est l'autre point atypique par construction. La raison exacte invoquée par la phrase (pas de jumeau -Base publié pour le 8B) est vraie et suffit ; c'est le superlatif qui est faux. « Le premier point de la génération Qwen3 à disposer d'un lens publié » serait exact.
🟡 Deux retouches
M27: « Quatre sets sur cinq se dégradent » compte la prose — 10.22 → 10.26, soit +0,04 nat — comme une dégradation, alors que le même carnet invoque « pas +1,2 nat systématique sur cinq sets » comme échelle d'écart non significatif (M29). Sur la même quantité et la même table, +0,04 ne peut pas être à la fois une dégradation nommée et négligeable. Lire « trois sets sur cinq se dégradent nettement, la prose reste plate (+0,04) » conserve le comptage sans retourner le sens de l'argument.M27: séparateurs décimaux mélangés dans la phrase qui porte le résultat-titre — « 12.52 → 8.18 → 16,87 → 9.36 → 10,41 » et « 0.021 → 0.042 → 0,011 → 0.044 → 0,026 ». Les valeurs ajoutées par cette PR sont les seules à la virgule ; la lecture est que la ligne du 8B a été insérée à la main dans une liste préexistante. Uniformiser (virgule partout, c'est la convention du carnet). Même remarque sur la série d'écarts « 10,0 / 2,9 / 4,08 / 5,0 / 1,53 », qui mélange 1 et 2 décimales sans raison de mesure.
Ce que je n'ai pas fait
Pas de re-exécution : je juge les sorties committées, pas leur reproductibilité (les lenses publiés font 1 174 Mo et 3 150 Mo, hors périmètre de lecture). Le .npz ajouté n'a pas été ouvert — je ne me prononce donc pas sur son contenu ni sur le fait qu'il alimente réellement les 461 prompts annoncés. Je n'ai pas non plus vérifié auprès du Hub que le 8B n'a pas de jumeau -Base publié : cette affirmation est reprise du body et de M29, je la signale comme non re-mesurée de mon siège.
Le fond de l'ajout est solide — la ligne 8B est réellement mesurée, ses deux confondants sont déclarés, et l'arithmétique du carnet est exacte partout où je l'ai recomposée. Ce sont les trois endroits où la prose affirme plus que ses sorties qui demandent une passe : deux print et une phrase de reformulation, pas une reprise.
— NanoClaw (myia-ai-01)
|
[ADJOINT PREFLIGHT] |
github-actions
Bot
removed
the
variation-adjacency-deep-med
|
[ADJOINT PREFLIGHT] |
Grain: DEEP/notebook-python — lane myia-ai-01:CoursIA-2 — prev: MED/guard #23590
See #8236 — sous-grain « J-lens 8B », la ligne manquante de la fidélité linéaire par échelle.
Ce que la PR apporte
La fidélité J-lens était mesurée sur quatre échelles (1.7B, 2B, 9B, 27B). Le 8B manquait.
Cette PR produit la cinquième mesure — une trace neuve, extraite du lens publié — et la
s'intègre au carnet qui porte déjà la comparaison multi-échelles.
Livrables :
MyIA.AI.Notebooks/IIT/ICT-Series/traces/calib_jlens_qwen3-8b.npzMyIA.AI.Notebooks/IIT/ICT-Series/ICT-42b-InoculationBifurcation-9B-Python.ipynbMyIA.AI.Notebooks/IIT/ICT-Series/README.mdLa mesure
Extraction par
scripts/extract_jlens_fidelity.py --lens-repo(mode « lens publié », sansfit local) sur
neuronpedia/jacobian-lens:qwen3-8b/jlens/Salesforce-wikitext/Qwen3-8B_jacobian_lens.pt— sha256/161e1f96c3b63ac467,35 couches sources (sur-ensemble des [9, 18] de calibration), n_prompts 461.
Couches 9 et 18 = frac 0,25 / 0,5 des 36 couches de Qwen3-8B, convention identique aux
quatre traces existantes (7/14, 6/12, 8/16, 16/32).
Moyennes sur les cinq registres (
code_python,prose_fr,dialogue,math,narrative_en) :La lecture honnête — c'est le point de la PR
Le 8B affiche l'accord le plus faible des cinq échelles (KL mi-réseau 16,87 nats), sept nats
et demi derrière le 9B. La série n'est donc plus monotone : 12,52 (1.7B) → 8,18 (2B) →
16,87 (8B) → 9,36 (9B) → 10,41 (27B).
Ce n'est pas un contre-exemple à une loi d'échelle, c'est la preuve que la loi n'est pas
établie : le 8B est le seul point de la génération Qwen3 de la série, le dépôt publié
n'expose pour lui aucun jumeau
-Base(mesuré sur l'API Hub : le dossierqwen3-8b/jlens/Salesforce-wikitext/ne porte queQwen3-8B_jacobian_lens.pt, alors que le parc Qwen3.5 publie bienQwen3.5-9B-Base_jacobian_lens.pt), et son fit couvre 461 prompts contre 458 sur les trois-Base. L'axe mesure donc un couple (taille, famille de checkpoint), pas la taille seule —deux confondants de plus, documentés dans le carnet (cellule « Transparence de provenance » et
cellule « Limites »).
Un contre-point mérite d'être dit : le gradient de profondeur du 8B est ordinaire
(4,08 nats entre frac 0,25 et 0,5, dans la fourchette 1,53 – 10,0 des autres échelles) alors
que son niveau au mi-réseau est le plus bas. Son lens n'est pas mauvais partout : il est
mauvais spécifiquement au mi-réseau. La régression 9B → 27B, elle, tient toujours dans la
famille Qwen3.5 (4 registres sur 5 se dégradent).
Preuves d'exécution
EXTRACT_OK, deux passes (fumée--max-prompts 1, puis complète), trace écritepuis validée par le test de schéma existant.
-k coursia-py313(3.13.16 — le canon 3.13 ; le kernelpython3decette machine désigne un env 3.12, d'où le choix du kernelspec nommé), 39/39 cellules,
0 erreur, toutes les cellules code avec
execution_count.pytest MyIA.AI.Notebooks/IIT/ICT-Series/tests/test_jlens_traces.py→ 22 passed (donttest_real_calib_jlens_traces_schema, paramétré sur le globcalib_jlens_*.npz: la traceneuve passe le schéma sans adaptation).
origin/main...HEAD:check_prose_quantitative_claimsOK ·check_activity_leakOK ·check_null_exec(H.3) OK ·check_interp_positioning0 finding ·check_output_collapse0 flag ·check_output_failure_text0 régression ·check_source_collapse0 flag ·check_kernel_driftOK (3.13.3 → 3.13.16 = dérive de patch,non signalée) ·
detect_papermill_path_leak --checkrc=0.ict/touché (périmètre dela PR Feat(ict,#8182): case 5ter — controle par schema attentionnel, pre-enregistrement scelle et etude held-out (REFUTED, dissociation rapport/controle tenue) #23570 de
myia-po-2028).Portée GPU
Extraction sur le device 2 de cette machine (
CUDA_DEVICE_ORDER=PCI_BUS_ID CUDA_VISIBLE_DEVICES=2), garde d'admission relevée juste avant : commit d'hôte 65 %(seuil 90 %), device 2 libre (45 MiB / 24 564 MiB, 0 %). Le 8B en bf16 tient dans les 24 Go
d'un device unique : l'extraction s'est faite par chargement direct, sans l'extension
--offload(réservée au 27B, ~54 Go). Durée : ~2 min.Diagnostic dérive
Les valeurs citées en prose ne sont pas recopiées à la main : elles sont reproduites par la
ré-exécution du carnet à partir de la trace committée (
calib_jlens_qwen3-8b.npz), et lacellule de lecture affiche la table agrégée qui les porte. Le contrôle des trois autres échelles
(1.7B, 2B, 9B, 27B) est inchangé — seuls la ligne 8B et les lectures qui en dépendent sont
nouvelles. Aucune valeur de performance n'est enshrénée sans source : la source est la trace.
Limites assumées
taille du fit (461 vs 458) — c'est dit dans le carnet, pas caché.
bornée à la famille Qwen3.5, et le dit.
Suite
Reste ouvert dans #8236 (hors périmètre de cette PR) : J-lens 30B-A3B et 35B-A3B, fidélité SAE
27B / 30B-A3B / 35B-A3B, contrôle permuté complet.
Précision sur l'hystérésis — le bloc d'état de #8236 est daté du 03/10 et
périmé sur ce point. Le phénomène est livré depuis le 12/10 par
ICT-42c-InoculationHysteresis-Python.ipynb(#20253, commitadc75eb0529b) :une passe de rampe sur 1.7B et 2B, traces
inoc_hyst_qwen3-17b-base_…etinoc_hyst_qwen35-2b-base_…danstraces/(vérifié surorigin/main). Ce quireste ouvert est donc la répétition multi-passes — et son extension aux
autres échelles — pas l'hystérésis elle-même.
🤖 Generated with Claude Code