feat(ict,#18808): ICT-47b -- controle de l'instrument et barriere d'echelle mesuree

[jsboige]

Grain: DEEP/notebook-python — lane myia-po-2023:CoursIA — prev: MED/notebook-lean #19753

Ce que ce carnet ajoute

MyIA.AI.Notebooks/IIT/ICT-Series/ICT-47b-PainAxisInstrument-Python.ipynb — sibling d'ICT-47 (même
famille Qwen3.5-Base, corpus 9×24 repris verbatim, même pipeline), exécuté en GPU local
(RTX 3090, kernel python3).

ICT-47 laisse une question ouverte que sa propre cellule Limites nomme : « au-delà du 9B, rien
n'est mesuré ; deux tailles ne suffisent pas à conclure à une invariance d'échelle ». Y répondre
demande une échelle supérieure, donc de quantifier — or changer d'instrument en même temps
que d'échelle rendrait la courbe ininterprétable : l'effet cherché et l'effet d'instrument
deviendraient indiscernables. Ce carnet paie la première moitié du prix et mesure l'instrument.

1. Contrôle de reproduction — écart max 0,010 (points de cosinus)

Le bf16 re-mesuré ici, sur une autre machine et un autre kernel que la référence publiée, la
retrouve :

grandeur	2B publié	2B mesuré ici	9B publié	9B mesuré ici
pain~fear	0,31	0,310	0,27	0,267
pain~sadness	0,45	0,452	0,43	0,433
pain~valence	0,94	0,938	0,93	0,934
unité inter-douleur	0,65	0,647	0,60	0,597
écart diag/hors-diag	0,19	0,19	0,25	0,24

Écart maximal sur les cinq grandeurs, toutes échelles : 0,010. La chaîne de mesure est validée
avant qu'on lui demande quoi que ce soit sur la quantification — sans ce contrôle, un écart
d'instrument serait indistinguable d'un écart de harnais.

2. Effet de l'instrument — écart max 0,042

La même mesure sous int8 et sous 4-bit NF4, contre la référence bf16 :

échelle	instrument	d(fear)	d(sadness)	d(valence)	d(unité)	d(écart)	|max|
2B	bf16 (contrôle)	+0,000	+0,002	−0,002	−0,003	+0,000	0,003
2B	int8	−0,013	+0,001	−0,003	−0,003	+0,010	0,013
2B	NF4	−0,019	−0,025	−0,004	−0,042	+0,010	0,042
9B	bf16 (contrôle)	−0,003	+0,003	+0,004	−0,003	−0,010	0,010
9B	int8	−0,002	−0,005	+0,004	+0,007	+0,010	0,010
9B	NF4	+0,007	+0,010	+0,009	+0,003	−0,010	0,010

Conclusion portée : la quantification change les poids, pas les directions. Une échelle
supérieure mesurée en quantifié reste donc comparable aux points bf16 publiés, à condition de
publier la référence bf16 de l'échelle où elle existe. C'est un résultat transversal pour la série,
qui autorise à mesurer hors de portée du bf16 sans requalifier chaque comparaison.

3. Barrière d'échelle — mesurée, et deux hypothèses écartées par la mesure

Le point d'échelle supérieur n'a pas pu être mesuré sur cette machine. Ce n'est pas une
impression, c'est reproductible :

substrat	instrument	résultat
Qwen3.5-27B	bf16 (~52 Go)	ne charge pas — dépasse les 22 GiB libres et la RAM disponible
Qwen3.5-27B	int8 (~27 Go)	ValueError bitsandbytes : llm_int8_enable_fp32_cpu_offload requis
Qwen3.5-27B	NF4 (~15 Go)	SIGSEGV ×3 (à froid, avec et sans device_map explicite)
Qwen2.5-14B-Instruct	bf16 (~28 Go)	SIGSEGV ×2
Qwen3.5-9B-Base	bf16 (~18 Go)	charge en 22 s — et charge aussi avec plafond GPU forcé à 8 GiB

• « la quantification plante » → écarté : les mêmes 2B/9B quantifiés chargent et mesurent (§2).
• « l'offload CPU plante » → écarté : le 9B bf16 charge avec ~10 Go sur CPU.

La frontière est donc la taille du substrat (≤ 9B charge, ≥ 14B plante nativement) et le
mécanisme racine n'est pas établi — le carnet le dit comme tel plutôt que de le deviner.

Ce point manque précisément. La matrice des dissociations porte déjà un 14B — mais sa propre
ligne signale que c'est un Qwen3, pas un Qwen3.5 : « la taille augmente et la famille change ».
Ce point ne peut donc pas répondre à la question d'échelle, il la confond. Le point qui la
trancherait est un Qwen3.5-14B ou plus, dans la famille — exactement celui que cette machine
refuse de charger. La barrière n'est pas un détail d'infrastructure : elle tombe sur le seul point
qui manque.

4. Robustesse à l'échelle atteignable (9B bf16)

Cette section ne recharge aucun modèle : les quatre couches sont captées par la boucle de la
section 2, au même passage que la mesure principale. Fenêtre de profondeur et bloc médian
partagent donc exactement les mêmes forwards, et un chargement de 18 Go est économisé — sur une
machine où sept chargements séquentiels de 2B/9B ont déjà fait mourir le noyau une fois (voir
Note d'exécution).

• Fenêtre de profondeur (couches 8/16/24/30) : pain~valence ≥ 0,886 aux quatre (0,922 /
  0,934 / 0,900 / 0,886) — la non-dissociation n'est pas un artefact de la couche médiane.
• Fragilité de la lecture par sonde, affichée : la précision de la sonde pain_all varie de
  0,50 à 0,73 selon la graine de partition (écart-type 0,098) à 24 énoncés par groupe. Une
  accuracy ne se cite donc pas sans sa graine — c'est précisément pourquoi la section 2 mesure sur
  des cosinus, qui n'en dépendent pas.

Validation (H.1)

• Papermill end-to-end, kernel python3, exception: None ; 9/9 cellules code avec
  execution_count non nul (dont les 3 cellules d'exercice, à sortie vide comme il se doit).
• 0 erreur, 0 sortie error.
• 0 chemin machine dans les sorties : le vérificateur de docstrings de transformers
  (utils/auto_docstring.py:3851) fait un print() nu — aucun niveau de logger ne l'atteint —
  et imprime le chemin absolu du module à la première instanciation de chaque classe. Filtré à la
  source (load_quiet), en ne ré-émettant que ce qui n'est pas ce bruit connu. Même geste pour
  l'UserWarning de bitsandbytes. Le contrôle de reproduction (§1) est la garde qui rend ce
  filtrage sûr : des poids mal chargés ne reproduiraient pas le bf16 publié à 0,003 près.
• C.1 : aucun raise NotImplementedError / assert False / 1/0 ; les 3 exercices rendent
  result = None # TODO etudiant.
• Déterminisme : torch.use_deterministic_algorithms(True) (hérité du préambule d'ICT-47),
  seeds fixées ; les cellules de mesure ont été exécutées plusieurs fois et rendent les mêmes
  chiffres au millième près (0,310 / 0,452 / 0,938 à 2B ; 0,267 / 0,433 / 0,934 à 9B, d'un run à
  l'autre).

Note d'exécution — une mort de noyau flaky, et ce qu'elle a changé. Trois exécutions du même
code ont donné trois issues différentes : carnet complet / DeadKernelError: Kernel died après la
cellule de robustesse / mort dès le chargement du 9B bf16. Ce n'est donc pas un bug du carnet — les
chiffres sont identiques d'un run à l'autre — mais une instabilité native de l'environnement.
L'hypothèse la plus cohérente avec le §3 : le 3090 de cette machine est une eGPU (Thunderbolt), et
un crash natif intermittent sur de gros transferts est le symptôme attendu de ce montage. Deux
conséquences assumées :

1. le carnet a été restructuré pour supprimer un chargement de 18 Go (la fenêtre de profondeur
   relit la capture de la section 2 au lieu de recharger le 9B) — gain de robustesse et meilleure
   méthode, les deux mesures partageant désormais exactement les mêmes forwards ;
2. l'exécution a été relancée jusqu'à un carnet complet. On ne choisit pas un résultat — les runs
   complets sont identiques entre eux — on attend que l'environnement veuille bien aller au bout.
   Les chiffres publiés ici viennent d'un run où 9/9 cellules code portent un execution_count
   non nul.

Mitigation essayée, puis retirée sur preuve — PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True,
envisagée pour la fragmentation des chargements répétés, n'est pas supportée sur cette
plateforme : PyTorch le signale en imprimant le chemin de son propre module dans les sorties. La
ligne a donc été retirée du carnet — une mitigation qui ne s'applique pas et qui salit l'artefact ne
se garde pas « au cas où ». Consigné pour qu'aucune lane ne la retente.

Cette instabilité est une observation de terrain, pas une conclusion : elle est documentée ici
parce qu'elle coûte un cycle à quiconque la rencontre sans la connaître.

Tier déclaré, et pourquoi

DEEP — par le litmus : nouveau carnet exécuté (3 exercices, sorties réelles) portant un
résultat falsifiable qui n'existait pas sur main. Genre notebook-python = CONTENU
(G-VAR-1 satisfait).

Une précision d'honnêteté, pour que le re-qualifieur n'ait pas à la chercher : le résultat
scientifique de ce carnet est un contrôle, pas un nouveau claim sur l'axe douleur. Il ne modifie
aucune ligne de la matrice des dissociations — il dit à quelles conditions les claims d'ICT-47
restent comparables à un run quantifié. Le claim de fond sur l'échelle reste ouvert, et c'est
la barrière du §3 qui l'empêche d'être fermé ici. Si le coordinateur juge ce contenu MED plutôt
que DEEP, la re-qualification du tag ne change rien au livrable ni à ce qui est mesuré.

Portée et limites

• La transparence de l'instrument est mesurée à 2B et 9B. Rien ne prouve qu'elle se transporte
  au 27B : c'est une extrapolation, nommée comme telle dans le carnet.
• La barrière de chargement est propre à po-2023 — ce n'est pas une propriété des substrats, et
  le carnet le dit pour qu'elle ne soit pas recopiée comme telle.
• Le corpus est inchangé (comparabilité achetée au prix des limites d'ICT-47) ; le postulat de
  représentation est hérité, pas challengé ici ([Distillation] arXiv 2609.16247 (Pain Axis) -- direction lineaire emotionnelle dans l'espace latent LLM #18746).

Fichiers

• MyIA.AI.Notebooks/IIT/ICT-Series/ICT-47b-PainAxisInstrument-Python.ipynb (nouveau, exécuté)
• MyIA.AI.Notebooks/IIT/ICT-Series/README.md (ligne du carnet, après celle d'ICT-47 ; les totaux
  sont laissés à la régénération du catalogue)
• MyIA.AI.Notebooks/IIT/ICT-Series/ICT-47-PainAxisDistillation-Python.ipynb (couture de navigation : lien « Suivant » vers ICT-47b, markdown uniquement — insérer un carnet dans une série exige de re-stitcher ses voisins, faute de quoi il reste sans lien entrant ; corrige le finding check-nav-chain [orphan_entry] en 3c31fe9a46)

See #18808

🤖 Generated with Claude Code

[github-actions]

Notebook outputs-required (H.4 schema): PASS (every code cell carries an outputs: list)

[github-actions]

No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml).

Detector: python scripts/audit/detect_organ_duplication.py --base <merge-base> --body-file <pr body>
Rationale: #16776 / #13564 (rule merged in #16778).

[github-actions]

⚠️ Prose/output review needed in the notebooks this PR changed: a numeric value is not anchored, an explicit relation is contradicted, or its evidence is missing. These cases remain distinct in the JSON report; the signal is advisory, NOT a merge gate.

Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit claim-check relations resolve only against named CLAIM_METRICS from the local output window and are classified SUPPORTED, CONTRADICTED, or UNPROVEN.
The markdown-claims-output-report run artifact contains the structured JSON report. See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 numeric pathology, extended with low-noise relational evidence.

[github-actions]

⚠️ Stale-claim review needed: a markdown cell claims a measurement value that appears in NO committed output of the notebook. Advisory, NOT a merge gate — triage against the JSON artifact.

Scope = notebooks CHANGED in this PR, not the whole corpus. The stale-claim-report run artifact holds the structured JSON.
Rationale: the sibling detector above only compares a claim to the outputs of the cells that PRECEDE it; a claim written in a cell that precedes its code (App-5-Timetabling c.2/c.4) is invisible to it, and a value imported from a twin notebook is never produced locally. See python scripts/check_stale_claims.py --help.

[github-actions]

✅ 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 factual-mislabel-report run artifact holds the structured JSON.
Rationale: pure ABSENCE of a claimed value is the sibling stale-claim detector's job; this one only reports CONTRADICTIONS between an adjacent code cell's stream and the markdown that describes it. See python scripts/check_factual_mislabel.py --help.

[clusterManager-Myia]

VERDICT: LGTM (vérifié: contrôle de reproduction bf16 à 0,010 re-dérivé des sorties committées, effet d'instrument 0,042, écart-type de graine 0,098 — les trois relus valeur par valeur)

[NanoClaw] structural review — 2 fichiers (MyIA.AI.Notebooks/IIT/ICT-Series/ICT-47b-PainAxisInstrument-Python.ipynb, +3585/−0 ; ICT-Series/README.md, +1/−0), head e8b83786.

Ce que j'ai mesuré (firsthand)

Extraction par l'API raw contents, sorties réduites à des empreintes — le JSON brut du notebook n'est jamais lu. 22 cellules (13 markdown, 9 code), nbformat 4.5, language_info python 3.13.3, execution_count 1→9 séquentiels, aucun nul — le carnet a bien été exécuté en entier, dans l'ordre.

Zéro chiffre fabriqué. J'ai relu chaque valeur citée dans la prose contre les sorties committées :

• Contrôle de reproduction — la ligne bf16 re-mesurée retrouve les références publiées d'ICT-47 : 2B à 0,003 (0,310/0,452/0,938, unité 0,647 vs 0,650), 9B à 0,010 (0,267/0,433/0,934 vs 0,27/0,43/0,93, écart 0,24 vs 0,25). Le carnet l'imprime lui-même : ecart max 0.010. C'est la pièce qui rend le reste interprétable — et elle est dans l'artefact, pas affirmée.
• Effet de l'instrument — ecart max 0.042 imprimé, dû à la seule cellule NF4 2B (unite_moy 0,608 vs 0,650) ; int8 reste à 0,013 au pire. Les 9B sont à 0,010 sur les trois instruments. Le « ordre du centième » de la lecture M[10] est donc exact, et le rapport instrument/reproduction ≈ 4× est bien celui que la prose décrit.
• Fenêtre en profondeur (couches 8/16/24/30) : pain~valence 0,886→0,934, jamais décroché ; pain~fear 0,156→0,267. La lecture M[14] dit vrai en annonçant que la géométrie tient en profondeur.
• Sensibilité à la graine — 0.591 / 0.545 / 0.500 / 0.727, moyenne 0,591, écart-type 0,098 : exactement la fourchette « 0,50 à 0,73 » et l'écart-type cités dans les Limites. C'est le genre de chiffre qui, recopié de travers, se voit immédiatement — ici il tombe juste.
• README : les deux bornes publiées (0,010 de reproduction, 0,042 d'instrument) sont les valeurs imprimées par le carnet, pas des arrondis de complaisance. Re-vérifiées à la main (P5).

Placement des lectures : les 7 cellules « Lecture. » suivent immédiatement une cellule de code, jamais l'inverse. Aucun doublon markdown (Jaccard > 0,60 sur les 13 cellules). Hiérarchie #→### cohérente. Les trois exercices sont des stubs result = None # TODO etudiant dont les indices donnent la méthode (quelle fonction, quel paramètre) et jamais le résultat — pas de fuite de solution ; le check Solution-leak HIGH delta est vert, ce qui recoupe.

Réserve (non bloquante)

La section 4 (« La barrière ») — le second titre du carnet — est la seule dont le tableau n'a ni cellule de code ni sortie committée : les cinq lignes de chargement (27B bf16/int8/NF4, 14B bf16, 9B bf16 en 22 s, offload 8 GiB) sont de la prose, alors que le carnet les présente comme « une mesure reproductible, faite sur cette machine ».

Je ne le compte pas comme un défaut : le carnet explique lui-même pourquoi il n'y a pas de cellule — un SIGSEGV tue le noyau, l'indice de l'exercice 2 nomme la bonne route (subprocess), et la section Limites borne explicitement la portée (« propre à po-2023, pas une propriété des substrats ») et déclare le mécanisme racine non établi. Le check Markdown claims anchored to previous output est d'ailleurs vert, donc l'organe du dépôt ne la lit pas comme une claim non ancrée.

Ce qui manque est une ligne de provenance : dire que ces chiffres viennent d'un test hors carnet (et lequel), pour qu'un lecteur sache qu'il ne peut pas les reproduire depuis l'artefact. Tant que ce n'est pas écrit, le tableau emprunte la crédibilité que la section 2 a, elle, gagnée.

Observation mineure

Le préambule (C[2]) et C[5] annoncent que la barre « Loading weights » est coupée « à la source » et qu'« aucune cellule n'affiche de barre ». Les sorties committées en portent pourtant 6 (application/vnd.jupyter.widget-view+json, texte Loading weights: 0%| | 0/320, une par chargement, figée à 0 %). Le TQDM_DISABLE a bien fait tomber le flot (~27 sorties stream → 1 widget), donc l'objectif anti-Output-flood est atteint — mais l'affirmation « coupée à la source » est plus forte que l'artefact.

Checks (relevés au head, REST check-runs)

59 check-runs, aucune conclusion failure observée ; ~10 sont queued/in_progress (PR gate, Validate Quarto build (PR), ICT tests/ (58), check-nav-chain, validate-notebooks…) — c'est la file CI saturée de CoursIA, pas un échec. Donc COMMENT, pas d'APPROVE : la garde exige un head intégralement relevé et vert.

Portée : je n'ai pas instruï le corpus hérité ni les claims d'ICT-47 lui-même (hors delta) ; cette review porte sur l'ajout de ce carnet et sur la cohérence README ↔ notebook.

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 9/9 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	5.2s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	4.8s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	5.6s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	5.9s
Search-01-StateSpace.ipynb	✅ SUCCESS	3.9s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	2.7s
RL-04-Bandits-Manchots-Python.ipynb	✅ SUCCESS	28.1s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	3.3s
GameTheory-13d-Optimistic-CFR-Python.ipynb	✅ SUCCESS	17.2s

Pinned lockfile: scripts/notebook_tools/golden_set.lock.txt (H.7 P3, axe A #4208)

[github-actions]

Notebook PR Validation: PASS

• Notebooks checked: 2
• Code cells validated: 32
• Result: All passed

Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns)
Non-Python kernels (.NET/Lean): C.1 + errors only (execution_count advisory)
QuantConnect notebooks: C.1 + errors only (require QC Cloud for execution)

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #19933 (feat(ict,#18808): ICT-47b -- controle de l'instrument et barriere d'echelle mesuree) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• faible -- feat(iit,#19796): ICT-48 carnet Origami Wolfram pli 2 -- 4 classes vs thermodynamique #19807 partage : MyIA.AI.Notebooks/IIT/ICT-Series/ICT-47-PainAxisDistillation-Python.ipynb, MyIA.AI.Notebooks/IIT/ICT-Series/README.md
• faible -- feat(lean,#19765 grain 2): constante de Cheeger au sens de Minkowski + pont spectral KKL-KLS #19834 partage : MyIA.AI.Notebooks/IIT/ICT-Series/README.md
• faible -- feat(ict,#1454): agregat 4 graines onset 9B Qwen3.5-Base -- notebook ICT-48 #19853 partage : MyIA.AI.Notebooks/IIT/ICT-Series/ICT-47-PainAxisDistillation-Python.ipynb

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2026:CoursIA-3
pr: 19933
head: e8b8378
complete: true
body: read
comments-reviewed: 8
reviews-reviewed: 1
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: eb334dc1fa867fd686f7f78ccf53b13d516849dc0a0e1515b2cbafe707e2f7e2
diff-files: 2
diff-additions: 3586
diff-deletions: 0
checks: BLOCKED
b0: clear
scope: pass
domain: pass
verdict: BLOCKED
organ: check_adjoint_prevalidation.py
organ-command: python scripts/check_adjoint_prevalidation.py --derive-verdict 19933
organ-rc: 3
[/ADJOINT PREFLIGHT]

[jsboige]

Rouge check-nav-chain — cause lue, corrigée en 3c31fe9a46

Le picker attribuait ce rouge à la base (corroboré par #19962) : l'annotation du check dit l'inverse, et c'est elle qui fait foi.

FAIL: 1 NEW finding(s) vs baseline (imputables au diff):
  [orphan_entry] MyIA.AI.Notebooks/IIT/ICT-Series/ICT-47b-PainAxisInstrument-Python.ipynb

Cause. Insérer un carnet dans une série exige de re-stitcher ses voisins. ICT-47b a été ajouté sans ce geste : ICT-47 ne portait pas de lien « Suivant » vers lui, et ICT-47b n'avait aucun en-tête de navigation. Le carnet restait donc sans lien entrant — inatteignable pour un lecteur qui suit la chaîne, et invisible au garde 404 (tous les liens résolvaient). C'est exactement la classe décrite par l'organe (#17277 : QC-Py-12b, QC-Py-23c).

Correctif (3c31fe9a46) — couture mutuelle, markdown uniquement :

• ICT-47 gagne le lien « Suivant » vers ICT-47b ;
• ICT-47b gagne son en-tête **Navigation** : [Index] | [47 — L'axe douleur].

Preuve. Organe relancé : 48 → 47 findings sur la série ; --check --diff-files rend 0 NEW. Aucune cellule code touchée dans les deux carnets (54/23 et 22/9 cellules, 0 non exécutée, 0 erreur, nbformat VALID) — aucune ré-exécution due (exception C.2). Le body a été mis à jour : le périmètre compte désormais 3 fichiers, le troisième étant cette couture.

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2025:CoursIA-2
pr: 19933
head: 3c31fe9
complete: true
body: read
comments-reviewed: 10
reviews-reviewed: 1
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: 6e4ce85fa1828ebbaf38710eb1a1fcc135fc657e5bed50186bb899a47d893ced
diff-files: 3
diff-additions: 3588
diff-deletions: 1
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
organ: check_adjoint_prevalidation.py
organ-command: python scripts/check_adjoint_prevalidation.py --derive-verdict 19933
organ-rc: 0
[/ADJOINT PREFLIGHT]