Skip to content

Epic : Schmidhuber — elargir le logement, pas le construire (curation en cours) #16775

Open
Open
Epic : Schmidhuber — elargir le logement, pas le construire (curation en cours)#16775

Description

@myia-ai-01
myia-ai-01
opened on Sep 18, 2026

État mesuré au 2026-10-05 (lane myia-po-2025:CoursIA-2, passe consolidation #13906 — mesuré sur origin/main + GitHub + gisement) — l'EPIC n'est pas fermable : le Grain 1 (attribution) est non livré à 0/3, et la curation du Grain 2, livrée le 23/09, n'a débouché sur aucune fille parce que son propre gate (source lue avant issue) n'est pas franchi — les 5 sources restent à acquérir. Tout ce qui reste est lane-actionnable ; aucun gate user.

Grain par grain :

Élément État Preuve
Grain 1 — attribution (3 critères de sortie du body) non livré, 0/3 (1) les 6 notebooks QC nn.LSTM portent toujours 0 citation hochreiter|schmidhuber (contrôles positifs : nn.LSTM matche bien 1 fichier chacun ; QC-Py-22 rend 1 hit citation — le zéro est réel, pas un glob muet) ; (2) Ha & Schmidhuber = 0 dans rl_8 ; (3) predictability minimization = 0 dans 3.6-Modeles-Generatifs. Rien n'a bougé depuis l'ouverture.
Grain 2 — curation livrée, non intégrée au body proposition D1-D5 par po-2027 (c. du 23/09 00:49, mesure re-vérifiée à c818f6abc) : chaque distillation porte source primaire, état gisement, cible vérifiée, organe, critère de sortie falsifiable — patron Tegmark appliqué. La citation d'ouverture de ce body (« le travail de curation… reste à faire ») est périmée depuis le 23/09.
Issues filles 0 ouverte sur 5 proposées aucune fille D1-D5 dans le pool (recherche Schmidhuber + noms) ; conforme au gate de l'EPIC : « une veine devient une issue quand sa source est lue » — pas encore le cas.
Acquisition gisement 0/5, re-mesuré le 05/10 409 PDF au gisement, 0 match (schmidhuber/wierstra/natural evolution/gödel/locoart/low-complexity/ashley/morphology) — l'état « À acquérir » de la table du 23/09 tient toujours.
Claim libéré le claim epic-wide de po-2027 (23/09, curation) est périmé depuis >48 h ; la curation qu'il annonçait est livrée.

Ce qui reste, dans l'ordre (tout est lane-actionnable) :

  1. Acquisition des 5 sources au gisement (téléchargement aux URL canoniques de la table du 23/09, classement, sha8) — prérequis du gate, aucun des 5 n'y est.
  2. Lectures intégrales puis ouverture des filles D1-D5 selon le patron Tegmark (cible re-vérifiée contre l'arbre du jour).
  3. Grain 1 en parallèle — travail borné d'attribution markdown-only (exception C.2, pas de ré-exécution), 3 critères falsifiables déjà écrits dans le body.

Portée de la mesure : body + 3 commentaires lus intégralement ; greps sur origin/main avec témoins positifs ; gisement scanné par nom de fichier (pas par contenu — le scan contenu du 23/09 reste la référence pour les mentions secondaires). Non mesuré : l'éventuel avancement des résonances candidates nommées par la curation (#16774 jalon 3, #13778, #11161) — hors périmètre de cette passe.

Epic : Schmidhuber — élargir le logement, pas le construire

Epic parapluie ouvert sur mandat user du 2026-09-18 (#16759, commentaire) : « pour l'instant il hante le dépôt plus qu'il ne l'habite, sur le même modèle de l'Epic parapluie qui nous offre cette issue. Le travail de curation pour déterminer les issues de cet Epic reste à faire. »

Cet Epic ouvre le parapluie et pose la mesure. Il ne pré-scope pas les distillations : le corpus n'est pas lu, et fabriquer des issues sur des textes non lus serait l'inverse du patron de l'Epic Tegmark (#16741), qui s'appuie sur 16 lectures intégrales.

Note de correction (ai-01). La première version de ce body affirmait que six notebooks utilisaient nn.LSTM « sans aucune citation », en laissant entendre que l'attribution manquait partout. C'était trop fort : le recensement complet montre que les notebooks d'enseignement citent Hochreiter & Schmidhuber depuis l'audit de fidélité #3164. La mesure exacte est ci-dessous ; la correction est conservée plutôt qu'effacée.

Le diagnostic, mesuré — 19 HABITE / 29 HANTE / 8 VOISIN

Schmidhuber est l'une des quatre fibres déclarées de la tresse ICT (docs/ict/tresse-cartographie.md §1.2, « la compression comme dissociations »). Il n'est donc pas un nom qu'on ferait entrer : il est déjà structurant. Recensement firsthand sur main (c818f6abc) — 48 fichiers, 111 lignes portent son nom.

Ce qui HABITE l'habite sérieusement (19 artefacts)

C'est la nuance que le diagnostic doit intégrer, et elle change le geste :

Donc : ce n'est pas un fantôme invoqué. C'est un locataire d'une seule pièce dans une maison de sept strates. L'Epic doit élargir le logement, pas le construire.

Ce qui HANTE (29 fichiers)

Prose de cadrage, essentiellement : 13 fichiers docs/, 4 notebooks qui le citent en thèse sans exécuter sa jambe (ICT-14 exécute Friston, pas lui), 5 fichiers slides/, 2 docstrings de modules qui le nomment sans importer beauty.

Ce qui est VOISIN — son idée sans son nom (8 artefacts)

Artefact Mesure
6 notebooks QC de recherche/projets (research_lstm, Crypto-LSTM-Prediction, DL-LSTM, Ensemble-DLinear-TFT, Mamba-Crypto-Ranking, TFT-Crypto-Ranking) nn.LSTM exécuté (8 à 17 cellules chacun), hochreiter|schmidhuber = 0
RL/rl_8_model_based_dyna_q.ipynb:63 « World Models » cité en exemple — « Ha & Schmidhuber » : 0 hit dans tout le dépôt
ML/…/3.6-Modeles-Generatifs.ipynb GAN attribué à Goodfellow 2014 ; l'antériorité predictability minimization (1992) : 0 hit

L'écart est donc réel mais borné, et déjà entamé : le geste #3164 a couvert la surface d'enseignement, pas la surface de recherche. C'est une lacune que leiden-declaration-position.md nomme déjà — « la provenance n'est pas encore uniforme dans tous les notebooks historiques » — et nous la tenons ici chiffrée.

Ce qui est absent — 0 hit dans tout le dépôt

Gödel machine · Algorithmic Theory of Everything / A Computer Scientist's View of Life, the Universe and Everything · upside-down RL · predictability minimization · fast weight programmers / transformers linéaires · Ha & Schmidhuber world models.

Low-complexity art : présent uniquement en slide (slides/07-elargissements/slides.marp.md:640-646, « Compression, Esthétique et Cosmologie ») — prose, zéro exécutable.

Gisement bibliographique — 0 PDF, vérifié deux fois

G:\Mon Drive\MyIA\IA\Bibliographie IA : recherche par nom de fichier et scan du contenu des 2 premières pages des 355 PDF → 0 hit nom, 0 hit concept. (Le seul « Schmid » du gisement est une autre personne.) À contraster avec les 16 PDF qui fondent l'Epic Tegmark. Comme #16741 a commencé par 16 lectures, celui-ci commence par une acquisition.

Grain 1 — compléter l'attribution là où elle manque (borné, falsifiable)

Porter le geste #3164 à la surface de recherche : les 6 notebooks QC nn.LSTM, le world models de rl_8, l'antériorité GAN de 3.6-Modeles-Generatifs.

  • Contrainte C.2 : ces notebooks sont exécutés. Une citation en markdown ne touche aucune cellule de code → exception markdown-only, pas de ré-exécution, ne pas rouvrir les sorties.
  • Critère de sortie : nn.LSTM sans citation passe de 6 à 0 dans les notebooks QC, chemins cités ; Ha & Schmidhuber et predictability minimization passent de 0 à ≥1 aux deux emplacements nommés.
  • Ce que ce grain n'est pas : un arbitrage de priorité scientifique. On cite, on ne tranche pas les querelles d'antériorité.

Grain 2 — la curation (le travail que tu dis restant)

Chaque œuvre entre avec : source primaire, présence au gisement, et résonance dépôt vérifiée contre l'arbre.

Œuvre État mesuré Résonance candidate
Low-complexity art (locoart) slide seulement, absent du gisement #16774 jalon 3 — et la slide existante est le point de départ, pas un doublon
Gödel machine 0 hit, absent du gisement auto-amélioration prouvée — pont direct avec la veine B de #16741 (vericoding, proof-integrity) : une machine qui prouve que sa réécriture l'améliore
« In the beginning was the code » 0 hit, absent ; titre exact à vérifier à la source (voisines : A Computer Scientist's View…, 1997 ; Algorithmic Theory of Everything, 2000) la veine MUH — c'est le texte que Tegmark cite dans R16
LSTM from scratch utilisé 6+ fois, jamais construit notebook d'implémentation ; le pont naturel entre l'usage QC et l'enseignement
Compression progress, Speed Prior, PowerPlay déjà HABITE et attribués (ict/beauty.py) rien à distiller — à citer comme acquis, pas à réouvrir

Rien de cette table n'est un engagement de livraison. Une ligne devient une issue quand sa source est lue et sa résonance vérifiée — patron #16741.

La colonne vertébrale : la longueur de description

Trois Epics, une quantité. Schmidhuber est le seul auteur des trois à être déjà une fibre déclarée — ce qui explique la forme exacte du diagnostic : on a importé son opération sans jamais importer ses textes.

Ce que cet Epic n'est pas

Règles de livraison

Curation — brief user du 2026-09-19

Le brief ouvre la curation en donnant d'abord une thèse de lecture : la marque de fabrique de cette œuvre est d'ajouter du Meta et/ou de la hiérarchie. Puis il nomme cinq résonances « pas forcément triviales », et laisse explicitement « la curation classique » aux lanes.

Ce qui suit qualifie ces cinq veines contre l'arbre (c818f6abc, quatre mesures firsthand). Aucune n'est un engagement de livraison : une veine devient une issue quand sa source est lue et sa cible re-vérifiée.

Révisions du 2026-09-19 (précisions user, deux passes). Six affirmations de la première version étaient fausses ou mal cadrées ; elles sont corrigées en place, la correction visible plutôt qu'effacée : (1) la 8ᵉ référence est désormais identifiée ; (2) « le harnais » ne désigne pas les sous-agents Claude Code mais la flotte de 7 machines ; (3) l'utilité mesurable existe — le taux de merge par dollar — elle n'est simplement pas dérivée ; (4) j'avais mesuré l'usage d'Infer.NET dans ce dépôt et laissé le chiffre passer pour une mesure de la bibliothèque ; (5) trois constats de la veine narration portaient sur un état périmé ou sur un futur — dont #15604, ouverte, que je n'avais pas trouvée ; (6) toute la veine A était mesurée sur le sous-module seul et ignorait 25 notebooks MGS-*, une Epic fermée (#12373) et sa boucle corrective encore ouverte (#13778).

Ces six-là sont une seule et même faute, et elle mérite d'être nommée : un chiffre juste sur le mauvais objet. Aucune de ces mesures n'était arithmétiquement fausse — chacune portait sur un périmètre plus étroit que la phrase qui la servait. C'est plus dangereux qu'un chiffre faux, parce que ça se lit comme une réponse. Deux sous-cas se sont répétés : mesurer notre usage et l'énoncer comme une propriété de l'objet (harnais, Infer.NET, sous-module) ; et interroger l'arbre quand l'état vit dans le pool d'issues — où une règle qui interdit de committer (bibliography-hygiene §2) garantit un zéro hit qui ne mesure que sa propre conformité.

La thèse, et ce que la mesure en dit

La thèse n'est pas décorative : elle prédit correctement la liste des absents déjà mesurée plus haut.

Absent mesuré (0 hit) Meta Hiérarchie
Gödel machine (réécriture de soi prouvée améliorante) ✔
Low-complexity art (un critère sur les œuvres) ✔
Fast weight programmers (un réseau programme l'autre) ✔
World models (contrôleur au-dessus d'un modèle du monde) ✔
Predictability minimization (deux réseaux en opposition) ✔
Upside-down RL (la commande devient l'entrée) ✔

Six absents sur sept portent exactement le motif que la thèse nomme. Et symétriquement, ce qui HABITE déjà le dépôt (ict/beauty.py : Speed Prior, PowerPlay, compression-progress) est du Meta pur — un critère sur l'apprentissage, jamais un apprenant. Le dépôt a donc importé une pièce de Meta et zéro hiérarchie.

C'est la lecture qui ordonne les veines ci-dessous : elles sont toutes des hiérarchies (garde au-dessus d'un optimiseur, graphe d'agents, distribution sur la recherche, arc sur des segments), c'est-à-dire la moitié manquante.

Veine A — MetaGeneticSharp : l'opérateur manquant et le régime qui l'encadre

Correction majeure — la v1 de cette veine a mesuré le sous-module seul. Elle a donc raté trois choses, toutes sur main ou dans le pool : la série MyIA.AI.Notebooks/Search/Part4-Metaheuristics/MGS-*, 25 notebooks ; l'Epic #12373 (MGS vs mealpy, CLOSED COMPLETED le 2026-09-01) avec ses successeurs #13777 (CLOSED) et #13778 (OPEN) ; et #16415 (Dream-RSI, CLOSED COMPLETED) qui nomme déjà, mot pour mot, le manque que A.2 décrit. Conséquence directe : ce que la v1 présentait comme une greffe neuve sur un socle vierge est en réalité la suite nommée d'un chantier fermé, dont le banc d'essai est déjà construit et dont la boucle corrective est déjà ouverte. La veine n'est pas affaiblie, elle est déplacée d'un cran — de « construire » vers « contribuer à une boucle ouverte ». C'est exactement la subsidiarité demandée, et c'est la v1 qui redémarrait le brûleur.

Ce qui existe déjà, et qui commande la forme de la contribution

Acquis Mesure firsthand
Série MGS 25 notebooks dans Part4-Metaheuristics/ — dont MGS-16-AlgorithmSelection (14 cellules code, 14 exécutées) et MGS-17-ParameterControl (11/11)
Le banc de dé-biaisement MGS-10-CenterBias (biais central) et MGS-12-AxisAlignment (rotation) instrumentent les deux techniques du banc CEC ; les décorateurs sont des classes réelles du fork — Extensions/ShiftedFitness.cs, Extensions/RotatedFitness.cs, chacune avec ses tests NUnit (Extensions.Tests/*FitnessTests.cs)
Diagnostic déjà rendu #12373 : coût systématique (mealpy plus cher par évaluation sur 8/9 paires, ratio médian 2,38×), qualité spécifique à la paire (mealpy devant 6/9, MGS devant 3/9). Corollaire écrit : « le noyau n'est pas la cause de l'écart de qualité, ce qui déplace le travail correctif d'un cran »
Boucle corrective ouverte #13778 : baseline figée → diagnostic causal → correctif atomique dans le sous-module → re-benchmark apparié. Graines {0,1,7,42}, budgets et checkpoints 25/50/75/100 % identiques avant/après, verdict obligatoire IMPROVES / NO IMPROVEMENT / TRADE-OFF / INCONCLUSIVE — « pas de « prometteur » »
Série vivante, pas dormante MGS-17-ParameterControl a été modifiée hier — PR #16579, mergée le 2026-09-18 (grain densité #13410). Une lane est déjà dans ces notebooks
Le tiers manquant, déjà nommé #16415 (Dream-RSI) : « le tiers manquant de l'Epic : pas seulement « quel moteur » mais « quelle politique d'exploration au-dessus du moteur » »

Contrainte qui tombe directement sur cette veine. #13778 porte en non-objectif « multiplier les notebooks de classement », et clôt par « les prochains face-à-face sont gelés tant qu'ils n'alimentent pas cette boucle corrective ». Un dixième moteur mis au banc serait donc refusé par l'Epic en cours. Une contribution Schmidhuber n'entre ici que comme correctif causal d'un écart mesuré, jamais comme un concurrent de plus au classement. C'est une contrainte utile : elle rend la veine falsifiable au lieu de collectionnable.

A.1 — L'opérateur : Natural Evolution Strategies

Publication — Wierstra, Schaul, Glasmachers, Sun, Peters, Schmidhuber, JMLR 15 (2014) 949-980.

La mesure de voisinage, repo-wide cette fois (la v1 annonçait « CMA = 1 seul hit » — c'était le sous-module seul, relu à tort comme le dépôt) :

Terme Repo-wide Ce que c'est réellement
natural gradient · gradient naturel · NaturalGradient 0 —
EvolutionStrategy (identifiant de code) 0 —
« Evolution Stratégies » (prose) MGS-17 §4, et lui seul nommé comme le vrai que la démo avoue ne pas être
CMA-ES 5 emplacements, invoqué nulle part table de benchmark Rustuna (App-18c), stub d'exercice # TODO etudiant (App-18c cellule 25), exercice MGS-07d (quantifier l'orientation « que CMA-ES exploite pour apprendre la géométrie locale »), commentaire de primitive différée (Compound/DifferentialEvolution.cs:39), Search-05
Wierstra 2, RL/rl_3_experience_replay_her.ipynb co-auteur de DDPG (ICLR 2016), pas de NES

Verdict : VOISIN, au sens strict. La série mesure la grandeur qu'un gradient naturel exploite (l'orientation du paysage en MGS-07d, le delta de rotation par famille d'opérateurs en MGS-12), nomme la famille qui l'apporte (MGS-17 §4), diffère la primitive qui la servirait (DifferentialEvolution.cs:39) — et n'en implémente aucune. Le nom de l'auteur est même déjà dans le dépôt, sous un autre chapeau. C'est la configuration que la règle de fibre (#16759) désigne comme la vraie dette : l'invention est là en creux, le nom n'y est pas.

L'accroche la plus nette, verbatim de MGS-12 — la conclusion pose que « on juge un optimiseur sur la structure de ses opérateurs (vectoriels vs composante par composante, centrés vs non), pas sur le nom de sa métaphore », et l'exercice 1 demande d'opposer un croisement arithmétique (« une opération géométrique indépendante du repère, donc a priori équivariante par rotation ») au croisement uniforme. L'invariance par rotation est déjà l'axe de lecture du notebook. NES est la famille dont c'est la propriété constitutive, et elle est absente du banc.

Objection honnête, et elle est forte. #12373 conclut que le noyau n'est pas la cause de l'écart de qualité. Ajouter un noyau — ce qu'est un NaturalEvolutionStrategy : ICompoundMetaheuristic — n'est donc pas ce que ce diagnostic appelle. Il faut le dire nettement : A.1 ne prétend pas corriger l'écart MGS↔mealpy. Elle vise l'autre axe, celui de MGS-12 — la robustesse à la rotation, mesurée et non traitée. Deux mesures distinctes, deux dettes distinctes ; les confondre serait vendre la veine.

Critère de sortie falsifiable, emprunté à #13778 plutôt qu'inventé : opérateur implémenté dans le sous-module, passé au banc existant (RotatedFitness ∘ ShiftedFitness) contre un opérateur diagonal en place, sur {0,1,7,42} à budget d'évaluation égalisé, médiane + min-max, verdict dans le vocabulaire de l'Epic — NO IMPROVEMENT et INCONCLUSIVE compris, et publiés tels quels. La v1 proposait un critère de ma main ; celui-ci est celui que la lane applique déjà.

A.2 — Le régime : Meta Guard, et l'échelle déjà gravie à mi-hauteur

Publication — Continually Adapting Optimizers Improve Meta-Generalization, Wang, Kirsch, Faccio, Zhuge, Schmidhuber, OPT2023.

Le problème qu'elle pose, verbatim de l'abstract : un optimiseur méta-appris bat SGD/Adam mais échoue à généraliser sur certaines tâches ; on retombe alors sur l'analytique par un garde — sauf qu'« à un certain point du processus itératif, un tel garde peut rendre l'optimiseur appris incompatible avec la suite de l'optimisation, et donc inutile pour progresser ». Meta Guard continue d'adapter l'optimiseur appris à la tâche cible pendant le run, au lieu de le geler.

Ce n'est pas une idée neuve ici — elle a déjà été atteinte par une autre porte. #16415 (Dream-RSI), fermée COMPLETED, formule le même manque sans citer ce papier : « pas seulement « quel moteur » mais « quelle politique d'exploration au-dessus du moteur » ». Deux publications d'un même entourage convergent sur le même trou du dépôt ; la veine A.2 confirme un besoin déjà inscrit, elle ne l'ouvre pas.

L'échelle est construite à mi-hauteur, et le dépôt dit lui-même où il s'arrête. MGS-16 répond au No-Free-Lunch en sélectionnant le moteur ; MGS-17 en contrôlant ses paramètres pendant la course, sur la taxonomie d'Eiben. Quatre barreaux, dont le dépôt tient le premier :

Barreau État mesuré
0 — taux par individu, assigné par indice (ctx.OriginalIndex) construit, MGS-17 §4 — et le notebook le qualifie lui-même de démonstration du mécanisme
1 — σ encodé dans le chromosome, muté et sélectionné avec la solution exercice non fait, MGS-17 exercice 3. Verbatim : « le vrai self-adaptatif (Evolution Stratégies, Schwefel) encode le taux dans le chromosome »
2 — gradient naturel sur les paramètres de la distribution absent — c'est A.1
3 — un garde qui arbitre appris ↔ analytique et laisse l'appris continuer de s'adapter absent — c'est Meta Guard

Et la conclusion de MGS-17 pose précisément le problème que le barreau 3 adresse : « No-Free-Lunch du paramètre : aucune stratégie ne domine Rastrigin ET Sphere ». Quand aucune stratégie de contrôle ne domine, la question cesse d'être « laquelle » et devient « qui arbitre, et l'arbitrage gèle-t-il ce qu'il écarte » — l'énoncé même du papier.

La prise dans le code, vérifiée firsthand (et c'est le mécanisme que MGS-17 pilote déjà, pas une abstraction que j'invente) :

Pièce Preuve
Le point d'injection du contrôle Metaheuristics/Probability/ProbabilityConfig.cs:22 — public Func<IEvolutionContext, float, float> DynamicProbability, consommé sous ProbabilityStrategy.OverwriteProbability (ProbabilityStrategy.cs:25, ProbabilityConfig.cs:26-28)
La portée par individu EvolutionContext/EvolutionContext.cs:23 — public int OriginalIndex
Le séquenceur par génération Primitives/GenerationMetaHeuristic.cs — « applique des métaheuristiques distinctes selon le numéro de génération : cycle à travers les phases, chacune durant sa taille de phase en générations »
Le dispatch par étape Primitives/StageSwitchMetaHeuristic.cs + EvolutionStage.cs (Selection | Crossover | Mutation | Reinsertion)
Le treillis de portées Parameters/ParamScope.cs — Constant | Evolution | Generation | Stage | MetaHeuristic | Individual : une valeur est calculée une fois par combinaison de portée et réutilisée à l'intérieur
La dimension île Primitives/IslandMetaHeuristic.cs · Populations/IslandPopulation.cs

Un garde au sens du papier est un DynamicProbability — ou un MetaHeuristicParameter<T>.Generator — de portée Generation qui arbitre entre opérateur appris et opérateur analytique ; l'apport de Meta Guard est que l'appris continue de s'adapter sous l'arbitrage. Le code est assez mûr pour porter la subtilité : le commentaire de StageSwitchMetaHeuristic documente qu'un cache en portée Generation figerait le switch en masquant l'étape hors de la clé du cache — c'est, dans le vocabulaire du treillis, exactement le gel que le papier reproche au garde naïf.

Deux liens non triviaux : Zhuge et Faccio co-signent GPTSwarm (veine B) — les deux veines ont des auteurs communs. Et l'introduction du papier cite explicitement les Fast Weight Programmers / Transformers linéaires et le méta-méta-apprentissage : la thèse Meta/hiérarchie y est posée par l'auteur lui-même.

Bémol de livraison : sous-module ⇒ commiter dedans d'abord, pousser, puis bumper le pointeur parent ; pas de gate CI sur ces dépôts (deux vérifications firsthand indépendantes, sur deux lanes distinctes, exigées dans le body de la PR de bump).

Note de correction (source). La v1 déclarait la référence openreview.net/pdf?id=562Bx0qZT5 non identifiée (page, PDF et API bloqués par Cloudflare depuis cette lane), en ajoutant que sa localisation dans la veine A était une inférence de voisinage. Le user a fourni l'accès direct : c'est bien la veine A, et l'inférence était juste — mais elle restait une inférence, et c'est la fourniture de la source, pas ma déduction, qui l'a établie.

Veine B — orchestration agentique : élargir le tracker #16457

Publications — MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework (ICLR 2024) et Language Agents as Optimizable Graphs / GPTSwarm (arXiv 2402.16823, ICML 2024).

Les deux disent la thèse : MetaGPT encode des procédures dans des rôles (hiérarchie) ; GPTSwarm fait du graphe d'agents lui-même l'objet optimisé — nœuds et arêtes (Meta).

Ce que « le harnais » désigne — correction

Correction. La première version mesurait « le harnais » comme les 23 sous-agents et 17 skills Claude Code de ce dépôt. Ce n'est pas l'objet : le user précise que ces sous-agents sont d'ailleurs peu utilisés. Le harnais visé est la flotte de 7 machines — outils dédiés par machine, protocoles de communication RooSync, coordination sur Git. C'est un système distribué réel avec des agents hétérogènes, pas un roster de prompts. La mesure de la v1 n'était donc pas fausse, elle portait sur le mauvais objet, ce qui est pire.

La surface, mesurée firsthand sur main (c818f6abc)

Surface Mesure Pourquoi elle accroche
La flotte 7 machines, outils dédiés, RooSync + Git comme protocoles c'est le graphe d'agents réel : des nœuds hétérogènes, des arêtes de communication explicites, et une production observable
Semantic Kernel 186 fichiers (31 série dédiée, 18 dans Argument_Analysis/) 10-SemanticKernel-NotebookMaker.ipynb : 3 agents Admin / Coder / Reviewer — des rôles porteurs de procédure, le cœur de MetaGPT
Google ADK 19 fichiers, ML/DataScienceWithAgents/Track2-GoogleADK/ utils/adk_orchestrator.py — « orchestration multi-agents au-dessus de Google ADK » (contrat C4, #14058) : un plan déclaratif enchaînant N spécialistes = un graphe d'arêtes
semantic-fleet sous-module, dépôt dont CoursIA est steward une flotte d'agents sous notre responsabilité
Diffus AgentGroupChat : 44 fichiers ; multi.?agent : 769 occurrences / 242 fichiers la matière est là, non consolidée — la raison d'être du tracker

Deux absences qui cadrent l'axe : swarm = 0 hit d'orchestration (tout est ParticleSwarm) ; society of mind = 0 hit.

Un graphe d'agents réel et déjà écrit, trouvé en mesurant la veine E : le harnais spectacular du projet Epita assemble 39 phases-capacités en un DAG déclaratif (build_spectacular_workflow()), avec un registre à résolution par capacité (find_for_capability). C'est, de tout ce qui est mesuré ici, l'objet le plus proche de ce que GPTSwarm optimise : des nœuds typés, des arêtes déclarées, et un résolveur qui choisit qui remplit quoi. La veine B et la veine E ne sont donc pas voisines par hasard — elles regardent le même artefact par deux bouts.

L'utilité mesurable — correction, elle n'est pas absente

Correction. La v1 concluait qu'« optimiser des arêtes suppose une utilité mesurable, et ni adk_orchestrator ni le harnais n'en exposent ». Faux pour le harnais de flotte. Le user nomme la fonction objectif que le cluster s'est déjà posée : le taux de merge par dollar dépensé. Et elle n'est pas théorique — la lane Epita instrumente déjà les deux moitiés du ratio : un compte de PRs livrées par round au numérateur, une dépense LLM mesurée par run et par campagne au dénominateur. (Les valeurs vivent sur le dashboard de coordination, pas ici.)

Trois régimes d'utilité, honnêtement distincts, et mesurés.

1. Flotte / production — les ingrédients existent, le ratio n'est calculé nulle part. Mesure firsthand : le dépôt compte déjà de la comptabilité de jetons réelle — SymbolicAI/Lean/lean_runner.py tient un tokens_used par tentative de preuve, alimenté des usage des deux fournisseurs (lean_runner.py:905, 1024-1026, 1057-1059) ; semantic-fleet/model_tester/api_utils.py rend (texte, temps, jetons) par appel ; scripts/genai-stack/probe_minicpm5_duel.py mesure un débit en jetons/s. Mais la sonde décisive rend zéro : merge rate|merges_per|per_merge|cost_per|usd_per sur scripts/**.py → aucune métrique de taux de merge ni de coût par run n'existe dans le dépôt. Et scripts/coordination/debt_ledger.py, lu en entier, ne calcule que des stocks — eat_hours est une charge due, jamais normalisée par un temps ni par un coût ; rate|velocity|burn|ratio|throughput sur le fichier ne rend que des faux positifs.

Donc la correction se corrige elle-même à mi-chemin : l'utilité est mesurable et la lane Epita en instrumente les deux moitiés sur son dashboard — mais aucun organe du dépôt ne calcule le ratio. Ce n'est pas « pas d'utilité », c'est « utilité mesurée, jamais dérivée ».

Organe candidat, et il est bon marché : le numérateur vit dans Git (PRs mergées par lane, par fenêtre) ; le dénominateur demande une comptabilité de coût par lane. debt_ledger.py est architecturé pour ça — un kind supplémentaire y coûte une constante, cinq entrées de dict et ses FieldSpec. Le ledger porte déjà un stock ; lui ajouter un flux est le geste minimal qui rend le merge-par-dollar calculable plutôt que rapporté.

2. Epita et ICT — les embryons sont réels et chiffrés. Le user les situe ; la mesure les confirme, toutes cellules exécutées :

Surface Objectif numérique déjà évalué
GameTheory-16-MechanismDesign.ipynb (16/16) équivalence des revenus en Monte-Carlo (10 000 enchères : 1er prix 49,92 / 2nd prix 50,01 / théorique 50,00), paiements VCG, table de compatibilité aux incitations, et la non-monotonicité de Conitzer-Sandholm — bien-être 10 → 16 (hausse) pendant que le revenu 8 → 4 (baisse)
GameTheory-16b-Automated-Mechanism-Design.ipynb (4/4) recherche exhaustive sur 4096 mécanismes candidats avec verify_DSIC / verify_IR / verify_social_welfare, et un témoin d'impossibilité committé : sous DSIC ∧ IR ∧ (∀i,∀r : paiement ≥ 1), « l'ensemble des mécanismes admissibles est VIDE »
ICT-13-AxelrodStrategicMorphodynamics.ipynb (21/21) taux de coopération — min 0,261 / max 0,938 / moyenne 0,714
ICT-26-SignalingConvention.ipynb (8/8) émergence de convention de Lewis — learned_success 1,000 vs contrôle 0,241, information mutuelle 1,993 vs 0,00
ICT-28-CollectiveAdoption.ipynb (8/8) fraction d'adoption vs conformité ρ — courbe de masse critique, 0,000 à ρ=0,05 → 1,000 à ρ=0,95
ICT-25-InoculationRL.ipynb (20/20) écart de reward-hacking — vérificateur propre 0,0 vs faille 1,0

Nuance à ne pas sauter : ce sont des objectifs sur des populations ou des mécanismes, pas sur un graphe d'agents LLM. Ils fournissent le type de signal manquant, pas le signal lui-même.

3. ADK en data science — qualitatif assumé. « J'imagine que c'est plus dur de ne pas rester sur du qualitatif » — et c'est le bon verdict : ne pas fabriquer une métrique pour avoir une métrique.

Ce qui reste ouvert, et c'est un vrai sujet de conception : un ratio global (merge/dollar) est une utilité scalaire sur tout le système ; optimiser des arêtes demande d'attribuer du crédit à des arcs individuels. C'est le problème d'attribution classique, et le nommer est la première étape honnête.

Veine C — la pépite bilevel : Stackelberg × PPO

Publication — Efficient Morphology-Control Co-Design via Stackelberg Proximal Policy Optimization, Dai, Wang, Ashley, Schmidhuber, ICLR 2026. Le leader choisit la morphologie, le suiveur l'optimise par PPO : la hiérarchie est le mécanisme, pas la métaphore.

La cible, mesurée — le résultat le plus net des quatre mesures.

  • PPO : 100 fichiers (RL 24, QuantConnect 22, GenAI 14…), avec du lourd : rl_6c_ppo_from_scratch.ipynb (surrogate clippé + GAE, from scratch), QC-Py-33-RL-PPO-Trading.ipynb, rlpt_1_ppo_lm_rlhf.ipynb, rlpt_4_dpo_vs_ppo.ipynb, artefacts entraînés committés.
  • Stackelberg : 34 fichiers (GameTheory 18) : GameTheory-14-DifferentialGames.ipynb (+ jumeau C#), 09b-Commitment-Stackelberg, 09c-Stackelberg-SecurityGame, examples/stackelberg_leader_follower.py, et des tests d'invariants en forme close (tests/test_stackelberg.py : Cournot (30,30), Stackelberg (45,22.5)).
  • Co-occurrence : exactement 4 fichiers — et les quatre sont des surfaces de navigation (README.md, les deux COURSE_CATALOG.generated.*, docs/curriculum/recherche.md). Zéro fichier de contenu ne les combine. Aucun notebook, aucun script, aucun lake.

« Du PPO ET du Stackelberg en pagaille » est vérifié, et les deux ne se sont jamais rencontrés ailleurs que dans le catalogue. Le plat est de choix précisément parce que les deux ingrédients sont dans la cuisine depuis toujours et n'ont jamais été dans la même casserole.

Second gisement, séparé : sur 33 racines de lake Lean, Stackelberg = 0 hit — et même la sonde synonyme leader|follower dans les .lean de GameTheory = 0. Aucune formalisation, sous aucun nom.

Organes candidats (deux, indépendants) : (1) un notebook de co-design bilevel réutilisant le PPO from-scratch existant en suiveur ; (2) le premier lake portant l'équilibre leader/suiveur, adossé aux invariants en forme close déjà testés en Python.

Veine D — Infer.NET sur les chaînes, et le drafter

Publications (une paire, même équipe) — Accelerating the inference of string generation-based chemical reaction models (J. Cheminformatics 17, 2025) et Fast and scalable retrosynthetic planning with a transformer neural network (Digital Discovery 5(4), 2026, 1783-1793).

Le brief ne se plante pas sur le terrain : la première porte littéralement sur l'accélération de l'inférence d'un modèle de génération de chaînes (SMILES→SMILES), où la largeur de faisceau est le « nombre d'hypothèses maintenues ». Pas une analogie avec le beam search : le même objet technique.

Ce que j'avais mesuré, et pourquoi c'était le mauvais objet

Correction. La v1 écrivait que « StringDistribution n'apparaît que 4 fois dans tout le dépôt et jamais dans le notebook Infer ; StringAutomaton et WeightFunction = 0 hit », et en tirait que l'objet pointu était hors de portée. Ces chiffres mesurent l'usage de la bibliothèque DANS CoursIA — pas la bibliothèque. Présentés dans une section qui jugeait la faisabilité, ils donnaient à lire « la machinerie est maigre » alors qu'ils disaient « nous ne nous en servons pas ». C'est une confusion instrument/objet, et elle sous-estimait la veine.

Ce que la bibliothèque porte réellement (dotnet/infer, src/Runtime/Distributions/Automata, 49 fichiers) : un automate pondéré complet — Automaton éclaté en partiels Determinization, EpsilonClosure, Condensation, StronglyConnectedComponent, Simplification, EnumerateSupport, GroupExtractor ; StringAutomaton et ListAutomaton ; Transducer / StringTransducer / ListTransducer ; la famille WeightFunctions (IWeightFunction, DictionaryWeightFunction, PointMassWeightFunction, MultiRepresentationWeightFunction) ; et la conversion vers/depuis les expressions régulières (RegexpTreeBuilder, RegexpAutomatonFormat).

C'est StringTransducer qui change le verdict. Un transducteur pondéré composé avec une distribution de proposition est exactement l'objet formel derrière le décodage guidé et derrière le reranking de faisceau. La bibliothèque a donc la pièce ; c'est notre usage qui s'arrête à la façade de modélisation.

Ce qui existe côté CoursIA, mesuré.

  • Le composant tourne : Probas/Infer/Infer-14-Sequences.ipynb §5 « Motif Finding (Bioinformatique) » — PWM tirée en Dirichlet sur DiscreteChar, séquence assemblée par Variable.StringOfLength + Variable.StringFromArray, présence Bernoulli, position DiscreteUniform, inférence en QualityBand.Experimental. 21/21 cellules exécutées, port fidèle du MotifFinder de dotnet/infer. La génétique du brief est bien là.
  • Beam search réel : Sudoku-16-NeuralNetwork-Python.ipynb (beam_width=3), RAG-et-Memoire-Semantique/05-Stockage-Vectoriel.ipynb (beam_hnsw), GenAI/Texte/12_Test_Time_Scaling.ipynb (faisceau sur états arithmétiques).
  • Drafter : aucune implémentation. Seule surface : 11_Quantization.ipynb, qui discute le décodage spéculatif et rapporte une acceptation MTP mesurée à 0 % sous AWQ-Int4.
  • Décodage contraint : 0 hit. Pas de logits_processor, pas d'Outlines, pas de grammaire-contrainte. La seule contrainte est côté fournisseur (03_Structured_Outputs.ipynb, response_format: json_schema).

Le cadrage qui tient après correction. L'automate ne modélise pas la distribution du prochain token : mal placé pour tirer un brouillon, bien placé pour dire quelles continuations sont admissibles et repondérer un faisceau — c'est-à-dire la surface à 0 hit du dépôt. Le rôle passe de drafter à contraignant / repondérateur, et avec StringTransducer ce n'est plus une spéculation de principe mais une pièce existante.

Bémol restant : Infer.NET est .NET, les surfaces de décodage sont Python/vLLM — le pont est cross-runtime, décision d'architecture, pas détail.

Veine E — narration, en face de l'analyse des sophismes

Publication — On the Distillation of Stories for Transferring Narrative Arcs in Collections of Independent Media, Ashley, Herrmann, Friggstad, Schmidhuber, IEEE TPAMI 2024, qui introduit une quantité d'« information narrative ». (Ashley co-signe aussi la publication de la veine C.)

Trois corrections, qui déplacent la veine plutôt qu'elles ne la réduisent

Correction 1 — mon chiffre de liens croisés mesure une distillation en retard, pas l'ontologie. La v1 annonçait « 1408 sophismes × 102 colonnes, seulement 22 relations au total, la matrice de liens croisés est quasi vide », et en faisait le gisement de la veine. Le user corrige : la distillation côté CoursIA est en retard, et il y a beaucoup plus de liens croisés aujourd'hui en amont. Mon chiffre est donc une mesure du décalage de distillation, pas de l'état de l'art. Il reste utile — à ce titre exactement, et pas comme « la matrice est vide ».

Correction 2 — « l'analyse spectrale » est un projet nommé, et sa définition est précise. spectral = 0 hit en contexte argumentation dans CoursIA reste vrai. Le user précise ce que le mot désigne : dans le cadre Epita, il a été question de porter le geste de détection de sophismes vers une analyse « spectrale » de corpus donnés — c'est-à-dire leur co-occurrence, orthogonalement à leur séquencement. La paire est nette : spectre = co-occurrence (quels sophismes vont ensemble dans un corpus), narration = séquence (dans quel ordre ils se déploient).

Et la mesure ajoute une demi-surprise. En allant compter les experts du harnais Epita, le mot se trouve — pas dans CoursIA, dans le harnais vivant : l'expert act1_framing produit « genre, enjeux, spectre de sophismes attendu dérivé, lecture en théorie des jeux », et act2_narrative découpe le récit en temps de mouvement groupés par famille de sophisme. Donc la moitié prédictive du spectre existe déjà (du genre on dérive le spectre attendu), et c'est la moitié mesurée qui manque (d'un corpus on remonte les co-occurrences observées). L'axe n'est donc pas à ouvrir : il est à fermer par le bas, et sa moitié haute sert de témoin de validation — un spectre prédit et un spectre mesuré qui se confrontent valent mieux que l'un des deux seul.

Correction 3 — SwitchAngel n'est pas « un Epic à venir » vaguement situé : c'est #15604, ouverte et entièrement spécifiée. La v1 concluait de SwitchAngel = 0 hit repo-wide que « le troisième exemple cité est le seul qui ne porte pas encore l'axe », puis, corrigée une première fois, qu'il s'agissait d'« un Epic pas encore réalisé ». Les deux cadrages ratent l'essentiel, et le user a dû me pointer l'issue : #15604 — pipeline livecoding-video : narration slammée + capture Strudel + TTS expressif, OPEN depuis le 2026-09-11, 6 étapes spécifiées, qui prolonge bien 04-5-LiveCoding-LLM-Music.ipynb et se raccorde nommément au workflow audiobook (#1028, 04-6→04-13, FishAudio S2-Pro et ses 29 tags prosodiques).

Et le zéro hit n'était pas un résultat — c'était la règle en train de fonctionner. L'Epic écrit, mot pour mot : « Aucune archive SwitchAngel ne sera committée dans le dépôt. », tout le banc d'analyse restant sur le gisement bibliographique privé, « périmètre bibliography-hygiene.md §2 ». Un grep sur l'arbre ne pouvait structurellement rien trouver : il mesurait la conformité à une règle, jamais une absence de travail. J'ai interrogé l'arbre là où l'état vivait dans le pool d'issues — c'est un défaut d'instrument, pas une donnée.

Ce que ça change pour la veine E : l'axe narration n'est pas « à ouvrir », il a déjà son Epic de production ; ce qui reste à la curation, c'est le versant spectral (co-occurrence), qui lui n'a pas d'organe.

Ce qui est là, mesuré

  • Le pont argumentation ↔ narration est déjà livré côté CoursIA : Argument_Analysis_Restitution_3_Actes.ipynb (52 occurrences narrat) transforme le dump d'analyse — sophismes, qualité, extensions de Dung — en récit en trois actes (Acte I mise en situation / Acte II récit dialectique / Acte III conclusion actionnable), échafaudage déterministe portant le contrat d'honnêteté, narration LLM gatée. Il se décrit comme la distillation de l'arc anti-théâtre / fail-loud du projet Epita (Epic CoursIA Epic: Intégrer Argumentum (sous-module) + refonte Argument_Analysis + complétion Tweety (source 2025-Epita-Intelligence-Symbolique) #2137).
  • L'arc narratif de l'audiobook est du code de première classe : GenAI/Audio/04-Applications/v4/p0_narrative_research.py construit un NarrativeContext{acts, characters, themes, narrative_technique} ; schemas.py:58-71 porte ActDefinition{default_tension} et CharacterProfile{emotional_arc} ; p3_dramatic_context.py:47-52 pose une courbe de tension en 4 actes (3→5→8→9) et assigne à chaque segment sa « position narrative dans l'arc ». La prosodie est une couche séparée et en aval (verify_prosody.py) — la distinction supposée par le brief est réelle et structurelle.

Le harnais Epita : où vit la narration, compté

Le brief dit « certains des 40 experts du harnais Epita pas encore distillé s'occupent bien de la narration ». Mesure firsthand sur le dépôt public jsboigeEpita/2025-Epita-Intelligence-Symbolique (branche par défaut) — le compte tombe juste, et il désigne un harnais précis :

Harnais Roster Compte
spectacular (pipeline DAG) build_spectacular_workflow(), argumentation_analysis/orchestration/workflows.py 39 phases-capacités
conversational AGENT_CONFIG, orchestration/conversational_orchestrator.py:199 8 spécialistes

Les « 40 » sont donc les 39 du spectacular (41 en union des deux harnais). Et les projets étudiants figés de la racine — 12 répertoires — ne sont pas le roster : ils ont été digérés dans argumentation_analysis/, avec une trace de provenance écrite pour 9 capacités dans TWEETY_CAPABILITY_MAP.md, colonne « Student Project ».

La narration n'est pas une préoccupation marginale de ce roster : elle en occupe la sortie. Les trois dernières capacités du DAG sont act1_framing, act2_narrative, act3_conclusion — les trois actes sont des experts de plein droit dans le pipeline, pas un post-traitement :

Expert Fichier Ce que la source en dit
act1_framing reporting/restitution/act1_framing.py « genre, enjeux, spectre de sophismes attendu dérivé, lecture en théorie des jeux »
act2_narrative reporting/restitution/act2_narrative_plugin.py (1 558 l., le plus gros fichier de code du groupe narratif) « générateur d'Acte II — récit dialectique par mouvement argumentatif » ; récit découpé en temps groupés par famille de sophisme ; « un échange contradictoire Walton-Krabbe (point vs réfutation) »
act3_conclusion reporting/restitution/act3_conclusion.py verdict gaté (G1-G4), appréciations équilibrées, et le « que faire »
deep_synthesis agents/core/synthesis/deep_synthesis_agent.py agrège l'état du run en rapport structuré — sa section 5 lit l'analysis_trace, l'entrée de la narration
narrative_synthesis plugins/narrative_synthesis_plugin.py prose narrative tissant les sorties de phases — conversational uniquement, sauté en mode pipeline
dialogue_protocols · adversarial_debate · dung_arbitration_service logic/dialogue_handler.py · debate/debate_agent.py · informal/dung_arbitration_stage.py les trois loci Walton-Krabbe : protocoles, débat multi-personnalités, arbitrage de Dung sur les candidats sophismes

Et le geste séquence se livre en ce moment même : #2314 « argumentative sequence for analysis_trace — anchor, move, reacts_to-by-id » et #2315 « anchor the argumentative sequence in the source text », toutes deux ouvertes, ajoutent un vocabulaire fermé TRACE_MOVES = assert/concede/retract/challenge/withdraw et des ancres {offset, length}. Vérifié : text_sequence.py n'est pas encore sur main.

Le résultat le plus parlant pour cette veine vient de là : en ordonnant les arguments par position dans le texte plutôt que par ordre d'extraction, la mesure de run réel montre que les deux ordres diffèrent — le modèle liste d'abord les revendications saillantes, pas les premières. C'est, mesuré en production et presque par accident, la distinction même que la correction 2 nomme : la saillance n'est pas la séquence. Le spectre lit l'une, la narration lit l'autre.

Le retard de distillation, chiffré au passage : docs/architecture/spectacular_capability_matrix.md inventorie 72 composants et date du 2026-05-14 — il est antérieur de quatre mois au travail sur les actes et la séquence, et ne porte donc pas les trois actes. Le « pas encore complètement distillé » du brief a cette mesure-là : ce n'est pas seulement CoursIA qui est en retard sur Epita, c'est la doc d'architecture d'Epita qui est en retard sur son propre code.

Organe candidat : mesurer l'« information narrative » entre la trace analytique et sa restitution en trois actes — un chiffre qui dit ce que l'arc préserve et ce qu'il jette. Producteur et consommateur existent tous les deux ; il manque la quantité.

Ce que cette curation ne fait pas

  • Elle ne préempte pas « la curation classique », que le brief laisse explicitement aux lanes : les entrées connues de la homepage et les grandes publications séminales restent à instruire par le grain 2 ci-dessus, avec le même critère.
  • Elle ne crée aucune issue fille. Cinq veines qualifiées ≠ cinq issues. Une veine devient une issue quand sa source est lue et sa cible re-vérifiée contre l'arbre du jour.
  • Elle ne juge personne. On cite des travaux et on gradue des résonances ; aucune caractérisation de personne vivante n'entre sur cette surface publique.
  • Elle n'exempte pas du critère d'entrée (MUH : le texte ou Tegmark cite Schmidhuber — cadrage ICT (fibre a gagner, pas acquise) #16759) : une fibre s'acquiert par un organe, pas par une citation. Chaque veine dit donc ce qui s'exécute ou se prouve.

Rattachements

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions