From e0f294c0e3a2f62b3608497aaedd01a563f1068b Mon Sep 17 00:00:00 2001 From: jsboige Date: Tue, 13 Oct 2026 16:15:21 +0200 Subject: [PATCH 1/3] Fix(readme,#20549): Search + SymbolicAI -- 189 liens .html morts remplaces en .ipynb Signale en cours a l'EPF (13/10) : les READMEs lient des carnets en .html -- sur github.com ces cibles 404 (les rendus Quarto vivent sur Pages, jamais commis). Forme de reference : .ipynb (arbitrage #18911). Perimetre : Search (6 READMEs, 139 occurrences), SymbolicAI/Tweety (3 READMEs, 43), + 7 liens croises IIT/Probas -> Tweety-11 (memes cibles mortes). 14 fichiers, 178 lignes reecrites (remplacement pur href, symetrique +/-). Verifications : - regen_quarto_render.py --check-readme-links : 0 HTML_404 restant depuis/vers Search+SymbolicAI - check_docs_links.py --check --base origin/main : OK, no new broken links (8645 total) - pre-controle : les 459 cibles du depot ont toutes leur .ipynb present (0 cas piege, mesure issue #20549) Voir #20549 (partiel : 189/459 ; ML/RL/GenAI/Probas au sweep). Grain: LIGHT/readme -- lane myia-po-2025:CoursIA -- prev: MED/genai #20543 Co-Authored-By: Claude Sonnet 5.5 --- MyIA.AI.Notebooks/IIT/README.md | 4 +- .../DecisionTheory/Causal-Bridges/README.md | 2 +- MyIA.AI.Notebooks/Probas/Infer/README.md | 4 +- MyIA.AI.Notebooks/Probas/PyMC/README.md | 2 +- MyIA.AI.Notebooks/Probas/README.md | 2 +- .../Search/Applications/README.md | 64 +++++++-------- .../Search/Part1-Foundations/README.md | 38 ++++----- MyIA.AI.Notebooks/Search/Part2-CSP/README.md | 56 ++++++------- .../Search/Part5-Frontieres/README.md | 36 ++++---- MyIA.AI.Notebooks/Search/README.md | 54 ++++++------ .../Search/search_lean/README.md | 8 +- MyIA.AI.Notebooks/SymbolicAI/Tweety/README.md | 82 +++++++++---------- .../Tweety/argumentation_lean/README.md | 2 +- .../SymbolicAI/Tweety/dotnet-build/README.md | 2 +- 14 files changed, 178 insertions(+), 178 deletions(-) diff --git a/MyIA.AI.Notebooks/IIT/README.md b/MyIA.AI.Notebooks/IIT/README.md index 7cff6934d2..f04dee7ae1 100644 --- a/MyIA.AI.Notebooks/IIT/README.md +++ b/MyIA.AI.Notebooks/IIT/README.md @@ -458,7 +458,7 @@ les arcs entrants de `X`, brisant les chemins de confusion — de sorte que | Paradigme | Notebook | Instanciation de `do(·)` | Résultat-signature | |-----------|----------|---------------------------|--------------------| -| **Symbolique** (logique propositionnelle, Java/Tweety) | [Tweety-11-Causal-Python](../SymbolicAI/Tweety/Tweety-11-Causal-Python.html) | `scm.intervene(p, b)` → nouveau SCM dont l'équation de `p` devient une constante | `P(rain\|drops)=True ≠ P(rain\|do(drops))=False` (baromètre) | +| **Symbolique** (logique propositionnelle, Java/Tweety) | [Tweety-11-Causal-Python](../SymbolicAI/Tweety/Tweety-11-Causal-Python.ipynb) | `scm.intervene(p, b)` → nouveau SCM dont l'équation de `p` devient une constante | `P(rain\|drops)=True ≠ P(rain\|do(drops))=False` (baromètre) | | **Bayésien par message passing** (Infer.NET, EP/VMP — Gibbs disponible) | [Infer-5](../Probas/Infer/Infer-5-Causal-Inference.ipynb) | mutilation de graphe `Variable.Bernoulli(1.0)` ; backdoor / front-door | paradoxe de Simpson résolu, identifiabilité par ajustement | | **Bayésien MCMC** (PyMC) | [PyMC-5](../Probas/PyMC/PyMC-05-Causal-Inference.ipynb) | opérateur natif `pm.do(model, {X:x})` ; backdoor / front-door | contrefactuel par abduction (postérieur sur les exogènes) | | **Théorie de l'information / émergence** (ICT) | [ICT-05-CausalEmergence-Python](ICT-Series/ICT-05-CausalEmergence-Python.ipynb) | distribution d'intervention `p(C)` **uniforme** sur les états = `do(X_t = x)` appliqué à tout le micro-état | quelle **échelle** « fait » le plus de travail causal (EI / CP) | @@ -475,7 +475,7 @@ L'**émergence** apparaît quand une description **macro** (gros-grain) réalise causal que le micro — l'`effectiveness` monte sous coarse-graining. **Parcours de lecture conseillé** : commencer par le **symbolique qualitatif** -([Tweety-11](../SymbolicAI/Tweety/Tweety-11-Causal-Python.html)) pour *voir* `observe` vs `do` sans +([Tweety-11](../SymbolicAI/Tweety/Tweety-11-Causal-Python.ipynb)) pour *voir* `observe` vs `do` sans nombres ; passer au **quantitatif distributionnel** ([Infer-5](../Probas/Infer/Infer-5-Causal-Inference.ipynb) message passing, [PyMC-5](../Probas/PyMC/PyMC-05-Causal-Inference.ipynb) MCMC) pour *calculer* les effets et lever le paradoxe de Simpson ; finir par l'**information-théorique** diff --git a/MyIA.AI.Notebooks/Probas/DecisionTheory/Causal-Bridges/README.md b/MyIA.AI.Notebooks/Probas/DecisionTheory/Causal-Bridges/README.md index 09573fab33..f561b89430 100644 --- a/MyIA.AI.Notebooks/Probas/DecisionTheory/Causal-Bridges/README.md +++ b/MyIA.AI.Notebooks/Probas/DecisionTheory/Causal-Bridges/README.md @@ -36,7 +36,7 @@ Les quatre séries **implantent le même formalisme** avec des outils différent | Direction | Notebook | Moteur | Ce qu'il apporte de plus | |-----------|----------|--------|--------------------------| -| Logique + SCM + contrefactuels | [Tweety-11](../../../SymbolicAI/Tweety/Tweety-11-Causal-Python.html) | Tweety (.NET) | backend causal logique, opérateur `do` natif | +| Logique + SCM + contrefactuels | [Tweety-11](../../../SymbolicAI/Tweety/Tweety-11-Causal-Python.ipynb) | Tweety (.NET) | backend causal logique, opérateur `do` natif | | Message passing exact | [Infer-5](../../Infer/Infer-5-Causal-Inference.ipynb) | Infer.NET | backdoor, front-door, Simpson, médiation, capstone contrefactuel | | MCMC bayésien | [PyMC-5](../../PyMC/PyMC-05-Causal-Inference.ipynb) | PyMC | incertitude postérieure sur l'effet, contrefactuel bayésien | | Émergence causale (Hoel) | [ICT-5](../../../IIT/ICT-Series/ICT-05-CausalEmergence-Python.ipynb), [ICT-6](../../../IIT/ICT-Series/ICT-06-SortingToTPM-CausalEmergence-Python.ipynb) | PyPhi (CE 2.0) | information effective, coarse-graining, multiscale | diff --git a/MyIA.AI.Notebooks/Probas/Infer/README.md b/MyIA.AI.Notebooks/Probas/Infer/README.md index bf625f25e1..4657d7c8ea 100644 --- a/MyIA.AI.Notebooks/Probas/Infer/README.md +++ b/MyIA.AI.Notebooks/Probas/Infer/README.md @@ -694,9 +694,9 @@ Cette extraction clarifie les deux fils du corpus Probas : la **modélisation ba | Front-door | `Σ_m P(M\|X)Σ_{x'} P(Y\|M,x')P(x')` | Ajustement par médiateur quand U est inobservable | | Simpson | agrégé ≠ conditionnel | Renversement : la conclusion s'inverse | -**Positionnement** : le notebook [Infer-4](Infer-4-Bayesian-Networks.ipynb) n'abordait la causalité qu'en deux cellules isolées. Infer-5 en fait un traitement dédié et **distributionnel** : les effets causaux sont **calculés** par le moteur d'inférence Infer.NET via mutilation de graphe, là où le jumeau symbolique [Tweety-11-Causal-Python](../../SymbolicAI/Tweety/Tweety-11-Causal-Python.html) raisonne en Java propositionnel, et où [PyMC-4](../PyMC/PyMC-04-Bayesian-Networks.ipynb) démontre `P(Cloudy|do(Rain))` en MCMC. +**Positionnement** : le notebook [Infer-4](Infer-4-Bayesian-Networks.ipynb) n'abordait la causalité qu'en deux cellules isolées. Infer-5 en fait un traitement dédié et **distributionnel** : les effets causaux sont **calculés** par le moteur d'inférence Infer.NET via mutilation de graphe, là où le jumeau symbolique [Tweety-11-Causal-Python](../../SymbolicAI/Tweety/Tweety-11-Causal-Python.ipynb) raisonne en Java propositionnel, et où [PyMC-4](../PyMC/PyMC-04-Bayesian-Networks.ipynb) démontre `P(Cloudy|do(Rain))` en MCMC. -**Ponts causaux** : Infer-5 est le maillon **distributionnel par message passing** (Infer.NET, EP/VMP) d'un pont à quatre paradigmes autour du `do(·)` de Pearl — le jumeau symbolique [Tweety-11-Causal-Python](../../SymbolicAI/Tweety/Tweety-11-Causal-Python.html) (Java propositionnel), le jumeau MCMC [PyMC-5](../PyMC/PyMC-05-Causal-Inference.ipynb), et la lecture par l'émergence causale [ICT-5](../../IIT/ICT-Series/ICT-05-CausalEmergence-Python.ipynb), où la distribution d'intervention `p(C)` uniforme **est** `do(X_t = x)`. Vue d'ensemble : le [README IIT](../../IIT/README.md), section « Ponts causaux : le do-calculus de Pearl à travers les paradigmes ». +**Ponts causaux** : Infer-5 est le maillon **distributionnel par message passing** (Infer.NET, EP/VMP) d'un pont à quatre paradigmes autour du `do(·)` de Pearl — le jumeau symbolique [Tweety-11-Causal-Python](../../SymbolicAI/Tweety/Tweety-11-Causal-Python.ipynb) (Java propositionnel), le jumeau MCMC [PyMC-5](../PyMC/PyMC-05-Causal-Inference.ipynb), et la lecture par l'émergence causale [ICT-5](../../IIT/ICT-Series/ICT-05-CausalEmergence-Python.ipynb), où la distribution d'intervention `p(C)` uniforme **est** `do(X_t = x)`. Vue d'ensemble : le [README IIT](../../IIT/README.md), section « Ponts causaux : le do-calculus de Pearl à travers les paradigmes ». **Applications** : baromètre (confondeur), diagnostic médical (paradoxe de Simpson), tabac-cancer (front-door), requêtes contrefactuelles. diff --git a/MyIA.AI.Notebooks/Probas/PyMC/README.md b/MyIA.AI.Notebooks/Probas/PyMC/README.md index 61631d94d0..3d4f8a812f 100644 --- a/MyIA.AI.Notebooks/Probas/PyMC/README.md +++ b/MyIA.AI.Notebooks/Probas/PyMC/README.md @@ -143,7 +143,7 @@ Ces corrections sont **éditoriales** (prose, pas de modification des figures su > **Numérotation** : la série PyMC est **numérotée 1:1** avec son jumeau C# Infer (PyMC-5 ↔ Infer-5 = inférence causale, PyMC-14 ↔ Infer-14 = séquences, etc.) pour faciliter la comparaison des deux moteurs sur les mêmes modèles. Le sujet de [Infer-10-Thompson-Sampling](../DecisionTheory/DecInfer/DecInfer-10-Thompson-Sampling.ipynb) est, côté Python, **intégré dans** [PyMC-7-Sequential](../DecisionTheory/DecPyMC/DecPyMC-7-Sequential.ipynb) (section bandits bayésiens MCMC) — d'où l'absence d'un PyMC-21 distinct. -> **Ponts causaux** : [PyMC-5](PyMC-05-Causal-Inference.ipynb) est le maillon **MCMC** d'un pont à quatre paradigmes autour du `do(·)` de Pearl — le jumeau **message passing** en C# [Infer-5](../Infer/Infer-5-Causal-Inference.ipynb) (Infer.NET, EP/VMP), le jumeau symbolique [Tweety-11-Causal-Python](../../SymbolicAI/Tweety/Tweety-11-Causal-Python.html), et la lecture par l'émergence causale [ICT-5](../../IIT/ICT-Series/ICT-05-CausalEmergence-Python.ipynb). Vue d'ensemble : le [README IIT](../../IIT/README.md), section « Ponts causaux : le do-calculus de Pearl à travers les paradigmes ». +> **Ponts causaux** : [PyMC-5](PyMC-05-Causal-Inference.ipynb) est le maillon **MCMC** d'un pont à quatre paradigmes autour du `do(·)` de Pearl — le jumeau **message passing** en C# [Infer-5](../Infer/Infer-5-Causal-Inference.ipynb) (Infer.NET, EP/VMP), le jumeau symbolique [Tweety-11-Causal-Python](../../SymbolicAI/Tweety/Tweety-11-Causal-Python.ipynb), et la lecture par l'émergence causale [ICT-5](../../IIT/ICT-Series/ICT-05-CausalEmergence-Python.ipynb). Vue d'ensemble : le [README IIT](../../IIT/README.md), section « Ponts causaux : le do-calculus de Pearl à travers les paradigmes ». ## Progression Pédagogique diff --git a/MyIA.AI.Notebooks/Probas/README.md b/MyIA.AI.Notebooks/Probas/README.md index 4b98b1ab63..7c299e7e27 100644 --- a/MyIA.AI.Notebooks/Probas/README.md +++ b/MyIA.AI.Notebooks/Probas/README.md @@ -404,7 +404,7 @@ La causalité est traitée à **quatre endroits** du dépôt, chacun avec son mo | Série | Moteur | Angle causal | |-------|--------|--------------| -| [Tweety-11-Causal-Python](../SymbolicAI/Tweety/Tweety-11-Causal-Python.html) | Tweety (.NET, logique) | modèle causal structurel, opérateur `do`, contrefactuels | +| [Tweety-11-Causal-Python](../SymbolicAI/Tweety/Tweety-11-Causal-Python.ipynb) | Tweety (.NET, logique) | modèle causal structurel, opérateur `do`, contrefactuels | | [Infer-5-Causal-Inference](Infer/Infer-5-Causal-Inference.ipynb) | Infer.NET (message passing) | backdoor, front-door, paradoxe de Simpson, médiation | | [PyMC-05-Causal-Inference](PyMC/PyMC-05-Causal-Inference.ipynb) | PyMC (MCMC) | backdoor, front-door, contrefactuel bayésien | | [ICT-5](../IIT/ICT-Series/ICT-05-CausalEmergence-Python.ipynb) · [ICT-6](../IIT/ICT-Series/ICT-06-SortingToTPM-CausalEmergence-Python.ipynb) | PyPhi (CE 2.0) | émergence causale, information effective de Hoel | diff --git a/MyIA.AI.Notebooks/Search/Applications/README.md b/MyIA.AI.Notebooks/Search/Applications/README.md index 08e26fc1ba..c531c13fbe 100644 --- a/MyIA.AI.Notebooks/Search/Applications/README.md +++ b/MyIA.AI.Notebooks/Search/Applications/README.md @@ -61,7 +61,7 @@ Quatre notebooks autour du Puissance 4 — deux Python et deux C# — forment un | # | Notebook | Durée | Contenu | Source | |---|----------|-------|---------|--------| -| 1 | [App-14b-ConnectFour](Search/App-14b-ConnectFour.html) | ~50 min | Puissance 4 : aléatoire, Minimax α-β, MCTS, glouton, framework AIMA (Russell & Norvig), tournoi round-robin | Projet étudiant | +| 1 | [App-14b-ConnectFour](Search/App-14b-ConnectFour.ipynb) | ~50 min | Puissance 4 : aléatoire, Minimax α-β, MCTS, glouton, framework AIMA (Russell & Norvig), tournoi round-robin | Projet étudiant | | 1b | [App-14c-ConnectFour-CSharp](Search/App-14c-ConnectFour-CSharp.ipynb) | ~45 min | **Jumeau C#** — Minimax + Alpha-Beta + MCTS (UCB1) + glouton + iterative deepening from-scratch, heuristique de fenêtres + tournoi round-robin, parité #4956 | Jumeau .NET | | 2 | [App-14-ConnectFour-Adversarial](Search/App-14-ConnectFour-Adversarial.ipynb) | ~45 min | Benchmark adversarial : Minimax, Alpha-Beta, MCTS | Projet étudiant | | 2b | [App-14-ConnectFour-CSharp](Search/App-14-ConnectFour-CSharp.ipynb) | ~40 min | **Jumeau C#** — Minimax + Alpha-Beta (élagage) + MCTS (UCB1) from-scratch, benchmark nœuds + tournoi round-robin, parité #4956 | Jumeau .NET | @@ -75,59 +75,59 @@ Le gros de la sous-série, et un panorama de ce que la programmation par contrai Les classiques fondateurs d'abord : les N-Queens (App-1) — le banc d'essai canonique de la recherche avec contraintes, ici résolu sur 8 reines par la solution connue que toute la littérature partage : -[![Échiquier 8×8 avec une solution connue des 8-Reines : aucune paire de reines ne se menace](assets/readme/app1-nqueens-board.png)](CSP/App-1-NQueens.html) +[![Échiquier 8×8 avec une solution connue des 8-Reines : aucune paire de reines ne se menace](assets/readme/app1-nqueens-board.png)](CSP/App-1-NQueens.ipynb) La coloration de graphes (App-2) part, elle, du graphe d'adjacence des départements français métropolitains — encore sans couleur assignée ici, le tracé sert de support à l'illustration de la contrainte de différence par frontière : -[![Graphe d'adjacence des départements français métropolitains — vue non colorée servant de support à l'illustration de la contrainte de différence par frontière](assets/readme/app2-graphcoloring-map.png)](CSP/App-2-GraphColoring.html) +[![Graphe d'adjacence des départements français métropolitains — vue non colorée servant de support à l'illustration de la contrainte de différence par frontière](assets/readme/app2-graphcoloring-map.png)](CSP/App-2-GraphColoring.ipynb) Viennent ensuite les problèmes d'ordonnancement réalistes. Le planning infirmier (App-3) montre 15 infirmières réparties sur 28 jours, avec les créneaux Matin/Après-midi/Nuit, les jours de repos et les week-ends marqués en rouge : -[![Planning de gardes : 15 infirmières sur 28 jours, créneaux M/A/N/Repos, week-ends en rouge, équité des charges](assets/readme/app3-nurseschedule-planning.png)](CSP/App-3-NurseScheduling.html) +[![Planning de gardes : 15 infirmières sur 28 jours, créneaux M/A/N/Repos, week-ends en rouge, équité des charges](assets/readme/app3-nurseschedule-planning.png)](CSP/App-3-NurseScheduling.ipynb) Le calendrier sportif (App-15) commence, lui, par ses données brutes : la matrice des distances entre les six villes de la ligue, à partir de laquelle le solveur équilibre les déplacements : -[![Matrice des distances entre les 6 villes de la ligue (entrée du calendrier sportif App-15)](assets/readme/app15-sports-calendar.png)](CSP/App-15-SportsScheduling.html) +[![Matrice des distances entre les 6 villes de la ligue (entrée du calendrier sportif App-15)](assets/readme/app15-sports-calendar.png)](CSP/App-15-SportsScheduling.ipynb) Enfin, deux terrains où la modélisation est tout le travail. Le Picross (App-11) sert de leçon de vitesse : un puzzle 5×5 présenté avec ses indices de lignes et de colonnes — la grille encore vierge, à laisser au solveur CP-SAT le soin de noircir : -[![Puzzle Picross 5x5 avec indices de lignes/colonnes (énoncé) : grille à résoudre par propagation de contraintes](assets/readme/app11-picross-grid.png)](CSP/App-11-Picross.html) +[![Puzzle Picross 5x5 avec indices de lignes/colonnes (énoncé) : grille à résoudre par propagation de contraintes](assets/readme/app11-picross-grid.png)](CSP/App-11-Picross.ipynb) La génération procédurale de niveaux (App-19) encode le Wave Function Collapse en CP-SAT — un niveau OPTIMAL produit par le solveur, avec un héros, trois ennemis, une clé et un coffre, sur un pavage de tuiles mur / sol / eau / porte / herbe : -[![Niveau WFC généré par CP-SAT : tuiles wall/floor/water/door/grass, héros, 3 ennemis, clé, coffre](assets/readme/app19-wfc-tiles.png)](CSP/App-19-ProceduralGeneration-WFC.html) +[![Niveau WFC généré par CP-SAT : tuiles wall/floor/water/door/grass, héros, 3 ennemis, clé, coffre](assets/readme/app19-wfc-tiles.png)](CSP/App-19-ProceduralGeneration-WFC.ipynb) *Figures : sorties d'exécution réelles extraites des notebooks (non régénérées, règle C.3), downscalées ≤1200 px / ≤200 ko (EPIC #5654) — provenance détaillée dans [`assets/readme/MANIFEST.md`](assets/readme/MANIFEST.md).* | # | Notebook | Durée | Contenu | Source | |---|----------|-------|---------|--------| -| 1 | [App-1-NQueens](CSP/App-1-NQueens.html) | ~30 min | Backtracking, Min-Conflicts, OR-Tools | Classique | +| 1 | [App-1-NQueens](CSP/App-1-NQueens.ipynb) | ~30 min | Backtracking, Min-Conflicts, OR-Tools | Classique | | 1b | [App-1b-NQueens-CSharp](CSP/App-1b-NQueens-CSharp.ipynb) | ~35 min | Twin C# : Backtracking (simple/MRV/FC), Min-Conflicts, énumération + symétrie D4 | Classique | -| 2 | [App-2-GraphColoring](CSP/App-2-GraphColoring.html) | ~45 min | Greedy, DSATUR, CP-SAT, départements | Projet étudiant | +| 2 | [App-2-GraphColoring](CSP/App-2-GraphColoring.ipynb) | ~45 min | Greedy, DSATUR, CP-SAT, départements | Projet étudiant | | 2b | [App-2b-GraphColoring-CSharp](CSP/App-2b-GraphColoring-CSharp.ipynb) | ~40 min | Twin C# : Greedy (3 ordres), DSATUR, Welsh-Powell, backtracking χ exact + Mycielski | Classique | | 2c | [App-2-GraphColoring-Statistical-Validity-Python](CSP/App-2-GraphColoring-Statistical-Validity-Python.ipynb) | ~50 min | Validité statistique cross-instance : bootstrap, Mann-Whitney, taille d'effet et densité | Nouveau | -| 3 | [App-3-NurseScheduling](CSP/App-3-NurseScheduling.html) | ~60 min | Hard/soft constraints, CP-SAT | Projet étudiant | -| 3b | [App-3b-NurseScheduling-CSharp](CSP/App-3b-NurseScheduling-CSharp.html) | ~45 min | **Jumeau C#** — glouton, backtracking, min-conflicts from-scratch (modélisation 1 var/slot, optimisation préférences), parité #4956 | Jumeau .NET | -| 4 | [App-4-JobShopScheduling](CSP/App-4-JobShopScheduling.html) | ~60 min | Intervalles, précédences, makespan | Projet étudiant | -| 4b | [App-4b-JobShopScheduling-CSharp](CSP/App-4b-JobShopScheduling-CSharp.html) | ~45 min | **Jumeau C#** — dispatching heuristics (SPT/LPT/MOR/MWKR/FIFO) + branch-and-bound optimal from-scratch (énumération active + élagage), Gantt ASCII, parité #4956 | Jumeau .NET | -| 5 | [App-5-Timetabling](CSP/App-5-Timetabling.html) | ~50 min | MiniZinc + OR-Tools | Projet étudiant | +| 3 | [App-3-NurseScheduling](CSP/App-3-NurseScheduling.ipynb) | ~60 min | Hard/soft constraints, CP-SAT | Projet étudiant | +| 3b | [App-3b-NurseScheduling-CSharp](CSP/App-3b-NurseScheduling-CSharp.ipynb) | ~45 min | **Jumeau C#** — glouton, backtracking, min-conflicts from-scratch (modélisation 1 var/slot, optimisation préférences), parité #4956 | Jumeau .NET | +| 4 | [App-4-JobShopScheduling](CSP/App-4-JobShopScheduling.ipynb) | ~60 min | Intervalles, précédences, makespan | Projet étudiant | +| 4b | [App-4b-JobShopScheduling-CSharp](CSP/App-4b-JobShopScheduling-CSharp.ipynb) | ~45 min | **Jumeau C#** — dispatching heuristics (SPT/LPT/MOR/MWKR/FIFO) + branch-and-bound optimal from-scratch (énumération active + élagage), Gantt ASCII, parité #4956 | Jumeau .NET | +| 5 | [App-5-Timetabling](CSP/App-5-Timetabling.ipynb) | ~50 min | MiniZinc + OR-Tools | Projet étudiant | | 5b | [App-5-Timetabling-CSharp](CSP/App-5-Timetabling-CSharp.ipynb) | ~35 min | **Jumeau C#** — glouton MRV + branch-and-bound optimal from-scratch (énumération avec élagage par contrainte dure), visualisation ASCII, parité #4956 | Jumeau .NET | -| 6 | [App-6-Minesweeper](CSP/App-6-Minesweeper.html) | ~50 min | CSP + probabilités + LLM | Projet étudiant | +| 6 | [App-6-Minesweeper](CSP/App-6-Minesweeper.ipynb) | ~50 min | CSP + probabilités + LLM | Projet étudiant | | 6 | [App-6-Minesweeper-CSharp](CSP/App-6-Minesweeper-CSharp.ipynb) | ~50 min | **Jumeau C#** — CSP backtracking from-scratch + probabilités, parité #4956 | Jumeau .NET | -| 7 | [App-7-Wordle](CSP/App-7-Wordle.html) | ~45 min | Filtrage CSP + théorie de l'information | Projet étudiant | -| 7b | [App-7b-Wordle-CSharp](CSP/App-7b-Wordle-CSharp.html) | ~35 min | **Jumeau C#** — filtrage simple, CSP par propagation de domaines, solveur par entropie de Shannon from-scratch, parité #4956 | Jumeau .NET | -| 8 | [App-8-MiniZinc](CSP/App-8-MiniZinc.html) | ~50 min | Syntaxe MiniZinc, contraintes globales | Nouveau | +| 7 | [App-7-Wordle](CSP/App-7-Wordle.ipynb) | ~45 min | Filtrage CSP + théorie de l'information | Projet étudiant | +| 7b | [App-7b-Wordle-CSharp](CSP/App-7b-Wordle-CSharp.ipynb) | ~35 min | **Jumeau C#** — filtrage simple, CSP par propagation de domaines, solveur par entropie de Shannon from-scratch, parité #4956 | Jumeau .NET | +| 8 | [App-8-MiniZinc](CSP/App-8-MiniZinc.ipynb) | ~50 min | Syntaxe MiniZinc, contraintes globales | Nouveau | | 8 | [App-8-MiniZinc-CSharp](CSP/App-8-MiniZinc-CSharp.ipynb) | ~50 min | **Jumeau C#** — Google.OrTools CP-SAT (Prong A #3801), modèles déclaratifs équivalents MiniZinc (MiniZinc n'a pas de binding .NET), parité #4956 | Jumeau .NET | -| 9 | [App-11-Picross](CSP/App-11-Picross.html) | ~40 min | Nonogrammes : 27Mx speedup CP-SAT | Projet étudiant | +| 9 | [App-11-Picross](CSP/App-11-Picross.ipynb) | ~40 min | Nonogrammes : 27Mx speedup CP-SAT | Projet étudiant | | 9b | [App-11b-Picross-CSharp](CSP/App-11b-Picross-CSharp.ipynb) | ~40 min | Twin C# : énumération de motifs, propagation par intersection (point fixe), naïf vs propagation | Classique | -| 10 | [App-15-SportsScheduling](CSP/App-15-SportsScheduling.html) | ~55 min | Calendrier sportif : contraintes TV, équité, déplacements | Projet étudiant | +| 10 | [App-15-SportsScheduling](CSP/App-15-SportsScheduling.ipynb) | ~55 min | Calendrier sportif : contraintes TV, équité, déplacements | Projet étudiant | | 10b | [App-15b-SportsScheduling-CSharp](CSP/App-15b-SportsScheduling-CSharp.ipynb) | ~55 min | **Jumeau C#** — Google.OrTools CP-SAT natif .NET, round-robin + équilibre D/E + déplacements, parité #4956 | Jumeau .NET | -| 11 | [App-16-Crossword-CSP](CSP/App-16-Crossword-CSP.html) | ~45 min | Mots croisés : backtracking, OR-Tools, génération | Projet étudiant | +| 11 | [App-16-Crossword-CSP](CSP/App-16-Crossword-CSP.ipynb) | ~45 min | Mots croisés : backtracking, OR-Tools, génération | Projet étudiant | | 11 | [App-16-Crossword-CSP-CSharp](CSP/App-16-Crossword-CSP-CSharp.ipynb) | ~45 min | **Jumeau C#** — backtracking + propagation de domaines from-scratch (le twin Python s'appuie sur OR-Tools CP-SAT), parité #4956 | Jumeau .NET | -| 12 | [App-19-ProceduralGeneration-WFC](CSP/App-19-ProceduralGeneration-WFC.html) | ~45 min | Génération procédurale : Wave Function Collapse via CP-SAT | Projet étudiant | +| 12 | [App-19-ProceduralGeneration-WFC](CSP/App-19-ProceduralGeneration-WFC.ipynb) | ~45 min | Génération procédurale : Wave Function Collapse via CP-SAT | Projet étudiant | | 12 | [App-19-ProceduralGeneration-WFC-CSharp](CSP/App-19-ProceduralGeneration-WFC-CSharp.ipynb) | ~45 min | **Jumeau C#** — Wave Function Collapse from-scratch (algorithme de Gumin : effondrement progressif + propagation de contraintes), parité #4956 | Jumeau .NET | -| 13 | [App-20-SudokuBenchmark-Python](CSP/App-20-SudokuBenchmark-Python.html) | ~50 min | Benchmark comparatif : 4 solveurs Sudoku, un problème NP-complet | Nouveau | -| 13b | [App-20b-SudokuBenchmark-CSharp](CSP/App-20b-SudokuBenchmark-CSharp.html) | ~35 min | **Jumeau C#** — backtracking naïf/MRV, AC-3, Dancing Links (Knuth) from-scratch, benchmark 3 difficultés, parité #4956 | Jumeau .NET | +| 13 | [App-20-SudokuBenchmark-Python](CSP/App-20-SudokuBenchmark-Python.ipynb) | ~50 min | Benchmark comparatif : 4 solveurs Sudoku, un problème NP-complet | Nouveau | +| 13b | [App-20b-SudokuBenchmark-CSharp](CSP/App-20b-SudokuBenchmark-CSharp.ipynb) | ~35 min | **Jumeau C#** — backtracking naïf/MRV, AC-3, Dancing Links (Knuth) from-scratch, benchmark 3 difficultés, parité #4956 | Jumeau .NET | | 14 | [App-21-VoiceLeading](CSP/App-21-VoiceLeading.ipynb) | ~40 min | Hommage Munkres : voice leading chorale par affectation (Kuhn-Munkres via scipy) + audit/réparation du contrepoint de Fux en CP-SAT — encodage issu des projets étudiants EPITA PrCon (H1/H1_V2) | Hommage Munkres / projets étudiants EPITA | --- @@ -138,17 +138,17 @@ Quand l'espace est trop vaste ou l'objectif trop irrégulier pour les méthodes | # | Notebook | Durée | Contenu | Source | |---|----------|-------|---------|--------| -| 1 | [App-9-EdgeDetection](Hybrid/App-9-EdgeDetection.html) | ~40 min | GA pour filtres de convolution | Existant | -| 2 | [App-9b-EdgeDetection-CSharp](Hybrid/App-9b-EdgeDetection-CSharp.html) | ~35 min | GeneticSharp (C#) | Existant | -| 3 | [App-10-Portfolio](Hybrid/App-10-Portfolio.html) | ~40 min | Multi-objectif, frontière de Pareto | Existant | -| 4 | [App-10b-Portfolio-CSharp](Hybrid/App-10b-Portfolio-CSharp.html) | ~30 min | GeneticSharp (C#) | Existant | +| 1 | [App-9-EdgeDetection](Hybrid/App-9-EdgeDetection.ipynb) | ~40 min | GA pour filtres de convolution | Existant | +| 2 | [App-9b-EdgeDetection-CSharp](Hybrid/App-9b-EdgeDetection-CSharp.ipynb) | ~35 min | GeneticSharp (C#) | Existant | +| 3 | [App-10-Portfolio](Hybrid/App-10-Portfolio.ipynb) | ~40 min | Multi-objectif, frontière de Pareto | Existant | +| 4 | [App-10b-Portfolio-CSharp](Hybrid/App-10b-Portfolio-CSharp.ipynb) | ~30 min | GeneticSharp (C#) | Existant | | 5 | [App-13-TSP-Metaheuristics](Hybrid/App-13-TSP-Metaheuristics.ipynb) | ~50 min | TSP : SA, GA, ACO, OR-Tools routing | Classique | | 5b | [App-13b-TSP-Metaheuristics-CSharp](Hybrid/App-13b-TSP-Metaheuristics-CSharp.ipynb) | ~45 min | Twin C# : force brute, plus proche voisin, 2-opt from-scratch, recuit simulé sur permutations | Classique | -| 6 | [App-17-VRP-Logistics](Hybrid/App-17-VRP-Logistics.html) | ~60 min | Vehicle Routing : SA, GA, ACO, CP-SAT | Projet étudiant | +| 6 | [App-17-VRP-Logistics](Hybrid/App-17-VRP-Logistics.ipynb) | ~60 min | Vehicle Routing : SA, GA, ACO, CP-SAT | Projet étudiant | | 6b | [App-17b-VRP-Logistics-CSharp](Hybrid/App-17b-VRP-Logistics-CSharp.ipynb) | ~50 min | Twin C# : Nearest-Neighbor, cheapest-insertion, 2-opt, recuit simulé (métaheuristiques from-scratch) | Jumeau .NET | | 6c | [App-17b-VRP-Logistics-Python](Hybrid/App-17b-VRP-Logistics-Python.ipynb) | ~45 min | Twin Python from-scratch : NN, insertion, 2-opt, recuit et vérification OR-Tools | Jumeau Python | -| 7 | [App-18-HyperparameterTuning](Hybrid/App-18-HyperparameterTuning.html) | ~40 min | Optimisation ML : Bayésienne, GA, PSO, Optuna | Nouveau | -| 7b | [App-18b-HyperparameterTuning-CSharp](Hybrid/App-18b-HyperparameterTuning-CSharp.html) | ~40 min | **Jumeau C#** — Grid/Random Search + Bayesian Optimization from-scratch (Gaussian Process RBF + Expected Improvement via Abramowitz-Stegun) + GA + PSO, objectif = k-NN CV 5-fold, parité #4956 | Jumeau .NET | +| 7 | [App-18-HyperparameterTuning](Hybrid/App-18-HyperparameterTuning.ipynb) | ~40 min | Optimisation ML : Bayésienne, GA, PSO, Optuna | Nouveau | +| 7b | [App-18b-HyperparameterTuning-CSharp](Hybrid/App-18b-HyperparameterTuning-CSharp.ipynb) | ~40 min | **Jumeau C#** — Grid/Random Search + Bayesian Optimization from-scratch (Gaussian Process RBF + Expected Improvement via Abramowitz-Stegun) + GA + PSO, objectif = k-NN CV 5-fold, parité #4956 | Jumeau .NET | | 7c | [App-18b-HyperparameterTuning-Python](Hybrid/App-18b-HyperparameterTuning-Python.ipynb) | ~45 min | Twin Python from-scratch : Grid/Random, GP-EI, GA, PSO et vérification Optuna | Jumeau Python | | 7d | [App-18c-HyperparameterTuning-Rustuna-vs-Optuna](Hybrid/App-18c-HyperparameterTuning-Rustuna-vs-Optuna.ipynb) | ~30 min | Rustuna vs Optuna : pont SOTA triple (Random numpy / Optuna TPE / Rustuna TPE) sur l'objectif k-NN CV d'App-18b, speedup mesuré deux régimes, audit d'une dépendance expérimentale (bug `best_trial` mesuré) | Nouveau | | 8 | [App-22-AlgorithmSelection-Python](Hybrid/App-22-AlgorithmSelection-Python.ipynb) | ~45 min | Sélection empirique d'algorithmes : 3 jeux (Sudoku, Puissance 4, Wordle), 13 familles conceptuelles / 14 étiquettes mesurées, non-commensurabilité des métriques + frontières de Pareto + choix sous préférences — hommage PR IS #42 (Théodore Deguest) | Projet étudiant (IS PR #42) | @@ -227,7 +227,7 @@ Quand l'espace est trop vaste ou l'objectif trop irrégulier pour les méthodes La plupart des notebooks d'application sont adaptés de projets étudiants réalisés dans le cadre de cours d'IA. Les références spécifiques sont indiquées dans chaque notebook. -Le [App-22-AlgorithmSelection-Python](Hybrid/App-22-AlgorithmSelection-Python.html) est un cas particulier : il **distille** un projet étudiant — **Théodore Deguest**, *« Benchmark cross-paradigme de solveurs de jeux »*, PR [IS #42](https://github.com/jsboigeEpita/2026-Epita-Intelligence-Symbolique/pull/42) — sans en recopier le code. Les solveurs restent dans le dépôt source ; seules les données de résultats sont réutilisées (licence MIT, attribution conservée), et l'analyse est nouvelle et porte la marque CoursIA. +Le [App-22-AlgorithmSelection-Python](Hybrid/App-22-AlgorithmSelection-Python.ipynb) est un cas particulier : il **distille** un projet étudiant — **Théodore Deguest**, *« Benchmark cross-paradigme de solveurs de jeux »*, PR [IS #42](https://github.com/jsboigeEpita/2026-Epita-Intelligence-Symbolique/pull/42) — sans en recopier le code. Les solveurs restent dans le dépôt source ; seules les données de résultats sont réutilisées (licence MIT, attribution conservée), et l'analyse est nouvelle et porte la marque CoursIA. Le [App-23-PRESENT-Differential-Cryptanalysis-SAT](Hybrid/App-23-PRESENT-Differential-Cryptanalysis-SAT.ipynb) distille le projet PrCon F2 de **Théodore Deguest**, *« Cryptanalyse différentielle de PRESENT via SAT »*, PR [PrCon #49](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/49). Le notebook reconstruit l'expérience de façon autonome, reproduit la DDT et les frontières SAT/UNSAT, corrige le seuil documentaire à R=15/W=66 et distingue explicitement trail, cluster et niveau de preuve. diff --git a/MyIA.AI.Notebooks/Search/Part1-Foundations/README.md b/MyIA.AI.Notebooks/Search/Part1-Foundations/README.md index 7f427d0068..5d5b806043 100644 --- a/MyIA.AI.Notebooks/Search/Part1-Foundations/README.md +++ b/MyIA.AI.Notebooks/Search/Part1-Foundations/README.md @@ -8,7 +8,7 @@ Le parcours s'ouvre sur une idée simple et étonnamment puissante : avant de r Cette formalisation se voit : le **monde de l'aspirateur** (Search-1) se ramène à un espace d'états de huit nœuds — la position de l'aspirateur croisée à la propreté des deux pièces — reliés par des transitions colorées selon l'action exécutée (aspirer, aller à gauche, aller à droite). C'est ce graphe qu'explorent ensuite tous les algorithmes de la partie. -[![Espace d'états du monde de l'aspirateur : 8 états en grille, transitions colorées par action](assets/readme/search1-statespace.png)](Search-01-StateSpace.html) +[![Espace d'états du monde de l'aspirateur : 8 états en grille, transitions colorées par action](assets/readme/search1-statespace.png)](Search-01-StateSpace.ipynb) La suite change deux fois de point de vue. Quand seule la destination compte — pas le chemin —, la recherche locale (Search-4) abandonne l'arbre d'exploration pour naviguer de voisin en voisin dans un paysage de fitness, quitte à accepter temporairement de moins bonnes solutions pour s'échapper des optima locaux (recuit simulé, recherche tabou). Les algorithmes génétiques (Search-5) généralisent le procédé : une population entière explore en parallèle, sélection et croisement faisant émerger les bonnes solutions. Et quand l'environnement riposte — un adversaire joue contre vous —, la recherche devient un jeu : Minimax et l'élagage Alpha-Beta (Search-6), puis Monte Carlo Tree Search (Search-7), qui remplace l'évaluation experte par la simulation statistique et mène jusqu'à l'architecture d'AlphaGo. @@ -32,11 +32,11 @@ Cette partie est l'alphabet de toute la série : la formalisation en espace d'é | # | Notebook | Kernel | Contenu | Durée | |---|----------|--------|---------|-------| -| 1 | [Search-01-StateSpace](Search-01-StateSpace.html) | Python 3 | Espaces d'états, formalisation (S, A, T, G), taquin, aspirateur, recherche d'itinéraire | ~40 min | -| 1 (.NET) | [Search-01-StateSpace (C#)](Search-01-StateSpace-CSharp.html) | .NET (C#) | **Jumeau .NET** : formalisation (S, A, T, G) en C# 9.0 (`SearchProblem` abstrait, `object` comme etat generique), VacuumWorld (8 etats, parcours complet), 8-Puzzle (181 440 etats), RouteFinding — port C# fidèle avec `Dictionary`, tuples nommes (`(char pos, bool gSale, bool dSale)`) | ~40 min | -| 2 | [Search-02-Uninformed](Search-02-Uninformed.html) | Python 3 | BFS, DFS, UCS, IDDFS : comparaison des algorithmes non informés | ~50 min | +| 1 | [Search-01-StateSpace](Search-01-StateSpace.ipynb) | Python 3 | Espaces d'états, formalisation (S, A, T, G), taquin, aspirateur, recherche d'itinéraire | ~40 min | +| 1 (.NET) | [Search-01-StateSpace (C#)](Search-01-StateSpace-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : formalisation (S, A, T, G) en C# 9.0 (`SearchProblem` abstrait, `object` comme etat generique), VacuumWorld (8 etats, parcours complet), 8-Puzzle (181 440 etats), RouteFinding — port C# fidèle avec `Dictionary`, tuples nommes (`(char pos, bool gSale, bool dSale)`) | ~40 min | +| 2 | [Search-02-Uninformed](Search-02-Uninformed.ipynb) | Python 3 | BFS, DFS, UCS, IDDFS : comparaison des algorithmes non informés | ~50 min | | 2 (.NET) | [Search-02-Uninformed (C#)](Search-02-Uninformed-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : BFS (Queue), DFS (Stack), UCS (PriorityQueue), IDDFS — port C# fidèle sur le graphe des villes françaises + arbre profond 8x3 (ratio BFS/DFS = 156,1×) + BFS bidirectionnel avec reconstruction de coût | ~50 min | -| 2b | [Search-02b-NetworkX](Search-02b-NetworkX.html) | Python 3 | **Boîte à outils de graphes** `networkx` : `Graph`/`DiGraph`, DFS/BFS, Dijkstra, Bellman-Ford, centralités de degré, composantes connexes, MST, Floyd-Warshall, parité structurelle avec QuikGraph (Search-2c) — matière optionnelle, utile dès la fin de Search-2 | ~1h | +| 2b | [Search-02b-NetworkX](Search-02b-NetworkX.ipynb) | Python 3 | **Boîte à outils de graphes** `networkx` : `Graph`/`DiGraph`, DFS/BFS, Dijkstra, Bellman-Ford, centralités de degré, composantes connexes, MST, Floyd-Warshall, parité structurelle avec QuikGraph (Search-2c) — matière optionnelle, utile dès la fin de Search-2 | ~1h | | 2b (.NET) | [Search-02b-NetworkX (C#)](Search-02b-NetworkX-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : théorie des graphes from-scratch (`Dictionary` / adjacency list pondérée) — parcours BFS/DFS, plus courts chemins (Dijkstra), centralités, flot maximum (Ford-Fulkerson), exercices (détection de cycles DFS 3 couleurs, A* avec heuristique, communautés Louvain) + tranche 2 QuikGraph (parité lib-vs-lib sur la même instance) — port C# fidèle du notebook Python NetworkX, distinct de Search-2c (QuikGraph, approche library) — parité #4956 | ~1h | | 2c | [Search-02c-QuikGraph](Search-02c-QuikGraph.ipynb) | .NET (C#) | Bibliothèque de graphes QuikGraph 2.5.0 (NuGet) : AdjacencyGraph / BidirectionalGraph / UndirectedGraph, DFS/BFS, Dijkstra, Bellman-Ford, centralités de degré, composantes connexes, Edmonds-Karp (flot max), parité avec NetworkX | ~1h | | 3 | [Search-03-Informed](Search-03-Informed.ipynb) | Python 3 | A*, Greedy, IDA*, heuristiques admissibles et consistantes | ~50 min | @@ -49,25 +49,25 @@ Cette partie est l'alphabet de toute la série : la formalisation en espace d'é | 3d (.NET) | [Search-03d-WeightedAstar (C#)](Search-03d-WeightedAstar-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : même Weighted A\*, balayage de W — port C# (PriorityQueue, value types), coût <= W fois l'optimal (accrétion de Search-3) | ~50min | | 3e | [Search-03e-AStar-Optimality](Search-03e-AStar-Optimality.ipynb) | Python 3 (+WSL lean) | **Compagnon formel** : l'admissibilité comme condition exacte de l'optimalité d'A\* — preuves du lake [`search_lean`](../search_lean/) visitées depuis Python (subprocess → WSL `lean`), pont vers Lean-6 (accrétion de Search-3) | ~45min | | 3f | [Search-03f-Reparer-Localement-Sous-Garantie](Search-03f-Reparer-Localement-Sous-Garantie-Python.ipynb) | Python 3 | **Réparer localement sous garantie** (op 6 du chantier ICT, [#12204](https://github.com/jsboige/CoursIA/issues/12204)) : recherche incrémentale **LPA\*** (Koenig & Likhachev 2002) — g/rhs et file d'incohérences, repair après blocage d'une cellule du plan optimal : optimalité **transportée** (34 = 34) au prix de 12 expansions contre 273 au A\* from scratch (23×), séquence de 8 changements 8/8 concordante (9 vs 2258 expansions cumulées), contre-témoins mesurés — repair naïf dette +2 ; sans propagation, g(goal) affirme 34 pour un optimum réel de 36 sur un monde à goulet, où le changement structurel annule l'avantage (269 vs 276) — 2e attestation, substrat indépendant de GT-13b/13c ; **section « recoller »** (op 5 du chantier ICT) : tables locales de trois fenêtres chevauchantes recollées — compatibilité par paires vérifiée, composition sur le triple violée puis réparée, témoin exploitable exécuté pas à pas (accrétion de Search-3) | ~1h45 | -| 4 | [Search-04-LocalSearch](Search-04-LocalSearch.html) | Python 3 | Hill Climbing, Simulated Annealing, Tabu Search, paysages de fitness | ~45 min | +| 4 | [Search-04-LocalSearch](Search-04-LocalSearch.ipynb) | Python 3 | Hill Climbing, Simulated Annealing, Tabu Search, paysages de fitness | ~45 min | | 4 (.NET) | [Search-04-LocalSearch (C#)](Search-04-LocalSearch-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : Hill Climbing (steepest-ascent), Random-Restart, recuit simulé (critère de Metropolis, programmes de refroidissement), recherche tabou (liste tabou) — port C# fidèle sur paysage 1D multimodal puis N-Reines (benchmark taux de succès) | ~45 min | -| 5 | [Search-05-GeneticAlgorithms](Search-05-GeneticAlgorithms.html) | Python 3 | Sélection, crossover, mutation, DEAP/PyGAD, théorie unifiée | ~50 min | -| 5 (.NET) | [Search-05-GeneticAlgorithms (C#)](Search-05-GeneticAlgorithms-CSharp.html) | .NET (C#) | **Jumeau .NET** : algorithme générique from-scratch `GeneticAlgorithm` (sélection roulette/tournoi, crossover 1-point/arithmétique, mutation bit-flip/gaussienne), élitisme, taux de mutation adaptatif — port C# fidèle validé sur OneMax (convergence 20/20, GA-easy), **piège déceptif Goldberg k-trap (k=4, L=20)** : hill-climber bloqué 17/20 (gradient trompeur), AG atteint 20/20 via croisement qui recombine les blocs tout-1 [#6849] + Rastrigin (f(x)≈1.3, optimum local évité) | ~1h | +| 5 | [Search-05-GeneticAlgorithms](Search-05-GeneticAlgorithms.ipynb) | Python 3 | Sélection, crossover, mutation, DEAP/PyGAD, théorie unifiée | ~50 min | +| 5 (.NET) | [Search-05-GeneticAlgorithms (C#)](Search-05-GeneticAlgorithms-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : algorithme générique from-scratch `GeneticAlgorithm` (sélection roulette/tournoi, crossover 1-point/arithmétique, mutation bit-flip/gaussienne), élitisme, taux de mutation adaptatif — port C# fidèle validé sur OneMax (convergence 20/20, GA-easy), **piège déceptif Goldberg k-trap (k=4, L=20)** : hill-climber bloqué 17/20 (gradient trompeur), AG atteint 20/20 via croisement qui recombine les blocs tout-1 [#6849] + Rastrigin (f(x)≈1.3, optimum local évité) | ~1h | | 6 | [Search-06-AdversarialSearch](Search-06-AdversarialSearch.ipynb) | Python 3 | Minimax, Alpha-Beta pruning, Null-window search, tables de transposition | ~1h | -| 6 (.NET) | [Search-06-AdversarialSearch (C#)](Search-06-AdversarialSearch-CSharp.html) | .NET (C#) | **Jumeau .NET** : Minimax, Alpha-Beta (speedup 31,9×), heuristique + profondeur limitée, iterative deepening, table de transposition — port C# fidèle sur Tic-Tac-Toe (valeur du jeu = 0) | ~1h | +| 6 (.NET) | [Search-06-AdversarialSearch (C#)](Search-06-AdversarialSearch-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : Minimax, Alpha-Beta (speedup 31,9×), heuristique + profondeur limitée, iterative deepening, table de transposition — port C# fidèle sur Tic-Tac-Toe (valeur du jeu = 0) | ~1h | | 7 | [Search-07-MCTS-And-Beyond](Search-07-MCTS-And-Beyond.ipynb) | Python 3 | Monte Carlo Tree Search, UCB1, OpenSpiel, architecture AlphaGo (DQN+MCTS) | ~1h30 | | 7 (.NET) | [Search-07-MCTS-And-Beyond (C#)](Search-07-MCTS-And-Beyond-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : MCTS générique (`IJeuSommeNulle` + UCB1, sélection/expansion/rollout/backprop en convention UCT « moved-into »), Minimax, convergence Tic-Tac-Toe, benchmark paramètre c (c=√2 optimal → 100 %), Nim (découvre l'action optimale 3) — port C# fidèle, tables texte au lieu de matplotlib | ~1h30 | | 8 | [Search-08-DancingLinks](Search-08-DancingLinks.ipynb) | Python 3 | Algorithme X de Knuth, Dancing Links (DLX), couverture exacte (Sudoku, N-Queens, Pentominoes) | ~1h30 | -| 8 (.NET) | [Search-08-DancingLinks (C#)](Search-08-DancingLinks-CSharp.html) | .NET (C#) | **Jumeau .NET** : Algorithme X naïf (réduction de matrice) + structure Dancing Links from-scratch (`DlxNode` toroïdal, `Cover`/`Uncover` O(1), heuristique S de Knuth), couverture exacte canonique [S2,S4,S6], pavage de polyominos (triominos I/L sur grille 2×3), comparaison perf DLX vs backtracking (DLX ~27× plus rapide sur pavage 3×3) — port C# fidèle Prong A, tables texte au lieu de matplotlib | ~1h30 | +| 8 (.NET) | [Search-08-DancingLinks (C#)](Search-08-DancingLinks-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : Algorithme X naïf (réduction de matrice) + structure Dancing Links from-scratch (`DlxNode` toroïdal, `Cover`/`Uncover` O(1), heuristique S de Knuth), couverture exacte canonique [S2,S4,S6], pavage de polyominos (triominos I/L sur grille 2×3), comparaison perf DLX vs backtracking (DLX ~27× plus rapide sur pavage 3×3) — port C# fidèle Prong A, tables texte au lieu de matplotlib | ~1h30 | | 9 | [Search-09-LinearProgramming](Search-09-LinearProgramming.ipynb) | Python 3 | Programmation linéaire avec PuLP, simplex, problème du transport, diet problem, PLNE | ~2h | | 9 (.NET) | [Search-09-LinearProgramming (C#)](Search-09-LinearProgramming-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : programmation linéaire avec Google OrTools (`LinearSolver`, solveurs GLOP/CBC) — problème de production, diet problem, analyse de sensibilité et dualité (shadow prices), PLNE (sac à dos binaire), exercices (set cover, optimisation multi-objectif) — port C# fidèle du notebook Python (PuLP) — parité #4956 | ~1h | | 9b | [Search-09b-SpuriousMinima](Search-09b-SpuriousMinima.ipynb) | Python 3 | Relaxation SDP de MaxCut (Goemans–Williamson, résolue exactement par cvxpy/CLARABEL) **et sa factorisation de Burer–Monteiro** $Y = XX^T$ : recensement borné des minima fallacieux par rang (40 départs × 3 instances C6/K8/G10, graines fixes, référence brute-force $2^{n-1}$) — à $r=1$ le paysage dégénère en MaxCut discret (40/40 fallacieux), les pièges se raréfient aux rangs intermédiaires, et **aucun piège à/au-dessus du seuil** $r(r+1)/2 > m$ (Burer–Monteiro 2005, Barvinok–Pataki) — le point d'arrivée « certification » du fil paysages (suite directe de Search-9, écho de MGS-15) | ~1h15 | | 9c | [Search-09c-CombinatorialDiscrepancy](Search-09c-CombinatorialDiscrepancy.ipynb) | Python 3 | Discrépance combinatoire (Beck–Fiala 1981, frontière 2025 Bansal–Jiang arXiv:2508.03961) : colorier ±1 sans déséquilibrer, borne inf √k (Chernoff), arrondi flottant 2k−1 implémenté, CP-SAT en oracle exact — fil relaxation/arrondi/optimisation combinatoire (accrétion de Search-9) | ~45min | -| 9d | [Search-09d-BeckFiala-Lean-Python](Search-09d-BeckFiala-Lean-Python.html) | Python 3 | **Pont Python vers le lake `discrepancy_lean`** : squelette de l'algorithme de Beck-Fiala (arrondi itératif, départ `0`, phases sur les lignes dangereuses), définitions Lean citées verbatim et écart mesuré à la borne `2k − 1` du théorème `beck_fiala_classic` — sans Lean au runtime, caveat préprocesseur documenté | ~45min | -| 9e | [Search-09e-Komlos-Lean](Search-09e-Komlos-Lean.html) | lean4-wsl | **Compagnon formel de Search-09c** : le lake [`discrepancy_lean`](../discrepancy_lean/README.md) exécuté depuis le kernel Lean 4 — `#check` des conjectures (Komlós ∃C universel, Beck–Fiala 2k−1, régimes Bansal–Jiang 2025), témoins coloriés ±1 énumérés exhaustivement sur des instances jouet (Hadamard ½n en particulier), exercices ancrés sur les énoncés du lake | ~45min | -| 10 | [Search-10-SymbolicAutomata](Search-10-SymbolicAutomata.html) | Python 3 | Automates finis (DFA/NFA) avec automata-lib, prédicats Z3, automates symboliques | ~2h | +| 9d | [Search-09d-BeckFiala-Lean-Python](Search-09d-BeckFiala-Lean-Python.ipynb) | Python 3 | **Pont Python vers le lake `discrepancy_lean`** : squelette de l'algorithme de Beck-Fiala (arrondi itératif, départ `0`, phases sur les lignes dangereuses), définitions Lean citées verbatim et écart mesuré à la borne `2k − 1` du théorème `beck_fiala_classic` — sans Lean au runtime, caveat préprocesseur documenté | ~45min | +| 9e | [Search-09e-Komlos-Lean](Search-09e-Komlos-Lean.ipynb) | lean4-wsl | **Compagnon formel de Search-09c** : le lake [`discrepancy_lean`](../discrepancy_lean/README.md) exécuté depuis le kernel Lean 4 — `#check` des conjectures (Komlós ∃C universel, Beck–Fiala 2k−1, régimes Bansal–Jiang 2025), témoins coloriés ±1 énumérés exhaustivement sur des instances jouet (Hadamard ½n en particulier), exercices ancrés sur les énoncés du lake | ~45min | +| 10 | [Search-10-SymbolicAutomata](Search-10-SymbolicAutomata.ipynb) | Python 3 | Automates finis (DFA/NFA) avec automata-lib, prédicats Z3, automates symboliques | ~2h | | 10 (.NET) | [Search-10-SymbolicAutomata (C#)](Search-10-SymbolicAutomata-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** (tranches 1+2) : automates finis classiques (DFA/NFA hand-rolled, opérations ensemblistes par produit cartésien) **+** automates symboliques avec `Microsoft.Z3` (NuGet 4.12.2) — classe `SymbolicAutomaton` (transitions = prédicats Z3, décision via solveur SMT), intervalle [10,100], parité, multiples de 5, opérations symboliques (union/intersection/complément via `MkAnd`/`MkOr`/`MkNot` vérifiées exactes) — port C# fidèle §1-4 — parité #4956 | ~1h30 | -| 11 | [Search-11-Metaheuristics](Search-11-Metaheuristics.html) | Python 3 | PSO, ABC, SA, BRO avec MEALPy, benchmark comparatif de métaheuristiques | ~1h30 | +| 11 | [Search-11-Metaheuristics](Search-11-Metaheuristics.ipynb) | Python 3 | PSO, ABC, SA, BRO avec MEALPy, benchmark comparatif de métaheuristiques | ~1h30 | | 11 (.NET) | [Search-11-Metaheuristics (C#)](Search-11-Metaheuristics-CSharp.ipynb) | .NET (C#) | **Jumeau .NET** : PSO (inertie décroissante + clamp velocity), recuit simulé (acceptation Metropolis, pas proportionnel à √(T/T₀)), algorithme génétique (tournoi, croisement arithmétique, mutation gaussienne, élitisme) from-scratch, fonctions de benchmark (Sphere/Rastrigin/Rosenbrock/Ackley), convergence gbest monotone, benchmark comparatif PSO/SA/GA, optimisation de profit (retrouve l'optimum analytique x≈17.14, y≈15.71), TSP par recuit 2-opt — parité #4956, tables texte au lieu de matplotlib | ~1h30 | | 11b (.NET) | [Search-11b-Metaheuristiques-Deep](Search-11b-Metaheuristiques-Deep.ipynb) (+ [T2 PSO](Search-11b-Metaheuristiques-Deep-Part2.ipynb), [T3 ABC](Search-11b-Metaheuristiques-Deep-Part3.ipynb), [T4 Benchmark](Search-11b-Metaheuristiques-Deep-Part4.ipynb)) | .NET (C#) | **Déclinaison deep-dive** en 4 volets — un algorithme from-scratch approfondi par tranche : recuit simulé (T1), Particle Swarm Optimization (T2), Artificial Bee Colony (T3), benchmark comparatif capstone (T4). Complète le jumeau 11 (.NET) (survol PSO/SA/GA) par un traitement détaillé algorithme par algorithme | ~4×45 min | | 11c | [Search-11c-Empirical-Algorithm-Selection](Search-11c-Empirical-Algorithm-Selection.ipynb) | Python 3 | Distillation du projet L4 EPITA SCIA 2026 (Th. Deguest, PR source #42) : **sélection empirique d'algorithmes** sous protocole commun (timeout 5 s, budget nœuds explicite, métriques uniformes) sur deux terrains — Sudoku (BT naïf/MRV, DLX, CP-SAT, Z3, GA, recuit simulé ; tranche 1) et Puissance 4 (random, minimax, alpha-beta, MCTS ; round-robin double, tranche 2) — front de Pareto qualité-coût, sweep de budget qui **inverse la sélection**, carte problème × paradigme : No Free Lunch mesuré (Rice 1976, Wolpert 1996), écho App-14 | ~1h30 | @@ -125,9 +125,9 @@ Pour le setup complet, voir le [README de la série Search](../README.md). ## Bibliothèques : parité Python `networkx` ↔ .NET `QuikGraph` -Le notebook [Search-2c-QuikGraph](Search-02c-QuikGraph.ipynb) ferme la boucle côté **.NET Interactive** : il offre l'équivalent C# du notebook Python [Search-2b-NetworkX](Search-02b-NetworkX.html), avec une table de parité structurelle entre les deux écosystèmes. Le notebook Python modélise par exemple un réseau routier 5×5 : les arêtes sont colorées par poids (du jaune au rouge) et le plus court chemin — identique pour Dijkstra et A\* — y est tracé en rouge entre la source (en vert) et la destination (en rouge). +Le notebook [Search-2c-QuikGraph](Search-02c-QuikGraph.ipynb) ferme la boucle côté **.NET Interactive** : il offre l'équivalent C# du notebook Python [Search-2b-NetworkX](Search-02b-NetworkX.ipynb), avec une table de parité structurelle entre les deux écosystèmes. Le notebook Python modélise par exemple un réseau routier 5×5 : les arêtes sont colorées par poids (du jaune au rouge) et le plus court chemin — identique pour Dijkstra et A\* — y est tracé en rouge entre la source (en vert) et la destination (en rouge). -[![Réseau routier 5×5 : arêtes pondérées colorées, plus court chemin Dijkstra en rouge](assets/readme/search02b-networkx.png)](Search-02b-NetworkX.html) +[![Réseau routier 5×5 : arêtes pondérées colorées, plus court chemin Dijkstra en rouge](assets/readme/search02b-networkx.png)](Search-02b-NetworkX.ipynb) La règle pratique : **QuikGraph 2.5.0** (fork KeRNeLith, NuGet) couvre les algorithmes classiques (DFS, BFS, Dijkstra, Bellman-Ford, A\*, Edmonds-Karp, Tarjan, MST, Floyd-Warshall) et **suffit pour tous les notebooks Search 1-11** si l'on travaille en C# — son **verdict honnête** est qu'il ne fournit pas les centralités élaborées (betweenness, closeness, PageRank) ni la détection de communautés (Louvain), qu'il faut alors implémenter à la main ou brancher une autre bibliothèque. @@ -173,7 +173,7 @@ Cette première partie a posé **l'alphabet de la recherche en IA**. L'arc péda Deux de ces familles se donnent à voir dans les figures extraites des notebooks. La **recherche systématique** oppose d'abord les stratégies à l'aveugle : sur un même arbre binaire, l'écart d'expansion entre BFS (par niveaux) et DFS (en profondeur) saute aux yeux dès qu'on numérote les nœuds par ordre d'exploration. -[![BFS vs DFS : deux arbres binaires, nœuds numérotés par ordre d'exploration](assets/readme/search2-bfs-dfs.png)](Search-02-Uninformed.html) +[![BFS vs DFS : deux arbres binaires, nœuds numérotés par ordre d'exploration](assets/readme/search2-bfs-dfs.png)](Search-02-Uninformed.ipynb) Dès qu'une heuristique est disponible, A* exploite ce savoir pour prioriser les états prometteurs : sur le 8-puzzle, chaque état développé est annoté de ses coûts `g` (déjà parcouru), `h` (estimé par distance de Manhattan) et `f = g + h`, et l'optimum est atteint en explorant peu de nœuds. @@ -181,11 +181,11 @@ Dès qu'une heuristique est disponible, A* exploite ce savoir pour prioriser les Côté **recherche locale et évolutive**, le benchmark comparatif de Search-11 confirme le *no-free-lunch* : aucune métaheuristique ne domine partout, que ce soit en fitness atteinte (échelle log) ou en temps de calcul. -[![Comparaison des métaheuristiques : fitness (log) et temps, par algorithme et fonction](assets/readme/search11-metaheuristics.png)](Search-11-Metaheuristics.html) +[![Comparaison des métaheuristiques : fitness (log) et temps, par algorithme et fonction](assets/readme/search11-metaheuristics.png)](Search-11-Metaheuristics.ipynb) L'étude du paramètre clé, la taille de population PSO, quantifie alors l'arbitrage entre qualité de la solution et coût de calcul. -[![Impact de la taille de population PSO : fitness et temps](assets/readme/search11-convergence.png)](Search-11-Metaheuristics.html) +[![Impact de la taille de population PSO : fitness et temps](assets/readme/search11-convergence.png)](Search-11-Metaheuristics.ipynb) Le véritable enseignement, au-delà du catalogue d'algorithmes, est un **réflexe d'ingénieur** : chaque méthode y est présentée comme un compromis — complétude contre mémoire, garantie contre temps de calcul, exploration contre exploitation — et jamais comme une recette universelle. diff --git a/MyIA.AI.Notebooks/Search/Part2-CSP/README.md b/MyIA.AI.Notebooks/Search/Part2-CSP/README.md index 4be67bf0b0..d4d639399b 100644 --- a/MyIA.AI.Notebooks/Search/Part2-CSP/README.md +++ b/MyIA.AI.Notebooks/Search/Part2-CSP/README.md @@ -8,31 +8,31 @@ Les deux premiers notebooks installent le socle. CSP-1 pose le modèle (X, D, C) Ces deux idées se voient sur le fil rouge de la partie, la coloration de l'Australie. CSP-1 en pose le **graphe de contraintes** : sept variables — les États — reliées par une contrainte de différence par frontière, chacune dotée d'un domaine de trois couleurs (la Tasmanie, sans voisin, flotte hors du graphe) : -[![Graphe de contraintes de la coloration de l'Australie : 7 variables aux domaines de taille 3, la Tasmanie isolée](assets/readme/csp1-backtracking-tree.png)](CSP-1-Fundamentals.html) +[![Graphe de contraintes de la coloration de l'Australie : 7 variables aux domaines de taille 3, la Tasmanie isolée](assets/readme/csp1-backtracking-tree.png)](CSP-1-Fundamentals.ipynb) CSP-2 montre ensuite la propagation à l'œuvre sur le même graphe : une fois WA fixée à Rouge, AC-3 réduit les domaines de SA et NT à {Vert, Bleu} avant tout essai de valeur — la déduction locale a resserré l'espace de recherche : -[![Propagation AC-3 sur la coloration de l'Australie, avant/après : WA fixée à Rouge, domaines de SA et NT réduits à Vert-Bleu](assets/readme/csp2-ac3-propagation.png)](CSP-2-Consistency.html) +[![Propagation AC-3 sur la coloration de l'Australie, avant/après : WA fixée à Rouge, domaines de SA et NT réduits à Vert-Bleu](assets/readme/csp2-ac3-propagation.png)](CSP-2-Consistency.ipynb) La montée en puissance occupe les quatre notebooks suivants. CSP-3 passe aux contraintes globales (AllDifferent, Cumulative, Circuit), ces contraintes de haut niveau pour lesquelles les solveurs embarquent des propagateurs spécialisés — c'est là que CP-SAT se met à résoudre en quelques millisecondes ce qu'un backtracking naïf mettrait des heures à parcourir. CSP-4 et CSP-5 appliquent l'arsenal aux deux grands classiques industriels : l'ordonnancement (Job-Shop, RCPSP, planification d'infirmiers) et l'optimisation combinatoire (Bin Packing, Knapsack, portefeuille). CSP-6, le notebook le plus avancé, ouvre le capot : la Lazy Clause Generation explique pourquoi CP-SAT s'appelle ainsi — un solveur CP qui apprend des clauses SAT en cours de route — et les hybridations CP+ML et LLM+CSP esquissent ce que devient la discipline à l'ère des grands modèles : le langage naturel comme interface de modélisation, le solveur comme garant. Trois de ces jalons s'illustrent directement. La contrainte globale `Cumulative` (CSP-3) ordonnance quatre tâches sous une capacité de deux machines — le Gantt optimal, et un profil de charge qui sature la capacité presque partout : -[![Contrainte globale Cumulative : ordonnancement optimal de 4 tâches sur 2 machines, Gantt et profil de charge saturant la capacité 2](assets/readme/csp3-global-constraints.png)](CSP-3-Advanced.html) +[![Contrainte globale Cumulative : ordonnancement optimal de 4 tâches sur 2 machines, Gantt et profil de charge saturant la capacité 2](assets/readme/csp3-global-constraints.png)](CSP-3-Advanced.ipynb) CSP-4 passe au Job-Shop : trois jobs s'entrelacent sur trois machines via `IntervalVar` et `NoOverlap`, pour un makespan optimal de 11 : -[![Diagramme de Gantt d'un Job-Shop résolu par CP-SAT : 3 jobs entrelacés sur 3 machines, makespan 11](assets/readme/csp4-jobshop-gantt.png)](CSP-4-Scheduling.html) +[![Diagramme de Gantt d'un Job-Shop résolu par CP-SAT : 3 jobs entrelacés sur 3 machines, makespan 11](assets/readme/csp4-jobshop-gantt.png)](CSP-4-Scheduling.ipynb) Le benchmark de parallélisation de CSP-6 rappelle enfin qu'aucun mécanisme n'est magique : sur un N-Queens 12 résolu en quelques millisecondes, passer de 1 à 4 workers n'apporte aucune accélération — le surcoût de coordination l'emporte et le speedup réel reste sous 1×, loin de l'idéal linéaire : -[![Parallélisation CP-SAT sur N-Queens 12 : temps de résolution et speedup restant sous 1x avec 1, 2 puis 4 workers](assets/readme/csp6-lazy-clause-generation.png)](CSP-6-Hybridization.html) +[![Parallélisation CP-SAT sur N-Queens 12 : temps de résolution et speedup restant sous 1x avec 1, 2 puis 4 workers](assets/readme/csp6-lazy-clause-generation.png)](CSP-6-Hybridization.ipynb) Les trois derniers notebooks desserrent chacun une hypothèse du cadre classique : et si toutes les contraintes n'avaient pas le même poids (CSP-7, contraintes souples) ? Et si les variables étaient des intervalles de temps (CSP-8, algèbre d'Allen) ? Et si personne ne détenait le problème en entier (CSP-9, résolution distribuée et préservation de la vie privée) ? L'algèbre d'Allen (CSP-8) donne le vocabulaire de ce temps qualitatif : treize relations de base entre deux intervalles. La figure extraite du notebook n'en rend toutefois **que cinq visibles** (before, meets, overlaps, during, equals) — le tracé des huit autres vignettes est défaillant dans la sortie actuelle du notebook ; limitation illustrative assumée, en attendant une correction du tracé et une ré-exécution : -[![Relations d'Allen entre deux intervalles : rendu partiel, 5 des 13 vignettes tracées (before, meets, overlaps, during, equals)](assets/readme/csp8-allen-algebra.png)](CSP-8-Temporal.html) +[![Relations d'Allen entre deux intervalles : rendu partiel, 5 des 13 vignettes tracées (before, meets, overlaps, during, equals)](assets/readme/csp8-allen-algebra.png)](CSP-8-Temporal.ipynb) *Figures : sorties d'exécution réelles extraites des notebooks (non régénérées, règle C.3), downscalées ≤1200 px / ≤200 ko (EPIC #5654) — provenance détaillée dans [`assets/readme/MANIFEST.md`](assets/readme/MANIFEST.md).* @@ -54,15 +54,15 @@ Si la Partie 1 enseigne à chercher, celle-ci enseigne à modéliser — et c'es | # | Notebook | Kernel | Contenu | Durée | |---|----------|--------|---------|-------| -| 1 | [CSP-1-Fundamentals](CSP-1-Fundamentals.html) | Python 3 | Modèle CSP (X, D, C), backtracking, heuristiques MRV et LCV | ~50 min | -| 2 | [CSP-2-Consistency](CSP-2-Consistency.html) | Python 3 | AC-3, Forward Checking, MAC : propagation de contraintes | ~45 min | -| 3 | [CSP-3-Advanced](CSP-3-Advanced.html) | Python 3 | Contraintes globales OR-Tools : AllDifferent, Cumulative, Circuit, LNS | ~50 min | -| 4 | [CSP-4-Scheduling](CSP-4-Scheduling.html) | Python 3 | Job-Shop (JSSP), RCPSP, Nurse Scheduling, IntervalVar, NoOverlap | ~1h | -| 5 | [CSP-5-Optimization](CSP-5-Optimization.html) | Python 3 | Bin Packing, Knapsack, Cutting Stock, Portfolio Optimization | ~1h | -| 6 | [CSP-6-Hybridization](CSP-6-Hybridization.html) | Python 3 | Lazy Clause Generation (LCG), CP+SAT, CP+ML, LLM+CSP | ~1h30 | -| 7 | [CSP-7-Soft](CSP-7-Soft.html) | Python 3 | Contraintes souples : Fuzzy CSP, Weighted CSP, Semiring-based CSP | ~1h | -| 8 | [CSP-8-Temporal](CSP-8-Temporal.html) | Python 3 | Algèbre d'intervalles d'Allen, Simple Temporal Problems (STP), TCSP | ~1h | -| 9 | [CSP-9-Distributed](CSP-9-Distributed.html) | Python 3 | Asynchronous Backtracking (ABT), AWC, Privacy-preserving CSP | ~1h30 | +| 1 | [CSP-1-Fundamentals](CSP-1-Fundamentals.ipynb) | Python 3 | Modèle CSP (X, D, C), backtracking, heuristiques MRV et LCV | ~50 min | +| 2 | [CSP-2-Consistency](CSP-2-Consistency.ipynb) | Python 3 | AC-3, Forward Checking, MAC : propagation de contraintes | ~45 min | +| 3 | [CSP-3-Advanced](CSP-3-Advanced.ipynb) | Python 3 | Contraintes globales OR-Tools : AllDifferent, Cumulative, Circuit, LNS | ~50 min | +| 4 | [CSP-4-Scheduling](CSP-4-Scheduling.ipynb) | Python 3 | Job-Shop (JSSP), RCPSP, Nurse Scheduling, IntervalVar, NoOverlap | ~1h | +| 5 | [CSP-5-Optimization](CSP-5-Optimization.ipynb) | Python 3 | Bin Packing, Knapsack, Cutting Stock, Portfolio Optimization | ~1h | +| 6 | [CSP-6-Hybridization](CSP-6-Hybridization.ipynb) | Python 3 | Lazy Clause Generation (LCG), CP+SAT, CP+ML, LLM+CSP | ~1h30 | +| 7 | [CSP-7-Soft](CSP-7-Soft.ipynb) | Python 3 | Contraintes souples : Fuzzy CSP, Weighted CSP, Semiring-based CSP | ~1h | +| 8 | [CSP-8-Temporal](CSP-8-Temporal.ipynb) | Python 3 | Algèbre d'intervalles d'Allen, Simple Temporal Problems (STP), TCSP | ~1h | +| 9 | [CSP-9-Distributed](CSP-9-Distributed.ipynb) | Python 3 | Asynchronous Backtracking (ABT), AWC, Privacy-preserving CSP | ~1h30 | ### Parité Python ⇄ .NET @@ -70,15 +70,15 @@ Les neuf notebooks de cette partie existent en **binôme bilingue** : une versio | # | Python (OR-Tools CP-SAT) | .NET (C#) | Solveur .NET | |---|--------------------------|-----------|--------------| -| 1 | [CSP-1-Fundamentals](CSP-1-Fundamentals.html) | [CSP-1-Fundamentals-CSharp](CSP-1-Fundamentals-CSharp.html) | Choco-solver via IKVM | -| 2 | [CSP-2-Consistency](CSP-2-Consistency.html) | [CSP-2-Consistency-CSharp](CSP-2-Consistency-CSharp.html) | Choco-solver via IKVM (propagation native) | -| 3 | [CSP-3-Advanced](CSP-3-Advanced.html) | [CSP-3-Advanced-CSharp](CSP-3-Advanced-CSharp.ipynb) | Choco-solver via IKVM | -| 4 | [CSP-4-Scheduling](CSP-4-Scheduling.html) | [CSP-4-Scheduling-CSharp](CSP-4-Scheduling-CSharp.html) | OR-Tools CP-SAT natif (+ section Choco comparative) | -| 5 | [CSP-5-Optimization](CSP-5-Optimization.html) | [CSP-5-Optimization-CSharp](CSP-5-Optimization-CSharp.html) | Choco-solver via IKVM (contrainte globale `binPacking`) | -| 6 | [CSP-6-Hybridization](CSP-6-Hybridization.html) | [CSP-6-Hybridization-CSharp](CSP-6-Hybridization-CSharp.html) | OR-Tools CP-SAT natif (LCG, CP+SAT) | -| 7 | [CSP-7-Soft](CSP-7-Soft.html) | [CSP-7-Soft-CSharp](CSP-7-Soft-CSharp.html) | Choco-solver via IKVM (réification `reifyWith` / `ifThen`) | -| 8 | [CSP-8-Temporal](CSP-8-Temporal.html) | [CSP-8-Temporal-CSharp](CSP-8-Temporal-CSharp.html) | OR-Tools CP-SAT natif (IntervalVar temporels) | -| 9 | [CSP-9-Distributed](CSP-9-Distributed.html) | [CSP-9-Distributed-CSharp](CSP-9-Distributed-CSharp.html) | ABT multi-agent (port from scratch, Yokoo 1992) | +| 1 | [CSP-1-Fundamentals](CSP-1-Fundamentals.ipynb) | [CSP-1-Fundamentals-CSharp](CSP-1-Fundamentals-CSharp.ipynb) | Choco-solver via IKVM | +| 2 | [CSP-2-Consistency](CSP-2-Consistency.ipynb) | [CSP-2-Consistency-CSharp](CSP-2-Consistency-CSharp.ipynb) | Choco-solver via IKVM (propagation native) | +| 3 | [CSP-3-Advanced](CSP-3-Advanced.ipynb) | [CSP-3-Advanced-CSharp](CSP-3-Advanced-CSharp.ipynb) | Choco-solver via IKVM | +| 4 | [CSP-4-Scheduling](CSP-4-Scheduling.ipynb) | [CSP-4-Scheduling-CSharp](CSP-4-Scheduling-CSharp.ipynb) | OR-Tools CP-SAT natif (+ section Choco comparative) | +| 5 | [CSP-5-Optimization](CSP-5-Optimization.ipynb) | [CSP-5-Optimization-CSharp](CSP-5-Optimization-CSharp.ipynb) | Choco-solver via IKVM (contrainte globale `binPacking`) | +| 6 | [CSP-6-Hybridization](CSP-6-Hybridization.ipynb) | [CSP-6-Hybridization-CSharp](CSP-6-Hybridization-CSharp.ipynb) | OR-Tools CP-SAT natif (LCG, CP+SAT) | +| 7 | [CSP-7-Soft](CSP-7-Soft.ipynb) | [CSP-7-Soft-CSharp](CSP-7-Soft-CSharp.ipynb) | Choco-solver via IKVM (réification `reifyWith` / `ifThen`) | +| 8 | [CSP-8-Temporal](CSP-8-Temporal.ipynb) | [CSP-8-Temporal-CSharp](CSP-8-Temporal-CSharp.ipynb) | OR-Tools CP-SAT natif (IntervalVar temporels) | +| 9 | [CSP-9-Distributed](CSP-9-Distributed.ipynb) | [CSP-9-Distributed-CSharp](CSP-9-Distributed-CSharp.ipynb) | ABT multi-agent (port from scratch, Yokoo 1992) | > **Quel solveur .NET pour quel terrain ?** CSP-4 (ordonnancement `IntervalVar`, `NoOverlap`, `Cumulative`), CSP-6 (Lazy Clause Generation, CP+SAT) et CSP-8 (intervalles temporels) sont routés vers **OR-Tools CP-SAT natif** — le terrain où CP-SAT excelle, cf. *vrai outil SOTA pour le problème* (#3801). Les binômes 1, 2, 3, 5 et 7 illustrent **Choco via IKVM** comme levier de parité .NET pour une lib Java — y compris `binPacking`, contrainte globale dont la propagation surpasse la linéarisation BoolVar manuelle. CSP-9 (DisCSP) n'a pas de solveur off-the-shelf : l'algorithme ABT (Yokoo 1992) y est porté **from scratch** en C# multi-agent. @@ -101,7 +101,7 @@ flowchart LR SOCLE --> IND ``` -Les notebooks CSP présupposent les bases de la Partie 1 : formalisation en espace d'états ([Search-1](../Part1-Foundations/Search-01-StateSpace.html)) et backtracking ([Search-2](../Part1-Foundations/Search-02-Uninformed.html)). +Les notebooks CSP présupposent les bases de la Partie 1 : formalisation en espace d'états ([Search-1](../Part1-Foundations/Search-01-StateSpace.ipynb)) et backtracking ([Search-2](../Part1-Foundations/Search-02-Uninformed.ipynb)). ## Prérequis & environnement @@ -125,8 +125,8 @@ Pour le setup complet, voir le [README de la série Search](../README.md). ## Ponts vers SymbolicAI Les notebooks CSP nécessitent une compréhension préalable de : -- **[Search-1 (StateSpace)](../Part1-Foundations/Search-01-StateSpace.html)** : formalisation des problèmes -- **[Search-2 (Uninformed)](../Part1-Foundations/Search-02-Uninformed.html)** : backtracking = DFS avec retour arrière +- **[Search-1 (StateSpace)](../Part1-Foundations/Search-01-StateSpace.ipynb)** : formalisation des problèmes +- **[Search-2 (Uninformed)](../Part1-Foundations/Search-02-Uninformed.ipynb)** : backtracking = DFS avec retour arrière ## Progression recommandée @@ -217,7 +217,7 @@ Le véritable enseignement est une **sensibilité à la modélisation** : le mê - **Les applications** : les [40 notebooks d'application](../Applications/README.md) (N-Queens, Nurse Scheduling, VRP, TSP, Picross, Minesweeper CSP) mettent en pratique CP-SAT sur des problèmes concrets avec benchmark baseline-comparison. - **Vers le raisonnement symbolique** : la modélisation déclarative de cette partie est le premier contact avec un mode de raisonnement qu'approfondissent [Z3/SMT](../../SymbolicAI/SMT/Z3-Linq2Z3/README.md) (SMT solving), les [Planners](../../SymbolicAI/Planners/) (PDDL, HTN) et [Tweety](../../SymbolicAI/Tweety/) (logique formelle) côté SymbolicAI. CSP-6 (LCG) fait explicitement le pont vers SAT. -- **Retour aux fondamentaux** : après avoir vu la puissance de la propagation, reprendre [Search-2 (backtracking)](../Part1-Foundations/Search-02-Uninformed.html) — le DFS y apparaît comme un cas particulier de CSP sans propagation, et l'on mesure le saut qu'apportent AC-3/MAC. +- **Retour aux fondamentaux** : après avoir vu la puissance de la propagation, reprendre [Search-2 (backtracking)](../Part1-Foundations/Search-02-Uninformed.ipynb) — le DFS y apparaît comme un cas particulier de CSP sans propagation, et l'on mesure le saut qu'apportent AC-3/MAC. - **La série dans son ensemble** : le [sommaire Search](../README.md) cartographie les quatre parties et les applications — celle-ci est le socle déclaratif qui prolonge la Partie 1 (recherche) et prépare la Partie 4 (métaheuristiques) et les Applications. ### Le fil rouge diff --git a/MyIA.AI.Notebooks/Search/Part5-Frontieres/README.md b/MyIA.AI.Notebooks/Search/Part5-Frontieres/README.md index ebb8445dca..ccc9e35a8d 100644 --- a/MyIA.AI.Notebooks/Search/Part5-Frontieres/README.md +++ b/MyIA.AI.Notebooks/Search/Part5-Frontieres/README.md @@ -22,16 +22,16 @@ Dix carnets qui ne traitent pas un problème classique pour l'apprendre — ils | # | Notebook | Durée | Contenu | Source | |---|----------|-------|---------|--------| -| 1 | [Frontieres-01-EdgeColoring-Tutte-Python](Frontieres-01-EdgeColoring-Tutte-Python.html) | ~45 min | Coloration d'arêtes cubiques : Vizing, Petersen, ponts, graphes apex et CP-SAT — vérification empirique d'un théorème récent (arXiv 2608.22870) | Nouveau | -| 2 | [Frontieres-02-Factorio-Balancer-Python](Frontieres-02-Factorio-Balancer-Python.html) | ~35 min | Belt balancer Factorio : MIP continu vs CP-SAT discret sur cas borné, N×N throughput-unlimited | Distillation Venturini 2024 | -| 3 | [Frontieres-03-MAPF-Guarantee-Audit-Python](Frontieres-03-MAPF-Guarantee-Audit-Python.html) | ~60 min | MAPF : validateur indépendant, oracle CP-SAT time-expanded, réfutation OD-A*, arrêt CBS au but, audit des garanties ECBS — distillation PrCon G3 (Matteo Atkinson, Paul Witkowski) | Projet étudiant (PrCon PRs #33/#36/#42) | -| 4 | [Frontieres-04-CombinatorialAuctions-WDP-VCG-Python](Frontieres-04-CombinatorialAuctions-WDP-VCG-Python.html) | ~60 min | Enchères combinatoires : WDP exact CP-SAT vs force brute, langage XOR, budget global, paiements VCG et audit de leurs garanties, contre-exemple de manipulation sous budget matérialisé, forensics `PRICE_SCALE` sur 18 instances CATS — distillation PrCon J2 (Majerczyk, Chartouni, Wangon-Zekou) | Projet étudiant (PrCon PR #26) | -| 5 | [Frontieres-05-CoveringArrays-Guarantee-Audit-Python](Frontieres-05-CoveringArrays-Guarantee-Audit-Python.html) | ~55 min | Covering Arrays : oracle constraint-aware, set cover CP-SAT exact, bornes et baselines IPOG/AETG-like — distillation PrCon H4 (Valérian Pichot) | Projet étudiant (PrCon PR #58) | -| 6 | [Frontieres-06-LearningToBranch-Generalization-Audit-Python](Frontieres-06-LearningToBranch-Generalization-Audit-Python.html) | ~75 min | Learning to branch : dérivation de dom/wdeg, splits groupés, transfert inter-familles, performance intégrée, coût d'inférence et seuil d'amortissement — distillation PrCon G4 (Simon Naulet, Matis Codjia) | Projet étudiant (PrCon PR #46) | -| 7 | [Frontieres-07-SALBP-AssemblyLineBalancing-Audit-Python](Frontieres-07-SALBP-AssemblyLineBalancing-Audit-Python.html) | ~70 min | SALBP-1/2 : CP-SAT, PuLP/CBC et RPW, statuts/incumbents/bornes, identité de benchmark, front Pareto certifié et MMALBP robuste/pondéré — distillation PrCon B1 (Ilias Kalalou, Kaelan Grall) | Projet étudiant (PrCon PR #57) | -| 8 | [Frontieres-08-OrbitalAssembly-Certificate-Audit-Python](Frontieres-08-OrbitalAssembly-Certificate-Audit-Python.html) | ~70 min | Assemblage orbital : physique de Hohmann dans le modèle, auditeur externe, preuve que la scalarisation est exactement lexicographique, comparaison à makespan égal, front d'échange ε-contrainte et sonde en taille **et** en densité — distillation PrCon C4 (Gurvan Estable, Joris Bely, Kévin Lubert) | Projet étudiant (PrCon PR #53) | -| 9 | [Frontieres-09-RCPSP-Max-Feasibility-Bounds-Python](Frontieres-09-RCPSP-Max-Feasibility-Bounds-Python.html) | ~65 min | RCPSP/max : le lag maximal comme arc inverse, faisabilité NP-difficile et son témoin de circuit positif, balayage des trois régimes temporel/ressource/réalisable, échelle de bornes certifiées et repli explicite quand la référence externe manque — distillation PrCon B4 (Arthur Gallier, Nicolas Naegelen) | Projet étudiant (PrCon PR #51) | -| 10 | [Frontieres-10-NeuralDiving-Coloration-Python](Frontieres-10-NeuralDiving-Coloration-Python.html) | ~60 min | Neural diving : un plongeur MLP prédit une affectation partielle, injectée comme hint réparable dans CP-SAT ; la médiane des branches recule (2829 → 2325, 25/25 instances améliorées) alors que ≈ 49 % des arêtes du hint violent l'adjacence — cohérence du hint avec les contraintes, pas précision par bit — hommage Nair et al. 2021 | Recherche (Nair et al. 2021) | +| 1 | [Frontieres-01-EdgeColoring-Tutte-Python](Frontieres-01-EdgeColoring-Tutte-Python.ipynb) | ~45 min | Coloration d'arêtes cubiques : Vizing, Petersen, ponts, graphes apex et CP-SAT — vérification empirique d'un théorème récent (arXiv 2608.22870) | Nouveau | +| 2 | [Frontieres-02-Factorio-Balancer-Python](Frontieres-02-Factorio-Balancer-Python.ipynb) | ~35 min | Belt balancer Factorio : MIP continu vs CP-SAT discret sur cas borné, N×N throughput-unlimited | Distillation Venturini 2024 | +| 3 | [Frontieres-03-MAPF-Guarantee-Audit-Python](Frontieres-03-MAPF-Guarantee-Audit-Python.ipynb) | ~60 min | MAPF : validateur indépendant, oracle CP-SAT time-expanded, réfutation OD-A*, arrêt CBS au but, audit des garanties ECBS — distillation PrCon G3 (Matteo Atkinson, Paul Witkowski) | Projet étudiant (PrCon PRs #33/#36/#42) | +| 4 | [Frontieres-04-CombinatorialAuctions-WDP-VCG-Python](Frontieres-04-CombinatorialAuctions-WDP-VCG-Python.ipynb) | ~60 min | Enchères combinatoires : WDP exact CP-SAT vs force brute, langage XOR, budget global, paiements VCG et audit de leurs garanties, contre-exemple de manipulation sous budget matérialisé, forensics `PRICE_SCALE` sur 18 instances CATS — distillation PrCon J2 (Majerczyk, Chartouni, Wangon-Zekou) | Projet étudiant (PrCon PR #26) | +| 5 | [Frontieres-05-CoveringArrays-Guarantee-Audit-Python](Frontieres-05-CoveringArrays-Guarantee-Audit-Python.ipynb) | ~55 min | Covering Arrays : oracle constraint-aware, set cover CP-SAT exact, bornes et baselines IPOG/AETG-like — distillation PrCon H4 (Valérian Pichot) | Projet étudiant (PrCon PR #58) | +| 6 | [Frontieres-06-LearningToBranch-Generalization-Audit-Python](Frontieres-06-LearningToBranch-Generalization-Audit-Python.ipynb) | ~75 min | Learning to branch : dérivation de dom/wdeg, splits groupés, transfert inter-familles, performance intégrée, coût d'inférence et seuil d'amortissement — distillation PrCon G4 (Simon Naulet, Matis Codjia) | Projet étudiant (PrCon PR #46) | +| 7 | [Frontieres-07-SALBP-AssemblyLineBalancing-Audit-Python](Frontieres-07-SALBP-AssemblyLineBalancing-Audit-Python.ipynb) | ~70 min | SALBP-1/2 : CP-SAT, PuLP/CBC et RPW, statuts/incumbents/bornes, identité de benchmark, front Pareto certifié et MMALBP robuste/pondéré — distillation PrCon B1 (Ilias Kalalou, Kaelan Grall) | Projet étudiant (PrCon PR #57) | +| 8 | [Frontieres-08-OrbitalAssembly-Certificate-Audit-Python](Frontieres-08-OrbitalAssembly-Certificate-Audit-Python.ipynb) | ~70 min | Assemblage orbital : physique de Hohmann dans le modèle, auditeur externe, preuve que la scalarisation est exactement lexicographique, comparaison à makespan égal, front d'échange ε-contrainte et sonde en taille **et** en densité — distillation PrCon C4 (Gurvan Estable, Joris Bely, Kévin Lubert) | Projet étudiant (PrCon PR #53) | +| 9 | [Frontieres-09-RCPSP-Max-Feasibility-Bounds-Python](Frontieres-09-RCPSP-Max-Feasibility-Bounds-Python.ipynb) | ~65 min | RCPSP/max : le lag maximal comme arc inverse, faisabilité NP-difficile et son témoin de circuit positif, balayage des trois régimes temporel/ressource/réalisable, échelle de bornes certifiées et repli explicite quand la référence externe manque — distillation PrCon B4 (Arthur Gallier, Nicolas Naegelen) | Projet étudiant (PrCon PR #51) | +| 10 | [Frontieres-10-NeuralDiving-Coloration-Python](Frontieres-10-NeuralDiving-Coloration-Python.ipynb) | ~60 min | Neural diving : un plongeur MLP prédit une affectation partielle, injectée comme hint réparable dans CP-SAT ; la médiane des branches recule (2829 → 2325, 25/25 instances améliorées) alors que ≈ 49 % des arêtes du hint violent l'adjacence — cohérence du hint avec les contraintes, pas précision par bit — hommage Nair et al. 2021 | Recherche (Nair et al. 2021) | ## Prérequis par notebook @@ -52,21 +52,21 @@ Dix carnets qui ne traitent pas un problème classique pour l'apprendre — ils La plupart des carnets prolongent des projets étudiants réalisés dans le cadre de cours d'IA, sans en recopier le code : les références spécifiques sont indiquées dans chaque carnet. -Le [Frontieres-03-MAPF-Guarantee-Audit-Python](Frontieres-03-MAPF-Guarantee-Audit-Python.html) distille le projet PrCon G3 de **Matteo Atkinson** et **Paul Witkowski**, *« Coordination de drones par Multi-Agent Path Finding »*, PRs [PrCon #33](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/33), [#36](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/36) et [#42](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/42). Un rerun frais alimente un validateur et un oracle CP-SAT indépendants ; le notebook distingue trajectoire valide, optimum observé et garantie réellement établie, avec provenance détaillée dans [`data/app24-mapf-audit/SOURCE.md`](data/app24-mapf-audit/SOURCE.md). +Le [Frontieres-03-MAPF-Guarantee-Audit-Python](Frontieres-03-MAPF-Guarantee-Audit-Python.ipynb) distille le projet PrCon G3 de **Matteo Atkinson** et **Paul Witkowski**, *« Coordination de drones par Multi-Agent Path Finding »*, PRs [PrCon #33](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/33), [#36](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/36) et [#42](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/42). Un rerun frais alimente un validateur et un oracle CP-SAT indépendants ; le notebook distingue trajectoire valide, optimum observé et garantie réellement établie, avec provenance détaillée dans [`data/app24-mapf-audit/SOURCE.md`](data/app24-mapf-audit/SOURCE.md). -Le [Frontieres-04-CombinatorialAuctions-WDP-VCG-Python](Frontieres-04-CombinatorialAuctions-WDP-VCG-Python.html) distille le projet PrCon J2 de **Lucas Majerczyk**, **Nabil Chartouni** et **Wilfrid Wangon-Zekou**, *« Enchères combinatoires et Winner Determination »*, PR [PrCon #26](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/26). Le notebook ré-écrit le solveur WDP (CP-SAT, prix entiers milli-unités bout-en-bout) sans importer le package `wdp/` des étudiants ; il re-résout les 18 instances CATS, **matérialise en exécutable** le contre-exemple de manipulation sous budget documenté mais jamais testé dans la source, et audite honnêtement l'écart `PRICE_SCALE` entre les outputs committés et le code au commit source. Données et provenance : [`data/app25-wdp-vcg-audit`](data/app25-wdp-vcg-audit/). +Le [Frontieres-04-CombinatorialAuctions-WDP-VCG-Python](Frontieres-04-CombinatorialAuctions-WDP-VCG-Python.ipynb) distille le projet PrCon J2 de **Lucas Majerczyk**, **Nabil Chartouni** et **Wilfrid Wangon-Zekou**, *« Enchères combinatoires et Winner Determination »*, PR [PrCon #26](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/26). Le notebook ré-écrit le solveur WDP (CP-SAT, prix entiers milli-unités bout-en-bout) sans importer le package `wdp/` des étudiants ; il re-résout les 18 instances CATS, **matérialise en exécutable** le contre-exemple de manipulation sous budget documenté mais jamais testé dans la source, et audite honnêtement l'écart `PRICE_SCALE` entre les outputs committés et le code au commit source. Données et provenance : [`data/app25-wdp-vcg-audit`](data/app25-wdp-vcg-audit/). -Le [Frontieres-05-CoveringArrays-Guarantee-Audit-Python](Frontieres-05-CoveringArrays-Guarantee-Audit-Python.html) distille le projet PrCon H4 de **Valérian Pichot**, *« Covering Arrays »*, PR [PrCon #58](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/58). Sans recopier le générateur étudiant, le notebook reconstruit un oracle indépendant, un set cover CP-SAT exact et deux baselines approchées ; il reproduit surtout le faux verdict d'un validateur qui exige des interactions sémantiquement impossibles, puis le répare par un univers constraint-aware. Provenance : [`data/app26-covering-arrays-audit/SOURCE.md`](data/app26-covering-arrays-audit/SOURCE.md). +Le [Frontieres-05-CoveringArrays-Guarantee-Audit-Python](Frontieres-05-CoveringArrays-Guarantee-Audit-Python.ipynb) distille le projet PrCon H4 de **Valérian Pichot**, *« Covering Arrays »*, PR [PrCon #58](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/58). Sans recopier le générateur étudiant, le notebook reconstruit un oracle indépendant, un set cover CP-SAT exact et deux baselines approchées ; il reproduit surtout le faux verdict d'un validateur qui exige des interactions sémantiquement impossibles, puis le répare par un univers constraint-aware. Provenance : [`data/app26-covering-arrays-audit/SOURCE.md`](data/app26-covering-arrays-audit/SOURCE.md). -Le [Frontieres-06-LearningToBranch-Generalization-Audit-Python](Frontieres-06-LearningToBranch-Generalization-Audit-Python.html) distille le projet PrCon G4 de **Simon Naulet** et **Matis Codjia**, *« Apprentissage d'heuristiques de branchement pour solveur CP »*, PR [PrCon #46](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/46). La reproduction est entièrement réécrite : elle remplace le split par lignes par des instances disjointes, ajoute trois transferts leave-one-family-out et compare l'arbre, le temps total et le coût d'inférence à une baseline choisie sur le train uniquement. Elle établit un résultat négatif utile : une imitation locale fidèle ne garantit ni un arbre plus petit ni un solveur plus rapide. Provenance : [`data/app28-learning-to-branch-audit/SOURCE.md`](data/app28-learning-to-branch-audit/SOURCE.md). +Le [Frontieres-06-LearningToBranch-Generalization-Audit-Python](Frontieres-06-LearningToBranch-Generalization-Audit-Python.ipynb) distille le projet PrCon G4 de **Simon Naulet** et **Matis Codjia**, *« Apprentissage d'heuristiques de branchement pour solveur CP »*, PR [PrCon #46](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/46). La reproduction est entièrement réécrite : elle remplace le split par lignes par des instances disjointes, ajoute trois transferts leave-one-family-out et compare l'arbre, le temps total et le coût d'inférence à une baseline choisie sur le train uniquement. Elle établit un résultat négatif utile : une imitation locale fidèle ne garantit ni un arbre plus petit ni un solveur plus rapide. Provenance : [`data/app28-learning-to-branch-audit/SOURCE.md`](data/app28-learning-to-branch-audit/SOURCE.md). -Le [Frontieres-07-SALBP-AssemblyLineBalancing-Audit-Python](Frontieres-07-SALBP-AssemblyLineBalancing-Audit-Python.html) rend hommage au projet PrCon B1 d'**Ilias Kalalou** et **Kaelan Grall**, *« Équilibrage de chaîne d'assemblage (SALBP) »*, PR [PrCon #57](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/57). Le notebook préserve leur geste central — SALBP-1/2, comparaison CP-SAT/PuLP/RPW, Pareto et multi-modèles — dans une réécriture CoursIA indépendante qui publie statuts, incumbents, bornes, gaps, identité structurelle des instances et validation hors solveur. Aucun code, texte ou figure étudiante n'est copié. Provenance : [`data/app29-salbp-audit/SOURCE.md`](data/app29-salbp-audit/SOURCE.md). +Le [Frontieres-07-SALBP-AssemblyLineBalancing-Audit-Python](Frontieres-07-SALBP-AssemblyLineBalancing-Audit-Python.ipynb) rend hommage au projet PrCon B1 d'**Ilias Kalalou** et **Kaelan Grall**, *« Équilibrage de chaîne d'assemblage (SALBP) »*, PR [PrCon #57](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/57). Le notebook préserve leur geste central — SALBP-1/2, comparaison CP-SAT/PuLP/RPW, Pareto et multi-modèles — dans une réécriture CoursIA indépendante qui publie statuts, incumbents, bornes, gaps, identité structurelle des instances et validation hors solveur. Aucun code, texte ou figure étudiante n'est copié. Provenance : [`data/app29-salbp-audit/SOURCE.md`](data/app29-salbp-audit/SOURCE.md). -Le [Frontieres-08-OrbitalAssembly-Certificate-Audit-Python](Frontieres-08-OrbitalAssembly-Certificate-Audit-Python.html) rend hommage au projet PrCon C4 de **Gurvan Estable**, **Joris Bely** et **Kévin Lubert**, *« Assemblage orbital de satellites »*, PR [PrCon #53](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/53). Le geste distillé est une décision de modélisation : faire descendre la physique dans le modèle, durées issues d'un temps de vol de Hohmann calculé et coûts d'un Δv calculé, les deux contraignant les mêmes intervalles CP-SAT. La reproduction CoursIA est indépendante et volontairement discrétisée autrement, donc non comparable chiffre à chiffre : elle ajoute un auditeur externe qui ne partage aucun état avec les solveurs, la preuve que l'objectif scalarisé `makespan × (B+1) + ergol` est *exactement* lexicographique dès que le budget borne l'ergol — ce que le rapport source qualifiait prudemment d'« approximation » —, une comparaison à makespan égal qui sépare l'inefficacité en ergol d'une heuristique de son retard d'échéancier, un front d'échange ε-contrainte dont chaque point porte son statut, et une sonde qui montre que la taille est un mauvais prédicteur de difficulté. Aucun code, texte ou figure étudiante n'est copié. Provenance : [`data/app30-orbital-assembly-audit/SOURCE.md`](data/app30-orbital-assembly-audit/SOURCE.md). +Le [Frontieres-08-OrbitalAssembly-Certificate-Audit-Python](Frontieres-08-OrbitalAssembly-Certificate-Audit-Python.ipynb) rend hommage au projet PrCon C4 de **Gurvan Estable**, **Joris Bely** et **Kévin Lubert**, *« Assemblage orbital de satellites »*, PR [PrCon #53](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/53). Le geste distillé est une décision de modélisation : faire descendre la physique dans le modèle, durées issues d'un temps de vol de Hohmann calculé et coûts d'un Δv calculé, les deux contraignant les mêmes intervalles CP-SAT. La reproduction CoursIA est indépendante et volontairement discrétisée autrement, donc non comparable chiffre à chiffre : elle ajoute un auditeur externe qui ne partage aucun état avec les solveurs, la preuve que l'objectif scalarisé `makespan × (B+1) + ergol` est *exactement* lexicographique dès que le budget borne l'ergol — ce que le rapport source qualifiait prudemment d'« approximation » —, une comparaison à makespan égal qui sépare l'inefficacité en ergol d'une heuristique de son retard d'échéancier, un front d'échange ε-contrainte dont chaque point porte son statut, et une sonde qui montre que la taille est un mauvais prédicteur de difficulté. Aucun code, texte ou figure étudiante n'est copié. Provenance : [`data/app30-orbital-assembly-audit/SOURCE.md`](data/app30-orbital-assembly-audit/SOURCE.md). -Le [Frontieres-09-RCPSP-Max-Feasibility-Bounds-Python](Frontieres-09-RCPSP-Max-Feasibility-Bounds-Python.html) rend hommage au projet PrCon B4 d'**Arthur Gallier** et **Nicolas Naegelen**, *« RCPSP — ordonnancement de projet sous contraintes de ressources »*, PR [PrCon #51](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/51). Leur rendu a fait ce que [Planners-8-Temporal](../../SymbolicAI/Planners/03-Advanced/Planners-8-Temporal-Csharp.html) laissait explicitement « en exercice » : confronter un solveur à un benchmark public d'ordonnancement. La vérification indépendante conduite pour cette distillation confirme leurs dix makespans, tous recalculés `OPTIMAL` par un modèle réécrit de zéro. Le prolongement CoursIA porte sur ce que leur section RCPSP/max rendait possible sans l'exercer : un lag maximal s'encode par un **arc inverse** qui referme un circuit, la faisabilité elle-même devient NP-difficile (Bartusch, Möhring, Radermacher, 1988), et un circuit de poids strictement positif en est le témoin vérifiable à la main. Le notebook balaye les trois régimes — infaisable temporellement, infaisable par les ressources, réalisable —, mesure que le diagnostic polynomial épargne au solveur le tiers gauche du domaine, et propose une échelle de bornes certifiées comme repli explicite lorsqu'aucune référence externe n'est disponible : le champ `niveau_de_preuve` interdit de confondre un écart à une borne calculée avec un écart à un optimum connu. Aucun code, texte ou figure étudiante n'est copié. Provenance : [`data/app31-rcpsp-max/SOURCE.md`](data/app31-rcpsp-max/SOURCE.md). +Le [Frontieres-09-RCPSP-Max-Feasibility-Bounds-Python](Frontieres-09-RCPSP-Max-Feasibility-Bounds-Python.ipynb) rend hommage au projet PrCon B4 d'**Arthur Gallier** et **Nicolas Naegelen**, *« RCPSP — ordonnancement de projet sous contraintes de ressources »*, PR [PrCon #51](https://github.com/jsboigeEpita/2026-Epita-Programmation-par-Contraintes/pull/51). Leur rendu a fait ce que [Planners-8-Temporal](../../SymbolicAI/Planners/03-Advanced/Planners-8-Temporal-Csharp.ipynb) laissait explicitement « en exercice » : confronter un solveur à un benchmark public d'ordonnancement. La vérification indépendante conduite pour cette distillation confirme leurs dix makespans, tous recalculés `OPTIMAL` par un modèle réécrit de zéro. Le prolongement CoursIA porte sur ce que leur section RCPSP/max rendait possible sans l'exercer : un lag maximal s'encode par un **arc inverse** qui referme un circuit, la faisabilité elle-même devient NP-difficile (Bartusch, Möhring, Radermacher, 1988), et un circuit de poids strictement positif en est le témoin vérifiable à la main. Le notebook balaye les trois régimes — infaisable temporellement, infaisable par les ressources, réalisable —, mesure que le diagnostic polynomial épargne au solveur le tiers gauche du domaine, et propose une échelle de bornes certifiées comme repli explicite lorsqu'aucune référence externe n'est disponible : le champ `niveau_de_preuve` interdit de confondre un écart à une borne calculée avec un écart à un optimum connu. Aucun code, texte ou figure étudiante n'est copié. Provenance : [`data/app31-rcpsp-max/SOURCE.md`](data/app31-rcpsp-max/SOURCE.md). -Le [Frontieres-10-NeuralDiving-Coloration-Python](Frontieres-10-NeuralDiving-Coloration-Python.html) rend hommage au second geste de l'article de Nair et al. (2021), *« Solving Mixed Integer Programs Using Neural Networks »* (arXiv:2012.13349) : le **diving**, qui apprend une solution partielle pour guider un solveur MIP. Frontieres-06 a audité la composante *branching* (politique de branchement apprise) ; Frontieres-10 enchaîne sur l'autre composante : un plongeur MLP prédit une affectation des 60 sommets d'une coloration de graphe, injectée comme `hint` réparable dans OR-Tools CP-SAT, et l'on mesure l'effet sur les branches de preuve. La famille est calibrée pour qu'une fenêtre existe : les set-cover denses s'effondrent au presolve (`nodes = 0`) et les knapsack corrélés ne se prouvent pas en fenêtre notebook ; la coloration 60 sommets / 3 arêtes branche (médiane 2742, 2303-3799 sur les 60 instances d'entraînement) et se prouve (< 0,1 s). Verdict mesuré sur 25 instances de test, sur un run déterministe (`num_workers = 1`) : la médiane des branches recule (2829 → 2325, ≈ −18 %), les 25 instances s'améliorent (gain relatif médian ≈ 15 %, de 8 % à 28 %), et ≈ 49 % des arêtes du hint (44 sur ~90) sont en conflit avec l'adjacence — la cohérence, pas la précision par bit, détermine l'effet du hint. Le notebook ne copie aucun code, donnée, figure ou prose de l'article, archivé au gisement `G:\Mon Drive\MyIA\IA\Bibliographie IA\Search\`. Provenance : [`data/app33-neural-diving/SOURCE.md`](data/app33-neural-diving/SOURCE.md). +Le [Frontieres-10-NeuralDiving-Coloration-Python](Frontieres-10-NeuralDiving-Coloration-Python.ipynb) rend hommage au second geste de l'article de Nair et al. (2021), *« Solving Mixed Integer Programs Using Neural Networks »* (arXiv:2012.13349) : le **diving**, qui apprend une solution partielle pour guider un solveur MIP. Frontieres-06 a audité la composante *branching* (politique de branchement apprise) ; Frontieres-10 enchaîne sur l'autre composante : un plongeur MLP prédit une affectation des 60 sommets d'une coloration de graphe, injectée comme `hint` réparable dans OR-Tools CP-SAT, et l'on mesure l'effet sur les branches de preuve. La famille est calibrée pour qu'une fenêtre existe : les set-cover denses s'effondrent au presolve (`nodes = 0`) et les knapsack corrélés ne se prouvent pas en fenêtre notebook ; la coloration 60 sommets / 3 arêtes branche (médiane 2742, 2303-3799 sur les 60 instances d'entraînement) et se prouve (< 0,1 s). Verdict mesuré sur 25 instances de test, sur un run déterministe (`num_workers = 1`) : la médiane des branches recule (2829 → 2325, ≈ −18 %), les 25 instances s'améliorent (gain relatif médian ≈ 15 %, de 8 % à 28 %), et ≈ 49 % des arêtes du hint (44 sur ~90) sont en conflit avec l'adjacence — la cohérence, pas la précision par bit, détermine l'effet du hint. Le notebook ne copie aucun code, donnée, figure ou prose de l'article, archivé au gisement `G:\Mon Drive\MyIA\IA\Bibliographie IA\Search\`. Provenance : [`data/app33-neural-diving/SOURCE.md`](data/app33-neural-diving/SOURCE.md). ## Ponts inter-séries diff --git a/MyIA.AI.Notebooks/Search/README.md b/MyIA.AI.Notebooks/Search/README.md index 9e50f33f53..6fff99b654 100644 --- a/MyIA.AI.Notebooks/Search/README.md +++ b/MyIA.AI.Notebooks/Search/README.md @@ -123,7 +123,7 @@ Problèmes du monde réel adaptés de projets étudiants. Chaque application est | # | Notebook | Durée | Contenu | Source | |---|----------|-------|---------|--------| -| 1 | [App-14b-ConnectFour](Applications/Search/App-14b-ConnectFour.html) | ~50 min | Puissance 4 : 5 IA au tournoi (Random, Glouton, Minimax α-β d=4/d=6, MCTS) + framework AIMA | Projet étudiant | +| 1 | [App-14b-ConnectFour](Applications/Search/App-14b-ConnectFour.ipynb) | ~50 min | Puissance 4 : 5 IA au tournoi (Random, Glouton, Minimax α-β d=4/d=6, MCTS) + framework AIMA | Projet étudiant | | 1b | [App-14c-ConnectFour-CSharp](Applications/Search/App-14c-ConnectFour-CSharp.ipynb) | ~45 min | **Jumeau C#** — Minimax + Alpha-Beta + MCTS (UCB1) + glouton + iterative deepening from-scratch, heuristique de fenêtres + tournoi round-robin, parité #4956 | Jumeau .NET | | 2 | [App-14-ConnectFour-Adversarial](Applications/Search/App-14-ConnectFour-Adversarial.ipynb) | ~45 min | Benchmark adversarial : Minimax, Alpha-Beta, MCTS | Projet étudiant | | 2b | [App-14-ConnectFour-CSharp](Applications/Search/App-14-ConnectFour-CSharp.ipynb) | ~40 min | **Jumeau C#** — Minimax + Alpha-Beta (élagage) + MCTS (UCB1) from-scratch, benchmark nœuds + tournoi round-robin, parité #4956 | Jumeau .NET | @@ -132,22 +132,22 @@ Problèmes du monde réel adaptés de projets étudiants. Chaque application est | # | Notebook | Durée | Contenu | Source | |---|----------|-------|---------|--------| -| 1 | [App-1-NQueens](Applications/CSP/App-1-NQueens.html) | ~30 min | Benchmark classique CSP : backtracking, min-conflicts, OR-Tools | Classique | -| 2 | [App-2-GraphColoring](Applications/CSP/App-2-GraphColoring.html) | ~45 min | Coloration de cartes : Greedy, DSATUR, CP-SAT, départements français | Projet étudiant | -| 3 | [App-3-NurseScheduling](Applications/CSP/App-3-NurseScheduling.html) | ~60 min | Planning infirmiers : contraintes hard/soft, OR-Tools CP-SAT | Projet étudiant | -| 4 | [App-4-JobShopScheduling](Applications/CSP/App-4-JobShopScheduling.html) | ~60 min | Ordonnancement industriel : intervalles, précédences, makespan | Projet étudiant | -| 5 | [App-5-Timetabling](Applications/CSP/App-5-Timetabling.html) | ~50 min | Emploi du temps universitaire : MiniZinc + OR-Tools | Projet étudiant | -| 6 | [App-6-Minesweeper](Applications/CSP/App-6-Minesweeper.html) | ~50 min | Démineur CSP : propagation, probabilités, hybride CSP+LLM | Projet étudiant | -| 7 | [App-7-Wordle](Applications/CSP/App-7-Wordle.html) | ~45 min | Solveur Wordle : filtrage CSP + théorie de l'information | Projet étudiant | -| 8 | [App-8-MiniZinc](Applications/CSP/App-8-MiniZinc.html) | ~50 min | Modélisation déclarative : syntaxe MiniZinc, contraintes globales | Nouveau | -| 9 | [App-11-Picross](Applications/CSP/App-11-Picross.html) | ~40 min | Nonogrammes : speedup 27Mx CP-SAT vs naïve | Projet étudiant | -| 10 | [App-15-SportsScheduling](Applications/CSP/App-15-SportsScheduling.html) | ~55 min | Calendrier sportif : contraintes TV, équité, déplacements | Projet étudiant | -| 11 | [App-16-Crossword-CSP](Applications/CSP/App-16-Crossword-CSP.html) | ~45 min | Mots croisés : backtracking, OR-Tools, génération | Projet étudiant | -| 12 | [App-19-ProceduralGeneration-WFC](Applications/CSP/App-19-ProceduralGeneration-WFC.html) | ~45 min | Génération procédurale : Wave Function Collapse via CP-SAT | Projet étudiant | +| 1 | [App-1-NQueens](Applications/CSP/App-1-NQueens.ipynb) | ~30 min | Benchmark classique CSP : backtracking, min-conflicts, OR-Tools | Classique | +| 2 | [App-2-GraphColoring](Applications/CSP/App-2-GraphColoring.ipynb) | ~45 min | Coloration de cartes : Greedy, DSATUR, CP-SAT, départements français | Projet étudiant | +| 3 | [App-3-NurseScheduling](Applications/CSP/App-3-NurseScheduling.ipynb) | ~60 min | Planning infirmiers : contraintes hard/soft, OR-Tools CP-SAT | Projet étudiant | +| 4 | [App-4-JobShopScheduling](Applications/CSP/App-4-JobShopScheduling.ipynb) | ~60 min | Ordonnancement industriel : intervalles, précédences, makespan | Projet étudiant | +| 5 | [App-5-Timetabling](Applications/CSP/App-5-Timetabling.ipynb) | ~50 min | Emploi du temps universitaire : MiniZinc + OR-Tools | Projet étudiant | +| 6 | [App-6-Minesweeper](Applications/CSP/App-6-Minesweeper.ipynb) | ~50 min | Démineur CSP : propagation, probabilités, hybride CSP+LLM | Projet étudiant | +| 7 | [App-7-Wordle](Applications/CSP/App-7-Wordle.ipynb) | ~45 min | Solveur Wordle : filtrage CSP + théorie de l'information | Projet étudiant | +| 8 | [App-8-MiniZinc](Applications/CSP/App-8-MiniZinc.ipynb) | ~50 min | Modélisation déclarative : syntaxe MiniZinc, contraintes globales | Nouveau | +| 9 | [App-11-Picross](Applications/CSP/App-11-Picross.ipynb) | ~40 min | Nonogrammes : speedup 27Mx CP-SAT vs naïve | Projet étudiant | +| 10 | [App-15-SportsScheduling](Applications/CSP/App-15-SportsScheduling.ipynb) | ~55 min | Calendrier sportif : contraintes TV, équité, déplacements | Projet étudiant | +| 11 | [App-16-Crossword-CSP](Applications/CSP/App-16-Crossword-CSP.ipynb) | ~45 min | Mots croisés : backtracking, OR-Tools, génération | Projet étudiant | +| 12 | [App-19-ProceduralGeneration-WFC](Applications/CSP/App-19-ProceduralGeneration-WFC.ipynb) | ~45 min | Génération procédurale : Wave Function Collapse via CP-SAT | Projet étudiant | | 12 (C#) | [App-19-ProceduralGeneration-WFC-CSharp](Applications/CSP/App-19-ProceduralGeneration-WFC-CSharp.ipynb) | ~45 min | Twin C# du 12 : WFC from-scratch (entropie de Shannon + propagation AC-3 + backtracking) (See #4956) | Marathon | -| 13 | [App-20-SudokuBenchmark-Python](Applications/CSP/App-20-SudokuBenchmark-Python.html) | ~50 min | Benchmark 4 solveurs Sudoku (backtracking naïf → optimisé → contraintes) sur banc Easy/Medium/Hard : dénombrement du travail | Synthèse série | -| 13 (C#) | [App-20b-SudokuBenchmark-CSharp](Applications/CSP/App-20b-SudokuBenchmark-CSharp.html) | ~50 min | Twin C# du 13 : mêmes solveurs from-scratch en .NET, comparaison des écosystèmes | Jumeau .NET | -| 16 | [Frontieres-05-CoveringArrays-Guarantee-Audit-Python](Part5-Frontieres/Frontieres-05-CoveringArrays-Guarantee-Audit-Python.html) | ~55 min | Covering Arrays : oracle constraint-aware, set cover CP-SAT exact, bornes et baselines IPOG/AETG-like — distillation PrCon H4 (Valérian Pichot) | Projet étudiant (PrCon PR #58) | +| 13 | [App-20-SudokuBenchmark-Python](Applications/CSP/App-20-SudokuBenchmark-Python.ipynb) | ~50 min | Benchmark 4 solveurs Sudoku (backtracking naïf → optimisé → contraintes) sur banc Easy/Medium/Hard : dénombrement du travail | Synthèse série | +| 13 (C#) | [App-20b-SudokuBenchmark-CSharp](Applications/CSP/App-20b-SudokuBenchmark-CSharp.ipynb) | ~50 min | Twin C# du 13 : mêmes solveurs from-scratch en .NET, comparaison des écosystèmes | Jumeau .NET | +| 16 | [Frontieres-05-CoveringArrays-Guarantee-Audit-Python](Part5-Frontieres/Frontieres-05-CoveringArrays-Guarantee-Audit-Python.ipynb) | ~55 min | Covering Arrays : oracle constraint-aware, set cover CP-SAT exact, bornes et baselines IPOG/AETG-like — distillation PrCon H4 (Valérian Pichot) | Projet étudiant (PrCon PR #58) | Les autres jumeaux C# de la sous-série CSP (N-Queens, GraphColoring, NurseScheduling, JobShop, Timetabling, Minesweeper, Wordle, MiniZinc, Picross, SportsScheduling) suivent le même principe : ré-implémentation .NET du notebook Python de référence, solveurs from-scratch ou OR-Tools natif selon le sujet (marathon #4956). @@ -155,18 +155,18 @@ Les autres jumeaux C# de la sous-série CSP (N-Queens, GraphColoring, NurseSched | # | Notebook | Durée | Contenu | Source | |---|----------|-------|---------|--------| -| 1 | [App-9-EdgeDetection](Applications/Hybrid/App-9-EdgeDetection.html) | ~40 min | Détection de bords par GA : PyGAD, filtres de convolution | Existant (refonte) | -| 2 | [App-9b-EdgeDetection-CSharp](Applications/Hybrid/App-9b-EdgeDetection-CSharp.html) | ~35 min | Side track C# : GeneticSharp pour detection de bords | Existant | -| 3 | [App-10-Portfolio](Applications/Hybrid/App-10-Portfolio.html) | ~40 min | Optimisation de portefeuille : frontière de Pareto, multi-objectif | Existant (refonte) | -| 4 | [App-10b-Portfolio-CSharp](Applications/Hybrid/App-10b-Portfolio-CSharp.html) | ~30 min | Side track C# : GeneticSharp pour portefeuille | Existant | +| 1 | [App-9-EdgeDetection](Applications/Hybrid/App-9-EdgeDetection.ipynb) | ~40 min | Détection de bords par GA : PyGAD, filtres de convolution | Existant (refonte) | +| 2 | [App-9b-EdgeDetection-CSharp](Applications/Hybrid/App-9b-EdgeDetection-CSharp.ipynb) | ~35 min | Side track C# : GeneticSharp pour detection de bords | Existant | +| 3 | [App-10-Portfolio](Applications/Hybrid/App-10-Portfolio.ipynb) | ~40 min | Optimisation de portefeuille : frontière de Pareto, multi-objectif | Existant (refonte) | +| 4 | [App-10b-Portfolio-CSharp](Applications/Hybrid/App-10b-Portfolio-CSharp.ipynb) | ~30 min | Side track C# : GeneticSharp pour portefeuille | Existant | | 5 | [App-13-TSP-Metaheuristics](Applications/Hybrid/App-13-TSP-Metaheuristics.ipynb) | ~50 min | TSP : SA, GA, ACO, OR-Tools routing | Classique | | 6 | [App-13b-TSP-Metaheuristics-CSharp](Applications/Hybrid/App-13b-TSP-Metaheuristics-CSharp.ipynb) | ~45 min | **Jumeau C#** — SA, GA, ACO from-scratch sur le même TSP, parité #4956 | Jumeau .NET | -| 7 | [App-17-VRP-Logistics](Applications/Hybrid/App-17-VRP-Logistics.html) | ~60 min | Vehicle Routing : SA, GA, ACO, CP-SAT | Projet étudiant | +| 7 | [App-17-VRP-Logistics](Applications/Hybrid/App-17-VRP-Logistics.ipynb) | ~60 min | Vehicle Routing : SA, GA, ACO, CP-SAT | Projet étudiant | | 8 | [App-17b-VRP-Logistics-CSharp](Applications/Hybrid/App-17b-VRP-Logistics-CSharp.ipynb) | ~55 min | **Jumeau C#** — VRP métaheuristiques .NET, parité #4956 | Jumeau .NET | | 8b | [App-17b-VRP-Logistics-Python](Applications/Hybrid/App-17b-VRP-Logistics-Python.ipynb) | ~45 min | **Twin Python du b** — VRP métaheuristiques from-scratch (numpy) + vérification OR-Tools, parité #4956 | Jumeau Python | -| 9 | [App-18-HyperparameterTuning](Applications/Hybrid/App-18-HyperparameterTuning.html) | ~40 min | Optimisation ML : Bayésienne, GA, PSO, Optuna | Nouveau | -| 10 | [App-18b-HyperparameterTuning-CSharp](Applications/Hybrid/App-18b-HyperparameterTuning-CSharp.html) | ~35 min | **Jumeau C#** — tuning GA/PSO from-scratch .NET, parité #4956 | Jumeau .NET | -| 11 | [App-18b-HyperparameterTuning-Python](Applications/Hybrid/App-18b-HyperparameterTuning-Python.html) | ~35 min | **Jumeau Python from-scratch** — GP+EI, GA, PSO numpy + pont Optuna, parité #4956 | Jumeau Python | +| 9 | [App-18-HyperparameterTuning](Applications/Hybrid/App-18-HyperparameterTuning.ipynb) | ~40 min | Optimisation ML : Bayésienne, GA, PSO, Optuna | Nouveau | +| 10 | [App-18b-HyperparameterTuning-CSharp](Applications/Hybrid/App-18b-HyperparameterTuning-CSharp.ipynb) | ~35 min | **Jumeau C#** — tuning GA/PSO from-scratch .NET, parité #4956 | Jumeau .NET | +| 11 | [App-18b-HyperparameterTuning-Python](Applications/Hybrid/App-18b-HyperparameterTuning-Python.ipynb) | ~35 min | **Jumeau Python from-scratch** — GP+EI, GA, PSO numpy + pont Optuna, parité #4956 | Jumeau Python | | 12 | [App-22-AlgorithmSelection-Python](Applications/Hybrid/App-22-AlgorithmSelection-Python.ipynb) | ~45 min | Sélection empirique d'algorithmes : 3 jeux, 13 familles conceptuelles / 14 étiquettes mesurées, non-commensurabilité + Pareto + choix sous préférences — hommage PR IS #42 (Théodore Deguest) | Projet étudiant (IS PR #42) | --- @@ -565,8 +565,8 @@ La thèse est puissante et honnêtement présentée : il n'existe pas d'algorith - **Approfondir l'IA symbolique** : [SymbolicAI](../SymbolicAI/README.md) (Z3/SMT, planification PDDL/HTN, logique formelle Tweety) est le prolongement naturel de la Partie 2 — les CSP y deviennent du *satisfiability solving* et la modélisation par contraintes se généralise en raisonnement logique. Plusieurs ponts explicites sont tracés (CSP-3 → Z3, CSP-4 → Planners, CSP-6 → LLM+CSP). - **Élargir aux jeux et à l'apprentissage par renforcement** : [GameTheory](../GameTheory/README.md) (Minimax, MCTS, choix social) et les notebooks RL (MCTS + DQN, AlphaGo) reprennent la recherche adversariale sous l'angle de l'apprentissage — où la valeur des positions n'est plus calculée mais *apprise*. - **Pratiquer sur la couverture exacte** : [Sudoku](../Sudoku/README.md) (DLX, automates symboliques) applique Dancing Links et les techniques de cette série à une famille de puzzles combinatoires concrets. -- **Construire plutôt qu'utiliser** : la [Partie 4 — métaheuristiques composables](Part4-Metaheuristics/README.md) (C# .NET 9, MetaGeneticSharp) prolonge [Search-5](Part1-Foundations/Search-05-GeneticAlgorithms.html)/[Search-11](Part1-Foundations/Search-11-Metaheuristics.html) sous l'angle de l'*ingénierie* — au lieu d'importer WOA ou EO, on les *reconstruit* depuis des primitives composables (`Match`, `Container`, grammaire fluente) au-dessus de GeneticSharp, et l'on assemble des configurations qu'aucune bibliothèque monolithique n'offre (sous-populations spécialisées, îles migratoires). -- Pour la pratique : reprenez [CSP-6-Hybridization](Part2-CSP/CSP-6-Hybridization.html) et expérimentez le pont LLM+CSP — comment un modèle de langage peut-il *amorçer* un solveur par contraintes, et où cette hybridation gagne-t-elle (ou perd-elle) par rapport au CP-SAT pur ? +- **Construire plutôt qu'utiliser** : la [Partie 4 — métaheuristiques composables](Part4-Metaheuristics/README.md) (C# .NET 9, MetaGeneticSharp) prolonge [Search-5](Part1-Foundations/Search-05-GeneticAlgorithms.ipynb)/[Search-11](Part1-Foundations/Search-11-Metaheuristics.ipynb) sous l'angle de l'*ingénierie* — au lieu d'importer WOA ou EO, on les *reconstruit* depuis des primitives composables (`Match`, `Container`, grammaire fluente) au-dessus de GeneticSharp, et l'on assemble des configurations qu'aucune bibliothèque monolithique n'offre (sous-populations spécialisées, îles migratoires). +- Pour la pratique : reprenez [CSP-6-Hybridization](Part2-CSP/CSP-6-Hybridization.ipynb) et expérimentez le pont LLM+CSP — comment un modèle de langage peut-il *amorçer* un solveur par contraintes, et où cette hybridation gagne-t-elle (ou perd-elle) par rapport au CP-SAT pur ? ### Le fil rouge @@ -590,7 +590,7 @@ Le hub Search alignait une riche prose sur la double approche *exploration syst | QC | `kelly_lean` (#5047) | Kelly criterion + mean-variance bound | [QC-Py-10-Risk-Portfolio-Management](../QuantConnect/Python/QC-Py-10-Risk-Portfolio-Management.ipynb) (Kelly sizing) | | GameTheory | `game_theory_lean/SocialChoice` (lakes standalone `social_choice_lean` #5050 + `cooperative_games_lean` absorbés post-#4365, contenue dans `game_theory_lean/`) | Arrow + Sen voting | [GameTheory-15-CooperativeGames-Python](../GameTheory/GameTheory-15-CooperativeGames-Python.ipynb) | | GameTheory | `game_theory_lean/CooperativeGames/Shapley.lean` (lake `cooperative_games_lean` supprimé post-#4365, contenu absorbé) | Bondareva-Shapley 0 sorry #3954 | [GameTheory-13-ImperfectInfo-CFR-Python](../GameTheory/GameTheory-13-ImperfectInfo-CFR-Python.ipynb) | -| SymbolicAI | `argumentation_lean` (#5043 MERGED) | Tweety Preferred extensions + Dung framework | [Tweety-03-Dung-CSharp](../SymbolicAI/Tweety/Tweety-03-Dung-CSharp.html) (Dung Preferred semantics) | +| SymbolicAI | `argumentation_lean` (#5043 MERGED) | Tweety Preferred extensions + Dung framework | [Tweety-03-Dung-CSharp](../SymbolicAI/Tweety/Tweety-03-Dung-CSharp.ipynb) (Dung Preferred semantics) | ```mermaid flowchart LR diff --git a/MyIA.AI.Notebooks/Search/search_lean/README.md b/MyIA.AI.Notebooks/Search/search_lean/README.md index 06bda7651a..144c1e42fd 100644 --- a/MyIA.AI.Notebooks/Search/search_lean/README.md +++ b/MyIA.AI.Notebooks/Search/search_lean/README.md @@ -26,7 +26,7 @@ la propriété qui distingue A* d'une simple recherche en largeur. Le notebook compagnon historique [`Exploration_non_informée_et_informée_intro.ipynb`](../_archive/Exploration_non_informée_et_informée_intro.ipynb) (archivé en 2026-07-03, tranche 8/8 du plan #5081) puis ses successeurs officiels -[`Search-02-Uninformed.ipynb`](../Part1-Foundations/Search-02-Uninformed.html) +[`Search-02-Uninformed.ipynb`](../Part1-Foundations/Search-02-Uninformed.ipynb) et [`Search-03-Informed.ipynb`](../Part1-Foundations/Search-03-Informed.ipynb) illustrent ceci en Python sur un terrain pondéré où A* exploite l'heuristique pour explorer moins de nœuds que BFS. @@ -193,7 +193,7 @@ flowchart TD Le module [`Szpiro.lean`](Szpiro.lean) (miroir EN : [`Szpiro_en.lean`](Szpiro_en.lean)) est le sibling Lean du carnet -[`App-32-Szpiro-Pasten-2026.ipynb`](../Applications/Search/App-32-Szpiro-Pasten-2026.html) : +[`App-32-Szpiro-Pasten-2026.ipynb`](../Applications/Search/App-32-Szpiro-Pasten-2026.ipynb) : Pasten 2026, *Improved Bounds for Szpiro's Conjecture* (arXiv 2609.17390) rend la borne `h(E) ≪ N·log log N` **inconditionnelle** — elle était connue sous GRH — et prouve `h(E) ≪_S N` pour les courbes semistables hors d'un ensemble fini. @@ -242,6 +242,6 @@ Phases suivantes (suivi #4048) : of Minimum Cost Paths*, IEEE Trans. Syst. Sci. Cybern. **4**(2), 1968. - H. Pasten, *Improved Bounds for Szpiro's Conjecture*, arXiv 2609.17390 (2026), archivé `G:\Mon Drive\MyIA\IA\Bibliographie IA\NumberTheory\` — carnet compagnon - [`App-32-Szpiro-Pasten-2026.ipynb`](../Applications/Search/App-32-Szpiro-Pasten-2026.html). + [`App-32-Szpiro-Pasten-2026.ipynb`](../Applications/Search/App-32-Szpiro-Pasten-2026.ipynb). - S. Russell, P. Norvig, *Artificial Intelligence: A Modern Approach*, §3.5 (A* Search). -- Notebooks compagnons : [`Search-02-Uninformed.ipynb`](../Part1-Foundations/Search-02-Uninformed.html), [`Search-03-Informed.ipynb`](../Part1-Foundations/Search-03-Informed.ipynb) (le notebook historique [`Exploration_non_informée_et_informée_intro.ipynb`](../_archive/Exploration_non_informée_et_informée_intro.ipynb) est archivé depuis 2026-07-03). +- Notebooks compagnons : [`Search-02-Uninformed.ipynb`](../Part1-Foundations/Search-02-Uninformed.ipynb), [`Search-03-Informed.ipynb`](../Part1-Foundations/Search-03-Informed.ipynb) (le notebook historique [`Exploration_non_informée_et_informée_intro.ipynb`](../_archive/Exploration_non_informée_et_informée_intro.ipynb) est archivé depuis 2026-07-03). diff --git a/MyIA.AI.Notebooks/SymbolicAI/Tweety/README.md b/MyIA.AI.Notebooks/SymbolicAI/Tweety/README.md index 2cc2f6916f..7a11ddc3c5 100644 --- a/MyIA.AI.Notebooks/SymbolicAI/Tweety/README.md +++ b/MyIA.AI.Notebooks/SymbolicAI/Tweety/README.md @@ -172,18 +172,18 @@ Numéros nus uniquement, lisibles de haut en bas. Le compte et la maturité exac | # | Notebook | Ce qu'on y apprend | Stack | |---|----------|--------------------|-------| -| 1 | [Tweety-01-Setup-Python](Tweety-01-Setup-Python.html) | Configuration JVM, JARs, solveurs externes | Python | -| 2 | [Tweety-02-Basic-Logics-Python](Tweety-02-Basic-Logics-Python.html) | Logique propositionnelle (SAT) et du premier ordre (FOL) | Python | -| 3 | [Tweety-03-Advanced-Logics-Python](Tweety-03-Advanced-Logics-Python.html) | DL, Modale, QBF, Conditionnelle | Python | -| 4 | [Tweety-04-Belief-Revision-Python](Tweety-04-Belief-Revision-Python.html) | MUS, MaxSAT, Mesures d'incohérence, AGM | Python | -| 5 | [Tweety-05-Abstract-Argumentation-Python](Tweety-05-Abstract-Argumentation-Python.html) | Dung AF, sémantiques grounded/stable/CF2 | Python | -| 6 | [Tweety-06-Structured-Argumentation-Python](Tweety-06-Structured-Argumentation-Python.html) | ASPIC+, DeLP, ABA, ASP | Python | -| 7 | [Tweety-07a-Extended-Frameworks-Python](Tweety-07a-Extended-Frameworks-Python.html) | ADF, Bipolar, WAF, SAF, SetAF, Extended | Python | -| 8 | [Tweety-08-Agent-Dialogues-Python](Tweety-08-Agent-Dialogues-Python.html) | Agents, dialogues argumentatifs, loteries | Python | -| 9 | [Tweety-09-Preferences-Python](Tweety-09-Preferences-Python.html) | Préférences, théorie du vote | Python | -| 10 | [Tweety-10-MLN-Python](Tweety-10-MLN-Python.html) | Markov Logic Networks (FOL pondérée) | Python | -| 11 | [Tweety-11-Causal-Python](Tweety-11-Causal-Python.html) | do-calculus de Pearl, interventions, contrefactuels | Python | -| 12 | [Tweety-12-Grounded-Via-TweetyProject-Python](Tweety-12-Grounded-Via-TweetyProject-Python.html) | Bouclage de la sémantique grounded entre Python et Lean | Python | +| 1 | [Tweety-01-Setup-Python](Tweety-01-Setup-Python.ipynb) | Configuration JVM, JARs, solveurs externes | Python | +| 2 | [Tweety-02-Basic-Logics-Python](Tweety-02-Basic-Logics-Python.ipynb) | Logique propositionnelle (SAT) et du premier ordre (FOL) | Python | +| 3 | [Tweety-03-Advanced-Logics-Python](Tweety-03-Advanced-Logics-Python.ipynb) | DL, Modale, QBF, Conditionnelle | Python | +| 4 | [Tweety-04-Belief-Revision-Python](Tweety-04-Belief-Revision-Python.ipynb) | MUS, MaxSAT, Mesures d'incohérence, AGM | Python | +| 5 | [Tweety-05-Abstract-Argumentation-Python](Tweety-05-Abstract-Argumentation-Python.ipynb) | Dung AF, sémantiques grounded/stable/CF2 | Python | +| 6 | [Tweety-06-Structured-Argumentation-Python](Tweety-06-Structured-Argumentation-Python.ipynb) | ASPIC+, DeLP, ABA, ASP | Python | +| 7 | [Tweety-07a-Extended-Frameworks-Python](Tweety-07a-Extended-Frameworks-Python.ipynb) | ADF, Bipolar, WAF, SAF, SetAF, Extended | Python | +| 8 | [Tweety-08-Agent-Dialogues-Python](Tweety-08-Agent-Dialogues-Python.ipynb) | Agents, dialogues argumentatifs, loteries | Python | +| 9 | [Tweety-09-Preferences-Python](Tweety-09-Preferences-Python.ipynb) | Préférences, théorie du vote | Python | +| 10 | [Tweety-10-MLN-Python](Tweety-10-MLN-Python.ipynb) | Markov Logic Networks (FOL pondérée) | Python | +| 11 | [Tweety-11-Causal-Python](Tweety-11-Causal-Python.ipynb) | do-calculus de Pearl, interventions, contrefactuels | Python | +| 12 | [Tweety-12-Grounded-Via-TweetyProject-Python](Tweety-12-Grounded-Via-TweetyProject-Python.ipynb) | Bouclage de la sémantique grounded entre Python et Lean | Python | **Durée indicative du parcours léger** : environ 13 h pour les notebooks racine Python. Le parcours **s'arrête où vous voulez** : le palier 5 (argumentation abstraite) ou le palier 6 (argumentation structurée) se suffisent à eux-mêmes pour qui ne vise que la modélisation du raisonnement. @@ -195,45 +195,45 @@ Une section par palier qui ouvre des lettres. Chaque lettre est **facultative** | Lettre | Notebook | Ce que cette lettre ajoute | |---|---|---| -| 02a | [Tweety-02-Basic-Logics-CSharp](Tweety-02-Basic-Logics-CSharp.html) | Jumeau C#/.NET du 02 (IKVM, **port pilote** #4792, premier pont Java→.NET de la série) | -| 02b | [Tweety-02b-Semantics-CSharp](Tweety-02b-Semantics-CSharp.html) | Sémantique propositionnelle .NET (mondes possibles) | -| 02c | [Tweety-02c-FOL-CSharp](Tweety-02c-FOL-CSharp.html) | FOL porté .NET via IKVM 8.15.0 (`tweetyproject.logics.fol.*` réel, DLL `tweety-pl` référençant `IKVM.Runtime` 8.15.0) | -| 02d | [Tweety-02d-FOL-Lab-Lean-Python](Tweety-02d-FOL-Lab-Lean-Python.html) | **Labo croisé** (tranche B de l'EPIC #15066) : un même syllogisme exécuté par `SimpleFolReasoner` (six verdicts) et certifié par le noyau Lean sur le corpus **FFL épinglé** — conséquences quantifiées, contre-modèles finis exhibés ; la distinction `FALSE` ≠ « négation prouvée » y est mesurée | -| 02e | [Tweety-02e-Preuves-Hilbert-Gentzen-Lean-Python](Tweety-02e-Preuves-Hilbert-Gentzen-Lean-Python.html) | **Calculs de preuve** (tranche D de l'EPIC #15066) : trois axiomes de Hilbert vérifiés par deux oracles réels, une preuve de Hilbert construite par **chaînage avant** (coût mesuré), puis le calcul des séquents **LK** — hauteur et taille d'un arbre **avant/après** élimination des coupures, le Hauptsatz étant invoqué comme **théorème du noyau** (`Derivation.Canonical.constructiveHauptsatz`, témoin `IsCutFree`) | -| 02f | [Tweety-02f-Modal-Zoo-Lean-Python](Tweety-02f-Modal-Zoo-Lean-Python.html) | **Zoo modal certifié** (tranche G de l'EPIC #15066) : huit systèmes normaux (`K`, `KD`, `KT`, `KTB`, `K4`, `S4`, `KD45`, `S5`) et **l'ordre** qui les relie. Les listes du module `FormalLogic.ModalZoo` ([#17642](https://github.com/jsboige/CoursIA/pull/17642)) sont **exportées** par `lake env lean` (`ModalZoo.toJson`), l'ordre est **recalculé** en Python sur les seuls profils exportés, puis la carte est dessinée : 21 inclusions strictes sur 28 paires du cube, dont 11 arêtes de couverture, et 7 paires **incomparables** — chacune certifiée par le noyau | +| 02a | [Tweety-02-Basic-Logics-CSharp](Tweety-02-Basic-Logics-CSharp.ipynb) | Jumeau C#/.NET du 02 (IKVM, **port pilote** #4792, premier pont Java→.NET de la série) | +| 02b | [Tweety-02b-Semantics-CSharp](Tweety-02b-Semantics-CSharp.ipynb) | Sémantique propositionnelle .NET (mondes possibles) | +| 02c | [Tweety-02c-FOL-CSharp](Tweety-02c-FOL-CSharp.ipynb) | FOL porté .NET via IKVM 8.15.0 (`tweetyproject.logics.fol.*` réel, DLL `tweety-pl` référençant `IKVM.Runtime` 8.15.0) | +| 02d | [Tweety-02d-FOL-Lab-Lean-Python](Tweety-02d-FOL-Lab-Lean-Python.ipynb) | **Labo croisé** (tranche B de l'EPIC #15066) : un même syllogisme exécuté par `SimpleFolReasoner` (six verdicts) et certifié par le noyau Lean sur le corpus **FFL épinglé** — conséquences quantifiées, contre-modèles finis exhibés ; la distinction `FALSE` ≠ « négation prouvée » y est mesurée | +| 02e | [Tweety-02e-Preuves-Hilbert-Gentzen-Lean-Python](Tweety-02e-Preuves-Hilbert-Gentzen-Lean-Python.ipynb) | **Calculs de preuve** (tranche D de l'EPIC #15066) : trois axiomes de Hilbert vérifiés par deux oracles réels, une preuve de Hilbert construite par **chaînage avant** (coût mesuré), puis le calcul des séquents **LK** — hauteur et taille d'un arbre **avant/après** élimination des coupures, le Hauptsatz étant invoqué comme **théorème du noyau** (`Derivation.Canonical.constructiveHauptsatz`, témoin `IsCutFree`) | +| 02f | [Tweety-02f-Modal-Zoo-Lean-Python](Tweety-02f-Modal-Zoo-Lean-Python.ipynb) | **Zoo modal certifié** (tranche G de l'EPIC #15066) : huit systèmes normaux (`K`, `KD`, `KT`, `KTB`, `K4`, `S4`, `KD45`, `S5`) et **l'ordre** qui les relie. Les listes du module `FormalLogic.ModalZoo` ([#17642](https://github.com/jsboige/CoursIA/pull/17642)) sont **exportées** par `lake env lean` (`ModalZoo.toJson`), l'ordre est **recalculé** en Python sur les seuls profils exportés, puis la carte est dessinée : 21 inclusions strictes sur 28 paires du cube, dont 11 arêtes de couverture, et 7 paires **incomparables** — chacune certifiée par le noyau | #### Autour de 03 — logiques avancées : modal et laboratoire | Lettre | Notebook | Ce que cette lettre ajoute | |---|---|---| -| 03b | [Tweety-03b-Modal-Lab-Lean-Python](Tweety-03b-Modal-Lab-Lean-Python.html) | **Labo modal croisé** (tranche C de l'EPIC #15066) : schémas `K`/`T`/`4`/`5` — syntaxe `MlParser` Tweety (bug SPASS #1334 documenté), balayage exhaustif des 512 cadres 3-mondes en Python (correspondances T/réflexif, 4/transitif, 5/euclidien mesurées en égalités exactes), certificats du kernel Lean sur le pont `FormalLogic.ModalBridge` (#17017) | -| 03c-DL | [Tweety-03-Advanced-Logics-CSharp](Tweety-03-Advanced-Logics-CSharp.html) | DL/ML/QBF/CL .NET — **DRAFT** : conflits de noms DLL entre `logics.ml` + `logics.cl` + `logics.qbf` simultanés | -| 03c-CL | [Tweety-03-Conditional-Logics-CSharp](Tweety-03-Conditional-Logics-CSharp.html) | Logique conditionnelle .NET (IKVM) — raisonneur `cl` réel | -| 03c-Dung | [Tweety-03-Dung-CSharp](Tweety-03-Dung-CSharp.html) | Argumentation de Dung .NET (IKVM, c.182 PR #5194) — `NaiveDlReasoner` | -| 03c-ML | [Tweety-03-ModalLogic-CSharp](Tweety-03-ModalLogic-CSharp.html) | Logique modale .NET (IKVM) — `MlReasoner` réel | -| 03c-QBF | [Tweety-03-QBF-CSharp](Tweety-03-QBF-CSharp.html) | QBF .NET (IKVM, c.185 PR #5202) — solveur QBF réel | +| 03b | [Tweety-03b-Modal-Lab-Lean-Python](Tweety-03b-Modal-Lab-Lean-Python.ipynb) | **Labo modal croisé** (tranche C de l'EPIC #15066) : schémas `K`/`T`/`4`/`5` — syntaxe `MlParser` Tweety (bug SPASS #1334 documenté), balayage exhaustif des 512 cadres 3-mondes en Python (correspondances T/réflexif, 4/transitif, 5/euclidien mesurées en égalités exactes), certificats du kernel Lean sur le pont `FormalLogic.ModalBridge` (#17017) | +| 03c-DL | [Tweety-03-Advanced-Logics-CSharp](Tweety-03-Advanced-Logics-CSharp.ipynb) | DL/ML/QBF/CL .NET — **DRAFT** : conflits de noms DLL entre `logics.ml` + `logics.cl` + `logics.qbf` simultanés | +| 03c-CL | [Tweety-03-Conditional-Logics-CSharp](Tweety-03-Conditional-Logics-CSharp.ipynb) | Logique conditionnelle .NET (IKVM) — raisonneur `cl` réel | +| 03c-Dung | [Tweety-03-Dung-CSharp](Tweety-03-Dung-CSharp.ipynb) | Argumentation de Dung .NET (IKVM, c.182 PR #5194) — `NaiveDlReasoner` | +| 03c-ML | [Tweety-03-ModalLogic-CSharp](Tweety-03-ModalLogic-CSharp.ipynb) | Logique modale .NET (IKVM) — `MlReasoner` réel | +| 03c-QBF | [Tweety-03-QBF-CSharp](Tweety-03-QBF-CSharp.ipynb) | QBF .NET (IKVM, c.185 PR #5202) — solveur QBF réel | #### Autour de 04 — belief revision et ASPIC+ | Lettre | Notebook | Ce que cette lettre ajoute | |---|---|---| -| 04c-BR | [Tweety-04-Belief-Revision-CSharp](Tweety-04-Belief-Revision-CSharp.html) | Belief Revision .NET (IKVM) : `Revision`/`MUSMaxSAT` réels | -| 04c-Aspic | [Tweety-04-Aspic-CSharp](Tweety-04-Aspic-CSharp.html) | ASPIC+ .NET (IKVM) — `AspicArgumentation` réel | +| 04c-BR | [Tweety-04-Belief-Revision-CSharp](Tweety-04-Belief-Revision-CSharp.ipynb) | Belief Revision .NET (IKVM) : `Revision`/`MUSMaxSAT` réels | +| 04c-Aspic | [Tweety-04-Aspic-CSharp](Tweety-04-Aspic-CSharp.ipynb) | ASPIC+ .NET (IKVM) — `AspicArgumentation` réel | #### Autour de 05 — argumentation abstraite et compagnons Lean | Lettre | Notebook | Ce que cette lettre ajoute | |---|---|---| -| 05b | [Tweety-05b-Argumentation-Lean](Tweety-05b-Argumentation-Lean.html) | **Compagnon natif** (kernel Lean) : preuve formelle 0-sorry de Dung dans le lake `argumentation_lean` (grounded = point fixe Knaster–Tarski), `#check` + `#print axioms` in-kernel (UNLOCK c.127, jonction Mathlib #2611) | -| 05c | [Tweety-05-Abstract-Argumentation-CSharp](Tweety-05-Abstract-Argumentation-CSharp.html) | Twin C# Dung AF **from-scratch** (BCL .NET, pas IKVM/JVM) : fonction caractéristique, acceptabilité, ensembles admissibles/complets, sémantiques grounded (plus petit point fixe) / stable / preferred, labeling 3 valeurs (in/out/undec), génération aléatoire, 3 exercices | -| 05d | [Tweety-05d-Stable-Synthesis-Lean-Python](Tweety-05d-Stable-Synthesis-Lean-Python.html) | **Synthèse certifiée** d'extensions stables (Loi II #12205, variante `-c`, #13597) : spécification → **Z3** (générateur ≠ vérificateur) → témoin `{1, 2, 5}` → certificat Lean `by decide` dans le lake `argumentation_lean` (module `Argumentation.Synthesis` + sibling `_en`, i18n #4980) ; cas UNSAT du 3-cycle certifié (`afB_no_stable`) | -| 05e | [Tweety-05e-Propositional-Lab-Lean-Python](Tweety-05e-Propositional-Lab-Lean-Python.html) | **Compagnon transversal** (tranche A de l'EPIC #15066) : trois formules-témoins (`SYL` valide, `ORB` satisfiable non valide, `CONTR` insatisfiable) traversent **trois lectures** — Tweety via JPype (verdicts et contre-modèles **calculés**), recomptage Python indépendant des 8 mondes du fragment `{a, b, c}`, certification du kernel Lean natif sur **Foundation (FFL)** au commit épinglé ; la même chaîne de formule est sérialisée pour les deux moteurs (SOTA, aucune réimplémentation jouet) | +| 05b | [Tweety-05b-Argumentation-Lean](Tweety-05b-Argumentation-Lean.ipynb) | **Compagnon natif** (kernel Lean) : preuve formelle 0-sorry de Dung dans le lake `argumentation_lean` (grounded = point fixe Knaster–Tarski), `#check` + `#print axioms` in-kernel (UNLOCK c.127, jonction Mathlib #2611) | +| 05c | [Tweety-05-Abstract-Argumentation-CSharp](Tweety-05-Abstract-Argumentation-CSharp.ipynb) | Twin C# Dung AF **from-scratch** (BCL .NET, pas IKVM/JVM) : fonction caractéristique, acceptabilité, ensembles admissibles/complets, sémantiques grounded (plus petit point fixe) / stable / preferred, labeling 3 valeurs (in/out/undec), génération aléatoire, 3 exercices | +| 05d | [Tweety-05d-Stable-Synthesis-Lean-Python](Tweety-05d-Stable-Synthesis-Lean-Python.ipynb) | **Synthèse certifiée** d'extensions stables (Loi II #12205, variante `-c`, #13597) : spécification → **Z3** (générateur ≠ vérificateur) → témoin `{1, 2, 5}` → certificat Lean `by decide` dans le lake `argumentation_lean` (module `Argumentation.Synthesis` + sibling `_en`, i18n #4980) ; cas UNSAT du 3-cycle certifié (`afB_no_stable`) | +| 05e | [Tweety-05e-Propositional-Lab-Lean-Python](Tweety-05e-Propositional-Lab-Lean-Python.ipynb) | **Compagnon transversal** (tranche A de l'EPIC #15066) : trois formules-témoins (`SYL` valide, `ORB` satisfiable non valide, `CONTR` insatisfiable) traversent **trois lectures** — Tweety via JPype (verdicts et contre-modèles **calculés**), recomptage Python indépendant des 8 mondes du fragment `{a, b, c}`, certification du kernel Lean natif sur **Foundation (FFL)** au commit épinglé ; la même chaîne de formule est sérialisée pour les deux moteurs (SOTA, aucune réimplémentation jouet) | #### Autour de 06 — argumentation structurée et jumeau C# | Lettre | Notebook | Ce que cette lettre ajoute | |---|---|---| -| 06c | [Tweety-06-Structured-Argumentation-CSharp](Tweety-06-Structured-Argumentation-CSharp.html) | Twin C# ASPIC+ from-scratch (BCL, pas IKVM ; DeLP/ABA/ASP conceptuel) | +| 06c | [Tweety-06-Structured-Argumentation-CSharp](Tweety-06-Structured-Argumentation-CSharp.ipynb) | Twin C# ASPIC+ from-scratch (BCL, pas IKVM ; DeLP/ABA/ASP conceptuel) | #### Autour de 07 — cadres étendus et probabilistes @@ -241,23 +241,23 @@ Le palier 07 est porté par le **07a** (Python) et son jumeau **07ac** (C#) ; le | Lettre | Notebook | Ce que cette lettre ajoute | |---|---|---| -| 07ac | [Tweety-07a-Extended-Frameworks-CSharp](Tweety-07a-Extended-Frameworks-CSharp.html) | Twin C# hybride : ADF/SetAF/EAF/VAF from-scratch (BCL, Kleene 3-valued) + tranche 2 lib Tweety réelle via IKVM (DLL shade 7a versionnée à la racine, rebuildable via `dotnet-build/rebuild-7a.sh` ; #4956) | -| 07b | [Tweety-07b-Ranking-Probabilistic-Python](Tweety-07b-Ranking-Probabilistic-Python.html) | Sémantiques de classement (ranking) et argumentation probabiliste | -| 07bc | [Tweety-07b-Ranking-Probabilistic-CSharp](Tweety-07b-Ranking-Probabilistic-CSharp.html) | Jumeau C# du 07b (IKVM, c.179 PR #5231) — `Ranking`, `SubgraphProbability` réels | +| 07ac | [Tweety-07a-Extended-Frameworks-CSharp](Tweety-07a-Extended-Frameworks-CSharp.ipynb) | Twin C# hybride : ADF/SetAF/EAF/VAF from-scratch (BCL, Kleene 3-valued) + tranche 2 lib Tweety réelle via IKVM (DLL shade 7a versionnée à la racine, rebuildable via `dotnet-build/rebuild-7a.sh` ; #4956) | +| 07b | [Tweety-07b-Ranking-Probabilistic-Python](Tweety-07b-Ranking-Probabilistic-Python.ipynb) | Sémantiques de classement (ranking) et argumentation probabiliste | +| 07bc | [Tweety-07b-Ranking-Probabilistic-CSharp](Tweety-07b-Ranking-Probabilistic-CSharp.ipynb) | Jumeau C# du 07b (IKVM, c.179 PR #5231) — `Ranking`, `SubgraphProbability` réels | #### Autour de 08 et 09 — applications multi-agents | Lettre | Notebook | Ce que cette lettre ajoute | |---|---|---| -| 08c | [Tweety-08-Agent-Dialogues-CSharp](Tweety-08-Agent-Dialogues-CSharp.html) | Twin C# dialogues argumentatifs from-scratch (BCL .NET, pas IKVM/JVM ; Dung AF + agents + protocole Claim/Argue/Concede/Retract + loterie argumentative Monte-Carlo) | -| 09c | [Tweety-09-Preferences-CSharp](Tweety-09-Preferences-CSharp.html) | Préférences .NET (IKVM, c.180 PR #5268) | +| 08c | [Tweety-08-Agent-Dialogues-CSharp](Tweety-08-Agent-Dialogues-CSharp.ipynb) | Twin C# dialogues argumentatifs from-scratch (BCL .NET, pas IKVM/JVM ; Dung AF + agents + protocole Claim/Argue/Concede/Retract + loterie argumentative Monte-Carlo) | +| 09c | [Tweety-09-Preferences-CSharp](Tweety-09-Preferences-CSharp.ipynb) | Préférences .NET (IKVM, c.180 PR #5268) | #### Autour de 10 et 11 — synthèse | Lettre | Notebook | Ce que cette lettre ajoute | |---|---|---| -| 10c | [Tweety-10-MLN-CSharp](Tweety-10-MLN-CSharp.html) | MLN porté .NET (IKVM, c.188 PR #5209) — `MarkovLogicNetwork`, vrais appels | -| 11c | [Tweety-11-Causal-CSharp](Tweety-11-Causal-CSharp.html) | Twin C# moteur causal booléen from-scratch .NET : do-operator, contrefactuels par mondes jumeaux | +| 10c | [Tweety-10-MLN-CSharp](Tweety-10-MLN-CSharp.ipynb) | MLN porté .NET (IKVM, c.188 PR #5209) — `MarkovLogicNetwork`, vrais appels | +| 11c | [Tweety-11-Causal-CSharp](Tweety-11-Causal-CSharp.ipynb) | Twin C# moteur causal booléen from-scratch .NET : do-operator, contrefactuels par mondes jumeaux | ### Sous-série Argumentation — Argumentum @@ -343,9 +343,9 @@ La signature du do-calculus — **P(rain | drops) ≠ P(rain | do(drops))** — Tweety raisonne sur le do-calculus en **logique propositionnelle** : `do(X)` y est *qualitatif* — un atome forcé, un SCM réécrit, une réponse vrai/faux. C'est idéal pour *voir* la différence entre `observe` et `do` sans nombres, mais Tweety **ne chiffre pas** un effet causal ni ne lève quantitativement un paradoxe de Simpson. Les séries probabilistes du dépôt reprennent **exactement ce notebook** avec des distributions : -- [Infer-5-Causal-Inference](../../Probas/Infer/Infer-5-Causal-Inference.html) — le **jumeau distributionnel par message passing** : `P(Y|do(X))` calculé par mutilation de graphe en Infer.NET (EP/VMP), ajustements backdoor / front-door, paradoxe de Simpson résolu numériquement. -- [PyMC-05-Causal-Inference](../../Probas/PyMC/PyMC-05-Causal-Inference.html) — la version **MCMC** avec l'opérateur natif `pm.do` et le contrefactuel par abduction. -- [ICT-05-CausalEmergence-Python](../../IIT/ICT-Series/ICT-05-CausalEmergence-Python.html) — le même `do` monte d'un cran : à **quelle échelle** un système fait-il le plus de travail causal ? +- [Infer-5-Causal-Inference](../../Probas/Infer/Infer-5-Causal-Inference.ipynb) — le **jumeau distributionnel par message passing** : `P(Y|do(X))` calculé par mutilation de graphe en Infer.NET (EP/VMP), ajustements backdoor / front-door, paradoxe de Simpson résolu numériquement. +- [PyMC-05-Causal-Inference](../../Probas/PyMC/PyMC-05-Causal-Inference.ipynb) — la version **MCMC** avec l'opérateur natif `pm.do` et le contrefactuel par abduction. +- [ICT-05-CausalEmergence-Python](../../IIT/ICT-Series/ICT-05-CausalEmergence-Python.ipynb) — le même `do` monte d'un cran : à **quelle échelle** un système fait-il le plus de travail causal ? Vue d'ensemble des quatre paradigmes : le [README IIT](../../IIT/README.md), section « Ponts causaux : le do-calculus de Pearl à travers les paradigmes ». diff --git a/MyIA.AI.Notebooks/SymbolicAI/Tweety/argumentation_lean/README.md b/MyIA.AI.Notebooks/SymbolicAI/Tweety/argumentation_lean/README.md index 13eb26406c..636b926ebb 100644 --- a/MyIA.AI.Notebooks/SymbolicAI/Tweety/argumentation_lean/README.md +++ b/MyIA.AI.Notebooks/SymbolicAI/Tweety/argumentation_lean/README.md @@ -127,7 +127,7 @@ lake build Argumentation ## Notebook compagnon -[`Tweety-05-Abstract-Argumentation-Python.ipynb`](../Tweety-05-Abstract-Argumentation-Python.html) +[`Tweety-05-Abstract-Argumentation-Python.ipynb`](../Tweety-05-Abstract-Argumentation-Python.ipynb) — présentation pédagogique Python (tweety) des cadres de Dung et de leurs extensions, dont cette formalisation est le pendant prouvé. Paire Lean + Python côte à côte. diff --git a/MyIA.AI.Notebooks/SymbolicAI/Tweety/dotnet-build/README.md b/MyIA.AI.Notebooks/SymbolicAI/Tweety/dotnet-build/README.md index 1da4a10e93..553aa9e2ef 100644 --- a/MyIA.AI.Notebooks/SymbolicAI/Tweety/dotnet-build/README.md +++ b/MyIA.AI.Notebooks/SymbolicAI/Tweety/dotnet-build/README.md @@ -20,7 +20,7 @@ sous runtime 8.15.0 (types exposés et instanciables). Toutes les recettes cible | `build-tweety-pl-shade.pom.xml` | POM aggregator Maven shade (produit le fat-jar) | Oui (reproductibilité) | | `build-TweetyShade.csproj` | Projet MSBuild `` (convertit le fat-jar en DLL) | Oui (reproductibilité) | -## Fichiers — cluster `beliefdynamics` (notebook [`../Tweety-04-Belief-Revision-CSharp.ipynb`](../Tweety-04-Belief-Revision-CSharp.html)) +## Fichiers — cluster `beliefdynamics` (notebook [`../Tweety-04-Belief-Revision-CSharp.ipynb`](../Tweety-04-Belief-Revision-CSharp.ipynb)) | Fichier | Rôle | Committé ? | |---------|------|-----------| From b8b0f54acfbee28b5656a179313785887af6bb37 Mon Sep 17 00:00:00 2001 From: jsboige Date: Tue, 13 Oct 2026 16:53:30 +0200 Subject: [PATCH 2/3] Fix(readme,#20549): sweep complet -- 312 liens restants (ML, RL, GenAI, Probas, residuel) en .ipynb Suite de la demande user (cours EPF, 13/10) : apres Search+SymbolicAI (commit precedent), ce commit couvre le reste du depot -- ML (331 occurrences), RL (58), GenAI (42), Probas (17 + 1 cross-link SymbolicAI restant), Complexity (7), QuantConnect (6), IIT (3), Compression (1). 33 READMEs, 458 occurrences, remplacement pur d'href X.html -> X.ipynb (cibles .ipynb toutes presentes, pre-controle issue #20549 : 0 cas piege). Verifications : - regen_quarto_render.py --check-readme-links : 0 HTML_404 sur tout le depot (647 occurrences corrigees au total sur la PR) - check_docs_links.py --check --base origin/main : OK, no new broken links (8645 total) Closes #20549 Co-Authored-By: Claude Sonnet 5.5 --- MyIA.AI.Notebooks/Complexity/README.md | 12 +- MyIA.AI.Notebooks/Compression/README.md | 2 +- MyIA.AI.Notebooks/GenAI/3D/README.md | 4 +- MyIA.AI.Notebooks/GenAI/FineTuning/README.md | 36 ++--- .../GenAI/Image/01-Foundation/README.md | 2 +- .../GenAI/PostTraining/README.md | 22 +-- .../GenAI/Vibe-Coding/analyzers/README.md | 4 +- MyIA.AI.Notebooks/IIT/ICT-Series/README.md | 2 +- .../01-PythonForDataScience/README.md | 16 +-- .../02-ML-Cours/README.md | 130 +++++++++--------- .../03-DeepLearning/README.md | 92 ++++++------- .../DataScienceWithAgents/04-Vision/README.md | 52 +++---- .../04b-Wavelet-Scattering/README.md | 12 +- .../ML/DataScienceWithAgents/README.md | 122 ++++++++-------- .../Day1-Foundations/Labs/README.md | 2 +- .../Labs/Lab2-RFP-Analysis/README.md | 2 +- .../Labs/Lab3-CV-Screening/README.md | 2 +- .../Day2-Document-Agents/README.md | 4 +- .../Labs/Lab4-DataWrangling/README.md | 2 +- .../Labs/Lab5-Viz-ML/README.md | 2 +- .../Labs/Lab6-First-Agent/README.md | 2 +- .../Labs/Lab7-Data-Analysis-Agent/README.md | 2 +- .../Day3-Data-Agents/README.md | 8 +- MyIA.AI.Notebooks/ML/ML.Net/README.md | 40 +++--- MyIA.AI.Notebooks/ML/README.md | 54 ++++---- .../Probas/Applications/Percolation/README.md | 4 +- .../Probas/Applications/README.md | 4 +- MyIA.AI.Notebooks/Probas/README.md | 12 +- .../QuantConnect/Python/README.md | 2 +- .../QuantConnect/kelly_lean/README.md | 4 +- .../projects/ML-RandomForest/README.md | 2 +- .../projects/RiskParity/README.md | 4 +- MyIA.AI.Notebooks/RL/README.md | 102 +++++++------- 33 files changed, 381 insertions(+), 381 deletions(-) diff --git a/MyIA.AI.Notebooks/Complexity/README.md b/MyIA.AI.Notebooks/Complexity/README.md index 168bfc9673..634a6a8a78 100644 --- a/MyIA.AI.Notebooks/Complexity/README.md +++ b/MyIA.AI.Notebooks/Complexity/README.md @@ -31,13 +31,13 @@ n'y existe pas encore, et pourquoi. | [`Complexity-03c-ComplexityZoo-Navigation-Python.ipynb`](Complexity-03c-ComplexityZoo-Navigation-Python.ipynb) | Recherche | approfondissement de **03 — Plus de temps, plus de problèmes** | Scott Aaronson (fondateur du Complexity Zoo, 2004 — plus de 500 classes répertoriées) ; Theodore Baker, John Gill, Robert Solovay (*Relativizations of the P=?NP Question*, 1975) | La chaîne $L \subseteq NL \subseteq P \subseteq NP$ **tournée sur instances** : atteignabilité décidée deux fois — vérificateur à 2 mots de mémoire (certificat lu une fois, accord sur 4 tailles, faux témoin amputé refusé) contre DFS dont la pile explore ~$n/3$ sommets ; 2-SAT (Kosaraju, linéaire, $n=800$) contre 3-SAT (DPLL, densité-seuil $4{,}267n$) : facteurs de croissance **mesurés** par variable (~1,10× en noeuds, ~1,16× en temps), 20 certificats sur 20 vérifiés en polynomial ; **Baker–Gill–Solovay exécuté** — monde A : oracle diagonal, 4 machines vaincues par basculement d'un seul témoin, le côté NP exhaustif confirme $L_O$ sur chaque stade ; monde B : l'oracle QBF donne $P^B = NP^B$ en une requête — la barrière de relativisation vue du jouet ; carte du Zoo à 8 arêtes classées Mesuré/Cité/Ouvert (+ carte mermaid) ; encart **gap Mathlib** : `Computability/` couvre la calculabilité, mais aucune classe à bornage — le Zoo est absent | Français | | [`Complexity-04-OnlineAlgorithms-Python.ipynb`](Complexity-04-OnlineAlgorithms-Python.ipynb) | Licence | — | — (socle) | Louer ou acheter des skis : balayage des seuils, pire rapport $2 - 1/B$ atteint exactement au seuil $T = B$, puis distribution randomisée dont le pire rapport **converge vers $e/(e-1) \approx 1{,}58198$** ; pagination : Belady hors ligne contre LRU et FIFO — rapport tendant vers $k$ sur le motif cyclique ($4{,}84$ à $k=5$), retombant à $1{,}47$ sur requêtes aléatoires ; secrétaire : fraction d'observation balayée, sommet **plat** autour de $1/e$ (indiscernable de $0{,}4$ à $0{,}003$ près) ; quatre énoncés séparés Mesuré/Cité ; trois exercices exécutables | Français | | [`Complexity-04b-OnlineConjectures-Secretary-KServer.ipynb`](Complexity-04b-OnlineConjectures-Secretary-KServer.ipynb) | Recherche | approfondissement de **04 — Décider sans connaître la suite** | Sahil Singla & Christian Coester, Elias Koutsoupias, Marek Zbysiński (les deux preprints de septembre 2026 : conjecture du secrétaire matroïdal 2007 et conjecture k-server ~1990, tombées à 24 h d'écart) | Baseline $1/e$ du secrétaire classique mesurée par Monte Carlo ($n$ = 20/100/1000) ; deux matroïdes à oracle d'indépendance (uniforme, graphique) avec optimum offline exact et compétitivité de deux stratégies online ; **work function algorithm implémenté exactement** (DP sur les $\binom{m}{2}$ configurations) : sur le cycle $C_5$, ratio WFA 1,67 sous la borne $k=2$ quand greedy explose (20 à 60 requêtes, 160 à 480 — non compétitif) ; tableau du double visage randomisation/déterminisme ; trois niveaux épistémiques Mesuré/Cité/Absent (prudence « preuve annoncée ») ; encart **gap Mathlib** (matroïdes présents, compétitivité/k-server/work functions absents) | Français | -| [`Complexity-04c-KServer-WorkFunction-Python.ipynb`](Complexity-04c-KServer-WorkFunction-Python.html) | Recherche | lettre de la marche **04 — Décider sans connaître la suite** | Manasse, McGeoch & Sleator (conjecture k-server, ~1990) ; Christian Coester, Elias Koutsoupias, Marek Zbysiński (preprint arXiv 2609.15979) | **Un** des deux problèmes de 04b, mesuré à fond : la **work function** implémentée comme DP exact sur les configurations — elle **est** l'optimum offline —, WFA en ligne sur ligne, cycle et métrique uniforme, vérification par instance WFA ≤ k×OPT (aucune violation sur les instances seedées), duel WFA contre LRU et FIFO sur la pagination (boucle k+2 : LRU devant WFA en fautes, les deux sous k×OPT), work function visualisée en heatmap des configurations. Bandeau d'honnêteté : les ratios réalisés (~1,1-1,6) restent sous la garantie pire-cas k — mesuré n'est pas prouvé, et le preprint n'est pas relu | Français | -| [`Complexity-04d-Secretaire-Matroidal-Python.ipynb`](Complexity-04d-Secretaire-Matroidal-Python.html) | Recherche | lettre de la marche **04 — Décider sans connaître la suite** | Sahil Singla (conjecture du secrétaire matroïdal, 2007) ; preprint arXiv 2609.14555 | L'**autre** problème de 04b, élément par élément : trois matroïdes jouets par oracle d'indépendance (uniforme, partition, graphique), l'algorithme de Singla reconstruit (échantillon Bin(n,1/2), configuration virtuelle, glouton des deux côtés — purement ordinal, ne connaît que n), banc de mesure P[accept \| e ∈ OPT] sur plusieurs instances × milliers d'essais : la garantie 1/4 jamais violée et **serrée sur les rangs 1-2**, E[ALG]/OPT ≈ 0,44, prix de l'universalité 0,41 → 0,26 contre le seuil 1/e classique. La garantie sert de **test exécutable** : c'est le banc qui a détecté le bug du prototype | Français | +| [`Complexity-04c-KServer-WorkFunction-Python.ipynb`](Complexity-04c-KServer-WorkFunction-Python.ipynb) | Recherche | lettre de la marche **04 — Décider sans connaître la suite** | Manasse, McGeoch & Sleator (conjecture k-server, ~1990) ; Christian Coester, Elias Koutsoupias, Marek Zbysiński (preprint arXiv 2609.15979) | **Un** des deux problèmes de 04b, mesuré à fond : la **work function** implémentée comme DP exact sur les configurations — elle **est** l'optimum offline —, WFA en ligne sur ligne, cycle et métrique uniforme, vérification par instance WFA ≤ k×OPT (aucune violation sur les instances seedées), duel WFA contre LRU et FIFO sur la pagination (boucle k+2 : LRU devant WFA en fautes, les deux sous k×OPT), work function visualisée en heatmap des configurations. Bandeau d'honnêteté : les ratios réalisés (~1,1-1,6) restent sous la garantie pire-cas k — mesuré n'est pas prouvé, et le preprint n'est pas relu | Français | +| [`Complexity-04d-Secretaire-Matroidal-Python.ipynb`](Complexity-04d-Secretaire-Matroidal-Python.ipynb) | Recherche | lettre de la marche **04 — Décider sans connaître la suite** | Sahil Singla (conjecture du secrétaire matroïdal, 2007) ; preprint arXiv 2609.14555 | L'**autre** problème de 04b, élément par élément : trois matroïdes jouets par oracle d'indépendance (uniforme, partition, graphique), l'algorithme de Singla reconstruit (échantillon Bin(n,1/2), configuration virtuelle, glouton des deux côtés — purement ordinal, ne connaît que n), banc de mesure P[accept \| e ∈ OPT] sur plusieurs instances × milliers d'essais : la garantie 1/4 jamais violée et **serrée sur les rangs 1-2**, E[ALG]/OPT ≈ 0,44, prix de l'universalité 0,41 → 0,26 contre le seuil 1/e classique. La garantie sert de **test exécutable** : c'est le banc qui a détecté le bug du prototype | Français | | [`Complexity-05-CountingHarder-Permanent.ipynb`](Complexity-05-CountingHarder-Permanent.ipynb) | Licence | — | — (socle) | De vérifier (02) à **compter** : la classe #P déroulée à la main sur une expression à trois variables (huit certificats énumérés, quatre témoins) ; le **déterminant** défini par la même somme de $n!$ produits mais tombé à $O(n^3)$ par Gauss — chronométré au doublement des tailles (facteur borné, la signature du polynôme) ; la **permanente** sans les signes : la définition $n!$ exécutée telle quelle (copie pédagogique déclarée), comptes canoniques validés (identité, tout-un $= n!$, la $3 imes3$ déroulée terme à terme) ; l'écart **mesuré** côte à côte jusqu'à $n = 10$ avec extrapolation du mur factoriel ; Valiant 1979 (#P-difficile même en 0/1) au niveau **Cité** ; le pont aux graphes : compter les couplages parfaits d'un biparti **est** une permanente — vérifié par deux machines indépendantes | Français | | [`Complexity-05b-AaronsonArkhipov-PermanenteBosonSampling.ipynb`](Complexity-05b-AaronsonArkhipov-PermanenteBosonSampling.ipynb) | Recherche | approfondissement de **05 — Compter est plus dur que vérifier** | Scott Aaronson & Alex Arkhipov (*The Computational Complexity of Linear Optics*, 2011 — la permanente comme frontière quantique) | La définition $n!$ **exécutée** avec comptes canoniques, vérifiée contre l'énumération brute des couplages parfaits (perm(0/1)) ; **Ryser vectorisé réemployé de Sudoku-15** (`batch_perm8`, généralisé à toute taille) contre Gauss instrumenté : comptes exacts par formules fermées validées par instrumentation — à $n=20$, définition $4{,}9 \times 10^{19}$ opérations contre 5 149 pour Gauss, Ryser/det ≈ $1{,}6 \times 10^4$ en temps à $n=16$ ; #P-difficulté (Valiant 1979) maintenue au niveau **Cité**, FPRAS non négatif (Jerrum–Sinclair–Vigoda) en exception qui désigne les signes ; **BosonSampling jouet** : unitaire Haar (QR, Mezzadri), loi $\lvert\mathrm{perm}\rvert^2$ exacte sur 56/924/12 870 sorties, TV(échantillon, exact) → 0, coût d'énumération extrapolé jusqu'à ~1 an à 1 TFLOP/s pour $(20, 40)$ ; encart **gap Mathlib** — premier verdict **positif** de la série : `Matrix.permanent` existe (forme $n!$) face à un dossier `Determinant/` entier, mais ni Ryser ni couche complexité | Français | | [`Complexity-06-Simuler-Circuit-Quantique-Classiquement-Python.ipynb`](Complexity-06-Simuler-Circuit-Quantique-Classiquement-Python.ipynb) | Licence | — | — (socle) | Le **coût de la simulation classique** d'un circuit quantique : barrière exponentielle **O(2^n)** sur n qubits pour la simulation vectorielle naïve (Hadamard uniforme chronométré à n = 4, 8, 16, 20), plafond mémoire 16 Go atteint vers n = 30 (limite pratique n ≈ 28) ; algorithme de **Gottesman-Knill** (Aaronson & Gottesman 2004) — la sous-famille **Clifford** (H, S, CNOT) se simule en O(n²) grâce à la description par table de Pauli ; le carnet échantillonne directement sans reconstruire le vecteur d'état jusqu'à n = 28 ; distinction **échantillonner** vs **calculer la distribution exacte** (Aaronson-Arkhipov 2011 pour le boson sampling ; folklore pour les circuits universels) ; inclusion BQP ⊆ PP ⊆ P#P (théorème) au niveau **Cité**, l'ouverte portant sur BQP vs P / PH ; trois exercices exécutables (matrice unitaire 16×16 d'un circuit H/T/CNOT, distinction échantillonner / calculer, énoncé BQP) | Français | -| [`Complexity-06b-AaronsonGottesman-Dequantification-Python.ipynb`](Complexity-06b-AaronsonGottesman-Dequantification-Python.html) | Recherche | accrétion de **06 — Simuler un circuit quantique classiquement** | Scott Aaronson & Daniel Gottesman (*Improved Simulation of Stabilizer Circuits*, 2004 — déquantifier les suprématies par l'arbitre exécutable) | Le formalisme stabilisateur **exécuté** : table de phase et conjugaison CHP **dérivées des matrices 2×2**, jamais recopiées ; port CHP complet (rowsum, portes, mesures — déterministe par lecture GF(2), aléatoire par re-stabilisation) croisé contre l'état complet 2^n : **84 valeurs propres stabilisatrices exactes au 1e-9** (zéro bruit), distributions TV sous 6× le bruit de sondage ; banc discriminant (mesures sur ce banc) : bascule **dès n=10 qubits**, ratio **665×** à n=20, échelons locaux au-dessus du plancher 2× (le mur réel est plus raide que 2^n : la mémoire aussi a une loi) ; une **seule** porte T ferme le port — stim n'est pas installé dans l'environnement de ce banc, la frontière Clifford/le-reste est attestée par le port seul (cf. issue de suivi pour la ré-exécution avec stim) | Français | -| [`Complexity-07-KolmogorovBornee-Sequences-Python.ipynb`](Complexity-07-KolmogorovBornee-Sequences-Python.html) | Recherche | arrivé de Search/Applications (ex-App-34) — renuméroté 07 : la complexité de Kolmogorov **bornée** est une notion de complexité ; le pli Kolmogorov/MDL de l’EPIC Compression [#18706](https://github.com/jsboige/CoursIA/issues/18706) pourra y renvoyer | Strannegård, Nizamati, Sjöberg & Engström (*Bounded Kolmogorov Complexity Based on Cognitive Models*, AGI 2013 — modéliser le sujet à mémoire limitée plutôt que la séquence) | K(x) opérationnalisée en coût **à mémoire bornée** : langage de termes (numérales, position n, regard arrière f(n−c), opérations binaires) résolu par énumération par longueur croissante ; trois expériences falsifiables — E1 balayage de la borne de mémoire (score(B) sur batterie de 30 items), E2 discrimination à la borne (seuils prédits par bounded_mul contre basculements mesurés), E3 baselines honnêtes (interpolation polynomiale, différences finies) ; verdicts rendus par les cellules, y compris négatifs ; limites déclarées (batterie maison, TRS opérationnalisé) | Français | +| [`Complexity-06b-AaronsonGottesman-Dequantification-Python.ipynb`](Complexity-06b-AaronsonGottesman-Dequantification-Python.ipynb) | Recherche | accrétion de **06 — Simuler un circuit quantique classiquement** | Scott Aaronson & Daniel Gottesman (*Improved Simulation of Stabilizer Circuits*, 2004 — déquantifier les suprématies par l'arbitre exécutable) | Le formalisme stabilisateur **exécuté** : table de phase et conjugaison CHP **dérivées des matrices 2×2**, jamais recopiées ; port CHP complet (rowsum, portes, mesures — déterministe par lecture GF(2), aléatoire par re-stabilisation) croisé contre l'état complet 2^n : **84 valeurs propres stabilisatrices exactes au 1e-9** (zéro bruit), distributions TV sous 6× le bruit de sondage ; banc discriminant (mesures sur ce banc) : bascule **dès n=10 qubits**, ratio **665×** à n=20, échelons locaux au-dessus du plancher 2× (le mur réel est plus raide que 2^n : la mémoire aussi a une loi) ; une **seule** porte T ferme le port — stim n'est pas installé dans l'environnement de ce banc, la frontière Clifford/le-reste est attestée par le port seul (cf. issue de suivi pour la ré-exécution avec stim) | Français | +| [`Complexity-07-KolmogorovBornee-Sequences-Python.ipynb`](Complexity-07-KolmogorovBornee-Sequences-Python.ipynb) | Recherche | arrivé de Search/Applications (ex-App-34) — renuméroté 07 : la complexité de Kolmogorov **bornée** est une notion de complexité ; le pli Kolmogorov/MDL de l’EPIC Compression [#18706](https://github.com/jsboige/CoursIA/issues/18706) pourra y renvoyer | Strannegård, Nizamati, Sjöberg & Engström (*Bounded Kolmogorov Complexity Based on Cognitive Models*, AGI 2013 — modéliser le sujet à mémoire limitée plutôt que la séquence) | K(x) opérationnalisée en coût **à mémoire bornée** : langage de termes (numérales, position n, regard arrière f(n−c), opérations binaires) résolu par énumération par longueur croissante ; trois expériences falsifiables — E1 balayage de la borne de mémoire (score(B) sur batterie de 30 items), E2 discrimination à la borne (seuils prédits par bounded_mul contre basculements mesurés), E3 baselines honnêtes (interpolation polynomiale, différences finies) ; verdicts rendus par les cellules, y compris négatifs ; limites déclarées (batterie maison, TRS opérationnalisé) | Français | ## Parcours @@ -51,9 +51,9 @@ principal de niveau licence qui en pose d'abord les notions. | 01 | Compter des pas | Découverte | — | | 02 | Vérifier ou trouver : P, NP, certificat, réduction | Découverte | — | | 03 | [Plus de temps, plus de problèmes](Complexity-03-TimeHierarchy.ipynb) | Licence | [03b — Hartmanis–Stearns](Complexity-03b-HartmanisStearns-TimeHierarchy.ipynb), [03c — Zoo et oracles](Complexity-03c-ComplexityZoo-Navigation-Python.ipynb) | -| 04 | [Décider sans connaître la suite](Complexity-04-OnlineAlgorithms-Python.ipynb) | Licence | [04b — conjectures online](Complexity-04b-OnlineConjectures-Secretary-KServer.ipynb), [04c — k-server, work function](Complexity-04c-KServer-WorkFunction-Python.html), [04d — secrétaire matroïdal](Complexity-04d-Secretaire-Matroidal-Python.html) | +| 04 | [Décider sans connaître la suite](Complexity-04-OnlineAlgorithms-Python.ipynb) | Licence | [04b — conjectures online](Complexity-04b-OnlineConjectures-Secretary-KServer.ipynb), [04c — k-server, work function](Complexity-04c-KServer-WorkFunction-Python.ipynb), [04d — secrétaire matroïdal](Complexity-04d-Secretaire-Matroidal-Python.ipynb) | | 05 | [Compter est plus dur que vérifier](Complexity-05-CountingHarder-Permanent.ipynb) | Licence | [05b — La permanente, frontière quantique](Complexity-05b-AaronsonArkhipov-PermanenteBosonSampling.ipynb) | -| 06 | [Simuler un circuit quantique classiquement](Complexity-06-Simuler-Circuit-Quantique-Classiquement-Python.ipynb) | Licence | [06b — Aaronson–Gottesman](Complexity-06b-AaronsonGottesman-Dequantification-Python.html) | +| 06 | [Simuler un circuit quantique classiquement](Complexity-06-Simuler-Circuit-Quantique-Classiquement-Python.ipynb) | Licence | [06b — Aaronson–Gottesman](Complexity-06b-AaronsonGottesman-Dequantification-Python.ipynb) | | 07 | [Complexité de Kolmogorov bornée : séquences à mémoire limitée](Complexity-07-KolmogorovBornee-Sequences-Python.ipynb) | Recherche | — | ## Position dans le dépôt diff --git a/MyIA.AI.Notebooks/Compression/README.md b/MyIA.AI.Notebooks/Compression/README.md index 4937fb5eef..0dfc2a082b 100644 --- a/MyIA.AI.Notebooks/Compression/README.md +++ b/MyIA.AI.Notebooks/Compression/README.md @@ -22,7 +22,7 @@ Lean des définitions est prévu par les plis suivants. | Carnet | Niveau | Contenu | |---|---|---| -| [Compression-01 — Codes préfixes : de Shannon-Fano à Huffman](Compression-01-ShannonFano-Prefixe-Python.html) | Découverte | codes préfixes, inégalité de Kraft, Shannon-Fano contre Huffman, l'entropie comme borne | +| [Compression-01 — Codes préfixes : de Shannon-Fano à Huffman](Compression-01-ShannonFano-Prefixe-Python.ipynb) | Découverte | codes préfixes, inégalité de Kraft, Shannon-Fano contre Huffman, l'entropie comme borne | ## Position dans le dépôt diff --git a/MyIA.AI.Notebooks/GenAI/3D/README.md b/MyIA.AI.Notebooks/GenAI/3D/README.md index 6df47d0be0..c08caf3533 100644 --- a/MyIA.AI.Notebooks/GenAI/3D/README.md +++ b/MyIA.AI.Notebooks/GenAI/3D/README.md @@ -14,7 +14,7 @@ L'objectif fil rouge de la série est de **comprendre NeRF de l'intérieur** — À l'issue de la série, l'apprenant sait : -- **Écrire un pipeline NeRF complet** : encodage positionnel $\gamma$ (pont avec les Fourier features de [`3.4d`](../../ML/DataScienceWithAgents/03-DeepLearning/3.4d-Fourier-Features-Biais-Spectral-Python.html)), MLP à sauts de connexion, échantillonnage stratifié le long des rayons, compositing alpha différentiable, quadrature de l'équation de rendu. +- **Écrire un pipeline NeRF complet** : encodage positionnel $\gamma$ (pont avec les Fourier features de [`3.4d`](../../ML/DataScienceWithAgents/03-DeepLearning/3.4d-Fourier-Features-Biais-Spectral-Python.ipynb)), MLP à sauts de connexion, échantillonnage stratifié le long des rayons, compositing alpha différentiable, quadrature de l'équation de rendu. - **Relier représentation continue et biais spectral** : pourquoi un MLP brut ne peut pas apprendre les hautes fréquences d'une scène, et ce que l'encodage positionnel change. - **Mesurer les limites d'une architecture** : temps d'entraînement par scène, effondrement sans Fourier features, sensibilité aux poses, échelle unique du rayon, coût de l'échantillonnage volumique. - **Situer les successeurs** : Mip-NeRF (frustum conique), Instant-NGP (tables de hachage), 3DGS (gaussiennes explicites) — et pourquoi chaque correctif change de représentation plutôt que de régler le MLP. @@ -28,7 +28,7 @@ L'objectif fil rouge de la série est de **comprendre NeRF de l'intérieur** — ## Prérequis et exécution -- **Prérequis conceptuel** : biais spectral et Fourier features ([`3.4d-Fourier-Features`](../../ML/DataScienceWithAgents/03-DeepLearning/3.4d-Fourier-Features-Biais-Spectral-Python.html), Pli 1 de l'Epic #18605). +- **Prérequis conceptuel** : biais spectral et Fourier features ([`3.4d-Fourier-Features`](../../ML/DataScienceWithAgents/03-DeepLearning/3.4d-Fourier-Features-Biais-Spectral-Python.ipynb), Pli 1 de l'Epic #18605). - **Exécution** : PyTorch (CPU jouable pour la scène jouet ; GPU recommandé — ~2-3 min pour 3D-01, ~10-12 min pour 3D-02 sur RTX 3090). Les seeds sont fixés : les résultats sont reproductibles. - **Dataset** : `tiny_nerf_data.npz` (scène Blender « Lego » 100×100, © les auteurs de NeRF) téléchargé au premier lancement depuis la page projet UCSD des auteurs, mis en cache dans `data/` (hors dépôt). diff --git a/MyIA.AI.Notebooks/GenAI/FineTuning/README.md b/MyIA.AI.Notebooks/GenAI/FineTuning/README.md index 30a627b503..cdb4900845 100644 --- a/MyIA.AI.Notebooks/GenAI/FineTuning/README.md +++ b/MyIA.AI.Notebooks/GenAI/FineTuning/README.md @@ -44,23 +44,23 @@ FineTuning/ | Notebook | Sujet | Prérequis | Durée | Niveau | |----------|-------|-----------|-------|--------| -| [FT-00a](FT-00a-LoRA-from-scratch-Python.html) | LoRA from scratch : `LoRALinear`/`LoRAConv2d` en PyTorch pur, initialisation canonique, fusion et sa dérive | Bases PyTorch | ~30 min | Intermédiaire | -| [FT-00b](FT-00b-LoRA-Hyperparams-from-scratch-Python.html) | Ablation `r × alpha` from scratch : sweet-spots mesurés sur 18 configurations, comparaisons aux baselines | FT-00a | ~15 min | Intermédiaire | -| [FT-01](FT-01-Introduction-FineTuning-Python.html) | Fine-tuning complet, partiel, LoRA | Bases LLMs | ~30 min | Débutant | -| [FT-02](FT-02-QLoRA-Quantization-Python.html) | Quantization NF4, QLoRA, bitsandbytes | FT-01 | ~30 min | Intermédiaire | -| [FT-03](FT-03-Supervised-FineTuning-SFT-Python.html) | SFT sur Qwen3.5-0.8B : enseigner un contrat de format balisé | FT-01 | ~45 min | Intermédiaire | -| [FT-04](FT-04-RLHF-DPO-Python.html) | Reward Model, RLHF, DPO | FT-01, FT-02, FT-03 | ~30 min | Avancé | -| [FT-05](FT-05-ModelMerging-Routing-Python.html) | TIES, DARE, MergeKit, routage MoE | FT-01 à FT-04 | ~45 min | Avancé | -| [FT-06](FT-06-Vision-Language-LoRA-Python.html) | LoRA vision-langage Qwen3.5-0.8B, conformité image->texte | FT-02, FT-03 | ~45 min | Avancé | +| [FT-00a](FT-00a-LoRA-from-scratch-Python.ipynb) | LoRA from scratch : `LoRALinear`/`LoRAConv2d` en PyTorch pur, initialisation canonique, fusion et sa dérive | Bases PyTorch | ~30 min | Intermédiaire | +| [FT-00b](FT-00b-LoRA-Hyperparams-from-scratch-Python.ipynb) | Ablation `r × alpha` from scratch : sweet-spots mesurés sur 18 configurations, comparaisons aux baselines | FT-00a | ~15 min | Intermédiaire | +| [FT-01](FT-01-Introduction-FineTuning-Python.ipynb) | Fine-tuning complet, partiel, LoRA | Bases LLMs | ~30 min | Débutant | +| [FT-02](FT-02-QLoRA-Quantization-Python.ipynb) | Quantization NF4, QLoRA, bitsandbytes | FT-01 | ~30 min | Intermédiaire | +| [FT-03](FT-03-Supervised-FineTuning-SFT-Python.ipynb) | SFT sur Qwen3.5-0.8B : enseigner un contrat de format balisé | FT-01 | ~45 min | Intermédiaire | +| [FT-04](FT-04-RLHF-DPO-Python.ipynb) | Reward Model, RLHF, DPO | FT-01, FT-02, FT-03 | ~30 min | Avancé | +| [FT-05](FT-05-ModelMerging-Routing-Python.ipynb) | TIES, DARE, MergeKit, routage MoE | FT-01 à FT-04 | ~45 min | Avancé | +| [FT-06](FT-06-Vision-Language-LoRA-Python.ipynb) | LoRA vision-langage Qwen3.5-0.8B, conformité image->texte | FT-02, FT-03 | ~45 min | Avancé | ### Socle from-scratch (compléments techniques, 00a → 00b → 00c) | Notebook | Sujet | Prérequis | Durée | Niveau | |----------|-------|-----------|-------|--------| -| [FT-00a](FT-00a-LoRA-from-scratch-Python.html) | LoRA from scratch : `LoRALinear`/`LoRAConv2d` en PyTorch pur, initialisation canonique, fusion et sa dérive | Bases PyTorch | ~30 min | Intermédiaire | -| [FT-00b](FT-00b-LoRA-Hyperparams-from-scratch-Python.html) | Ablation `r × alpha` from scratch : sweet-spots mesurés sur 18 configurations, comparaisons aux baselines | FT-00a | ~15 min | Intermédiaire | -| [FT-00c](FT-00c-LoRA-SOTA-Comparison-Python.html) | La même adaptation refaite avec `peft.LoraConfig` : paramètres, exactitude, lignes de code — le coût/bénéfice de l'outil SOTA mesuré | FT-00a | ~15 min | Intermédiaire | -| [FT-00d](FT-00d-LoRA-QLoRA-SOTA-Comparison-Python.html) | QLoRA = peft + bitsandbytes 4-bit NF4 ; la mesure structurelle first-hand qui montre que bnb ne mord que sur `nn.Linear` (SmallCNN 19.85 %, BigMLP 100 %, DistilBERT 64.37 % — mesures first-hand) — l'arbre de décision avant d'invoquer QLoRA | FT-00a, FT-00c | ~30 min | Intermédiaire | +| [FT-00a](FT-00a-LoRA-from-scratch-Python.ipynb) | LoRA from scratch : `LoRALinear`/`LoRAConv2d` en PyTorch pur, initialisation canonique, fusion et sa dérive | Bases PyTorch | ~30 min | Intermédiaire | +| [FT-00b](FT-00b-LoRA-Hyperparams-from-scratch-Python.ipynb) | Ablation `r × alpha` from scratch : sweet-spots mesurés sur 18 configurations, comparaisons aux baselines | FT-00a | ~15 min | Intermédiaire | +| [FT-00c](FT-00c-LoRA-SOTA-Comparison-Python.ipynb) | La même adaptation refaite avec `peft.LoraConfig` : paramètres, exactitude, lignes de code — le coût/bénéfice de l'outil SOTA mesuré | FT-00a | ~15 min | Intermédiaire | +| [FT-00d](FT-00d-LoRA-QLoRA-SOTA-Comparison-Python.ipynb) | QLoRA = peft + bitsandbytes 4-bit NF4 ; la mesure structurelle first-hand qui montre que bnb ne mord que sur `nn.Linear` (SmallCNN 19.85 %, BigMLP 100 %, DistilBERT 64.37 % — mesures first-hand) — l'arbre de décision avant d'invoquer QLoRA | FT-00a, FT-00c | ~30 min | Intermédiaire | ## Technologies couvertes @@ -100,7 +100,7 @@ pip install mergekit # Pour FT-05 uniquement ## Concepts clés ### LoRA (Low-Rank Adaptation) -Décompose les mises à jour de poids en matrices de bas rang (A, B avec rang r << dim). Réduit les paramètres entraînables de ~99%. Le mécanisme est démonté from-scratch (sans `peft`) dans [FT-00a](FT-00a-LoRA-from-scratch-Python.html) : initialisation canonique, gel, budget `r(d+k)`, fusion et sa (non-)bit-exactitude. Le **réglage** `r × alpha` est mesuré dans [FT-00b](FT-00b-LoRA-Hyperparams-from-scratch-Python.html) : 18 configurations sur la même mini-tâche, trois régularités quantifiées. La **confrontation à l'outil SOTA** est faite dans [FT-00c](FT-00c-LoRA-SOTA-Comparison-Python.html) : `peft.LoraConfig` refait la même adaptation en deux lignes — le notebook mesure ce que l'écosystème apporte et ce qu'il masque. +Décompose les mises à jour de poids en matrices de bas rang (A, B avec rang r << dim). Réduit les paramètres entraînables de ~99%. Le mécanisme est démonté from-scratch (sans `peft`) dans [FT-00a](FT-00a-LoRA-from-scratch-Python.ipynb) : initialisation canonique, gel, budget `r(d+k)`, fusion et sa (non-)bit-exactitude. Le **réglage** `r × alpha` est mesuré dans [FT-00b](FT-00b-LoRA-Hyperparams-from-scratch-Python.ipynb) : 18 configurations sur la même mini-tâche, trois régularités quantifiées. La **confrontation à l'outil SOTA** est faite dans [FT-00c](FT-00c-LoRA-SOTA-Comparison-Python.ipynb) : `peft.LoraConfig` refait la même adaptation en deux lignes — le notebook mesure ce que l'écosystème apporte et ce qu'il masque. ### QLoRA Combine quantization 4-bit (NF4 + double quantization) avec LoRA. Permet de fine-tuner des modèles 7B sur un GPU consumer (RTX 3090/4090). @@ -164,7 +164,7 @@ Le rang `r` de LoRA contrôle le compromis paramètres/qualité : - **r=32-64** : tâches complexes (raisonnement, code). Plus de paramètres mais plus de VRAM. - **r=128+** : rarement nécessaire — à ce stade, un full fine-tuning partiel est souvent plus efficace. -Le notebook [FT-01](FT-01-Introduction-FineTuning-Python.html) compare r=4 vs r=16 vs r=64 sur DistilBERT pour rendre ce compromis visible. +Le notebook [FT-01](FT-01-Introduction-FineTuning-Python.ipynb) compare r=4 vs r=16 vs r=64 sur DistilBERT pour rendre ce compromis visible. ### bitsandbytes ne s'installe pas sur Windows @@ -208,10 +208,10 @@ Si le modèle merge (FT-05) perd en qualité par rapport aux adaptateurs individ | Série | Connection | Détails | |-------|------------|---------| | **[GenAI/PostTraining](../PostTraining/README.md)** | Profondeur méthodologique | Série sœur : la math du loss derrière SFT/DPO + GRPO/RLVR. FineTuning = recettes, PostTraining = pourquoi ça marche. | -| **[RL — RL-05 MDP/Q-Learning](../../RL/RL-05-MDP-Programmation-Dynamique-Q-Learning-Python.html)** | Fondations policy/value | Socle Bellman/Q réutilisé par tout post-training. | -| **[RL — RL-06c PPO from scratch](../../RL/RL-06c-PPO-Depuis-Zero-Python.html)** | PPO from scratch | L'optimiseur derrière PPO-RLHF, implémenté pas à pas. | -| **[RL — RL-09 offline RL](../../RL/RL-09-RL-Offline-Behavior-Cloning-Python.html)** | SFT = Behavior Cloning | DPO comme preference learning offline ; contrainte de support = KL. | -| **[RL — RL-10 reward shaping](../../RL/RL-10-Reward-Shaping-Curriculum-Python.html)** | Reward model = shaping appris | Reward shaping (Ng 1999) et reward hacking, préfiguration tabulaire du reward model RLHF. | +| **[RL — RL-05 MDP/Q-Learning](../../RL/RL-05-MDP-Programmation-Dynamique-Q-Learning-Python.ipynb)** | Fondations policy/value | Socle Bellman/Q réutilisé par tout post-training. | +| **[RL — RL-06c PPO from scratch](../../RL/RL-06c-PPO-Depuis-Zero-Python.ipynb)** | PPO from scratch | L'optimiseur derrière PPO-RLHF, implémenté pas à pas. | +| **[RL — RL-09 offline RL](../../RL/RL-09-RL-Offline-Behavior-Cloning-Python.ipynb)** | SFT = Behavior Cloning | DPO comme preference learning offline ; contrainte de support = KL. | +| **[RL — RL-10 reward shaping](../../RL/RL-10-Reward-Shaping-Curriculum-Python.ipynb)** | Reward model = shaping appris | Reward shaping (Ng 1999) et reward hacking, préfiguration tabulaire du reward model RLHF. | ## Références diff --git a/MyIA.AI.Notebooks/GenAI/Image/01-Foundation/README.md b/MyIA.AI.Notebooks/GenAI/Image/01-Foundation/README.md index 312f4d2beb..995b8079bc 100644 --- a/MyIA.AI.Notebooks/GenAI/Image/01-Foundation/README.md +++ b/MyIA.AI.Notebooks/GenAI/Image/01-Foundation/README.md @@ -25,7 +25,7 @@ Ce module couvre les fondamentaux de la génération d'images par IA : modèles | 4 | [01-4-Forge-SD-XL-Turbo](01-4-Forge-SD-XL-Turbo.ipynb) | Stable Diffusion XL Turbo | ComfyUI | Variable | | 5 | [01-5-Qwen-Image-Edit](01-5-Qwen-Image-Edit.ipynb) | Introduction Qwen | ComfyUI | ~29GB | | 5b | [01-5b-Qwen-Image-Edit-2509](01-5b-Qwen-Image-Edit-2509.ipynb) | Édition avancée Qwen Image Edit 2509 | ComfyUI | ~29GB | -| 5c | [01-5c-Qwen-Image-21-Workflows](01-5c-Qwen-Image-21-Workflows.html) | Workflows de référence Qwen-Image 2.1 (nomadoor) sur instance hébergée | ComfyUI 0.37.2 (hébergée) | palier INT8 #17266 | +| 5c | [01-5c-Qwen-Image-21-Workflows](01-5c-Qwen-Image-21-Workflows.ipynb) | Workflows de référence Qwen-Image 2.1 (nomadoor) sur instance hébergée | ComfyUI 0.37.2 (hébergée) | palier INT8 #17266 | **[01-1](01-1-OpenAI-DALL-E-3.ipynb) — API cloud.** Le point d'entrée le plus immédiat : un prompt, une clé, et gpt-image-1 renvoie un visuel en ~19 s : diff --git a/MyIA.AI.Notebooks/GenAI/PostTraining/README.md b/MyIA.AI.Notebooks/GenAI/PostTraining/README.md index 67cca016e4..955cf54716 100644 --- a/MyIA.AI.Notebooks/GenAI/PostTraining/README.md +++ b/MyIA.AI.Notebooks/GenAI/PostTraining/README.md @@ -207,12 +207,12 @@ PT-06 documente le pipeline d'évaluation complet et produit un tableau comparat | Série | Connection | Details | |-------|------------|---------| -| **[RL](../../RL/)** | RL classique fondamentaux + sous-série `rlpt_*` | Les notebooks RL ([RL-05 MDP/Q-Learning](../../RL/RL-05-MDP-Programmation-Dynamique-Q-Learning-Python.html) et [RL-06c PPO from scratch](../../RL/RL-06c-PPO-Depuis-Zero-Python.html)) établissent l'intuition policy/value que PPO/GRPO réutilisent. Recommandés comme prérequis pour PT-04. | -| **[RL — RLPT-02 GRPO](../../RL/PostTraining/RLPT-02-GRPO-Minimal-Python.html)** | GRPO *naked* (sans `trl`) | La mécanique de GRPO (group rollouts, avantage intra-groupe, no critic) écrite à la main sur Qwen3.5-0.8B. Bon prérequis conceptuel pour PT-11a/PT-11b. | -| **[RL — RLPT-03 reward hacking](../../RL/PostTraining/RLPT-03-Reward-Hacking-Python.html)** | Cas clinique d'inoculation | Mini-cas : 3 voies pour déclencher le hack sur récompense vérifiable, inoculation comme variable. PT-07 est l'outil (catalogue de détecteurs), RLPT-03 le cas d'usage. | -| **[RL — RLPT-04 DPO vs PPO](../../RL/PostTraining/RLPT-04-DPO-Offline-contre-GRPO-Online-Python.html)** | Comparaison offline vs online | DPO/ORPO offline vs GRPO online à budget 40 steps — prérequis empirique pour PT-06 (évaluation comparative). | -| **[RL — RL-09 offline](../../RL/RL-09-RL-Offline-Behavior-Cloning-Python.html)** | DPO = preference learning offline | Le Behavior Cloning y est l'analogue tabulaire du SFT, et la contrainte de support de BCQ celle de la pénalité KL de DPO (PT-03). Le meilleur prérequis conceptuel pour DPO. | -| **[RL — RL-10 reward shaping](../../RL/RL-10-Reward-Shaping-Curriculum-Python.html)** | Reward model = shaping appris | Le reward shaping (Ng 1999) et son biais (shaping naïf → reward hacking) préfigurent le reward model appris et le Goodhart traité en [PT-07](PT_07_rewardspy_reward_hacking.html). | +| **[RL](../../RL/)** | RL classique fondamentaux + sous-série `rlpt_*` | Les notebooks RL ([RL-05 MDP/Q-Learning](../../RL/RL-05-MDP-Programmation-Dynamique-Q-Learning-Python.ipynb) et [RL-06c PPO from scratch](../../RL/RL-06c-PPO-Depuis-Zero-Python.ipynb)) établissent l'intuition policy/value que PPO/GRPO réutilisent. Recommandés comme prérequis pour PT-04. | +| **[RL — RLPT-02 GRPO](../../RL/PostTraining/RLPT-02-GRPO-Minimal-Python.ipynb)** | GRPO *naked* (sans `trl`) | La mécanique de GRPO (group rollouts, avantage intra-groupe, no critic) écrite à la main sur Qwen3.5-0.8B. Bon prérequis conceptuel pour PT-11a/PT-11b. | +| **[RL — RLPT-03 reward hacking](../../RL/PostTraining/RLPT-03-Reward-Hacking-Python.ipynb)** | Cas clinique d'inoculation | Mini-cas : 3 voies pour déclencher le hack sur récompense vérifiable, inoculation comme variable. PT-07 est l'outil (catalogue de détecteurs), RLPT-03 le cas d'usage. | +| **[RL — RLPT-04 DPO vs PPO](../../RL/PostTraining/RLPT-04-DPO-Offline-contre-GRPO-Online-Python.ipynb)** | Comparaison offline vs online | DPO/ORPO offline vs GRPO online à budget 40 steps — prérequis empirique pour PT-06 (évaluation comparative). | +| **[RL — RL-09 offline](../../RL/RL-09-RL-Offline-Behavior-Cloning-Python.ipynb)** | DPO = preference learning offline | Le Behavior Cloning y est l'analogue tabulaire du SFT, et la contrainte de support de BCQ celle de la pénalité KL de DPO (PT-03). Le meilleur prérequis conceptuel pour DPO. | +| **[RL — RL-10 reward shaping](../../RL/RL-10-Reward-Shaping-Curriculum-Python.ipynb)** | Reward model = shaping appris | Le reward shaping (Ng 1999) et son biais (shaping naïf → reward hacking) préfigurent le reward model appris et le Goodhart traité en [PT-07](PT_07_rewardspy_reward_hacking.ipynb). | | **[GenAI/FineTuning](../FineTuning/)** | Boîte à outils fine-tuning | Série sœur dans GenAI : LoRA/QLoRA/SFT/DPO en pratique. PostTraining = profondeur méthodologique (voir [`COURSE_CATALOG.generated.md`](../../../COURSE_CATALOG.generated.md) pour le décompte canonique), FineTuning = recettes exécutables. | ## Frontière avec RL/rlpt_* — où ouvre `PT_*`, où ouvre `rlpt_*` @@ -223,11 +223,11 @@ Les sous-séries [RL/rlpt_*](../../RL/) et cette série PostTraining couvrent ** | Question pédagogique | Ouvrir | Pourquoi | |---|---|---| -| « Comment SFT/DPO/GRPO sont-ils *câblés* dans `trl` ? Comment lire une loss ? » | [PT-02](PT_02_sft_baseline.html), [PT-03](PT_03_dpo_direct_preference.html), [PT-04](PT_04_grpo_deepseek_r1.html) | `trl.SFTTrainer`/`DPOTrainer`/`GRPOTrainer` sur vrai LLM Qwen3.5-0.8B QLoRA, vraies losses, vrais gradients via la pile HuggingFace. | -| « Comment GRPO *fonctionne* intérieurement — group rollouts, avantage intra-groupe, no critic ? » | [PT-08](PT_08_grpo_from_scratch_toy_env.html) (toy env) ou [RL/RLPT-02](../../RL/PostTraining/RLPT-02-GRPO-Minimal-Python.html) (vrai LM sans `trl`) | La mécanique écrite à la main — on voit chaque rollout, chaque reward, chaque log-prob ratio. | -| « GRPO + RLVR sur vrai LLM, avec détecteur Goodhart en ligne, multi-seed ? » | [PT-11a](PT_11a_grpo_qwen35_rlvr.html), [PT-11b](PT_11b_grpo_qwen_rlvr_on_verifiers.html) | La pile SOTA 2025 : `trl.GRPOTrainer` + Z3/SymPy + `rewardspy.watch_trl` (Goodhart live), 4 seeds dans PT-11b-multi-seed. | -| « Quels sont les détecteurs statistiques du reward hacking ? » | [PT-07](PT_07_rewardspy_reward_hacking.html) | Catalogue `rewardspy.detectors` (6 classes : Component Dominance, Length Drift, etc.) — l'**outil**. | -| « Le reward hacking est-il un attracteur spontané sur petit modèle ? Cas clinique. » | [RL/RLPT-03](../../RL/PostTraining/RLPT-03-Reward-Hacking-Python.html) | Mini-cas : 3 voies pour déclencher le hack, inoculation comme variable — le **cas d'usage** de `rewardspy`. | +| « Comment SFT/DPO/GRPO sont-ils *câblés* dans `trl` ? Comment lire une loss ? » | [PT-02](PT_02_sft_baseline.ipynb), [PT-03](PT_03_dpo_direct_preference.ipynb), [PT-04](PT_04_grpo_deepseek_r1.ipynb) | `trl.SFTTrainer`/`DPOTrainer`/`GRPOTrainer` sur vrai LLM Qwen3.5-0.8B QLoRA, vraies losses, vrais gradients via la pile HuggingFace. | +| « Comment GRPO *fonctionne* intérieurement — group rollouts, avantage intra-groupe, no critic ? » | [PT-08](PT_08_grpo_from_scratch_toy_env.ipynb) (toy env) ou [RL/RLPT-02](../../RL/PostTraining/RLPT-02-GRPO-Minimal-Python.ipynb) (vrai LM sans `trl`) | La mécanique écrite à la main — on voit chaque rollout, chaque reward, chaque log-prob ratio. | +| « GRPO + RLVR sur vrai LLM, avec détecteur Goodhart en ligne, multi-seed ? » | [PT-11a](PT_11a_grpo_qwen35_rlvr.ipynb), [PT-11b](PT_11b_grpo_qwen_rlvr_on_verifiers.ipynb) | La pile SOTA 2025 : `trl.GRPOTrainer` + Z3/SymPy + `rewardspy.watch_trl` (Goodhart live), 4 seeds dans PT-11b-multi-seed. | +| « Quels sont les détecteurs statistiques du reward hacking ? » | [PT-07](PT_07_rewardspy_reward_hacking.ipynb) | Catalogue `rewardspy.detectors` (6 classes : Component Dominance, Length Drift, etc.) — l'**outil**. | +| « Le reward hacking est-il un attracteur spontané sur petit modèle ? Cas clinique. » | [RL/RLPT-03](../../RL/PostTraining/RLPT-03-Reward-Hacking-Python.ipynb) | Mini-cas : 3 voies pour déclencher le hack, inoculation comme variable — le **cas d'usage** de `rewardspy`. | | « InoculationRL complet, panel persona × reward hackable, capstone ? » | [#5105 ICT-25](https://github.com/jsboige/CoursIA/issues/5105) | Capstone final — **distinct** de `RLPT-03` (qui en est la version compacte). | Le constat d'éventuelle duplication `RLPT-02 ↔ PT-11a` et `RLPT-03 ↔ PT-07` est traité en [#11460](https://github.com/jsboige/CoursIA/issues/11460) : les deux séries *se complètent* par l'angle du regard (mécanique vs déploiement outillé), pas par duplication. diff --git a/MyIA.AI.Notebooks/GenAI/Vibe-Coding/analyzers/README.md b/MyIA.AI.Notebooks/GenAI/Vibe-Coding/analyzers/README.md index 7881c36747..4bf55c3566 100644 --- a/MyIA.AI.Notebooks/GenAI/Vibe-Coding/analyzers/README.md +++ b/MyIA.AI.Notebooks/GenAI/Vibe-Coding/analyzers/README.md @@ -4,14 +4,14 @@ > *The Unexpected AI Stack: C#/.NET, Part 1* (Charles Chen, 08/2026). > Sub-grain [#10500b](https://github.com/jsboige/CoursIA/issues/10500) — packaging > `.csproj` standalone des analyseurs prototypés dans -> [`Roslyn-Code-Guardrails.html`](Roslyn-Code-Guardrails.html) (PR #10502). +> [`Roslyn-Code-Guardrails.html`](Roslyn-Code-Guardrails.ipynb) (PR #10502). > Sub-grain #10500c — extension `AGSEC004` (HttpClient non-constant URL). > Sub-grain #10500d — registry de suppressions `#pragma warning disable AGSECxxx`. > Sub-grain #10500e — extension `AGSEC005` (credentials hardcodées). ## Pourquoi ce dossier -Le notebook [`Roslyn-Code-Guardrails`](Roslyn-Code-Guardrails.html), +Le notebook [`Roslyn-Code-Guardrails`](Roslyn-Code-Guardrails.ipynb), désormais hébergé dans ce dossier `analyzers/`, a prototypé trois analyseurs Roslyn en cellules .NET Interactive (cell 4) et un `CodeFixProvider` (cell 10) — c'est la **démonstration pédagogique** de l'axe. diff --git a/MyIA.AI.Notebooks/IIT/ICT-Series/README.md b/MyIA.AI.Notebooks/IIT/ICT-Series/README.md index 4625765f3f..55fb23c440 100644 --- a/MyIA.AI.Notebooks/IIT/ICT-Series/README.md +++ b/MyIA.AI.Notebooks/IIT/ICT-Series/README.md @@ -235,7 +235,7 @@ La **strate 5 commence ici** : le substrat mesuré n'est plus un système dynami | [ICT-38-SLens-SelfLocation-Python](ICT-38-SLens-SelfLocation-Python.ipynb) | **S-Lens — la représentation porte-t-elle la bonne référence ?** *(strate 5, GPU requis, POC expérimental)* : quand la valeur à produire se trouve à une position déterminée par le **contenu** (et non par la position absolue du token), bancs synthétiques à vérité terrain exacte — lecture par tête et intervention causale appariée | [#15814](https://github.com/jsboige/CoursIA/issues/15814) | | [ICT-39-CompositionRegards-Python](ICT-39-CompositionRegards-Python.ipynb) | **Composition de regards** *(opération 12 « Composer des regards »)* : distinguer la lecture avant (`get`/`play`) de la demande arrière (`put`/`coplay`), les composer réellement, et construire le témoin falsifiable où deux regards composés divergent de leurs lectures isolées — prérequis légers (fonctions, composition, modulo 3) | [#12204](https://github.com/jsboige/CoursIA/issues/12204) | | [ICT-42-InoculationBifurcation-Pilot-Python](ICT-42-InoculationBifurcation-Pilot-Python.ipynb) | **Inoculation et bifurcation représentationnelle — pilote multi-échelle** *(strate 5, GPU-free à la lecture, traces GPU pré-calculées)* : jalon 3 de l'Épic [#8236](https://github.com/jsboige/CoursIA/issues/8236) — la première expérience de la série qui **intervient** sur le réseau au lieu de l'observer. Un panel de 16 features SAE différentielles (code/prose, dérivées GPU-free des références de chaque échelle) est partiellement supprimé (`h' = h − α·δ`) à mi-profondeur, intensité croissante α ∈ {0, 0.25, 0.5, 0.75, 1}, et la divergence des activations SAE est mesurée **au residual final** — après propagation non-linéaire par toutes les couches aval — sur deux échelles (Qwen3-1.7B-Base, Qwen3.5-2B-Base, SAE W32K-L0_50). Ordre-paramètre m(α), netteté (pente max, facteur de rupture vs réponse proportionnelle), profil token-par-token, comparaison cross-échelle + concordance de Spearman par prompt. Résultat : **dissociation de forme** — le 1.7B répond massivement dès α = 0.25 (36 % de sa valeur finale) puis sature sous-proportionnellement (facteur de rupture 2.77 < 4, pente max au premier cran α* = 0.125) ; le 2B absorbe puis **bascule tardivement** (facteur 8.11 > 4, α* = 0.625), transition portée par prose_fr (×11) et dialogue (×10.8) quand code_python reste proportionnel (×4.05) ; Spearman prompts cross-échelle négatif aux quatre intensités (−0.25 à −0.66). *Contrôle de plomberie α = 0 : ids top-k identiques et divergence L1 exactement nulle vs extraction sans hook.* **Contrôle permuté (phase 6)** : sous panel aléatoire de même taille (seed, hors panel différentiel), la réponse chute de 4× à 28× et la bascule super-linéaire du 2B disparaît (m(1)/m(0.25) = 1.18 vs 8.11 sous panel différentiel) — signature portée par le panel, avec le confondant d'activité mesuré (tirage 80-770× moins actif). **Contrôle apparié en norme (phase 6b)** : sous tirage restreint à la bande d'activité [m/8, 8m] (le panel occupe les rangs 1-19 de la distribution d'activité — une bande ×2 n'y laisse que 1-4 candidats), la réponse **revient** (m(1) = 0.1235 au 2B, 5.6× le tirage uniforme, ordre de grandeur du panel) mais la super-linéarité est divisée par 2.4 (×3.38 vs ×8.11) et la sélectivité par jeu disparaît (×3.2-3.9 homogène vs prose_fr ×11.1 sous panel) : **la norme porte l'amplitude, le contenu du panel porte la discrimination** — révision assumée de la lecture de la phase 6. Limites assumées : pas d'hystérésis (clamp par passe), appariement par le bas (tirage réalisé à ~58-67% de l'activité du panel), divergence dans l'espace top-k uniquement, panels indépendants → comparaison de forme, jamais d'amplitude | [#8236](https://github.com/jsboige/CoursIA/issues/8236) | -| [ICT-42b-InoculationBifurcation-9B-Python](ICT-42b-InoculationBifurcation-9B-Python.html) | **Inoculation et bifurcation représentationnelle — 3e échelle (9B) + fidélité J-lens 4 échelles** *(strate 5, GPU-free à la lecture, traces pré-calculées)* : étend le pilote ICT-42 au Qwen3.5-9B-Base (SAE W64K-L0_50, panel différentiel 16 features, inoculation mi-réseau `h' = h − α·δ`) — **la bifurcation recule et s'adoucit** : α* ≈ 0.875 (vs 0.375/0.625), m(1) = 0.33 (vs 1.10/0.65), spécificité préservée (×53 vs panel aléatoire), réorganisation plus que destruction (81 % du top-50 remplacé à m(1) minimal). **Volet fidélité J-lens sur quatre échelles** (1.7B/2B fits locaux, 9B/27B lens publiés `neuronpedia/jacobian-lens`) : le relevé linéaire s'améliore de 1.7B à 2B (KL mi-réseau 12.5 → 8.2 nats) **puis régresse** au 9B (9.4) et au 27B (10.4) — instrument et expérience convergent : la part linéairement propagée d'une écriture mi-réseau rétrécit avec la taille ; au quart de profondeur le mouvement s'inverse (27B 11.9 vs 9B 14.4, l'écart quart→midi resserre de 5.0 à 1.5 nats). Caveat 27B assumé : instruct (pas de jumeau -Base au parc, cf ICT-43) et fit 672 prompts (vs 458) — deux confondants documentés dans le carnet. Contrôles : plomberie α = 0, panel permuté (phase 6), apparié en norme (phase 6b), transparence de provenance (sha256, abandon mesuré du fit local 9B ~8-16 j) | [#8236](https://github.com/jsboige/CoursIA/issues/8236) · [#18086](https://github.com/jsboige/CoursIA/issues/18086) | +| [ICT-42b-InoculationBifurcation-9B-Python](ICT-42b-InoculationBifurcation-9B-Python.ipynb) | **Inoculation et bifurcation représentationnelle — 3e échelle (9B) + fidélité J-lens 4 échelles** *(strate 5, GPU-free à la lecture, traces pré-calculées)* : étend le pilote ICT-42 au Qwen3.5-9B-Base (SAE W64K-L0_50, panel différentiel 16 features, inoculation mi-réseau `h' = h − α·δ`) — **la bifurcation recule et s'adoucit** : α* ≈ 0.875 (vs 0.375/0.625), m(1) = 0.33 (vs 1.10/0.65), spécificité préservée (×53 vs panel aléatoire), réorganisation plus que destruction (81 % du top-50 remplacé à m(1) minimal). **Volet fidélité J-lens sur quatre échelles** (1.7B/2B fits locaux, 9B/27B lens publiés `neuronpedia/jacobian-lens`) : le relevé linéaire s'améliore de 1.7B à 2B (KL mi-réseau 12.5 → 8.2 nats) **puis régresse** au 9B (9.4) et au 27B (10.4) — instrument et expérience convergent : la part linéairement propagée d'une écriture mi-réseau rétrécit avec la taille ; au quart de profondeur le mouvement s'inverse (27B 11.9 vs 9B 14.4, l'écart quart→midi resserre de 5.0 à 1.5 nats). Caveat 27B assumé : instruct (pas de jumeau -Base au parc, cf ICT-43) et fit 672 prompts (vs 458) — deux confondants documentés dans le carnet. Contrôles : plomberie α = 0, panel permuté (phase 6), apparié en norme (phase 6b), transparence de provenance (sha256, abandon mesuré du fit local 9B ~8-16 j) | [#8236](https://github.com/jsboige/CoursIA/issues/8236) · [#18086](https://github.com/jsboige/CoursIA/issues/18086) | | Document | Contenu | Issue | |----------|-------|-------| diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/01-PythonForDataScience/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/01-PythonForDataScience/README.md index b33b0bfa5b..2421e56704 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/01-PythonForDataScience/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/01-PythonForDataScience/README.md @@ -12,14 +12,14 @@ Avant d'orchestrer des agents LLM qui *écrivent* du code data science (labs Lan | Notebook | Contenu | Durée | |----------|---------|-------| -| [1.1-Python](notebooks/1.1-Python_pour_la_Data_Science.html) | types et conversions (`float()` d'import), structures (`list`/`dict`/`tuple`/`set`), fonctions et docstring, compréhensions, fichiers en `with` + encodage explicite, traceback lu de bas en haut | ~60-75 min | -| [1.2-NumPy](notebooks/1.2-Manipulation_de_Donnees_avec_NumPy.html) | `ndarray`, vectorisation (timing vs boucle), broadcasting, indexation/masques booléens, `axis`, `default_rng(seed)` | ~60-75 min | -| [1.3-Pandas](notebooks/1.3-Analyse_de_Donnees_avec_Pandas.html) | `DataFrame`, sélection de colonnes, filtrage booléen, `merge`/`join` (4 `how=`), données manquantes (`isna`/`fillna`/`dropna`), séries temporelles (`to_datetime`, `.dt`, `resample`), `read_csv` réel | ~45 min | -| [1.4-Visualisation](notebooks/1.4-Visualisation_Matplotlib_Seaborn.html) | matplotlib (figure/axes, 4 questions → 4 graphiques), erreurs classiques (axe tronqué, surcharge), seaborn (`hue`, `pairplot`, heatmap de corrélation) — sur manchots de Palmer | ~60 min | -| [1.5-Exploration](notebooks/1.5-Exploration_Nettoyage_Donnees_Reelles.html) | audit (dimensions/types/manquants/doublons), journal des décisions, isotopes et quasi-doublon instruit, référence auteur reproduite à 0 divergence — sur `penguins_raw.csv` | ~75 min | -| [1.6-Statistiques](notebooks/1.6-Statistiques_Descriptives.html) | moyenne/médiane/mode, écart-type et CV, skewness par sous-groupe, corrélation de Pearson et paradoxe de Simpson mesuré (−0,24 / +0,39 à +0,65) — renvoi vers [`Probas/`](../../../Probas/README.md) | ~60 min | - -> **Numérotation.** La série commence à `1.1` (Python strict-minimum pour lire 1.2) — les notebooks `1.2` et `1.3` d'origine sont inchangés. La continuité logique est `1.1` (Python) → `1.2` (NumPy) → `1.3` (Pandas) → `1.4` (Visualisation) → `1.5` (Exploration) → `1.6` (Statistiques) → [Lab 1](../Track1-LangChain/Day1-Foundations/Labs/Lab1-PythonForDataScience.html) (mise en pratique sur ventes synthétiques) → [02-ML-Cours 2.1](../02-ML-Cours/2.1-Workflow-ML.html). +| [1.1-Python](notebooks/1.1-Python_pour_la_Data_Science.ipynb) | types et conversions (`float()` d'import), structures (`list`/`dict`/`tuple`/`set`), fonctions et docstring, compréhensions, fichiers en `with` + encodage explicite, traceback lu de bas en haut | ~60-75 min | +| [1.2-NumPy](notebooks/1.2-Manipulation_de_Donnees_avec_NumPy.ipynb) | `ndarray`, vectorisation (timing vs boucle), broadcasting, indexation/masques booléens, `axis`, `default_rng(seed)` | ~60-75 min | +| [1.3-Pandas](notebooks/1.3-Analyse_de_Donnees_avec_Pandas.ipynb) | `DataFrame`, sélection de colonnes, filtrage booléen, `merge`/`join` (4 `how=`), données manquantes (`isna`/`fillna`/`dropna`), séries temporelles (`to_datetime`, `.dt`, `resample`), `read_csv` réel | ~45 min | +| [1.4-Visualisation](notebooks/1.4-Visualisation_Matplotlib_Seaborn.ipynb) | matplotlib (figure/axes, 4 questions → 4 graphiques), erreurs classiques (axe tronqué, surcharge), seaborn (`hue`, `pairplot`, heatmap de corrélation) — sur manchots de Palmer | ~60 min | +| [1.5-Exploration](notebooks/1.5-Exploration_Nettoyage_Donnees_Reelles.ipynb) | audit (dimensions/types/manquants/doublons), journal des décisions, isotopes et quasi-doublon instruit, référence auteur reproduite à 0 divergence — sur `penguins_raw.csv` | ~75 min | +| [1.6-Statistiques](notebooks/1.6-Statistiques_Descriptives.ipynb) | moyenne/médiane/mode, écart-type et CV, skewness par sous-groupe, corrélation de Pearson et paradoxe de Simpson mesuré (−0,24 / +0,39 à +0,65) — renvoi vers [`Probas/`](../../../Probas/README.md) | ~60 min | + +> **Numérotation.** La série commence à `1.1` (Python strict-minimum pour lire 1.2) — les notebooks `1.2` et `1.3` d'origine sont inchangés. La continuité logique est `1.1` (Python) → `1.2` (NumPy) → `1.3` (Pandas) → `1.4` (Visualisation) → `1.5` (Exploration) → `1.6` (Statistiques) → [Lab 1](../Track1-LangChain/Day1-Foundations/Labs/Lab1-PythonForDataScience.ipynb) (mise en pratique sur ventes synthétiques) → [02-ML-Cours 2.1](../02-ML-Cours/2.1-Workflow-ML.ipynb). ## Objectifs d'apprentissage diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/02-ML-Cours/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/02-ML-Cours/README.md index be5f931dbb..6d71011d32 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/02-ML-Cours/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/02-ML-Cours/README.md @@ -18,110 +18,110 @@ La thèse est volontairement classique : on ne peut évaluer ce qu'un agent gén | Notebook | Sujet | Concept-phare | Dataset | |----------|-------|---------------|---------| -| [2.1-Workflow-ML](2.1-Workflow-ML.html) | Le workflow ML (split → fit → predict → évaluer) | Surapprentissage rendu **visible** (sweep `max_depth` 1→25) | synthétique `make_*` | -| [2.2-Descente-de-gradient](2.2-Descente-de-gradient.html) | Ouvrir la boîte noire de `fit()` | 3 learning rates (lent / bon / **divergeant**) | synthétique `make_regression` | -| [2.3-Regression-lineaire-logistique](2.3-Regression-lineaire-logistique.html) | Régression linéaire (OLS) vs logistique (MLE) | **OLS vs MLE** : droite vs sigmoïde sur mêmes labels binaires | synthétique `make_*` | -| [2.3b-Naive-Bayes-Generatif](2.3b-Naive-Bayes-Generatif.html) | Bayésien naïf génératif vs régression logistique discriminative | **Génératif vs discriminatif** : modéliser P(x\|y) puis Bayes, ou P(y\|x) directement — l'hypothèse d'indépendance coûte du biais | synthétique (corrélations homogènes et en bloc) | -| [2.3c-Regression-Grande-Dimension](2.3c-Regression-Grande-Dimension.html) | p >> n : ridge, PCR (composantes principales), PLS (composantes supervisées) | **Var ≠ valeur prédictive** : la PLS trouve en 5 composantes ce que la PCR paie à 44 | synthétique (blocs corrélés, SEED=42) | -| [2.3d-Modele-Gaussien-LDA-QDA](2.3d-Modele-Gaussien-LDA-QDA.html) | Modèle gaussien : analyse discriminante linéaire (LDA) vs quadratique (QDA) | **L'hypothèse de covariance décide la frontière** : partagée → droite (LDA), propre → conique (QDA) | synthétique `make_*` (régimes contrôlés) | -| [2.4-Arbres-Forets-Ensembles](2.4-Arbres-Forets-Ensembles.html) | Arbres, forêt aléatoire, gradient boosting | **Réduction de variance** : frontière en escalier vs lisse | réel `load_breast_cancer` | -| [2.4b-AdaBoost-From-Scratch](2.4b-AdaBoost-From-Scratch.html) | *Accrétion de 2.4* — AdaBoost (SAMME) écrit à la main : stump à erreur pondérée, vote α = ½ln((1−ε)/ε), repondération des exemples, borne d'erreur ∏2√(ε(1−ε)) vérifiée | **Les poids rendus visibles** : la masse migre vers les exemples difficiles, l'escalier du comité émerge des demi-plans pondérés | réel `load_breast_cancer` | -| [2.5-Biais-Variance-CV-ROC](2.5-Biais-Variance-CV-ROC.html) | Compromis biais-variance, validation croisée, ROC/AUC | **ROC + coût du seuil** : faux négatifs vs faux positifs | réel `load_breast_cancer` | -| [2.5b-Calibration-Probabilites](2.5b-Calibration-Probabilites.html) | Calibration des probabilités : reliability diagrams, ECE, Brier | **Pourquoi 0.87 n'est pas 87 % de chances** : discrimination vs calibration, la diagonale du reliability diagram | réel `load_breast_cancer` | -| [2.5c-Equite-Sous-Groupes](2.5c-Equite-Sous-Groupes.html) | Équité par sous-groupe : parité démographique, equalized odds, l'incompatibilité des trois métriques sous prévalences différentes (Chouldechova) et le post-traitement par seuils par groupe (Hardt) | **L'accuracy globale ne suffit pas** : 96,4 % global coexiste avec deux groupes à [0,977–0,995] et [0,922–0,957] | synthétique contrôlé (2 groupes, prévalences réglables) | -| [2.5d-Derive-Distribution-Deploiement](2.5d-Derive-Distribution-Deploiement.html) | Dérive de distribution au déploiement : trois dérives construites volontairement (covariable, étiquette, concept), chacune mesurée par l'écart entre ce que la validation croisée annonce et ce que le déploiement produit ; trois détecteurs (test à deux échantillons, classifieur discriminant, MMD) réimplémentés puis confrontés à `alibi-detect` | **Deux dérives sur trois se corrigent** : la covariable par pondération d'importance, l'étiquette par BBSE — la dérive de concept ne se corrige pas sans nouvelles étiquettes, et le carnet le montre | synthétique contrôlé (régimes entraînement/déploiement réglables) | -| [2.6-Clustering-KMeans-PCA](2.6-Clustering-KMeans-PCA.html) | Apprentissage non supervisé : KMeans + ACP | **Structure retrouvée sans étiquettes** (PCA 2D + reconstruction) | réel `load_digits` | -| [2.7-Modeles-Non-Parametriques](2.7-Modeles-Non-Parametriques.html) | SVM à noyau et k plus proches voisins | **Le kernel trick rendu visible** (linéaire vs RBF sur demi-lunes) | synthétique `make_moons` + réel `load_breast_cancer` | -| [2.7b-SMO-From-Scratch](2.7b-SMO-From-Scratch.html) | *Accrétion de 2.7* — SMO (Platt) écrit à la main : sous-problème 2D (dont la branche dégénérée `η ≤ 0`), cascade de working set, KKT et gap de dualité | **Le solveur écrit à la main retrouve sklearn** : même biais à 4·10⁻⁴ près, gap de dualité ≈ 3·10⁻³, pire violation KKT ponctuelle ≈ 10⁻³ | synthétique `make_moons` | -| [2.7c-SVM-SOTA-Comparison](2.7c-SVM-SOTA-Comparison.html) | *Accrétion de 2.7b* — le SOTA (LIBSVM sous `sklearn.svm.SVC`) lu sous le capot : dual reconstruit depuis `dual_coef_`, gap de dualité et violations KKT mesurés sur LIBSVM, working set au second ordre et shrinking, tolérance d'arrêt comme contrat | **Le SOTA n'achète pas la solution, il achète le temps** : même optimum et mêmes 48 supports que la SMO maison, trois ordres de grandeur plus vite (fit sub-milliseconde contre 1,19 s) — les deux solveurs s'arrêtent à `tol` près | synthétique `make_moons` (graine de 2.7b) | -| [2.8-Theorie-PAC](2.8-Theorie-PAC.html) | Théorie PAC : sample complexity et dimension VC | **La borne PAC prédit l'empirique** (m_min théorique vs courbe d'erreur) | synthétique `make_*` | -| [2.8b-Theorie-PAC-Lean](2.8b-Theorie-PAC-Lean.html) | *Compagnon Lean* (kernel `lean4-wsl`) — la même borne, **démontrée** plutôt que mesurée | **Ce que 2.8 constate, le lake le prouve** : Hoeffding, borne de l'union, ERM, complexité d'échantillon | aucun (arithmétique exacte) | -| [2.8c-Borne-Temoin-Concentration](2.8c-Borne-Temoin-Concentration.html) | *Carte transversale + compagnon numérique Python* — Novikoff, témoin extrémal et Hoeffding bilatérale sur des instances seedées | **Mesurer avant de certifier** : 2.8c rejoue les trois phénomènes en NumPy ; 2.8b et 2.8d portent les preuves Lean | synthétique seedé | -| [2.8d-Lean-Novikoff-Convergence](2.8d-Lean-Novikoff-Convergence.html) | *Compagnon Lean* (kernel `lean4-wsl`) — la moitié Perceptron du lake, **exécutée** : Novikoff `n·γ² ≤ R²`, ses deux lemmes, son témoin de saturation | **Le théorème interrogé en direct** : `#check` + `#print axioms` depuis le lake, dynamique rejouée sur entiers, balayage de marge | aucun (arithmétique exacte) | -| [2.9-Grokking-Generalisation](2.9-Grokking-Generalisation.html) | *Épilogue, amorce du [3.5](../03-DeepLearning/3.5-Phenomenes-de-Generalisation.html)* — grokking : la généralisation qui arrive en retard (premier réseau de neurones, PyTorch boîte noire) | **L'horloge cachée** : embeddings rangés en cercle après le grok (ACP + Fourier) | synthétique `(a+b) mod 97` | -| [2.9b-GenEFT-Theorie-Effective](2.9b-GenEFT-Theorie-Effective.html) | *Accrétion de 2.9* — GenEFT (Baek, Liu & Tegmark 2024), théorie effective de la généralisation : bits de description, fraction critique, gap inductif, puis dynamique des « repons » | **Le ratio des learning rates décide** : frontière arctan (Théorème 3), diagramme de phase en pente −1, règle η_dec/η_enc ≲ 10 | synthétique (graphe de connaissances n=30 : mod 3, mod 5, greater-than, biparti) | -| [2.9c-Grokking-Diagrammes-Phases](2.9c-Grokking-Diagrammes-Phases.html) | *Accrétion de 2.9* — la cartographie de R02 (Liu, Michaud & Tegmark 2022) : les 4 phases (compréhension, grokking, mémorisation, confusion), la course encoder/decoder, RQI et généralisation par parallélogrammes, grokking MNIST, ticket de loterie aux axes | **Le grokking est une zone frontière** : carte des phases multi-seed (Table 1 exacte) où le grokking apparaît coincé entre compréhension et mémorisation, et l'accuracy de validation continue qui révèle où vivent les frontières | synthétique `(a+b)` non modulaire + réel MNIST (1 000 ex., App J) | -| [2.9d-Features-Circulaires-Helice-Nombres](2.9d-Features-Circulaires-Helice-Nombres.html) | *Accrétion de 2.9* — features circulaires des jours/mois (R10, Engels et al.) et hélice des nombres (R07, Kantamneni & Tegmark) sur modèles-jouets white-box : ACP des activations, intervention causale par rotation, FFT des états cachés | **La géométrie latente prédit les échecs** : une droite à R²=0.974 condamne l'addition linéaire à 6.8 % (le modèle : ~100 %) ; les erreurs se concentrent à ±5 = un tour de l'horloge dominante | synthétique `days/months later`, `(a+b) mod 97`, `a+b` (0..149) | -| [2.9e-MIPS-Extraction-Programme](2.9e-MIPS-Extraction-Programme.html) | *Chaînon aval du [2.9](2.9-Grokking-Generalisation.html)* — MIPS : extraire le programme qu'un réseau entraîné implémente déjà (Michaud et al. 2024, [arXiv:2402.05110](https://arxiv.org/abs/2402.05110)) | **Du réseau au programme vérifié** : états cachés → machine à états → autoencodeur booléen (les $4!$ assignations essayées) → régression symbolique → **ripple-carry adder**, vérifié exhaustivement | synthétique `s + t` sur 6 bits | +| [2.1-Workflow-ML](2.1-Workflow-ML.ipynb) | Le workflow ML (split → fit → predict → évaluer) | Surapprentissage rendu **visible** (sweep `max_depth` 1→25) | synthétique `make_*` | +| [2.2-Descente-de-gradient](2.2-Descente-de-gradient.ipynb) | Ouvrir la boîte noire de `fit()` | 3 learning rates (lent / bon / **divergeant**) | synthétique `make_regression` | +| [2.3-Regression-lineaire-logistique](2.3-Regression-lineaire-logistique.ipynb) | Régression linéaire (OLS) vs logistique (MLE) | **OLS vs MLE** : droite vs sigmoïde sur mêmes labels binaires | synthétique `make_*` | +| [2.3b-Naive-Bayes-Generatif](2.3b-Naive-Bayes-Generatif.ipynb) | Bayésien naïf génératif vs régression logistique discriminative | **Génératif vs discriminatif** : modéliser P(x\|y) puis Bayes, ou P(y\|x) directement — l'hypothèse d'indépendance coûte du biais | synthétique (corrélations homogènes et en bloc) | +| [2.3c-Regression-Grande-Dimension](2.3c-Regression-Grande-Dimension.ipynb) | p >> n : ridge, PCR (composantes principales), PLS (composantes supervisées) | **Var ≠ valeur prédictive** : la PLS trouve en 5 composantes ce que la PCR paie à 44 | synthétique (blocs corrélés, SEED=42) | +| [2.3d-Modele-Gaussien-LDA-QDA](2.3d-Modele-Gaussien-LDA-QDA.ipynb) | Modèle gaussien : analyse discriminante linéaire (LDA) vs quadratique (QDA) | **L'hypothèse de covariance décide la frontière** : partagée → droite (LDA), propre → conique (QDA) | synthétique `make_*` (régimes contrôlés) | +| [2.4-Arbres-Forets-Ensembles](2.4-Arbres-Forets-Ensembles.ipynb) | Arbres, forêt aléatoire, gradient boosting | **Réduction de variance** : frontière en escalier vs lisse | réel `load_breast_cancer` | +| [2.4b-AdaBoost-From-Scratch](2.4b-AdaBoost-From-Scratch.ipynb) | *Accrétion de 2.4* — AdaBoost (SAMME) écrit à la main : stump à erreur pondérée, vote α = ½ln((1−ε)/ε), repondération des exemples, borne d'erreur ∏2√(ε(1−ε)) vérifiée | **Les poids rendus visibles** : la masse migre vers les exemples difficiles, l'escalier du comité émerge des demi-plans pondérés | réel `load_breast_cancer` | +| [2.5-Biais-Variance-CV-ROC](2.5-Biais-Variance-CV-ROC.ipynb) | Compromis biais-variance, validation croisée, ROC/AUC | **ROC + coût du seuil** : faux négatifs vs faux positifs | réel `load_breast_cancer` | +| [2.5b-Calibration-Probabilites](2.5b-Calibration-Probabilites.ipynb) | Calibration des probabilités : reliability diagrams, ECE, Brier | **Pourquoi 0.87 n'est pas 87 % de chances** : discrimination vs calibration, la diagonale du reliability diagram | réel `load_breast_cancer` | +| [2.5c-Equite-Sous-Groupes](2.5c-Equite-Sous-Groupes.ipynb) | Équité par sous-groupe : parité démographique, equalized odds, l'incompatibilité des trois métriques sous prévalences différentes (Chouldechova) et le post-traitement par seuils par groupe (Hardt) | **L'accuracy globale ne suffit pas** : 96,4 % global coexiste avec deux groupes à [0,977–0,995] et [0,922–0,957] | synthétique contrôlé (2 groupes, prévalences réglables) | +| [2.5d-Derive-Distribution-Deploiement](2.5d-Derive-Distribution-Deploiement.ipynb) | Dérive de distribution au déploiement : trois dérives construites volontairement (covariable, étiquette, concept), chacune mesurée par l'écart entre ce que la validation croisée annonce et ce que le déploiement produit ; trois détecteurs (test à deux échantillons, classifieur discriminant, MMD) réimplémentés puis confrontés à `alibi-detect` | **Deux dérives sur trois se corrigent** : la covariable par pondération d'importance, l'étiquette par BBSE — la dérive de concept ne se corrige pas sans nouvelles étiquettes, et le carnet le montre | synthétique contrôlé (régimes entraînement/déploiement réglables) | +| [2.6-Clustering-KMeans-PCA](2.6-Clustering-KMeans-PCA.ipynb) | Apprentissage non supervisé : KMeans + ACP | **Structure retrouvée sans étiquettes** (PCA 2D + reconstruction) | réel `load_digits` | +| [2.7-Modeles-Non-Parametriques](2.7-Modeles-Non-Parametriques.ipynb) | SVM à noyau et k plus proches voisins | **Le kernel trick rendu visible** (linéaire vs RBF sur demi-lunes) | synthétique `make_moons` + réel `load_breast_cancer` | +| [2.7b-SMO-From-Scratch](2.7b-SMO-From-Scratch.ipynb) | *Accrétion de 2.7* — SMO (Platt) écrit à la main : sous-problème 2D (dont la branche dégénérée `η ≤ 0`), cascade de working set, KKT et gap de dualité | **Le solveur écrit à la main retrouve sklearn** : même biais à 4·10⁻⁴ près, gap de dualité ≈ 3·10⁻³, pire violation KKT ponctuelle ≈ 10⁻³ | synthétique `make_moons` | +| [2.7c-SVM-SOTA-Comparison](2.7c-SVM-SOTA-Comparison.ipynb) | *Accrétion de 2.7b* — le SOTA (LIBSVM sous `sklearn.svm.SVC`) lu sous le capot : dual reconstruit depuis `dual_coef_`, gap de dualité et violations KKT mesurés sur LIBSVM, working set au second ordre et shrinking, tolérance d'arrêt comme contrat | **Le SOTA n'achète pas la solution, il achète le temps** : même optimum et mêmes 48 supports que la SMO maison, trois ordres de grandeur plus vite (fit sub-milliseconde contre 1,19 s) — les deux solveurs s'arrêtent à `tol` près | synthétique `make_moons` (graine de 2.7b) | +| [2.8-Theorie-PAC](2.8-Theorie-PAC.ipynb) | Théorie PAC : sample complexity et dimension VC | **La borne PAC prédit l'empirique** (m_min théorique vs courbe d'erreur) | synthétique `make_*` | +| [2.8b-Theorie-PAC-Lean](2.8b-Theorie-PAC-Lean.ipynb) | *Compagnon Lean* (kernel `lean4-wsl`) — la même borne, **démontrée** plutôt que mesurée | **Ce que 2.8 constate, le lake le prouve** : Hoeffding, borne de l'union, ERM, complexité d'échantillon | aucun (arithmétique exacte) | +| [2.8c-Borne-Temoin-Concentration](2.8c-Borne-Temoin-Concentration.ipynb) | *Carte transversale + compagnon numérique Python* — Novikoff, témoin extrémal et Hoeffding bilatérale sur des instances seedées | **Mesurer avant de certifier** : 2.8c rejoue les trois phénomènes en NumPy ; 2.8b et 2.8d portent les preuves Lean | synthétique seedé | +| [2.8d-Lean-Novikoff-Convergence](2.8d-Lean-Novikoff-Convergence.ipynb) | *Compagnon Lean* (kernel `lean4-wsl`) — la moitié Perceptron du lake, **exécutée** : Novikoff `n·γ² ≤ R²`, ses deux lemmes, son témoin de saturation | **Le théorème interrogé en direct** : `#check` + `#print axioms` depuis le lake, dynamique rejouée sur entiers, balayage de marge | aucun (arithmétique exacte) | +| [2.9-Grokking-Generalisation](2.9-Grokking-Generalisation.ipynb) | *Épilogue, amorce du [3.5](../03-DeepLearning/3.5-Phenomenes-de-Generalisation.ipynb)* — grokking : la généralisation qui arrive en retard (premier réseau de neurones, PyTorch boîte noire) | **L'horloge cachée** : embeddings rangés en cercle après le grok (ACP + Fourier) | synthétique `(a+b) mod 97` | +| [2.9b-GenEFT-Theorie-Effective](2.9b-GenEFT-Theorie-Effective.ipynb) | *Accrétion de 2.9* — GenEFT (Baek, Liu & Tegmark 2024), théorie effective de la généralisation : bits de description, fraction critique, gap inductif, puis dynamique des « repons » | **Le ratio des learning rates décide** : frontière arctan (Théorème 3), diagramme de phase en pente −1, règle η_dec/η_enc ≲ 10 | synthétique (graphe de connaissances n=30 : mod 3, mod 5, greater-than, biparti) | +| [2.9c-Grokking-Diagrammes-Phases](2.9c-Grokking-Diagrammes-Phases.ipynb) | *Accrétion de 2.9* — la cartographie de R02 (Liu, Michaud & Tegmark 2022) : les 4 phases (compréhension, grokking, mémorisation, confusion), la course encoder/decoder, RQI et généralisation par parallélogrammes, grokking MNIST, ticket de loterie aux axes | **Le grokking est une zone frontière** : carte des phases multi-seed (Table 1 exacte) où le grokking apparaît coincé entre compréhension et mémorisation, et l'accuracy de validation continue qui révèle où vivent les frontières | synthétique `(a+b)` non modulaire + réel MNIST (1 000 ex., App J) | +| [2.9d-Features-Circulaires-Helice-Nombres](2.9d-Features-Circulaires-Helice-Nombres.ipynb) | *Accrétion de 2.9* — features circulaires des jours/mois (R10, Engels et al.) et hélice des nombres (R07, Kantamneni & Tegmark) sur modèles-jouets white-box : ACP des activations, intervention causale par rotation, FFT des états cachés | **La géométrie latente prédit les échecs** : une droite à R²=0.974 condamne l'addition linéaire à 6.8 % (le modèle : ~100 %) ; les erreurs se concentrent à ±5 = un tour de l'horloge dominante | synthétique `days/months later`, `(a+b) mod 97`, `a+b` (0..149) | +| [2.9e-MIPS-Extraction-Programme](2.9e-MIPS-Extraction-Programme.ipynb) | *Chaînon aval du [2.9](2.9-Grokking-Generalisation.ipynb)* — MIPS : extraire le programme qu'un réseau entraîné implémente déjà (Michaud et al. 2024, [arXiv:2402.05110](https://arxiv.org/abs/2402.05110)) | **Du réseau au programme vérifié** : états cachés → machine à états → autoencodeur booléen (les $4!$ assignations essayées) → régression symbolique → **ripple-carry adder**, vérifié exhaustivement | synthétique `s + t` sur 6 bits | | [2.9f-Grokking-Theorie-Effective-Lean](2.9f-Grokking-Theorie-Effective-Lean.ipynb) | *Compagnon Lean* (kernel `lean4-wsl`) du module `EffectiveTheory` — la théorie effective de la représentation de R02 (Liu, Michaud & Tegmark 2022), cette fois **instanciée** : `prop1_zeroLoss` monté en `example`, `parallelogram_iff_eq` employé comme réécriture, `#print axioms` lu, identité d'Euler du théorème `loss0_grad_dot_self` **mesurée** sur un embedding effectivement entraîné | **Ce que le `#check` affiche, l'instanciation l'éprouve** : les parallélogrammes et la conservation de `Z₀` cessent d'être des signatures pour devenir des théorèmes appliqués et des quantités vérifiées | aucun (arithmétique exacte) | -| [2.10-Optimisation-Hyperparametres](2.10-Optimisation-Hyperparametres.html) | La méthodologie du réglage : grille, hasard, bayésien (TPE) — et quand s'arrêter | **Le budget qui s'aplatit** : le bayésien s'installe dès le premier tiers du budget ; le critère d'arrêt économise la moitié des essais | synthétique `make_classification` (MLP) | -| [2.11-Regularisation-Sparse-LASSO](2.11-Regularisation-Sparse-LASSO.html) | *Régularisation sparse* — LASSO (L1, polyèdre) vs Ridge (L2, boule), coord descent, sélection de λ, cas pathologique colinéarité (ElasticNet) | **La géométrie décide** : polyèdre L1 → sparsity (sélection de variables), boule L2 → shrink continu ; sur features corrélées, LASSO est arbitraire et ElasticNet stabilise | synthétique `design_sparse(n, p, k, snr)` | -| [2.11b-Proximal-Operators-From-Scratch](2.11b-Proximal-Operators-From-Scratch.html) | *Pend direct de 2.11 (LASSO)* — opérateurs proximaux : ISTA (forward-backward splitting) et FISTA (inertie de Nesterov, `O(1/k²)`) pour le Lasso ; sparse recovery synthétique `n=200, p=500, k=30` | **Quatre solveurs convergent vers la même solution** : ISTA, FISTA, `sklearn.Lasso` (coord descent) et `cvxpy` CLARABEL (SOCP) donnent tous `‖x−x*‖₂ ≈ 0.13` ; FISTA gagne ~k fois en itérations vs ISTA | synthétique (signal sparse gaussien, mesures bruitées) | -| [2.11c-Lasso-SOTA-Comparison](2.11c-Lasso-SOTA-Comparison.html) | *SOTA du bloc LASSO* — coordinate descent from scratch (le moteur réel de `sklearn.Lasso`), `LassoCV` pour le λ, mise à l'échelle `p` croissant (500 → 4000) | **Le λ se mesure, il ne se déclare pas** : LassoCV retient ~100× le seuil Donoho-Johnstone théorique (λ ≈ 0,25 contre 0,0125) et restitue la parcimonie juste (30 non-nuls, 26/30 du support) là où l'a priori surestime (92) | synthétique (même problème sparse que 2.11b, seed partagé) | -| [2.11d-Optimisation-ADMM-From-Scratch](2.11d-Optimisation-ADMM-From-Scratch.html) | *ADMM from scratch* — split `β = z`, opérateur proximal en brique élémentaire, pré-factorisation Cholesky, balayage du paramètre `ρ` | **Un seul optimum, plusieurs chemins** : sur design corrélé `ρ_corr = 0,95` (κ ≈ 80), coord-descente, sklearn et cvxpy coïncident à ~10⁻⁷ et ADMM à 2,1·10⁻³ — exactement sa tolérance d'arrêt ; `ρ` change la trajectoire, pas la solution | synthétique (design AR(1) corrélé, formulation `β = z` scindée) | -| [2.11e-CVXPY-Optimisation](2.11e-CVXPY-Optimisation.html) | *Troisième voie (bloc B.7) — le déclaratif* — le problème écrit, pas la méthode : le Lasso en une ligne `cvxpy`, la reformulation canonique lue sur ce que le solveur reçoit (500 inconnues déclarées → 1200 variables, épigraphe), un problème trois solveurs (CLARABEL, SCS, OSQP), le certificat KKT lu dans les variables duales, `λmax = ‖Aᵀb‖∞` calculé par le solveur seul | **Quatre moteurs, un optimum à 10⁻⁶ près** : cvxpy, coord descent scratch, ISTA et sklearn coïncident sur P1 ; le déclaratif paie sa généralité à l'échelle mais gagne la course du changement — group Lasso ou forme contrainte sans écrire un nouvel algorithme, convexité certifiée par le ruleset DCP | synthétique (même problème sparse que 2.11b, seed partagé) | -| [2.11f-Comparaison-Optimisation-Convexe](2.11f-Comparaison-Optimisation-Convexe.html) | *Clôture de la chaîne (bloc B.8)* — le tableau croisé bloc A / bloc B : six solveurs Lasso (ISTA, FISTA, ADMM, coord descent, sklearn, cvxpy) re-mesurés dans un même processus sur P1 et deux solveurs SVM (SMO maison vs LIBSVM) sur le terrain de 2.7b/2.7c ; objectif, itérations à unités nommées, LOC à deux portées étiquetées, sondes d'échelle (`n` et `p` croissants) | **Le SOTA achète le temps, le from scratch achète la visibilité** : mêmes optima et mêmes vecteurs supports partout (certificats croisés, dont l'égalité calculée avec la baseline committée de 2.7b) ; des itérations non comparables d'une ligne à l'autre sans nommer l'unité ; LOC bibliothèque = surface d'appel, jamais l'implémentation | synthétiques des parents (`make_moons` seed 42 ; P1 sparse seed 42) | -| [2.12-Donnees-Desequilibrees](2.12-Donnees-Desequilibrees.html) | *Classes déséquilibrées* — la métrique qui ment (accuracy vs PR), stratégies de rééchantillonnage, seuillage par coût | **La courbe PR dit la vérité** : sur une classe à ~3 %, la ROC flatte, seule l'average precision rend l'arbitrage visible | synthétique `make_classification` (~3 % positifs) | -| [2.13-Analyse-Erreurs](2.13-Analyse-Erreurs.html) | Le geste du praticien : diagnostiquer un modèle entraîné (tranches, worst-k, plan d'action) | **La poche invisible** : 67.6% d'erreur sur ~5% de la population, cachée dans un score global correct (82.2%) | synthétique télécom (churn, incident d'étiquetage) | -| [2.14-Explicabilite-SHAP-LIME-Contrefactuels](2.14-Explicabilite-SHAP-LIME-Contrefactuels.html) | Expliquer une décision individuelle : SHAP (arbre + kernel), LIME, contrefactuels DiCE — et leurs limites communes | **Additivité exacte vs récits instables** : Tree SHAP se vérifie à 1e-16, LIME varie de seed en seed (σ jusqu'à 0.035), le contrefactuel est un autre récit | réel German Credit (credit-g, 1000×21, CSV vendé) | -| [2.14b-XAI-Shap-Attribution-Causal-Bridge](2.14b-XAI-Shap-Attribution-Causal-Bridge.html) | *Pont attribution ↔ causalité* — Kernel SHAP marginal contre Tree SHAP conditionnel sur un DAG explicite (`age -> credit_amount -> default`), sur l'individu idx=773 ; puis LIME, DiCE et un contrefactuel `age=42` | **L'attribution reste une fonction du background dataset** : écarts marginal/conditionnel en valeur absolue mais même signe des contributions ; l'additivité se vérifie (base + somme φ = 0.9400 vs P(default\|x) = 0.940) ; un contrefactuel (`age=42`, f(x') = 0.7200) n'est **pas** une intervention `do(.)` — l'exercice 3 (les distinguer) reste à compléter | DAG simulé (2 features, 1000 individus) | -| [2.15-Donnee-Comme-Responsabilite-Python](2.15-Donnee-Comme-Responsabilite-Python.html) | *La donnée comme responsabilité* — inférence d'appartenance (MIA) menée pour de vrai, confidentialité différentielle : mécanisme de Laplace, DP-SGD écrit à la main puis confronté au SOTA diffprivlib (IBM), datasheet et model card | **La protection se mesure, elle ne se déclare pas** : la forêt qui mémorise laisse fuir ses données (avantage d'attaque +0.439, AUC 0.719) quand la régression régularisée, qui généralise, retombe à +0.057 ; face à diffprivlib, le DP-SGD maison est « cohérent en tendance, divergent en ampleur » | réel `load_breast_cancer` | +| [2.10-Optimisation-Hyperparametres](2.10-Optimisation-Hyperparametres.ipynb) | La méthodologie du réglage : grille, hasard, bayésien (TPE) — et quand s'arrêter | **Le budget qui s'aplatit** : le bayésien s'installe dès le premier tiers du budget ; le critère d'arrêt économise la moitié des essais | synthétique `make_classification` (MLP) | +| [2.11-Regularisation-Sparse-LASSO](2.11-Regularisation-Sparse-LASSO.ipynb) | *Régularisation sparse* — LASSO (L1, polyèdre) vs Ridge (L2, boule), coord descent, sélection de λ, cas pathologique colinéarité (ElasticNet) | **La géométrie décide** : polyèdre L1 → sparsity (sélection de variables), boule L2 → shrink continu ; sur features corrélées, LASSO est arbitraire et ElasticNet stabilise | synthétique `design_sparse(n, p, k, snr)` | +| [2.11b-Proximal-Operators-From-Scratch](2.11b-Proximal-Operators-From-Scratch.ipynb) | *Pend direct de 2.11 (LASSO)* — opérateurs proximaux : ISTA (forward-backward splitting) et FISTA (inertie de Nesterov, `O(1/k²)`) pour le Lasso ; sparse recovery synthétique `n=200, p=500, k=30` | **Quatre solveurs convergent vers la même solution** : ISTA, FISTA, `sklearn.Lasso` (coord descent) et `cvxpy` CLARABEL (SOCP) donnent tous `‖x−x*‖₂ ≈ 0.13` ; FISTA gagne ~k fois en itérations vs ISTA | synthétique (signal sparse gaussien, mesures bruitées) | +| [2.11c-Lasso-SOTA-Comparison](2.11c-Lasso-SOTA-Comparison.ipynb) | *SOTA du bloc LASSO* — coordinate descent from scratch (le moteur réel de `sklearn.Lasso`), `LassoCV` pour le λ, mise à l'échelle `p` croissant (500 → 4000) | **Le λ se mesure, il ne se déclare pas** : LassoCV retient ~100× le seuil Donoho-Johnstone théorique (λ ≈ 0,25 contre 0,0125) et restitue la parcimonie juste (30 non-nuls, 26/30 du support) là où l'a priori surestime (92) | synthétique (même problème sparse que 2.11b, seed partagé) | +| [2.11d-Optimisation-ADMM-From-Scratch](2.11d-Optimisation-ADMM-From-Scratch.ipynb) | *ADMM from scratch* — split `β = z`, opérateur proximal en brique élémentaire, pré-factorisation Cholesky, balayage du paramètre `ρ` | **Un seul optimum, plusieurs chemins** : sur design corrélé `ρ_corr = 0,95` (κ ≈ 80), coord-descente, sklearn et cvxpy coïncident à ~10⁻⁷ et ADMM à 2,1·10⁻³ — exactement sa tolérance d'arrêt ; `ρ` change la trajectoire, pas la solution | synthétique (design AR(1) corrélé, formulation `β = z` scindée) | +| [2.11e-CVXPY-Optimisation](2.11e-CVXPY-Optimisation.ipynb) | *Troisième voie (bloc B.7) — le déclaratif* — le problème écrit, pas la méthode : le Lasso en une ligne `cvxpy`, la reformulation canonique lue sur ce que le solveur reçoit (500 inconnues déclarées → 1200 variables, épigraphe), un problème trois solveurs (CLARABEL, SCS, OSQP), le certificat KKT lu dans les variables duales, `λmax = ‖Aᵀb‖∞` calculé par le solveur seul | **Quatre moteurs, un optimum à 10⁻⁶ près** : cvxpy, coord descent scratch, ISTA et sklearn coïncident sur P1 ; le déclaratif paie sa généralité à l'échelle mais gagne la course du changement — group Lasso ou forme contrainte sans écrire un nouvel algorithme, convexité certifiée par le ruleset DCP | synthétique (même problème sparse que 2.11b, seed partagé) | +| [2.11f-Comparaison-Optimisation-Convexe](2.11f-Comparaison-Optimisation-Convexe.ipynb) | *Clôture de la chaîne (bloc B.8)* — le tableau croisé bloc A / bloc B : six solveurs Lasso (ISTA, FISTA, ADMM, coord descent, sklearn, cvxpy) re-mesurés dans un même processus sur P1 et deux solveurs SVM (SMO maison vs LIBSVM) sur le terrain de 2.7b/2.7c ; objectif, itérations à unités nommées, LOC à deux portées étiquetées, sondes d'échelle (`n` et `p` croissants) | **Le SOTA achète le temps, le from scratch achète la visibilité** : mêmes optima et mêmes vecteurs supports partout (certificats croisés, dont l'égalité calculée avec la baseline committée de 2.7b) ; des itérations non comparables d'une ligne à l'autre sans nommer l'unité ; LOC bibliothèque = surface d'appel, jamais l'implémentation | synthétiques des parents (`make_moons` seed 42 ; P1 sparse seed 42) | +| [2.12-Donnees-Desequilibrees](2.12-Donnees-Desequilibrees.ipynb) | *Classes déséquilibrées* — la métrique qui ment (accuracy vs PR), stratégies de rééchantillonnage, seuillage par coût | **La courbe PR dit la vérité** : sur une classe à ~3 %, la ROC flatte, seule l'average precision rend l'arbitrage visible | synthétique `make_classification` (~3 % positifs) | +| [2.13-Analyse-Erreurs](2.13-Analyse-Erreurs.ipynb) | Le geste du praticien : diagnostiquer un modèle entraîné (tranches, worst-k, plan d'action) | **La poche invisible** : 67.6% d'erreur sur ~5% de la population, cachée dans un score global correct (82.2%) | synthétique télécom (churn, incident d'étiquetage) | +| [2.14-Explicabilite-SHAP-LIME-Contrefactuels](2.14-Explicabilite-SHAP-LIME-Contrefactuels.ipynb) | Expliquer une décision individuelle : SHAP (arbre + kernel), LIME, contrefactuels DiCE — et leurs limites communes | **Additivité exacte vs récits instables** : Tree SHAP se vérifie à 1e-16, LIME varie de seed en seed (σ jusqu'à 0.035), le contrefactuel est un autre récit | réel German Credit (credit-g, 1000×21, CSV vendé) | +| [2.14b-XAI-Shap-Attribution-Causal-Bridge](2.14b-XAI-Shap-Attribution-Causal-Bridge.ipynb) | *Pont attribution ↔ causalité* — Kernel SHAP marginal contre Tree SHAP conditionnel sur un DAG explicite (`age -> credit_amount -> default`), sur l'individu idx=773 ; puis LIME, DiCE et un contrefactuel `age=42` | **L'attribution reste une fonction du background dataset** : écarts marginal/conditionnel en valeur absolue mais même signe des contributions ; l'additivité se vérifie (base + somme φ = 0.9400 vs P(default\|x) = 0.940) ; un contrefactuel (`age=42`, f(x') = 0.7200) n'est **pas** une intervention `do(.)` — l'exercice 3 (les distinguer) reste à compléter | DAG simulé (2 features, 1000 individus) | +| [2.15-Donnee-Comme-Responsabilite-Python](2.15-Donnee-Comme-Responsabilite-Python.ipynb) | *La donnée comme responsabilité* — inférence d'appartenance (MIA) menée pour de vrai, confidentialité différentielle : mécanisme de Laplace, DP-SGD écrit à la main puis confronté au SOTA diffprivlib (IBM), datasheet et model card | **La protection se mesure, elle ne se déclare pas** : la forêt qui mémorise laisse fuir ses données (avantage d'attaque +0.439, AUC 0.719) quand la régression régularisée, qui généralise, retombe à +0.057 ; face à diffprivlib, le DP-SGD maison est « cohérent en tendance, divergent en ampleur » | réel `load_breast_cancer` | -> **Épilogue — au-delà du socle scikit-learn.** Les huit chapitres ci-dessus posent le socle canonique. Le notebook [2.9](2.9-Grokking-Generalisation.html) fait un pas de côté vers le **deep learning** : il entraîne le premier réseau de neurones de la série (PyTorch, quelques minutes sur CPU) pour montrer le **grokking** — la généralisation qui surgit longtemps *après* la mémorisation parfaite, un phénomène que la borne PAC (2.8) ne laissait pas prévoir — et réutilise l'ACP du 2.6 pour révéler la structure apprise. Il joue le rôle d'**amorce** : le traitement canonique — montage réécrit en NumPy pur (gradient à la main), contre-témoin isolant le weight-decay, double descente — est le [3.5 — Phénomènes de généralisation](../03-DeepLearning/3.5-Phenomenes-de-Generalisation.html) de la série Deep Learning, dont les exercices portent les leviers classiques (weight-decay, seuil de données) ; ceux du 2.9 lui sont propres (horloge, modulus, dimension d'embedding). Son accrétion [2.9b](2.9b-GenEFT-Theorie-Effective.html) apporte la contrepartie théorique — **GenEFT**, la théorie effective de la généralisation : la longueur en bits de la relation fixe la **fraction critique** de données, et la dynamique encodeur/décodeur (les « repons », leur quantité conservée) prédit une **frontière arctan** entre mémorisation et généralisation qui ne dépend que du ratio des learning rates — le grokking devient un régime calculable. Son accrétion [2.9c](2.9c-Grokking-Diagrammes-Phases.html) fait la **cartographie** : les quatre phases de l'apprentissage définies par la théorie effective de R02 (Liu, Michaud & Tegmark 2022) — compréhension, grokking, mémorisation, confusion — mesurées sur un toy à decoder appris multi-seed (le grokking y apparaît comme une **zone frontière** entre compréhension et mémorisation, pas un régime à rechercher), confirmées sur MNIST (App J), puis relues par le **ticket de loterie aux axes** (App K) — où le ticket se révèle **forgé par l'entraînement** plutôt qu'hérité de l'initialisation. +> **Épilogue — au-delà du socle scikit-learn.** Les huit chapitres ci-dessus posent le socle canonique. Le notebook [2.9](2.9-Grokking-Generalisation.ipynb) fait un pas de côté vers le **deep learning** : il entraîne le premier réseau de neurones de la série (PyTorch, quelques minutes sur CPU) pour montrer le **grokking** — la généralisation qui surgit longtemps *après* la mémorisation parfaite, un phénomène que la borne PAC (2.8) ne laissait pas prévoir — et réutilise l'ACP du 2.6 pour révéler la structure apprise. Il joue le rôle d'**amorce** : le traitement canonique — montage réécrit en NumPy pur (gradient à la main), contre-témoin isolant le weight-decay, double descente — est le [3.5 — Phénomènes de généralisation](../03-DeepLearning/3.5-Phenomenes-de-Generalisation.ipynb) de la série Deep Learning, dont les exercices portent les leviers classiques (weight-decay, seuil de données) ; ceux du 2.9 lui sont propres (horloge, modulus, dimension d'embedding). Son accrétion [2.9b](2.9b-GenEFT-Theorie-Effective.ipynb) apporte la contrepartie théorique — **GenEFT**, la théorie effective de la généralisation : la longueur en bits de la relation fixe la **fraction critique** de données, et la dynamique encodeur/décodeur (les « repons », leur quantité conservée) prédit une **frontière arctan** entre mémorisation et généralisation qui ne dépend que du ratio des learning rates — le grokking devient un régime calculable. Son accrétion [2.9c](2.9c-Grokking-Diagrammes-Phases.ipynb) fait la **cartographie** : les quatre phases de l'apprentissage définies par la théorie effective de R02 (Liu, Michaud & Tegmark 2022) — compréhension, grokking, mémorisation, confusion — mesurées sur un toy à decoder appris multi-seed (le grokking y apparaît comme une **zone frontière** entre compréhension et mémorisation, pas un régime à rechercher), confirmées sur MNIST (App J), puis relues par le **ticket de loterie aux axes** (App K) — où le ticket se révèle **forgé par l'entraînement** plutôt qu'hérité de l'initialisation. -> **La carte des phases du grokking.** L'accrétion [2.9c](2.9c-Grokking-Diagrammes-Phases.html) transforme la courbe isolée du 2.9 en cartographie, avec les critères **exacts** de la Table 1 de R02 (seuils 90 %, retard 10³ steps). Le toy à decoder hard-codé ne peut **pas** mémoriser : RQI = 1.000 et validation parfaite à toute fraction de données, et la généralisation par **parallélogrammes** dAcc borne inférieurement l'accuracy réelle (0.609 ≤ 0.890 à 25 % des paires, convergence à 75 %) sans toucher au jeu de validation. Sur le toy à decoder appris (100 runs multi-seed vectorisés en ~36 s), la carte learning-rate-decoder × fraction révèle le grokking comme **une seule cellule frontière** entre compréhension et mémorisation, sur un paysage d'accuracy continue (0.03 → 0.90) — pas un régime à rechercher, un symptôme de réglage. Sur MNIST (App J : 1 000 exemples, MSE one-hot, tête lente), un seul levier sépare les phases : init ×10 → mémorisation figée (train 1.000, val 0.130 sur 25 000 steps), init standard → compréhension (val 0.905, seuil 60 % franchi au step 500). Et le **ticket de loterie aux axes** (App K) referme le questionnement du 2.9 : la structure circulaire n'est **pas** en germe à l'initialisation (corrélation circulaire r = 0.075 ≈ bruit) — le ticket est forgé — mais la solution vit sur peu d'axes : 10 directions sur 32 suffisent à 0.930 d'accuracy (protocole Fig 22 exact : projection sur les n PCs du final, reconstruction, decoder gelé). +> **La carte des phases du grokking.** L'accrétion [2.9c](2.9c-Grokking-Diagrammes-Phases.ipynb) transforme la courbe isolée du 2.9 en cartographie, avec les critères **exacts** de la Table 1 de R02 (seuils 90 %, retard 10³ steps). Le toy à decoder hard-codé ne peut **pas** mémoriser : RQI = 1.000 et validation parfaite à toute fraction de données, et la généralisation par **parallélogrammes** dAcc borne inférieurement l'accuracy réelle (0.609 ≤ 0.890 à 25 % des paires, convergence à 75 %) sans toucher au jeu de validation. Sur le toy à decoder appris (100 runs multi-seed vectorisés en ~36 s), la carte learning-rate-decoder × fraction révèle le grokking comme **une seule cellule frontière** entre compréhension et mémorisation, sur un paysage d'accuracy continue (0.03 → 0.90) — pas un régime à rechercher, un symptôme de réglage. Sur MNIST (App J : 1 000 exemples, MSE one-hot, tête lente), un seul levier sépare les phases : init ×10 → mémorisation figée (train 1.000, val 0.130 sur 25 000 steps), init standard → compréhension (val 0.905, seuil 60 % franchi au step 500). Et le **ticket de loterie aux axes** (App K) referme le questionnement du 2.9 : la structure circulaire n'est **pas** en germe à l'initialisation (corrélation circulaire r = 0.075 ≈ bruit) — le ticket est forgé — mais la solution vit sur peu d'axes : 10 directions sur 32 suffisent à 0.930 d'accuracy (protocole Fig 22 exact : projection sur les n PCs du final, reconstruction, decoder gelé). -> **Les cercles et l'hélice — la géométrie du latent.** Le notebook [2.9d](2.9d-Features-Circulaires-Helice-Nombres.html) poursuit l'épilogue en remontant d'un cran : si l'horloge du 2.9 est un cercle, ces cercles sont-ils des objets de calcul à part entière — et que deviennent les nombres hors du monde modulaire ? Deux papiers de la même école servent de fil. **R10** (Engels et al., ICLR 2025) : les jours et les mois vivent sur des **features circulaires irréductibles**, causalement actives chez Mistral 7B — tourner la représentation décale la réponse. **R07** (Kantamneni & Tegmark) : les entiers vivent sur une **hélice** — une massue linéaire enroulée d'horloges périodiques — et cette géométrie **prédit les performances avant toute prédiction**. Sur des modèles-jouets entraînés from scratch (white-box total, kernel GPU `coursia-ml-training` comme le 2.8c), le notebook mesure chaque pièce : le cercle des jours, déformé en ACP brute mais causal (rotation 6/7 de tour → +2 jours cohérents 7/7) ; le cercle des mois au même montage ; l'horloge mod-97 rangée à la fréquence dominante k\*=35 (R²=0.998 là où l'ACP naïve à la fréquence 1 donne ~0) mais **sans plan causal unique** (rotation : 0 % — négatif honnête, contrasté avec les LLM du papier) ; le contrepoint P=7 ; l'hélice de l'addition 0..149 avec les horloges **mesurées** du jouet (T ≈ 2.4/3.4/5.4, pas les {2,5,10,100} héritées de Qwen) ; la punchline de l'annexe E (une droite explique R²=0.974 de la représentation, donc l'addition linéaire échoue : 6.8 % contre ~100 % pour le modèle — le modèle comme **code correcteur d'erreurs**) ; et l'anatomie des erreurs de l'annexe F (88 % des erreurs à ±5, exactement un tour de l'horloge dominante T=5.36 — le quantum d'erreur d'un modèle qui calcule en trigonométrie). Les exercices portent les indices d'irréductibilité S(f) et Mϵ(f) de R10 et le test du χ² sur quanta arbitraires. +> **Les cercles et l'hélice — la géométrie du latent.** Le notebook [2.9d](2.9d-Features-Circulaires-Helice-Nombres.ipynb) poursuit l'épilogue en remontant d'un cran : si l'horloge du 2.9 est un cercle, ces cercles sont-ils des objets de calcul à part entière — et que deviennent les nombres hors du monde modulaire ? Deux papiers de la même école servent de fil. **R10** (Engels et al., ICLR 2025) : les jours et les mois vivent sur des **features circulaires irréductibles**, causalement actives chez Mistral 7B — tourner la représentation décale la réponse. **R07** (Kantamneni & Tegmark) : les entiers vivent sur une **hélice** — une massue linéaire enroulée d'horloges périodiques — et cette géométrie **prédit les performances avant toute prédiction**. Sur des modèles-jouets entraînés from scratch (white-box total, kernel GPU `coursia-ml-training` comme le 2.8c), le notebook mesure chaque pièce : le cercle des jours, déformé en ACP brute mais causal (rotation 6/7 de tour → +2 jours cohérents 7/7) ; le cercle des mois au même montage ; l'horloge mod-97 rangée à la fréquence dominante k\*=35 (R²=0.998 là où l'ACP naïve à la fréquence 1 donne ~0) mais **sans plan causal unique** (rotation : 0 % — négatif honnête, contrasté avec les LLM du papier) ; le contrepoint P=7 ; l'hélice de l'addition 0..149 avec les horloges **mesurées** du jouet (T ≈ 2.4/3.4/5.4, pas les {2,5,10,100} héritées de Qwen) ; la punchline de l'annexe E (une droite explique R²=0.974 de la représentation, donc l'addition linéaire échoue : 6.8 % contre ~100 % pour le modèle — le modèle comme **code correcteur d'erreurs**) ; et l'anatomie des erreurs de l'annexe F (88 % des erreurs à ±5, exactement un tour de l'horloge dominante T=5.36 — le quantum d'erreur d'un modèle qui calcule en trigonométrie). Les exercices portent les indices d'irréductibilité S(f) et Mϵ(f) de R10 et le test du χ² sur quanta arbitraires. -> **Les compagnons formels et numériques.** Le notebook [2.8b](2.8b-Theorie-PAC-Lean.html) tourne sous kernel **Lean 4** (`lean4-wsl`) et suit module par module la moitié statistique du lake [`learning_theory_lean/`](../../learning_theory_lean/README.md). Là où 2.8 *observe* que la borne PAC prédit la courbe d'erreur empirique, 2.8b en rend les étapes exécutables — `expect`/Markov, MGF de Bernoulli, Hoeffding, borne de l'union, ERM, complexité d'échantillon — avec les **noms de déclarations du lake**. Le compagnon [2.8d](2.8d-Lean-Novikoff-Convergence.html) fait de même pour la **moitié Perceptron** : borne de Novikoff `n·γ² ≤ R²`, lemmes de croissance et témoin de saturation, interrogés en direct sous `lean4-wsl`, avec une dynamique rejouée sur entiers. Entre eux, [2.8c](2.8c-Borne-Temoin-Concentration.html) reste la **carte transversale et le compagnon numérique Python** : il rejoue en NumPy la borne, le témoin et Hoeffding sous kernel `coursia-ml-training`. Ainsi, 2.8c mesure sur des instances explicites tandis que 2.8b et 2.8d certifient les énoncés généraux. C'est la même paire empirique/formel que la série ML annonce dans sa section [Théorie formelle (Lean)](../../README.md#théorie-formelle-lean) (EPIC #11703). Le compagnon [2.9f](2.9f-Grokking-Theorie-Effective-Lean.ipynb) porte le même geste sur l'autre versant du lake — le module `EffectiveTheory` (théorie effective de la représentation, R02) : là où le carnet `SL-1b` de la série `SymbolicAI/SymbolicLearning` (§8) présente ces déclarations par `#check`, 2.9f les **instancie** (`prop1_zeroLoss` monté en `example`, `parallelogram_iff_eq` employé comme réécriture, `#print axioms` pour l'intégrité de la preuve) et **mesure** sur un embedding entraîné l'identité d'Euler que `loss0_grad_dot_self` démontre — une preuve sans mesure ne dit pas que le modèle étudié est dans son domaine, une mesure sans preuve ne dit pas pourquoi elle tient. +> **Les compagnons formels et numériques.** Le notebook [2.8b](2.8b-Theorie-PAC-Lean.ipynb) tourne sous kernel **Lean 4** (`lean4-wsl`) et suit module par module la moitié statistique du lake [`learning_theory_lean/`](../../learning_theory_lean/README.md). Là où 2.8 *observe* que la borne PAC prédit la courbe d'erreur empirique, 2.8b en rend les étapes exécutables — `expect`/Markov, MGF de Bernoulli, Hoeffding, borne de l'union, ERM, complexité d'échantillon — avec les **noms de déclarations du lake**. Le compagnon [2.8d](2.8d-Lean-Novikoff-Convergence.ipynb) fait de même pour la **moitié Perceptron** : borne de Novikoff `n·γ² ≤ R²`, lemmes de croissance et témoin de saturation, interrogés en direct sous `lean4-wsl`, avec une dynamique rejouée sur entiers. Entre eux, [2.8c](2.8c-Borne-Temoin-Concentration.ipynb) reste la **carte transversale et le compagnon numérique Python** : il rejoue en NumPy la borne, le témoin et Hoeffding sous kernel `coursia-ml-training`. Ainsi, 2.8c mesure sur des instances explicites tandis que 2.8b et 2.8d certifient les énoncés généraux. C'est la même paire empirique/formel que la série ML annonce dans sa section [Théorie formelle (Lean)](../../README.md#théorie-formelle-lean) (EPIC #11703). Le compagnon [2.9f](2.9f-Grokking-Theorie-Effective-Lean.ipynb) porte le même geste sur l'autre versant du lake — le module `EffectiveTheory` (théorie effective de la représentation, R02) : là où le carnet `SL-1b` de la série `SymbolicAI/SymbolicLearning` (§8) présente ces déclarations par `#check`, 2.9f les **instancie** (`prop1_zeroLoss` monté en `example`, `parallelogram_iff_eq` employé comme réécriture, `#print axioms` pour l'intégrité de la preuve) et **mesure** sur un embedding entraîné l'identité d'Euler que `loss0_grad_dot_self` démontre — une preuve sans mesure ne dit pas que le modèle étudié est dans son domaine, une mesure sans preuve ne dit pas pourquoi elle tient. -> **Au-delà du socle — classes déséquilibrées.** Le notebook [2.12](2.12-Donnees-Desequilibrees.html) sort du cadre des huit chapitres pour traiter le cas où la classe d'intérêt est rare (fraude, défaut, anomalie, régime de marché). La ROC y apparaît comme une métrique qui **ment** — sur une classe à ~3 %, le taux de faux positifs reste bas *par construction* — et la **courbe Precision-Recall** comme la métrique honnête. Cinq stratégies y sont comparées sur le même protocole multi-seed (`class_weight`, sous-échantillonnage, sur-échantillonnage naïf, SMOTE, et « ne rien faire »), avec la matrice de confusion et la courbe PR pour chacune ; le tableau final montre qu'**aucune stratégie ne domine partout** — le choix dépend du coût d'un faux négatif face à un faux positif. Le seuil optimal n'y est pas `0.5` mais celui qui minimise le **coût attendu** (pont vers la théorie de la décision), et le piège de la **fuite SMOTE-avant-split** y est démontré puis corrigé. -> **Le geste du praticien.** Le notebook [2.13](2.13-Analyse-Erreurs.html) ferme la boucle : mesurer (2.4, 2.5) ne suffit pas, il faut **diagnostiquer**. Sur un modèle au score global correct (accuracy 82.2%, aucune alerte), l'analyse par tranches révèle une **poche** à 67.6% d'erreur — 115 étiquettes d'entraînement corrompues par un incident d'intégration, invisibles de toute métrique globale. Le workflow : tranches → worst-k (les deux côtés de la matrice) → confiance → cause → correction **mesurée** (−42.3 points sur la poche) — ce qui distingue un praticien d'un tourneur d'hyperparamètres (le tuning, lui, ne répare rien : 67.6% → 67.6%). -> **Ouvrir la boîte noire, honnêtement.** Le notebook [2.14](2.14-Explicabilite-SHAP-LIME-Contrefactuels.html) prend le relais du diagnostic : expliquer **une décision individuelle** — pourquoi ce dossier-là, à 70.7% de risque ? Trois moteurs réels consommés (pas de réimplémentation jouet) : **Tree SHAP** (exact, additivité vérifiée à 1.1e-16), **Kernel SHAP** (espace brut, le pipeline comme boîte noire — même top-5, reconstruction exacte), **LIME** (surrogate local linéaire, R² 0.496) et **DiCE** pour les contrefactuels (3 plans d'action, probabilité ramenée de 0.707 à ~0.35-0.40). Le fil rouge honnête : ces outils produisent des **récits**, pas des causes — LIME instable de seed en seed (σ jusqu'à 0.0352), la base de référence SHAP déplace la valeur de base (0.3135 vs 0.2132) sans changer le classement, et Rudin 2019 rappelle qu'un modèle intrinsèquement interprétable évite le problème. Ponts posés vers Causal-Bridges/ (SHAP n'est **pas** de la causalité), PyMC-05 et Infer-5 (inférence causale), Tweety-11 (argumentation). -> **L'attribution face à la causalité.** Le notebook [2.14b](2.14b-XAI-Shap-Attribution-Causal-Bridge.html) franchit le pont annoncé par 2.14 : sur un DAG explicite (`age → credit_amount → default`), il confronte **Kernel SHAP marginal** et **Tree SHAP conditionnel** sur le même individu (idx=773) — l'additivité se vérifie au dix-millième (base + somme φ = 0.9400 vs P(default|x) = 0.940), mais les écarts marginal/conditionnel rappellent que **l'attribution est une fonction du background dataset**, pas de la structure causale. Et le geste décisif : un contrefactuel DiCE (`age=42`, f(x') = 0.7200) n'est **pas** une intervention `do(·)` — l'exercice 3 demande de les distinguer. C'est le même honnête « récit ≠ cause » que 2.14, descendu d'un cran, jusqu'au seuil de l'inférence causale proprement dite (PyMC-05, Infer-5). -> **La donnée comme responsabilité.** Le notebook [2.15](2.15-Donnee-Comme-Responsabilite-Python.html) referme le triptyque du praticien : diagnostiquer (2.13), expliquer (2.14), puis **protéger les personnes derrière les données**. L'attaque par inférence d'appartenance y est menée pour de vrai : la confiance du modèle en ses exemples d'entraînement sert de signal, et la forêt qui mémorise offre un avantage d'attaque de +0.439 (AUC 0.719) là où la régression régularisée, qui généralise, retombe à +0.057 — la première protection contre la fuite est la généralisation elle-même. Vient ensuite la confidentialité différentielle : le mécanisme de Laplace (bruit calibré par le budget epsilon), le **DP-SGD écrit à la main** (clipper chaque gradient, bruiter chaque lot, composer le budget), la courbe utilité/confidentialité mesurée, puis la confrontation au SOTA **diffprivlib** consommé tel quel — verdict honnête du notebook : cohérent en tendance, divergent en ampleur. La datasheet (Gebru et al. 2018) et la model card (Mitchell et al. 2019) ferment le parcours : sur un jeu de données médical, documenter provenance, limites et usages est une responsabilité, pas une formalité. +> **Au-delà du socle — classes déséquilibrées.** Le notebook [2.12](2.12-Donnees-Desequilibrees.ipynb) sort du cadre des huit chapitres pour traiter le cas où la classe d'intérêt est rare (fraude, défaut, anomalie, régime de marché). La ROC y apparaît comme une métrique qui **ment** — sur une classe à ~3 %, le taux de faux positifs reste bas *par construction* — et la **courbe Precision-Recall** comme la métrique honnête. Cinq stratégies y sont comparées sur le même protocole multi-seed (`class_weight`, sous-échantillonnage, sur-échantillonnage naïf, SMOTE, et « ne rien faire »), avec la matrice de confusion et la courbe PR pour chacune ; le tableau final montre qu'**aucune stratégie ne domine partout** — le choix dépend du coût d'un faux négatif face à un faux positif. Le seuil optimal n'y est pas `0.5` mais celui qui minimise le **coût attendu** (pont vers la théorie de la décision), et le piège de la **fuite SMOTE-avant-split** y est démontré puis corrigé. +> **Le geste du praticien.** Le notebook [2.13](2.13-Analyse-Erreurs.ipynb) ferme la boucle : mesurer (2.4, 2.5) ne suffit pas, il faut **diagnostiquer**. Sur un modèle au score global correct (accuracy 82.2%, aucune alerte), l'analyse par tranches révèle une **poche** à 67.6% d'erreur — 115 étiquettes d'entraînement corrompues par un incident d'intégration, invisibles de toute métrique globale. Le workflow : tranches → worst-k (les deux côtés de la matrice) → confiance → cause → correction **mesurée** (−42.3 points sur la poche) — ce qui distingue un praticien d'un tourneur d'hyperparamètres (le tuning, lui, ne répare rien : 67.6% → 67.6%). +> **Ouvrir la boîte noire, honnêtement.** Le notebook [2.14](2.14-Explicabilite-SHAP-LIME-Contrefactuels.ipynb) prend le relais du diagnostic : expliquer **une décision individuelle** — pourquoi ce dossier-là, à 70.7% de risque ? Trois moteurs réels consommés (pas de réimplémentation jouet) : **Tree SHAP** (exact, additivité vérifiée à 1.1e-16), **Kernel SHAP** (espace brut, le pipeline comme boîte noire — même top-5, reconstruction exacte), **LIME** (surrogate local linéaire, R² 0.496) et **DiCE** pour les contrefactuels (3 plans d'action, probabilité ramenée de 0.707 à ~0.35-0.40). Le fil rouge honnête : ces outils produisent des **récits**, pas des causes — LIME instable de seed en seed (σ jusqu'à 0.0352), la base de référence SHAP déplace la valeur de base (0.3135 vs 0.2132) sans changer le classement, et Rudin 2019 rappelle qu'un modèle intrinsèquement interprétable évite le problème. Ponts posés vers Causal-Bridges/ (SHAP n'est **pas** de la causalité), PyMC-05 et Infer-5 (inférence causale), Tweety-11 (argumentation). +> **L'attribution face à la causalité.** Le notebook [2.14b](2.14b-XAI-Shap-Attribution-Causal-Bridge.ipynb) franchit le pont annoncé par 2.14 : sur un DAG explicite (`age → credit_amount → default`), il confronte **Kernel SHAP marginal** et **Tree SHAP conditionnel** sur le même individu (idx=773) — l'additivité se vérifie au dix-millième (base + somme φ = 0.9400 vs P(default|x) = 0.940), mais les écarts marginal/conditionnel rappellent que **l'attribution est une fonction du background dataset**, pas de la structure causale. Et le geste décisif : un contrefactuel DiCE (`age=42`, f(x') = 0.7200) n'est **pas** une intervention `do(·)` — l'exercice 3 demande de les distinguer. C'est le même honnête « récit ≠ cause » que 2.14, descendu d'un cran, jusqu'au seuil de l'inférence causale proprement dite (PyMC-05, Infer-5). +> **La donnée comme responsabilité.** Le notebook [2.15](2.15-Donnee-Comme-Responsabilite-Python.ipynb) referme le triptyque du praticien : diagnostiquer (2.13), expliquer (2.14), puis **protéger les personnes derrière les données**. L'attaque par inférence d'appartenance y est menée pour de vrai : la confiance du modèle en ses exemples d'entraînement sert de signal, et la forêt qui mémorise offre un avantage d'attaque de +0.439 (AUC 0.719) là où la régression régularisée, qui généralise, retombe à +0.057 — la première protection contre la fuite est la généralisation elle-même. Vient ensuite la confidentialité différentielle : le mécanisme de Laplace (bruit calibré par le budget epsilon), le **DP-SGD écrit à la main** (clipper chaque gradient, bruiter chaque lot, composer le budget), la courbe utilité/confidentialité mesurée, puis la confrontation au SOTA **diffprivlib** consommé tel quel — verdict honnête du notebook : cohérent en tendance, divergent en ampleur. La datasheet (Gebru et al. 2018) et la model card (Mitchell et al. 2019) ferment le parcours : sur un jeu de données médical, documenter provenance, limites et usages est une responsabilité, pas une formalité. -> **La méthodologie du réglage.** Le notebook [2.10](2.10-Optimisation-Hyperparametres.html) assume le rôle que le 2.13 laisse en creux — celui du « tourneur d'hyperparamètres » — et le fait **honnêtement** : un espace de recherche mixte (continu, discret, conditionnel) sur un MLP, un budget commun de 45 essais, et les trois stratégies superposées sur la courbe *meilleur score vs nombre d'essais* (médiane sur 3 graines, bande min–max). La grille exhaustive y explose en dimension (6300 configurations, 0.7 % couvertes), le hasard tient l'argument de couverture de Bergstra & Bengio, et le search bayésien (TPE/Optuna, **consommé**, pas réécrit) s'installe dès le premier tiers du budget. Le vrai concept-phare est le **critère d'arrêt** : un gain marginal explicite (arrêter si le meilleur n'a pas gagné δ sur les K derniers essais) qui économise 21 à 31 essais sur 45 pour un coût de 2 à 8 millièmes d'AUC. C'est la méthodologie transverse que réutilisent les sweeps du ML-Training-Pipeline et l'ablation du Lab14. +> **La méthodologie du réglage.** Le notebook [2.10](2.10-Optimisation-Hyperparametres.ipynb) assume le rôle que le 2.13 laisse en creux — celui du « tourneur d'hyperparamètres » — et le fait **honnêtement** : un espace de recherche mixte (continu, discret, conditionnel) sur un MLP, un budget commun de 45 essais, et les trois stratégies superposées sur la courbe *meilleur score vs nombre d'essais* (médiane sur 3 graines, bande min–max). La grille exhaustive y explose en dimension (6300 configurations, 0.7 % couvertes), le hasard tient l'argument de couverture de Bergstra & Bengio, et le search bayésien (TPE/Optuna, **consommé**, pas réécrit) s'installe dès le premier tiers du budget. Le vrai concept-phare est le **critère d'arrêt** : un gain marginal explicite (arrêter si le meilleur n'a pas gagné δ sur les K derniers essais) qui économise 21 à 31 essais sur 45 pour un coût de 2 à 8 millièmes d'AUC. C'est la méthodologie transverse que réutilisent les sweeps du ML-Training-Pipeline et l'ablation du Lab14. -> **La régularisation sparse.** Le notebook [2.11](2.11-Regularisation-Sparse-LASSO.html) comble le trou que la série laissait en suspens entre [2.3c](2.3c-Regression-Grande-Dimension.html) (Ridge L2 en grande dimension) et [2.10](2.10-Optimisation-Hyperparametres.html) (méthodologie du réglage, où LassoCV apparaissait en passant) : la **géométrie** de la contrainte — boule L2 pour Ridge (shrink continu) vs polyèdre L1 pour LASSO (sparsity, sélection de variables). Sur 50 features dont 5 vraiment actives (SNR ≈ 4), LASSO retrouve ~80-100 % du support actif en 5-7 coefficients non-nuls, Ridge distribue les poids sur les 50. La **coord descent** from-scratch (10-50 itérations, soft-thresholding `S(z,λ) = sign(z)·max(|z|-λ, 0)`) est validée à 1e-3 près contre `sklearn.linear_model.Lasso`. **LassoCV** sélectionne λ automatiquement (grille logspace + CV 5 folds, sub-seconde). Le **cas pathologique** : sur 3 paires de features corrélées à ρ = 0.7, LASSO devient **arbitraire** (alterne `b₀ = 0` ou `b₁ = 0` selon le tirage) ; **ElasticNet** (`l1_ratio = 0.7`) distribue le poids sur les deux features de chaque paire — la **règle pratique** : ElasticNet dès que des features corrélées sont attendues. Le **chemin de régularisation** `β(λ)` trace l'arrivée progressive des features : λ grand → 0 non-nuls, λ intermédiaire → les 5 vraies features, λ petit → bruit. Le tout avec 3 exercices (C.1 stubs) sur le λ qui tue la sélection, le SNR faible où Ridge bat LASSO en MSE, et la stabilité d'ElasticNet sur paires corrélées. +> **La régularisation sparse.** Le notebook [2.11](2.11-Regularisation-Sparse-LASSO.ipynb) comble le trou que la série laissait en suspens entre [2.3c](2.3c-Regression-Grande-Dimension.ipynb) (Ridge L2 en grande dimension) et [2.10](2.10-Optimisation-Hyperparametres.ipynb) (méthodologie du réglage, où LassoCV apparaissait en passant) : la **géométrie** de la contrainte — boule L2 pour Ridge (shrink continu) vs polyèdre L1 pour LASSO (sparsity, sélection de variables). Sur 50 features dont 5 vraiment actives (SNR ≈ 4), LASSO retrouve ~80-100 % du support actif en 5-7 coefficients non-nuls, Ridge distribue les poids sur les 50. La **coord descent** from-scratch (10-50 itérations, soft-thresholding `S(z,λ) = sign(z)·max(|z|-λ, 0)`) est validée à 1e-3 près contre `sklearn.linear_model.Lasso`. **LassoCV** sélectionne λ automatiquement (grille logspace + CV 5 folds, sub-seconde). Le **cas pathologique** : sur 3 paires de features corrélées à ρ = 0.7, LASSO devient **arbitraire** (alterne `b₀ = 0` ou `b₁ = 0` selon le tirage) ; **ElasticNet** (`l1_ratio = 0.7`) distribue le poids sur les deux features de chaque paire — la **règle pratique** : ElasticNet dès que des features corrélées sont attendues. Le **chemin de régularisation** `β(λ)` trace l'arrivée progressive des features : λ grand → 0 non-nuls, λ intermédiaire → les 5 vraies features, λ petit → bruit. Le tout avec 3 exercices (C.1 stubs) sur le λ qui tue la sélection, le SNR faible où Ridge bat LASSO en MSE, et la stabilité d'ElasticNet sur paires corrélées. -> **Les opérateurs proximaux.** Le notebook [2.11b](2.11b-Proximal-Operators-From-Scratch.html) prend le **relais algorithmique** que le 2.11 (LASSO coord descent) laissait en suspens : comment minimiser un objectif composite `f(x) + λ·‖x‖₁` où `f` est lisse et `‖x‖₁` ne l'est pas ? **ISTA** alterne un pas de gradient sur `f` et un **soft-thresholding** `S_λ(x) = sign(x)·max(|x|−λ, 0)` ; **FISTA** ajoute l'inertie de Nesterov et passe d'une convergence `O(1/k)` à `O(1/k²)`. Le notebook pose un problème de **sparse recovery** canonique (signal `x* ∈ ℝ^500` à `k=30` coefficients actifs, `n=200` mesures bruitées, ratio `n/p = 0.40`) et confronte **quatre solveurs** sur le même problème : ISTA from-scratch (numpy), FISTA from-scratch (numpy), `sklearn.Lasso` (coordinate descent) et `cvxpy` CLARABEL (SOCP, vérité terrain). Mesure : les quatre convergent vers la même solution à `‖x−x*‖₂ ≈ 0.13` près (rappel du support ≈ 93 %), FISTA gagne un facteur `~k` en itérations vs ISTA, et `sklearn.Lasso` reste le plus rapide (coord descent par colonne). Trois exercices (C.1 stubs) ferment le notebook : soft-thresholding vectorisé sur matrice, ISTA avec backtracking de Lipschitz (Beck & Teboulle 2009 Algo 3.1), et FISTA sur **Elastic Net proximal** (L1 + ridge). Pont direct vers 2.11 (Lasso coord descent) et 2.7b (SMO, autre solveur d'un problème dual). +> **Les opérateurs proximaux.** Le notebook [2.11b](2.11b-Proximal-Operators-From-Scratch.ipynb) prend le **relais algorithmique** que le 2.11 (LASSO coord descent) laissait en suspens : comment minimiser un objectif composite `f(x) + λ·‖x‖₁` où `f` est lisse et `‖x‖₁` ne l'est pas ? **ISTA** alterne un pas de gradient sur `f` et un **soft-thresholding** `S_λ(x) = sign(x)·max(|x|−λ, 0)` ; **FISTA** ajoute l'inertie de Nesterov et passe d'une convergence `O(1/k)` à `O(1/k²)`. Le notebook pose un problème de **sparse recovery** canonique (signal `x* ∈ ℝ^500` à `k=30` coefficients actifs, `n=200` mesures bruitées, ratio `n/p = 0.40`) et confronte **quatre solveurs** sur le même problème : ISTA from-scratch (numpy), FISTA from-scratch (numpy), `sklearn.Lasso` (coordinate descent) et `cvxpy` CLARABEL (SOCP, vérité terrain). Mesure : les quatre convergent vers la même solution à `‖x−x*‖₂ ≈ 0.13` près (rappel du support ≈ 93 %), FISTA gagne un facteur `~k` en itérations vs ISTA, et `sklearn.Lasso` reste le plus rapide (coord descent par colonne). Trois exercices (C.1 stubs) ferment le notebook : soft-thresholding vectorisé sur matrice, ISTA avec backtracking de Lipschitz (Beck & Teboulle 2009 Algo 3.1), et FISTA sur **Elastic Net proximal** (L1 + ridge). Pont direct vers 2.11 (Lasso coord descent) et 2.7b (SMO, autre solveur d'un problème dual). -> **Le λ mesuré, le SOTA libéré.** Le notebook [2.11c](2.11c-Lasso-SOTA-Comparison.html) referme le geste SOTA côté Lasso, symétrique du [2.7c](2.7c-SVM-SOTA-Comparison.html) côté SVM : la **coordinate descent from scratch** y est écrite comme le *moteur réel* de `sklearn.Lasso` (pas une réimplémentation jouet — le même algorithme, `α = λ/n` près), puis `LassoCV` prend le relais pour le choix de λ. La mesure phare est un désaveu de l'a priori : le seuil universel de Donoho-Johnstone (`λ = 0.0125`) surestime le support (92 non-nuls, vérité : 30), quand la CV retient `λ ≈ 0.25` — **cent fois le théorique** — et restitue la parcimonie juste (30 non-nuls, 26/30 du support). Les trois moteurs (ISTA, CD scratch, sklearn) coïncident à l'objectif près (`10⁻⁶`) et à `4·10⁻³` en solution, et l'échelle `p` (500 → 4000) montre le **quand SOTA** : à `p=4000`, ISTA vectorisé et sklearn convergent au même ordre (~0,2 s) quand la boucle Python paie ~1 s — le from scratch est la compréhension, le SOTA est l'échelle. +> **Le λ mesuré, le SOTA libéré.** Le notebook [2.11c](2.11c-Lasso-SOTA-Comparison.ipynb) referme le geste SOTA côté Lasso, symétrique du [2.7c](2.7c-SVM-SOTA-Comparison.ipynb) côté SVM : la **coordinate descent from scratch** y est écrite comme le *moteur réel* de `sklearn.Lasso` (pas une réimplémentation jouet — le même algorithme, `α = λ/n` près), puis `LassoCV` prend le relais pour le choix de λ. La mesure phare est un désaveu de l'a priori : le seuil universel de Donoho-Johnstone (`λ = 0.0125`) surestime le support (92 non-nuls, vérité : 30), quand la CV retient `λ ≈ 0.25` — **cent fois le théorique** — et restitue la parcimonie juste (30 non-nuls, 26/30 du support). Les trois moteurs (ISTA, CD scratch, sklearn) coïncident à l'objectif près (`10⁻⁶`) et à `4·10⁻³` en solution, et l'échelle `p` (500 → 4000) montre le **quand SOTA** : à `p=4000`, ISTA vectorisé et sklearn convergent au même ordre (~0,2 s) quand la boucle Python paie ~1 s — le from scratch est la compréhension, le SOTA est l'échelle. -> **ADMM : découper pour régner.** Le notebook [2.11d](2.11d-Optimisation-ADMM-From-Scratch.html) complète la famille en réécrivant le Lasso sous forme **scindée** `min ½‖Xβ−y‖² + λ‖z‖₁ sous β = z` : chaque rôle a son update (β prend le data-fit via une Cholesky pré-factorisée, z prend la parcimonie via le soft-thresholding — la même brique proximale que 2.11b, ici en `argmin` par coordonnée), et le paramètre `ρ` arbitre la vitesse. Le résultat central est un certificat croisé : sur un design corrélé AR(1) (`ρ_corr = 0,95`, conditionnement κ ≈ 80), coord-descente, `sklearn` et `cvxpy` (l'arbitre) coïncident à ~`10⁻⁷`, et ADMM à `2,1·10⁻³` — précisément sa tolérance d'arrêt. Le balayage de `ρ` montre le concept honnête : `ρ` change la **trajectoire** (budget d'itérations, palier de `z` à zéro tant que `λ/ρ` domine), jamais la **solution** — l'optimum d'un problème convexe est unique. Trois exercices (trajectoires `β(ρ)`, `ρ` empirique sur cas pathologique, extension ridge) ferment le notebook. Pont direct vers 2.11b (proximal) et 2.7b (autre split d'un problème dual). +> **ADMM : découper pour régner.** Le notebook [2.11d](2.11d-Optimisation-ADMM-From-Scratch.ipynb) complète la famille en réécrivant le Lasso sous forme **scindée** `min ½‖Xβ−y‖² + λ‖z‖₁ sous β = z` : chaque rôle a son update (β prend le data-fit via une Cholesky pré-factorisée, z prend la parcimonie via le soft-thresholding — la même brique proximale que 2.11b, ici en `argmin` par coordonnée), et le paramètre `ρ` arbitre la vitesse. Le résultat central est un certificat croisé : sur un design corrélé AR(1) (`ρ_corr = 0,95`, conditionnement κ ≈ 80), coord-descente, `sklearn` et `cvxpy` (l'arbitre) coïncident à ~`10⁻⁷`, et ADMM à `2,1·10⁻³` — précisément sa tolérance d'arrêt. Le balayage de `ρ` montre le concept honnête : `ρ` change la **trajectoire** (budget d'itérations, palier de `z` à zéro tant que `λ/ρ` domine), jamais la **solution** — l'optimum d'un problème convexe est unique. Trois exercices (trajectoires `β(ρ)`, `ρ` empirique sur cas pathologique, extension ridge) ferment le notebook. Pont direct vers 2.11b (proximal) et 2.7b (autre split d'un problème dual). -> **Le déclaratif, puis la synthèse — la chaîne optimisation convexe se referme.** Le notebook [2.11e](2.11e-CVXPY-Optimisation.html) prend le **troisième chemin** : on n'écrit plus l'algorithme du tout — on **écrit le problème** (`cvxpy`), on choisit le solveur par son nom (CLARABEL, SCS, OSQP), et le ruleset DCP refuse une formulation non convexe avant même de la résoudre. Son certificat : quatre moteurs (cvxpy, coord descent from scratch, ISTA, `sklearn`) atteignent le même objectif à `10⁻⁶` près sur P1, la dualité sort des variables duales sans être recodée, et `λmax = ‖Aᵀb‖∞` se calcule par le solveur seul — la contrepartie est le prix de la généralité (500 inconnues déclarées deviennent 1200 variables canoniques), la valeur est la **course du changement** : un group Lasso ou une forme contrainte sans écrire un nouvel algorithme. La clôture [2.11f](2.11f-Comparaison-Optimisation-Convexe.html) assemble enfin le tableau croisé demandé par l'EPIC ([#16061](https://github.com/jsboige/CoursIA/issues/16061), bloc B.8) : six solveurs Lasso et deux solveurs SVM re-mesurés **dans un même processus, mêmes graines, mêmes normalisations**, sous un contrat de comparaison explicite — itérations à **unités nommées** (appels d'examen vs sélections de working set vs epochs : elles ne s'additionnent pas), LOC à **deux portées étiquetées** (corps de solveur défini dans le notebook vs surface d'appel publique), sondes d'échelle en `n` et en `p`. Le verdict mesuré : partout les mêmes optima et les mêmes vecteurs supports (certificats croisés, dont l'égalité calculée avec la baseline committée de 2.7b) — le SOTA achète le temps et l'échelle, le from scratch achète la **visibilité** (α, caches d'erreurs, résidus, compteurs dans leur propre unité). +> **Le déclaratif, puis la synthèse — la chaîne optimisation convexe se referme.** Le notebook [2.11e](2.11e-CVXPY-Optimisation.ipynb) prend le **troisième chemin** : on n'écrit plus l'algorithme du tout — on **écrit le problème** (`cvxpy`), on choisit le solveur par son nom (CLARABEL, SCS, OSQP), et le ruleset DCP refuse une formulation non convexe avant même de la résoudre. Son certificat : quatre moteurs (cvxpy, coord descent from scratch, ISTA, `sklearn`) atteignent le même objectif à `10⁻⁶` près sur P1, la dualité sort des variables duales sans être recodée, et `λmax = ‖Aᵀb‖∞` se calcule par le solveur seul — la contrepartie est le prix de la généralité (500 inconnues déclarées deviennent 1200 variables canoniques), la valeur est la **course du changement** : un group Lasso ou une forme contrainte sans écrire un nouvel algorithme. La clôture [2.11f](2.11f-Comparaison-Optimisation-Convexe.ipynb) assemble enfin le tableau croisé demandé par l'EPIC ([#16061](https://github.com/jsboige/CoursIA/issues/16061), bloc B.8) : six solveurs Lasso et deux solveurs SVM re-mesurés **dans un même processus, mêmes graines, mêmes normalisations**, sous un contrat de comparaison explicite — itérations à **unités nommées** (appels d'examen vs sélections de working set vs epochs : elles ne s'additionnent pas), LOC à **deux portées étiquetées** (corps de solveur défini dans le notebook vs surface d'appel publique), sondes d'échelle en `n` et en `p`. Le verdict mesuré : partout les mêmes optima et les mêmes vecteurs supports (certificats croisés, dont l'égalité calculée avec la baseline committée de 2.7b) — le SOTA achète le temps et l'échelle, le from scratch achète la **visibilité** (α, caches d'erreurs, résidus, compteurs dans leur propre unité). -> **Le SOTA côté SVM, la boîte noire ouverte.** Le notebook [2.7c](2.7c-SVM-SOTA-Comparison.html) applique au SVM la règle pratique de l'EPIC optimisation convexe ([#16061](https://github.com/jsboige/CoursIA/issues/16061), bloc B.5) : *from scratch pour comprendre, SOTA pour produire* — et il montre que les deux se **certifient mutuellement**. Sur le même terrain que 2.7b (graine près), LIBSVM (`sklearn.svm.SVC`) rend exactement le même classifieur : même accuracy (0,967), mêmes 48 supports, écart de score de décision déjà mesuré à 0,005 en 2.7b — mais **trois ordres de grandeur plus vite** (fit sub-milliseconde contre 1,19 s de la boucle Python). Le geste distinctif : le dual que `SVC` ne rend pas se **reconstruit** depuis `dual_coef_` (contrainte `Σ α_i y_i` exacte à `10⁻¹⁶`), et le gap de dualité comme les violations KKT se mesurent sur LIBSVM exactement comme sur la SMO maison — les deux solveurs s'arrêtent à `tol = 10⁻³` près, chacun avec son critère. Le notebook détaille aussi ce que LIBSVM fait que la cascade de Platt ne fait pas (working set au second ordre, shrinking, cache de noyau) et l'exercice 3 pose le geste de production : `GridSearchCV` sur `C × gamma`. +> **Le SOTA côté SVM, la boîte noire ouverte.** Le notebook [2.7c](2.7c-SVM-SOTA-Comparison.ipynb) applique au SVM la règle pratique de l'EPIC optimisation convexe ([#16061](https://github.com/jsboige/CoursIA/issues/16061), bloc B.5) : *from scratch pour comprendre, SOTA pour produire* — et il montre que les deux se **certifient mutuellement**. Sur le même terrain que 2.7b (graine près), LIBSVM (`sklearn.svm.SVC`) rend exactement le même classifieur : même accuracy (0,967), mêmes 48 supports, écart de score de décision déjà mesuré à 0,005 en 2.7b — mais **trois ordres de grandeur plus vite** (fit sub-milliseconde contre 1,19 s de la boucle Python). Le geste distinctif : le dual que `SVC` ne rend pas se **reconstruit** depuis `dual_coef_` (contrainte `Σ α_i y_i` exacte à `10⁻¹⁶`), et le gap de dualité comme les violations KKT se mesurent sur LIBSVM exactement comme sur la SMO maison — les deux solveurs s'arrêtent à `tol = 10⁻³` près, chacun avec son critère. Le notebook détaille aussi ce que LIBSVM fait que la cascade de Platt ne fait pas (working set au second ordre, shrinking, cache de noyau) et l'exercice 3 pose le geste de production : `GridSearchCV` sur `C × gamma`. -> **La grande dimension.** Le notebook [2.3c](2.3c-Regression-Grande-Dimension.html) ouvre le régime que le 2.3 ne faisait qu’annoncer (VIF 52) : p = 205 variables pour n = 120 observations. Une direction de X ne vaut pour la prédiction que par Cov(Y, Xu) — pas par Var(Xu) : l’ACP (donc la PCR) trie par Var et paie 38 composantes de leurre avant d’atteindre le signal ; la PLS trie par Cov et le capture en 5 composantes (RMSE test 0.244 contre 0.942 à budget égal), loadings à l’appui. Ridge (λ par CV) rend le problème déterminé et referme la promesse du 2.3. Le verdict est vérifié sur dix graines (section 9bis, hyperparamètres re-choisis à chaque tirage) : PLS et PCR devant quand le signal vit hors des grandes variances, ridge devant dans le régime aligné, OLS min-norme dépassée 8 fois sur 10 puis 6 fois sur 10. +> **La grande dimension.** Le notebook [2.3c](2.3c-Regression-Grande-Dimension.ipynb) ouvre le régime que le 2.3 ne faisait qu’annoncer (VIF 52) : p = 205 variables pour n = 120 observations. Une direction de X ne vaut pour la prédiction que par Cov(Y, Xu) — pas par Var(Xu) : l’ACP (donc la PCR) trie par Var et paie 38 composantes de leurre avant d’atteindre le signal ; la PLS trie par Cov et le capture en 5 composantes (RMSE test 0.244 contre 0.942 à budget égal), loadings à l’appui. Ridge (λ par CV) rend le problème déterminé et referme la promesse du 2.3. Le verdict est vérifié sur dix graines (section 9bis, hyperparamètres re-choisis à chaque tirage) : PLS et PCR devant quand le signal vit hors des grandes variances, ridge devant dans le régime aligné, OLS min-norme dépassée 8 fois sur 10 puis 6 fois sur 10. -> **La frontière, signature de l'hypothèse.** Le notebook [2.3d](2.3d-Modele-Gaussien-LDA-QDA.html) tisse le pont génératif que la série laissait en creux entre [2.3](2.3-Regression-lineaire-logistique.html) (OLS vs logistique) et [2.3b](2.3b-Naive-Bayes-Generatif.html) (hypothèse d'indépendance) : il dérive la frontière depuis la log-densité gaussienne et montre que c'est **l'hypothèse de covariance** — partagée vs propre — qui décide linéaire ou quadratique. Mesure phare : sur des régimes contrôlés, QDA devance LDA de **+5.7 pts** dès que les covariances diffèrent ; en grande dimension, QDA s'effondre (`nan`) dès que `d` rivalise avec `n_c` (2 classes, `n_c=30` : `nan` à `d=30`), là où LDA 0.975 et Naive Bayes 0.994 survivent. Le concept-phare n'est pas une course d'accuracy mais la **signature d'une hypothèse** — et le prix de la flexibilité (`O(d²)` pour QDA) devient une singularité. Cross-référé à [2.3b](2.3b-Naive-Bayes-Generatif.html) et [2.6](2.6-Clustering-KMeans-PCA.html). +> **La frontière, signature de l'hypothèse.** Le notebook [2.3d](2.3d-Modele-Gaussien-LDA-QDA.ipynb) tisse le pont génératif que la série laissait en creux entre [2.3](2.3-Regression-lineaire-logistique.ipynb) (OLS vs logistique) et [2.3b](2.3b-Naive-Bayes-Generatif.ipynb) (hypothèse d'indépendance) : il dérive la frontière depuis la log-densité gaussienne et montre que c'est **l'hypothèse de covariance** — partagée vs propre — qui décide linéaire ou quadratique. Mesure phare : sur des régimes contrôlés, QDA devance LDA de **+5.7 pts** dès que les covariances diffèrent ; en grande dimension, QDA s'effondre (`nan`) dès que `d` rivalise avec `n_c` (2 classes, `n_c=30` : `nan` à `d=30`), là où LDA 0.975 et Naive Bayes 0.994 survivent. Le concept-phare n'est pas une course d'accuracy mais la **signature d'une hypothèse** — et le prix de la flexibilité (`O(d²)` pour QDA) devient une singularité. Cross-référé à [2.3b](2.3b-Naive-Bayes-Generatif.ipynb) et [2.6](2.6-Clustering-KMeans-PCA.ipynb). ## Aperçu — les concepts-phare en images La série ne se contente pas d'ajuster des modèles : chaque chapitre **rend visible** un concept distinct, dans une figure extraite des sorties réelles des notebooks. Les voici replacées dans leur progression pédagogique — chacune illustre la capacité distinctive d'une technique et l'exerce sur un cas non trivial. -**[2.1 — Le surapprentissage, rendu observable.](2.1-Workflow-ML.html)** On balaie la profondeur d'un arbre de décision de 1 à 25 et l'on trace, côte à côte, le score d'entraînement et le score de test. Tant que la profondeur reste modeste, les deux courbes suivent la même trajectoire ; passé un seuil, elles se séparent, et l'écart ne cesse de grandir à mesure que le modèle mémorise le bruit de l'entraînement. Ce geste diagnostique — voir le surapprentissage plutôt que le subir — est le fil rouge du workflow ML. +**[2.1 — Le surapprentissage, rendu observable.](2.1-Workflow-ML.ipynb)** On balaie la profondeur d'un arbre de décision de 1 à 25 et l'on trace, côte à côte, le score d'entraînement et le score de test. Tant que la profondeur reste modeste, les deux courbes suivent la même trajectoire ; passé un seuil, elles se séparent, et l'écart ne cesse de grandir à mesure que le modèle mémorise le bruit de l'entraînement. Ce geste diagnostique — voir le surapprentissage plutôt que le subir — est le fil rouge du workflow ML.

Surapprentissage rendu visible : la courbe de score (train vs test) diverge quand la profondeur de l'arbre croît.

-**[2.2 — Trois régimes de learning rate.](2.2-Descente-de-gradient.html)** On ouvre la boîte noire de `fit()` en lançant la descente de gradient sur la même fonction de coût avec trois pas d'apprentissage. L'un converge trop lentement, le second trouve le minimum sans errer, le troisième oscille puis s'envole : la frontière entre une bonne convergence et la divergence tient à un seul scalaire, le *learning rate*. +**[2.2 — Trois régimes de learning rate.](2.2-Descente-de-gradient.ipynb)** On ouvre la boîte noire de `fit()` en lançant la descente de gradient sur la même fonction de coût avec trois pas d'apprentissage. L'un converge trop lentement, le second trouve le minimum sans errer, le troisième oscille puis s'envole : la frontière entre une bonne convergence et la divergence tient à un seul scalaire, le *learning rate*.

Effet du learning rate : trois régimes (trop lent, bon, divergent) sur la même fonction de coût.

-**[2.3 — Une sigmoïde plutôt qu'une droite.](2.3-Regression-lineaire-logistique.html)** À partir des mêmes étiquettes binaires, on ajuste d'abord une droite (moindres carrés, OLS), puis une sigmoïde (maximum de vraisemblance, MLE). La droite sort du cadre dès qu'elle doit prédire une probabilité ; la sigmoïde écrase le score linéaire dans [0, 1] et donne à chaque point sa probabilité d'appartenir à la classe — c'est tout l'écart entre régression linéaire et logistique. +**[2.3 — Une sigmoïde plutôt qu'une droite.](2.3-Regression-lineaire-logistique.ipynb)** À partir des mêmes étiquettes binaires, on ajuste d'abord une droite (moindres carrés, OLS), puis une sigmoïde (maximum de vraisemblance, MLE). La droite sort du cadre dès qu'elle doit prédire une probabilité ; la sigmoïde écrase le score linéaire dans [0, 1] et donne à chaque point sa probabilité d'appartenir à la classe — c'est tout l'écart entre régression linéaire et logistique.

Fonction sigmoïde : le score linéaire est écrasé en probabilité dans [0, 1] par la fonction de lien logistique (MLE).

-**[2.4 — La frontière, de l'escalier au lissage.](2.4-Arbres-Forets-Ensembles.html)** Sur le jeu de cancer du sein, on trace la frontière de décision d'un arbre unique, puis celle d'une forêt aléatoire. L'arbre seul découpe l'espace en escaliers rigides, sensible au bruit ; l'ensemble moyenne ces coupes et lisse la frontière. C'est la réduction de variance rendue géométrique — la raison pour laquelle les forêts battent l'arbre isolé. +**[2.4 — La frontière, de l'escalier au lissage.](2.4-Arbres-Forets-Ensembles.ipynb)** Sur le jeu de cancer du sein, on trace la frontière de décision d'un arbre unique, puis celle d'une forêt aléatoire. L'arbre seul découpe l'espace en escaliers rigides, sensible au bruit ; l'ensemble moyenne ces coupes et lisse la frontière. C'est la réduction de variance rendue géométrique — la raison pour laquelle les forêts battent l'arbre isolé.

Forêt aléatoire : la frontière de décision, escalier d'un arbre seul vs lissage par l'ensemble (réduction de variance géométrique, jeu de cancer du sein mean radius × mean texture).

-**[2.4b — Le comité qui concentre ses poids.](2.4b-AdaBoost-From-Scratch.html)** AdaBoost (SAMME) reconstruit à la main sur le même jeu que 2.4 : chaque tour retient le stump d'erreur pondérée minimale, lui donne un vote α = ½ln((1−ε)/ε), puis fait monter le poids des exemples mal classés — et descendre les autres. La figure montre la conséquence : la masse des poids migre vers les exemples difficiles (les dix plus lourds portent 17 % de la masse au tour 1, 46 % au tour 20), pendant que la frontière du comité émerge en escalier de la superposition des demi-plans pondérés. Le comité écrit à la main classe le jeu de test à l'identique de `sklearn.ensemble.AdaBoostClassifier` (0,959, accord des prédictions 1,000) — la réimplémentation est validée par recoupement avec la référence. +**[2.4b — Le comité qui concentre ses poids.](2.4b-AdaBoost-From-Scratch.ipynb)** AdaBoost (SAMME) reconstruit à la main sur le même jeu que 2.4 : chaque tour retient le stump d'erreur pondérée minimale, lui donne un vote α = ½ln((1−ε)/ε), puis fait monter le poids des exemples mal classés — et descendre les autres. La figure montre la conséquence : la masse des poids migre vers les exemples difficiles (les dix plus lourds portent 17 % de la masse au tour 1, 46 % au tour 20), pendant que la frontière du comité émerge en escalier de la superposition des demi-plans pondérés. Le comité écrit à la main classe le jeu de test à l'identique de `sklearn.ensemble.AdaBoostClassifier` (0,959, accord des prédictions 1,000) — la réimplémentation est validée par recoupement avec la référence.

AdaBoost : la migration des poids — taille des points proportionnelle au multiplicateur de poids vs uniforme, part du top-10 dans le titre de chaque panneau (17 % au tour 1, 41 % au tour 5, 46 % au tour 20), jeu de cancer du sein mean radius × mean texture.

-**[2.5 — Le coût d'un seuil.](2.5-Biais-Variance-CV-ROC.html)** La courbe ROC balaye tous les seuils de décision possibles et échange les faux positifs contre les faux négatifs ; l'aire sous la courbe (AUC) résume ce compromis en un nombre. Mais le bon seuil n'est pas celui qui maximise l'AUC : il dépend du coût métier d'un faux négatif (rater un cancer) face à un faux positif. La figure impose cette lecture économique de la décision. +**[2.5 — Le coût d'un seuil.](2.5-Biais-Variance-CV-ROC.ipynb)** La courbe ROC balaye tous les seuils de décision possibles et échange les faux positifs contre les faux négatifs ; l'aire sous la courbe (AUC) résume ce compromis en un nombre. Mais le bon seuil n'est pas celui qui maximise l'AUC : il dépend du coût métier d'un faux négatif (rater un cancer) face à un faux positif. La figure impose cette lecture économique de la décision.

Courbe ROC et AUC : le coût du seuil, arbitrage entre faux positifs et faux négatifs.

-**[2.6 — La structure retrouvée sans étiquettes.](2.6-Clustering-KMeans-PCA.html)** Sur les chiffres manuscrits, sans jamais fournir les étiquettes, l'analyse en composantes principales projette les images en deux dimensions — et les amas qui émergent suivent déjà les classes de chiffres. C'est la promesse de l'apprentissage non supervisé : retrouver la structure latente que les étiquettes confirmeraient a posteriori. +**[2.6 — La structure retrouvée sans étiquettes.](2.6-Clustering-KMeans-PCA.ipynb)** Sur les chiffres manuscrits, sans jamais fournir les étiquettes, l'analyse en composantes principales projette les images en deux dimensions — et les amas qui émergent suivent déjà les classes de chiffres. C'est la promesse de l'apprentissage non supervisé : retrouver la structure latente que les étiquettes confirmeraient a posteriori.

Réduction de dimension (ACP) : structure des chiffres retrouvée sans étiquettes en 2 composantes.

-**[2.7b — Le solveur écrit à la main retrouve la bibliothèque.](2.7b-SMO-From-Scratch.html)** Sur les deux demi-lunes, on écrit SMO (l'algorithme de Platt) à la main, puis on superpose sa frontière de décision à celle de `sklearn.svm.SVC`. Les deux panneaux montrent la même frontière, les mêmes marges à −1 / 0 / +1 et les mêmes régimes de vecteurs supports (non-support, `0 < α < C` sur la marge, `α = C` en slack actif — point dans la marge ou mal classé). Le concept-phare est le contrôle : le biais appris à la main et celui de sklearn coïncident à 4·10⁻⁴, l'écart maximal de score de décision reste à 5·10⁻³ au plus sur les deux ensembles (0,0049 en test, 0,0050 en entraînement), et le **gap de dualité** chiffre l'écart à l'optimum à environ 3·10⁻³ — un **recoupement empirique** entre deux solveurs aux heuristiques distinctes, dans un cas où l'optimum dual est unique (Gram RBF définie positive sur des points deux à deux distincts). +**[2.7b — Le solveur écrit à la main retrouve la bibliothèque.](2.7b-SMO-From-Scratch.ipynb)** Sur les deux demi-lunes, on écrit SMO (l'algorithme de Platt) à la main, puis on superpose sa frontière de décision à celle de `sklearn.svm.SVC`. Les deux panneaux montrent la même frontière, les mêmes marges à −1 / 0 / +1 et les mêmes régimes de vecteurs supports (non-support, `0 < α < C` sur la marge, `α = C` en slack actif — point dans la marge ou mal classé). Le concept-phare est le contrôle : le biais appris à la main et celui de sklearn coïncident à 4·10⁻⁴, l'écart maximal de score de décision reste à 5·10⁻³ au plus sur les deux ensembles (0,0049 en test, 0,0050 en entraînement), et le **gap de dualité** chiffre l'écart à l'optimum à environ 3·10⁻³ — un **recoupement empirique** entre deux solveurs aux heuristiques distinctes, dans un cas où l'optimum dual est unique (Gram RBF définie positive sur des points deux à deux distincts).

SMO écrit à la main vs sklearn SVC : frontières de décision superposées sur les deux demi-lunes, marges à −1/0/+1 et régimes de vecteurs supports ; biais appris b = −0.074 dans les deux panneaux.

@@ -217,7 +217,7 @@ Cette série est le **référent manuel** des labs agentic qui suivent. Une fois ## Références transverses -Les citations canoniques ancrées dans la série (cellule `## References` de chaque notebook) incluent : Mitchell 1997 (généralisation), Cauchy 1847 (descente de gradient), Nelder & Wedderburn 1972 (modèles linéaires généralisés), Cox 1958 (régression logistique), Breiman et al. 1984 (CART), Breiman 2001 (forêts aléatoires), Friedman 2001 (gradient boosting), Stone 1974 (validation croisée), Bradley 1997 (AUC), Brier 1950 (score de Brier), Niculescu-Mizil & Caruana 2005 (calibration par famille de modèles), Platt 1999 (Platt scaling), Zadrozny & Elkan 2002 (régression isotonique), Guo et al. 2017 (ECE, temperature scaling), MacQueen 1967 (k-means), Pearson 1901 (ACP), Cortes & Vapnik 1995 (réseaux de vecteurs supports), Platt 1998 (*Sequential Minimal Optimization — a fast algorithm for training support vector machines*), Fan, Chen & Lin 2005 (sélection du working set au second ordre), Chang & Lin 2011 (LIBSVM), Cover & Hart 1967 (k plus proches voisins), Valiant 1984 (théorie PAC), Vapnik & Chervonenkis 1971 (dimension VC), Novikoff 1962 (convergence du perceptron), Bergstra et al. 2011 (TPE), Bergstra & Bengio 2012 (random search), Akiba et al. 2019 (Optuna), Hoerl & Kennard 1970 (ridge), Tibshirani 1996 (LASSO), Zou & Hastie 2005 (elastic net), Donoho & Johnstone 1994 (seuil universel), Beck & Teboulle 2009 (ISTA/FISTA), Friedman, Hastie & Tibshirani 2010 (glmnet, coordinate descent), Boyd et al. 2011 (ADMM), Wold 1975 (NIPALS/PLS), de Jong 1993 (SIMPLS), Frank & Friedman 1993 (continuum ridge/PCR/PLS), Jolliffe 2002 (ACP), Hastie/Tibshirani/Friedman 2009 (*The Elements of Statistical Learning*), **Goodfellow/Bengio/Courville 2016 (*Deep Learning*, MIT Press — la référence canonique du deep learning, ancrée par la série [03-DeepLearning](../03-DeepLearning/README.md), notamment la ch. 6.5 dans [3.1-Rétropropagation](../03-DeepLearning/3.1-Retropropagation.html) et la ch. 8 dans [2.2-Descente-de-gradient](2.2-Descente-de-gradient.html) — ch. 20 « Deep Generative Models » dans [3.6-Modeles-Generatifs](../03-DeepLearning/3.6-Modeles-Generatifs.html) et [3.6b](../03-DeepLearning/3.6b-Modeles-Generatifs-PyTorch.html))** et Pedregosa et al. 2011 (scikit-learn). +Les citations canoniques ancrées dans la série (cellule `## References` de chaque notebook) incluent : Mitchell 1997 (généralisation), Cauchy 1847 (descente de gradient), Nelder & Wedderburn 1972 (modèles linéaires généralisés), Cox 1958 (régression logistique), Breiman et al. 1984 (CART), Breiman 2001 (forêts aléatoires), Friedman 2001 (gradient boosting), Stone 1974 (validation croisée), Bradley 1997 (AUC), Brier 1950 (score de Brier), Niculescu-Mizil & Caruana 2005 (calibration par famille de modèles), Platt 1999 (Platt scaling), Zadrozny & Elkan 2002 (régression isotonique), Guo et al. 2017 (ECE, temperature scaling), MacQueen 1967 (k-means), Pearson 1901 (ACP), Cortes & Vapnik 1995 (réseaux de vecteurs supports), Platt 1998 (*Sequential Minimal Optimization — a fast algorithm for training support vector machines*), Fan, Chen & Lin 2005 (sélection du working set au second ordre), Chang & Lin 2011 (LIBSVM), Cover & Hart 1967 (k plus proches voisins), Valiant 1984 (théorie PAC), Vapnik & Chervonenkis 1971 (dimension VC), Novikoff 1962 (convergence du perceptron), Bergstra et al. 2011 (TPE), Bergstra & Bengio 2012 (random search), Akiba et al. 2019 (Optuna), Hoerl & Kennard 1970 (ridge), Tibshirani 1996 (LASSO), Zou & Hastie 2005 (elastic net), Donoho & Johnstone 1994 (seuil universel), Beck & Teboulle 2009 (ISTA/FISTA), Friedman, Hastie & Tibshirani 2010 (glmnet, coordinate descent), Boyd et al. 2011 (ADMM), Wold 1975 (NIPALS/PLS), de Jong 1993 (SIMPLS), Frank & Friedman 1993 (continuum ridge/PCR/PLS), Jolliffe 2002 (ACP), Hastie/Tibshirani/Friedman 2009 (*The Elements of Statistical Learning*), **Goodfellow/Bengio/Courville 2016 (*Deep Learning*, MIT Press — la référence canonique du deep learning, ancrée par la série [03-DeepLearning](../03-DeepLearning/README.md), notamment la ch. 6.5 dans [3.1-Rétropropagation](../03-DeepLearning/3.1-Retropropagation.ipynb) et la ch. 8 dans [2.2-Descente-de-gradient](2.2-Descente-de-gradient.ipynb) — ch. 20 « Deep Generative Models » dans [3.6-Modeles-Generatifs](../03-DeepLearning/3.6-Modeles-Generatifs.ipynb) et [3.6b](../03-DeepLearning/3.6b-Modeles-Generatifs-PyTorch.ipynb))** et Pedregosa et al. 2011 (scikit-learn). ## Conclusion — ce que vous emportez @@ -231,7 +231,7 @@ La série s'ouvrait sur une thèse : *on ne peut juger ce qu'un agent LLM produi - **Approfondir la théorie** : Hastie, Tibshirani & Friedman, *The Elements of Statistical Learning* (2009) reprend et formalise l'ensemble de ces chapitres ; le [guide utilisateur scikit-learn](https://scikit-learn.org/stable/user_guide.html) (Pedregosa et al. 2011) en est le prolongement pratique direct. - **Exercer le jugement** : reprenez un notebook des tracks [Track1-LangChain](../Track1-LangChain/README.md) ou [Track2-GoogleADK](../Track2-GoogleADK/README.md) et confrontez le pipeline produit par l'agent aux quatre questions ci-dessus — c'est le meilleur exercice de consolidation, car il met le socle au travail. -- **Vers le deep learning et le RL** : la descente de gradient (2.2) et la notion de capacité d'un modèle (2.8) sont les deux fondations directement réinvesties par les réseaux de neurones ; l'épilogue [2.9](2.9-Grokking-Generalisation.html) fait ce premier pas (un réseau de neurones qui *grokke*, entraîné en quelques minutes sur CPU), et la série [RL](../../../RL/README.md) montre cette même descente de gradient à l'œuvre dans l'apprentissage par renforcement profond (DQN, PPO). +- **Vers le deep learning et le RL** : la descente de gradient (2.2) et la notion de capacité d'un modèle (2.8) sont les deux fondations directement réinvesties par les réseaux de neurones ; l'épilogue [2.9](2.9-Grokking-Generalisation.ipynb) fait ce premier pas (un réseau de neurones qui *grokke*, entraîné en quelques minutes sur CPU), et la série [RL](../../../RL/README.md) montre cette même descente de gradient à l'œuvre dans l'apprentissage par renforcement profond (DQN, PPO). --- diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/README.md index 193c7a2022..8ce82ea8f5 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/README.md @@ -7,9 +7,9 @@ ## Pourquoi cette série Le socle [`02-ML-Cours`](../02-ML-Cours/README.md) laisse un chaînon ouvert. La descente de -gradient y est ouverte à la main ([2.2](../02-ML-Cours/2.2-Descente-de-gradient.html)) — mais +gradient y est ouverte à la main ([2.2](../02-ML-Cours/2.2-Descente-de-gradient.ipynb)) — mais sur **une droite** ; le premier réseau de neurones de la formation -([2.9](../02-ML-Cours/2.9-Grokking-Generalisation.html)) est entraîné en PyTorch **boîte +([2.9](../02-ML-Cours/2.9-Grokking-Generalisation.ipynb)) est entraîné en PyTorch **boîte noire** : `loss.backward()` et tout suit. Entre les deux, personne n'a écrit la **rétropropagation** à la main — l'étape où l'on comprend réellement *pourquoi* un réseau apprend. @@ -24,34 +24,34 @@ séries (RL, PostTraining, ML-Training-Pipeline). L'entraînement final du 2.9 e | Notebook | Sujet | Concept-phare | Validation | |----------|-------|---------------|------------| -| [3.0-Theorie-Information](3.0-Theorie-Information.html) | Entropie, cross-entropy et KL construites from scratch sur un texte français, puis MSE vs cross-entropy sur un classifieur (le piège du gradient saturé), température (softmax) et pont vers DPO/GRPO | **La loss qui fait apprendre** : pourquoi la cross-entropy (et pas la MSE) est la bonne loss d'un classifieur, et la KL comme mesure de décalage entre deux distributions de modèle | entropie du français ~4,4 bits (redondance ~10-15 %, borne ≤ log₂K vérifiée) ; identité H(p,q)=H(p)+D_KL vérifiée, KL>0 sur tout le balayage (Gibbs) ; init saturée et fausse : la CE s'échappe (0,88) quand la MSE reste bloquée (0,39), gradient CE/MSE ~51× ; log 0 maîtrisé par lissage ε ; KL minimale en T=1 | -| [3.1-Retropropagation](3.1-Retropropagation.html) | Le MLP et la rétropropagation à la main (NumPy pur, sans autograd) | **Le gradient vérifié** : différence finie vs analytique, parité exacte avec PyTorch | écart 1,3e-11 (seuil 1e-6) ; loss initiale, premier pas et trajectoire 3000 iters identiques à 1,1e-16 près ; init nulle = gradient nul (0,500 figé) | -| [3.2-Optimisateurs](3.2-Optimisateurs.html) | Momentum, Adagrad, RMSProp, Adam et schedules, écrits en NumPy pur puis validés pas à pas contre `torch.optim` | **La parité exacte** : les 5 mises à jour sont celles de torch | GD/momentum/Adam à 1,11e-16, Adagrad bit-à-bit (0,00e+00), RMSProp à 2,22e-16 (float64, 1 pas) ; Beale : 5 trajectoires superposées (facteur 200 entre lr utilisables) ; MLP du 3.1 : 5 optimisateurs × 3 graines (RMSProp 0,059 < Adam 0,061 < … < GD 0,070) ; schedules : coût en full-batch déterministe, gain sous le plancher de bruit en mini-batch | -| [3.3-Regularisation](3.3-Regularisation.html) | Dropout, weight decay et early stopping écrits à la main sur un MLP construit pour surapprendre (17 000 paramètres, 100 points d'entraînement, 12 étiquettes fausses) | **Corriger la variance sans changer le modèle** : trois remèdes appliqués au même surapprentissage fabriqué | sans régularisation : val acc 84,0 % (les 12 erreurs mémorisées) ; dropout p=0,3 : 89,0 % ; early stopping : +4,5 % ; gradient check du dropout (masque gelé) et invariants du dropout inverse (p=0,4, 2000×50) | -| [3.4-Attention-Transformer-From-Scratch](3.4-Attention-Transformer-From-Scratch.html) | De l'attention mono-tête lisible sur l'inversion de séquence au mini-GPT de 1,25 M entraîné dans le notebook | **L'attention jusqu'au bout, sur CPU** : attention + masque causal + multi-têtes + bloc pré-norme, équivalence numérique avec `torch.nn`, mini-GPT char-level entraîné (117 s) sur le *Horla* (Maupassant, domaine public, 59 k caractères) | sac de mots A = B pour phrases opposées (1-9) ; inversion : poids requete 0 = `[0,007 0,007 0,007 0,007 0,007 0,967]` ; multi-têtes maison vs `torch.nn.MultiheadAttention` à 2,38e-07 (assert allclose 1e-5) ; mini-GPT 1 251 040 paramètres : perte ln(85)=4,44 → train 2,46 / val 2,45 en 800 étapes (117 s), perplexité val 11,5 ; 4 têtes spécialisées post-entraînement (diagonale 0,110 / 0,172 / 0,133 / 0,102) | -| [3.4c-MoE-from-scratch](3.4c-MoE-from-scratch.html) | La couche Mixture of Experts écrite à la main (routeur top-k, capacité par expert avec jetons jetés, loss d'équilibrage `E·Σ f_i·P_i`), son coût mesuré en millisecondes contre deux FFN denses d'équivalence (iso-calcul, iso-paramètres) puis son entraînement dense contre MoE sur la tâche jouet du TV-00b (série TransformerVariants) | **Découpler paramètres et calcul** : E experts dont seuls k travaillent par jeton — le banc entrelacé mesure ce que la promesse vaut réellement, routage compris | routeur vérifié sur cas contrôlés (entropie uniforme 2,0794 = ln 8, tie-break de `topk` exposé) ; banc de coût : MoE E=8 k=2 (1 054 720 params) à 0,75× le temps du dense-32d iso-paramètres mais ~2,9× le dense-8d iso-calcul (rapports calculés dans la même cellule ; les temps absolus varient avec la machine) — le routage top-k a un coût propre qui mange une partie de l'économie théorique ; qualité : la tâche jouet ne discrimine pas (acc 1,000 partout, dit comme tel) — l'information est dans les routeurs : sans loss d'équilibrage, parts 0,284…0,000 ; avec α=0,01, parts 0,118–0,134 quasi uniformes (L_aux 1,29 → 1,00) ; 3 exercices | -| [3.4d-Fourier-Features-Biais-Spectral](3.4d-Fourier-Features-Biais-Spectral-Python.html) | Le **biais spectral** d'un MLP tanh reproduit empiriquement (Rahaman et al. 2019) face à un signal 1D à 13 cycles, puis débloqué par le mapping de Fourier `γ(x) = [cos(2πB x), sin(2πB x)]` avec `B ~ N(0, σ²)` (Tancik et al. 2020, geste NeRF) — trois régimes mesurés (sous-ajustement, bande utile, aliasing) plus un témoin négatif qui combine σ=50 et h=256 : la capacité mémorise le train sans récupérer le test | **Le MLP n'apprend pas les hautes fréquences** : la NTK tanh a une bande passante trop étroite pour la cible 13 cycles ; un mapping `B ~ N(0, σ²)` adapté la débloque, σ excessif re-sur-ajuste — la MSE comme bande à dépasser, pas comme optimum ponctuel | garde gradient 2,08e-07 (seuil 1e-5) ; balayage σ (64 pts train / 400 test, seed 0) : baseline 3,23e-01 (plafond spectral), σ=1 1,40e-02, σ=2 minimum à 8,33e-03, σ=5 1,21e-02, σ=10 9,70e-03, σ=20 7,41e-02 (aliasing), σ=50 4,42e-01 ; témoin négatif σ=50 + h=256 (99 073 paramètres) : MSE train 1,36e-07 contre test 4,32e-01, rapport 3,2e-07 — la capacité mémorise le train sans gain au test ; 3 exercices | -| [3.5-Phenomenes-de-Generalisation](3.5-Phenomenes-de-Generalisation.html) | Grokking et double descente reproduits en NumPy pur (MLP à embeddings + Adam à la main), confrontés à la borne PAC du 2.8 | **Le phénomène sans la boîte noire** : mémorisation → transition abrupte, et le W de la double descente | garde gradient ≤ 1e-6 (embeddings inclus) ; grok mesuré : train saturé ~500 pas, test 100 % des dizaines de milliers de pas plus tard (wd = 1) ; contre-témoin wd = 0 ; double descente : pic au seuil M ≈ n (×5 le creux), asymptote moderne sous le creux classique, 20 graines | -| [3.6-Modeles-Generatifs](3.6-Modeles-Generatifs.html) | VAE, GAN et diffusion (DDPM) écrits en NumPy pur, même cible (huit modes sur un cercle), même budget (6 000 pas, batch 256, largeur 64), face à une baseline GMM ajustée par EM | **Trois objectifs, trois échecs** : le VAE couvre mais moyenne, le GAN s'effondre, la diffusion raffine au prix de 100 passes par échantillon | garde gradient 1,4e-08 (ELBO + reparamétrisation) et 3,2e-10 (eps-net) ; multi-4-graines : GMM 8/8 disp 0,99 (2,2 s) ; VAE 8/8 disp 6,0 ; GAN 1,5 ± 0,5 modes ; DDPM 8/8 disp 1,51 ; trajectoire de denoising en 5 instantanés (t = 99 → 0) | -| [3.6b-Modeles-Generatifs-PyTorch](3.6b-Modeles-Generatifs-PyTorch.html) | Versant **framework** du 3.6 : VAE, GAN et DDPM (diffusion) entraînés sur une même cible 2D à 4 modes (mélange de Gaussiennes, PyTorch CPU) puis comparés — ELBO vs adversarial vs débruitage | **Le compromis qualité/diversité** : 4 mécanismes génératifs sur les mêmes métriques (couverture de modes, entropie effective), le GMM empirique en référence « modèle exact » | médiane sur 3 graines (budget de pas commun) : GMM cov 4/4 ESS 3,96 · VAE cov 4/4 ESS 3,95 · GAN cov 3/4 ESS 2,99 (perte de diversité, un mode jamais couvert) · Diff cov 4/4 ESS 1,62 (couvre mais sous-échantillonne le mode le plus faible) — verdict nuancé, pas de « gagnant » unique | -| [3.6c-Modeles-Generatifs-Diffusion-from-scratch](3.6c-Modeles-Generatifs-Diffusion-from-scratch.html) | Le DDPM écrit à la main : schedule β, forme fermée du forward, réseau ε_θ, loss MSE sur le bruit, sampler ancestral — sans librairie de diffusion | **La diffusion sans boîte noire** : chaque pièce du DDPM démontrée et mesurée, schedules linéaire et cosinus comparés à budget égal | 16 entraînements + échantillonnages (17,7 min CPU) ; MMD médiane sur 4 graines par budget × bande passante : le cosinus domine aux petites σ (budget 24, σ 0,25 : 0,00197), le linéaire reprend aux grandes (budget 12, σ 2,0 : 0,02087 vs 0,02359) | -| [3.6d-Modeles-Generatifs-Score-SDE-from-scratch](3.6d-Modeles-Generatifs-Score-SDE-from-scratch.html) | Le passage à la limite continue du DDPM : réseau de score, formulation SDE, et trois solveurs (Euler-Maruyama, Langevin recuit, prédicteur-correcteur) écrits à la main | **La vue continue de la diffusion** : mêmes cibles, plusieurs solveurs, tous mesurés contre un plancher vrai/vrai | plancher vrai/vrai MMD 1,6e-4 ; Euler-Maruyama (réseau) 0,00156, modes 5/5, 1,0 s ; prédicteur-correcteur 0,00259 ; Langevin recuit 0,00894 (12,6 s) ; contre-exemple « mauvais signe » : 0,680, modes 1/5 | -| [3.6e-Modeles-Generatifs-Conditionnels-from-scratch](3.6e-Modeles-Generatifs-Conditionnels-from-scratch.html) | Génération conditionnelle et classifier-free guidance from scratch : le DDPM conditionné par classe, balayage du poids de guidance w | **Guider sans classifieur** : le compromis adhérence/diversité du CFG mesuré sur le même générateur | meilleur w = 1,0 sur les trois bandes passantes (MMD 0,009 à 0,029) ; w = 5,0 : adhérence 0,991 mais la diversité s'effondre (MMD jusqu'à 0,27) | -| [3.7-Distillation-Maitre-Eleve](3.7-Distillation-Maitre-Eleve.html) | Distillation teacher/student : un maître entraîné distille son savoir (dark knowledge) vers un élève ~9× plus petit | **Le facteur T² vérifié** : la KL brute chute en ~1/T², la KL scalée reste constante ; verdict INCONCLUSIVE au seuil strict — gain par exemple net (DM p < 0.001, CE 0.63 → 0.58) mais edge 0.6σ/1.4σ sous 5 folds × 4 graines | maître 0.8906 / distillé 0.8145 vs baseline 0.8029 ; ECE 0.0458 vs 0.0684 ; ratio params 8.9× ; 5 folds × 4 graines (20 paires), entrainement deterministe | -| [3.8-Representations-Contrastives](3.8-Representations-Contrastives.html) | Pré-entraînement contrastif moderne sur vues continues : augmentations contrôlées du sac-de-mots (mask/swap/identité), encodeur MLP et loss InfoNCE écrits from scratch sans autograd, pont explicite vers le skip-gram (cooccurrence discrète vs vue continue) | **Apprendre des représentations sans étiquettes** : deux vues d'une même phrase attirent leurs embeddings, les autres phrases les repoussent | sonde linéaire 0,432 (chance 1/7 = 0,143 ; aléatoire gelé 0,161 ; skip-gram BoW 0,154 ; supervisé from scratch 0,368) ; contre-témoin de collapse mesuré (verdict NON) ; ablations température × augmentations × graines avec écart-type inter-graines ; 3 exercices | -| [3.9-Compression-Quantization-FP](3.9-Compression-Quantization-FP.html) | La quantification flottante FP32 → FP16/BF16 écrite bit à bit (arrondi, troncature, découpe mantisse/exposant), vérifiée contre `torch.half()` et `torch.bfloat16` | **Le geste fondateur de la compression** : réduire la largeur d'un format soi-même et mesurer exactement ce qu'on perd | arrondi maison = torch.half()/bfloat16 exactement (0 écart sur 20 000 valeurs) ; troncature = facteur 2,0 en erreur moyenne (FP16 2,009, BF16 1,981) ; erreurs sous les bornes théoriques (FP16 arrondi 4,85e-4 ≤ 4,88e-4) ; falaise FP16 à 65 520 (inf), BF16 la franchit (9,97e37) | -| [3.9a-Compression-Quantization-INT8](3.9a-Compression-Quantization-INT8.html) | La quantification INT8 construite à la main (mapping affine, fake-quant per-tensor/per-channel, activations dynamiques par hooks, calibrations statiques min/max et KL — port fidèle TensorRT) sur ResNet-20/CIFAR-10 entraîné dans le notebook, puis la falaise INT4 | **Le déjeuner gratuit et sa limite** : INT8 égale le FP32 à ±0,001 près pour 4× moins de mémoire ; la discrimination vit dans l'erreur de poids et la falaise INT4 | FP32 0,9019 ; w8 per-tensor 0,9024 / per-channel 0,9020 (erreur s3.1.conv1 : 1,05e-2 vs 7,72e-3) ; dynamique w-channel 0,9018 ; statique min/max 0,9017 ; statique KL 0,9012 (seuils 60-100 % du range, masse coupée ≤ 0,005 %) ; INT4 0,8778 (−2,4 pts, erreur ×18) ; 270 906 poids : 1,08 Mo → 0,27 Mo (4,0×) | -| [3.9b-Compression-Pruning-from-scratch](3.9b-Compression-Pruning-from-scratch.html) | L'élagage construit à la main : masque de magnitude (`kthvalue`) par couche et global, le piège « sparse n'est pas smaller » (octets et MACs du tenseur dense inchangés), puis élagage **structuré** — filtres entiers, transfert de poids sous la contrainte de couplage résiduel, contrôle d'identité bit-à-bit, recalibrage BatchNorm — et la loterie (LTH), sur le même ResNet-20/CIFAR-10 que `3.9a` Contrepoint §9 : l'outil standard `torch.nn.utils.prune` (`l1_unstructured`) sur le même réseau, `prune.remove` pour replier le masque ; comparatif quatre voies à 90 % gardés (§10) : dense, élagage simple, LTH, outil standard. | **Sparse n'est pas smaller** : la sparsité est une propriété des *valeurs*, la taille une propriété des *formes* ; seuls les filtres entiers coupés réduisent réellement poids et MACs | Référence 0,8980 ; à 80 % gardés sans réentraînement : 0,8956 (par couche) / 0,8964 (global) ; 10 % de zéros : 270 896 valeurs stockées (1058,2 Kio) et 40,81 M MACs inchangés ; structuré keep=0,50 : 80 762 poids (−70,4 %) et 21,48 M MACs (−47,4 %), transfert brut 0,1001 → recalibré BN 0,1001 → réentraîné 0,8447, init aléatoire à largeur égale 0,7115 ; keep=0,75 réentraîné 0,8906 ; LTH 90 % gardés reset+réentraîné 0,8172 ; contrôle d'identité à keep=1,0 : écart max 0 \| Contrepoint §9 : accord des masques manuel/outil 100 % (couche stem ; sparsités 9,999 % / 10,000 %), coupe sans réentraînement 0,8970 ; §10 quatre voies : dense 0,8980 / élagage simple 0,8994 / outil standard 0,9021 / LTH 0,8172. -| [3.9c-Pruning-From-Scratch](3.9c-Pruning-From-Scratch.html) | Trois familles de pruning écrites en numpy pur — unstructured magnitude top-k% par layer (Han et al. 2015), structured filter pruning L1-norm sur kernels (Li et al. 2017), Lottery Ticket Hypothesis reset-poids-init + retrain (Frankle & Carlin 2019) — puis confrontation avec `torch.nn.utils.prune` (Bloc B.2 #16060) sur MLP 784-256-128-10 / MNIST subset 20k (CPU-compatible, <10 min) | **Le reset à l'init est la clef LTH — sur terrain léger, Pruning simple gagne** : à 80 % de sparsité effective (mask reappliqué après `opt.step()`, Tell c.1166), LTH 0.9678 et Pruning simple 0.9704 ; `torch.nn.utils.prune` 0.9719 reste au-dessus (hook forward_pre_hook natif) ; l'avantage LTH documenté (Frankle & Carlin 2019) joue sur modèles plus grands (ResNet/CIFAR-10, voir 3.9b) | Dense 0.9675, `torch.nn.utils.prune` 0.9719, LTH 0.9678, Pruning simple 0.9704 ; 235 146 paramètres, ~7s/epoch CPU, 5 epochs/méthode ; 3 exercices C.1 | -| [3.9d-Compression-Distillation-from-scratch](3.9d-Compression-Distillation-from-scratch.html) | La distillation de Hinton écrite à la main (loss `(1−α)·CE + α·T²·KL` sur softmax tempérées, hint FitNets en MSE relative) : un maître ResNet-20 (272 474 paramètres) enseigne à un élève ResNet-8 (78 042, ratio 3,5×) sur CIFAR-10, même recette SGD/cosine/crop+flip, 3 graines + balayage T ∈ {1, 2, 4, 8} | **Le rattrapage partiel mesuré en σ** : à budget égal, l'élève distillé gagne +2,05 pts (+12,6 σ sur 3 graines) — le pendant « entraînement » de la compression, là où le 3.9a montre son pendant « déploiement » | maître 0,9012 ; scratch 0,8437 ± 0,0015 ; KD T=4 α=0,7 0,8642 ± 0,0006 (+12,6 σ, écart-type ÷ 2,5) ; + hint FitNets 0,8654 ± 0,0022 (~0,5 σ vs KD seul — verdict honnête) ; balayage T 0,8512 / 0,8624 / 0,8647 / 0,8595 (sommet mesuré T=4) ; dark knowledge : masse non-cible 0,086 → 0,609 entre T=1 et T=4 ; 3 exercices | -| [3.9e-Compression-Quantization-SOTA](3.9e-Compression-Quantization-SOTA.html) | Le pendant SOTA de 3.9a : la même INT8 par l'écosystème torch.ao — quantification dynamique, FX graphes statiques (MinMax, Histogramme), observateurs déclarés | **L'écosystème contre la main** : même exactitude à ±0,001, zéro mécanique écrite | témoin FP32 0,7896 (recette CPU 6 époques) ; dynamique fc INT8 0,7898 (+0,0002) ; FX MinMax 0,7900 (+0,0004, 10 conv fusionnés) ; FX Histogramme 0,7901 (+0,0005) | -| [3.9f-Compression-Pruning-SOTA](3.9f-Compression-Pruning-SOTA.html) | Le pendant élagage de la famille compression : magnitude pruning écrit à la main (quelques lignes) puis déclaré à l'API `torch.nn.utils.prune` (`l1_unstructured`, `global_unstructured`, `random_unstructured` en contre-témoin, `ln_structured` par canaux), sur le même témoin ResNet-20/CIFAR-10 | **Un masque, quatre décisions** : critère, allocation locale/globale, granularité, persistance — l'API garantit le masque (hooks), la main donne le contrôle | témoin FP32 0,7896 (recette CPU 6 époques) ; main 50 % : 0,5775 ≈ API L1 50 % : 0,5791 (même sélection, écart 0,0016 = ordres flottants) ; global L1 75 % : 0,4031 vs random 75 % : 0,1000 — l'allocation bat l'uniforme à budget égal ; structuré 50 % canaux : 0,1000 (336 canaux morts) ; state_dict 1071 Ko → 2129 Ko (orig+masque) → 1071 Ko après `remove()` ; latence 30,7 → 33,8 ms : rien gagné sans format épars | -| [3.9g-Compression-Comparatif-A-vs-B](3.9g-Compression-Comparatif-A-vs-B.html) | Le capstone comparatif de la famille compression (bloc 7 de #16060) : le même ResNet-20 entraîné une fois (40 époques GPU), passé sous chaque méthode avec les mêmes instruments — accuracy, taille brute + compressée zlib, latence CPU médiane batch 64, FLOPs par hooks, LOC par `inspect.getsource` — INT8 dynamique manuel (per-tensor uint8) vs `quantize_dynamic`, pruning magnitude 50 % post-training par couche (manuel, `kthvalue`) vs `global_unstructured` (sélection globale L1), FP16 | **La vraie différence A-vs-B n'est pas l'outillage, c'est la politique** : INT8 dynamique sur un CNN à dominance conv ne touche que 0,2 % des poids (±0,02 pt, aucune accélération — le gain INT8 des CNN vit dans le FX statique de 3.9e) ; à budget de coupes égal, l'allocation globale conserve 5,96 pts de plus que la par couche | FP32 0,9036 ; INT8 manuel 0,9038 (+0,02, 25 LOC) ≈ torch.ao 0,9036 (0,00, 1 LOC) ; pruning par couche 0,8122 (−9,14, 14 LOC) vs global 0,8718 (−3,18, 1 LOC) ; tailles brutes 1070,6 Ko partout sauf FP16 535,4 Ko (×2,0, 0,9038) ; zlib 1003,6 → 597,2/594,9 Ko pour le pruning (×1,7) ; latence CPU 25,7-30,3 ms sans gain structurel pour aucune méthode ; FLOPs 40,8 M partout ; 3 exercices C.1 (per-channel, taux de coupure par dichotomie, pipeline combiné) | -| [3.10-Modeles-Generatifs-Diffusion-SOTA](3.10-Modeles-Generatifs-Diffusion-SOTA.html) | Le pendant SOTA de 3.6c/d/e : la bibliothèque `diffusers` (DDPM, DDIM, UNet outillé, pipelines) face aux implémentations maison | **La librairie : moins de code, plus d'outils, mêmes maths** — et la stochasticité de η rendue visible | maison ancestral 31 LOC, 92,7 ms/img, MMD 0,0419 ; maison DDIM(20) 22 LOC, 1,6 ms/img ; lib DDIM(20) 8 LOC, 7,0 ms/img, 0,0448 ; classes couvertes 10/10 (maison) vs 9/10 (lib) ; η=1,0 : écart 0,34 entre 2 runs de même x_T | -| [3.11-Budget-Memoire-Entrainement](3.11-Budget-Memoire-Entrainement.html) | Le budget mémoire d'un entraînement — poids, gradients, états d'optimiseur, activations — **calculé à la main puis confronté à la mesure** sur un mini-GPT réel, chaque écart servant à corriger le modèle (premier volet de #18210) | **Les activations ne sont pas proportionnelles au lot** : la rétropropagation retient les matrices engagées dans les multiplications, donc la loi est affine, A = A₀ + k·lot — et le terme constant A₀ vaut, à 0,87 % près, les poids eux-mêmes | formule des paramètres corrigée par la mesure : les termes omis (plongement positionnel, LayerNorms) valaient +4 736/+10 496/+17 280 selon la taille, résidu **0** après correction et décomposé terme à terme (12 288 + 4 608 + 384) ; ajustement affine sur lots 1-32 : A₀ = 3 667 524 o, k = 2 815 488 o/lot, **résidus nuls**, A₀/P = 0,9913, coefficient c = 21,48 valeurs retenues par élément (littérature en précision mixte : 34, rapport 0,63) ; le rapport naïf A/(lot·s·d·L) surestime c à petit lot (49,46 au lot 1 → 22,35 au lot 32) ; lois vérifiées en s (écart ≤ 0,1 %) et en d (A₀ ×3,50/×3,72, k ×1,69/×1,81 — sous-linéaire, dit comme tel) ; budget à lot 8 : petit 8,36 GiB, moyen 56,68 GiB, grand 209,84 GiB, lot maximal 24 GiB → 29 / 1 / ne tient pas ; mesure sur RTX 3090 : après modèle +22,17 MiB contre 22,15 attendus, et pic de rétropropagation 346,56 MiB **inférieur** à la somme analytique 368,52 (rapport 0,940) ; 3 exercices C.1 | -| [3.12-Les-Collectives](3.12-Les-Collectives.html) | L'anneau `all-reduce` écrit à la main (reduce-scatter puis all-gather, `batch_isend_irecv`) contre l'appel natif `dist.all_reduce`, sur `gloo`/CPU à 2 et 4 rangs — exactitude, éléments sur le fil, messages, puis chronométrage (deuxième volet de #18210) | **Le compte, pas la durée** : le volume par rang de l'anneau, 2(p−1)n/p, tend vers 2n quand p grandit — la moitié du schéma naïf à 4 rangs — mais la somme flottante n'étant pas associative, les deux implémentations ne rendent pas le même résultat | égalité **au bit** avec l'appel natif sur des entiers ; à 4 rangs 12 messages (= 4(p−1)) et 18 éléments envoyés par rang contre 36 pour le schéma naïf (exactement p/2), à 2 rangs 12 contre 12 (aucun gain) ; la non-associativité est d'abord établie hors réseau — ((1e16+1,0)−1e16)+3,0 = 3,0 contre (1e16−1e16)+(1,0+3,0) = 4,0 — puis **retrouvée dans la mesure** : à 4 rangs l'anneau rend 3,0 et le natif 4,0 (écart 1,0), à 2 rangs les deux coïncident (1e16, le petit terme absorbé) ; chronométrage : à 4 rangs et 2 Mo l'anneau est plus lent sans recouvrement (facteur 1,3-1,6 selon la série), à 32 Mo les deux plages se recouvrent (inséparables, dit comme tel) ; inversion mesurée que le carnet n'explique pas — à 32 Mo le natif à 2 rangs (0,102-0,284 s) est ~1,8× plus lent qu'à 4 rangs (0,068-0,119 s) ; noyau `coursia-ml-training` **requis** (`gloo` échoue à créer son périphérique sous le noyau générique — mesuré) ; 3 exercices C.1 | -| [3.13-Decouper-le-Modele-DDP-ZeRO-FSDP](3.13-Decouper-le-Modele-DDP-ZeRO-FSDP.html) | Où va la mémoire quand on découpe : `DistributedDataParallel`, `ZeroRedundancyOptimizer` (ZeRO-1) et `FullyShardedDataParallel` (ZeRO-2 `SHARD_GRAD_OP` et ZeRO-3 `FULL_SHARD`) mesurés sur le même modèle à 2 et 4 rangs, puis l'occupation du parallélisme de pipeline — GPipe contre 1F1B — comptée par `saved_tensors_hooks` (troisième volet de #18210) | **Ce qui est découpé décide de tout, et deux stratégies peuvent coïncider au repos** : ZeRO-2 et ZeRO-3 rendent le même total à l'arrêt, parce que la différence documentée entre elles est *quand* FSDP resharde les paramètres — donc dans le pic, invisible sur un relevé au repos, et dit comme tel | par rang sur 526 336 paramètres (4P = 2 105 344 o) : DDP 8 421 440 o (4,00 P) à 2 **comme** à 4 rangs — répliqué, insensible au monde ; ZeRO-1 6 316 064 o (3,00 P) puis 5 263 376 o (2,50 P), seul l'état d'optimiseur (8P) se divisant ; ZeRO-2 et ZeRO-3 identiques, 4 210 692 o (2,00 P) puis 2 105 348 o (1,00 P) ; deux pièges de mesure documentés — l'état de ZeRO-1 vit dans l'optimiseur **local** (`opt.optim.state`), une lecture sur l'enveloppe rend 0 et fabrique une économie totale qui n'existe pas, et FSDP refuse le CPU dans sa seule branche d'auto-détection, qu'un `device_id=torch.device("cpu")` explicite contourne légitimement ; pipeline à 2 rangs : pic de tenseurs vivants du dernier étage 5 × horizon pour GPipe (10 / 20 / 40 aux horizons 2 / 4 / 8) contre **constant à 5** pour 1F1B, pour 40 sauvegardes dans les deux cas — et `mb_args` attend un **micro-lot**, le lot complet faisant bloquer `gloo` sans message ; 3 exercices C.1 | -| [3.13b-Deux-Cartes-Reelles-DDP-FSDP-nccl](3.13b-Deux-Cartes-Reelles-DDP-FSDP-nccl.html) | Le même dispositif que 3.13 transporté sur deux vraies cartes hétérogènes (RTX 3090 et RTX 3080 Ti) sous `nccl`, dans un conteneur Linux : DDP puis FSDP `FULL_SHARD` à 2 rangs, un par carte — le **pic CUDA** mesuré (`max_memory_allocated`, pas recalculé) et le **temps par pas** s'ajoutent aux octets détenus, puis le diagnostic du rang lent : une pause de 50 ms injectée après chaque pas sur un seul rang (quatrième volet de #18210, sous #19256) | **Le découpage paie en mémoire et facture en temps — et dans un couple déséquilibré, celui qui attend n'est pas celui qui traîne** : le sharding divise l'état détenu mais rallonge le pas, car chaque couche se regroupe à la volée ; et l'attente du all-reduce se lit chez la carte **saine**, pas chez la lente | par rang sur 134 M paramètres : DDP détient 4,00 P et pointe à 3 091 Mo, FSDP retombe à 2,00 P et pointe à 1 299 Mo — **au-dessus** du 2P nu (1 074 Mo) : les tampons de regroupement vivent par-dessus l'état découpé ; pas médian 402 ms (DDP) contre 654 ms (FSDP), soit environ 63 % de temps par pas en plus pour un pic réduit d'un facteur 2,4 — un arbitrage, pas un gain gratuit ; rang lent : la pause de 50 ms sur le rang 0 laisse ses propres pas courts (394 ms) et fait passer le rang sain de 402 à 444 ms — il paie exactement la pause de l'autre ; exécution via conteneur `pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime` (`--gpus all`, `--shm-size 8g`) ; 3 exercices C.1 | +| [3.0-Theorie-Information](3.0-Theorie-Information.ipynb) | Entropie, cross-entropy et KL construites from scratch sur un texte français, puis MSE vs cross-entropy sur un classifieur (le piège du gradient saturé), température (softmax) et pont vers DPO/GRPO | **La loss qui fait apprendre** : pourquoi la cross-entropy (et pas la MSE) est la bonne loss d'un classifieur, et la KL comme mesure de décalage entre deux distributions de modèle | entropie du français ~4,4 bits (redondance ~10-15 %, borne ≤ log₂K vérifiée) ; identité H(p,q)=H(p)+D_KL vérifiée, KL>0 sur tout le balayage (Gibbs) ; init saturée et fausse : la CE s'échappe (0,88) quand la MSE reste bloquée (0,39), gradient CE/MSE ~51× ; log 0 maîtrisé par lissage ε ; KL minimale en T=1 | +| [3.1-Retropropagation](3.1-Retropropagation.ipynb) | Le MLP et la rétropropagation à la main (NumPy pur, sans autograd) | **Le gradient vérifié** : différence finie vs analytique, parité exacte avec PyTorch | écart 1,3e-11 (seuil 1e-6) ; loss initiale, premier pas et trajectoire 3000 iters identiques à 1,1e-16 près ; init nulle = gradient nul (0,500 figé) | +| [3.2-Optimisateurs](3.2-Optimisateurs.ipynb) | Momentum, Adagrad, RMSProp, Adam et schedules, écrits en NumPy pur puis validés pas à pas contre `torch.optim` | **La parité exacte** : les 5 mises à jour sont celles de torch | GD/momentum/Adam à 1,11e-16, Adagrad bit-à-bit (0,00e+00), RMSProp à 2,22e-16 (float64, 1 pas) ; Beale : 5 trajectoires superposées (facteur 200 entre lr utilisables) ; MLP du 3.1 : 5 optimisateurs × 3 graines (RMSProp 0,059 < Adam 0,061 < … < GD 0,070) ; schedules : coût en full-batch déterministe, gain sous le plancher de bruit en mini-batch | +| [3.3-Regularisation](3.3-Regularisation.ipynb) | Dropout, weight decay et early stopping écrits à la main sur un MLP construit pour surapprendre (17 000 paramètres, 100 points d'entraînement, 12 étiquettes fausses) | **Corriger la variance sans changer le modèle** : trois remèdes appliqués au même surapprentissage fabriqué | sans régularisation : val acc 84,0 % (les 12 erreurs mémorisées) ; dropout p=0,3 : 89,0 % ; early stopping : +4,5 % ; gradient check du dropout (masque gelé) et invariants du dropout inverse (p=0,4, 2000×50) | +| [3.4-Attention-Transformer-From-Scratch](3.4-Attention-Transformer-From-Scratch.ipynb) | De l'attention mono-tête lisible sur l'inversion de séquence au mini-GPT de 1,25 M entraîné dans le notebook | **L'attention jusqu'au bout, sur CPU** : attention + masque causal + multi-têtes + bloc pré-norme, équivalence numérique avec `torch.nn`, mini-GPT char-level entraîné (117 s) sur le *Horla* (Maupassant, domaine public, 59 k caractères) | sac de mots A = B pour phrases opposées (1-9) ; inversion : poids requete 0 = `[0,007 0,007 0,007 0,007 0,007 0,967]` ; multi-têtes maison vs `torch.nn.MultiheadAttention` à 2,38e-07 (assert allclose 1e-5) ; mini-GPT 1 251 040 paramètres : perte ln(85)=4,44 → train 2,46 / val 2,45 en 800 étapes (117 s), perplexité val 11,5 ; 4 têtes spécialisées post-entraînement (diagonale 0,110 / 0,172 / 0,133 / 0,102) | +| [3.4c-MoE-from-scratch](3.4c-MoE-from-scratch.ipynb) | La couche Mixture of Experts écrite à la main (routeur top-k, capacité par expert avec jetons jetés, loss d'équilibrage `E·Σ f_i·P_i`), son coût mesuré en millisecondes contre deux FFN denses d'équivalence (iso-calcul, iso-paramètres) puis son entraînement dense contre MoE sur la tâche jouet du TV-00b (série TransformerVariants) | **Découpler paramètres et calcul** : E experts dont seuls k travaillent par jeton — le banc entrelacé mesure ce que la promesse vaut réellement, routage compris | routeur vérifié sur cas contrôlés (entropie uniforme 2,0794 = ln 8, tie-break de `topk` exposé) ; banc de coût : MoE E=8 k=2 (1 054 720 params) à 0,75× le temps du dense-32d iso-paramètres mais ~2,9× le dense-8d iso-calcul (rapports calculés dans la même cellule ; les temps absolus varient avec la machine) — le routage top-k a un coût propre qui mange une partie de l'économie théorique ; qualité : la tâche jouet ne discrimine pas (acc 1,000 partout, dit comme tel) — l'information est dans les routeurs : sans loss d'équilibrage, parts 0,284…0,000 ; avec α=0,01, parts 0,118–0,134 quasi uniformes (L_aux 1,29 → 1,00) ; 3 exercices | +| [3.4d-Fourier-Features-Biais-Spectral](3.4d-Fourier-Features-Biais-Spectral-Python.ipynb) | Le **biais spectral** d'un MLP tanh reproduit empiriquement (Rahaman et al. 2019) face à un signal 1D à 13 cycles, puis débloqué par le mapping de Fourier `γ(x) = [cos(2πB x), sin(2πB x)]` avec `B ~ N(0, σ²)` (Tancik et al. 2020, geste NeRF) — trois régimes mesurés (sous-ajustement, bande utile, aliasing) plus un témoin négatif qui combine σ=50 et h=256 : la capacité mémorise le train sans récupérer le test | **Le MLP n'apprend pas les hautes fréquences** : la NTK tanh a une bande passante trop étroite pour la cible 13 cycles ; un mapping `B ~ N(0, σ²)` adapté la débloque, σ excessif re-sur-ajuste — la MSE comme bande à dépasser, pas comme optimum ponctuel | garde gradient 2,08e-07 (seuil 1e-5) ; balayage σ (64 pts train / 400 test, seed 0) : baseline 3,23e-01 (plafond spectral), σ=1 1,40e-02, σ=2 minimum à 8,33e-03, σ=5 1,21e-02, σ=10 9,70e-03, σ=20 7,41e-02 (aliasing), σ=50 4,42e-01 ; témoin négatif σ=50 + h=256 (99 073 paramètres) : MSE train 1,36e-07 contre test 4,32e-01, rapport 3,2e-07 — la capacité mémorise le train sans gain au test ; 3 exercices | +| [3.5-Phenomenes-de-Generalisation](3.5-Phenomenes-de-Generalisation.ipynb) | Grokking et double descente reproduits en NumPy pur (MLP à embeddings + Adam à la main), confrontés à la borne PAC du 2.8 | **Le phénomène sans la boîte noire** : mémorisation → transition abrupte, et le W de la double descente | garde gradient ≤ 1e-6 (embeddings inclus) ; grok mesuré : train saturé ~500 pas, test 100 % des dizaines de milliers de pas plus tard (wd = 1) ; contre-témoin wd = 0 ; double descente : pic au seuil M ≈ n (×5 le creux), asymptote moderne sous le creux classique, 20 graines | +| [3.6-Modeles-Generatifs](3.6-Modeles-Generatifs.ipynb) | VAE, GAN et diffusion (DDPM) écrits en NumPy pur, même cible (huit modes sur un cercle), même budget (6 000 pas, batch 256, largeur 64), face à une baseline GMM ajustée par EM | **Trois objectifs, trois échecs** : le VAE couvre mais moyenne, le GAN s'effondre, la diffusion raffine au prix de 100 passes par échantillon | garde gradient 1,4e-08 (ELBO + reparamétrisation) et 3,2e-10 (eps-net) ; multi-4-graines : GMM 8/8 disp 0,99 (2,2 s) ; VAE 8/8 disp 6,0 ; GAN 1,5 ± 0,5 modes ; DDPM 8/8 disp 1,51 ; trajectoire de denoising en 5 instantanés (t = 99 → 0) | +| [3.6b-Modeles-Generatifs-PyTorch](3.6b-Modeles-Generatifs-PyTorch.ipynb) | Versant **framework** du 3.6 : VAE, GAN et DDPM (diffusion) entraînés sur une même cible 2D à 4 modes (mélange de Gaussiennes, PyTorch CPU) puis comparés — ELBO vs adversarial vs débruitage | **Le compromis qualité/diversité** : 4 mécanismes génératifs sur les mêmes métriques (couverture de modes, entropie effective), le GMM empirique en référence « modèle exact » | médiane sur 3 graines (budget de pas commun) : GMM cov 4/4 ESS 3,96 · VAE cov 4/4 ESS 3,95 · GAN cov 3/4 ESS 2,99 (perte de diversité, un mode jamais couvert) · Diff cov 4/4 ESS 1,62 (couvre mais sous-échantillonne le mode le plus faible) — verdict nuancé, pas de « gagnant » unique | +| [3.6c-Modeles-Generatifs-Diffusion-from-scratch](3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb) | Le DDPM écrit à la main : schedule β, forme fermée du forward, réseau ε_θ, loss MSE sur le bruit, sampler ancestral — sans librairie de diffusion | **La diffusion sans boîte noire** : chaque pièce du DDPM démontrée et mesurée, schedules linéaire et cosinus comparés à budget égal | 16 entraînements + échantillonnages (17,7 min CPU) ; MMD médiane sur 4 graines par budget × bande passante : le cosinus domine aux petites σ (budget 24, σ 0,25 : 0,00197), le linéaire reprend aux grandes (budget 12, σ 2,0 : 0,02087 vs 0,02359) | +| [3.6d-Modeles-Generatifs-Score-SDE-from-scratch](3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb) | Le passage à la limite continue du DDPM : réseau de score, formulation SDE, et trois solveurs (Euler-Maruyama, Langevin recuit, prédicteur-correcteur) écrits à la main | **La vue continue de la diffusion** : mêmes cibles, plusieurs solveurs, tous mesurés contre un plancher vrai/vrai | plancher vrai/vrai MMD 1,6e-4 ; Euler-Maruyama (réseau) 0,00156, modes 5/5, 1,0 s ; prédicteur-correcteur 0,00259 ; Langevin recuit 0,00894 (12,6 s) ; contre-exemple « mauvais signe » : 0,680, modes 1/5 | +| [3.6e-Modeles-Generatifs-Conditionnels-from-scratch](3.6e-Modeles-Generatifs-Conditionnels-from-scratch.ipynb) | Génération conditionnelle et classifier-free guidance from scratch : le DDPM conditionné par classe, balayage du poids de guidance w | **Guider sans classifieur** : le compromis adhérence/diversité du CFG mesuré sur le même générateur | meilleur w = 1,0 sur les trois bandes passantes (MMD 0,009 à 0,029) ; w = 5,0 : adhérence 0,991 mais la diversité s'effondre (MMD jusqu'à 0,27) | +| [3.7-Distillation-Maitre-Eleve](3.7-Distillation-Maitre-Eleve.ipynb) | Distillation teacher/student : un maître entraîné distille son savoir (dark knowledge) vers un élève ~9× plus petit | **Le facteur T² vérifié** : la KL brute chute en ~1/T², la KL scalée reste constante ; verdict INCONCLUSIVE au seuil strict — gain par exemple net (DM p < 0.001, CE 0.63 → 0.58) mais edge 0.6σ/1.4σ sous 5 folds × 4 graines | maître 0.8906 / distillé 0.8145 vs baseline 0.8029 ; ECE 0.0458 vs 0.0684 ; ratio params 8.9× ; 5 folds × 4 graines (20 paires), entrainement deterministe | +| [3.8-Representations-Contrastives](3.8-Representations-Contrastives.ipynb) | Pré-entraînement contrastif moderne sur vues continues : augmentations contrôlées du sac-de-mots (mask/swap/identité), encodeur MLP et loss InfoNCE écrits from scratch sans autograd, pont explicite vers le skip-gram (cooccurrence discrète vs vue continue) | **Apprendre des représentations sans étiquettes** : deux vues d'une même phrase attirent leurs embeddings, les autres phrases les repoussent | sonde linéaire 0,432 (chance 1/7 = 0,143 ; aléatoire gelé 0,161 ; skip-gram BoW 0,154 ; supervisé from scratch 0,368) ; contre-témoin de collapse mesuré (verdict NON) ; ablations température × augmentations × graines avec écart-type inter-graines ; 3 exercices | +| [3.9-Compression-Quantization-FP](3.9-Compression-Quantization-FP.ipynb) | La quantification flottante FP32 → FP16/BF16 écrite bit à bit (arrondi, troncature, découpe mantisse/exposant), vérifiée contre `torch.half()` et `torch.bfloat16` | **Le geste fondateur de la compression** : réduire la largeur d'un format soi-même et mesurer exactement ce qu'on perd | arrondi maison = torch.half()/bfloat16 exactement (0 écart sur 20 000 valeurs) ; troncature = facteur 2,0 en erreur moyenne (FP16 2,009, BF16 1,981) ; erreurs sous les bornes théoriques (FP16 arrondi 4,85e-4 ≤ 4,88e-4) ; falaise FP16 à 65 520 (inf), BF16 la franchit (9,97e37) | +| [3.9a-Compression-Quantization-INT8](3.9a-Compression-Quantization-INT8.ipynb) | La quantification INT8 construite à la main (mapping affine, fake-quant per-tensor/per-channel, activations dynamiques par hooks, calibrations statiques min/max et KL — port fidèle TensorRT) sur ResNet-20/CIFAR-10 entraîné dans le notebook, puis la falaise INT4 | **Le déjeuner gratuit et sa limite** : INT8 égale le FP32 à ±0,001 près pour 4× moins de mémoire ; la discrimination vit dans l'erreur de poids et la falaise INT4 | FP32 0,9019 ; w8 per-tensor 0,9024 / per-channel 0,9020 (erreur s3.1.conv1 : 1,05e-2 vs 7,72e-3) ; dynamique w-channel 0,9018 ; statique min/max 0,9017 ; statique KL 0,9012 (seuils 60-100 % du range, masse coupée ≤ 0,005 %) ; INT4 0,8778 (−2,4 pts, erreur ×18) ; 270 906 poids : 1,08 Mo → 0,27 Mo (4,0×) | +| [3.9b-Compression-Pruning-from-scratch](3.9b-Compression-Pruning-from-scratch.ipynb) | L'élagage construit à la main : masque de magnitude (`kthvalue`) par couche et global, le piège « sparse n'est pas smaller » (octets et MACs du tenseur dense inchangés), puis élagage **structuré** — filtres entiers, transfert de poids sous la contrainte de couplage résiduel, contrôle d'identité bit-à-bit, recalibrage BatchNorm — et la loterie (LTH), sur le même ResNet-20/CIFAR-10 que `3.9a` Contrepoint §9 : l'outil standard `torch.nn.utils.prune` (`l1_unstructured`) sur le même réseau, `prune.remove` pour replier le masque ; comparatif quatre voies à 90 % gardés (§10) : dense, élagage simple, LTH, outil standard. | **Sparse n'est pas smaller** : la sparsité est une propriété des *valeurs*, la taille une propriété des *formes* ; seuls les filtres entiers coupés réduisent réellement poids et MACs | Référence 0,8980 ; à 80 % gardés sans réentraînement : 0,8956 (par couche) / 0,8964 (global) ; 10 % de zéros : 270 896 valeurs stockées (1058,2 Kio) et 40,81 M MACs inchangés ; structuré keep=0,50 : 80 762 poids (−70,4 %) et 21,48 M MACs (−47,4 %), transfert brut 0,1001 → recalibré BN 0,1001 → réentraîné 0,8447, init aléatoire à largeur égale 0,7115 ; keep=0,75 réentraîné 0,8906 ; LTH 90 % gardés reset+réentraîné 0,8172 ; contrôle d'identité à keep=1,0 : écart max 0 \| Contrepoint §9 : accord des masques manuel/outil 100 % (couche stem ; sparsités 9,999 % / 10,000 %), coupe sans réentraînement 0,8970 ; §10 quatre voies : dense 0,8980 / élagage simple 0,8994 / outil standard 0,9021 / LTH 0,8172. +| [3.9c-Pruning-From-Scratch](3.9c-Pruning-From-Scratch.ipynb) | Trois familles de pruning écrites en numpy pur — unstructured magnitude top-k% par layer (Han et al. 2015), structured filter pruning L1-norm sur kernels (Li et al. 2017), Lottery Ticket Hypothesis reset-poids-init + retrain (Frankle & Carlin 2019) — puis confrontation avec `torch.nn.utils.prune` (Bloc B.2 #16060) sur MLP 784-256-128-10 / MNIST subset 20k (CPU-compatible, <10 min) | **Le reset à l'init est la clef LTH — sur terrain léger, Pruning simple gagne** : à 80 % de sparsité effective (mask reappliqué après `opt.step()`, Tell c.1166), LTH 0.9678 et Pruning simple 0.9704 ; `torch.nn.utils.prune` 0.9719 reste au-dessus (hook forward_pre_hook natif) ; l'avantage LTH documenté (Frankle & Carlin 2019) joue sur modèles plus grands (ResNet/CIFAR-10, voir 3.9b) | Dense 0.9675, `torch.nn.utils.prune` 0.9719, LTH 0.9678, Pruning simple 0.9704 ; 235 146 paramètres, ~7s/epoch CPU, 5 epochs/méthode ; 3 exercices C.1 | +| [3.9d-Compression-Distillation-from-scratch](3.9d-Compression-Distillation-from-scratch.ipynb) | La distillation de Hinton écrite à la main (loss `(1−α)·CE + α·T²·KL` sur softmax tempérées, hint FitNets en MSE relative) : un maître ResNet-20 (272 474 paramètres) enseigne à un élève ResNet-8 (78 042, ratio 3,5×) sur CIFAR-10, même recette SGD/cosine/crop+flip, 3 graines + balayage T ∈ {1, 2, 4, 8} | **Le rattrapage partiel mesuré en σ** : à budget égal, l'élève distillé gagne +2,05 pts (+12,6 σ sur 3 graines) — le pendant « entraînement » de la compression, là où le 3.9a montre son pendant « déploiement » | maître 0,9012 ; scratch 0,8437 ± 0,0015 ; KD T=4 α=0,7 0,8642 ± 0,0006 (+12,6 σ, écart-type ÷ 2,5) ; + hint FitNets 0,8654 ± 0,0022 (~0,5 σ vs KD seul — verdict honnête) ; balayage T 0,8512 / 0,8624 / 0,8647 / 0,8595 (sommet mesuré T=4) ; dark knowledge : masse non-cible 0,086 → 0,609 entre T=1 et T=4 ; 3 exercices | +| [3.9e-Compression-Quantization-SOTA](3.9e-Compression-Quantization-SOTA.ipynb) | Le pendant SOTA de 3.9a : la même INT8 par l'écosystème torch.ao — quantification dynamique, FX graphes statiques (MinMax, Histogramme), observateurs déclarés | **L'écosystème contre la main** : même exactitude à ±0,001, zéro mécanique écrite | témoin FP32 0,7896 (recette CPU 6 époques) ; dynamique fc INT8 0,7898 (+0,0002) ; FX MinMax 0,7900 (+0,0004, 10 conv fusionnés) ; FX Histogramme 0,7901 (+0,0005) | +| [3.9f-Compression-Pruning-SOTA](3.9f-Compression-Pruning-SOTA.ipynb) | Le pendant élagage de la famille compression : magnitude pruning écrit à la main (quelques lignes) puis déclaré à l'API `torch.nn.utils.prune` (`l1_unstructured`, `global_unstructured`, `random_unstructured` en contre-témoin, `ln_structured` par canaux), sur le même témoin ResNet-20/CIFAR-10 | **Un masque, quatre décisions** : critère, allocation locale/globale, granularité, persistance — l'API garantit le masque (hooks), la main donne le contrôle | témoin FP32 0,7896 (recette CPU 6 époques) ; main 50 % : 0,5775 ≈ API L1 50 % : 0,5791 (même sélection, écart 0,0016 = ordres flottants) ; global L1 75 % : 0,4031 vs random 75 % : 0,1000 — l'allocation bat l'uniforme à budget égal ; structuré 50 % canaux : 0,1000 (336 canaux morts) ; state_dict 1071 Ko → 2129 Ko (orig+masque) → 1071 Ko après `remove()` ; latence 30,7 → 33,8 ms : rien gagné sans format épars | +| [3.9g-Compression-Comparatif-A-vs-B](3.9g-Compression-Comparatif-A-vs-B.ipynb) | Le capstone comparatif de la famille compression (bloc 7 de #16060) : le même ResNet-20 entraîné une fois (40 époques GPU), passé sous chaque méthode avec les mêmes instruments — accuracy, taille brute + compressée zlib, latence CPU médiane batch 64, FLOPs par hooks, LOC par `inspect.getsource` — INT8 dynamique manuel (per-tensor uint8) vs `quantize_dynamic`, pruning magnitude 50 % post-training par couche (manuel, `kthvalue`) vs `global_unstructured` (sélection globale L1), FP16 | **La vraie différence A-vs-B n'est pas l'outillage, c'est la politique** : INT8 dynamique sur un CNN à dominance conv ne touche que 0,2 % des poids (±0,02 pt, aucune accélération — le gain INT8 des CNN vit dans le FX statique de 3.9e) ; à budget de coupes égal, l'allocation globale conserve 5,96 pts de plus que la par couche | FP32 0,9036 ; INT8 manuel 0,9038 (+0,02, 25 LOC) ≈ torch.ao 0,9036 (0,00, 1 LOC) ; pruning par couche 0,8122 (−9,14, 14 LOC) vs global 0,8718 (−3,18, 1 LOC) ; tailles brutes 1070,6 Ko partout sauf FP16 535,4 Ko (×2,0, 0,9038) ; zlib 1003,6 → 597,2/594,9 Ko pour le pruning (×1,7) ; latence CPU 25,7-30,3 ms sans gain structurel pour aucune méthode ; FLOPs 40,8 M partout ; 3 exercices C.1 (per-channel, taux de coupure par dichotomie, pipeline combiné) | +| [3.10-Modeles-Generatifs-Diffusion-SOTA](3.10-Modeles-Generatifs-Diffusion-SOTA.ipynb) | Le pendant SOTA de 3.6c/d/e : la bibliothèque `diffusers` (DDPM, DDIM, UNet outillé, pipelines) face aux implémentations maison | **La librairie : moins de code, plus d'outils, mêmes maths** — et la stochasticité de η rendue visible | maison ancestral 31 LOC, 92,7 ms/img, MMD 0,0419 ; maison DDIM(20) 22 LOC, 1,6 ms/img ; lib DDIM(20) 8 LOC, 7,0 ms/img, 0,0448 ; classes couvertes 10/10 (maison) vs 9/10 (lib) ; η=1,0 : écart 0,34 entre 2 runs de même x_T | +| [3.11-Budget-Memoire-Entrainement](3.11-Budget-Memoire-Entrainement.ipynb) | Le budget mémoire d'un entraînement — poids, gradients, états d'optimiseur, activations — **calculé à la main puis confronté à la mesure** sur un mini-GPT réel, chaque écart servant à corriger le modèle (premier volet de #18210) | **Les activations ne sont pas proportionnelles au lot** : la rétropropagation retient les matrices engagées dans les multiplications, donc la loi est affine, A = A₀ + k·lot — et le terme constant A₀ vaut, à 0,87 % près, les poids eux-mêmes | formule des paramètres corrigée par la mesure : les termes omis (plongement positionnel, LayerNorms) valaient +4 736/+10 496/+17 280 selon la taille, résidu **0** après correction et décomposé terme à terme (12 288 + 4 608 + 384) ; ajustement affine sur lots 1-32 : A₀ = 3 667 524 o, k = 2 815 488 o/lot, **résidus nuls**, A₀/P = 0,9913, coefficient c = 21,48 valeurs retenues par élément (littérature en précision mixte : 34, rapport 0,63) ; le rapport naïf A/(lot·s·d·L) surestime c à petit lot (49,46 au lot 1 → 22,35 au lot 32) ; lois vérifiées en s (écart ≤ 0,1 %) et en d (A₀ ×3,50/×3,72, k ×1,69/×1,81 — sous-linéaire, dit comme tel) ; budget à lot 8 : petit 8,36 GiB, moyen 56,68 GiB, grand 209,84 GiB, lot maximal 24 GiB → 29 / 1 / ne tient pas ; mesure sur RTX 3090 : après modèle +22,17 MiB contre 22,15 attendus, et pic de rétropropagation 346,56 MiB **inférieur** à la somme analytique 368,52 (rapport 0,940) ; 3 exercices C.1 | +| [3.12-Les-Collectives](3.12-Les-Collectives.ipynb) | L'anneau `all-reduce` écrit à la main (reduce-scatter puis all-gather, `batch_isend_irecv`) contre l'appel natif `dist.all_reduce`, sur `gloo`/CPU à 2 et 4 rangs — exactitude, éléments sur le fil, messages, puis chronométrage (deuxième volet de #18210) | **Le compte, pas la durée** : le volume par rang de l'anneau, 2(p−1)n/p, tend vers 2n quand p grandit — la moitié du schéma naïf à 4 rangs — mais la somme flottante n'étant pas associative, les deux implémentations ne rendent pas le même résultat | égalité **au bit** avec l'appel natif sur des entiers ; à 4 rangs 12 messages (= 4(p−1)) et 18 éléments envoyés par rang contre 36 pour le schéma naïf (exactement p/2), à 2 rangs 12 contre 12 (aucun gain) ; la non-associativité est d'abord établie hors réseau — ((1e16+1,0)−1e16)+3,0 = 3,0 contre (1e16−1e16)+(1,0+3,0) = 4,0 — puis **retrouvée dans la mesure** : à 4 rangs l'anneau rend 3,0 et le natif 4,0 (écart 1,0), à 2 rangs les deux coïncident (1e16, le petit terme absorbé) ; chronométrage : à 4 rangs et 2 Mo l'anneau est plus lent sans recouvrement (facteur 1,3-1,6 selon la série), à 32 Mo les deux plages se recouvrent (inséparables, dit comme tel) ; inversion mesurée que le carnet n'explique pas — à 32 Mo le natif à 2 rangs (0,102-0,284 s) est ~1,8× plus lent qu'à 4 rangs (0,068-0,119 s) ; noyau `coursia-ml-training` **requis** (`gloo` échoue à créer son périphérique sous le noyau générique — mesuré) ; 3 exercices C.1 | +| [3.13-Decouper-le-Modele-DDP-ZeRO-FSDP](3.13-Decouper-le-Modele-DDP-ZeRO-FSDP.ipynb) | Où va la mémoire quand on découpe : `DistributedDataParallel`, `ZeroRedundancyOptimizer` (ZeRO-1) et `FullyShardedDataParallel` (ZeRO-2 `SHARD_GRAD_OP` et ZeRO-3 `FULL_SHARD`) mesurés sur le même modèle à 2 et 4 rangs, puis l'occupation du parallélisme de pipeline — GPipe contre 1F1B — comptée par `saved_tensors_hooks` (troisième volet de #18210) | **Ce qui est découpé décide de tout, et deux stratégies peuvent coïncider au repos** : ZeRO-2 et ZeRO-3 rendent le même total à l'arrêt, parce que la différence documentée entre elles est *quand* FSDP resharde les paramètres — donc dans le pic, invisible sur un relevé au repos, et dit comme tel | par rang sur 526 336 paramètres (4P = 2 105 344 o) : DDP 8 421 440 o (4,00 P) à 2 **comme** à 4 rangs — répliqué, insensible au monde ; ZeRO-1 6 316 064 o (3,00 P) puis 5 263 376 o (2,50 P), seul l'état d'optimiseur (8P) se divisant ; ZeRO-2 et ZeRO-3 identiques, 4 210 692 o (2,00 P) puis 2 105 348 o (1,00 P) ; deux pièges de mesure documentés — l'état de ZeRO-1 vit dans l'optimiseur **local** (`opt.optim.state`), une lecture sur l'enveloppe rend 0 et fabrique une économie totale qui n'existe pas, et FSDP refuse le CPU dans sa seule branche d'auto-détection, qu'un `device_id=torch.device("cpu")` explicite contourne légitimement ; pipeline à 2 rangs : pic de tenseurs vivants du dernier étage 5 × horizon pour GPipe (10 / 20 / 40 aux horizons 2 / 4 / 8) contre **constant à 5** pour 1F1B, pour 40 sauvegardes dans les deux cas — et `mb_args` attend un **micro-lot**, le lot complet faisant bloquer `gloo` sans message ; 3 exercices C.1 | +| [3.13b-Deux-Cartes-Reelles-DDP-FSDP-nccl](3.13b-Deux-Cartes-Reelles-DDP-FSDP-nccl.ipynb) | Le même dispositif que 3.13 transporté sur deux vraies cartes hétérogènes (RTX 3090 et RTX 3080 Ti) sous `nccl`, dans un conteneur Linux : DDP puis FSDP `FULL_SHARD` à 2 rangs, un par carte — le **pic CUDA** mesuré (`max_memory_allocated`, pas recalculé) et le **temps par pas** s'ajoutent aux octets détenus, puis le diagnostic du rang lent : une pause de 50 ms injectée après chaque pas sur un seul rang (quatrième volet de #18210, sous #19256) | **Le découpage paie en mémoire et facture en temps — et dans un couple déséquilibré, celui qui attend n'est pas celui qui traîne** : le sharding divise l'état détenu mais rallonge le pas, car chaque couche se regroupe à la volée ; et l'attente du all-reduce se lit chez la carte **saine**, pas chez la lente | par rang sur 134 M paramètres : DDP détient 4,00 P et pointe à 3 091 Mo, FSDP retombe à 2,00 P et pointe à 1 299 Mo — **au-dessus** du 2P nu (1 074 Mo) : les tampons de regroupement vivent par-dessus l'état découpé ; pas médian 402 ms (DDP) contre 654 ms (FSDP), soit environ 63 % de temps par pas en plus pour un pic réduit d'un facteur 2,4 — un arbitrage, pas un gain gratuit ; rang lent : la pause de 50 ms sur le rang 0 laisse ses propres pas courts (394 ms) et fait passer le rang sain de 402 à 444 ms — il paie exactement la pause de l'autre ; exécution via conteneur `pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime` (`--gpus all`, `--shm-size 8g`) ; 3 exercices C.1 | | [3.14-Debug-Entrainement-N-Apprend-Pas](3.14-Debug-Entrainement-N-Apprend-Pas-Python.ipynb) | Diagnostiquer un entrainement qui boucle sans faire baisser la perte : loss qui stagne, oscille, explose ou plafonne. Cinq controles systematiques appliques dans l ordre -- data pipeline (shape/range/NaN), loss adaptee a la tache, gradient (norme non-NaN et raisonnable), learning rate (ni trop petit ni trop grand), initialisation (poids pas tous a zero). Le carnet utilise `SGDClassifier` de scikit-learn (CPU strict) sur une classification binaire jouet, la perte mesuree explicitement par `log_loss` a chaque passe -- un diagnostic **avant** l installation de la pile GPU | **Tout entrainement qui tourne sans apprendre releve d un des cinq controles casse** -- lr trop petit (stagne a la perte initiale), lr trop grand (oscille puis explose), data pipeline (X et y de shapes incompatibles ou normalisation absente), initialisation (matrices de poids a zero), ou loss non adaptee a la tache (`squared_loss` sur classification, par exemple). Les checks 1 et 4 sont outilles dans le carnet (les trois autres dependent du framework) ; le diagnostic tient en moins de cinq minutes sur CPU, avant de bruler du budget GPU | mesure a graine fixe (random_state=42) -- lr=1e-6 : la perte reste au niveau du hasard, 0.6931 a 0.6896 en 50 passes -- lr=10.0 : la perte oscille (0.66, 0.24, 0.53) sans converger -- lr=50.0 : la perte depasse 1, le modele se trompe avec confiance -- lr=0.01 : 0.69 des la premiere passe a 0.38, puis 0.11 en 30 passes. Le diagnostic tranche les six taux testes (stagne / converge / oscille / explose). Exercices C.1 : reproduire les deux patterns symptomatiques, puis appliquer le diagnostic a un modele lineaire malade | @@ -59,8 +59,8 @@ séries (RL, PostTraining, ML-Training-Pipeline). L'entraînement final du 2.9 e Les deux chantiers annoncés par cette feuille de route sont livrés : théorie de l'information appliquée — entropie, KL, cross-entropy (#12420, livrée par #12640 → notebook -[3.0](3.0-Theorie-Information.html)) ; régularisation — dropout, weight decay, early stopping -(#12409, livrée par #12527 → notebook [3.3](3.3-Regularisation.html)). Le fil directeur n'a +[3.0](3.0-Theorie-Information.ipynb)) ; régularisation — dropout, weight decay, early stopping +(#12409, livrée par #12527 → notebook [3.3](3.3-Regularisation.ipynb)). Le fil directeur n'a pas changé et vaut pour la suite : chaque mécanisme écrit à la main, vérifié contre torch, puis consommé via l'API officielle. @@ -87,25 +87,25 @@ Cette série ancre ses carnets dans la **référence canonique du deep learning* | Chapitre | Sujet | Carnet(s) d'ancrage | |---|---|---| -| ch. 5 | Machine learning de base | [3.0-Théorie-Information](3.0-Theorie-Information.html) (entropie, KL) | -| ch. 6 (6.5) | Réseaux feedforward, backprop | [3.1-Rétropropagation](3.1-Retropropagation.html) — contre-exemple fondateur soldé | -| ch. 7 (5.2.2, 7.5, 7.8) | Régularisation | [3.3-Régularisation](3.3-Regularisation.html) | -| ch. 8 (8.1-8.3) | Optimisation pour le deep learning | [2.2-Descente-de-gradient](../02-ML-Cours/2.2-Descente-de-gradient.html) (carnet 02, ancrage par [#19329](https://github.com/jsboige/CoursIA/pull/19329)) | -| ch. 9 | Réseaux convolutifs | [4.1-Conv-NumPy-Torch-Allclose](../04-Vision/4.1-Conv-NumPy-Torch-Allclose.html) | -| ch. 14 | Autoencodeurs | (passerelle vers [3.6](3.6-Modeles-Generatifs.html) / [3.6b](3.6b-Modeles-Generatifs-PyTorch.html), ch. 20) | -| ch. 20 (20.10.3, 20.10.4, 20.10.5) | Modèles génératifs profonds (VAE, GAN, débruitage) | [3.6-Modeles-Generatifs](3.6-Modeles-Generatifs.html), [3.6b-Modeles-Generatifs-PyTorch](3.6b-Modeles-Generatifs-PyTorch.html) | +| ch. 5 | Machine learning de base | [3.0-Théorie-Information](3.0-Theorie-Information.ipynb) (entropie, KL) | +| ch. 6 (6.5) | Réseaux feedforward, backprop | [3.1-Rétropropagation](3.1-Retropropagation.ipynb) — contre-exemple fondateur soldé | +| ch. 7 (5.2.2, 7.5, 7.8) | Régularisation | [3.3-Régularisation](3.3-Regularisation.ipynb) | +| ch. 8 (8.1-8.3) | Optimisation pour le deep learning | [2.2-Descente-de-gradient](../02-ML-Cours/2.2-Descente-de-gradient.ipynb) (carnet 02, ancrage par [#19329](https://github.com/jsboige/CoursIA/pull/19329)) | +| ch. 9 | Réseaux convolutifs | [4.1-Conv-NumPy-Torch-Allclose](../04-Vision/4.1-Conv-NumPy-Torch-Allclose.ipynb) | +| ch. 14 | Autoencodeurs | (passerelle vers [3.6](3.6-Modeles-Generatifs.ipynb) / [3.6b](3.6b-Modeles-Generatifs-PyTorch.ipynb), ch. 20) | +| ch. 20 (20.10.3, 20.10.4, 20.10.5) | Modèles génératifs profonds (VAE, GAN, débruitage) | [3.6-Modeles-Generatifs](3.6-Modeles-Generatifs.ipynb), [3.6b-Modeles-Generatifs-PyTorch](3.6b-Modeles-Generatifs-PyTorch.ipynb) | -**Lecture recommandée du livre** pour cette série : ch. 6 (pour [3.1](3.1-Retropropagation.html)), ch. 8 (pour [2.2](../02-ML-Cours/2.2-Descente-de-gradient.html) et [3.2](3.2-Optimisateurs.html)), ch. 9 (pour [4.1](../04-Vision/4.1-Conv-NumPy-Torch-Allclose.html)), ch. 20 (pour [3.6](3.6-Modeles-Generatifs.html), [3.6b](3.6b-Modeles-Generatifs-PyTorch.html), [3.6c](3.6c-Modeles-Generatifs-Diffusion-from-scratch.html), [3.6d](3.6d-Modeles-Generatifs-Score-SDE-from-scratch.html), [3.6e](3.6e-Modeles-Generatifs-Conditionnels-from-scratch.html)). Le livre est **PDF archivé** dans le gisement partagé — voir [docs/reference/bibliography-hygiene.md](../../../../docs/reference/bibliography-hygiene.md). +**Lecture recommandée du livre** pour cette série : ch. 6 (pour [3.1](3.1-Retropropagation.ipynb)), ch. 8 (pour [2.2](../02-ML-Cours/2.2-Descente-de-gradient.ipynb) et [3.2](3.2-Optimisateurs.ipynb)), ch. 9 (pour [4.1](../04-Vision/4.1-Conv-NumPy-Torch-Allclose.ipynb)), ch. 20 (pour [3.6](3.6-Modeles-Generatifs.ipynb), [3.6b](3.6b-Modeles-Generatifs-PyTorch.ipynb), [3.6c](3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb), [3.6d](3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb), [3.6e](3.6e-Modeles-Generatifs-Conditionnels-from-scratch.ipynb)). Le livre est **PDF archivé** dans le gisement partagé — voir [docs/reference/bibliography-hygiene.md](../../../../docs/reference/bibliography-hygiene.md). -**Survey unificateur** (à lire en complément pour la série 3.6) : Luo, C. (2022), *Understanding Diffusion Models: A Unified Perspective* — démontre dans « Three Equivalent Interpretations » (p. 15-17, éq. 115-118) que prédire $\epsilon$, prédire $x_0$ et régresser le score sont trois réparamétrisations du même objectif ; c'est l'arc de fond des carnets 3.6, 3.6c, 3.6d, 3.6e. Ancré par le [3.6d](3.6d-Modeles-Generatifs-Score-SDE-from-scratch.html) (passerelle vers le score) et le [3.10-Modeles-Generatifs-Diffusion-SOTA](3.10-Modeles-Generatifs-Diffusion-SOTA.html) (librerie `diffusers`). +**Survey unificateur** (à lire en complément pour la série 3.6) : Luo, C. (2022), *Understanding Diffusion Models: A Unified Perspective* — démontre dans « Three Equivalent Interpretations » (p. 15-17, éq. 115-118) que prédire $\epsilon$, prédire $x_0$ et régresser le score sont trois réparamétrisations du même objectif ; c'est l'arc de fond des carnets 3.6, 3.6c, 3.6d, 3.6e. Ancré par le [3.6d](3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb) (passerelle vers le score) et le [3.10-Modeles-Generatifs-Diffusion-SOTA](3.10-Modeles-Generatifs-Diffusion-SOTA.ipynb) (librerie `diffusers`). ## Prérequis - [02-ML-Cours](../02-ML-Cours/README.md) en entier — en particulier [2.2 (descente de - gradient)](../02-ML-Cours/2.2-Descente-de-gradient.html), [2.8 (théorie PAC, la borne que - ce notebook confronte)](../02-ML-Cours/2.8-Theorie-PAC.html) et - [2.9 (le grokking boîte noire que le 3.5 rouvre à la main)](../02-ML-Cours/2.9-Grokking-Generalisation.html) -- NumPy niveau [1.2](../01-PythonForDataScience/notebooks/1.2-Manipulation_de_Donnees_avec_NumPy.html) + gradient)](../02-ML-Cours/2.2-Descente-de-gradient.ipynb), [2.8 (théorie PAC, la borne que + ce notebook confronte)](../02-ML-Cours/2.8-Theorie-PAC.ipynb) et + [2.9 (le grokking boîte noire que le 3.5 rouvre à la main)](../02-ML-Cours/2.9-Grokking-Generalisation.ipynb) +- NumPy niveau [1.2](../01-PythonForDataScience/notebooks/1.2-Manipulation_de_Donnees_avec_NumPy.ipynb) (produits matriciels, broadcast) ## Environnement @@ -123,4 +123,4 @@ pip install torch torchvision pip install diffusers ``` -Tous les notebooks tournent sur CPU — la plupart en moins de dix minutes. Exceptions : la famille compression ([3.9a](3.9a-Compression-Quantization-INT8.html), [3.9b](3.9b-Compression-Pruning-from-scratch.html), [3.9e](3.9e-Compression-Quantization-SOTA.html), [3.9f](3.9f-Compression-Pruning-SOTA.html), [3.9g](3.9g-Compression-Comparatif-A-vs-B.html)) entraîne ResNet-20 sur CIFAR-10 — la recette complète (40 époques, ~8 min sur RTX 3090 ; ~30 min pour 3.9b, bras de réentraînement compris) exige un GPU ; sur CPU ces notebooks tournent une recette réduite de 6 époques (3 pour les bras de 3.9b ; ~9-15 min), le témoin GPU de 3.9a (0,9019) servant de référence croisée. [3.9d](3.9d-Compression-Distillation-from-scratch.html) exige aussi un GPU pour la distillation complète (maître + 9 entraînements d'élève + balayage T, ~2 h sur RTX 3080 Ti Laptop) ; sur CPU, recette réduite (6 époques, 1 graine). Et [3.6c](3.6c-Modeles-Generatifs-Diffusion-from-scratch.html) demande ~19 min CPU pour ses 16 entraînements. +Tous les notebooks tournent sur CPU — la plupart en moins de dix minutes. Exceptions : la famille compression ([3.9a](3.9a-Compression-Quantization-INT8.ipynb), [3.9b](3.9b-Compression-Pruning-from-scratch.ipynb), [3.9e](3.9e-Compression-Quantization-SOTA.ipynb), [3.9f](3.9f-Compression-Pruning-SOTA.ipynb), [3.9g](3.9g-Compression-Comparatif-A-vs-B.ipynb)) entraîne ResNet-20 sur CIFAR-10 — la recette complète (40 époques, ~8 min sur RTX 3090 ; ~30 min pour 3.9b, bras de réentraînement compris) exige un GPU ; sur CPU ces notebooks tournent une recette réduite de 6 époques (3 pour les bras de 3.9b ; ~9-15 min), le témoin GPU de 3.9a (0,9019) servant de référence croisée. [3.9d](3.9d-Compression-Distillation-from-scratch.ipynb) exige aussi un GPU pour la distillation complète (maître + 9 entraînements d'élève + balayage T, ~2 h sur RTX 3080 Ti Laptop) ; sur CPU, recette réduite (6 époques, 1 graine). Et [3.6c](3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb) demande ~19 min CPU pour ses 16 entraînements. diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04-Vision/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04-Vision/README.md index db2bd5cad6..5f404bf58f 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04-Vision/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04-Vision/README.md @@ -14,20 +14,20 @@ Cette série suit la **même discipline que 03** : *from scratch PUIS framework, | Notebook | Sujet | Concept-phare | Validation | |----------|-------|---------------|------------| -| [4.1 — Le neurone convolutif from scratch](4.1-Conv-NumPy-Torch-Allclose.html) | Conv2d NumPy pur (single + multi-canal), gradient vérifié par différence finie, parité epsilon machine avec `torch.nn.Conv2d`, pooling et invariance par translation | **La convolution n'est pas magique** : un produit scalaire local, partagé spatialement, parité NumPy/torch à epsilon machine | gradient analytique vs numérique : écart max 1e-10 ; multi-canal (3 in, 4 out) float64 : 5,33e-15 ; float32 : 1,91e-06 (précision BLAS CPU) ; invariance par translation mesurée pixel-à-pixel sur image réelle | -| [4.2 — ConvNet profonde : pourquoi les résiduelles](4.2-ConvNet-Profonde-Residuelles.html) | 20 conv2d empilées nues (effondrement du gradient), skip naïf (gradient réparé mais passe avant qui dérive), bloc pré-norme (les deux réparés), même protocole transposé à 20 blocs d'attention, puis accuracy CIFAR-10 sur 3 graines | **Le skip-connection n'est pas un détail architectural** : c'est le mécanisme qui rend les réseaux profonds entraînables. **C'est le même bloc que l'attention pré-norme dans [3.4](../03-DeepLearning/3.4-Attention-Transformer-From-Scratch.html)** | rapport de gradients `g_0/g_19` : `plain` 2,16e-08 contre `prenorm` 1,01 ; effondrement exponentiel en la profondeur (D = 4 → 28 : 1,47e-01 → 2,02e-12) ; `res_naif` répare le gradient mais `\\|h\\|` dérive d'un facteur 88 et la perte initiale monte à 17,4 au lieu de `ln 5` ; attention nue : rapport **plat** (0,92) alors que `\\|h\\|` est divisé par 2,1e+07 ; CIFAR-10 (5 classes, 3 graines) : `prenorm` 62,0 % ± 2,8 contre `plain` 34,0 % ± 10,0, soit +28,0 points pour un bruit de ±10,4 (rapport 2,7) | -| [4.2b — Lean : le gradient qui meurt, le gradient qui survit](4.2b-Lean-GradientFlow-Vanishing.html) | Companion kernel `lean4-wsl` du lake `learning_theory_lean` : la paire plafond/plancher `c ^ n` (pile plain) vs `(1-c) ^ n` (pile résiduelle) `#check`ée depuis le lake, anti-triangulaire au pire cas `t = ±2/5`, ancres numériques `norm_num`, balayage en profondeur rejoué en `Float`, 3 exercices | **La mesure du 4.2 devient un théorème** : `abs_deriv_plainStack_le` majore, `abs_deriv_residualStack_ge` minore — le raccourci identité garantit un plancher géométrique là où la pile nue a un plafond qui s'effondre | table `boundTable 0.4 [5,10,15,20]` : `c^n` 0,010240 → 0,000000 contre `(1-c)^n` 0,077760 → 0,000037 ; à n = 24 le plancher résiduel tient encore à 5e-06 ; exécution kernel lean4-wsl, 0 erreur (See #13106) | -| [4.4 — Détection d'objets from scratch : la grille d'anchors](4.4-Detection-Anchor-From-Scratch.html) | Terrain synthétique contrôlé (1-3 objets, largeurs 14-44 px, ratios 0,35-2,9, bruit gaussien + blobs de fond), grille d'anchors 5 184 (3 tailles × 3 ratios, stride 4), IoU vectorisée + garde-fous, assignation 0,5/0,35 + zone d'ombre + meilleur anchor par GT forcé, échantillonnage 1:3, encode/decode (dx, dy, dw, dh), loss BCE + 2×SmoothL1, NMS gloutonne, mAP VOC07/VOC10 calculé à la main, ablation grille carrée, 3 exercices | **Le réseau ne devine pas des boîtes, il corrige des hypothèses** : la détection anchor-based réduit la localisation à une régression de petits décalages contre des priors géométriques — et l'ablation mesure que la diversité des ratios y est absorbée par l'assignation forcée et la plage log ±3 | aller-retour encode/decode à 7,63e-06 px près ; 1,2 % des anchors ≥ 0,5 (le déséquilibre que le 1:3 compense) ; AnchorNet 74 717 paramètres ; 12 époques en 79 s GPU, loss 13,1 → 1,12 ; mAP@0.5 (400 images / 817 GT) : VOC07 0,853 / VOC10 0,914 ; ablation : grille carrée 0,864/0,926 contre complète 0,853/0,914 — écart de l'ordre du point (See #16057) | -| [4.4b — Détection anchor-free : le renversement CenterNet](4.4b-Detection-AnchorFree-From-Scratch.html) | CenterNet-like à la main sur le terrain du 4.4 : cible gaussienne (rayon canonique CornerNet, 3 cas de recouvrement, garde-fou causal IoU ≥ 0,7 sur grille exhaustive 30×30), offset sous-cellulaire, régression de taille, focal loss modifiée (facteurs (1−p)², p², (1−y)⁴) avec garde-fous analytiques, décodage par max-pool 3×3 + top-K, NMS, mAP VOC07/VOC10 au même harnais que 4.4, ablation de l'offset, mesure des collisions de centres, 3 exercices | **Prédire un point, pas une boîte** : l'anchor-free supprime la grille et ses cinq hyperparamètres — la contrepartie mesurée est la quantification (l'offset vaut 6,3 points de mAP07 et 10,0 de mAP10) et une capacité mono-échelle qui rend 18 points de mAP07 aux anchors sur ce terrain de tailles étalées | 83 621 paramètres contre 74 717 au 4.4 (léger avantage de capacité côté anchor-free : l'écart mesure la méthode) ; 12 époques en 9 s GPU, cuDNN déterministe (chiffres reproductibles d'une exécution à l'autre) ; focal loss vérifiée au garde-fou (faux positif confiant sur un voisin à y = 0,6 puni à 2,56 % du fond pur, théorie (1−0,6)⁴) ; mAP@0.5 (mêmes 400 images / 817 GT) : VOC07 0,673 / VOC10 0,707 contre 0,853 / 0,914 aux anchors ; ablation sans offset : 0,610 / 0,606 ; collisions de centres : 0 sur 817 GT, contrôle positif forcé détecté (See #16057) | -| [4.4c — Détection d'objets from scratch : la Focal Loss](4.4c-Detection-FocalLoss-From-Scratch.html) | Dérivation mathématique de $FL(p_t) = -\alpha_t (1 - p_t)^\gamma \log p_t$ depuis la BCE pondérée, implémentation PyTorch vectorisée sans lib, preuve numérique sur le régime 1000:1 (950 easy negatives + 50 hard negatives + 1 positif) que la contribution des easy negatives passe de 29 % du total BCE à 0,0 % en FL (γ=2), comparaison d'entraînement BCE vs focal sur classifieur binaire pathologique (80 positifs vs 8000 négatifs), 3 exercices (gradient analytique vs autograd, focal multi-classe, mini-détecteur avec focal) | **Le déséquilibre pos:neg n'est pas qu'un problème de ratio — c'est un problème de loss** : la BCE pondère tous les exemples pareillement, et les easy negatives continuent d'accumuler leur contribution. Le modulateur $(1-p_t)^\gamma$ écrase les easy examples et préserve les hard — c'est la troisième voie après le sous-échantillonnage (4.4) et la heatmap gaussienne (4.4b anchor-free). | sur batch pathologique 1000:1, BCE = 64,8 (29 % easy neg / 70 % hard neg / 0,2 % pos) vs FL(γ=2) = 8,2 (0,0 % easy neg / 99,9 % hard neg / 0,0 % pos) — easy neg **entièrement éliminés** ; entraînement 30 époques sur MLP 2→32→1 (2 entraînements, workload stable : batch 80 positifs / 8 000 négatifs, MLP 2→32→1, BCE vs FL(γ=2, α=0,5), torch 2.14.0+cu126, lr 1e-2, Adam, mesure cellule `focal11` post-c.1165 incluant `grad_class_metric` + `loss_share_per_class` — mesure exacte voir cellule `focal11` du notebook) : BCE → rappel sur positifs **= 0,00** (classifieur prédit tout comme négatif), FL(γ=2, α=0,5) → rappel **= 0,84** — la loss seule, sans aucun sous-échantillonnage, suffit à détecter la classe rare (See #16057) | -| [4.5 — Détection SOTA : fine-tuner torchvision](4.5-Detection-SOTA-Torchvision.html) | Le terrain exact du 4.4 (générateur et graines repris verbatim : mêmes images, mêmes 817 GT de validation), trois familles `torchvision.models.detection` fine-tunées (Faster R-CNN two-stage, RetinaNet one-stage anchors, FCOS anchor-free) via le pattern d'usine uniforme (`num_classes=2, weights=None, weights_backbone=ImageNet`, seuils 0,5/0,45 posés à la construction, `min_size=320` commun), gris → RGB, cibles xyxy/labels, `ap_voc` et matching glouton repris verbatim, comparatif final contre AnchorNet (nombres committés), 3 exercices | **Le pré-entraînement transfère hors domaine** : sur des images grises synthétiques jamais vues d'ImageNet, la moitié du budget du from scratch (1 000 img × 6 ép. contre 2 000 × 12) achète un mAP essentiellement complet — le vrai livrable est le pattern d'usine, vocabulaire de tout pipeline réel | Faster R-CNN 18,9 M · RetinaNet 32,2 M · FCOS 32,1 M paramètres (contre 75 k) ; mAP@0.5 sur les mêmes 400 images : 0,909/0,997 · 0,997/1,000 · 0,909/0,998 contre AnchorNet 0,853/0,914 ; latence 17,7-36,3 ms/img GPU ; fine-tuning 73 s / 109 s / 107 s (See #16057) | -| [4.5b — Détection SOTA : YOLO sous ultralytics](4.5b-Detection-SOTA-Ultralytics.html) | Terrain et protocole du 4.4 inchangés, conversion au format YOLO imposé par le pipeline (images uint8 + labels normalisés + `data.yaml`, répertoire temporaire, décomptes imprimés sans chemin machine), YOLO11n et YOLO11s fine-tunés au budget exact du 4.5 (1 000 × 6, `imgsz=96`, `workers=0`), évaluation `ap_voc` maison à seuils 0,5/0,45 (jamais le mAP auto-rapporté seul), **tableau final bloc A vs B** (AnchorNet, 3 torchvision, 2 YOLO : mAP, latence, paramètres, GFLOPs à 96, lignes de code), 3 exercices | **Le wrapper est un choix d'ingénieur, pas un raccourci** : le wrapper est plus court que le from scratch pour le même terrain (cf. lignes de code du tableau bloc A vs B) ; le nano signe le meilleur rapport latence/précision du comparatif — en échange : format de données imposé, hyperparamètres enfouis, mAP auto-rapporté à protocole interne (l'exercice 3 le confronte au nôtre) | YOLO11n 2,59 M · YOLO11s 9,43 M paramètres ; mAP@0.5 mêmes 400 images : 0,909/0,989 · 0,909/0,993 ; latence 10,3 / 10,8 ms/img GPU (les plus rapides du comparatif) ; GFLOPs à `imgsz=96` : 0,1 / 0,5 ; fine-tuning 57 s / 54 s (See #16057) | -| [4.5c — Bench YOLOv5 sur ultralytics](4.5c-YOLOv5-Bench-Ultralytics.html) | Mêmes terrain et protocole que le 4.5b, générateur et graines identiques (2 000 train / 400 val / 817 GT) — chunk 2/3 de l'EPF #16057 ; `yolov5nu.pt` fine-tuné au budget canonique 1 000 × 6 `imgsz=96` (la version « u » est la ré-implémentation Ultralytics unifiée de l'archi YOLOv5, pas l'archi 2020 d'origine) ; `ap_voc` maison à seuils 0,5/0,45, latence CPU mesurée (machine de référence CPU-only, voir §5 du notebook), tableau comparatif face à `yolo11n` et `yolo11s` | **Le retrofit d'une vieille architecture sur le pipeline moderne est un test d'écart de génération** : même budget, même protocole — `yolov5nu` sort dans le même ordre de VOC07 que les yolo11 mais perd dans le haut du rappel (VOC10 0,975 vs 0,989/0,993), au profit de la mêmefamille marketing. Le 4.5 livre le pattern d'usine torchvision, le 4.5b livre deux membres contemporains YOLO, ce notebook en ajoute un troisième — `yolov8s` manque encore pour la fratrie complète (chunk 3/3 sur issue #16346) | `yolov5nu` 2,51 M paramètres (vs 2,59 / 9,43 M pour yolo11n/s) ; GFLOPs 0,2 ; mAP@0.5 VOC07 0,909 / VOC10 0,975 ; latence 7,4 ms/img CPU ; fine-tuning 81 s sur machine CPU de référence `myia-po-2026` (torch 2.13.0+cpu) — latences non comparables aux 10,3 / 10,8 ms/img GPU du 4.5b (matériel différent) ; voir §5 du notebook (See #16346) | -| [4.5d — Détection SOTA : un second wrapper, LibreYOLO, et la leçon comparative](4.5d-Detection-SOTA-LibreYOLO.html) | Terrain et protocole du 4.4 inchangés (générateur verbatim, mêmes graines, mêmes 817 GT), convertisseur YOLO du 4.5b réutilisé (split canonique de 1000 images matérialisé sur disque — pas d'option `fraction` dans ce paquet), deux modèles au budget 1000 × 6 `imgsz=96` : **YOLOv9-tiny** (parité directe avec les lignes YOLO du 4.5b) et **YOLOv9-tiny End-to-End** (sans NMS, appariement un-pour-un — l'idée centrale de DETR au gabarit identique : un seul facteur varie), `ap_voc` maison aux seuils 0,5/0,45, GFLOPs mesurés par `FlopCounterMode` (builtin PyTorch), **cellule licence** lisant licence + SHA de chaque checkpoint à la source (API Hugging Face) avant usage avec refus assertif des non-permissifs, tableau final étendu (lignes committées 4.4/4.5/4.5b + deux nouvelles, colonnes licence code et checkpoint), 3 exercices | **Le portage d'un wrapper à l'autre est quasi gratuit** (même format YOLO, même API à trois lignes) — c'est le format qui est le standard, pas l'enseigne ; la fenêtre « détection sans NMS » s'ouvre à variables égales via YOLOv9E2E, les DETR-family modernes restant derrière un plancher de résolution mesuré (topk sur carte 3×3 : crash à 96 comme à 128 px, DETR classique livré inférence-seule) ; **la licence est une colonne du tableau** : AGPL côté ultralytics, MIT + checkpoints permissifs vérifiés à la source côté LibreYOLO | YOLOv9t 2,76 M params · 0,17 GFLOPs@96 · mAP@0.5 (mêmes 400 images / 817 GT) VOC07 0,909 / VOC10 0,986 · latence 86,9 ms/img ; YOLOv9t-e2e 2,60 M · 0,17 GFLOPs@96 · VOC07 0,817 / VOC10 0,897 · 92,2 ms/img ; fine-tuning 156 s / 119 s (See #18403, EPIC #16057) | -| [4.6 — Détection SOTA : YOLO sous ultralytics, scènes difficiles](4.6-Detection-Ultralytics-Difficult-Scenes.html) | **Générateur hostile** : 30 % d'images avec occlusion par grand rectangle sombre + multi-échelle (40 % petits 8-18 px, 60 % gros 30-60 px), 600 imgs train × 4 époques fine-tune, 3 modèles pré-entraînés comparés : **YOLOv5nu** (anchor-based, 2,5 M params), **YOLOv8s** (anchor-free + C2f, 11,1 M params), **YOLO11m** (C3k2, 20 M params), frise chronologique YOLO 2016-2024 dans la section "Récit YOLO", 3 exercices (taux d'occlusion, dominance petits, combiné) | **Le protocole de mesure peut masquer la dégradation** : à mAP@0.1, tous les modèles ≥ 0.94 ; le protocole COCO (mAP@0.5:0.95) révélé par `model.val()` capture les vraies différences (YOLOv8s 0,84 vs YOLOv5nu 0,73). Leçon de méthodologie d'évaluation : un seuil IoU trop tolérant (= 0,1 style VOC originel) cache les stresseurs. | YOLOv5nu 2,51 M · YOLOv8s 11,14 M · YOLO11m 20,05 M paramètres ; mAP@0.1 sur 200 imgs val difficiles : 0,946 / 0,987 / 0,949 ; recall : 0,957 / 0,993 / 0,968 ; latence 11,46 / 13,40 / 23,29 ms/img GPU ; fine-tuning 52 s / 30 s / 41 s — budget total mesuré : 3 min 14 s (GPU CUDA — mesure détaillée dans la ligne « mesure sur 4.6 » ci-dessous) (See #16337) | -| [4.6b — Détection SOTA : le renversement — le camouflage adversarial contre YOLO](4.6b-Detection-Adversarial-Camouflage.html) | **Boucle adversariale de Thys et al. 2019 from scratch** contre `yolov5nu` gelé : patch 3×96×96 paramétré sigmoïde (27 648 pixels, le seul objet optimisé), collage différentiable par `grid_sample` à grille affine inverse, EOT (échelle 0,50–0,90 × largeur boîte, rotation ±15°, luminosité, bruit, jitter), perte = somme des scores personne des **ancres dans la boîte du porteur** — avec le diagnostic mesuré qui la fonde (l'ancre maximale de l'image est souvent hors du piéton, 0,83 mesuré sur un arbre-plan : une perte max-global ne descend pas), Adam lr 0,15, 2000 iters batch 8 sur 100 images Penn-Fudan (piétons réels, cible = plus grand piéton, témoins = les autres) ; mesure sur 59 images jamais vues, transfert `yolo11n`, balayage de seuil 0,10–0,50, 3 exercices (taille de patch, EOT réduit vs complet, défense par fine-tuning adversarial) ; encart stance Weckert (Digital Camouflage) / Harvey (CV Dazzle) ↔ privacy computationnelle SC-15/16/17 | **Le porteur du patch échappe au détecteur pendant que les témoins restent détectés** — le renversement complet de la lignée : on ne comprend vraiment un détecteur qu'en l'attaquant ; l'attaque est **spécifique** (transfert quasi nul chez un détecteur jamais attaqué) ; le seuil de confiance déplace le problème (il rejette le porteur dans la même plage de confiance que les détections légitimes des scènes difficiles) ; écart digital/physique nommé sans le simuler | Recall cible 1,000 → **0,559** (le porteur devient invisible sur 44 % des images) · témoins 0,952 → 0,917 · confiance max in-box 0,783 → 0,343 · transfert `yolo11n` 0,983 → 0,949 (chute 0,034) · boucle adverse 182 s GPU · dataset via chaîne de repli vérifiée byte-identique (URL canonique UPenn cassée le 05/10/2026, miroir Hugging Face sha256 9095a961…) (See #18990, EPIC #16057) | -| [4.3 — Transfer learning : réutiliser un ResNet18 pré-entraîné](4.3-TransferLearning-ResNet.html) | Charger ResNet18 pré-entraîné ImageNet, greffer une tête (5 130 params), comparer gelé vs fine-tuné sur EuroSAT (Sentinel-2, 10 classes d'occupation du sol, 80+30 imgs/classe), 3 graines appariées + test de permutation des signes | **Le feature extractor pré-entraîné est réutilisable — et le prix de ne pas l'adapter se mesure** : le gelé fait déjà ~89 % ; le fine-tuné ajoute ~6 points, mais seulement avec un taux décroissant (à taux constants, l'optimiseur oscille et finit sous le gelé) | backbone gelé 11,18 M params (99,95 % du réseau) ; gelé 89,3 % ± 1,3 (5 130 params entraînés) vs fine-tuné 95,6 % ± 0,8 (Adam différencié 3e-4/3e-3, décroissance x0,3/époque, batch 64, 5 époques) ; écart apparié +6,2 pts sur 3 graines (rapport signal/bruit 3,2, p = 0,250 au test de permutation — plancher 0,125 à n = 3) | -| [4.6c — Du patch collé au vêtement porté : le dazzle à l'épreuve du style génératif](4.6c-Detection-Dazzle-Garment-StyleTransfer.html) | Le patch dazzle de 4.6b *(ex-4.2k, renuméroté par #19386)* régénéré à l'identique (graine 7, EOT complet, Adam 2000 iters), puis demandé **comme texture même du tissu** à Qwen Image Edit 2509 (img2img ComfyUI distant, Bearer depuis `.env`, 3 essais + backoff, graine 12 345), protocole d'attribution à **quatre conditions** — A vêtement non traité, B patch collé (ancre 4.6b), C vêtement stylé, **D contrôle génératif** (même pipeline sur l'image non patchée, prompt sans motif : le placebo de C) —, cap de coût déclaré n = 8 cibles (`RandomState(7)`), `denoise` 0,60 figé après balayage 0,45/0,60/0,75, 3 exercices (seuil de confiance, corrélation B↔C par image, fidélité L2 vs coût) | **La mesure, pas l'image, est le livrable — et elle renverse la lecture attendue** : le patch collé efface un porteur sur trois, le même motif re-rendu comme tissu n'efface **personne** — et le placebo génératif porte toute la dégradation mesurée ; le style-transfer filtre le signal adversarial au lieu de le transporter, et sans la condition D toute lecture de C aurait été fausse | A (n = 59) 1,000 / 0,952 / 0,783 — ancres 4.6b exactes · B 0,661 / 0,952 / 0,412 (classe de l'ancre 0,559 / 0,343, écart attendu de la ré-optimisation CUDA non bit-déterministe) · sous-ensemble (n = 8) : C recall cible **1,000**, conf in-box 0,648, témoins 0,250 · D 0,625 / 0,167 / 0,589 · **attribution** : C−A recall +0,000 / conf −0,138 · D−A −0,375 / −0,197 · C−D +0,375 / +0,059 · 19 appels génératifs distants (balayage inclus), 0 retry déclenché · exécution complète 22 min 37 s (kernel `py310-gpu`) (See #19387) | +| [4.1 — Le neurone convolutif from scratch](4.1-Conv-NumPy-Torch-Allclose.ipynb) | Conv2d NumPy pur (single + multi-canal), gradient vérifié par différence finie, parité epsilon machine avec `torch.nn.Conv2d`, pooling et invariance par translation | **La convolution n'est pas magique** : un produit scalaire local, partagé spatialement, parité NumPy/torch à epsilon machine | gradient analytique vs numérique : écart max 1e-10 ; multi-canal (3 in, 4 out) float64 : 5,33e-15 ; float32 : 1,91e-06 (précision BLAS CPU) ; invariance par translation mesurée pixel-à-pixel sur image réelle | +| [4.2 — ConvNet profonde : pourquoi les résiduelles](4.2-ConvNet-Profonde-Residuelles.ipynb) | 20 conv2d empilées nues (effondrement du gradient), skip naïf (gradient réparé mais passe avant qui dérive), bloc pré-norme (les deux réparés), même protocole transposé à 20 blocs d'attention, puis accuracy CIFAR-10 sur 3 graines | **Le skip-connection n'est pas un détail architectural** : c'est le mécanisme qui rend les réseaux profonds entraînables. **C'est le même bloc que l'attention pré-norme dans [3.4](../03-DeepLearning/3.4-Attention-Transformer-From-Scratch.ipynb)** | rapport de gradients `g_0/g_19` : `plain` 2,16e-08 contre `prenorm` 1,01 ; effondrement exponentiel en la profondeur (D = 4 → 28 : 1,47e-01 → 2,02e-12) ; `res_naif` répare le gradient mais `\\|h\\|` dérive d'un facteur 88 et la perte initiale monte à 17,4 au lieu de `ln 5` ; attention nue : rapport **plat** (0,92) alors que `\\|h\\|` est divisé par 2,1e+07 ; CIFAR-10 (5 classes, 3 graines) : `prenorm` 62,0 % ± 2,8 contre `plain` 34,0 % ± 10,0, soit +28,0 points pour un bruit de ±10,4 (rapport 2,7) | +| [4.2b — Lean : le gradient qui meurt, le gradient qui survit](4.2b-Lean-GradientFlow-Vanishing.ipynb) | Companion kernel `lean4-wsl` du lake `learning_theory_lean` : la paire plafond/plancher `c ^ n` (pile plain) vs `(1-c) ^ n` (pile résiduelle) `#check`ée depuis le lake, anti-triangulaire au pire cas `t = ±2/5`, ancres numériques `norm_num`, balayage en profondeur rejoué en `Float`, 3 exercices | **La mesure du 4.2 devient un théorème** : `abs_deriv_plainStack_le` majore, `abs_deriv_residualStack_ge` minore — le raccourci identité garantit un plancher géométrique là où la pile nue a un plafond qui s'effondre | table `boundTable 0.4 [5,10,15,20]` : `c^n` 0,010240 → 0,000000 contre `(1-c)^n` 0,077760 → 0,000037 ; à n = 24 le plancher résiduel tient encore à 5e-06 ; exécution kernel lean4-wsl, 0 erreur (See #13106) | +| [4.4 — Détection d'objets from scratch : la grille d'anchors](4.4-Detection-Anchor-From-Scratch.ipynb) | Terrain synthétique contrôlé (1-3 objets, largeurs 14-44 px, ratios 0,35-2,9, bruit gaussien + blobs de fond), grille d'anchors 5 184 (3 tailles × 3 ratios, stride 4), IoU vectorisée + garde-fous, assignation 0,5/0,35 + zone d'ombre + meilleur anchor par GT forcé, échantillonnage 1:3, encode/decode (dx, dy, dw, dh), loss BCE + 2×SmoothL1, NMS gloutonne, mAP VOC07/VOC10 calculé à la main, ablation grille carrée, 3 exercices | **Le réseau ne devine pas des boîtes, il corrige des hypothèses** : la détection anchor-based réduit la localisation à une régression de petits décalages contre des priors géométriques — et l'ablation mesure que la diversité des ratios y est absorbée par l'assignation forcée et la plage log ±3 | aller-retour encode/decode à 7,63e-06 px près ; 1,2 % des anchors ≥ 0,5 (le déséquilibre que le 1:3 compense) ; AnchorNet 74 717 paramètres ; 12 époques en 79 s GPU, loss 13,1 → 1,12 ; mAP@0.5 (400 images / 817 GT) : VOC07 0,853 / VOC10 0,914 ; ablation : grille carrée 0,864/0,926 contre complète 0,853/0,914 — écart de l'ordre du point (See #16057) | +| [4.4b — Détection anchor-free : le renversement CenterNet](4.4b-Detection-AnchorFree-From-Scratch.ipynb) | CenterNet-like à la main sur le terrain du 4.4 : cible gaussienne (rayon canonique CornerNet, 3 cas de recouvrement, garde-fou causal IoU ≥ 0,7 sur grille exhaustive 30×30), offset sous-cellulaire, régression de taille, focal loss modifiée (facteurs (1−p)², p², (1−y)⁴) avec garde-fous analytiques, décodage par max-pool 3×3 + top-K, NMS, mAP VOC07/VOC10 au même harnais que 4.4, ablation de l'offset, mesure des collisions de centres, 3 exercices | **Prédire un point, pas une boîte** : l'anchor-free supprime la grille et ses cinq hyperparamètres — la contrepartie mesurée est la quantification (l'offset vaut 6,3 points de mAP07 et 10,0 de mAP10) et une capacité mono-échelle qui rend 18 points de mAP07 aux anchors sur ce terrain de tailles étalées | 83 621 paramètres contre 74 717 au 4.4 (léger avantage de capacité côté anchor-free : l'écart mesure la méthode) ; 12 époques en 9 s GPU, cuDNN déterministe (chiffres reproductibles d'une exécution à l'autre) ; focal loss vérifiée au garde-fou (faux positif confiant sur un voisin à y = 0,6 puni à 2,56 % du fond pur, théorie (1−0,6)⁴) ; mAP@0.5 (mêmes 400 images / 817 GT) : VOC07 0,673 / VOC10 0,707 contre 0,853 / 0,914 aux anchors ; ablation sans offset : 0,610 / 0,606 ; collisions de centres : 0 sur 817 GT, contrôle positif forcé détecté (See #16057) | +| [4.4c — Détection d'objets from scratch : la Focal Loss](4.4c-Detection-FocalLoss-From-Scratch.ipynb) | Dérivation mathématique de $FL(p_t) = -\alpha_t (1 - p_t)^\gamma \log p_t$ depuis la BCE pondérée, implémentation PyTorch vectorisée sans lib, preuve numérique sur le régime 1000:1 (950 easy negatives + 50 hard negatives + 1 positif) que la contribution des easy negatives passe de 29 % du total BCE à 0,0 % en FL (γ=2), comparaison d'entraînement BCE vs focal sur classifieur binaire pathologique (80 positifs vs 8000 négatifs), 3 exercices (gradient analytique vs autograd, focal multi-classe, mini-détecteur avec focal) | **Le déséquilibre pos:neg n'est pas qu'un problème de ratio — c'est un problème de loss** : la BCE pondère tous les exemples pareillement, et les easy negatives continuent d'accumuler leur contribution. Le modulateur $(1-p_t)^\gamma$ écrase les easy examples et préserve les hard — c'est la troisième voie après le sous-échantillonnage (4.4) et la heatmap gaussienne (4.4b anchor-free). | sur batch pathologique 1000:1, BCE = 64,8 (29 % easy neg / 70 % hard neg / 0,2 % pos) vs FL(γ=2) = 8,2 (0,0 % easy neg / 99,9 % hard neg / 0,0 % pos) — easy neg **entièrement éliminés** ; entraînement 30 époques sur MLP 2→32→1 (2 entraînements, workload stable : batch 80 positifs / 8 000 négatifs, MLP 2→32→1, BCE vs FL(γ=2, α=0,5), torch 2.14.0+cu126, lr 1e-2, Adam, mesure cellule `focal11` post-c.1165 incluant `grad_class_metric` + `loss_share_per_class` — mesure exacte voir cellule `focal11` du notebook) : BCE → rappel sur positifs **= 0,00** (classifieur prédit tout comme négatif), FL(γ=2, α=0,5) → rappel **= 0,84** — la loss seule, sans aucun sous-échantillonnage, suffit à détecter la classe rare (See #16057) | +| [4.5 — Détection SOTA : fine-tuner torchvision](4.5-Detection-SOTA-Torchvision.ipynb) | Le terrain exact du 4.4 (générateur et graines repris verbatim : mêmes images, mêmes 817 GT de validation), trois familles `torchvision.models.detection` fine-tunées (Faster R-CNN two-stage, RetinaNet one-stage anchors, FCOS anchor-free) via le pattern d'usine uniforme (`num_classes=2, weights=None, weights_backbone=ImageNet`, seuils 0,5/0,45 posés à la construction, `min_size=320` commun), gris → RGB, cibles xyxy/labels, `ap_voc` et matching glouton repris verbatim, comparatif final contre AnchorNet (nombres committés), 3 exercices | **Le pré-entraînement transfère hors domaine** : sur des images grises synthétiques jamais vues d'ImageNet, la moitié du budget du from scratch (1 000 img × 6 ép. contre 2 000 × 12) achète un mAP essentiellement complet — le vrai livrable est le pattern d'usine, vocabulaire de tout pipeline réel | Faster R-CNN 18,9 M · RetinaNet 32,2 M · FCOS 32,1 M paramètres (contre 75 k) ; mAP@0.5 sur les mêmes 400 images : 0,909/0,997 · 0,997/1,000 · 0,909/0,998 contre AnchorNet 0,853/0,914 ; latence 17,7-36,3 ms/img GPU ; fine-tuning 73 s / 109 s / 107 s (See #16057) | +| [4.5b — Détection SOTA : YOLO sous ultralytics](4.5b-Detection-SOTA-Ultralytics.ipynb) | Terrain et protocole du 4.4 inchangés, conversion au format YOLO imposé par le pipeline (images uint8 + labels normalisés + `data.yaml`, répertoire temporaire, décomptes imprimés sans chemin machine), YOLO11n et YOLO11s fine-tunés au budget exact du 4.5 (1 000 × 6, `imgsz=96`, `workers=0`), évaluation `ap_voc` maison à seuils 0,5/0,45 (jamais le mAP auto-rapporté seul), **tableau final bloc A vs B** (AnchorNet, 3 torchvision, 2 YOLO : mAP, latence, paramètres, GFLOPs à 96, lignes de code), 3 exercices | **Le wrapper est un choix d'ingénieur, pas un raccourci** : le wrapper est plus court que le from scratch pour le même terrain (cf. lignes de code du tableau bloc A vs B) ; le nano signe le meilleur rapport latence/précision du comparatif — en échange : format de données imposé, hyperparamètres enfouis, mAP auto-rapporté à protocole interne (l'exercice 3 le confronte au nôtre) | YOLO11n 2,59 M · YOLO11s 9,43 M paramètres ; mAP@0.5 mêmes 400 images : 0,909/0,989 · 0,909/0,993 ; latence 10,3 / 10,8 ms/img GPU (les plus rapides du comparatif) ; GFLOPs à `imgsz=96` : 0,1 / 0,5 ; fine-tuning 57 s / 54 s (See #16057) | +| [4.5c — Bench YOLOv5 sur ultralytics](4.5c-YOLOv5-Bench-Ultralytics.ipynb) | Mêmes terrain et protocole que le 4.5b, générateur et graines identiques (2 000 train / 400 val / 817 GT) — chunk 2/3 de l'EPF #16057 ; `yolov5nu.pt` fine-tuné au budget canonique 1 000 × 6 `imgsz=96` (la version « u » est la ré-implémentation Ultralytics unifiée de l'archi YOLOv5, pas l'archi 2020 d'origine) ; `ap_voc` maison à seuils 0,5/0,45, latence CPU mesurée (machine de référence CPU-only, voir §5 du notebook), tableau comparatif face à `yolo11n` et `yolo11s` | **Le retrofit d'une vieille architecture sur le pipeline moderne est un test d'écart de génération** : même budget, même protocole — `yolov5nu` sort dans le même ordre de VOC07 que les yolo11 mais perd dans le haut du rappel (VOC10 0,975 vs 0,989/0,993), au profit de la mêmefamille marketing. Le 4.5 livre le pattern d'usine torchvision, le 4.5b livre deux membres contemporains YOLO, ce notebook en ajoute un troisième — `yolov8s` manque encore pour la fratrie complète (chunk 3/3 sur issue #16346) | `yolov5nu` 2,51 M paramètres (vs 2,59 / 9,43 M pour yolo11n/s) ; GFLOPs 0,2 ; mAP@0.5 VOC07 0,909 / VOC10 0,975 ; latence 7,4 ms/img CPU ; fine-tuning 81 s sur machine CPU de référence `myia-po-2026` (torch 2.13.0+cpu) — latences non comparables aux 10,3 / 10,8 ms/img GPU du 4.5b (matériel différent) ; voir §5 du notebook (See #16346) | +| [4.5d — Détection SOTA : un second wrapper, LibreYOLO, et la leçon comparative](4.5d-Detection-SOTA-LibreYOLO.ipynb) | Terrain et protocole du 4.4 inchangés (générateur verbatim, mêmes graines, mêmes 817 GT), convertisseur YOLO du 4.5b réutilisé (split canonique de 1000 images matérialisé sur disque — pas d'option `fraction` dans ce paquet), deux modèles au budget 1000 × 6 `imgsz=96` : **YOLOv9-tiny** (parité directe avec les lignes YOLO du 4.5b) et **YOLOv9-tiny End-to-End** (sans NMS, appariement un-pour-un — l'idée centrale de DETR au gabarit identique : un seul facteur varie), `ap_voc` maison aux seuils 0,5/0,45, GFLOPs mesurés par `FlopCounterMode` (builtin PyTorch), **cellule licence** lisant licence + SHA de chaque checkpoint à la source (API Hugging Face) avant usage avec refus assertif des non-permissifs, tableau final étendu (lignes committées 4.4/4.5/4.5b + deux nouvelles, colonnes licence code et checkpoint), 3 exercices | **Le portage d'un wrapper à l'autre est quasi gratuit** (même format YOLO, même API à trois lignes) — c'est le format qui est le standard, pas l'enseigne ; la fenêtre « détection sans NMS » s'ouvre à variables égales via YOLOv9E2E, les DETR-family modernes restant derrière un plancher de résolution mesuré (topk sur carte 3×3 : crash à 96 comme à 128 px, DETR classique livré inférence-seule) ; **la licence est une colonne du tableau** : AGPL côté ultralytics, MIT + checkpoints permissifs vérifiés à la source côté LibreYOLO | YOLOv9t 2,76 M params · 0,17 GFLOPs@96 · mAP@0.5 (mêmes 400 images / 817 GT) VOC07 0,909 / VOC10 0,986 · latence 86,9 ms/img ; YOLOv9t-e2e 2,60 M · 0,17 GFLOPs@96 · VOC07 0,817 / VOC10 0,897 · 92,2 ms/img ; fine-tuning 156 s / 119 s (See #18403, EPIC #16057) | +| [4.6 — Détection SOTA : YOLO sous ultralytics, scènes difficiles](4.6-Detection-Ultralytics-Difficult-Scenes.ipynb) | **Générateur hostile** : 30 % d'images avec occlusion par grand rectangle sombre + multi-échelle (40 % petits 8-18 px, 60 % gros 30-60 px), 600 imgs train × 4 époques fine-tune, 3 modèles pré-entraînés comparés : **YOLOv5nu** (anchor-based, 2,5 M params), **YOLOv8s** (anchor-free + C2f, 11,1 M params), **YOLO11m** (C3k2, 20 M params), frise chronologique YOLO 2016-2024 dans la section "Récit YOLO", 3 exercices (taux d'occlusion, dominance petits, combiné) | **Le protocole de mesure peut masquer la dégradation** : à mAP@0.1, tous les modèles ≥ 0.94 ; le protocole COCO (mAP@0.5:0.95) révélé par `model.val()` capture les vraies différences (YOLOv8s 0,84 vs YOLOv5nu 0,73). Leçon de méthodologie d'évaluation : un seuil IoU trop tolérant (= 0,1 style VOC originel) cache les stresseurs. | YOLOv5nu 2,51 M · YOLOv8s 11,14 M · YOLO11m 20,05 M paramètres ; mAP@0.1 sur 200 imgs val difficiles : 0,946 / 0,987 / 0,949 ; recall : 0,957 / 0,993 / 0,968 ; latence 11,46 / 13,40 / 23,29 ms/img GPU ; fine-tuning 52 s / 30 s / 41 s — budget total mesuré : 3 min 14 s (GPU CUDA — mesure détaillée dans la ligne « mesure sur 4.6 » ci-dessous) (See #16337) | +| [4.6b — Détection SOTA : le renversement — le camouflage adversarial contre YOLO](4.6b-Detection-Adversarial-Camouflage.ipynb) | **Boucle adversariale de Thys et al. 2019 from scratch** contre `yolov5nu` gelé : patch 3×96×96 paramétré sigmoïde (27 648 pixels, le seul objet optimisé), collage différentiable par `grid_sample` à grille affine inverse, EOT (échelle 0,50–0,90 × largeur boîte, rotation ±15°, luminosité, bruit, jitter), perte = somme des scores personne des **ancres dans la boîte du porteur** — avec le diagnostic mesuré qui la fonde (l'ancre maximale de l'image est souvent hors du piéton, 0,83 mesuré sur un arbre-plan : une perte max-global ne descend pas), Adam lr 0,15, 2000 iters batch 8 sur 100 images Penn-Fudan (piétons réels, cible = plus grand piéton, témoins = les autres) ; mesure sur 59 images jamais vues, transfert `yolo11n`, balayage de seuil 0,10–0,50, 3 exercices (taille de patch, EOT réduit vs complet, défense par fine-tuning adversarial) ; encart stance Weckert (Digital Camouflage) / Harvey (CV Dazzle) ↔ privacy computationnelle SC-15/16/17 | **Le porteur du patch échappe au détecteur pendant que les témoins restent détectés** — le renversement complet de la lignée : on ne comprend vraiment un détecteur qu'en l'attaquant ; l'attaque est **spécifique** (transfert quasi nul chez un détecteur jamais attaqué) ; le seuil de confiance déplace le problème (il rejette le porteur dans la même plage de confiance que les détections légitimes des scènes difficiles) ; écart digital/physique nommé sans le simuler | Recall cible 1,000 → **0,559** (le porteur devient invisible sur 44 % des images) · témoins 0,952 → 0,917 · confiance max in-box 0,783 → 0,343 · transfert `yolo11n` 0,983 → 0,949 (chute 0,034) · boucle adverse 182 s GPU · dataset via chaîne de repli vérifiée byte-identique (URL canonique UPenn cassée le 05/10/2026, miroir Hugging Face sha256 9095a961…) (See #18990, EPIC #16057) | +| [4.3 — Transfer learning : réutiliser un ResNet18 pré-entraîné](4.3-TransferLearning-ResNet.ipynb) | Charger ResNet18 pré-entraîné ImageNet, greffer une tête (5 130 params), comparer gelé vs fine-tuné sur EuroSAT (Sentinel-2, 10 classes d'occupation du sol, 80+30 imgs/classe), 3 graines appariées + test de permutation des signes | **Le feature extractor pré-entraîné est réutilisable — et le prix de ne pas l'adapter se mesure** : le gelé fait déjà ~89 % ; le fine-tuné ajoute ~6 points, mais seulement avec un taux décroissant (à taux constants, l'optimiseur oscille et finit sous le gelé) | backbone gelé 11,18 M params (99,95 % du réseau) ; gelé 89,3 % ± 1,3 (5 130 params entraînés) vs fine-tuné 95,6 % ± 0,8 (Adam différencié 3e-4/3e-3, décroissance x0,3/époque, batch 64, 5 époques) ; écart apparié +6,2 pts sur 3 graines (rapport signal/bruit 3,2, p = 0,250 au test de permutation — plancher 0,125 à n = 3) | +| [4.6c — Du patch collé au vêtement porté : le dazzle à l'épreuve du style génératif](4.6c-Detection-Dazzle-Garment-StyleTransfer.ipynb) | Le patch dazzle de 4.6b *(ex-4.2k, renuméroté par #19386)* régénéré à l'identique (graine 7, EOT complet, Adam 2000 iters), puis demandé **comme texture même du tissu** à Qwen Image Edit 2509 (img2img ComfyUI distant, Bearer depuis `.env`, 3 essais + backoff, graine 12 345), protocole d'attribution à **quatre conditions** — A vêtement non traité, B patch collé (ancre 4.6b), C vêtement stylé, **D contrôle génératif** (même pipeline sur l'image non patchée, prompt sans motif : le placebo de C) —, cap de coût déclaré n = 8 cibles (`RandomState(7)`), `denoise` 0,60 figé après balayage 0,45/0,60/0,75, 3 exercices (seuil de confiance, corrélation B↔C par image, fidélité L2 vs coût) | **La mesure, pas l'image, est le livrable — et elle renverse la lecture attendue** : le patch collé efface un porteur sur trois, le même motif re-rendu comme tissu n'efface **personne** — et le placebo génératif porte toute la dégradation mesurée ; le style-transfer filtre le signal adversarial au lieu de le transporter, et sans la condition D toute lecture de C aurait été fausse | A (n = 59) 1,000 / 0,952 / 0,783 — ancres 4.6b exactes · B 0,661 / 0,952 / 0,412 (classe de l'ancre 0,559 / 0,343, écart attendu de la ré-optimisation CUDA non bit-déterministe) · sous-ensemble (n = 8) : C recall cible **1,000**, conf in-box 0,648, témoins 0,250 · D 0,625 / 0,167 / 0,589 · **attribution** : C−A recall +0,000 / conf −0,138 · D−A −0,375 / −0,197 · C−D +0,375 / +0,059 · 19 appels génératifs distants (balayage inclus), 0 retry déclenché · exécution complète 22 min 37 s (kernel `py310-gpu`) (See #19387) | ## Frontières 4.5b / 4.5c — verdict de l'audit #16834 (v2) @@ -45,8 +45,8 @@ Cette série suit la **même discipline que 03** : *from scratch PUIS framework, ## Prérequis -- [`03-DeepLearning`](../03-DeepLearning/README.md) en entier — en particulier [3.4 (Attention-Transformer from scratch)](../03-DeepLearning/3.4-Attention-Transformer-From-Scratch.html) qui partage le mécanisme résiduel. -- NumPy niveau [`01-PythonForDataScience/1.2`](../01-PythonForDataScience/notebooks/1.2-Manipulation_de_Donnees_avec_NumPy.html) (broadcast, produits matriciels). +- [`03-DeepLearning`](../03-DeepLearning/README.md) en entier — en particulier [3.4 (Attention-Transformer from scratch)](../03-DeepLearning/3.4-Attention-Transformer-From-Scratch.ipynb) qui partage le mécanisme résiduel. +- NumPy niveau [`01-PythonForDataScience/1.2`](../01-PythonForDataScience/notebooks/1.2-Manipulation_de_Donnees_avec_NumPy.ipynb) (broadcast, produits matriciels). - PyTorch CPU (installé via `pip install torch torchvision`). ## Environnement @@ -69,18 +69,18 @@ Mesure sur 4.6b : exécution complète en 4 min 36 s sur GPU CUDA (dont 182 s de ## Feuille de route L'Epic #12422 *« Série Vision 04 (à décider) — Évolution des architectures CNN »* est livrée par cette série : -- 4.1 — [le neurone convolutif from scratch](4.1-Conv-NumPy-Torch-Allclose.html) (livré) -- 4.2 — [pourquoi la profondeur échoue sans résiduelles](4.2-ConvNet-Profonde-Residuelles.html) (livré) -- 4.2b — [companion Lean : le gradient qui meurt, le gradient qui survit](4.2b-Lean-GradientFlow-Vanishing.html) (livré) -- 4.4 — [détection anchor-based from scratch](4.4-Detection-Anchor-From-Scratch.html) (livré, See #16057) -- 4.4b — [détection anchor-free from scratch](4.4b-Detection-AnchorFree-From-Scratch.html) (livré — bloc A.2 de #16057, See #16145) -- 4.4c — [détection from scratch : la Focal Loss](4.4c-Detection-FocalLoss-From-Scratch.html) (livré, See #16057 — bloc A.3 trilogie anchor / anchor-free / focal) -- 4.3 — [transfer learning ResNet](4.3-TransferLearning-ResNet.html) (livré) +- 4.1 — [le neurone convolutif from scratch](4.1-Conv-NumPy-Torch-Allclose.ipynb) (livré) +- 4.2 — [pourquoi la profondeur échoue sans résiduelles](4.2-ConvNet-Profonde-Residuelles.ipynb) (livré) +- 4.2b — [companion Lean : le gradient qui meurt, le gradient qui survit](4.2b-Lean-GradientFlow-Vanishing.ipynb) (livré) +- 4.4 — [détection anchor-based from scratch](4.4-Detection-Anchor-From-Scratch.ipynb) (livré, See #16057) +- 4.4b — [détection anchor-free from scratch](4.4b-Detection-AnchorFree-From-Scratch.ipynb) (livré — bloc A.2 de #16057, See #16145) +- 4.4c — [détection from scratch : la Focal Loss](4.4c-Detection-FocalLoss-From-Scratch.ipynb) (livré, See #16057 — bloc A.3 trilogie anchor / anchor-free / focal) +- 4.3 — [transfer learning ResNet](4.3-TransferLearning-ResNet.ipynb) (livré) La famille **détection d'objets** poursuit sur l'Epic #16057 (même terrain, même protocole d'évaluation) : -- 4.2b — [Lean : le gradient qui meurt](4.2b-Lean-GradientFlow-Vanishing.html), 4.4 — [la détection from scratch à la grille d'anchors](4.4-Detection-Anchor-From-Scratch.html) (livrés) -- 4.4b — [la détection anchor-free from scratch](4.4b-Detection-AnchorFree-From-Scratch.html) (livré — bloc A.2 de #16057, See #16145) ; 4.4c — [la Focal Loss dédiée](4.4c-Detection-FocalLoss-From-Scratch.html) (livré — bloc A.3, See #16165) -- 4.5 — [la détection SOTA torchvision fine-tunée](4.5-Detection-SOTA-Torchvision.html) (livré — bloc B.1 de #16057) ; 4.5b — [YOLO sous ultralytics + tableau final bloc A vs B](4.5b-Detection-SOTA-Ultralytics.html) (livré — bloc B.2) ; [4.5c — Bench YOLOv5](4.5c-YOLOv5-Bench-Ultralytics.html) (livré, #16346) ; 4.6 — [YOLO sur scènes difficiles (occlusions + multi-échelle)](4.6-Detection-Ultralytics-Difficult-Scenes.html) (bloc B.3 : extension scènes difficiles, leçon méthodologie, See #16337) ; 4.5d — [second wrapper LibreYOLO + fenêtre sans-NMS E2E](4.5d-Detection-SOTA-LibreYOLO.html) (bloc B.4 : parité inter-enseignes, colonne licence, See #18403) ; 4.6b — [le camouflage adversarial, capstone de renversement](4.6b-Detection-Adversarial-Camouflage.html) (See #18990) +- 4.2b — [Lean : le gradient qui meurt](4.2b-Lean-GradientFlow-Vanishing.ipynb), 4.4 — [la détection from scratch à la grille d'anchors](4.4-Detection-Anchor-From-Scratch.ipynb) (livrés) +- 4.4b — [la détection anchor-free from scratch](4.4b-Detection-AnchorFree-From-Scratch.ipynb) (livré — bloc A.2 de #16057, See #16145) ; 4.4c — [la Focal Loss dédiée](4.4c-Detection-FocalLoss-From-Scratch.ipynb) (livré — bloc A.3, See #16165) +- 4.5 — [la détection SOTA torchvision fine-tunée](4.5-Detection-SOTA-Torchvision.ipynb) (livré — bloc B.1 de #16057) ; 4.5b — [YOLO sous ultralytics + tableau final bloc A vs B](4.5b-Detection-SOTA-Ultralytics.ipynb) (livré — bloc B.2) ; [4.5c — Bench YOLOv5](4.5c-YOLOv5-Bench-Ultralytics.ipynb) (livré, #16346) ; 4.6 — [YOLO sur scènes difficiles (occlusions + multi-échelle)](4.6-Detection-Ultralytics-Difficult-Scenes.ipynb) (bloc B.3 : extension scènes difficiles, leçon méthodologie, See #16337) ; 4.5d — [second wrapper LibreYOLO + fenêtre sans-NMS E2E](4.5d-Detection-SOTA-LibreYOLO.ipynb) (bloc B.4 : parité inter-enseignes, colonne licence, See #18403) ; 4.6b — [le camouflage adversarial, capstone de renversement](4.6b-Detection-Adversarial-Camouflage.ipynb) (See #18990) Chaque notebook est atomique (1 sujet vérifiable, < 3000 lignes, ≤ 15 fichiers), avec outputs commités (C.2) et ≥ 3 exercices par notebook (C.1, jamais `raise NotImplementedError`). diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04b-Wavelet-Scattering/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04b-Wavelet-Scattering/README.md index d6672b2458..eb94b8f6bd 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04b-Wavelet-Scattering/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04b-Wavelet-Scattering/README.md @@ -8,12 +8,12 @@ Série sur l'analyse multi-résolution : la transformée en ondelettes réimplé | Notebook | Sujet | Concept-phare | |----------|-------|---------------| -| [WS-00a-Ondelettes-1D-from-scratch](WS-00a-Ondelettes-1D-from-scratch.html) | DWT orthonormale à la main (Haar, D4 par formes closes, db4 par constantes publiées), synthèse écrite comme adjoint exact, validation croisée coefficient par coefficient contre PyWavelets, profil d'énergie par échelle, débruitage par seuillage dur/doux (seuil universel MAD, sans oracle) contre passe-bas Fourier (trois cutoffs, avec oracle) sur le banc canonique Donoho-Johnstone | **Aucune base n'est universellement parcimonieuse** : l'ondelette gagne le chirp (+4,5 dB sans oracle), Fourier gagne le stationnaire (+4,8 dB avec oracle), le mixte est serré | -| [WS-00b-Ondelettes-2D-from-scratch](WS-00b-Ondelettes-2D-from-scratch.html) | Transformée 2D séparable construite comme produit tensoriel du moteur 1D de WS-00a, pyramide de Mallat multi-niveaux, contrôle d'orientation sur motifs à orientation connue (marches verticale/horizontale/diagonale + constante en contrôle négatif), reconstruction parfaite et validation croisée `allclose` bande par bande contre PyWavelets, duel de compression à budget de coefficients apparié contre une DCT 8×8 | **Le pouvoir de parcimonie est conditionnel au budget** : db4 écrase la DCT 8×8 de +16,4 dB à 0,2 % de coefficients retenus, mais l'écart tombe à ~0,2 dB (indiscernable) dès 5 % — l'avantage de la base multi-échelle s'évapore quand on peut se permettre plus de coefficients | -| [WS-00c-Scattering-from-scratch](WS-00c-Scattering-from-scratch.html) | Transformée de scattering 2D from scratch : banc de morlets analytiques en forme close spectrale (pic unique, correction d'admissibilité, norme L²), cascade S0/S1/S2 en une passe pleine résolution, invariance L² par translation mesurée contre pixels et descripteur sans module, sélectivité d'orientation sur les marches de WS-00b, triple validation croisée contre kymatio (traduction du pipeline à filtres injectés = `allclose` rtol=1e-4 ; écart de l'écriture pleine résolution concentré sur S2 ; régime d'invariance commun à deux calibrages indépendants), classification Fashion-MNIST bornée avec test translaté ±2 px | **Le module rend la moyenne invariante** : l'écart par translation plafonne (0,73 à 8 px) là où pixels (1,14) et coefficients sans module (1,07) croissent sans borne — et à 600 images d'entraînement, le scattering complet tient 0,765 de précision sur test translaté quand les pixels s'effondrent de 0,790 à 0,425 | -| [WS-01-Denoising-SOTA](WS-01-Denoising-SOTA.html) | Bloc B.5 : duel débruitage d'images (4 images canoniques × 3 sigmas × 3 graines) entre la baseline from scratch (moteur WS-00b + seuil universel MAD de WS-00a, dur/doux) et les estimateurs SOTA — VisuShrink et BayesShrink (`skimage.restoration.denoise_wavelet`), SureShrink implémenté à la main (minimisation du risque SURE en O(n log n), validée contre force brute) sur les coefficients `pywt` | **À transformée identique (db4, parité `allclose`), l'écart de débruitage vient du seuil, pas du moteur** : BayesShrink adaptatif par sous-bande gagne **+2,2 à +3,0 dB** sur le seuil universel global à chaque régime de bruit ; VisuShrink (packaging lib du même universel doux) colle à la baseline from scratch à 0,2 dB près | -| [WS-02-Scattering-SOTA](WS-02-Scattering-SOTA.html) | kymatio (backend PyTorch, corpus batché en un tenseur) contre le moteur from-scratch de WS-00c repris à l'identique — même corpus (Fashion-MNIST 80/classe, 600/200), même classifieur (régression logistique L2), même test translaté ±2 px ; diagnostic de conventions par table de correspondance (permutation d'orientations mesurée par corrélation, canaux S1 appariés à 0,64-0,81) ; mesure jumelle accuracy/latence/mémoire ; loi de l'échantillon testée à 400/classe ; tableau récapitulatif final A-vs-B de la série (LOC et dépendances calculés à l'exécution) | **SOTA rime avec ingénierie, pas avec justesse** : kymatio transforme ~46× plus vite (rapport de latence mesuré dans le notebook) mais, ses filtres isotropes par défaut étant moins sélectifs que les morlets anisotropes from-scratch, l'accuracy bornée leur donne raison — comprendre en Bloc A, produire en Bloc B | -| [WS-03-Synthese-Scattering-vs-ResNet](WS-03-Synthese-Scattering-vs-ResNet.html) | Synthèse finale : représentation construite (scattering kymatio J=2, L=4, 1225-d) contre représentation apprise (ResNet18 pré-entraîné ImageNet, avgpool 512-d) sur le même Fashion-MNIST (1 500 train / 750 test, vrai split test torchvision), même sonde (régression logistique standardisée), même test translaté ±2 px, écart relatif de représentation mesuré sous décalage, tableau récap à quatre axes (discrimination, stabilité, coût, dimension) | **Construit et appris ne dominent pas les mêmes axes** : le scattering gagne le test propre (0,837 contre 0,811) et coûte ~28× moins cher à l'extraction (rapport relatif, tableau du notebook) sans avoir vu une seule image ; le ResNet gagne la robustesse au décalage (chute 0,060 contre 0,255, écart relatif 0,331 contre 0,425) — la frontière du *pourquoi du from scratch / quand du SOTA* se lit axe par axe, pas en un vainqueur | +| [WS-00a-Ondelettes-1D-from-scratch](WS-00a-Ondelettes-1D-from-scratch.ipynb) | DWT orthonormale à la main (Haar, D4 par formes closes, db4 par constantes publiées), synthèse écrite comme adjoint exact, validation croisée coefficient par coefficient contre PyWavelets, profil d'énergie par échelle, débruitage par seuillage dur/doux (seuil universel MAD, sans oracle) contre passe-bas Fourier (trois cutoffs, avec oracle) sur le banc canonique Donoho-Johnstone | **Aucune base n'est universellement parcimonieuse** : l'ondelette gagne le chirp (+4,5 dB sans oracle), Fourier gagne le stationnaire (+4,8 dB avec oracle), le mixte est serré | +| [WS-00b-Ondelettes-2D-from-scratch](WS-00b-Ondelettes-2D-from-scratch.ipynb) | Transformée 2D séparable construite comme produit tensoriel du moteur 1D de WS-00a, pyramide de Mallat multi-niveaux, contrôle d'orientation sur motifs à orientation connue (marches verticale/horizontale/diagonale + constante en contrôle négatif), reconstruction parfaite et validation croisée `allclose` bande par bande contre PyWavelets, duel de compression à budget de coefficients apparié contre une DCT 8×8 | **Le pouvoir de parcimonie est conditionnel au budget** : db4 écrase la DCT 8×8 de +16,4 dB à 0,2 % de coefficients retenus, mais l'écart tombe à ~0,2 dB (indiscernable) dès 5 % — l'avantage de la base multi-échelle s'évapore quand on peut se permettre plus de coefficients | +| [WS-00c-Scattering-from-scratch](WS-00c-Scattering-from-scratch.ipynb) | Transformée de scattering 2D from scratch : banc de morlets analytiques en forme close spectrale (pic unique, correction d'admissibilité, norme L²), cascade S0/S1/S2 en une passe pleine résolution, invariance L² par translation mesurée contre pixels et descripteur sans module, sélectivité d'orientation sur les marches de WS-00b, triple validation croisée contre kymatio (traduction du pipeline à filtres injectés = `allclose` rtol=1e-4 ; écart de l'écriture pleine résolution concentré sur S2 ; régime d'invariance commun à deux calibrages indépendants), classification Fashion-MNIST bornée avec test translaté ±2 px | **Le module rend la moyenne invariante** : l'écart par translation plafonne (0,73 à 8 px) là où pixels (1,14) et coefficients sans module (1,07) croissent sans borne — et à 600 images d'entraînement, le scattering complet tient 0,765 de précision sur test translaté quand les pixels s'effondrent de 0,790 à 0,425 | +| [WS-01-Denoising-SOTA](WS-01-Denoising-SOTA.ipynb) | Bloc B.5 : duel débruitage d'images (4 images canoniques × 3 sigmas × 3 graines) entre la baseline from scratch (moteur WS-00b + seuil universel MAD de WS-00a, dur/doux) et les estimateurs SOTA — VisuShrink et BayesShrink (`skimage.restoration.denoise_wavelet`), SureShrink implémenté à la main (minimisation du risque SURE en O(n log n), validée contre force brute) sur les coefficients `pywt` | **À transformée identique (db4, parité `allclose`), l'écart de débruitage vient du seuil, pas du moteur** : BayesShrink adaptatif par sous-bande gagne **+2,2 à +3,0 dB** sur le seuil universel global à chaque régime de bruit ; VisuShrink (packaging lib du même universel doux) colle à la baseline from scratch à 0,2 dB près | +| [WS-02-Scattering-SOTA](WS-02-Scattering-SOTA.ipynb) | kymatio (backend PyTorch, corpus batché en un tenseur) contre le moteur from-scratch de WS-00c repris à l'identique — même corpus (Fashion-MNIST 80/classe, 600/200), même classifieur (régression logistique L2), même test translaté ±2 px ; diagnostic de conventions par table de correspondance (permutation d'orientations mesurée par corrélation, canaux S1 appariés à 0,64-0,81) ; mesure jumelle accuracy/latence/mémoire ; loi de l'échantillon testée à 400/classe ; tableau récapitulatif final A-vs-B de la série (LOC et dépendances calculés à l'exécution) | **SOTA rime avec ingénierie, pas avec justesse** : kymatio transforme ~46× plus vite (rapport de latence mesuré dans le notebook) mais, ses filtres isotropes par défaut étant moins sélectifs que les morlets anisotropes from-scratch, l'accuracy bornée leur donne raison — comprendre en Bloc A, produire en Bloc B | +| [WS-03-Synthese-Scattering-vs-ResNet](WS-03-Synthese-Scattering-vs-ResNet.ipynb) | Synthèse finale : représentation construite (scattering kymatio J=2, L=4, 1225-d) contre représentation apprise (ResNet18 pré-entraîné ImageNet, avgpool 512-d) sur le même Fashion-MNIST (1 500 train / 750 test, vrai split test torchvision), même sonde (régression logistique standardisée), même test translaté ±2 px, écart relatif de représentation mesuré sous décalage, tableau récap à quatre axes (discrimination, stabilité, coût, dimension) | **Construit et appris ne dominent pas les mêmes axes** : le scattering gagne le test propre (0,837 contre 0,811) et coûte ~28× moins cher à l'extraction (rapport relatif, tableau du notebook) sans avoir vu une seule image ; le ResNet gagne la robustesse au décalage (chute 0,060 contre 0,255, écart relatif 0,331 contre 0,425) — la frontière du *pourquoi du from scratch / quand du SOTA* se lit axe par axe, pas en un vainqueur | ## Feuille de route (issue #16055) diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/README.md index 399923f6f7..91d385ddeb 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/README.md @@ -167,48 +167,48 @@ Le socle machine learning canonique avec scikit-learn, posé à la main entre le | Notebook | Sujet | Concept-phare | |----------|-------|---------------| -| [2.1-Workflow-ML](02-ML-Cours/2.1-Workflow-ML.html) | split → fit → predict → évaluer | surapprentissage rendu visible | -| [2.2-Descente-de-gradient](02-ML-Cours/2.2-Descente-de-gradient.html) | ouvrir la boîte noire de `fit()` | 3 learning rates (lent / bon / divergeant) | -| [2.3-Regression-lineaire-logistique](02-ML-Cours/2.3-Regression-lineaire-logistique.html) | OLS vs MLE | droite vs sigmoïde | -| [2.3b-Naive-Bayes-Generatif](02-ML-Cours/2.3b-Naive-Bayes-Generatif.html) | *Pont génératif* — classifieur naïf de Bayes (Bernoulli, multinomial, Gaussien), hypothèse d'indépendance conditionnelle | **L'indépendance qui décide** : la frontière est inherited du modèle conjoint, pas apprise | -| [2.3c-Regression-Grande-Dimension](02-ML-Cours/2.3c-Regression-Grande-Dimension.html) | p >> n : Ridge (L2), PCR (ACP) et PLS (supervisée) | **Var ≠ valeur prédictive** : la PLS trouve en 5 composantes ce que la PCR paie à 44 | -| [2.3d-Modele-Gaussien-LDA-QDA](02-ML-Cours/2.3d-Modele-Gaussien-LDA-QDA.html) | Analyse discriminante linéaire vs quadratique | **L'hypothèse de covariance décide la frontière** : partagée → droite (LDA), propre → conique (QDA) | -| [2.4-Arbres-Forets-Ensembles](02-ML-Cours/2.4-Arbres-Forets-Ensembles.html) | DecisionTree, RandomForest, GradientBoosting | réduction de variance | -| [2.5-Biais-Variance-CV-ROC](02-ML-Cours/2.5-Biais-Variance-CV-ROC.html) | biais-variance, validation croisée, ROC/AUC | coût du seuil de décision | -| [2.5b-Calibration-Probabilites](02-ML-Cours/2.5b-Calibration-Probabilites.html) | calibration des probabilités : reliability diagram, ECE | pourquoi 0.87 n'est pas 87 % de chances | -| [2.5c-Equite-Sous-Groupes](02-ML-Cours/2.5c-Equite-Sous-Groupes.html) | équité par sous-groupe : parité démographique, equalized odds, post-traitement par seuils (Hardt) | **L'accuracy globale ne suffit pas** : 96,4 % global coexiste avec des écarts de groupe [0,92–1,00] | -| [2.6-Clustering-KMeans-PCA](02-ML-Cours/2.6-Clustering-KMeans-PCA.html) | non supervisé : KMeans + ACP | structure retrouvée sans étiquettes | -| [2.7-Modeles-Non-Parametriques](02-ML-Cours/2.7-Modeles-Non-Parametriques.html) | SVM à noyau et k plus proches voisins | kernel trick (linéaire vs RBF) | -| [2.7b-SMO-From-Scratch](02-ML-Cours/2.7b-SMO-From-Scratch.html) | *Accrétion de 2.7* — SMO (Platt) écrit à la main : sous-problème 2D (dont la branche dégénérée `η ≤ 0`), cascade de working set, KKT et gap de dualité | **Le solveur écrit à la main retrouve sklearn** : même biais à 4·10⁻⁴ près, gap de dualité ≈ 3·10⁻³, pire violation KKT ponctuelle ≈ 10⁻³ | -| [2.8-Theorie-PAC](02-ML-Cours/2.8-Theorie-PAC.html) | théorie PAC : sample complexity, dimension VC | la borne PAC prédit l'empirique | -| [2.8b-Theorie-PAC-Lean](02-ML-Cours/2.8b-Theorie-PAC-Lean.html) | *Compagnon Lean* (kernel `lean4-wsl`) — la même borne PAC, démontrée | ce que 2.8 constate, le lake le prouve | -| [2.8c-Borne-Temoin-Concentration](02-ML-Cours/2.8c-Borne-Temoin-Concentration.html) | *Carte transversale + illustrations Python* — Sections 1--3 (reconstruction de la borne, témoin extrémal, Hoeffding bilatérale) sous kernel `coursia-ml-training` | qui porte quoi, et la mesure numérique Python exécutée | -| [2.8d-Lean-Novikoff-Convergence](02-ML-Cours/2.8d-Lean-Novikoff-Convergence.html) | *Compagnon Lean* (kernel `lean4-wsl`) — la moitié Perceptron du lake : Novikoff `n·γ² ≤ R²`, ses deux lemmes, son témoin de saturation | **Le théorème interrogé en direct** : `#check` + `#print axioms` depuis le lake, dynamique rejouée sur entiers | -| [2.9-Grokking-Generalisation](02-ML-Cours/2.9-Grokking-Generalisation.html) | *Épilogue* — grokking : la généralisation qui arrive en retard (premier réseau de neurones) | **L'horloge cachée** : embeddings rangés en cercle après le grok (ACP + Fourier) | -| [2.10-Optimisation-Hyperparametres](02-ML-Cours/2.10-Optimisation-Hyperparametres.html) | méthodologie du réglage : grille, hasard, bayésien (TPE) — et quand s'arrêter | le critère d'arrêt économise la moitié des essais | -| [2.11-Regularisation-Sparse-LASSO](02-ML-Cours/2.11-Regularisation-Sparse-LASSO.html) | *Régularisation sparse* — LASSO (L1, polyèdre) vs Ridge (L2, boule), coord descent, sélection de λ, ElasticNet sur features corrélées | **la géométrie décide** : polyèdre L1 → sparsity, boule L2 → shrink ; sur ρ > 0.7, ElasticNet stabilise | -| [2.12-Donnees-Desequilibrees](02-ML-Cours/2.12-Donnees-Desequilibrees.html) | *Classes déséquilibrées* — la métrique qui ment (accuracy vs PR), rééchantillonnage, seuillage par coût | **La courbe PR dit la vérité** : sur ~3 % de positifs, la ROC flatte — seule l'average precision rend l'arbitrage visible | -| [2.13-Analyse-Erreurs](02-ML-Cours/2.13-Analyse-Erreurs.html) | le geste du praticien : diagnostiquer un modèle entraîné (tranches, worst-k) | la poche invisible : 67.6% d'erreur sous un score global correct | -| [2.14-Explicabilite-SHAP-LIME-Contrefactuels](02-ML-Cours/2.14-Explicabilite-SHAP-LIME-Contrefactuels.html) | *Explicabilité XAI* — expliquer une décision individuelle : SHAP (arbre exact + kernel), LIME, contrefactuels DiCE, et leurs limites communes | **additivité exacte vs récits instables** : Tree SHAP vérifié à 1e-16, LIME instable de seed en seed | +| [2.1-Workflow-ML](02-ML-Cours/2.1-Workflow-ML.ipynb) | split → fit → predict → évaluer | surapprentissage rendu visible | +| [2.2-Descente-de-gradient](02-ML-Cours/2.2-Descente-de-gradient.ipynb) | ouvrir la boîte noire de `fit()` | 3 learning rates (lent / bon / divergeant) | +| [2.3-Regression-lineaire-logistique](02-ML-Cours/2.3-Regression-lineaire-logistique.ipynb) | OLS vs MLE | droite vs sigmoïde | +| [2.3b-Naive-Bayes-Generatif](02-ML-Cours/2.3b-Naive-Bayes-Generatif.ipynb) | *Pont génératif* — classifieur naïf de Bayes (Bernoulli, multinomial, Gaussien), hypothèse d'indépendance conditionnelle | **L'indépendance qui décide** : la frontière est inherited du modèle conjoint, pas apprise | +| [2.3c-Regression-Grande-Dimension](02-ML-Cours/2.3c-Regression-Grande-Dimension.ipynb) | p >> n : Ridge (L2), PCR (ACP) et PLS (supervisée) | **Var ≠ valeur prédictive** : la PLS trouve en 5 composantes ce que la PCR paie à 44 | +| [2.3d-Modele-Gaussien-LDA-QDA](02-ML-Cours/2.3d-Modele-Gaussien-LDA-QDA.ipynb) | Analyse discriminante linéaire vs quadratique | **L'hypothèse de covariance décide la frontière** : partagée → droite (LDA), propre → conique (QDA) | +| [2.4-Arbres-Forets-Ensembles](02-ML-Cours/2.4-Arbres-Forets-Ensembles.ipynb) | DecisionTree, RandomForest, GradientBoosting | réduction de variance | +| [2.5-Biais-Variance-CV-ROC](02-ML-Cours/2.5-Biais-Variance-CV-ROC.ipynb) | biais-variance, validation croisée, ROC/AUC | coût du seuil de décision | +| [2.5b-Calibration-Probabilites](02-ML-Cours/2.5b-Calibration-Probabilites.ipynb) | calibration des probabilités : reliability diagram, ECE | pourquoi 0.87 n'est pas 87 % de chances | +| [2.5c-Equite-Sous-Groupes](02-ML-Cours/2.5c-Equite-Sous-Groupes.ipynb) | équité par sous-groupe : parité démographique, equalized odds, post-traitement par seuils (Hardt) | **L'accuracy globale ne suffit pas** : 96,4 % global coexiste avec des écarts de groupe [0,92–1,00] | +| [2.6-Clustering-KMeans-PCA](02-ML-Cours/2.6-Clustering-KMeans-PCA.ipynb) | non supervisé : KMeans + ACP | structure retrouvée sans étiquettes | +| [2.7-Modeles-Non-Parametriques](02-ML-Cours/2.7-Modeles-Non-Parametriques.ipynb) | SVM à noyau et k plus proches voisins | kernel trick (linéaire vs RBF) | +| [2.7b-SMO-From-Scratch](02-ML-Cours/2.7b-SMO-From-Scratch.ipynb) | *Accrétion de 2.7* — SMO (Platt) écrit à la main : sous-problème 2D (dont la branche dégénérée `η ≤ 0`), cascade de working set, KKT et gap de dualité | **Le solveur écrit à la main retrouve sklearn** : même biais à 4·10⁻⁴ près, gap de dualité ≈ 3·10⁻³, pire violation KKT ponctuelle ≈ 10⁻³ | +| [2.8-Theorie-PAC](02-ML-Cours/2.8-Theorie-PAC.ipynb) | théorie PAC : sample complexity, dimension VC | la borne PAC prédit l'empirique | +| [2.8b-Theorie-PAC-Lean](02-ML-Cours/2.8b-Theorie-PAC-Lean.ipynb) | *Compagnon Lean* (kernel `lean4-wsl`) — la même borne PAC, démontrée | ce que 2.8 constate, le lake le prouve | +| [2.8c-Borne-Temoin-Concentration](02-ML-Cours/2.8c-Borne-Temoin-Concentration.ipynb) | *Carte transversale + illustrations Python* — Sections 1--3 (reconstruction de la borne, témoin extrémal, Hoeffding bilatérale) sous kernel `coursia-ml-training` | qui porte quoi, et la mesure numérique Python exécutée | +| [2.8d-Lean-Novikoff-Convergence](02-ML-Cours/2.8d-Lean-Novikoff-Convergence.ipynb) | *Compagnon Lean* (kernel `lean4-wsl`) — la moitié Perceptron du lake : Novikoff `n·γ² ≤ R²`, ses deux lemmes, son témoin de saturation | **Le théorème interrogé en direct** : `#check` + `#print axioms` depuis le lake, dynamique rejouée sur entiers | +| [2.9-Grokking-Generalisation](02-ML-Cours/2.9-Grokking-Generalisation.ipynb) | *Épilogue* — grokking : la généralisation qui arrive en retard (premier réseau de neurones) | **L'horloge cachée** : embeddings rangés en cercle après le grok (ACP + Fourier) | +| [2.10-Optimisation-Hyperparametres](02-ML-Cours/2.10-Optimisation-Hyperparametres.ipynb) | méthodologie du réglage : grille, hasard, bayésien (TPE) — et quand s'arrêter | le critère d'arrêt économise la moitié des essais | +| [2.11-Regularisation-Sparse-LASSO](02-ML-Cours/2.11-Regularisation-Sparse-LASSO.ipynb) | *Régularisation sparse* — LASSO (L1, polyèdre) vs Ridge (L2, boule), coord descent, sélection de λ, ElasticNet sur features corrélées | **la géométrie décide** : polyèdre L1 → sparsity, boule L2 → shrink ; sur ρ > 0.7, ElasticNet stabilise | +| [2.12-Donnees-Desequilibrees](02-ML-Cours/2.12-Donnees-Desequilibrees.ipynb) | *Classes déséquilibrées* — la métrique qui ment (accuracy vs PR), rééchantillonnage, seuillage par coût | **La courbe PR dit la vérité** : sur ~3 % de positifs, la ROC flatte — seule l'average precision rend l'arbitrage visible | +| [2.13-Analyse-Erreurs](02-ML-Cours/2.13-Analyse-Erreurs.ipynb) | le geste du praticien : diagnostiquer un modèle entraîné (tranches, worst-k) | la poche invisible : 67.6% d'erreur sous un score global correct | +| [2.14-Explicabilite-SHAP-LIME-Contrefactuels](02-ML-Cours/2.14-Explicabilite-SHAP-LIME-Contrefactuels.ipynb) | *Explicabilité XAI* — expliquer une décision individuelle : SHAP (arbre exact + kernel), LIME, contrefactuels DiCE, et leurs limites communes | **additivité exacte vs récits instables** : Tree SHAP vérifié à 1e-16, LIME instable de seed en seed | Documentation complète : [02-ML-Cours/README.md](02-ML-Cours/README.md) ## Deep Learning (03-DeepLearning) -Le prolongement direct du socle : là où [2.2](02-ML-Cours/2.2-Descente-de-gradient.html) ouvre `fit()` sur une droite et [2.9](02-ML-Cours/2.9-Grokking-Generalisation.html) entraîne un réseau PyTorch en boîte noire, cette série écrit la mécanique intermédiaire **à la main** — chaque mécanisme implémenté en NumPy pur, vérifié (gradient numérique, parité pas-à-pas avec PyTorch), puis relié à l'API `torch` que consomment les séries RL/PostTraining. +Le prolongement direct du socle : là où [2.2](02-ML-Cours/2.2-Descente-de-gradient.ipynb) ouvre `fit()` sur une droite et [2.9](02-ML-Cours/2.9-Grokking-Generalisation.ipynb) entraîne un réseau PyTorch en boîte noire, cette série écrit la mécanique intermédiaire **à la main** — chaque mécanisme implémenté en NumPy pur, vérifié (gradient numérique, parité pas-à-pas avec PyTorch), puis relié à l'API `torch` que consomment les séries RL/PostTraining. | Notebook | Sujet | Concept-phare | |----------|-------|---------------| -| [3.0-Theorie-Information](03-DeepLearning/3.0-Theorie-Information.html) | Entropie, cross-entropy et KL from scratch sur texte français, MSE vs CE sur classifieur, température softmax, pont DPO/GRPO | **La loss qui fait apprendre** : pourquoi la CE et pas la MSE ; KL comme mesure de décalage entre distributions | -| [3.1-Retropropagation](03-DeepLearning/3.1-Retropropagation.html) | Le MLP et la rétropropagation à la main (NumPy pur, sans autograd) | **Le gradient vérifié** (différence finie 1,3e-11 ; parité exacte avec PyTorch ; init nulle = gradient nul) | -| [3.2-Optimisateurs](03-DeepLearning/3.2-Optimisateurs.html) | Momentum, Adagrad, RMSProp, Adam et schedules, écrits puis validés pas à pas contre `torch.optim` | **La parité exacte** (5 mises à jour identiques à ≤2,2e-16 ; Beale 5 trajectoires ; MLP 3 graines ; schedules : coût en déterministe, gain en bruité) | -| [3.3-Regularisation](03-DeepLearning/3.3-Regularisation.html) | Dropout, weight decay et early stopping écrits à la main sur un MLP construit pour surapprendre (17 000 paramètres, 100 points, 12 étiquettes fausses) | **Corriger la variance sans changer le modèle** : trois remèdes appliqués au même surapprentissage fabriqué | -| [3.4-Attention-Transformer-From-Scratch](03-DeepLearning/3.4-Attention-Transformer-From-Scratch.html) | De l'attention mono-tête lisible sur l'inversion de séquence au mini-GPT de 1,25 M entraîné dans le notebook | **L'attention jusqu'au bout, sur CPU** : attention + masque causal + multi-têtes + bloc pré-norme, mini-GPT char-level (117 s, *Le Horla*) | -| [3.5-Phenomenes-de-Generalisation](03-DeepLearning/3.5-Phenomenes-de-Generalisation.html) | Grokking et double descente reproduits en NumPy pur (MLP à embeddings + Adam à la main), confrontés à la borne PAC du 2.8 | **Le phénomène sans la boîte noire** : mémorisation → transition abrupte, et le W de la double descente (pic au seuil M ≈ n, 20 graines) | -| [3.6-Modeles-Generatifs](03-DeepLearning/3.6-Modeles-Generatifs.html) | VAE, GAN et diffusion (DDPM) écrits en NumPy pur, même cible (huit modes sur un cercle), même budget, face à une baseline GMM | **Trois objectifs, trois échecs** : VAE couvre mais moyenne, GAN s'effondre, diffusion raffine au prix de 100 passes | -| [3.6b-Modeles-Generatifs-PyTorch](03-DeepLearning/3.6b-Modeles-Generatifs-PyTorch.html) | *Versant framework* du 3.6 : VAE, GAN et DDPM entraînés sur cible 2D à 4 modes (PyTorch CPU) | **Le compromis qualité/diversité** : 4 mécanismes sur mêmes métriques, verdict nuancé, pas de « gagnant » unique | -| [3.7-Distillation-Maitre-Eleve](03-DeepLearning/3.7-Distillation-Maitre-Eleve.html) | Distillation teacher/student : maître entraîné distille son savoir vers un élève ~9× plus petit | **Le facteur T² vérifié** : la KL brute chute en ~1/T², la KL scalée reste constante ; verdict INCONCLUSIVE au seuil strict | -| [3.8-Representations-Contrastives](03-DeepLearning/3.8-Representations-Contrastives.html) | Pré-entraînement contrastif moderne : vues continues, encodeur MLP et loss InfoNCE from scratch, pont vers skip-gram | **Apprendre des représentations sans étiquettes** : deux vues attirent leurs embeddings, les autres repoussent | +| [3.0-Theorie-Information](03-DeepLearning/3.0-Theorie-Information.ipynb) | Entropie, cross-entropy et KL from scratch sur texte français, MSE vs CE sur classifieur, température softmax, pont DPO/GRPO | **La loss qui fait apprendre** : pourquoi la CE et pas la MSE ; KL comme mesure de décalage entre distributions | +| [3.1-Retropropagation](03-DeepLearning/3.1-Retropropagation.ipynb) | Le MLP et la rétropropagation à la main (NumPy pur, sans autograd) | **Le gradient vérifié** (différence finie 1,3e-11 ; parité exacte avec PyTorch ; init nulle = gradient nul) | +| [3.2-Optimisateurs](03-DeepLearning/3.2-Optimisateurs.ipynb) | Momentum, Adagrad, RMSProp, Adam et schedules, écrits puis validés pas à pas contre `torch.optim` | **La parité exacte** (5 mises à jour identiques à ≤2,2e-16 ; Beale 5 trajectoires ; MLP 3 graines ; schedules : coût en déterministe, gain en bruité) | +| [3.3-Regularisation](03-DeepLearning/3.3-Regularisation.ipynb) | Dropout, weight decay et early stopping écrits à la main sur un MLP construit pour surapprendre (17 000 paramètres, 100 points, 12 étiquettes fausses) | **Corriger la variance sans changer le modèle** : trois remèdes appliqués au même surapprentissage fabriqué | +| [3.4-Attention-Transformer-From-Scratch](03-DeepLearning/3.4-Attention-Transformer-From-Scratch.ipynb) | De l'attention mono-tête lisible sur l'inversion de séquence au mini-GPT de 1,25 M entraîné dans le notebook | **L'attention jusqu'au bout, sur CPU** : attention + masque causal + multi-têtes + bloc pré-norme, mini-GPT char-level (117 s, *Le Horla*) | +| [3.5-Phenomenes-de-Generalisation](03-DeepLearning/3.5-Phenomenes-de-Generalisation.ipynb) | Grokking et double descente reproduits en NumPy pur (MLP à embeddings + Adam à la main), confrontés à la borne PAC du 2.8 | **Le phénomène sans la boîte noire** : mémorisation → transition abrupte, et le W de la double descente (pic au seuil M ≈ n, 20 graines) | +| [3.6-Modeles-Generatifs](03-DeepLearning/3.6-Modeles-Generatifs.ipynb) | VAE, GAN et diffusion (DDPM) écrits en NumPy pur, même cible (huit modes sur un cercle), même budget, face à une baseline GMM | **Trois objectifs, trois échecs** : VAE couvre mais moyenne, GAN s'effondre, diffusion raffine au prix de 100 passes | +| [3.6b-Modeles-Generatifs-PyTorch](03-DeepLearning/3.6b-Modeles-Generatifs-PyTorch.ipynb) | *Versant framework* du 3.6 : VAE, GAN et DDPM entraînés sur cible 2D à 4 modes (PyTorch CPU) | **Le compromis qualité/diversité** : 4 mécanismes sur mêmes métriques, verdict nuancé, pas de « gagnant » unique | +| [3.7-Distillation-Maitre-Eleve](03-DeepLearning/3.7-Distillation-Maitre-Eleve.ipynb) | Distillation teacher/student : maître entraîné distille son savoir vers un élève ~9× plus petit | **Le facteur T² vérifié** : la KL brute chute en ~1/T², la KL scalée reste constante ; verdict INCONCLUSIVE au seuil strict | +| [3.8-Representations-Contrastives](03-DeepLearning/3.8-Representations-Contrastives.ipynb) | Pré-entraînement contrastif moderne : vues continues, encodeur MLP et loss InfoNCE from scratch, pont vers skip-gram | **Apprendre des représentations sans étiquettes** : deux vues attirent leurs embeddings, les autres repoussent | Documentation complète : [03-DeepLearning/README.md](03-DeepLearning/README.md) @@ -218,9 +218,9 @@ Documentation complète : [03-DeepLearning/README.md](03-DeepLearning/README.md) | Notebook | Sujet | Concept-phare | |----------|-------|---------------| -| [4.1-Conv-NumPy-Torch-Allclose](04-Vision/4.1-Conv-NumPy-Torch-Allclose.html) | Conv2d NumPy pur (single + multi-canal), gradient vérifié par différence finie, parité epsilon machine avec `torch.nn.Conv2d`, pooling et invariance par translation | **La convolution n'est pas magique** : un produit scalaire local, partagé spatialement, parité NumPy/torch à epsilon machine | -| [4.2-ConvNet-Profonde-Residuelles](04-Vision/4.2-ConvNet-Profonde-Residuelles.html) | 20 conv2d empilées nues (effondrement du gradient), skip naïf (gradient réparé mais passe avant qui dérive), bloc pré-norme (les deux réparés), même protocole transposé à 20 blocs d'attention, puis accuracy CIFAR-10 sur 3 graines | **Le skip-connection n'est pas un détail architectural** : c'est le mécanisme qui rend les réseaux profonds entraînables | -| [4.3-TransferLearning-ResNet](04-Vision/4.3-TransferLearning-ResNet.html) | ResNet18 pré-entraîné ImageNet, tête greffée (5 130 params entraînables sur 11,18 M), gelé vs fine-tuné sur EuroSAT (Sentinel-2, 10 classes, 3 graines appariées + test de permutation des signes) | **Le feature extractor pré-entraîné est réutilisable — et le prix de ne pas l'adapter se mesure** : gelé ~89 % ; fine-tuné +6,2 pts appariés, mais seulement à taux différencié décroissant (à taux constants, l'optimiseur finit sous le gelé) | +| [4.1-Conv-NumPy-Torch-Allclose](04-Vision/4.1-Conv-NumPy-Torch-Allclose.ipynb) | Conv2d NumPy pur (single + multi-canal), gradient vérifié par différence finie, parité epsilon machine avec `torch.nn.Conv2d`, pooling et invariance par translation | **La convolution n'est pas magique** : un produit scalaire local, partagé spatialement, parité NumPy/torch à epsilon machine | +| [4.2-ConvNet-Profonde-Residuelles](04-Vision/4.2-ConvNet-Profonde-Residuelles.ipynb) | 20 conv2d empilées nues (effondrement du gradient), skip naïf (gradient réparé mais passe avant qui dérive), bloc pré-norme (les deux réparés), même protocole transposé à 20 blocs d'attention, puis accuracy CIFAR-10 sur 3 graines | **Le skip-connection n'est pas un détail architectural** : c'est le mécanisme qui rend les réseaux profonds entraînables | +| [4.3-TransferLearning-ResNet](04-Vision/4.3-TransferLearning-ResNet.ipynb) | ResNet18 pré-entraîné ImageNet, tête greffée (5 130 params entraînables sur 11,18 M), gelé vs fine-tuné sur EuroSAT (Sentinel-2, 10 classes, 3 graines appariées + test de permutation des signes) | **Le feature extractor pré-entraîné est réutilisable — et le prix de ne pas l'adapter se mesure** : gelé ~89 % ; fine-tuné +6,2 pts appariés, mais seulement à taux différencié décroissant (à taux constants, l'optimiseur finit sous le gelé) | Documentation complète : [04-Vision/README.md](04-Vision/README.md) @@ -230,9 +230,9 @@ Série d'analyse multi-résolution dans la même discipline from scratch : la tr | Notebook | Sujet | Concept-phare | |----------|-------|---------------| -| [WS-00a-Ondelettes-1D-from-scratch](04b-Wavelet-Scattering/WS-00a-Ondelettes-1D-from-scratch.html) | DWT orthonormale à la main (Haar, D4, db4), profil d'énergie par échelle, débruitage par seuillage dur/doux (seuil universel, sans oracle) contre passe-bas Fourier (cutoffs garde-tout/étroit/libre, avec oracle), banc Donoho-Johnstone (Doppler, HeaviSine, Stationnaire+burst) | **Aucune base n'est universellement parcimonieuse** : ondelette +4,5 dB sur le chirp sans oracle, Fourier +4,8 dB sur le stationnaire avec oracle, mixte serré | -| [WS-00b-Ondelettes-2D-from-scratch](04b-Wavelet-Scattering/WS-00b-Ondelettes-2D-from-scratch.html) | Transformée 2D séparable = produit tensoriel du moteur 1D de WS-00a, pyramide de Mallat, contrôle d'orientation sur motifs à orientation connue, reconstruction parfaite + `allclose` bande par bande contre PyWavelets, duel de compression à budget apparié contre une DCT 8×8 | **Le pouvoir de parcimonie est conditionnel au budget** : db4 écrase la DCT 8×8 de +16,4 dB à 0,2 % de coefficients retenus, mais l'écart tombe à ~0,2 dB dès 5 % | -| [WS-01-Denoising-SOTA](04b-Wavelet-Scattering/WS-01-Denoising-SOTA.html) | Bloc B : duel débruitage d'images (4 images × 3 sigmas × 3 graines) entre la baseline from scratch (moteur WS-00b, seuil universel de WS-00a) et les estimateurs SOTA — VisuShrink/BayesShrink (`skimage`), SureShrink écrit à la main (SURE validé contre force brute) sur coefficients `pywt` | **À transformée identique, l'écart vient du seuil, pas du moteur** : BayesShrink adaptatif par sous-bande gagne +2,2 à +3,0 dB sur le seuil universel global à chaque régime de bruit | +| [WS-00a-Ondelettes-1D-from-scratch](04b-Wavelet-Scattering/WS-00a-Ondelettes-1D-from-scratch.ipynb) | DWT orthonormale à la main (Haar, D4, db4), profil d'énergie par échelle, débruitage par seuillage dur/doux (seuil universel, sans oracle) contre passe-bas Fourier (cutoffs garde-tout/étroit/libre, avec oracle), banc Donoho-Johnstone (Doppler, HeaviSine, Stationnaire+burst) | **Aucune base n'est universellement parcimonieuse** : ondelette +4,5 dB sur le chirp sans oracle, Fourier +4,8 dB sur le stationnaire avec oracle, mixte serré | +| [WS-00b-Ondelettes-2D-from-scratch](04b-Wavelet-Scattering/WS-00b-Ondelettes-2D-from-scratch.ipynb) | Transformée 2D séparable = produit tensoriel du moteur 1D de WS-00a, pyramide de Mallat, contrôle d'orientation sur motifs à orientation connue, reconstruction parfaite + `allclose` bande par bande contre PyWavelets, duel de compression à budget apparié contre une DCT 8×8 | **Le pouvoir de parcimonie est conditionnel au budget** : db4 écrase la DCT 8×8 de +16,4 dB à 0,2 % de coefficients retenus, mais l'écart tombe à ~0,2 dB dès 5 % | +| [WS-01-Denoising-SOTA](04b-Wavelet-Scattering/WS-01-Denoising-SOTA.ipynb) | Bloc B : duel débruitage d'images (4 images × 3 sigmas × 3 graines) entre la baseline from scratch (moteur WS-00b, seuil universel de WS-00a) et les estimateurs SOTA — VisuShrink/BayesShrink (`skimage`), SureShrink écrit à la main (SURE validé contre force brute) sur coefficients `pywt` | **À transformée identique, l'écart vient du seuil, pas du moteur** : BayesShrink adaptatif par sous-bande gagne +2,2 à +3,0 dB sur le seuil universel global à chaque régime de bruit | Documentation complète : [04b-Wavelet-Scattering/README.md](04b-Wavelet-Scattering/README.md) @@ -242,23 +242,23 @@ Documentation complète : [04b-Wavelet-Scattering/README.md](04b-Wavelet-Scatter | Lab | Notebook | Contenu | |-----|----------|---------| -| 1 | [Lab1-PythonForDataScience](Track1-LangChain/Day1-Foundations/Labs/Lab1-PythonForDataScience.html) | Pandas, Matplotlib, Scikit-Learn | +| 1 | [Lab1-PythonForDataScience](Track1-LangChain/Day1-Foundations/Labs/Lab1-PythonForDataScience.ipynb) | Pandas, Matplotlib, Scikit-Learn | ### Day 2 - Agents Documentaires | Lab | Notebook | Contenu | |-----|----------|---------| -| 2 | [Lab2-RFP-Analysis](Track1-LangChain/Day2-Document-Agents/Labs/Lab2-RFP-Analysis/Lab2-RFP-Analysis.html) | Parser des appels d'offres avec LLM | -| 3 | [Lab3-CV-Screening](Track1-LangChain/Day2-Document-Agents/Labs/Lab3-CV-Screening/Lab3-CV-Screening.html) | Scoring CV avec agents IA | +| 2 | [Lab2-RFP-Analysis](Track1-LangChain/Day2-Document-Agents/Labs/Lab2-RFP-Analysis/Lab2-RFP-Analysis.ipynb) | Parser des appels d'offres avec LLM | +| 3 | [Lab3-CV-Screening](Track1-LangChain/Day2-Document-Agents/Labs/Lab3-CV-Screening/Lab3-CV-Screening.ipynb) | Scoring CV avec agents IA | ### Day 3 - Data + Agents | Lab | Notebook | Contenu | |-----|----------|---------| -| 4 | [Lab4-DataWrangling](Track1-LangChain/Day3-Data-Agents/Labs/Lab4-DataWrangling/Lab4-DataWrangling.html) | Nettoyage et transformation | -| 5 | [Lab5-Viz-ML](Track1-LangChain/Day3-Data-Agents/Labs/Lab5-Viz-ML/Lab5-Viz-ML.html) | Visualisation et intro ML | -| 6 | [Lab6-First-Agent](Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/Lab6-First-Agent.html) | Construction d'un agent simple | -| 7 | [Lab7-Data-Analysis-Agent](Track1-LangChain/Day3-Data-Agents/Labs/Lab7-Data-Analysis-Agent/Lab7-Data-Analysis-Agent.html) | Agent pour DataFrames | +| 4 | [Lab4-DataWrangling](Track1-LangChain/Day3-Data-Agents/Labs/Lab4-DataWrangling/Lab4-DataWrangling.ipynb) | Nettoyage et transformation | +| 5 | [Lab5-Viz-ML](Track1-LangChain/Day3-Data-Agents/Labs/Lab5-Viz-ML/Lab5-Viz-ML.ipynb) | Visualisation et intro ML | +| 6 | [Lab6-First-Agent](Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/Lab6-First-Agent.ipynb) | Construction d'un agent simple | +| 7 | [Lab7-Data-Analysis-Agent](Track1-LangChain/Day3-Data-Agents/Labs/Lab7-Data-Analysis-Agent/Lab7-Data-Analysis-Agent.ipynb) | Agent pour DataFrames | ## Track Track2-GoogleADK (Days 4-7) @@ -268,35 +268,35 @@ Track avancé intégrant les frameworks Google ADK (DS-STAR, MLE-STAR) avec supp | Lab | Notebook | Objectif | |-----|----------|----------| -| 8 | [ADK-Introduction](Track2-GoogleADK/Day4-Foundations/Lab8-ADK-Introduction.html) | Architecture ADK, configuration providers | -| 9 | [First-ADK-Agent](Track2-GoogleADK/Day4-Foundations/Lab9-First-ADK-Agent.html) | Premier agent pour Data Science | +| 8 | [ADK-Introduction](Track2-GoogleADK/Day4-Foundations/Lab8-ADK-Introduction.ipynb) | Architecture ADK, configuration providers | +| 9 | [First-ADK-Agent](Track2-GoogleADK/Day4-Foundations/Lab9-First-ADK-Agent.ipynb) | Premier agent pour Data Science | ### Day 5 - DS-STAR (Labs 10-12 + extensions 12b-12d, 18) | Lab | Notebook | Objectif | |-----|----------|----------| -| 10 | [File-Analyzer](Track2-GoogleADK/Day5-DS-Star/Lab10-File-Analyzer.html) | Analyse de fichiers hétérogènes | -| 11 | [Planner-Coder-Loop](Track2-GoogleADK/Day5-DS-Star/Lab11-Planner-Coder-Loop.html) | Boucle itérative multi-agents | -| 12 | [DS-Star-Workshop](Track2-GoogleADK/Day5-DS-Star/Lab12-DS-Star-Workshop.html) | Application complète | -| 12b | [Sequential-Orchestration](Track2-GoogleADK/Day5-DS-Star/Lab12b-Sequential-Orchestration.html) | Contrat C4 : désignation séquentielle, l'orchestrateur explicite au-dessus d'ADK | -| 12c | [Agent-Handoff](Track2-GoogleADK/Day5-DS-Star/Lab12c-Agent-Handoff.html) | Contrat C5 : handoff inter-agents natif câblé et observable | -| 12d | [Token-Usage](Track2-GoogleADK/Day5-DS-Star/Lab12d-Token-Usage.html) | Contrat C6 : traçabilité de la consommation LLM | -| 12e | [Session-Persistence](Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.html) | Persistance d'état de session : une conversation qui se souvient | +| 10 | [File-Analyzer](Track2-GoogleADK/Day5-DS-Star/Lab10-File-Analyzer.ipynb) | Analyse de fichiers hétérogènes | +| 11 | [Planner-Coder-Loop](Track2-GoogleADK/Day5-DS-Star/Lab11-Planner-Coder-Loop.ipynb) | Boucle itérative multi-agents | +| 12 | [DS-Star-Workshop](Track2-GoogleADK/Day5-DS-Star/Lab12-DS-Star-Workshop.ipynb) | Application complète | +| 12b | [Sequential-Orchestration](Track2-GoogleADK/Day5-DS-Star/Lab12b-Sequential-Orchestration.ipynb) | Contrat C4 : désignation séquentielle, l'orchestrateur explicite au-dessus d'ADK | +| 12c | [Agent-Handoff](Track2-GoogleADK/Day5-DS-Star/Lab12c-Agent-Handoff.ipynb) | Contrat C5 : handoff inter-agents natif câblé et observable | +| 12d | [Token-Usage](Track2-GoogleADK/Day5-DS-Star/Lab12d-Token-Usage.ipynb) | Contrat C6 : traçabilité de la consommation LLM | +| 12e | [Session-Persistence](Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.ipynb) | Persistance d'état de session : une conversation qui se souvient | ### Day 6 - MLE-STAR (Labs 13-15) | Lab | Notebook | Objectif | |-----|----------|----------| -| 13 | [Web-Search-SOTA](Track2-GoogleADK/Day6-MLE-Star/Lab13-Web-Search-SOTA.html) | Recherche de modèles SOTA | -| 14 | [Ablation-Refinement](Track2-GoogleADK/Day6-MLE-Star/Lab14-Ablation-Refinement.html) | Optimisation ciblée | -| 15 | [Kaggle-Challenge](Track2-GoogleADK/Day6-MLE-Star/Lab15-Kaggle-Challenge.html) | Compétition Kaggle | +| 13 | [Web-Search-SOTA](Track2-GoogleADK/Day6-MLE-Star/Lab13-Web-Search-SOTA.ipynb) | Recherche de modèles SOTA | +| 14 | [Ablation-Refinement](Track2-GoogleADK/Day6-MLE-Star/Lab14-Ablation-Refinement.ipynb) | Optimisation ciblée | +| 15 | [Kaggle-Challenge](Track2-GoogleADK/Day6-MLE-Star/Lab15-Kaggle-Challenge.ipynb) | Compétition Kaggle | ### Day 7 - Production (Labs 16-17) | Lab | Notebook | Objectif | |-----|----------|----------| -| 16 | [Data-Science-Agent](Track2-GoogleADK/Day7-Production/Lab16-Data-Science-Agent.html) | Agent BigQuery/BQML | -| 17 | [Final-Project](Track2-GoogleADK/Day7-Production/Lab17-Final-Project.html) | Projet intégré | +| 16 | [Data-Science-Agent](Track2-GoogleADK/Day7-Production/Lab16-Data-Science-Agent.ipynb) | Agent BigQuery/BQML | +| 17 | [Final-Project](Track2-GoogleADK/Day7-Production/Lab17-Final-Project.ipynb) | Projet intégré | ### Technologies Track2-GoogleADK diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day1-Foundations/Labs/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day1-Foundations/Labs/README.md index ab2461dc85..e17614e4d7 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day1-Foundations/Labs/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day1-Foundations/Labs/README.md @@ -26,7 +26,7 @@ Ce laboratoire ouvre la **Journée 1** du workshop. Il pose les fondations techn ## Notebook -- [Lab1-PythonForDataScience.ipynb](Lab1-PythonForDataScience.html) — notebook étudiant (3 exercices : statistiques par produit, filtrage conditionnel, prédictions par produit) +- [Lab1-PythonForDataScience.ipynb](Lab1-PythonForDataScience.ipynb) — notebook étudiant (3 exercices : statistiques par produit, filtrage conditionnel, prédictions par produit) ## Suite diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/Labs/Lab2-RFP-Analysis/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/Labs/Lab2-RFP-Analysis/README.md index bf102b2672..ade38d6444 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/Labs/Lab2-RFP-Analysis/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/Labs/Lab2-RFP-Analysis/README.md @@ -24,7 +24,7 @@ Ce laboratoire ouvre la **Journée 2** sur l'IA agentique appliquée à la pré- ## Notebook -- [Lab2-RFP-Analysis.ipynb](Lab2-RFP-Analysis.html) - notebook étudiant +- [Lab2-RFP-Analysis.ipynb](Lab2-RFP-Analysis.ipynb) - notebook étudiant - `Lab2-RFP-Analysis_output.ipynb` - version exécutée de référence ## Navigation diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/Labs/Lab3-CV-Screening/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/Labs/Lab3-CV-Screening/README.md index bc11106402..a0c6f2425b 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/Labs/Lab3-CV-Screening/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/Labs/Lab3-CV-Screening/README.md @@ -25,7 +25,7 @@ Ce laboratoire prolonge la logique du [Lab 2](../Lab2-RFP-Analysis/README.md) (a ## Notebook -- [Lab3-CV-Screening.ipynb](Lab3-CV-Screening.html) - notebook étudiant +- [Lab3-CV-Screening.ipynb](Lab3-CV-Screening.ipynb) - notebook étudiant - `Lab3-CV-Screening_output.ipynb` - version exécutée de référence ## Navigation diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/README.md index 380e9915ed..7e5814aeb5 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day2-Document-Agents/README.md @@ -8,8 +8,8 @@ La **Journée 2** opère le basculement central du workshop : de l'écriture du | Lab | Sujet | Concept-phare | |-----|-------|---------------| -| [Lab 2 — RFP Analysis](Labs/Lab2-RFP-Analysis/Lab2-RFP-Analysis.html) | d'un appel d'offres à un PoC en 1 heure | extraction structurée d'un texte libre par LLM | -| [Lab 3 — CV Screening](Labs/Lab3-CV-Screening/Lab3-CV-Screening.html) | pré-qualifier des candidats avec l'IA | analyse, notation et résumé de CVs vs offre | +| [Lab 2 — RFP Analysis](Labs/Lab2-RFP-Analysis/Lab2-RFP-Analysis.ipynb) | d'un appel d'offres à un PoC en 1 heure | extraction structurée d'un texte libre par LLM | +| [Lab 3 — CV Screening](Labs/Lab3-CV-Screening/Lab3-CV-Screening.ipynb) | pré-qualifier des candidats avec l'IA | analyse, notation et résumé de CVs vs offre | ## Prérequis diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab4-DataWrangling/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab4-DataWrangling/README.md index 1093018e70..100c0a47a9 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab4-DataWrangling/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab4-DataWrangling/README.md @@ -25,7 +25,7 @@ Ce laboratoire ouvre la **Journée 3** côté data. Il part du constat classique ## Notebook -- [Lab4-DataWrangling.ipynb](Lab4-DataWrangling.html) — notebook étudiant (5 étapes guidées + 3 exercices : analyse temporelle, détection d'anomalies par méthode IQR, correction de doublons) +- [Lab4-DataWrangling.ipynb](Lab4-DataWrangling.ipynb) — notebook étudiant (5 étapes guidées + 3 exercices : analyse temporelle, détection d'anomalies par méthode IQR, correction de doublons) ## Suite diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab5-Viz-ML/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab5-Viz-ML/README.md index 5dac249732..f2c92c8942 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab5-Viz-ML/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab5-Viz-ML/README.md @@ -24,7 +24,7 @@ Ce laboratoire fait suite au [Lab 4](../Lab4-DataWrangling/README.md) : il repar ## Notebook -- [Lab5-Viz-ML.ipynb](Lab5-Viz-ML.html) — notebook étudiant (exemple guidé + exercices : prix moyen par catégorie, distribution des prix, matrice de confusion, courbe ROC / AUC) +- [Lab5-Viz-ML.ipynb](Lab5-Viz-ML.ipynb) — notebook étudiant (exemple guidé + exercices : prix moyen par catégorie, distribution des prix, matrice de confusion, courbe ROC / AUC) ## Suite diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/README.md index 54373b51ec..9c55ece922 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/README.md @@ -21,7 +21,7 @@ Après avoir utilisé des chaînes LangChain "fil tendu" dans les Labs 2 et 3, c ## Notebook -- [Lab6-First-Agent.ipynb](Lab6-First-Agent.html) - notebook étudiant +- [Lab6-First-Agent.ipynb](Lab6-First-Agent.ipynb) - notebook étudiant - `Lab6-First-Agent_output.ipynb` - version exécutée de référence ## Suite diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab7-Data-Analysis-Agent/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab7-Data-Analysis-Agent/README.md index ea7d423f4d..81a3026580 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab7-Data-Analysis-Agent/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab7-Data-Analysis-Agent/README.md @@ -21,7 +21,7 @@ Ce laboratoire **fusionne les deux mondes** explorés précédemment : la **Data ## Notebook -- [Lab7-Data-Analysis-Agent.ipynb](Lab7-Data-Analysis-Agent.html) - notebook étudiant +- [Lab7-Data-Analysis-Agent.ipynb](Lab7-Data-Analysis-Agent.ipynb) - notebook étudiant - `Lab7-Data-Analysis-Agent_output.ipynb` - version exécutée de référence ## Suite et transition diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/README.md index b8ce4c1ddf..bd20349004 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/README.md @@ -8,10 +8,10 @@ La **Journée 3** clôt le track LangChain : les agents deviennent capables de * | Lab | Sujet | Concept-phare | |-----|-------|---------------| -| [Lab 4 — Data Wrangling](Labs/Lab4-DataWrangling/Lab4-DataWrangling.html) | nettoyer un jeu de données « sale » réaliste | Pandas au service de la robustesse | -| [Lab 5 — Viz & ML](Labs/Lab5-Viz-ML/Lab5-Viz-ML.html) | exploration visuelle puis classification scikit-learn | la visualisation guidant le modèle | -| [Lab 6 — First Agent](Labs/Lab6-First-Agent/Lab6-First-Agent.html) | construire son premier agent LangChain | les 4 composants : LLM, Outils, Prompt, Exécuteur | -| [Lab 7 — Data Analysis Agent](Labs/Lab7-Data-Analysis-Agent/Lab7-Data-Analysis-Agent.html) | agent répondant en langage naturel sur un DataFrame | l'agent comme interface d'analyse | +| [Lab 4 — Data Wrangling](Labs/Lab4-DataWrangling/Lab4-DataWrangling.ipynb) | nettoyer un jeu de données « sale » réaliste | Pandas au service de la robustesse | +| [Lab 5 — Viz & ML](Labs/Lab5-Viz-ML/Lab5-Viz-ML.ipynb) | exploration visuelle puis classification scikit-learn | la visualisation guidant le modèle | +| [Lab 6 — First Agent](Labs/Lab6-First-Agent/Lab6-First-Agent.ipynb) | construire son premier agent LangChain | les 4 composants : LLM, Outils, Prompt, Exécuteur | +| [Lab 7 — Data Analysis Agent](Labs/Lab7-Data-Analysis-Agent/Lab7-Data-Analysis-Agent.ipynb) | agent répondant en langage naturel sur un DataFrame | l'agent comme interface d'analyse | ## Prérequis diff --git a/MyIA.AI.Notebooks/ML/ML.Net/README.md b/MyIA.AI.Notebooks/ML/ML.Net/README.md index cd24f76826..455302bdf6 100644 --- a/MyIA.AI.Notebooks/ML/ML.Net/README.md +++ b/MyIA.AI.Notebooks/ML/ML.Net/README.md @@ -11,7 +11,7 @@ maturity: BETA=23 ML.NET — la bibliothèque open-source de Microsoft — apporte le machine learning **nativement dans l'écosystème .NET** : on entraîne et on consomme des modèles directement en C#, sans quitter sa stack applicative ni dépendre d'un runtime Python. C'est un choix pensé pour les développeurs autant que pour les data scientists — l'AutoML abaisse la barrière d'entrée, et les modèles s'exécutent *in-process* dans des applications existantes (API web, services, desktop). L'interopérabilité **ONNX** permet d'importer des modèles entraînés ailleurs (scikit-learn, PyTorch, Hugging Face) et de les servir côté .NET : ML.NET devient ainsi un pont concret entre la recherche en Python et la production en entreprise. -> **Jumeaux de parité (C# ⇄ Python/scikit-learn).** Plusieurs notebooks de cette série disposent d'un **jumeau Python** co-localisé (`*-Python.ipynb`) qui couvre le **même concept pédagogique** avec les outils canoniques de l'écosystème Python (scikit-learn, statsmodels) — un contrepoint direct au pipeline ML.NET. Dès l'introduction ([ML-01-Python](ML-01-Introduction-Python.html)), le même workflow (régression, classification) se code en quelques lignes de scikit-learn. Là où ML.NET `RandomizedPca` détecte les anomalies, le jumeau utilise `sklearn.PCA` + erreur de reconstruction ; là où `ForecastBySsa` prévoit les séries temporelles, le jumeau emploie `statsmodels` STL + SARIMA ; là où `MatrixFactorization` recommande, le jumeau applique `NMF`. Cette parité permet de voir qu'un **même problème** se modélise idiomatiquement dans deux écosystèmes, et que les concepts (résidu de reconstruction, facteurs latents, décomposition tendance/saisonnalité) sont universels — seuls les outils diffèrent. Les jumeaux sont signalés dans les tables des notebooks ci-dessous. +> **Jumeaux de parité (C# ⇄ Python/scikit-learn).** Plusieurs notebooks de cette série disposent d'un **jumeau Python** co-localisé (`*-Python.ipynb`) qui couvre le **même concept pédagogique** avec les outils canoniques de l'écosystème Python (scikit-learn, statsmodels) — un contrepoint direct au pipeline ML.NET. Dès l'introduction ([ML-01-Python](ML-01-Introduction-Python.ipynb)), le même workflow (régression, classification) se code en quelques lignes de scikit-learn. Là où ML.NET `RandomizedPca` détecte les anomalies, le jumeau utilise `sklearn.PCA` + erreur de reconstruction ; là où `ForecastBySsa` prévoit les séries temporelles, le jumeau emploie `statsmodels` STL + SARIMA ; là où `MatrixFactorization` recommande, le jumeau applique `NMF`. Cette parité permet de voir qu'un **même problème** se modélise idiomatiquement dans deux écosystèmes, et que les concepts (résidu de reconstruction, facteurs latents, décomposition tendance/saisonnalité) sont universels — seuls les outils diffèrent. Les jumeaux sont signalés dans les tables des notebooks ci-dessous. Le parcours va du premier pipeline (ML-01) jusqu'à une application complète : préparation des données et feature engineering (ML-02), entraînement et AutoML (ML-03), évaluation rigoureuse par cross-validation et importance des variables (ML-04), puis les fonctionnalités avancées — prévision de séries temporelles par SSA (ML-05), interopérabilité ONNX (ML-06), systèmes de recommandation (ML-07), clustering non-supervisé par K-Means (ML-08) et détection d'anomalies par Randomized PCA (ML-09), puis l'introspection critique des benchmarks de détection d'anomalies (ML-09b), et enfin le Matrix Profile multidimensionnel, qui détecte sans rien apprendre (ML-09c) — avant un TP capstone qui marie ML.NET et la régression bayésienne d'Infer.NET. @@ -33,23 +33,23 @@ Le parcours va du premier pipeline (ML-01) jusqu'à une application complète : | # | Notebook | Contenu | Durée | |---|----------|---------|-------| -| 01 | [ML-01-Introduction](ML-01-Introduction.html) | Hello ML.NET World, pipeline de base · *jumeau [Python](ML-01-Introduction-Python.html)* | 30-40 min | -| 02 | [ML-02-Data&Features](ML-02-Data&Features.html) | IDataView, TextLoader, encodage · *jumeau [Python](ML-02-Data&Features-Python.html)* | 40-50 min | -| 03 | [ML-03-Entrainement&AutoML](ML-03-Entrainement&AutoML.html) | SDCA, LightGBM, AutoML · *jumeau [Python](ML-03-Entrainement&AutoML-Python.html)* | 45-60 min | -| 04 | [ML-04-Evaluation](ML-04-Evaluation.html) | Cross-validation, métriques, PFI · *jumeau [Python](ML-04-Evaluation-Python.html)* | 40-50 min | +| 01 | [ML-01-Introduction](ML-01-Introduction.ipynb) | Hello ML.NET World, pipeline de base · *jumeau [Python](ML-01-Introduction-Python.ipynb)* | 30-40 min | +| 02 | [ML-02-Data&Features](ML-02-Data&Features.ipynb) | IDataView, TextLoader, encodage · *jumeau [Python](ML-02-Data&Features-Python.ipynb)* | 40-50 min | +| 03 | [ML-03-Entrainement&AutoML](ML-03-Entrainement&AutoML.ipynb) | SDCA, LightGBM, AutoML · *jumeau [Python](ML-03-Entrainement&AutoML-Python.ipynb)* | 45-60 min | +| 04 | [ML-04-Evaluation](ML-04-Evaluation.ipynb) | Cross-validation, métriques, PFI · *jumeau [Python](ML-04-Evaluation-Python.ipynb)* | 40-50 min | ### Fonctionnalités avancées (ML-05 à ML-09c) | # | Notebook | Contenu | Jumeau Python (scikit-learn / statsmodels) | Durée | |---|----------|---------|------------------------------------------|-------| -| 05 | [ML-05-TimeSeries](ML-05-TimeSeries.html) | **Time Series Forecasting** avec ForecastBySsa (SSA) | [ML-05-Python](ML-05-TimeSeries-Python.html) — STL + SARIMA | 45-60 min | -| 05b | [ML-05b-Series-Temporelles-Classiques](ML-05b-Series-Temporelles-Classiques-Python.html) | **Socle statistique des séries temporelles** : ADF (stationnarité), ACF/PACF (ordres p/q), ARIMA/SARIMA, lissage exponentiel, backtest glissant | *standalone Python (statsmodels — le socle que ML-05 suppose)* | 60-75 min | -| 06 | [ML-06-ONNX](ML-06-ONNX.html) | **ONNX Integration** : modèles Python/PyTorch dans .NET | [ML-06-Python](ML-06-ONNX-Python.html) — skl2onnx + onnxruntime (export côté Python du pont inter-langage) | 45-60 min | -| 07 | [ML-07-Recommendation](ML-07-Recommendation.html) | **Recommandation** : Matrix Factorization, collaborative filtering | [ML-07-Python](ML-07-Recommendation-Python.html) — NMF | 45-60 min | -| 08 | [ML-08-Clustering](ML-08-Clustering.html) | **Clustering non-supervisé** : K-Means, segmentation RFM, méthode du coude | [ML-08-Python](ML-08-Clustering-Python.html) — KMeans scikit-learn + méthode du coude | 45-60 min | -| 09 | [ML-09-Anomaly-Detection](ML-09-Anomaly-Detection.html) | **Détection d'anomalies** : Randomized PCA, AUC, seuil de décision | [ML-09-Python](ML-09-Anomaly-Detection-Python.html) — PCA + erreur de reconstruction | 45-60 min | -| 09b | [ML-09b-TSAD-Benchmark-Flaws](ML-09b-TSAD-Benchmark-Flaws-Python.html) | **Introspection des benchmarks** : pourquoi un détecteur de 1924 (SPC `M+3σ`) bat un auto-encodeur, les 4 pièges de Wu & Keogh, UCR Archive | *standalone Python (scikit-learn — anti-dote aux benchmarks triviaux)* | 45-60 min | -| 09c | [ML-09c-MatrixProfile-Multidim](ML-09c-MatrixProfile-Multidim-Python.html) | **Matrix Profile multidimensionnel** : détection sans apprentissage (`stumpy`), condensation `min`/`max`, mSTAMP, l'anomalie répétée que `k=1` cesse de voir | *standalone Python (stumpy — la réponse constructive à ML-09b)* | 45-60 min | +| 05 | [ML-05-TimeSeries](ML-05-TimeSeries.ipynb) | **Time Series Forecasting** avec ForecastBySsa (SSA) | [ML-05-Python](ML-05-TimeSeries-Python.ipynb) — STL + SARIMA | 45-60 min | +| 05b | [ML-05b-Series-Temporelles-Classiques](ML-05b-Series-Temporelles-Classiques-Python.ipynb) | **Socle statistique des séries temporelles** : ADF (stationnarité), ACF/PACF (ordres p/q), ARIMA/SARIMA, lissage exponentiel, backtest glissant | *standalone Python (statsmodels — le socle que ML-05 suppose)* | 60-75 min | +| 06 | [ML-06-ONNX](ML-06-ONNX.ipynb) | **ONNX Integration** : modèles Python/PyTorch dans .NET | [ML-06-Python](ML-06-ONNX-Python.ipynb) — skl2onnx + onnxruntime (export côté Python du pont inter-langage) | 45-60 min | +| 07 | [ML-07-Recommendation](ML-07-Recommendation.ipynb) | **Recommandation** : Matrix Factorization, collaborative filtering | [ML-07-Python](ML-07-Recommendation-Python.ipynb) — NMF | 45-60 min | +| 08 | [ML-08-Clustering](ML-08-Clustering.ipynb) | **Clustering non-supervisé** : K-Means, segmentation RFM, méthode du coude | [ML-08-Python](ML-08-Clustering-Python.ipynb) — KMeans scikit-learn + méthode du coude | 45-60 min | +| 09 | [ML-09-Anomaly-Detection](ML-09-Anomaly-Detection.ipynb) | **Détection d'anomalies** : Randomized PCA, AUC, seuil de décision | [ML-09-Python](ML-09-Anomaly-Detection-Python.ipynb) — PCA + erreur de reconstruction | 45-60 min | +| 09b | [ML-09b-TSAD-Benchmark-Flaws](ML-09b-TSAD-Benchmark-Flaws-Python.ipynb) | **Introspection des benchmarks** : pourquoi un détecteur de 1924 (SPC `M+3σ`) bat un auto-encodeur, les 4 pièges de Wu & Keogh, UCR Archive | *standalone Python (scikit-learn — anti-dote aux benchmarks triviaux)* | 45-60 min | +| 09c | [ML-09c-MatrixProfile-Multidim](ML-09c-MatrixProfile-Multidim-Python.ipynb) | **Matrix Profile multidimensionnel** : détection sans apprentissage (`stumpy`), condensation `min`/`max`, mSTAMP, l'anomalie répétée que `k=1` cesse de voir | *standalone Python (stumpy — la réponse constructive à ML-09b)* | 45-60 min | ### TP Pratique @@ -76,7 +76,7 @@ Le notebook 4 est le plus dense et le plus crucial : évaluation rigoureuse. Vou Le notebook 5 aborde les séries temporelles avec `ForecastBySsa` (Singular Spectrum Analysis), un algorithme qui détecte automatiquement les tendances et saisonnalités. Vous travaillerez sur un dataset de ventes quotidiennes, apprendrez à détecter des anomalies par écart à la moyenne mobile, à quantifier l'incertitude via les intervalles de confiance, et à comparer plusieurs configurations de prévision. Ce notebook est directement applicable à la prévision de ventes, de charge serveur, ou de demande produit. -Le notebook **5b** ([ML-05b-Series-Temporelles-Classiques-Python](ML-05b-Series-Temporelles-Classiques-Python.html)) pose le **socle statistique** que ML-05 suppose : tester la stationnarité (test ADF), lire une ACF/PACF pour identifier les ordres `p`/`q`, ajuster un ARIMA/SARIMA avec **diagnostic des résidus** (ACF plate + Ljung-Box), lisser par Holt-Winters — souvent à égalité avec ARIMA à moindre coût —, et **comparer honnêtement** (ARIMA vs Holt-Winters vs baseline naïve) sur un backtest glissant. C'est le chaînon entre la boîte noire SSA de ML-05 et la famille moderne de prévision (les notebooks HAR de [QuantConnect](../../QuantConnect/) poussent le même socle vers les features et la profondeur). +Le notebook **5b** ([ML-05b-Series-Temporelles-Classiques-Python](ML-05b-Series-Temporelles-Classiques-Python.ipynb)) pose le **socle statistique** que ML-05 suppose : tester la stationnarité (test ADF), lire une ACF/PACF pour identifier les ordres `p`/`q`, ajuster un ARIMA/SARIMA avec **diagnostic des résidus** (ACF plate + Ljung-Box), lisser par Holt-Winters — souvent à égalité avec ARIMA à moindre coût —, et **comparer honnêtement** (ARIMA vs Holt-Winters vs baseline naïve) sur un backtest glissant. C'est le chaînon entre la boîte noire SSA de ML-05 et la famille moderne de prévision (les notebooks HAR de [QuantConnect](../../QuantConnect/) poussent le même socle vers les features et la profondeur). ![Ventes quotidiennes 2023-2024 — série brute avec split Train/Test matérialisé par une ligne pointillée rouge au 2024-01-01](assets/readme/ml-ts-series.png) *Figure extraite du jumeau Python ML-05-TimeSeries-Python (cellule 7, output 0). La série journalière court sur 2023-01 → 2025-01 (deux ans), valeurs de 50 à 250 ventes/jour, avec un split explicite Train/Test au 2024-01-01 (matérialisé en rouge pointillé). On y lit la tendance haussière de fond et la saisonnalité hebdomadaire superposée — les deux ingredients que `ForecastBySsa` et la décomposition STL cherchent à séparer.* @@ -91,7 +91,7 @@ Le notebook 6 présente l'interopérabilité ONNX — le pont entre l'écosystè Le notebook 7 explore les systèmes de recommandation — un domaine où ML.NET brille vraiment en production. Vous implémenterez la factorisation matricielle (collaborative filtering), apprendrez à générer des recommendations Top-N, à mesurer la qualité avec Precision@K et NDCG, et à gérer le "cold start problem" (nouveaux utilisateurs ou items sans historique). Deux exemples concrets : recommandation de films et recommandation e-commerce. -Les notebooks 8 et 9 couvrent l'apprentissage **non-supervisé**. Le notebook 8 (K-Means) partitionne les clients en segments naturels sans étiquettes, via la distance euclidienne — il illustre pourquoi la normalisation y est indispensable. Le notebook 9 (Randomized PCA) répond à une question différente : étant donné un régime de fonctionnement normal, quels points s'en écartent assez pour être des anomalies ? Le cas d'usage est la **maintenance prédictive** (capteurs industriels), et l'accent est mis sur le choix du **seuil de décision** (compromis détection / fausse alarme) — une problématique opérationnelle qui n'apparaît ni en classification (ML-03) ni en clustering (ML-08). Le notebook 10 ([ML-09b-TSAD-Benchmark-Flaws](ML-09b-TSAD-Benchmark-Flaws-Python.html)) pousse la critique plus loin : il montre qu'un détecteur de **1924** (Statistical Process Control, `M+3σ`) bat un auto-encodeur sur un benchmark trivial, identifie les **4 pièges** que Wu & Keogh (2020) imputent aux benchmarks de détection d'anomalies, puis bascule sur l'**UCR Archive** — le benchmark honnête où les méthodes simples échouent enfin. C'est le chaînon entre ML-09 et le Matrix Profile. Le notebook 11 ([ML-09c-MatrixProfile-Multidim](ML-09c-MatrixProfile-Multidim-Python.html)) ferme ce chaînon par une réponse constructive : le Matrix Profile n'a **aucune phase d'entraînement**, donc structurellement rien à surapprendre — et sur une anomalie conjointe dont les trois marginales ne bougent pas, il la classe **première** là où la carte `M+3σ` et l'ACP de ML-09 ne la voient pas du tout. +Les notebooks 8 et 9 couvrent l'apprentissage **non-supervisé**. Le notebook 8 (K-Means) partitionne les clients en segments naturels sans étiquettes, via la distance euclidienne — il illustre pourquoi la normalisation y est indispensable. Le notebook 9 (Randomized PCA) répond à une question différente : étant donné un régime de fonctionnement normal, quels points s'en écartent assez pour être des anomalies ? Le cas d'usage est la **maintenance prédictive** (capteurs industriels), et l'accent est mis sur le choix du **seuil de décision** (compromis détection / fausse alarme) — une problématique opérationnelle qui n'apparaît ni en classification (ML-03) ni en clustering (ML-08). Le notebook 10 ([ML-09b-TSAD-Benchmark-Flaws](ML-09b-TSAD-Benchmark-Flaws-Python.ipynb)) pousse la critique plus loin : il montre qu'un détecteur de **1924** (Statistical Process Control, `M+3σ`) bat un auto-encodeur sur un benchmark trivial, identifie les **4 pièges** que Wu & Keogh (2020) imputent aux benchmarks de détection d'anomalies, puis bascule sur l'**UCR Archive** — le benchmark honnête où les méthodes simples échouent enfin. C'est le chaînon entre ML-09 et le Matrix Profile. Le notebook 11 ([ML-09c-MatrixProfile-Multidim](ML-09c-MatrixProfile-Multidim-Python.ipynb)) ferme ce chaînon par une réponse constructive : le Matrix Profile n'a **aucune phase d'entraînement**, donc structurellement rien à surapprendre — et sur une anomalie conjointe dont les trois marginales ne bougent pas, il la classe **première** là où la carte `M+3σ` et l'ACP de ML-09 ne la voient pas du tout. ![Clustering K-Means sur données RFM — vérité terrain (Dormants/Réguliers/VIP) à gauche, clusters retrouvés par K-Means à droite](assets/readme/ml-clustering.png) *Figure extraite du jumeau Python ML-08-Clustering-Python (cellule 12, output 0). Deux panneaux côte-à-côte : à gauche la vérité terrain (générée par mixture gaussienne puis cachée à l'algorithme), à droite les clusters retrouvés par K-Means (K=3). Les axes sont Frequency (achats/mois, 0-30) × Monetary (EUR, 0-700). Les trois segments Dormants (rouge, <5 achats/mois, <100 EUR), Réguliers (vert, 5-15 achats, 100-300 EUR), VIP (bleu, 15+ achats, 300+ EUR) sont correctement identifiés — limitation illustrative assumée : la figure documente la capacité distinctive de K-Means à retrouver une partition linéairement séparable dans l'espace RFM normalisé, pas les cas réels où les segments se chevauchent ou ne sont pas gaussiens (voir cellules 13-18 du notebook pour les limites et les métriques Davies-Bouldin / silhouette).* @@ -442,17 +442,17 @@ Voir la licence du repository principal. ### Ce que vous avez appris -Cette série vous a fait passer du **premier pipeline ML en C#** ([ML-01](ML-01-Introduction.html)) à une **application complète de bout en bout**, en consolidant trois acquis cibles pour un praticien .NET : +Cette série vous a fait passer du **premier pipeline ML en C#** ([ML-01](ML-01-Introduction.ipynb)) à une **application complète de bout en bout**, en consolidant trois acquis cibles pour un praticien .NET : -- **Construire et justifier un pipeline ML.NET complet** — de `MLContext` au `PredictionEngine`, vous savez enchaîner chargement ([ML-02](ML-02-Data&Features.html)), entraînement ([ML-03](ML-03-Entrainement&AutoML.html)) et prédiction, en laissant l'AutoML explorer l'espace des algorithmes (SDCA, LightGBM) plutôt que de choisir à l'aveugle. -- **Évaluer rigoureusement et expliquer** — [ML-04](ML-04-Evaluation.html) (le notebook le plus dense) vous a armé pour ne plus vous contenter d'un « ça marche » : cross-validation K-fold, R²/MAE/RMSE, Permutation Feature Importance. Un modèle que vous comprenez et pouvez défendre devant un stakeholder, pas seulement un score. -- **Servir en production sans quitter .NET** — les notebooks avancés couvrent les cas où ML.NET excelle en entreprise : prévision par [SSA](ML-05-TimeSeries.html), [interop ONNX](ML-06-ONNX.html) (modèles scikit-learn/PyTorch/Hugging Face consommés en C#), [recommandation](ML-07-Recommendation.html) par factorisation matricielle. Le R&D reste en Python, la production tourne en .NET. +- **Construire et justifier un pipeline ML.NET complet** — de `MLContext` au `PredictionEngine`, vous savez enchaîner chargement ([ML-02](ML-02-Data&Features.ipynb)), entraînement ([ML-03](ML-03-Entrainement&AutoML.ipynb)) et prédiction, en laissant l'AutoML explorer l'espace des algorithmes (SDCA, LightGBM) plutôt que de choisir à l'aveugle. +- **Évaluer rigoureusement et expliquer** — [ML-04](ML-04-Evaluation.ipynb) (le notebook le plus dense) vous a armé pour ne plus vous contenter d'un « ça marche » : cross-validation K-fold, R²/MAE/RMSE, Permutation Feature Importance. Un modèle que vous comprenez et pouvez défendre devant un stakeholder, pas seulement un score. +- **Servir en production sans quitter .NET** — les notebooks avancés couvrent les cas où ML.NET excelle en entreprise : prévision par [SSA](ML-05-TimeSeries.ipynb), [interop ONNX](ML-06-ONNX.ipynb) (modèles scikit-learn/PyTorch/Hugging Face consommés en C#), [recommandation](ML-07-Recommendation.ipynb) par factorisation matricielle. Le R&D reste en Python, la production tourne en .NET. ### Prochaines étapes - **Approfondir l'incertitude** — le [TP capstone](TP-prevision-ventes.ipynb) introduit la régression bayésienne via Infer.NET ; la série [Probas/Infer](../../Probas/Infer/README.md) en est le prolongement natural (même moteur probabiliste, même stack .NET). - **Aller plus loin en ML appliqué** — *Hands-On AI Trading* (cité en Ressources) montre ML.NET en production sur un pipeline de trading réel ; les notebooks [DataScienceWithAgents](../DataScienceWithAgents/README.md) (Python) donnent le contrepoint agentique du même métier. -- **Déployer des LLM/NLP** — [ML-06 ONNX](ML-06-ONNX.html) ouvre la voie : servir BERT, Whisper ou d'autres modèles Hugging Face dans une appli .NET via ONNX Runtime, sans dépendance Python. +- **Déployer des LLM/NLP** — [ML-06 ONNX](ML-06-ONNX.ipynb) ouvre la voie : servir BERT, Whisper ou d'autres modèles Hugging Face dans une appli .NET via ONNX Runtime, sans dépendance Python. ### Le fil rouge diff --git a/MyIA.AI.Notebooks/ML/README.md b/MyIA.AI.Notebooks/ML/README.md index 897974dcfc..814bcffe79 100644 --- a/MyIA.AI.Notebooks/ML/README.md +++ b/MyIA.AI.Notebooks/ML/README.md @@ -67,11 +67,11 @@ Le parcours Python s'articule en trois temps. Les **fondations** (NumPy/Pandas) ### Parcours Data Scientist classique (~12h) -1. [ML-01](ML.Net/ML-01-Introduction.html) → comprendre le pipeline ML +1. [ML-01](ML.Net/ML-01-Introduction.ipynb) → comprendre le pipeline ML 1. [NumPy](DataScienceWithAgents/01-PythonForDataScience/notebooks/1.2-Manipulation_de_Donnees_avec_NumPy.ipynb) + [Pandas](DataScienceWithAgents/01-PythonForDataScience/notebooks/1.3-Analyse_de_Donnees_avec_Pandas.ipynb) → maîtriser les données 1. [Socle ML canonique 2.1 → 2.8](DataScienceWithAgents/02-ML-Cours/) → les fondamentaux scikit-learn (gradient, régressions, ensembles, biais-variance, non supervisé, PAC) -1. [ML-02](ML.Net/ML-02-Data&Features.html) + [ML-03](ML.Net/ML-03-Entrainement&AutoML.html) → entraîner des modèles -1. [ML-04](ML.Net/ML-04-Evaluation.html) → évaluer rigoureusement +1. [ML-02](ML.Net/ML-02-Data&Features.ipynb) + [ML-03](ML.Net/ML-03-Entrainement&AutoML.ipynb) → entraîner des modèles +1. [ML-04](ML.Net/ML-04-Evaluation.ipynb) → évaluer rigoureusement ### Parcours AI Agent Builder (~15h) @@ -81,9 +81,9 @@ Le parcours Python s'articule en trois temps. Les **fondations** (NumPy/Pandas) ### Parcours Enterprise .NET (~6h) -1. [ML-01](ML.Net/ML-01-Introduction.html) à [ML-04](ML.Net/ML-04-Evaluation.html) : fondamentaux ML.NET -1. [ML-05](ML.Net/ML-05-TimeSeries.html) : séries temporelles -1. [ML-06](ML.Net/ML-06-ONNX.html) : interop Python → .NET +1. [ML-01](ML.Net/ML-01-Introduction.ipynb) à [ML-04](ML.Net/ML-04-Evaluation.ipynb) : fondamentaux ML.NET +1. [ML-05](ML.Net/ML-05-TimeSeries.ipynb) : séries temporelles +1. [ML-06](ML.Net/ML-06-ONNX.ipynb) : interop Python → .NET 1. [TP-prevision-ventes](ML.Net/TP-prevision-ventes.ipynb) : projet intégré ## Quel parcours choisir @@ -175,24 +175,24 @@ Pipeline ML.NET complet en C#, de l'introduction à l'évaluation avancée : du | # | Notebook | Contenu | Focus | |---|----------|---------|-------| -| 1 | [ML-01-Introduction](ML.Net/ML-01-Introduction.html) | Hello ML.NET World, pipeline de base | Fondamentaux | -| 1-Py | [ML-01-Introduction-Python](ML.Net/ML-01-Introduction-Python.html) | **Jumeau Python** : pipeline ML.NET ⇄ scikit-learn (régression + classification) | Parité .NET⇄Python | -| 2 | [ML-02-Data&Features](ML.Net/ML-02-Data&Features.html) | IDataView, TextLoader, encodage | Préparation données | -| 2-Py | [ML-02-Data&Features-Python](ML.Net/ML-02-Data&Features-Python.html) | **Jumeau Python** : `IDataView`/Transforms ⇄ `ColumnTransformer`+`Pipeline` (scikit-learn) | Parité .NET⇄Python | -| 3 | [ML-03-Entrainement&AutoML](ML.Net/ML-03-Entrainement&AutoML.html) | SDCA, LightGBM, AutoML + **leaderboard visuel** (Plotly) | Entraînement | -| 3-Py | [ML-03-Entrainement&AutoML-Python](ML.Net/ML-03-Entrainement&AutoML-Python.html) | **Jumeau Python** : SDCA/LightGBM/AutoML ⇄ `LinearRegression`/`GradientBoosting`/`GridSearchCV` | Parité .NET⇄Python | -| 4 | [ML-04-Evaluation](ML.Net/ML-04-Evaluation.html) | Cross-validation, métriques, PFI | Évaluation | -| 4-Py | [ML-04-Evaluation-Python](ML.Net/ML-04-Evaluation-Python.html) | **Jumeau Python** : cross-validation + métriques + PFI ⇄ `cross_val_score` + `permutation_importance` (scikit-learn) | Parité .NET⇄Python | -| 5 | [ML-05-TimeSeries](ML.Net/ML-05-TimeSeries.html) | Forecasts temporelles, windowing | Séries temporelles | -| 5-Py | [ML-05-TimeSeries-Python](ML.Net/ML-05-TimeSeries-Python.html) | **Jumeau Python** : `ForecastBySsa` ⇄ `STL`+`SARIMA` (statsmodels) | Parité .NET⇄Python | -| 6 | [ML-06-ONNX](ML.Net/ML-06-ONNX.html) | Export ONNX, inférence en production | Déploiement | -| 6-Py | [ML-06-ONNX-Python](ML.Net/ML-06-ONNX-Python.html) | **Jumeau Python** : `skl2onnx` export + `onnxruntime` inférence ⇄ `OnnxTransformer` (ML.NET) | Parité .NET⇄Python | -| 7 | [ML-07-Recommendation](ML.Net/ML-07-Recommendation.html) | Système de recommandation | Recommandations | -| 7-Py | [ML-07-Recommendation-Python](ML.Net/ML-07-Recommendation-Python.html) | **Jumeau Python** : `MatrixFactorization` ⇄ `NMF` (scikit-learn) | Parité .NET⇄Python | -| 8 | [ML-08-Clustering](ML.Net/ML-08-Clustering.html) | K-Means, segmentation RFM, méthode du coude | Non-supervisé | -| 8-Py | [ML-08-Clustering-Python](ML.Net/ML-08-Clustering-Python.html) | **Jumeau Python** : `ClusteringCatalog` ⇄ `KMeans` scikit-learn + méthode du coude | Parité .NET⇄Python | -| 9 | [ML-09-Anomaly-Detection](ML.Net/ML-09-Anomaly-Detection.html) | Randomized PCA, AUC, seuil de décision | Détection d'anomalies | -| 9-Py | [ML-09-Anomaly-Detection-Python](ML.Net/ML-09-Anomaly-Detection-Python.html) | **Jumeau Python** : `RandomizedPca` ⇄ `PCA`+résidu (scikit-learn) | Parité .NET⇄Python | +| 1 | [ML-01-Introduction](ML.Net/ML-01-Introduction.ipynb) | Hello ML.NET World, pipeline de base | Fondamentaux | +| 1-Py | [ML-01-Introduction-Python](ML.Net/ML-01-Introduction-Python.ipynb) | **Jumeau Python** : pipeline ML.NET ⇄ scikit-learn (régression + classification) | Parité .NET⇄Python | +| 2 | [ML-02-Data&Features](ML.Net/ML-02-Data&Features.ipynb) | IDataView, TextLoader, encodage | Préparation données | +| 2-Py | [ML-02-Data&Features-Python](ML.Net/ML-02-Data&Features-Python.ipynb) | **Jumeau Python** : `IDataView`/Transforms ⇄ `ColumnTransformer`+`Pipeline` (scikit-learn) | Parité .NET⇄Python | +| 3 | [ML-03-Entrainement&AutoML](ML.Net/ML-03-Entrainement&AutoML.ipynb) | SDCA, LightGBM, AutoML + **leaderboard visuel** (Plotly) | Entraînement | +| 3-Py | [ML-03-Entrainement&AutoML-Python](ML.Net/ML-03-Entrainement&AutoML-Python.ipynb) | **Jumeau Python** : SDCA/LightGBM/AutoML ⇄ `LinearRegression`/`GradientBoosting`/`GridSearchCV` | Parité .NET⇄Python | +| 4 | [ML-04-Evaluation](ML.Net/ML-04-Evaluation.ipynb) | Cross-validation, métriques, PFI | Évaluation | +| 4-Py | [ML-04-Evaluation-Python](ML.Net/ML-04-Evaluation-Python.ipynb) | **Jumeau Python** : cross-validation + métriques + PFI ⇄ `cross_val_score` + `permutation_importance` (scikit-learn) | Parité .NET⇄Python | +| 5 | [ML-05-TimeSeries](ML.Net/ML-05-TimeSeries.ipynb) | Forecasts temporelles, windowing | Séries temporelles | +| 5-Py | [ML-05-TimeSeries-Python](ML.Net/ML-05-TimeSeries-Python.ipynb) | **Jumeau Python** : `ForecastBySsa` ⇄ `STL`+`SARIMA` (statsmodels) | Parité .NET⇄Python | +| 6 | [ML-06-ONNX](ML.Net/ML-06-ONNX.ipynb) | Export ONNX, inférence en production | Déploiement | +| 6-Py | [ML-06-ONNX-Python](ML.Net/ML-06-ONNX-Python.ipynb) | **Jumeau Python** : `skl2onnx` export + `onnxruntime` inférence ⇄ `OnnxTransformer` (ML.NET) | Parité .NET⇄Python | +| 7 | [ML-07-Recommendation](ML.Net/ML-07-Recommendation.ipynb) | Système de recommandation | Recommandations | +| 7-Py | [ML-07-Recommendation-Python](ML.Net/ML-07-Recommendation-Python.ipynb) | **Jumeau Python** : `MatrixFactorization` ⇄ `NMF` (scikit-learn) | Parité .NET⇄Python | +| 8 | [ML-08-Clustering](ML.Net/ML-08-Clustering.ipynb) | K-Means, segmentation RFM, méthode du coude | Non-supervisé | +| 8-Py | [ML-08-Clustering-Python](ML.Net/ML-08-Clustering-Python.ipynb) | **Jumeau Python** : `ClusteringCatalog` ⇄ `KMeans` scikit-learn + méthode du coude | Parité .NET⇄Python | +| 9 | [ML-09-Anomaly-Detection](ML.Net/ML-09-Anomaly-Detection.ipynb) | Randomized PCA, AUC, seuil de décision | Détection d'anomalies | +| 9-Py | [ML-09-Anomaly-Detection-Python](ML.Net/ML-09-Anomaly-Detection-Python.ipynb) | **Jumeau Python** : `RandomizedPca` ⇄ `PCA`+résidu (scikit-learn) | Parité .NET⇄Python | | TP | [TP-prevision-ventes](ML.Net/TP-prevision-ventes.ipynb) | Régression bayésienne (Infer.NET) | Application pratique | #### AutoML : quand le leaderboard bat le `Console.WriteLine` ([#7642](https://github.com/jsboige/CoursIA/pull/7642), [#7707](https://github.com/jsboige/CoursIA/pull/7707), [#7839](https://github.com/jsboige/CoursIA/pull/7839)) @@ -211,13 +211,13 @@ L'écart entre le pire et le meilleur essai est de **338×** — un fait pédago ### Trois figures du track ML.NET (scikit-learn, statsmodels) -[![Régression linéaire (ML-01) : droite de régression verte apprise par scikit-learn superposée aux données d'entraînement (cercles bleus) et de test (carrés oranges) — l'étoile rouge matérialise la prédiction pour une maison de 2,5 milliers de pieds carrés (~2,76 centaines de milliers de dollars).](assets/readme/ml1-intro.png)](ML.Net/ML-01-Introduction-Python.html) +[![Régression linéaire (ML-01) : droite de régression verte apprise par scikit-learn superposée aux données d'entraînement (cercles bleus) et de test (carrés oranges) — l'étoile rouge matérialise la prédiction pour une maison de 2,5 milliers de pieds carrés (~2,76 centaines de milliers de dollars).](assets/readme/ml1-intro.png)](ML.Net/ML-01-Introduction-Python.ipynb) *ML-01 — Régression linéaire prix/surface (scikit-learn). On observe que les points `Test` (oranges) s'éloignent de la droite au-delà de ~4 milliers de pieds carrés : le modèle linéaire sous-extrapole les grandes maisons, ce que la métrique R² seule ne signalera pas.* -[![Décomposition STL d'une série temporelle de ventes (ML-05) : quatre panneaux superposés — Observé (oscillations bruitées entre ~60 et ~190), Tendance (courbe orange lisse montant de ~110 début 2023 à ~160 fin 2023), Saisonnalité (sinusoïde verte d'amplitude ~40, période 7 jours), Bruit (résidu rouge, amplitude ~±25).](assets/readme/ml5-timeseries.png)](ML.Net/ML-05-TimeSeries-Python.html) +[![Décomposition STL d'une série temporelle de ventes (ML-05) : quatre panneaux superposés — Observé (oscillations bruitées entre ~60 et ~190), Tendance (courbe orange lisse montant de ~110 début 2023 à ~160 fin 2023), Saisonnalité (sinusoïde verte d'amplitude ~40, période 7 jours), Bruit (résidu rouge, amplitude ~±25).](assets/readme/ml5-timeseries.png)](ML.Net/ML-05-TimeSeries-Python.ipynb) *ML-05 — Décomposition STL (`statsmodels.tsa.seasonal_decompose`, période 7). La saisonnalité hebdomadaire se lit immédiatement (amplitude ±40), et la tendance capture la croissance sous-jacente (~+50 sur 12 mois). Le TP-prevision-ventes s'appuie sur ce découpage pour combiner signal et saisonnalité.* -[![Clustering K-Means (ML-08) en deux panneaux : à gauche la vérité terrain (3 segments Dormants/Réguliers/VIP sur l'axe Frequency × Monetary) ; à droite les clusters 0/1/2 retrouvés par K-Means — on observe que les labels K-Means ne s'alignent PAS avec les segments sémantiques (Cluster 0 ≠ Dormants) : K-Means segmente l'espace géométrique, pas la sémantique métier.](assets/readme/ml8-clustering.png)](ML.Net/ML-08-Clustering-Python.html) +[![Clustering K-Means (ML-08) en deux panneaux : à gauche la vérité terrain (3 segments Dormants/Réguliers/VIP sur l'axe Frequency × Monetary) ; à droite les clusters 0/1/2 retrouvés par K-Means — on observe que les labels K-Means ne s'alignent PAS avec les segments sémantiques (Cluster 0 ≠ Dormants) : K-Means segmente l'espace géométrique, pas la sémantique métier.](assets/readme/ml8-clustering.png)](ML.Net/ML-08-Clustering-Python.ipynb) *ML-08 — Clustering K-Means sur données RFM (scikit-learn). Le notebook démontre la **limitation sémantique** du K-Means non supervisé : les segments de clientèle (Dormants/Réguliers/VIP) sont des catégories métier, pas des clusters géométriques. La concordance parfaite n'est possible que par chance — d'où l'intérêt d'un *mapping* a posteriori (et des méthodes supervisées dès qu'on connaît les segments).* ## Python Data Science with Agents diff --git a/MyIA.AI.Notebooks/Probas/Applications/Percolation/README.md b/MyIA.AI.Notebooks/Probas/Applications/Percolation/README.md index 63e6aecde1..1106e8260b 100644 --- a/MyIA.AI.Notebooks/Probas/Applications/Percolation/README.md +++ b/MyIA.AI.Notebooks/Probas/Applications/Percolation/README.md @@ -11,8 +11,8 @@ critique** (p ≈ p_c). Simulation-first : on fait *voir* les trois régimes | Composant | Notebook | Stack | Ce qu'il apporte | |-----------|----------|-------|------------------| -| [Percolation-01-Supercritique-Python](Percolation-01-Supercritique-Python.html) | 1 (Python) | Python 3 + `networkx` | Tore carré (degré 4, `p_c(bond, ℤ²) = 1/2`) et tore hexagonal (degré 3, `p_c ≈ 0.6527`) — trois régimes mesurés, géant du tore, vitesse de disparition `Φ(n) ~ √n` | -| [Percolation-02-Lean](Percolation-02-Lean.html) | 2 (Lean 4) | Lean 4 + Mathlib (`percolation_lean`) | Compagnon exécutable du lake : configurations d'arêtes ouvertes, Harris–Kleitman fini, connexité croissante, composantes, frontière isopérimétrique avec profil calculé sur `C₃`/`C₄` | +| [Percolation-01-Supercritique-Python](Percolation-01-Supercritique-Python.ipynb) | 1 (Python) | Python 3 + `networkx` | Tore carré (degré 4, `p_c(bond, ℤ²) = 1/2`) et tore hexagonal (degré 3, `p_c ≈ 0.6527`) — trois régimes mesurés, géant du tore, vitesse de disparition `Φ(n) ~ √n` | +| [Percolation-02-Lean](Percolation-02-Lean.ipynb) | 2 (Lean 4) | Lean 4 + Mathlib (`percolation_lean`) | Compagnon exécutable du lake : configurations d'arêtes ouvertes, Harris–Kleitman fini, connexité croissante, composantes, frontière isopérimétrique avec profil calculé sur `C₃`/`C₄` | | [Percolation-03-Critique-Python](Percolation-03-Critique-Python.ipynb) | 3 (Python) | Python 3 + `networkx` | Physique du point critique : loi d'échelle finie `M(L, 1/2)/L² ~ L^{-β/ν}`, distribution de tailles `P(s) ~ s^{-τ'}`, convergence `p_c(L) → 1/2`. Sweep `L ∈ {8,16,32,64}` × `p ∈ {0.45,…,0.55}` × 32 seeds = 640 simulations `networkx.connected_components` canonique | | [Percolation-03b-Critique-L128-L256](Percolation-03b-Critique-L128-L256.ipynb) | 3b (Python) | Python 3 + `networkx` | Extension du carnet 03 aux tailles `L ∈ {128, 256}` pour la convergence asymptotique. Fit log-log sur 6 points (L = 8, 16, 32, 64, 128, 256) : β/ν = 0.1065, τ' = 2.188, p_c(L) → 1/2 monotone. Sweep `L ∈ {128, 256}` × `p ∈ {0.45,…,0.55}` × 32 seeds = 320 simulations ~48 s | | [Percolation-03c-Critique-L512](Percolation-03c-Critique-L512.ipynb) | 3c (Python) | Python 3 + `networkx` | Extension du carnet 03b à L = 512 pour la convergence asymptotique. Fit log-log sur 7 points (L = 8, 16, 32, 64, 128, 256, 512) : β/ν = 0.1062 (cible 0.1042, R²=0.977, std_err=0.007 — convergence asymptotique bloquée aux corrections d'échelle finie), p_c(L) → 1/2 monotone (écart 0.0013 à L=512). Sweep `L = 512` × `p ∈ {0.45,…,0.55}` × 32 seeds = 160 simulations ~186 s | diff --git a/MyIA.AI.Notebooks/Probas/Applications/README.md b/MyIA.AI.Notebooks/Probas/Applications/README.md index 005ed9378a..b58d41b54d 100644 --- a/MyIA.AI.Notebooks/Probas/Applications/README.md +++ b/MyIA.AI.Notebooks/Probas/Applications/README.md @@ -9,8 +9,8 @@ progressions vivent dans [`../Infer/`](../Infer/README.md), | Notebook | Kernel | Sujet | |---|---|---| | [`Pyro_RSA_Hyperbole.ipynb`](Pyro_RSA_Hyperbole.ipynb) | Python 3 | Rational Speech Acts bayésien en Pyro — pragmatique linguistique, implicatures scalaires, hyperboles | -| [`Percolation/Percolation-01-Supercritique-Python.ipynb`](Percolation/Percolation-01-Supercritique-Python.html) | Python 3 | Percolation de liens sur tore fini — simulation, trois régimes mesurés | -| [`Percolation/Percolation-02-Lean.ipynb`](Percolation/Percolation-02-Lean.html) | Lean 4 (WSL) | Compagnon exécutable du lake `percolation_lean` — noyau fini prouvé sans `sorry` | +| [`Percolation/Percolation-01-Supercritique-Python.ipynb`](Percolation/Percolation-01-Supercritique-Python.ipynb) | Python 3 | Percolation de liens sur tore fini — simulation, trois régimes mesurés | +| [`Percolation/Percolation-02-Lean.ipynb`](Percolation/Percolation-02-Lean.ipynb) | Lean 4 (WSL) | Compagnon exécutable du lake `percolation_lean` — noyau fini prouvé sans `sorry` | Le dossier [`Percolation/`](Percolation/README.md) a son README détaillé (duo simulation + formalisation, adossé à [l'issue #14871](https://github.com/jsboige/CoursIA/issues/14871)). diff --git a/MyIA.AI.Notebooks/Probas/README.md b/MyIA.AI.Notebooks/Probas/README.md index 7c299e7e27..15899db1ef 100644 --- a/MyIA.AI.Notebooks/Probas/README.md +++ b/MyIA.AI.Notebooks/Probas/README.md @@ -21,7 +21,7 @@ L'**arc décision** ([`DecisionTheory/DecInfer/`](DecisionTheory/DecInfer/README Le versant **PyMC** porte ces modèles en Python avec l'échantillonnage NUTS : le **corpus bayésien PyMC** ([`PyMC/`](PyMC/README.md), en miroir de l'arc Infer — paires numérotées, la paire de debugging étant `PyMC-02b` ↔ `Infer-2b` (toutes deux accrétions 2b, cf renommage #17808) ; fondations, modèles classiques, inférence causale, puis frontières : séquences, reco, processus gaussien épars, filtre de Kalman, change-point, survie) et les **miroirs de l'arc décision** ([`DecisionTheory/DecPyMC/`](DecisionTheory/DecPyMC/README.md), renumérotés, dont la **jambe actuarielle** 8-12). -La **percolation** ([`Applications/Percolation/`](Applications/Percolation/README.md)) complète ce trio Lean avec [`Percolation-02-Lean`](Applications/Percolation/Percolation-02-Lean.html) (noyau fini prouvé sans `sorry`, compagnon du lake `percolation_lean`), jumeau de la simulation Python [`Percolation-01-Supercritique-Python`](Applications/Percolation/Percolation-01-Supercritique-Python.html) (trois régimes mesurés). +La **percolation** ([`Applications/Percolation/`](Applications/Percolation/README.md)) complète ce trio Lean avec [`Percolation-02-Lean`](Applications/Percolation/Percolation-02-Lean.ipynb) (noyau fini prouvé sans `sorry`, compagnon du lake `percolation_lean`), jumeau de la simulation Python [`Percolation-01-Supercritique-Python`](Applications/Percolation/Percolation-01-Supercritique-Python.ipynb) (trois régimes mesurés). Enfin, un **pont causal** ([`DecisionTheory/Causal-Bridges/`](DecisionTheory/Causal-Bridges/README.md), kernels `python3` et `coursia-ml-training`) fédère les quatre traitements de la causalité disséminés dans le dépôt — Tweety (logique), Infer.NET, PyMC et l'émergence causale (PyPhi) — autour de l'échelle de Pearl et du do-calculus. Sur l'outil de référence [`dowhy`](https://www.pywhy.org/dowhy/), le pont identifie l'estimande (backdoor, front-door, variable instrumentale), l'estime puis le réfute ; il monte au troisième échelon de Pearl (contrefactuel individuel), couvre les méthodes quasi-expérimentales (DiD, contrôle synthétique, RDD), et pousse chaque hypothèse d'identification dans ses retranchements : découverte de structure quand le graphe manque (`causal-learn` : PC, GES, LiNGAM — CausalBridges-04, ex-DoWhy-3), sensibilité au confondeur caché (robustness value, E-value, Rosenbaum — CausalBridges-05, ex-DoWhy-4) et instrument faible (F-stat, biais IV vs OLS — CausalBridges-06, ex-DoWhy-5). @@ -400,7 +400,7 @@ La causalité est traitée à **quatre endroits** du dépôt, chacun avec son mo | [CausalBridges-05 — Le confondeur non observé](DecisionTheory/Causal-Bridges/CausalBridges-05-Dowhy-Sensibilite-Confounder.ipynb) | ~50 min | Sensibilité, pas certitude : robustness value de Cinelli-Hazlett (`linear-partial-R2`), **E-value natif** `dowhy`, bornes de Rosenbaum exactes (Γ*), courbe de bascule du confondeur simulé | | [CausalBridges-06 — L'instrument faible](DecisionTheory/Causal-Bridges/CausalBridges-06-Dowhy-Instrument-Faible.ipynb) | ~45 min | Variable instrumentale via `dowhy` (pipeline `identify` + `estimate(iv)` + `refute`) ; F-stat Staiger-Stock, biais IV vs OLS en Monte-Carlo, **verdict NON_IDENTIFIABLE** honnête sur exclusion violée | | [CausalBridges-07 — Quasi-Experimental](DecisionTheory/Causal-Bridges/CausalBridges-07-Quasi-Experimental.ipynb) | ~50 min | Méthodes quasi-expérimentales (DiD, contrôle synthétique, RDD, variables instrumentales) sur données réalistes ; estimands et hypothèses d'identification explicités | -| [CausalBridges-08 — Décomposer la discrimination](DecisionTheory/Causal-Bridges/CausalBridges-08-Causal-Fairness.html) | ~50 min | Équité causale : critères structurels Str-DE/IE/SE, famille TV (TE, Exp-SE, NDE, NIE) — Lem 4.1 et Thm 4.2 vérifiés avec `dowhy` sur données de crédit | +| [CausalBridges-08 — Décomposer la discrimination](DecisionTheory/Causal-Bridges/CausalBridges-08-Causal-Fairness.ipynb) | ~50 min | Équité causale : critères structurels Str-DE/IE/SE, famille TV (TE, Exp-SE, NDE, NIE) — Lem 4.1 et Thm 4.2 vérifiés avec `dowhy` sur données de crédit | | Série | Moteur | Angle causal | |-------|--------|--------------| @@ -447,8 +447,8 @@ Protocole de **représentation** — et non d'inférence : deux observations d'u Duo simulation + formalisation autour de la percolation de liens sur tore fini (Diskin–Easo–Radhakrishnan–Sudakov–Tassion, arXiv:2603.03257) : -[`Percolation-01-Supercritique-Python`](Applications/Percolation/Percolation-01-Supercritique-Python.html) (Python, trois régimes mesurés) et -[`Percolation-02-Lean`](Applications/Percolation/Percolation-02-Lean.html) (Lean 4, compagnon exécutable du lake `percolation_lean`, noyau fini prouvé sans `sorry`) — +[`Percolation-01-Supercritique-Python`](Applications/Percolation/Percolation-01-Supercritique-Python.ipynb) (Python, trois régimes mesurés) et +[`Percolation-02-Lean`](Applications/Percolation/Percolation-02-Lean.ipynb) (Lean 4, compagnon exécutable du lake `percolation_lean`, noyau fini prouvé sans `sorry`) — voir [`Applications/Percolation/README.md`](Applications/Percolation/README.md) et #14871. ## Carnets transverses (racine de la série) @@ -647,9 +647,9 @@ Cette série ancre mathématiquement ses résultats phares dans un assistant de | --- | --- | --- | --- | | Probas (DecisionTheory) | `decision_theory_lean` | Axiomes de Von Neumann-Morgenstern ⇒ existence d'une utilité espérée (`0 sorry`) | [`DecInfer-02-Lean-ExpectedUtility`](DecisionTheory/DecInfer/DecInfer-02-Lean-ExpectedUtility.ipynb) | | Probas (DecisionTheory) | `decision_theory_lean` | Coherence utility ⟹ preferences (loterie de référence) (`0 sorry`) | [`DecisionTheory/DecInfer/`](DecisionTheory/DecInfer/README.md) Coherence | -| ML ↔ Probas (PAC Learning) | [`learning_theory_lean`](../ML/learning_theory_lean/) | `pac_finite_class_bound` + `pac_agnostic_generalization` (`0 sorry bout-en-bout`) | [`2.8-Theorie-PAC`](../ML/DataScienceWithAgents/02-ML-Cours/2.8-Theorie-PAC.html) + [`2.8b-Theorie-PAC-Lean`](../ML/DataScienceWithAgents/02-ML-Cours/2.8b-Theorie-PAC-Lean.html) | +| ML ↔ Probas (PAC Learning) | [`learning_theory_lean`](../ML/learning_theory_lean/) | `pac_finite_class_bound` + `pac_agnostic_generalization` (`0 sorry bout-en-bout`) | [`2.8-Theorie-PAC`](../ML/DataScienceWithAgents/02-ML-Cours/2.8-Theorie-PAC.ipynb) + [`2.8b-Theorie-PAC-Lean`](../ML/DataScienceWithAgents/02-ML-Cours/2.8b-Theorie-PAC-Lean.ipynb) | | Probas (DecisionTheory) | `decision_theory_lean` Peters | Indice de Gittins, identités d'escompte (`0 sorry`, ref `v4.27.0-rc1`) | [`DecInfer-08b-Lean-Gittins`](DecisionTheory/DecInfer/DecInfer-08b-Lean-Gittins.ipynb) | -| QC ↔ Probas | `kelly_lean` | Fraction risquée `f* = μ−σ²/2` sous log-bienveillance (`0 sorry`) | [`Kelly_companion-Python.ipynb`](../QuantConnect/kelly_lean/Kelly_companion-Python.html) | +| QC ↔ Probas | `kelly_lean` | Fraction risquée `f* = μ−σ²/2` sous log-bienveillance (`0 sorry`) | [`Kelly_companion-Python.ipynb`](../QuantConnect/kelly_lean/Kelly_companion-Python.ipynb) | | GameTheory ↔ Probas | `game_theory_lean` (Arrow) | Impossibilité d'Arrow (5 axiomes ⇒ dictature) | [`01-Arrow-Impossibility-Theorem.ipynb`](../GameTheory/SocialChoice/01-Arrow-Impossibility-Theorem.ipynb) | | Search ↔ Probas | `search_lean` | Consistance heuristique `h ≤ h*` ⇒ optimalité `A*` | hub Search (cf [`search_lean/`](../Search/search_lean/)) | | SymbolicAI ↔ Probas | `argumentation_lean` | Extension Dung (`grounded`/`preferred`/`stable`) par cadre formel | [`Argumentation-03-Dung-AF-Semantics-Python.ipynb`](../SymbolicAI/Argument_Analysis/Argumentation-03-Dung-AF-Semantics-Python.ipynb) | diff --git a/MyIA.AI.Notebooks/QuantConnect/Python/README.md b/MyIA.AI.Notebooks/QuantConnect/Python/README.md index 956aeb0110..031a3f647d 100644 --- a/MyIA.AI.Notebooks/QuantConnect/Python/README.md +++ b/MyIA.AI.Notebooks/QuantConnect/Python/README.md @@ -198,7 +198,7 @@ Chaque notebook de la série rend visible un geste quantitatif distinct, dans un | [QC-Py-27-Production-Deployment](QC-Py-27-Production-Deployment.ipynb) | Déploiement live, monitoring | | [QC-Py-28-Market-Regime-Detection](QC-Py-28-Market-Regime-Detection.ipynb) | Détection de régimes de marché | | [QC-Py-28b-Macro-Cycle-Regimes](QC-Py-28b-Macro-Cycle-Regimes.ipynb) | Macro et régimes : diagnostic composite borné, indicateurs → budget de risque | -| [QC-Py-28c-Factor-Preprocessing-Regime](QC-Py-28c-Factor-Preprocessing-Regime.html) | Prétraitement de facteurs (FFD, standardisation, ACP) pour la détection de régime — port du livre 06/02, comparaison à la classe majoritaire | +| [QC-Py-28c-Factor-Preprocessing-Regime](QC-Py-28c-Factor-Preprocessing-Regime.ipynb) | Prétraitement de facteurs (FFD, standardisation, ACP) pour la détection de régime — port du livre 06/02, comparaison à la classe majoritaire | | [QC-Py-29-Derivatives-Valuation](QC-Py-29-Derivatives-Valuation.ipynb) | Valorisation d'un dérivé : Black-Scholes, arbre binomial et Monte-Carlo sur le même contrat — précision, convergence, flexibilité, coût, liquidité | ## Entraînement ML (QC-Py-30 à 32) diff --git a/MyIA.AI.Notebooks/QuantConnect/kelly_lean/README.md b/MyIA.AI.Notebooks/QuantConnect/kelly_lean/README.md index 78b7ee9a62..014307109a 100644 --- a/MyIA.AI.Notebooks/QuantConnect/kelly_lean/README.md +++ b/MyIA.AI.Notebooks/QuantConnect/kelly_lean/README.md @@ -128,8 +128,8 @@ lakes frères) ; deux notebooks compagnons le rendent pédagogique : | Notebook | Rôle | |---|---| -| [`Kelly_companion-Python.ipynb`](Kelly_companion-Python.html) | **Volet numérique (Python)** : montre, côte à côte avec les théorèmes prouvés, pourquoi `f*` maximise le taux de croissance espéré `g(f)` et pourquoi tout sur-pari (`f > f*`) ou sous-pari (`f < f*`) est strictement sous-optimal — narration économique, figures et lien trading. | -| [`Kelly_companion-Lean.ipynb`](Kelly_companion-Lean.html) | **Jumeau à kernel Lean 4** : chaque énoncé du lake est importé et vérifié par le noyau Lean lui-même (`#check`, `#print axioms`, exemples re-prouvés en cellule) — les énoncés qui compilent, pas la prose recopiée. | +| [`Kelly_companion-Python.ipynb`](Kelly_companion-Python.ipynb) | **Volet numérique (Python)** : montre, côte à côte avec les théorèmes prouvés, pourquoi `f*` maximise le taux de croissance espéré `g(f)` et pourquoi tout sur-pari (`f > f*`) ou sous-pari (`f < f*`) est strictement sous-optimal — narration économique, figures et lien trading. | +| [`Kelly_companion-Lean.ipynb`](Kelly_companion-Lean.ipynb) | **Jumeau à kernel Lean 4** : chaque énoncé du lake est importé et vérifié par le noyau Lean lui-même (`#check`, `#print axioms`, exemples re-prouvés en cellule) — les énoncés qui compilent, pas la prose recopiée. | ## Carnets suivants diff --git a/MyIA.AI.Notebooks/QuantConnect/projects/ML-RandomForest/README.md b/MyIA.AI.Notebooks/QuantConnect/projects/ML-RandomForest/README.md index 117f0c2e2c..5d06607fa3 100644 --- a/MyIA.AI.Notebooks/QuantConnect/projects/ML-RandomForest/README.md +++ b/MyIA.AI.Notebooks/QuantConnect/projects/ML-RandomForest/README.md @@ -76,7 +76,7 @@ Le CAGR de 24.25 % semble élevé, mais **trois caveats §C** l'attenent sévèr ## Figures du notebook de recherche -Le notebook [`research.ipynb`](research.html) teste cinq hypothèses sur les hyperparamètres du Random Forest — nombre d'estimateurs, profondeur maximale, seuil de prédiction, taille de l'univers et fréquence d'entraînement — puis synthétise l'importance des features. Provenance détaillée : [`MANIFEST.md`](assets/readme/MANIFEST.md). +Le notebook [`research.ipynb`](research.ipynb) teste cinq hypothèses sur les hyperparamètres du Random Forest — nombre d'estimateurs, profondeur maximale, seuil de prédiction, taille de l'univers et fréquence d'entraînement — puis synthétise l'importance des features. Provenance détaillée : [`MANIFEST.md`](assets/readme/MANIFEST.md). > **Lecture critique** : les « optimaux » identifiés par ce sweep (depth=10, Universe=5) sont des **artefacts d'overfitting sur le bull run Mag7**, comme l'atteste le choix de production v3 (depth=5, Universe=10). Les lire comme des victoires serait se tromper soi-même ; les lire comme des **warnings** (« ici le modèle mémorise le bruit ») est la bonne interprétation pédagogique. diff --git a/MyIA.AI.Notebooks/QuantConnect/projects/RiskParity/README.md b/MyIA.AI.Notebooks/QuantConnect/projects/RiskParity/README.md index 4fd32c56d0..dfdb56f82c 100644 --- a/MyIA.AI.Notebooks/QuantConnect/projects/RiskParity/README.md +++ b/MyIA.AI.Notebooks/QuantConnect/projects/RiskParity/README.md @@ -31,9 +31,9 @@ Hors échantillon, sans refus, le correctif ne change aucun ordre. Sur la fenêt ## Figures du notebook de recherche -Le notebook [`research.ipynb`](research.html) documente l'analyse complète de la parité de risque : exploration des actifs, inverse-volatility weighting (H1), backtest (H2), impact de TLT en 2020-2023 (H3), sensibilité au lookback de volatilité (H4) et analyse par régime de marché. La stratégie atteint un plafond structurel (Sharpe 0.544) — contre-exemple pédagogique. Provenance détaillée : [`MANIFEST.md`](assets/readme/MANIFEST.md). +Le notebook [`research.ipynb`](research.ipynb) documente l'analyse complète de la parité de risque : exploration des actifs, inverse-volatility weighting (H1), backtest (H2), impact de TLT en 2020-2023 (H3), sensibilité au lookback de volatilité (H4) et analyse par régime de marché. La stratégie atteint un plafond structurel (Sharpe 0.544) — contre-exemple pédagogique. Provenance détaillée : [`MANIFEST.md`](assets/readme/MANIFEST.md). -Le QuantBook [`quantbook.ipynb`](quantbook.html) reproduit cette analyse exploratoire sur les données natives QuantConnect (pondération inverse-volatilité). +Le QuantBook [`quantbook.ipynb`](quantbook.ipynb) reproduit cette analyse exploratoire sur les données natives QuantConnect (pondération inverse-volatilité). **Exploration — l'analyse des actifs (§2).** Le **dual-panel** juxtapose la courbe « Rendements cumulés 2015-2026 » sur 6 actifs (SPY/EFA/GLD/DBC/TLT) avec la heatmap de la matrice de corrélation. Les stats annualisées cell[4]·out[1] révèlent **GLD = meilleur Sharpe 0.81** (CAGR 12.02 %) avec **corrélation SPY 0.04** — diversifieur clé du portefeuille, tandis que **DBC sous-performe** (Sharpe 0.20, CAGR 3.45 %). La lecture visuelle confirme que GLD est l'actif qui contribue le plus à la diversification : l'inverse-vol weighting amplifie mécaniquement sa pondération face aux actifs les plus risqués. diff --git a/MyIA.AI.Notebooks/RL/README.md b/MyIA.AI.Notebooks/RL/README.md index 835b17434d..c79c994828 100644 --- a/MyIA.AI.Notebooks/RL/README.md +++ b/MyIA.AI.Notebooks/RL/README.md @@ -43,41 +43,41 @@ Le RL se comprend mieux en voyant l'agent apprendre. Six visualisations suivent | # | Notebook | Contenu | Durée | |---|----------|---------|-------| -| 1 | [RL-01-Premiers-Pas-Stable-Baselines3-Python](RL-01-Premiers-Pas-Stable-Baselines3-Python.html) | Introduction PPO, CartPole | 25-30 min | -| 1b | [RL-01b-Synthese-Logique-Bitwise-Python](RL-01b-Synthese-Logique-Bitwise-Python.html) | Synthèse logique d'un contrôleur CartPole : bitwise 4-règles — scellement observation→bits IEEE-754, contrôleur LQR de référence (taux de désaccord), PPO budget modeste, étude de rupture et ablation. Accrétion de RL-01 | 20-25 min | -| 1c | [RL-01c-Distillation-Politique-Prolog-Python](RL-01c-Distillation-Politique-Prolog-Python.html) | Distillation d'une politique RL en programme Prolog exécutable : teacher PPO from scratch (seed fixe), census exhaustif de T-bar, induction gloutonne type FOIL, liste de décision avec cuts, one-pass vs DAgger, SWI-Prolog réel journalisé. Accrétion de RL-01 | 45-60 min | -| 2 | [RL-02-Wrappers-Sauvegarde-Callbacks-Python](RL-02-Wrappers-Sauvegarde-Callbacks-Python.html) | Wrappers, sauvegarde, callbacks | 35-40 min | -| 3 | [RL-03-Experience-Replay-HER-Python](RL-03-Experience-Replay-HER-Python.html) | HER, goal-conditioned RL | 40-45 min | -| 4 | [RL-04-Bandits-Manchots-Python](RL-04-Bandits-Manchots-Python.html) | Bandits manchots, exploration vs exploitation, Thompson Sampling | 30-35 min | -| 5 | [RL-05-MDP-Programmation-Dynamique-Q-Learning-Python](RL-05-MDP-Programmation-Dynamique-Q-Learning-Python.html) | MDP, Value/Policy Iteration, Q-Learning tabulaire | 45-50 min | -| 6 | [RL-06-DQN-Policy-Gradient-Python](RL-06-DQN-Policy-Gradient-Python.html) | DQN depuis zéro, REINFORCE | 50-55 min | -| 6b | [RL-06b-Actor-Critic-Python](RL-06b-Actor-Critic-Python.html) | Actor-Critic (A2C) depuis zéro, advantage, entropy bonus | 45-50 min | -| 6c | [RL-06c-PPO-Depuis-Zero-Python](RL-06c-PPO-Depuis-Zero-Python.html) | PPO depuis zéro, échantillonnage d'importance (ratios par epoch, ESS), clipped surrogate, GAE, comparaison A2C vs PPO | 45-50 min | -| 6d | [RL-06d-SAC-Depuis-Zero-Python](RL-06d-SAC-Depuis-Zero-Python.html) | SAC depuis zéro, maximum entropy RL, twin Q-networks, auto-température | 45-50 min | -| 6e | [RL-06e-GRPO-Depuis-Zero-Python](RL-06e-GRPO-Depuis-Zero-Python.html) | GRPO depuis zéro (DeepSeek-R1), avantage relatif intra-groupe (sans critic), clip PPO + KL vs référence, portefeuille synthétique multi-seed | 45-50 min | -| 7 | [RL-07-Apprentissage-Multi-Agent-Python](RL-07-Apprentissage-Multi-Agent-Python.html) | Multi-Agent RL, PettingZoo, IQL | 45-50 min | -| 7b | [RL-07b-Sur-Generalisation-Climbing-Game-Python](RL-07b-Sur-Generalisation-Climbing-Game-Python.html) | Sur-généralisation relative dans le Climbing Game coopératif : même agent tabulaire, IQL vs Hysteretic Q-learning, protocole multi-graines, IQM + intervalle bootstrap, ablation du pessimisme | ~45 min | -| 8 | [RL-08-Dyna-Q-Planification-Python](RL-08-Dyna-Q-Planification-Python.html) | Model-based RL : Dyna-Q, Dyna-Q+, planification, rollouts | 45-50 min | -| 9 | [RL-09-RL-Offline-Behavior-Cloning-Python](RL-09-RL-Offline-Behavior-Cloning-Python.html) | RL offline : Behavior Cloning, erreur d'extrapolation, BCQ-lite | 50-55 min | -| 10 | [RL-10-Reward-Shaping-Curriculum-Python](RL-10-Reward-Shaping-Curriculum-Python.html) | Reward Shaping (Ng 1999), curriculum learning, pont RLHF | 45-50 min | -| 11 | [RL-11-POMDP-Croyances-Python](RL-11-POMDP-Croyances-Python.html) | POMDP, Tiger Problem, belief tracking, Q-MDP | 45-50 min | -| 12 | [RL-12-Distributional-RL-C51-Python](RL-12-Distributional-RL-C51-Python.html) | RL distributionnel : C51 (Categorical DQN) depuis zéro, projection catégorielle, politique CVaR | 50-55 min | -| 13 | [RL-13-Curiosite-RND-Python](RL-13-Curiosite-RND-Python.html) | Exploration par curiosité (RND), motivation intrinsèque, piège d'exploitation | 35-40 min | -| 14 | [RL-14-RL-Hierarchique-Options-Python](RL-14-RL-Hierarchique-Options-Python.html) | Hierarchical RL — l'Option framework de Sutton, Precup & Singh : abstraction temporelle, options `(I, π, β)`, gridworld quatre-pièces, crédit sur longue horizon | ~50 min | -| 15 | [RL-15-GRPO-Comparatif-Multi-Graines-Python](RL-15-GRPO-Comparatif-Multi-Graines-Python.html) | GRPO (Group Relative Policy Optimization) vs PPO sur CartPole-v1 — avantage relatif intra-groupe (sans critic) vs GAE bootstrapé, multi-seed 6 (0/1/7/42/99/123), Wilcoxon signed-rank + IC95% bootstrap. Prong B discrimination moteur. Sous-grain #13436 de l'EPIC #1454. **Verdict v3 (REPAIR c.644) : INCONCLUSIVE** (le claim initial v1 « GRPO BEATS PPO » souffrait de défauts done-mask + pad-mask — c.642 a corrigé en INCONCLUSIVE, puis c.644 a détecté 4 post-fix incohérences résolues : Wilcoxon n=4 inatteignable, verdict tri-state asymmétrique, hypothèse descriptive fausse réfutée, titre PR ré-aligné — verdict v3 INCONCLUSIVE maintenu, moyennes v3 = 299.36 vs 197.65, std = 55.26 vs 104.99) | 40-45 min | -| 16 | [RL-16-Dream-RSI-Python](RL-16-Dream-RSI-Python.html) | Dream-RSI (arXiv 2609.14858, preprint 14/09/2026) : exploration explicite **programmable** (politique = code), historique de découverte = simulateur-replay, **dreaming** = évaluation off-policy à coût zéro, boucle RSI avec incumbent (garantie non-régression replay-only) — monde jouet circle-packing stdlib (16 cercles), ablation replay brut vs guidance sémantique mesurée (3/2/7), chiffres du papier rapportés non canonisés. Distillation #16417 | 40-45 min | -| 19 | [RL-19-Reward-Tampering-Python](RL-19-Reward-Tampering-Python.html) | Reward tampering : l'agent qui peut **réécrire** sa récompense — *Rocks and Diamonds* à paramètre θ modifiable (exemple 2 d'Everitt et al., Synthese 2021), quatre agents résolus par **induction arrière exacte** sur 32 252 états (standard, oracle, *current-RF* TI-ignoring et TI-considering) : les trois prédictions du papier mesurées `conforme`. Au-delà du diagramme : **l'indifférence n'est pas la protection** — valeur de l'option de manipuler +16 (standard) contre +0 (TI-ignoring), mais départage aléatoire des égalités → manipulation 33/200 (H = 30) et 68/200 (H = 60), toujours après la tâche ; Q-learning standard 0/5 graines en initialisation nulle, 5/5 en optimiste. RF-input tampering (autocollants sur la caméra) : 88 observé / 0 réel contre 20 / 20 sous récompense sur croyance. Distillation #14468 | 35-40 min | -| pt-0 | [RLPT-00-Reward-Model-Bradley-Terry-Python](PostTraining/RLPT-00-Reward-Model-Bradley-Terry-Python.html) | Reward model from scratch (Bradley-Terry) : apprendre r(x, y) depuis des paires de préférences sur le monde de RLPT-01 — MLE BT sans `trl.RewardTrainer`, évaluation honnête vs plafond de Bayes, calibration (ECE), identification affine, multi-seed 4 | 35-40 min | -| pt-0b | [RLPT-00b-Biais-Dataset-Preferences-Python](PostTraining/RLPT-00b-Biais-Dataset-Preferences-Python.html) | Biais d'un dataset de préférences, mesurés sur monde synthétique à longueurs variables : les trois biais classiques (longueur, position, annotateurs) injectés à paramètres connus, dégât mesuré contre le plafond de Bayes d'un juge **oracle non biaisé**, puis les mitigations du cahier des charges (length-controlled, swap-augmentation, annotator embedding) plus une quatrième qui sert de contrôle — verdict mesuré : aucune ne franchit 2σ, le length-controlled est **structurellement** sans effet sur une métrique de classement, l'orthogonalisation de longueur **aggrave** le biais | 40-45 min | -| pt-0c | [RLPT-00c-Anatomie-Reward-Hacking-Python](PostTraining/RLPT-00c-Anatomie-Reward-Hacking-Python.html) | Anatomie d'un reward hacking **qui prend** — le pendant de `RLPT-03` : reward model Bradley-Terry appris sur des préférences à biais de longueur, PPO from scratch sur ce proxy, puis **bras de contrôle** (récompense longueur-contrôlée + oracle) qui identifie le biais comme cause. Mesures : qualité vraie 0,4545 → 0,0170 sous le proxy biaisé, contre 0,9905 sous contrôle ; basculement situé sur l'action de tête du proxy (argmax non correct à α ≈ 2,0), stable sur 4 graines | 35-40 min | -| pt-0d | [RLPT-00d-Reward-Trainer-TRL-Python](PostTraining/RLPT-00d-Reward-Trainer-TRL-Python.html) | Le **même** problème que `RLPT-00`, traité par le harnais industriel `trl.RewardTrainer` : monde, juge, architecture (5 441 paramètres) et seeds identiques, une seule variable — le harnais. Documente les **quatre exigences de contrat** non devinables (`num_labels=1`, `processing_class`, `gradient_checkpointing=False`, `self.post_init()`) et la traduction `y` → `chosen_ids`/`rejected_ids` ; verdict mesuré : `trl` **devance** la boucle maison (0.676 ± 0.007 vs 0.658 ± 0.008, écart +0.018 = 2.2σ ; Brier et Spearman meilleurs aussi) pour un coût en temps de **~10×** sur ce modèle minuscule, et l'évaluation honnête reste **entièrement à ré-écrire** — `trl` n'évalue pas pour vous | 35-40 min | -| pt-0e | [RLPT-00e-DPO-TRL-Python](PostTraining/RLPT-00e-DPO-TRL-Python.html) | `trl.DPOTrainer` (bras SOTA) contre DPO from scratch et reward model explicite de `RLPT-00` sur le **même monde et les mêmes paires de préférences**, à budget égal (même β, même lr, mêmes époques) — multi-seed {0,1,7,42} départagé au plafond de Bayes : verdict **B ≈ C > A** (DPO maison 0.679 / trl 0.678 / RM 0.661 vs plafond 0.695 ; B vs C indiscernables à ±0.008 près), marges implicites B↔C corrélées ρ≈0.98 = même math ; la différence robuste est le **coût fixe** de la pile (×22 sur jouet CPU) — inclut la garde de frontière prompt/complétion (piège trl : prompt sans espace finale) | 25-35 min | -| pt-0f | [RLPT-00f-GRPO-TRL-contre-PPO-Maison-Python](PostTraining/RLPT-00f-GRPO-TRL-contre-PPO-Maison-Python.html) | `trl.GRPOTrainer` (bras SOTA **en ligne**) contre le PPO maison de `RLPT-01` sur le **même monde et le même juge RM** (`RLPT-00`), à budget apparié (2 304 réponses évaluées par bras, même β_KL) — multi-seed {0,1,7,42} : verdict **INCONCLUSIVE** (gain maison 0.486±0.205 / trl 0.670±0.102, écart +0.184 < 2σ) ; la différence robuste est le **critic** (value net appris vs moyenne de groupe — la baseline est LE choix de design) et le coût d'écriture et de runtime (tableau comparatif section 7) — inclut le fait structurant mesuré dans l'env : `trl.PPOTrainer` a **quitté la racine** de trl (déplacé dans `trl.experimental.ppo`, assert garde-frontière sur la surface réelle) et le trainer historique **remis en service** en 3e bras (section 5bis : PPO complet critic + GAE, juge BT reconstruit au format lib, seed 0) | 30-45 min | -| pt-0g | [RLPT-00g-PPO-TRL-Experimental-Python](PostTraining/RLPT-00g-PPO-TRL-Experimental-Python.html) | `trl.experimental.ppo.PPOTrainer` / `PPOConfig` instanciés comme surface SOTA réelle (pas seulement importés) — surface instable par convention mais invocable, signature introspectée (`num_train_epochs`, `use_cpu`). Boucle PPO conforme Schulman 2017 (rollout → GAE → surrogate clip → value loss) avec hyperparamètres alignés sur `PPOConfig`. **Verdict SOTA `INTRINSIC`** documenté (6 axes) : la mini-tâche symbolique ne se branche pas sur `PPOTrainer` directement (LM `transformers` requis), mais l'algorithme est strictement celui qu'enrobe TRL. Multi-seed {0,1,7,42} : moyenne finale 0.401 ± 0.041, **en dessous** du baseline uniforme 0.497 (gap −0.096 ≈ 2.3σ), donc **dans la bande** des 3 baselines (verdict **INCONCLUSIVE** : PPO ne surpasse pas le baseline uniforme, mais l'écart reste comparable à 2σ et le notebook documente la signature d'apprentissage). Complément de `RLPT-00f` (PPO maison vs GRPO) sur l'axe RLHF #16063 — ferme l'item 6 | 30-40 min | -| pt-1 | [RLPT-01-PPO-RLHF-Petit-Modele-Python](PostTraining/RLPT-01-PPO-RLHF-Petit-Modele-Python.html) | PPO pour alignement d'un petit LM (RLHF toy, from scratch, char-level) : reward model jouet, KL vs politique SFT de référence, multi-seed 4 — la signature RLHF, différenciée de RL-06c (PPO CartPole) et RL-06e (GRPO) | 40-45 min | -| pt-2 | [RLPT-02-GRPO-Minimal-Python](PostTraining/RLPT-02-GRPO-Minimal-Python.html) | GRPO sur Qwen3.5-0.8B local (8 Go Viability), reward vérifiable, budget steps borné — le cœur « à la Deepseek » : group rollouts, avantage sans value net, pont #5105 | 45-55 min | -| pt-3 | [RLPT-03-Reward-Hacking-Python](PostTraining/RLPT-03-Reward-Hacking-Python.html) | Reward hacking × inoculation, version compacte du capstone #5105 : le hack sur récompense vérifiable faillible, la détection rewardspy, l'inoculation comme variable expérimentale, verdict reproductible (seed fixée) | 35-40 min | -| pt-4 | [RLPT-04-DPO-Offline-contre-GRPO-Online-Python](PostTraining/RLPT-04-DPO-Offline-contre-GRPO-Online-Python.html) | DPO/ORPO offline vs GRPO online sur même tâche conversationnelle, même budget 40 steps, préférences auto-fabriquées — verdict multi-seed {42,0,1,7} honnête DM, dispersion inter-seed documentée | 50-55 min | +| 1 | [RL-01-Premiers-Pas-Stable-Baselines3-Python](RL-01-Premiers-Pas-Stable-Baselines3-Python.ipynb) | Introduction PPO, CartPole | 25-30 min | +| 1b | [RL-01b-Synthese-Logique-Bitwise-Python](RL-01b-Synthese-Logique-Bitwise-Python.ipynb) | Synthèse logique d'un contrôleur CartPole : bitwise 4-règles — scellement observation→bits IEEE-754, contrôleur LQR de référence (taux de désaccord), PPO budget modeste, étude de rupture et ablation. Accrétion de RL-01 | 20-25 min | +| 1c | [RL-01c-Distillation-Politique-Prolog-Python](RL-01c-Distillation-Politique-Prolog-Python.ipynb) | Distillation d'une politique RL en programme Prolog exécutable : teacher PPO from scratch (seed fixe), census exhaustif de T-bar, induction gloutonne type FOIL, liste de décision avec cuts, one-pass vs DAgger, SWI-Prolog réel journalisé. Accrétion de RL-01 | 45-60 min | +| 2 | [RL-02-Wrappers-Sauvegarde-Callbacks-Python](RL-02-Wrappers-Sauvegarde-Callbacks-Python.ipynb) | Wrappers, sauvegarde, callbacks | 35-40 min | +| 3 | [RL-03-Experience-Replay-HER-Python](RL-03-Experience-Replay-HER-Python.ipynb) | HER, goal-conditioned RL | 40-45 min | +| 4 | [RL-04-Bandits-Manchots-Python](RL-04-Bandits-Manchots-Python.ipynb) | Bandits manchots, exploration vs exploitation, Thompson Sampling | 30-35 min | +| 5 | [RL-05-MDP-Programmation-Dynamique-Q-Learning-Python](RL-05-MDP-Programmation-Dynamique-Q-Learning-Python.ipynb) | MDP, Value/Policy Iteration, Q-Learning tabulaire | 45-50 min | +| 6 | [RL-06-DQN-Policy-Gradient-Python](RL-06-DQN-Policy-Gradient-Python.ipynb) | DQN depuis zéro, REINFORCE | 50-55 min | +| 6b | [RL-06b-Actor-Critic-Python](RL-06b-Actor-Critic-Python.ipynb) | Actor-Critic (A2C) depuis zéro, advantage, entropy bonus | 45-50 min | +| 6c | [RL-06c-PPO-Depuis-Zero-Python](RL-06c-PPO-Depuis-Zero-Python.ipynb) | PPO depuis zéro, échantillonnage d'importance (ratios par epoch, ESS), clipped surrogate, GAE, comparaison A2C vs PPO | 45-50 min | +| 6d | [RL-06d-SAC-Depuis-Zero-Python](RL-06d-SAC-Depuis-Zero-Python.ipynb) | SAC depuis zéro, maximum entropy RL, twin Q-networks, auto-température | 45-50 min | +| 6e | [RL-06e-GRPO-Depuis-Zero-Python](RL-06e-GRPO-Depuis-Zero-Python.ipynb) | GRPO depuis zéro (DeepSeek-R1), avantage relatif intra-groupe (sans critic), clip PPO + KL vs référence, portefeuille synthétique multi-seed | 45-50 min | +| 7 | [RL-07-Apprentissage-Multi-Agent-Python](RL-07-Apprentissage-Multi-Agent-Python.ipynb) | Multi-Agent RL, PettingZoo, IQL | 45-50 min | +| 7b | [RL-07b-Sur-Generalisation-Climbing-Game-Python](RL-07b-Sur-Generalisation-Climbing-Game-Python.ipynb) | Sur-généralisation relative dans le Climbing Game coopératif : même agent tabulaire, IQL vs Hysteretic Q-learning, protocole multi-graines, IQM + intervalle bootstrap, ablation du pessimisme | ~45 min | +| 8 | [RL-08-Dyna-Q-Planification-Python](RL-08-Dyna-Q-Planification-Python.ipynb) | Model-based RL : Dyna-Q, Dyna-Q+, planification, rollouts | 45-50 min | +| 9 | [RL-09-RL-Offline-Behavior-Cloning-Python](RL-09-RL-Offline-Behavior-Cloning-Python.ipynb) | RL offline : Behavior Cloning, erreur d'extrapolation, BCQ-lite | 50-55 min | +| 10 | [RL-10-Reward-Shaping-Curriculum-Python](RL-10-Reward-Shaping-Curriculum-Python.ipynb) | Reward Shaping (Ng 1999), curriculum learning, pont RLHF | 45-50 min | +| 11 | [RL-11-POMDP-Croyances-Python](RL-11-POMDP-Croyances-Python.ipynb) | POMDP, Tiger Problem, belief tracking, Q-MDP | 45-50 min | +| 12 | [RL-12-Distributional-RL-C51-Python](RL-12-Distributional-RL-C51-Python.ipynb) | RL distributionnel : C51 (Categorical DQN) depuis zéro, projection catégorielle, politique CVaR | 50-55 min | +| 13 | [RL-13-Curiosite-RND-Python](RL-13-Curiosite-RND-Python.ipynb) | Exploration par curiosité (RND), motivation intrinsèque, piège d'exploitation | 35-40 min | +| 14 | [RL-14-RL-Hierarchique-Options-Python](RL-14-RL-Hierarchique-Options-Python.ipynb) | Hierarchical RL — l'Option framework de Sutton, Precup & Singh : abstraction temporelle, options `(I, π, β)`, gridworld quatre-pièces, crédit sur longue horizon | ~50 min | +| 15 | [RL-15-GRPO-Comparatif-Multi-Graines-Python](RL-15-GRPO-Comparatif-Multi-Graines-Python.ipynb) | GRPO (Group Relative Policy Optimization) vs PPO sur CartPole-v1 — avantage relatif intra-groupe (sans critic) vs GAE bootstrapé, multi-seed 6 (0/1/7/42/99/123), Wilcoxon signed-rank + IC95% bootstrap. Prong B discrimination moteur. Sous-grain #13436 de l'EPIC #1454. **Verdict v3 (REPAIR c.644) : INCONCLUSIVE** (le claim initial v1 « GRPO BEATS PPO » souffrait de défauts done-mask + pad-mask — c.642 a corrigé en INCONCLUSIVE, puis c.644 a détecté 4 post-fix incohérences résolues : Wilcoxon n=4 inatteignable, verdict tri-state asymmétrique, hypothèse descriptive fausse réfutée, titre PR ré-aligné — verdict v3 INCONCLUSIVE maintenu, moyennes v3 = 299.36 vs 197.65, std = 55.26 vs 104.99) | 40-45 min | +| 16 | [RL-16-Dream-RSI-Python](RL-16-Dream-RSI-Python.ipynb) | Dream-RSI (arXiv 2609.14858, preprint 14/09/2026) : exploration explicite **programmable** (politique = code), historique de découverte = simulateur-replay, **dreaming** = évaluation off-policy à coût zéro, boucle RSI avec incumbent (garantie non-régression replay-only) — monde jouet circle-packing stdlib (16 cercles), ablation replay brut vs guidance sémantique mesurée (3/2/7), chiffres du papier rapportés non canonisés. Distillation #16417 | 40-45 min | +| 19 | [RL-19-Reward-Tampering-Python](RL-19-Reward-Tampering-Python.ipynb) | Reward tampering : l'agent qui peut **réécrire** sa récompense — *Rocks and Diamonds* à paramètre θ modifiable (exemple 2 d'Everitt et al., Synthese 2021), quatre agents résolus par **induction arrière exacte** sur 32 252 états (standard, oracle, *current-RF* TI-ignoring et TI-considering) : les trois prédictions du papier mesurées `conforme`. Au-delà du diagramme : **l'indifférence n'est pas la protection** — valeur de l'option de manipuler +16 (standard) contre +0 (TI-ignoring), mais départage aléatoire des égalités → manipulation 33/200 (H = 30) et 68/200 (H = 60), toujours après la tâche ; Q-learning standard 0/5 graines en initialisation nulle, 5/5 en optimiste. RF-input tampering (autocollants sur la caméra) : 88 observé / 0 réel contre 20 / 20 sous récompense sur croyance. Distillation #14468 | 35-40 min | +| pt-0 | [RLPT-00-Reward-Model-Bradley-Terry-Python](PostTraining/RLPT-00-Reward-Model-Bradley-Terry-Python.ipynb) | Reward model from scratch (Bradley-Terry) : apprendre r(x, y) depuis des paires de préférences sur le monde de RLPT-01 — MLE BT sans `trl.RewardTrainer`, évaluation honnête vs plafond de Bayes, calibration (ECE), identification affine, multi-seed 4 | 35-40 min | +| pt-0b | [RLPT-00b-Biais-Dataset-Preferences-Python](PostTraining/RLPT-00b-Biais-Dataset-Preferences-Python.ipynb) | Biais d'un dataset de préférences, mesurés sur monde synthétique à longueurs variables : les trois biais classiques (longueur, position, annotateurs) injectés à paramètres connus, dégât mesuré contre le plafond de Bayes d'un juge **oracle non biaisé**, puis les mitigations du cahier des charges (length-controlled, swap-augmentation, annotator embedding) plus une quatrième qui sert de contrôle — verdict mesuré : aucune ne franchit 2σ, le length-controlled est **structurellement** sans effet sur une métrique de classement, l'orthogonalisation de longueur **aggrave** le biais | 40-45 min | +| pt-0c | [RLPT-00c-Anatomie-Reward-Hacking-Python](PostTraining/RLPT-00c-Anatomie-Reward-Hacking-Python.ipynb) | Anatomie d'un reward hacking **qui prend** — le pendant de `RLPT-03` : reward model Bradley-Terry appris sur des préférences à biais de longueur, PPO from scratch sur ce proxy, puis **bras de contrôle** (récompense longueur-contrôlée + oracle) qui identifie le biais comme cause. Mesures : qualité vraie 0,4545 → 0,0170 sous le proxy biaisé, contre 0,9905 sous contrôle ; basculement situé sur l'action de tête du proxy (argmax non correct à α ≈ 2,0), stable sur 4 graines | 35-40 min | +| pt-0d | [RLPT-00d-Reward-Trainer-TRL-Python](PostTraining/RLPT-00d-Reward-Trainer-TRL-Python.ipynb) | Le **même** problème que `RLPT-00`, traité par le harnais industriel `trl.RewardTrainer` : monde, juge, architecture (5 441 paramètres) et seeds identiques, une seule variable — le harnais. Documente les **quatre exigences de contrat** non devinables (`num_labels=1`, `processing_class`, `gradient_checkpointing=False`, `self.post_init()`) et la traduction `y` → `chosen_ids`/`rejected_ids` ; verdict mesuré : `trl` **devance** la boucle maison (0.676 ± 0.007 vs 0.658 ± 0.008, écart +0.018 = 2.2σ ; Brier et Spearman meilleurs aussi) pour un coût en temps de **~10×** sur ce modèle minuscule, et l'évaluation honnête reste **entièrement à ré-écrire** — `trl` n'évalue pas pour vous | 35-40 min | +| pt-0e | [RLPT-00e-DPO-TRL-Python](PostTraining/RLPT-00e-DPO-TRL-Python.ipynb) | `trl.DPOTrainer` (bras SOTA) contre DPO from scratch et reward model explicite de `RLPT-00` sur le **même monde et les mêmes paires de préférences**, à budget égal (même β, même lr, mêmes époques) — multi-seed {0,1,7,42} départagé au plafond de Bayes : verdict **B ≈ C > A** (DPO maison 0.679 / trl 0.678 / RM 0.661 vs plafond 0.695 ; B vs C indiscernables à ±0.008 près), marges implicites B↔C corrélées ρ≈0.98 = même math ; la différence robuste est le **coût fixe** de la pile (×22 sur jouet CPU) — inclut la garde de frontière prompt/complétion (piège trl : prompt sans espace finale) | 25-35 min | +| pt-0f | [RLPT-00f-GRPO-TRL-contre-PPO-Maison-Python](PostTraining/RLPT-00f-GRPO-TRL-contre-PPO-Maison-Python.ipynb) | `trl.GRPOTrainer` (bras SOTA **en ligne**) contre le PPO maison de `RLPT-01` sur le **même monde et le même juge RM** (`RLPT-00`), à budget apparié (2 304 réponses évaluées par bras, même β_KL) — multi-seed {0,1,7,42} : verdict **INCONCLUSIVE** (gain maison 0.486±0.205 / trl 0.670±0.102, écart +0.184 < 2σ) ; la différence robuste est le **critic** (value net appris vs moyenne de groupe — la baseline est LE choix de design) et le coût d'écriture et de runtime (tableau comparatif section 7) — inclut le fait structurant mesuré dans l'env : `trl.PPOTrainer` a **quitté la racine** de trl (déplacé dans `trl.experimental.ppo`, assert garde-frontière sur la surface réelle) et le trainer historique **remis en service** en 3e bras (section 5bis : PPO complet critic + GAE, juge BT reconstruit au format lib, seed 0) | 30-45 min | +| pt-0g | [RLPT-00g-PPO-TRL-Experimental-Python](PostTraining/RLPT-00g-PPO-TRL-Experimental-Python.ipynb) | `trl.experimental.ppo.PPOTrainer` / `PPOConfig` instanciés comme surface SOTA réelle (pas seulement importés) — surface instable par convention mais invocable, signature introspectée (`num_train_epochs`, `use_cpu`). Boucle PPO conforme Schulman 2017 (rollout → GAE → surrogate clip → value loss) avec hyperparamètres alignés sur `PPOConfig`. **Verdict SOTA `INTRINSIC`** documenté (6 axes) : la mini-tâche symbolique ne se branche pas sur `PPOTrainer` directement (LM `transformers` requis), mais l'algorithme est strictement celui qu'enrobe TRL. Multi-seed {0,1,7,42} : moyenne finale 0.401 ± 0.041, **en dessous** du baseline uniforme 0.497 (gap −0.096 ≈ 2.3σ), donc **dans la bande** des 3 baselines (verdict **INCONCLUSIVE** : PPO ne surpasse pas le baseline uniforme, mais l'écart reste comparable à 2σ et le notebook documente la signature d'apprentissage). Complément de `RLPT-00f` (PPO maison vs GRPO) sur l'axe RLHF #16063 — ferme l'item 6 | 30-40 min | +| pt-1 | [RLPT-01-PPO-RLHF-Petit-Modele-Python](PostTraining/RLPT-01-PPO-RLHF-Petit-Modele-Python.ipynb) | PPO pour alignement d'un petit LM (RLHF toy, from scratch, char-level) : reward model jouet, KL vs politique SFT de référence, multi-seed 4 — la signature RLHF, différenciée de RL-06c (PPO CartPole) et RL-06e (GRPO) | 40-45 min | +| pt-2 | [RLPT-02-GRPO-Minimal-Python](PostTraining/RLPT-02-GRPO-Minimal-Python.ipynb) | GRPO sur Qwen3.5-0.8B local (8 Go Viability), reward vérifiable, budget steps borné — le cœur « à la Deepseek » : group rollouts, avantage sans value net, pont #5105 | 45-55 min | +| pt-3 | [RLPT-03-Reward-Hacking-Python](PostTraining/RLPT-03-Reward-Hacking-Python.ipynb) | Reward hacking × inoculation, version compacte du capstone #5105 : le hack sur récompense vérifiable faillible, la détection rewardspy, l'inoculation comme variable expérimentale, verdict reproductible (seed fixée) | 35-40 min | +| pt-4 | [RLPT-04-DPO-Offline-contre-GRPO-Online-Python](PostTraining/RLPT-04-DPO-Offline-contre-GRPO-Online-Python.ipynb) | DPO/ORPO offline vs GRPO online sur même tâche conversationnelle, même budget 40 steps, préférences auto-fabriquées — verdict multi-seed {42,0,1,7} honnête DM, dispersion inter-seed documentée | 50-55 min | ## Frontière avec GenAI/PostTraining — où ouvre `rlpt_*`, où ouvre `PT_*` @@ -85,16 +85,16 @@ Les sous-séries [`rlpt_*`](.) et [GenAI/PostTraining](../GenAI/PostTraining/REA | Question pédagogique | Ouvrir | Pourquoi | |---|---|---| -| « D'où vient le reward model avant tout RLHF — comment l'apprendre à partir de préférences ? » | [`RLPT-00`](PostTraining/RLPT-00-Reward-Model-Bradley-Terry-Python.html) | Bradley-Terry from scratch sur le monde de `RLPT-01` : l'étage que `RLPT-01` saute en codant son oracle en dur — plafond de Bayes, calibration, identification affine. | -| « Pourquoi un reward model apprend-il le biais de son annotateur plutôt que la qualité ? » | [`RLPT-00b`](PostTraining/RLPT-00b-Biais-Dataset-Preferences-Python.html) | Les trois biais d'un dataset de préférences injectés à paramètres connus : le RM **recopie** le raccourci du juge (gamma mesuré vs lambda injecté) quand le biais lui est représentable, et se contente de **sous-échelonner** quand il ne l'est pas (biais de position) — dans les deux cas l'accord à l'oracle descend. | -| « Le harnais SOTA (`trl`) fait-il mieux que ma boucle from scratch — et que me coûte-t-il ? » | [`RLPT-00d`](PostTraining/RLPT-00d-Reward-Trainer-TRL-Python.html) | `trl.RewardTrainer` sur le **même** monde que `RLPT-00`, à architecture identique : le harnais **gagne** (0.676 ± 0.007 vs 0.658 ± 0.008, +0.018 = 2.2σ), coûte ~10× le temps sur un modèle minuscule, impose quatre réglages de contrat, et n'évalue pas pour vous. | -| « Comment marche PPO-RLHF en petit, sans framework ? » | [`RLPT-01`](PostTraining/RLPT-01-PPO-RLHF-Petit-Modele-Python.html) | RLHF from scratch sur LM char-level — on voit les gradients, le reward model jouet, la KL vs la politique SFT de référence, multi-seed 4. | -| « Comment GRPO est câblé *intérieurement* (group rollouts, avantage intra-groupe, no critic) ? » | [`RLPT-02`](PostTraining/RLPT-02-GRPO-Minimal-Python.html) | GRPO Qwen3.5-0.8B local **sans `trl` complet** — la boucle d'entraînement est écrite à la main, on voit chaque rollout, chaque reward. | -| « Le reward hacking est-il un attracteur spontané sur petit modèle ? Comment l'inoculer ? » | [`RLPT-03`](PostTraining/RLPT-03-Reward-Hacking-Python.html) | Cas clinique minimal : 3 voies pour tenter de déclencher le hack, inoculation comme variable expérimentale, verdict reproductible (seed fixée). | -| « Pourquoi le reward hacking arrive-t-il — le reward model est-il vraiment la cause ? » | [`RLPT-00c`](PostTraining/RLPT-00c-Anatomie-Reward-Hacking-Python.html) | Isolation de cause : le biais de longueur est **lu dans les poids** du reward model appris, puis **retiré** — la qualité se rétablit (bras de contrôle), et le basculement est situé sur l'action de tête du proxy. | -| « DPO offline vs GRPO online à budget égal — qui gagne ? » | [`RLPT-04`](PostTraining/RLPT-04-DPO-Offline-contre-GRPO-Online-Python.html) | Comparaison à budget 40 steps, préférences auto-fabriquées, verdict multi-seed {42,0,1,7} honnête Diebold-Mariano, dispersion inter-seed documentée. | -| « GRPO + RLVR sur un vrai LLM, avec `trl` + reward vérifiable + détecteurs Goodhart en ligne ? » | [PT-11a](../GenAI/PostTraining/PT_11a_grpo_qwen35_rlvr.html), [PT-11b](../GenAI/PostTraining/PT_11b_grpo_qwen_rlvr_on_verifiers.html) | La chaîne *SOTA 2024-2025* appliquée : `trl.GRPOTrainer` + Qwen3.5-0.8B QLoRA 4-bit + Z3/SymPy vérificateur + `rewardspy.watch_trl` en ligne. | -| « Quels sont les 6 détecteurs statistiques du reward hacking ? » | [PT-07](../GenAI/PostTraining/PT_07_rewardspy_reward_hacking.html) | Le catalogue `rewardspy.detectors` (Component Dominance, Length Drift, etc.). Outil — `RLPT-03` est le cas d'usage. | +| « D'où vient le reward model avant tout RLHF — comment l'apprendre à partir de préférences ? » | [`RLPT-00`](PostTraining/RLPT-00-Reward-Model-Bradley-Terry-Python.ipynb) | Bradley-Terry from scratch sur le monde de `RLPT-01` : l'étage que `RLPT-01` saute en codant son oracle en dur — plafond de Bayes, calibration, identification affine. | +| « Pourquoi un reward model apprend-il le biais de son annotateur plutôt que la qualité ? » | [`RLPT-00b`](PostTraining/RLPT-00b-Biais-Dataset-Preferences-Python.ipynb) | Les trois biais d'un dataset de préférences injectés à paramètres connus : le RM **recopie** le raccourci du juge (gamma mesuré vs lambda injecté) quand le biais lui est représentable, et se contente de **sous-échelonner** quand il ne l'est pas (biais de position) — dans les deux cas l'accord à l'oracle descend. | +| « Le harnais SOTA (`trl`) fait-il mieux que ma boucle from scratch — et que me coûte-t-il ? » | [`RLPT-00d`](PostTraining/RLPT-00d-Reward-Trainer-TRL-Python.ipynb) | `trl.RewardTrainer` sur le **même** monde que `RLPT-00`, à architecture identique : le harnais **gagne** (0.676 ± 0.007 vs 0.658 ± 0.008, +0.018 = 2.2σ), coûte ~10× le temps sur un modèle minuscule, impose quatre réglages de contrat, et n'évalue pas pour vous. | +| « Comment marche PPO-RLHF en petit, sans framework ? » | [`RLPT-01`](PostTraining/RLPT-01-PPO-RLHF-Petit-Modele-Python.ipynb) | RLHF from scratch sur LM char-level — on voit les gradients, le reward model jouet, la KL vs la politique SFT de référence, multi-seed 4. | +| « Comment GRPO est câblé *intérieurement* (group rollouts, avantage intra-groupe, no critic) ? » | [`RLPT-02`](PostTraining/RLPT-02-GRPO-Minimal-Python.ipynb) | GRPO Qwen3.5-0.8B local **sans `trl` complet** — la boucle d'entraînement est écrite à la main, on voit chaque rollout, chaque reward. | +| « Le reward hacking est-il un attracteur spontané sur petit modèle ? Comment l'inoculer ? » | [`RLPT-03`](PostTraining/RLPT-03-Reward-Hacking-Python.ipynb) | Cas clinique minimal : 3 voies pour tenter de déclencher le hack, inoculation comme variable expérimentale, verdict reproductible (seed fixée). | +| « Pourquoi le reward hacking arrive-t-il — le reward model est-il vraiment la cause ? » | [`RLPT-00c`](PostTraining/RLPT-00c-Anatomie-Reward-Hacking-Python.ipynb) | Isolation de cause : le biais de longueur est **lu dans les poids** du reward model appris, puis **retiré** — la qualité se rétablit (bras de contrôle), et le basculement est situé sur l'action de tête du proxy. | +| « DPO offline vs GRPO online à budget égal — qui gagne ? » | [`RLPT-04`](PostTraining/RLPT-04-DPO-Offline-contre-GRPO-Online-Python.ipynb) | Comparaison à budget 40 steps, préférences auto-fabriquées, verdict multi-seed {42,0,1,7} honnête Diebold-Mariano, dispersion inter-seed documentée. | +| « GRPO + RLVR sur un vrai LLM, avec `trl` + reward vérifiable + détecteurs Goodhart en ligne ? » | [PT-11a](../GenAI/PostTraining/PT_11a_grpo_qwen35_rlvr.ipynb), [PT-11b](../GenAI/PostTraining/PT_11b_grpo_qwen_rlvr_on_verifiers.ipynb) | La chaîne *SOTA 2024-2025* appliquée : `trl.GRPOTrainer` + Qwen3.5-0.8B QLoRA 4-bit + Z3/SymPy vérificateur + `rewardspy.watch_trl` en ligne. | +| « Quels sont les 6 détecteurs statistiques du reward hacking ? » | [PT-07](../GenAI/PostTraining/PT_07_rewardspy_reward_hacking.ipynb) | Le catalogue `rewardspy.detectors` (Component Dominance, Length Drift, etc.). Outil — `RLPT-03` est le cas d'usage. | | « InoculationRL complet, panel persona × reward hackable, la réplique poids du capstone ? » | [#5105 ICT-25](https://github.com/jsboige/CoursIA/issues/5105) | Capstone final, **distinct** de `RLPT-03` (qui en est la version compacte). | **Une phrase à retenir** : `rlpt_*` = *la mécanique, en petit, sans framework* (from scratch, CPU/char-level ou Qwen3.5-0.8B sans la pile `trl` complète — on voit chaque rollout et chaque gradient) ; `GenAI/PostTraining` = *la chaîne réelle, à l'échelle* (`trl`, vrai LLM, solveur vérifiable, multi-seed, détecteurs Goodhart). Si votre question porte sur **pourquoi** un algorithme fonctionne, ouvrez `rlpt_*`. Si votre question porte sur **comment le déployer en SOTA 2025**, ouvrez `PT_*`. @@ -649,12 +649,12 @@ Plusieurs notebooks de cette série annoncent un « pont RLHF » (notebook 9 sur | Concept RL (cette série) | Réalisation côté LLM (GenAI) | |--------------------------|------------------------------| -| Behavior Cloning = imitation ([RL-09](RL-09-RL-Offline-Behavior-Cloning-Python.html)) | SFT — [PostTraining PT-02](../GenAI/PostTraining/PT_02_sft_baseline.html), [FineTuning FT-03](../GenAI/FineTuning/FT-03-Supervised-FineTuning-SFT-Python.html) | -| Contrainte de support BCQ = pénalité KL ([RL-09](RL-09-RL-Offline-Behavior-Cloning-Python.html)) | KL vers le modèle de référence dans PPO-RLHF / DPO — [PT-03](../GenAI/PostTraining/PT_03_dpo_direct_preference.html) | -| Reward shaping = guider via le signal ([RL-10](RL-10-Reward-Shaping-Curriculum-Python.html)) | Reward model appris à partir de préférences — [FineTuning FT-04](../GenAI/FineTuning/FT-04-RLHF-DPO-Python.html) | -| Biais du shaping naïf = reward hacking ([RL-10](RL-10-Reward-Shaping-Curriculum-Python.html)) | Goodhart / overoptimisation du reward model — [PT-07](../GenAI/PostTraining/PT_07_rewardspy_reward_hacking.html) | -| Policy gradient / PPO ([RL-06c](RL-06c-PPO-Depuis-Zero-Python.html)) | PPO-RLHF et son successeur GRPO — [PT-04](../GenAI/PostTraining/PT_04_grpo_deepseek_r1.html) | -| MDP, value/Q ([RL-05](RL-05-MDP-Programmation-Dynamique-Q-Learning-Python.html)) | Socle policy/value réutilisé par tout post-training — [GenAI/PostTraining](../GenAI/PostTraining/README.md) | +| Behavior Cloning = imitation ([RL-09](RL-09-RL-Offline-Behavior-Cloning-Python.ipynb)) | SFT — [PostTraining PT-02](../GenAI/PostTraining/PT_02_sft_baseline.ipynb), [FineTuning FT-03](../GenAI/FineTuning/FT-03-Supervised-FineTuning-SFT-Python.ipynb) | +| Contrainte de support BCQ = pénalité KL ([RL-09](RL-09-RL-Offline-Behavior-Cloning-Python.ipynb)) | KL vers le modèle de référence dans PPO-RLHF / DPO — [PT-03](../GenAI/PostTraining/PT_03_dpo_direct_preference.ipynb) | +| Reward shaping = guider via le signal ([RL-10](RL-10-Reward-Shaping-Curriculum-Python.ipynb)) | Reward model appris à partir de préférences — [FineTuning FT-04](../GenAI/FineTuning/FT-04-RLHF-DPO-Python.ipynb) | +| Biais du shaping naïf = reward hacking ([RL-10](RL-10-Reward-Shaping-Curriculum-Python.ipynb)) | Goodhart / overoptimisation du reward model — [PT-07](../GenAI/PostTraining/PT_07_rewardspy_reward_hacking.ipynb) | +| Policy gradient / PPO ([RL-06c](RL-06c-PPO-Depuis-Zero-Python.ipynb)) | PPO-RLHF et son successeur GRPO — [PT-04](../GenAI/PostTraining/PT_04_grpo_deepseek_r1.ipynb) | +| MDP, value/Q ([RL-05](RL-05-MDP-Programmation-Dynamique-Q-Learning-Python.ipynb)) | Socle policy/value réutilisé par tout post-training — [GenAI/PostTraining](../GenAI/PostTraining/README.md) | En résumé : **DPO** (Direct Preference Optimization) est l'aboutissement direct de la ligne offline RL + contrainte de support + preference learning tracée par les notebooks 9 et 10. Pour le voir tourner sur de vrais LLM, suivre [GenAI/PostTraining](../GenAI/PostTraining/README.md) puis [GenAI/FineTuning](../GenAI/FineTuning/README.md). From a98651d8d435a9113f4223377ce2cfebf2e430eb Mon Sep 17 00:00:00 2001 From: jsboige Date: Tue, 13 Oct 2026 16:57:25 +0200 Subject: [PATCH 3/3] Fix(readme,#20549): ancre HTML 2.4b-AdaBoost en .ipynb (angle mort scanner markdown) Signalement pair (audit independant coursia-2-7e) : la figure README 02-ML-Cours portait -- forme ancre HTML, invisible au scanner markdown-only de regen_quarto_render.py. Balayage flotte-wide de la meme classe : 1 seule occurrence (celle-ci). Cible .ipynb presente verifiee. Co-Authored-By: Claude Sonnet 5.5 --- .../ML/DataScienceWithAgents/02-ML-Cours/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/02-ML-Cours/README.md b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/02-ML-Cours/README.md index 6d71011d32..2bdb4ac3b1 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/02-ML-Cours/README.md +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/02-ML-Cours/README.md @@ -111,7 +111,7 @@ La série ne se contente pas d'ajuster des modèles : chaque chapitre **rend vis **[2.4b — Le comité qui concentre ses poids.](2.4b-AdaBoost-From-Scratch.ipynb)** AdaBoost (SAMME) reconstruit à la main sur le même jeu que 2.4 : chaque tour retient le stump d'erreur pondérée minimale, lui donne un vote α = ½ln((1−ε)/ε), puis fait monter le poids des exemples mal classés — et descendre les autres. La figure montre la conséquence : la masse des poids migre vers les exemples difficiles (les dix plus lourds portent 17 % de la masse au tour 1, 46 % au tour 20), pendant que la frontière du comité émerge en escalier de la superposition des demi-plans pondérés. Le comité écrit à la main classe le jeu de test à l'identique de `sklearn.ensemble.AdaBoostClassifier` (0,959, accord des prédictions 1,000) — la réimplémentation est validée par recoupement avec la référence. -

AdaBoost : la migration des poids — taille des points proportionnelle au multiplicateur de poids vs uniforme, part du top-10 dans le titre de chaque panneau (17 % au tour 1, 41 % au tour 5, 46 % au tour 20), jeu de cancer du sein mean radius × mean texture.

+

AdaBoost : la migration des poids — taille des points proportionnelle au multiplicateur de poids vs uniforme, part du top-10 dans le titre de chaque panneau (17 % au tour 1, 41 % au tour 5, 46 % au tour 20), jeu de cancer du sein mean radius × mean texture.

**[2.5 — Le coût d'un seuil.](2.5-Biais-Variance-CV-ROC.ipynb)** La courbe ROC balaye tous les seuils de décision possibles et échange les faux positifs contre les faux négatifs ; l'aire sous la courbe (AUC) résume ce compromis en un nombre. Mais le bon seuil n'est pas celui qui maximise l'AUC : il dépend du coût métier d'un faux négatif (rater un cancer) face à un faux positif. La figure impose cette lecture économique de la décision.