From 7e8ce9bfa2a2564ed6dbcb8e6678707dabba1b8a Mon Sep 17 00:00:00 2001 From: jsboige Date: Wed, 23 Sep 2026 00:36:26 +0200 Subject: [PATCH 1/2] revert(density,#17040): strip cells added by post-veto density merges (ml) Mechanical: cells whose id did not exist before each density merge are removed; see PR body for the per-notebook table. Code cells, outputs and execution counts unchanged. See #17040 Co-Authored-By: Claude Opus 5 (1M context) --- .../1.3-Analyse_de_Donnees_avec_Pandas.ipynb | 74 +----- .../3.6b-Modeles-Generatifs-PyTorch.ipynb | 100 +------ ...es-Generatifs-Diffusion-from-scratch.ipynb | 243 +----------------- ...es-Generatifs-Score-SDE-from-scratch.ipynb | 87 +------ .../3.7-Distillation-Maitre-Eleve.ipynb | 37 +-- .../3.8-Representations-Contrastives.ipynb | 72 +----- .../Lab6-First-Agent/Lab6-First-Agent.ipynb | 20 +- .../Lab11-Planner-Coder-Loop.ipynb | 98 ------- .../Day5-DS-Star/Lab12-DS-Star-Workshop.ipynb | 37 +-- .../Lab12e-Session-Persistence.ipynb | 65 +---- .../Day6-MLE-Star/Lab13-Web-Search-SOTA.ipynb | 23 +- 11 files changed, 14 insertions(+), 842 deletions(-) diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/01-PythonForDataScience/notebooks/1.3-Analyse_de_Donnees_avec_Pandas.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/01-PythonForDataScience/notebooks/1.3-Analyse_de_Donnees_avec_Pandas.ipynb index 52581039a0..ed74e43fcc 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/01-PythonForDataScience/notebooks/1.3-Analyse_de_Donnees_avec_Pandas.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/01-PythonForDataScience/notebooks/1.3-Analyse_de_Donnees_avec_Pandas.ipynb @@ -37,7 +37,7 @@ "\n", "### Durée estimée : 40-50 minutes\n", "\n", - "---\n", + "***\n", "\n", "Ce notebook est une introduction à Pandas, la bibliothèque incontournable pour la manipulation et l'analyse de données en Python." ] @@ -127,14 +127,6 @@ "print(df)" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture ancrée** : Le tableau imprimé, ligne à ligne : col1 = 1, 2, 10 ; col2 = 3, 4, 30 ; Nom = Alice, Bob, Charles — deux colonnes d'entiers, une colonne de chaînes, dans le MÊME objet. C'est le contrat du DataFrame : l'hétérogénéité se juge par colonne (chaque colonne a son dtype), là où un array numpy unique exigerait un type commun aux 9 valeurs. L'index `0, 1, 2` imprime a gauche n'a pas ete fourni : Pandas l'a fabrique (RangeIndex) parce que le dictionnaire ne portait que des colonnes — la ligne existe donc meme quand aucune donnee ne l'etiquette. Et les colonnes sont alignees par NOM : `col1`, `col2`, `Nom` gardent chacun leur dtype au sein du meme objet." - ], - "id": "7706042c-c970-4f31-b3d3-2e9ca71f16a6" - }, { "cell_type": "markdown", "id": "94f4ece9", @@ -207,14 +199,6 @@ "print(colonne_2)" ] }, - { - "cell_type": "markdown", - "id": "c2057490-4f12-4f3a-9ca7-9ebfba7b199f", - "metadata": {}, - "source": [ - "**Lecture ancree** : la sortie imprime deux fois le meme objet sous deux formes. D'abord « Le DataFrame complet » : `col1` et `col2` en deux colonnes, index `0-1`. Puis « La colonne 'col2' (qui est une Series Pandas) » : `0 3`, `1 4`, et son pied `Name: col2, dtype: int64`. L'extraction d'une colonne rend une **Series** 1-D qui emporte le nom (`Name: col2`) et le type (`int64`) de sa colonne d'origine — ce pied est la signature visible de la Series, un DataFrame ne l'imprime pas. C'est ce qui permettra les jointures par cle et les operations alignees de la suite." - ] - }, { "cell_type": "markdown", "id": "4cdc0e3c", @@ -273,14 +257,6 @@ "print(df_filtre)" ] }, - { - "cell_type": "markdown", - "id": "bdb3c322-e6a9-44a0-b2f2-ba41e518e1ed", - "metadata": {}, - "source": [ - "**Lecture ancree** : le resultat ne garde que **deux lignes** — Bob (`col1` = 2) et Charles (`col1` = 10) — et laisse tomber Alice (`col1` = 1). L'expression `df['col1'] > 1` produit une Series de booleens, et `df[filtre]` ne conserve que les lignes ou elle vaut `True`. Le masque est **calcule avant** d'etre applique : c'est la meme Series 1-D etiquetee que dans la section precedente, ici consommee comme index — la selection s'aligne sur les etiquettes, pas sur les positions." - ] - }, { "cell_type": "markdown", "id": "cell-jd-intro", @@ -398,14 +374,6 @@ "Voulez-vous ne garder que les commandes `inner` ? Ou toutes les commandes `left` ?\n" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture ancrée** : Les quatre jointures mesurées : inner **2 lignes** (Alice 100, Charles 250), left **3** (Bob apparaît, montant NaN), right **3** (le client_id=4 orphelin apparaît, nom NaN, montant 75), outer **4**. Deux asymétries lisibles : la clé orpheline (4) ne survit que dans right/outer — avec nom=NaN ; le client sans commande (Bob) ne survit que dans left/outer — avec montant=NaN. Noter aussi le dtype : montant passe à float dès qu'un NaN est possible (100 → 100.0). Les deux tables d'entree sont visibles juste au-dessus de ces comptes : `clients` porte 1 Alice, 2 Bob, 3 Charles, et `commandes` 1 -> 100, 3 -> 250, 4 -> 75 — trois clients, trois commandes, mais les ensembles de cles ne coincident pas : le 2 n'a aucune commande, le 4 n'a aucun client. Les quatre comptes ne sont donc que la projection chiffree de ce desaccord." - ], - "id": "1aaa4685-5aaa-4fa9-a288-802bfa3f36b8" - }, { "cell_type": "markdown", "id": "cell-jd-missing-intro", @@ -495,14 +463,6 @@ "print(notes_imputees)\n" ] }, - { - "cell_type": "markdown", - "id": "9401b3cf-62fe-4668-8487-5898e415f294", - "metadata": {}, - "source": [ - "**Lecture ancree** : « Diagnostic : ou manque-t-il des valeurs ? — nom 0, note 2, age 1 » : la table brute porte Alice (10.0, 20.0), Bob (NaN, 21.0), Charles (12.0, NaN), Diana (NaN, 22.0), Eve (30.0, 19.0) — **3 trous pour 5 lignes**, jamais deux dans la meme ligne. La carte des NaN par colonne (une Series `int64`) est l'instrument qui decide de la strategie AVANT tout calcul : une moyenne Pandas saute les NaN silencieusement, la mediane aussi — le diagnostic est ce qui empeche de croire qu'on a moyenne 5 notes." - ] - }, { "cell_type": "markdown", "id": "cell-jd-missing-read", @@ -518,14 +478,6 @@ "si l'absence est un signal metier, mieux vaut supprimer la ligne et l'asserter.\n" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture ancrée** : Détail qui compte dans la table fillna imprimée : après comblage, Bob et Diana ont note=12.0 — mais Charles garde **age = NaN**. La stratégie fillna de la sortie était ciblée sur `note` uniquement ; `age` conserve son trou. Traiter les valeurs manquantes colonne par colonne, pas dataframe d'un bloc : le diagnostic (note 2, age 1) annonce déjà deux traitements distincts. Le choix se chiffre d'ailleurs : `dropna` (3 lignes restantes) donne une moyenne de **17.33**, `fillna` a la mediane **12.0** donne **15.20** — cinq points d'ecart sur la meme colonne, pour une decision qui ne change qu'une chose : jeter les lignes trouees ou combler d'abord." - ], - "id": "f9f96479-6c6c-4e83-83e5-d8d63a67229f" - }, { "cell_type": "markdown", "id": "cell-jd-dt-intro", @@ -612,22 +564,6 @@ "plt.show()\n" ] }, - { - "cell_type": "markdown", - "id": "130486ae-5b2c-4187-92e3-9934af863fd1", - "metadata": {}, - "source": [ - "**Lecture ancrée** : la colonne `annee` vaut **2024 sur les cinq lignes** — `.dt.year` a extrait l'année de chaque date en une seule opération vectorisée, sans boucle : l'accessor `.dt` expose les propriétés datetime (`year`, `month`, `day`…) sur toute la Series. La table intermédiaire garde `date` et `montant` intacts : l'extraction **ajoute** une colonne, elle n'en remplace aucune. La sortie le confirme sur deux points : l'index `0..4` des cinq lignes d'origine est resté tel quel, et la colonne `date` garde l'horodatage complet (`2024-01-15`) — seule la colonne neuve `annee` porte l'information réduite à l'année." - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture ancrée** : « Ventes mensuelles (resample ME) » : 2024-01-31 → 200, 2024-02-29 → 200, 2024-03-31 → 240, « Freq: ME » — cinq transactions mensualisées en trois fins de mois : janvier réunit 120+80, février porte 200 seule, mars additionne 150+90. `resample('ME')` est le groupby du temps : il découpe à bord de mois fini et agrège — la Series résultante porte l'index des dates de clôture, pas des dates de transaction. La figure produite juste apres (600x300, un seul axe) trace cette Series a trois points : `resample` ne rend pas qu'un tableau, il rend une serie temporelle indexee par ses dates de cloture, directement tracable sans retraitement." - ], - "id": "8211e19e-0fe2-4592-a4cb-a17815fb6865" - }, { "cell_type": "markdown", "id": "cell-jd-csv-intro", @@ -694,14 +630,6 @@ "os.remove(chemin_csv)\n" ] }, - { - "cell_type": "markdown", - "id": "3b153a79-0f82-4c9e-8f7a-06c5466c6280", - "metadata": {}, - "source": [ - "**Lecture ancrée** : les types confirment le round-trip — `Date datetime64[us]` et `montant int64`. Mais la conversion de `Date` ne vient pas d'une détection : elle est **demandée explicitement** par le paramètre `parse_dates` de `read_csv` (sans lui, la colonne resterait une chaîne) ; seule l'inférence de `montant` (int64 deviné des valeurs) est réelle. Et le piège des lignes : le « Fichier relu » montre 3 lignes (120, 330, 240) alors que la table **brute** de la section précédente en comptait 5 (120, 80, 200, 150, 90) — seul 120 est commun, et la table mensuelle (200, 200, 240) n'est ni l'une ni l'autre. Le round-trip CSV garantit les **types** (et encore, parce qu'on les a demandés), jamais l'identité des lignes. Le pied `dtype: object` ne decrit pas une colonne : c'est le type de la Series d'etiquettes elle-meme (des chaines), distinct des deux types qu'elle enumere — lire ce pied comme un troisieme type serait une erreur d'un niveau." - ] - }, { "cell_type": "markdown", "id": "a1eb8902", diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6b-Modeles-Generatifs-PyTorch.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6b-Modeles-Generatifs-PyTorch.ipynb index f6388e67ef..1b449e5dad 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6b-Modeles-Generatifs-PyTorch.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6b-Modeles-Generatifs-PyTorch.ipynb @@ -144,13 +144,6 @@ "plt.gca().set_aspect('equal'); plt.show()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La cellule génère 6000 échantillons en 2D et affiche leurs caractéristiques : forme (6000, 2) et bornes [-3.84 -4. ] à [3.98 4. ]. Ces données synthétiques structurées en quatre clusters forment la base de tous les modèles génératifs démontrés dans ce notebook. Le nuage de points visualisé confirme la distribution en quatre groupes distincts dans l'espace bidimensionnel. Cette configuration permet de valider que les modèles génératifs produisent bien des échantillons dans chacune des régions cibles, avec une couverture mesurable par la fonction mode_coverage. Les quatre clusters sont positionnés de manière à ce que leurs centres soient clairement séparés, ce qui facilite l'évaluation visuelle et quantitative de la qualité des modèles génératifs." - ] - }, { "cell_type": "markdown", "id": "7f191496", @@ -224,13 +217,6 @@ "plt.show()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Les paramètres estimés du modèle de mélange gaussien (GMM) sur les 6000 échantillons sont affichés. Les poids [0.252 0.2 0.306 0.241] représentent la contribution relative de chaque composante gaussienne, totalisant bien 1.0. Les moyennes [[-2.49 1.98] [ 1.2 -1.99] [ 2.52 2.5 ] [-2.01 -2.51]] indiquent les centres des quatre clusters identifiés par l'algorithme EM. Le GMM a donc convergé vers une solution où chaque composante couvre exactement un des modes cibles de la distribution synthétique. La visualisation montre les échantillons générés par le GMM superposés aux données originales, démontrant que le modèle a correctement appris la structure sous-jacente. Le GMM est un modèle classique en apprentissage non supervisé, particulièrement efficace pour des distributions multimodales comme celle présentée ici. Il est largement utilisé en traitement du signal et en reconnaissance des formes." - ] - }, { "cell_type": "markdown", "id": "648ad6c6", @@ -286,13 +272,6 @@ "print(\"Couverture GMM (baseline) :\", cov_gmm, \"=>\", sum(cov_gmm), \"/\", len(cov_gmm), \"modes\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La fonction mode_coverage évalue si chaque mode cible est couvert par les échantillons générés. Le résultat [1, 1, 1, 1] => 4 / 4 modes indique que les quatre clusters cibles contiennent chacun au moins min_count=8 échantillons du GMM. Cette métrique de couverture est cruciale pour valider que les modèles génératifs ne produisent pas simplement des échantillons dans une région restreinte, mais couvrent bien l'ensemble de la distribution cible. C'est un critère objectif pour comparer les différents modèles (GMM, VAE, GAN, Diffusion) présentés dans ce notebook. Cette fonction de métrique est utilisée tout au long du notebook pour évaluer systématiquement la capacité de chaque modèle à capturer la diversité de la distribution sous-jacente." - ] - }, { "cell_type": "markdown", "id": "d07f0395", @@ -466,13 +445,6 @@ "print(\"Échantillons VAE :\", X_vae.shape)" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La définition de la classe VAE (Variational AutoEncoder) est complète. Ce modèle utilise une architecture encodeur-décodeur avec des couches linéaires et des activations ReLU. L'encodeur comprime les données d'entrée de dimension 2 vers une représentation latente de dimension 2 (z_dim=2), tandis que le décodeur reconstruit les données originales. L'entraînement montre la perte ELBO (Evidence Lower BOund) qui combine la perte de reconstruction et la divergence KL entre la distribution latente et une normale standard. Les valeurs affichées montrent la convergence du modèle après 800 itérations, avec une amélioration significative de la perte totale. Le VAE est un modèle génératif probabiliste qui apprend une distribution de probabilité sur l'espace latent, ce qui lui permet de générer de nouveaux échantillons en échantillonnant dans cet espace." - ] - }, { "cell_type": "markdown", "id": "9a0c576a", @@ -521,13 +493,6 @@ "print(\"Le z est aléatoire (eps) mais les dimensions sont indépendantes.\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La technique de rééchantillonnage (reparameterization trick) est illustrée ici. Plutôt que d'échantillonner directement z ~ N(mu, sigma^2), on exprime z comme mu + sigma * eps, où eps ~ N(0, 1) est un bruit indépendant. Cette astuce permet de calculer le gradient par rapport aux paramètres mu et logvar, ce qui est essentiel pour l'optimisation du VAE. La sortie montre un exemple concret avec mu= [[ 0.5 -0.5]], logvar= [[0. 0.]], et z= [[0.66 0.25]], démontrant que z varie autour de mu avec un écart contrôlé par sigma = exp(0.5 * logvar). Cette technique est fondamentale pour tous les modèles génératifs basés sur des variables latentes." - ] - }, { "cell_type": "markdown", "id": "f3d5142c", @@ -629,13 +594,6 @@ "plt.show()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Le VAE entraîné est évalué sur la couverture des modes. La sortie Couverture VAE : [1, 1, 1, 1] => 4 / 4 modes confirme que l'auto-encodeur variationnel a appris à générer des échantillons dans les quatre régions cibles. Cette performance est remarquable car le VAE, contrairement au GMM, apprend une représentation non linéaire et peut capturer des structures plus complexes. Les deux visualisations montrent la distribution des données originales (à gauche) et des échantillons générés par le VAE (à droite), permettant une comparaison visuelle de la qualité de la génération. Cette comparaison visuelle est essentielle pour valider que le VAE produit des échantillons réalistes." - ] - }, { "cell_type": "markdown", "id": "fa126d60", @@ -749,13 +707,6 @@ " print(f\" step {i:4d} coverage={cov}/4 mean={mean}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La classe Generator du GAN (Generative Adversarial Network) est définie ici. Ce générateur prend un vecteur latent z de dimension 4 et le transforme en un échantillon de dimension 2 via un réseau de neurones à deux couches cachées (hid=64). La sortie affiche la couverture du GAN au cours de l'entraînement, avec des instantanés à différents pas (0, 600, ...). On observe que la couverture passe de 0/4 à 1/4 puis 2/4 modes, montrant que le GAN apprend progressivement à générer des échantillons dans de nouvelles régions de l'espace." - ] - }, { "cell_type": "markdown", "id": "d3771054", @@ -801,13 +752,6 @@ "print(\"Attendu : -log(0.881) ~ 0.1266\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La fonction generator_loss implémente la perte non-saturante pour le générateur. Elle calcule -log(sigmoid(d_fake_logits) + 1e-8), où d_fake_logits sont les logits produits par le discriminateur pour les faux échantillons. Cette perte encourage le générateur à produire des échantillons qui trompent le discriminateur (c'est-à-dire, des échantillons avec des logits élevés). Le petit epsilon (1e-8) évite les divisions par zéro. La sortie montre que generator_loss(sigmoid(2.0) ~ 0.881) = 0.1269, ce qui correspond bien à -log(0.881) ~ 0.1266, validant l'implémentation." - ] - }, { "cell_type": "markdown", "id": "00967ec8", @@ -916,13 +860,6 @@ "plt.show()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Le générateur GAN produit 4000 échantillons après entraînement complet. La sortie Couverture GAN : [1, 0, 1, 1] => 3 / 4 modes indique que le GAN couvre trois des quatre modes cibles. Le centroïde des échantillons GAN : [ 0.5 -0.57] donne une indication de la position moyenne des échantillons générés. Contrairement au VAE, le GAN n'a pas réussi à couvrir tous les modes, ce qui peut s'expliquer par la difficulté d'optimiser simultanément le générateur et le discriminateur dans un jeu à somme nulle. La visualisation permet de voir quels modes sont bien couverts et lequel est manquant." - ] - }, { "cell_type": "markdown", "id": "85604abc", @@ -1055,13 +992,6 @@ "print(\"Réseau de bruit entraîné.\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Les paramètres du modèle de diffusion sont initialisés ici. T=200 étapes de diffusion sont définies, avec un schedule linéaire pour beta de 1e-4 à 0.02. Alpha et alpha_bar sont calculés à partir de beta : alpha = 1 - beta et alpha_bar = cumprod(alpha). Ces paramètres contrôlent le processus de diffusion forward (ajout de bruit) et reverse (débruitage). La perte du modèle de diffusion est affichée au cours de l'entraînement, montrant une diminution progressive de la perte, ce qui indique que le modèle apprend à mieux prédire le bruit ajouté à chaque étape." - ] - }, { "cell_type": "markdown", "id": "b36acbb2", @@ -1111,13 +1041,6 @@ "print(\"Au début, x_t ~ x0 ; à la fin (t~T), x_t ~ bruit pur.\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La fonction q_sample implémente l'étape de bruitage forward du processus de diffusion. Elle prend x0 (l'échantillon original), t (l'étape de temps) et noise (le bruit gaussien), et calcule x_t = sqrt(alpha_bar[t]) * x0 + sqrt(1 - alpha_bar[t]) * noise. La sortie montre l'évolution de x_t pour différents pas de temps t : au début (t=0), x_t ~ x0 ; à la fin (t~199), x_t ~ bruit pur. Cette progression illustre comment le processus de diffusion transforme progressivement les données en bruit gaussien pur." - ] - }, { "cell_type": "markdown", "id": "07d198a2", @@ -1228,13 +1151,6 @@ "print(\"pas d'inférence :\", T)" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La fonction p_sample_full implémente l'étape de débruitage complet du processus de diffusion. Elle utilise le modèle de diffusion ( predicteur de bruit) pour prédire le bruit à chaque étape, puis calcule x_{t-1} à partir de x_t. La sortie Couverture diffusion : [1, 1, 1, 1] => 4 / 4 modes montre que le modèle de diffusion, une fois entraîné, peut générer des échantillons qui couvrent les quatre modes cibles. Le processus utilise T=200 étapes de débruitage pour passer du bruit pur à un échantillon propre, avec une couverture complète des modes." - ] - }, { "cell_type": "code", "execution_count": 17, @@ -1287,13 +1203,6 @@ "print(\"Trajectoire inverse stockée :\", len(traj), \"instantanés (tous les 60 pas).\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La cellule visualise la trajectoire de diffusion pour un point spécifique. Un point cible [2.5, 2.5] est bruité pendant le forward process (partie supérieure) et débruité pendant le reverse process (partie inférieure). La sortie texte précise : Haut : la cible se bruite (disparaît dans le bruit). Bas : le débruitage pendant l'échantillonnage. Trajectoire inverse stockée : 3 instantanés (tous les 60 pas). Cette visualisation illustre parfaitement le mécanisme de diffusion qui est au cœur des modèles de diffusion modernes comme DALL-E ou Stable Diffusion." - ] - }, { "cell_type": "markdown", "id": "79ab2497", @@ -1554,13 +1463,6 @@ "print(\"\\nESS max = 4 (les 4 modes distincts) ; ESS proche de 1 = effondrement de la diversité.\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Le verdict multi-seed du notebook, médiane sur 3 graines : GMM cov 4/4 **ESS 3.96** (0.0 s) ; VAE 4/4 **3.95** (7.7 s) ; GAN **3/4, 2.99** (24.7 s) ; Diffusion **4/4 mais ESS 1.62** (5.6 s) — et la sortie conclut elle-même : « ESS max = 4 (les 4 modes distincts) ; ESS proche de 1 = effondrement de la diversité ». Deux mesures, deux verdicts : la couverture dit qu'un mode est visité, l'ESS (exp(entropie) de la partition aux centres) dit combien de modes sont visités *équitablement*. La Diffusion couvre tout et s'effondre quand même ; le GAN, instable par graine (2/4, 3/4, 4/4 en seeds 42/0/1), paie sa médiane à 3/4 du temps le plus long." - ] - }, { "cell_type": "markdown", "id": "0d1b876a", @@ -1653,4 +1555,4 @@ }, "nbformat": 4, "nbformat_minor": 5 -} \ No newline at end of file +} diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb index 188582a741..23dfdea523 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb @@ -127,20 +127,6 @@ " print(\"gpu :\", torch.cuda.get_device_name(0))" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** L’environnement d’exécution utilise un GPU NVIDIA GeForce RTX 3090, ce qui accélère significativement les calculs tensoriels nécessaires à l’entraînement des modèles de diffusion, notamment les opérations matricielles massives.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture supplémentaire :** Verbatim de la cellule d'environnement : « device : cuda » et « gpu : NVIDIA GeForce RTX 3090 » — entraînement et sampling tournent sur GPU ; les convolutions répétées du UNet et les mini-batchs de 128 images en tirent directement parti." - ] - }, { "cell_type": "markdown", "id": "908a52ee", @@ -264,13 +250,6 @@ "print(\"alpha_bar au dernier pas cosinus :\", float(const_cos.alphas_cumprod[-1]))" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Les schedules de diffusion montrent que la décroissance de ᾱ (produit cumulé des alphas) est beaucoup plus rapide avec le schedule cosinus (2.43×10⁻⁹) qu’avec le linéaire (4.04×10⁻⁵), ce qui explique une diffusion plus progressive.\n" - ] - }, { "cell_type": "markdown", "id": "0d3f5e0d", @@ -289,13 +268,6 @@ "survit** à la fin du forward. Plus il est petit, plus $x_T$ est proche d'un bruit pur." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** La courbe des βₜ révèle que le seuil ᾱ < 0.5 est franchi bien plus tôt avec le schedule linéaire (pas 259) qu’avec le cosinus (pas 496), illustrant la décroissance exponentielle plus lisse du cosinus.\n" - ] - }, { "cell_type": "code", "execution_count": 3, @@ -355,20 +327,6 @@ "print(f\"alpha_bar passe sous {seuil} au pas {t_lin} (lineaire) vs {t_cos} (cosinus)\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le jeu MNIST réduit en 8×8 pixels contient 60 000 images normalisées dans l’intervalle [−1, 1], format compatible avec le modèle de diffusion qui travaille sur des données centrées.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture supplémentaire :** La visualisation comparative des βₜ pour les deux schedules met en évidence une propriété fondamentale : le schedule cosinus produit des valeurs de βₜ plus petites et plus uniformes aux pas initiaux, ce qui peut aider à préserver la structure globale de l’image pendant le forward process.\n" - ] - }, { "cell_type": "markdown", "id": "734d7707", @@ -468,20 +426,6 @@ "plt.tight_layout(); plt.show()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** La fonction de chargement de MNIST 8×8 vérifie que les images sont bien normalisées entre −1 et 1, format requis pour que le modèle de diffusion fonctionne correctement avec des données centrées sur zéro.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture supplémentaire :** La réduction de MNIST à 8×8 pixels permet non seulement de réduire la complexité computationnelle mais aussi d’accélérer l’entraînement, tout en conservant suffisamment d’informations pour que les chiffres restent reconnaissables après génération.\n" - ] - }, { "cell_type": "markdown", "id": "53e534e0", @@ -544,13 +488,6 @@ "betas_etudiant = mon_schedule_cosinus(T)" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le réseau SmallUNet compte 396 417 paramètres et produit une sortie de forme (4, 1, 8, 8), identique à l’entrée xₜ, ce qui permet la prédiction du bruit à chaque pas de diffusion.\n" - ] - }, { "cell_type": "code", "execution_count": 6, @@ -625,13 +562,6 @@ "temps** sinusoïdal, le même mécanisme que le positional encoding des Transformers." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** L’embedding temporel sinusoïdal transforme le pas de diffusion en un vecteur de dimension 64, permettant au modèle de conditionner ses prédictions sur le niveau de bruit présent dans l’image à chaque itération.\n" - ] - }, { "cell_type": "code", "execution_count": 7, @@ -734,27 +664,6 @@ "print(\"sortie :\", tuple(modele_demo(entree, t_demo).shape), \"(meme forme que x_t)\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le module TimeEmbedding utilise des fonctions sinusoïdales de différentes fréquences pour encoder le pas de temps t, créant un vecteur dense de dimension 64 qui permet au réseau UNet de savoir à quel stade du processus de débruitage il se trouve.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture supplémentaire :** Avec 396 417 paramètres, ce modèle reste relativement léger pour un réseau de diffusion, ce qui le rend adapté à des expériences rapides tout en offrant une bonne qualité de génération.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture supplémentaire :** Cet embedding temporel est crucial car il permet au modèle de différencier les différents pas de diffusion, ce qui est essentiel pour un processus itératif comme le débruitage.\n" - ] - }, { "cell_type": "markdown", "id": "edfeca84", @@ -783,13 +692,6 @@ "orthogonalité des canaux, monotonie de la fréquence)." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** L’entraînement du modèle avec schedule linéaire converge vers une perte finale de 0.0564 en 12 époques (42,3 s), montrant que le réseau apprend effectivement à inverser le processus de diffusion.\n" - ] - }, { "cell_type": "code", "execution_count": 8, @@ -886,13 +788,6 @@ "de `diffusers` en interne — mais ici, on l'écrit." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** La fonction entrainer implémente la boucle d’optimisation complète : forward pass pour prédire le bruit, calcul de la perte MSE, backpropagation, et mise à jour des poids avec Adam, le tout sur des mini-batches de 128 échantillons.\n" - ] - }, { "cell_type": "code", "execution_count": 10, @@ -1043,13 +938,6 @@ "print(f\"termine en {temps_lin:.1f} s\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** La fonction entrainer est le cœur du pipeline : elle initialise le modèle SmallUNet, charge le dataset MNIST 8×8, exécute la boucle d’entraînement sur le nombre d’époques spécifié, et retourne le modèle entraîné, l’historique des pertes, et le temps d’exécution mesuré avec précision.\n" - ] - }, { "cell_type": "markdown", "id": "c24afdcd", @@ -1077,14 +965,6 @@ "des $\\tilde\\beta_t$ pour $t=1,\\dots,T$ (longueur `T`)." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le sampler ancestral génère 64 images en 2,17 secondes soit 33,9 ms par image, démontrant l’efficacité du processus de débruitage itératif.\n", - "" - ] - }, { "cell_type": "code", "execution_count": 11, @@ -1208,13 +1088,6 @@ "print(\"loss finale :\", round(histo_lin[-1], 5))" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** La courbe de convergence montre que la perte MSE sur le bruit diminue rapidement dans les premières époques puis se stabilise, confirmant que le modèle de diffusion apprend bien à inverser le processus de bruitage.\n" - ] - }, { "cell_type": "markdown", "id": "2e88f6d2", @@ -1244,13 +1117,6 @@ "`3.6d`) : il est indispensable aux petits $t$, nuisible aux grands." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le récapitulatif confirme la supériorité du schedule linéaire : perte plus basse (0.0564 vs 0.10135) et MMD plus proche du plancher (0.00721 vs 0.01086), avec un temps de sampling similaire (~2,5 s).\n" - ] - }, { "cell_type": "code", "execution_count": 14, @@ -1336,20 +1202,6 @@ "grille(echant_lin, titre=\"DDPM ancestral — schedule lineaire (12 epochs)\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Les instantanés du processus de débruitage montrent visuellement comment le modèle reconvertit progressivement le bruit en images reconnaissables de chiffres MNIST, illustrant le reverse process de la diffusion.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture supplémentaire :** Le sampling ancestral est au cœur des modèles de diffusion et nécessite un pas de temps précis pour chaque itération de débruitage.\n" - ] - }, { "cell_type": "code", "execution_count": 15, @@ -1392,20 +1244,6 @@ "plt.tight_layout(); plt.show()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** L’entraînement du schedule cosinus termine en 37 secondes, soit 5 secondes de moins que le linéaire, mais atteint une perte finale plus élevée (0.10135 vs 0.0564), illustrant le compromis entre vitesse et qualité.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le modèle cosinus, bien qu’entraîné plus rapidement (37 s contre 42,3 s), produit des échantillons de moins bonne qualité comme le montre la MMD plus élevée (0.01086 vs 0.00721), ce qui reflète la sensibilité du schedule cosinus aux hyperparamètres.\n" - ] - }, { "cell_type": "markdown", "id": "42e992f6", @@ -1567,20 +1405,6 @@ " + f\" -> ecart-type {float(np.std(temps_lin_tous, ddof=1)):.3f} s\")\n" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Verbatim : « MMD lineaire : 0.00721 », « MMD cosinus : 0.01086 », « MMD vrai/vrai: 0.00324 <- plancher, effectif egal (1024 contre 1024) » — et, à kernel σ=1.0, la ligne « sigma=1.0 lineaire 0.00721 | cosinus 0.01086 | plancher 0.00324 -> rang : lineaire ». Le linéaire est plus proche du plancher, donc plus proche de la distribution vraie à cette bande passante. Le coût de génération, mesuré dans la même cellule : « Temps d'echantillonnage, modele lineaire, 3 tirages : 2.51 s, 2.37 s, 2.23 s -> ecart-type 0.140 s » — environ 6 % de variation : la comparaison de qualité ne se joue pas sur des temps bruités." - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Verbatim : « termine en 37.0 s » (cosinus) contre « termine en 42.3 s » (linéaire) — plus rapide, mais « epoque finale : loss lineaire 0.05640 | cosinus 0.10135 » : la perte cosinus vaut ~1,8 fois la linéaire. Convergé plus vite en temps, moins bien en perte : le compromis vitesse/qualité est mesuré ici ; cette seule cellule ne l'explique pas, et le protocole multi-seeds plus loin le jugera « INCONCLUSIVE »." - ] - }, { "cell_type": "code", "execution_count": 17, @@ -1646,20 +1470,6 @@ "print(f\"epoque finale : loss lineaire {histo_lin[-1]:.5f} | cosinus {histo_cos[-1]:.5f}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** La comparaison côte à côte des courbes d’apprentissage montre que le schedule linéaire converge plus vite et plus bas que le cosinus, avec une perte finale de 0.0564 contre 0.10135, confirmant l’avantage du linéaire pour ce dataset.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le récapitulatif final synthétise toutes les métriques : perte, MMD, et temps d’échantillonnage, fournissant une vue d’ensemble comparative des deux schedules testés sur ce dataset.\n" - ] - }, { "cell_type": "code", "execution_count": 18, @@ -1707,27 +1517,6 @@ "plt.tight_layout(); plt.show()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Ce dictionnaire récapitulatif permet une comparaison objective et quantitative entre les deux schedules, en agrégeant perte finale, qualité des échantillons (MMD), et efficacité (temps par échantillon), trois métriques essentielles pour évaluer un modèle génératif.\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** La grille juxtapose vraies images et échantillons des deux schedules. Le jugement visuel s'appuie sur les métriques imprimées à 12 époques : perte finale 0.0564 (linéaire) contre 0.10135 (cosinus), MMD 0.00721 contre 0.01086 — les deux sont en faveur du linéaire à ce budget d'entraînement." - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Ce dictionnaire de récapitulatif, en plus des métriques de base, inclut aussi le temps par échantillon pour 1024 images, ce qui permet d’évaluer non seulement la qualité mais aussi l’efficacité computationnelle de chaque schedule de diffusion testé.\n" - ] - }, { "cell_type": "code", "execution_count": 19, @@ -1775,13 +1564,6 @@ " f\"| plancher vrai/vrai {mmd_ref:.5f}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Ce récapitulatif final est déterminant pour le choix du schedule optimal : le schedule linéaire, avec une perte de 0.05640 et une MMD de 0.00721, se rapproche davantage du plancher théorique (MMD vrai/vrai à 0.00324) que le schedule cosinus (perte 0.10135, MMD 0.01086), tout en maintenant des temps de sampling comparables (2,51 s vs 2,45 s pour 1024 échantillons), ce qui en fait le choix privilégié pour ce modèle de diffusion sur MNIST 8×8.\n" - ] - }, { "cell_type": "markdown", "id": "39974ec0", @@ -1980,20 +1762,6 @@ "print(f\"\\n16 entrainements + echantillonnages en {(time.time() - t0) / 60:.1f} min\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Les lignes brutes par graine balayent la largeur du kernel : « lineaire budget=12 seed= 0 s=0.25 0.00198 s=0.5 0.00233 s=1.0 0.00750 s=2.0 0.02107 s=4.0 0.01302 » — et le même profil revient à chaque configuration : MMD minimale à σ=0,25 (≈0.002), maximale vers σ=2 (de 0.010 à 0.038 selon la config), souvent repartie à la baisse à σ=4. La MMD ne se lit donc pas en valeur absolue : elle varie d'un ordre de grandeur avec la bande passante du kernel RBF — c'est ce qui justifie le tableau médian par case qui suit, seule base de comparaison entre schedules. L'écart entre schedules s'y voit aussi : à budget 24, « cosinus seed= 1 s=2.0 0.03412 s=4.0 0.03830 » contre « lineaire seed=42 s=2.0 0.01013 s=4.0 0.00632 » — à large bande, l'écart cosinus/linéaire dépasse le facteur 3." - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le benchmark protocole lance 16 entraînements (4 seeds × 2 budgets × 2 schedules) pour évaluer la robustesse des modèles face à la variabilité aléatoire, avec un temps total de 17,7 minutes pour l’ensemble des runs.\n" - ] - }, { "cell_type": "code", "execution_count": 21, @@ -2104,13 +1872,6 @@ "plt.tight_layout(); plt.show()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le tableau imprimé (médiane sur 4 seeds) dit autre chose que « le linéaire gagne » : à budget 12 et σ=0,25, **cosinus 0.00197 < linéaire 0.00198** (rang : cosinus) ; le linéaire ne reprend la tête qu'aux grandes largeurs de bande (σ≥1) à budget 12, et le cosinus domine à budget 24 sur σ≤2. Verdict imprimé : « VERDICT : INCONCLUSIVE (4 cases lineaire / 6 cases cosinus) ». Détail que la lecture ne doit pas gommer : 0.00198 et 0.00197 sont **sous** le plancher vrai/vrai 0.00324 — à σ=0,25 la MMD médiane passe sous sa référence ; la sortie imprime le plancher sans commenter ce passage, la lecture s'arrête au fait." - ] - }, { "cell_type": "markdown", "id": "cb9bd49c", @@ -2251,8 +2012,8 @@ "end_time": "2026-09-19T14:15:34.128122", "environment_variables": {}, "exception": null, - "input_path": "D:\\Dev\\CoursIA-16795-qc\\MyIA.AI.Notebooks\\ML\\DataScienceWithAgents\\03-DeepLearning\\3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb", - "output_path": "D:\\Dev\\CoursIA-16795-qc\\MyIA.AI.Notebooks\\ML\\DataScienceWithAgents\\03-DeepLearning\\3.6c-Modeles-Generatifs-Diffusion-from-scratch_output.ipynb", + "input_path": "3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb", + "output_path": "3.6c-Modeles-Generatifs-Diffusion-from-scratch.ipynb", "parameters": {}, "start_time": "2026-09-19T13:50:56.357191", "version": "2.7.0" diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb index 401f47c857..09d05724bb 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb @@ -267,14 +267,6 @@ "print(f\"sigma(1) = sqrt(1 - alpha_bar(1)) = {math.sqrt(1 - alpha_bar_vp(1.0)):.8f} (proche de 1 : Q approx N(0, I))\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : La fonction `alpha_bar_vp(t)` implémente le schedule de bruit du VP-SDE (Variance Preserving Stochastic Differential Equation) en utilisant une interpolation linéaire du taux de bruit `beta(t)` entre BETA_MIN=0.1 et BETA_MAX=20.0. Le calcul de `alpha_bar(t) = exp(-integral(beta(s) ds from 0 to t))` montre que ce coefficient passe de 1.0 à t=0 à environ 4.3e-05 à t=1, confirmant que le bruit accumulé efface progressivement la structure des données. La valeur de `sigma(t) = sqrt(1 - alpha_bar(t))` passe corrélativement de 0 à ~0.99998, illustrant comment le processus de diffusion ajoute du bruit gaussien de variance croissante. Cette paramétrisation est cruciale car elle détermine la quantité de bruit injecté à chaque pas de la dynamique de débruitage.\n" - ], - "id": "c14ca820" - }, { "cell_type": "code", "execution_count": 3, @@ -674,14 +666,6 @@ "le réseau devra apprendre." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « melange : 5 composantes | 4096 echantillons de reference », « poids : [0.24 0.2 0.18 0.22 0.16] ». Les moyennes, dans le code : [-1.60, 1.10], [1.70, 1.30], [1.90, -1.20], [-1.80, -1.40], [0.00, 0.00] — cinq modes bien séparés, dont un au centre. Les FORMES (σx, σy, ρ) par composante font varier orientations et échelles (« les orientations different, le score n'est pas radial », dit le commentaire du code) : déterminants de covariance de ~0.00058 (composante 3, σ 0.30/0.10, ρ -0.60) à 0.1296 (composante 5, σ 0.60/0.60, ρ 0). Cette cible multimodale est le banc d'essai de toutes les dynamiques qui suivent." - ], - "id": "e1956603" - }, { "cell_type": "code", "execution_count": 8, @@ -1203,14 +1187,6 @@ "print(f\"|cible| a t = 1.0 : {1/np.sqrt(1-alpha_bar_vp(1.0)):10.3f}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Le champ de score exact est calculé analytiquement sur une grille 26x26 couvrant l'espace [-3.2, 3.2]^2 à 4 instants différents (t=0.0, 0.3, 0.6, 0.9). Le score, défini comme le gradient du logarithme de la densité, est calculé pour le mélange gaussien bruité à chaque instant t. À t=0, le score correspond au score de la distribution cible non bruité. À mesure que t augmente, le bruit domine et le score devient de plus en plus simple, tendant vers un champ linéaire car la distribution s'approche d'une gaussienne centrée. Ces visualisations montrent comment le score évolue pour guider le processus de débruitage vers la distribution cible, avec des contours qui deviennent de plus en plus lisses à mesure que le bruit augmente.\n" - ], - "id": "65281af4" - }, { "cell_type": "markdown", "id": "0154e9fd", @@ -1401,14 +1377,6 @@ "print(f\"duree d'entrainement : {duree_entrainement:.1f} s ({len(histo)} pas)\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « pas 2000 / 8000 loss epsilon = 0.28111 », puis 0.25420, 0.25147, « pas 8000 / 8000 loss epsilon = 0.25051 » ; « loss epsilon : premiere tranche 0.37907 -> derniere tranche 0.25127 » et « duree d'entrainement : 49.2 s (8000 pas) ». La perte décroît et se stabilise juste au-dessus de 0.25. Architecture, dans le code : « encodage de temps de Fourier + 3 couches cachees », 35714 paramètres, appareil cuda." - ], - "id": "b78aa9d9" - }, { "cell_type": "markdown", "id": "c19bee7d", @@ -1643,14 +1611,6 @@ "print(f\"borne superieure (predicteur eps = 0, soit ne rien predire) : {2.0:.5f}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim du tableau « loss epsilon moyenne par tranche de t, contre le plancher intrinseque » : ratios mesuré/plancher 1.032, 1.028, 1.026, 0.979, 0.999, 1.022 sur [0.00, 0.60] — puis 1.105, 1.229, **2.507, 12.947** sur [0.60, 1.00]. Le ratio n'est PAS stable : il reste à ~3 % du plancher là où la perte est grande, mais explose aux grands t — non parce que le modèle y est mauvais, mais parce que le plancher lui-même y devient minuscule (0.00054 sur [0.90, 1.00] contre 0.00693 mesuré : l'écart absolu est petit, le ratio ne se lit pas seul). Bilan global imprimé : « moyenne sur t : mesuree 0.50619 | plancher 0.49562 | mesuree/plancher 1.0213 », contre « borne superieure (predicteur eps = 0, soit ne rien predire) : 2.00000 » — prédire quelque chose divise la perte par ~2 par rapport à ne rien prédire." - ], - "id": "2dfaa62a" - }, { "cell_type": "markdown", "id": "98ccccff", @@ -1843,31 +1803,6 @@ "plt.tight_layout(); plt.show()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim du tableau « t | EQM | similarite cosinus | |s exact| moyen » : t=0.02 **EQM 201.42536, cosinus 0.8533** ; t=0.10 EQM 2.03487, cosinus 0.9740 ; t=0.30 0.01692/0.9931 ; t=0.50 0.00947/0.9991 ; t=0.70 0.01361/0.9991 ; t=0.95 0.01596/0.9990. Lecture honnête : à t=0.02 l'EQM explose et le cosinus tombe à 0.85 — précisément là où la cible DSM diverge (|cible| = 36.6 à t=0.005, section précédente). Dès t=0.10 le champ appris suit le champ exact (cosinus > 0.97), et il y colle (≥ 0.999) de t=0.30 à t=0.95. Le champ appris est fidèle partout sauf au tout début de la trajectoire — le même défaut que la pondération de la perte compense à l'entraînement." - ], - "id": "2c130511" - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : La figure juxtapose champ exact et champ appris à t petit et t grand — l'œil y retrouve ce que le tableau vient de mesurer : structure suivie dès t=0.10 (cosinus 0.9740), quasi confondue aux grands t (0.999), décalage visible seulement au plus petit t." - ], - "id": "b1f81b0d" - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : La démonstration de la divergence de la cible aux petits t est cruciale pour comprendre pourquoi la pondération est nécessaire dans la perte DSM (Denoising Score Matching). Le calcul montre que |cible| = 36.6 à t = 0.005, alors qu'elle reste proche de 1.0 pour t ≥ 0.5 (1.042 à t=0.5, 1.000 à t=1.0). Cette divergence s'explique par le fait que la distribution de référence devient très concentrée quand t approche 0, et la densité peut devenir extrêmement grande dans certaines régions de l'espace. La pondération par alpha_bar(t) dans la perte DSM compense cet effet en donnant moins de poids aux petits t où la cible diverge, et plus de poids aux grands t où la cible est bien comportée. Sans cette pondération, l'entraînement serait dominé par les petits t et le modèle n'apprendrait pas correctement à reconstruire les données. Cette technique est au cœur des méthodes modernes d'échantillonnage par diffusion et explique pourquoi les modèles de score peuvent être entraînés efficacement sur des distributions complexes. La démonstration numérique montre clairement que l'écart entre les versions pondérée et non pondérée de la perte serait énorme sans cette correction.\n", - "" - ], - "id": "518428f9" - }, { "cell_type": "markdown", "id": "ea93cf09", @@ -2251,14 +2186,6 @@ " return part, int((part >= seuil).sum())" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Le test des quatre conventions de signe, verbatim : « derive = -1*(-beta/2 x) +1*beta*s | MMD=0.00079 | modes=5/5 <-- RETENUE » ; les trois autres : 0.68029 (modes 1/5), 0.04392 (modes 5/5), 0.68030 (modes 1/5). Le détail spectaculaire : les mauvais signes font **exploser la variance** — « Var empirique 141092958951420.7500 » contre « attendue 4.0987 » à t=0.00 pour l'un — et le « +1 +1 », qui passe le test des modes, **sous-disperse** (Var ~0.7 contre ~2.0 attendue) : seul le signe RETENU colle à la variance attendue sur toute la trajectoire (4.1501 vs 4.0987 à t=0.00, 1.9599 vs 2.0001 à t=1.00). Une dynamique de diffusion n'est pas une équation « au signe près »." - ], - "id": "945261c2" - }, { "cell_type": "markdown", "id": "8023ea49", @@ -2526,14 +2453,6 @@ "print(f\"{'N (echantillons par methode)':42s} {N_ECH}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Le tableau final, verbatim : Langevin recuit (réseau) MMD=0.00894 modes=5/5 12.6 s ; **Euler-Maruyama (réseau) 0.00156 5/5 1.0 s** ; Prédicteur-correcteur 0.00259 5/5 1.8 s ; Euler-Maruyama (score exact, contrôle) 0.00025 5/5 2.5 s ; Euler-Maruyama (mauvais signe, contre-exemple) 0.68030 **modes=1/5** 2.6 s ; « plancher vrai/vrai (tirage independant) MMD=0.00016 ». Lecture : le score exact frôle le plancher (0.00025 contre 0.00016), le réseau EM atteint 10× le plancher pour ~12× moins de temps que le Langevin recuit — et le contre-exemple mauvais signe, même sampler, tombe à 1 mode sur 5 : la qualité vient du score, pas du sampler." - ], - "id": "727f3548" - }, { "cell_type": "code", "execution_count": 26, @@ -2837,8 +2756,8 @@ "end_time": "2026-09-19T13:45:26.848350", "environment_variables": {}, "exception": null, - "input_path": "D:\\Dev\\CoursIA-16795-qc\\MyIA.AI.Notebooks\\ML\\DataScienceWithAgents\\03-DeepLearning\\3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb", - "output_path": "D:\\Dev\\CoursIA-16795-qc\\MyIA.AI.Notebooks\\ML\\DataScienceWithAgents\\03-DeepLearning\\3.6d-Modeles-Generatifs-Score-SDE-from-scratch_output.ipynb", + "input_path": "3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb", + "output_path": "3.6d-Modeles-Generatifs-Score-SDE-from-scratch.ipynb", "parameters": {}, "start_time": "2026-09-19T13:44:21.869039", "version": "2.7.0" @@ -2846,4 +2765,4 @@ }, "nbformat": 4, "nbformat_minor": 5 -} +} \ No newline at end of file diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.7-Distillation-Maitre-Eleve.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.7-Distillation-Maitre-Eleve.ipynb index 84228b2768..0040cb49d2 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.7-Distillation-Maitre-Eleve.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.7-Distillation-Maitre-Eleve.ipynb @@ -170,13 +170,6 @@ "print(f\"ratio : {n_params(teacher) / n_params(student):>6.1f}x\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « maitre : 235146 params », « eleve : 26506 params », « ratio : 8.9x », et sur le test « maitre : acc=0.8906 ece=0.0362 params=235146 [42s] ». Attention à l'attribution : 89,06 % est l'exactitude du MAÎTRE, pas de l'élève compressé. Le tableau final (section 8) donne le vrai trade-off : maitre 235146 params / 920.8 KB / 1.24 ms / acc 0.8906 / ECE 0.0362 ; baseline 26506 / 105.8 KB / 0.19 ms / 0.7948 / 0.0736 ; **distille** 26506 / 105.8 KB / 0.23 ms / **0.8132 / 0.0462**. Neuf fois plus petit que le maître, +1,8 point et mieux calibré que l'élève seul — c'est la distillation. Prudence sur la latence : distille 0.23 ms reste plus lent que la baseline 0.19 ms ; le gain de vitesse est contre le maître (1.24 ms), pas contre l'élève dur." - ] - }, { "cell_type": "markdown", "id": "c36f9023", @@ -265,13 +258,6 @@ " return model" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture du code** : La loss s'écrit `L_hard = F.cross_entropy(logits_student, y)` (terme dur) + KL tempéré : `F.kl_div(log_softmax(z_eleve/T), softmax(z_maitre/T)) * T²` (terme mou). Les deux rôles, dans la base : « à la limite `T → ∞` toutes les classes deviennent équiprobables (l'information s'efface), à `T → 1` on retombe sur la distribution dure du maître », et « le facteur `T²` compense l'amortissement du gradient des cibles molles quand `T` grandit » — facteur vérifié numériquement à la section suivante. C'est lui qui prépare la leçon de la grille de la section 5 : trop lissée (`T=5`), la cible du maître devient bruit pour l'élève." - ] - }, { "cell_type": "markdown", "id": "14822d8f", @@ -549,13 +535,6 @@ " print(f\"{a:>6.1f} {T:>4.0f} {st.mean(A):>9.4f} {st.mean(E):>9.4f}{tag}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « === BASELINE student-from-scratch (1500 etiquettes, 4 graines) === », « acc = 0.8029 +/- 0.0054 ece = 0.0684 ». La grille α/T ne dit pas « supérieur partout » : meilleure case `alpha=0, T=1` (acc 0.8145, ECE 0.0458) ; mais `alpha=0, T=5` retombe à **0.7940, SOUS la baseline** (ECE 0.0934), et `alpha=0.5, T=5` à 0.8007. La base tranche elle-même : « le gain est réel mais modeste (+0.0116 en moyenne : 0.8145 contre 0.8029) » et « T=5 casse la distillation ». La distillation gagne ici en **calibration** (ECE 0.0458 contre 0.0684, ~33 % d'erreur en moins) — pas en exactitude à toute température." - ] - }, { "cell_type": "markdown", "id": "113a9f2e", @@ -749,13 +728,6 @@ "`INCONCLUSIVE` si une jambe passe et pas l’autre, `NO BEATS` si aucune ne passe.\n" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture du protocole** : Verbatim : « Le verdict est `BEATS` si : (a) le gain moyen atteint au moins deux écarts-types des différences appariées, sur l'exactitude et sur la calibration ; (b) le test de Diebold–Mariano sur la perte par exemple (cross-entropie) donne un `p` médian < 0.05 » — et « Sinon on dégrade honnêtement : `INCONCLUSIVE` si une jambe passe et pas l'autre, `NO BEATS` si aucune ne passe ». Le plan est apparié : chaque paire (fold, graine) entraîne la baseline (élève dur) ET l'élève distillé (`alpha=0, T=1`) sur le même tirage de budget — la différence mesurée n'est pas entachée de variance d'échantillonnage entre les deux modèles." - ] - }, { "cell_type": "code", "execution_count": 9, @@ -958,13 +930,6 @@ "# TODO etudiant : expliquer l'effet d'une T trop grande (la cible tend vers l'uniforme)." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « 5 folds x 4 graines = 20 paires appariees », « exactitude : gain +0.0064 +/- 0.0113 | edge +0.6 sigma | victoires 17/20 », « calibration: gain +0.0166 +/- 0.0122 | edge +1.4 sigma | victoires 18/20 », « DM (CE/exemple): p median = 0.0000 | biais CE baseline 0.6337 vs distille 0.5813 » — et le verdict imprimé : « **VERDICT : INCONCLUSIVE** ». Le protocole du dépôt exige 2σ sur les DEUX jambes pour `BEATS` ; ici l'exactitude ne passe pas (+0.6 σ) et la calibration frôle (+1.4 σ, 18/20 victoires). Lecture honnête : la tendance favorise le distillé (le test DM sur la perte par exemple est net, p médian 0.0000), mais le notebook dégrade honnêtement en INCONCLUSIVE — la calibration est le signal le plus solide, l'exactitude reste une tendance faible." - ] - }, { "cell_type": "code", "execution_count": 12, @@ -1081,4 +1046,4 @@ }, "nbformat": 4, "nbformat_minor": 5 -} \ No newline at end of file +} diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.8-Representations-Contrastives.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.8-Representations-Contrastives.ipynb index ef89989db8..8c34ce344c 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.8-Representations-Contrastives.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/03-DeepLearning/3.8-Representations-Contrastives.ipynb @@ -116,13 +116,6 @@ "print(f\"vocab: {V} mots, phrases: {len(phrases)}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Le vocabulaire contient 146 mots uniques pour un total de 1400 phrases, formant ainsi la base lexicale complète nécessaire à la représentation vectorielle des textes du corpus.\n" - ] - }, { "cell_type": "markdown", "id": "sec-2", @@ -171,13 +164,6 @@ "print(f\"X.shape = {X.shape}, mean L1 = {np.abs(X).sum(axis=1).mean():.3f}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « X.shape = (1400, 146), mean L1 = 1.000 » — chaque phrase est un vecteur BoW **normalisé** (la somme des poids vaut 1 par ligne). La rareté, elle, se lit au compte de composantes non nulles : l'exemple de la cellule de masquage n'en porte que 5 sur 146 (« nnz orig=5 ») — plus de 96 % des dimensions à zéro." - ] - }, { "cell_type": "markdown", "id": "sec-3", @@ -265,13 +251,6 @@ " print(f\" politique={nom:<5} : nnz orig={nz_orig}, nnz vue={nz_vue}, cosinus={cos:.3f}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La politique de masquage aléatoire avec p=0.30 réduit effectivement et de manière contrôlée le nombre total de composantes non-nulles présentes (passant de 5 à seulement 3 dans cet exemple concret et illustratif) tout en conservant une similarité cosinus élevée de 0.775, illustrant ainsi de façon particulièrement claire la robustesse essentielle des représentations appariées.\n" - ] - }, { "cell_type": "markdown", "id": "sec-4", @@ -356,13 +335,6 @@ "print(f\"||z|| par ligne (doit valoir ~1.0) : {norms}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "L'encodeur MLP à deux couches produit systématiquement et de manière fiable des vecteurs de sortie normalisés avec une norme L2 exactement égale à 1.0 pour chaque ligne, cette propriété de normalisation étant essentielle pour utiliser efficacement la similarité cosinus comme principale métrique de comparaison entre représentations.\n" - ] - }, { "cell_type": "markdown", "id": "sec-5", @@ -480,13 +452,6 @@ "# à log(2) qui mesure l'apprentissage réel." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La perte InfoNCE calculée montre clairement et de manière précise que le cas 1 avec des paires strictement identiques donne une perte de 0.3133 correspondant exactement et sans erreur à la valeur théorique attendue -log(e/(e+1)), validant ainsi de façon définitive l'implémentation correcte et conforme de la fonction de perte contrastive.\n" - ] - }, { "cell_type": "markdown", "id": "sec-6", @@ -589,13 +554,6 @@ "print(f\"\\nLoss finale : {pertes_main[-1]:.4f}, log(64) = {math.log(64):.4f} (borne sup = log(batch))\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim de l'entraînement (« mask vs swap, τ=0.1, 8 époques, graine 0 ») : « époque 1 : loss=1.3217 », « époque 4 : loss=0.7024 », « époque 5 : loss=0.7460 » (rebond), « époque 7 : loss=0.5788 » (minimum), « époque 8 : loss=0.5975 ». Bilan imprimé : « Loss finale : 0.5975, log(64) = 4.1589 (borne sup = log(batch)) » — la perte finit ~7× sous le plancher « ne rien discriminer » : l'encodeur sépare ses paires positives des négatives du mini-lot, mais la descente n'est pas lisse (deux rebonds en huit époques)." - ] - }, { "cell_type": "markdown", "id": "sec-7", @@ -679,13 +637,6 @@ "print(f\" (chance = 1/{len(THEMES)} = {1/len(THEMES):.3f})\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « Sonde linéaire sur encodeur CONTRASTIF : accuracy = 0.432 » — sur le mini-corpus à 7 thèmes (base, section 1 : « 7 thèmes sémantiques »), la chance pure est 1/7 ≈ 0.143, et les thèmes sont « utilisés uniquement à l'évaluation aval » : la sonde lit une structure que le pré-entraînement n'a jamais vue comme cible. Le récapitulatif suivant réserve une surprise plus forte que ce simple écart à la chance." - ] - }, { "cell_type": "markdown", "id": "sec-8", @@ -783,13 +734,6 @@ "print(f\" Supervisé from scratch (borne sup): {acc_sup:.3f}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim du « Récapitulatif accuracy sonde linéaire » : « Aléatoire (init, gelé) : 0.161 », « Skip-gram simplifié (BoW brut) : 0.154 », « CONTRASTIF (pré-entraîné) : 0.432 ← cible », « Supervisé from scratch (borne sup): 0.368 ». La hiérarchie attendue voudrait le supervisé au-dessus — c'est l'inverse qui est imprimé : le pré-entraîné dépasse sa « borne sup » de +0.064 et vaut ~2.7× l'encodeur gelé. À ce budget de données, entraîner un MLP étiqueté from scratch fait moins bien que sonder un espace appris sans labels." - ] - }, { "cell_type": "markdown", "id": "sec-9", @@ -863,13 +807,6 @@ "print(f\" Verdict collapse : {'OUI (collapse)' if diag['sim_inter_mean'] > 0.95 or diag['top1_var_share'] > 0.95 else 'NON'}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim des « Diagnostics collapse (encodeur contrastif) » : « Dimensions pour 95% de variance : 22 / 32 », « Part de variance sur la dim 1 : 0.096 », « Similarité cosinus inter-phrases : 0.184 », « Verdict collapse : NON ». Les seuils de la section sont passés : le collapse signerait ≥95 % de la variance sur UNE dimension — ici la première n'en porte que 9,6 % — et des phrases toutes semblables imprimeraient une similarité > 0.95 — ici 0.184. L'espace utilise réellement ses 32 dimensions." - ] - }, { "cell_type": "markdown", "id": "sec-10", @@ -957,13 +894,6 @@ " print(f\"{tau:>6.2f} {pols[0]+'+'+pols[1]:<14} {m:>10.3f} {s:>10.3f} {accs}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim de l'ablation (« 3 températures × 3 paires d'augmentations × 3 graines = 27 runs », accuracy moyenne ± écart-type) : la meilleure case est « 0.10 swap+swap 0.374 0.017 », devant « 0.10 mask+swap 0.368 0.015 » et « 0.05 mask+swap 0.360 0.040 » ; le bas du tableau est τ=0.50 partout (0.248–0.340). Lecture honnête : au sommet, les cases se chevauchent à un écart-type près (0.374±0.017 vs 0.368±0.015) — ce qui est net, c'est le CLUSTER : τ=0.1 domine et τ=0.5 dégrade systématiquement (jusqu'à −0.13). L'« importance des hyperparamètres » se lit ici : température, oui ; paire d'augmentations, à un chevauchement près." - ] - }, { "cell_type": "markdown", "id": "sec-11", @@ -1190,4 +1120,4 @@ }, "nbformat": 4, "nbformat_minor": 5 -} \ No newline at end of file +} diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/Lab6-First-Agent.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/Lab6-First-Agent.ipynb index abf8ea2e07..aff58a93bc 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/Lab6-First-Agent.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track1-LangChain/Day3-Data-Agents/Labs/Lab6-First-Agent/Lab6-First-Agent.ipynb @@ -51,7 +51,7 @@ "\n", "### Duree estimee : 30-40 minutes\n", "\n", - "---" + "***" ] }, { @@ -274,14 +274,6 @@ "print(\"Prompt REACT configure avec ChatPromptTemplate\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture ancrée** : Le template, verbatim du code : `(\"system\", \"You are a helpful assistant. Use the tools available to help the user.\")` puis `MessagesPlaceholder(\"messages\")` — la sortie confirme « Prompt REACT configure avec ChatPromptTemplate ». Structure fixe (le rôle système, qui ordonne d'utiliser les outils) + slot variable (l'historique des messages) : LangGraph injectera la conversation dans le slot à chaque tour de la boucle REACT." - ], - "id": "37a3f099-783f-4cea-ba61-137b35bd32a1" - }, { "cell_type": "markdown", "id": "2ab21f9e", @@ -359,14 +351,6 @@ "print(\"Agent REACT cree avec LangGraph\")" ] }, - { - "cell_type": "markdown", - "id": "3604fb2c-b426-40e2-89a6-6f59ca2a83c0", - "metadata": {}, - "source": [ - "**Lecture ancree** : la cellule imprime « Agent REACT cree avec LangGraph », puis un `LangGraphDeprecatedSinceV10` integral : « create_react_agent has been moved to `langchain.agents`. Please update your import to `from langchain.agents import create_agent`. Deprecated in LangGraph V1.0 to be removed in V2.0. » Le traceback recopie la ligne fautive, `create_react_agent(model=llm, tools=tools, prompt=prompt)` : trois arguments nommes, trois roles — le modele decide, la liste d'outils agit, le prompt cadre. La boucle REACT n'est pas ecrite a la main : elle est COMPILEE par cet appel, c'est ce que « prebuilt » annonce dans `from langgraph.prebuilt import create_react_agent`. L'agent fonctionne aujourd'hui ; l'import migrera en v1.0 et disparaitra en v2.0." - ] - }, { "cell_type": "markdown", "id": "ba74b487", @@ -647,7 +631,7 @@ "\n", "À vous d'étendre l'agent en lui ajoutant un nouvel outil mathématique !\n", "\n", - "---\n", + "***\n", "**Retour au sommaire** : [Index ML](../../../../README.md)\n" ] }, diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab11-Planner-Coder-Loop.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab11-Planner-Coder-Loop.ipynb index e4c2a67313..d47ebc134b 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab11-Planner-Coder-Loop.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab11-Planner-Coder-Loop.ipynb @@ -163,13 +163,6 @@ "print(\"Imports OK : pandas, numpy, LLMClient et runtime Google ADK réel\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Les imports nécessaires au notebook sont validés avec succès. Le message Imports OK : pandas, numpy, LLMClient et runtime Google ADK réel confirme que toutes les dépendances sont disponibles, y compris le client LLM pour l'interaction avec les grands modèles de langage. Ce notebook utilise l'Agent Development Kit (ADK) de Google pour démontrer une boucle complète de type Data Science STAR (Search, Transform, Analyze, Report). L'ADK fournit les outils nécessaires pour créer des agents autonomes capable d'exécuter des tâches d'analyse de données complexes." - ] - }, { "cell_type": "code", "execution_count": 2, @@ -204,13 +197,6 @@ "print(f'Provider: {settings.active_provider}')" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La configuration du fournisseur LLM est affichée. Provider: openai indique que le notebook utilise les modèles OpenAI via l'ADK. Le modèle configuré est utilisé pour toutes les tâches de raisonnement dans la boucle DS-STAR. Cette configuration centralisée permet de changer facilement de fournisseur ou de modèle sans modifier le code des agents eux-mêmes. L'ADK abstraït les détails d'implémentation des différents fournisseurs de LLM, offrant une interface unifiée pour l'interaction avec les modèles." - ] - }, { "cell_type": "markdown", "id": "19c64070", @@ -297,13 +283,6 @@ "print(\"Dataclasses definies : Plan, ExecutionResult, VerificationStatus (SUCCESS, NEEDS_REFINEMENT, FAILED)\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Les dataclasses définies structurent l'ensemble de la boucle agentique. Plan contient les étapes (steps) et le raisonnement (reasoning) pour décomposer une question en un plan d'analyse exécutable. ExecutionResult stocke le succès ou l'échec de l'exécution, la sortie produit et les éventuelles erreurs. VerificationStatus est une énumération avec trois états : SUCCESS (le résultat est correct et complet), NEEDS_REFINEMENT (le résultat est partiel ou nécessite une amélioration), et FAILED (l'exécution a échoué). Ces structures de données fournissent un cadre clair pour organiser le flux de travail de l'agent DS-STAR." - ] - }, { "cell_type": "markdown", "id": "399bb4a1", @@ -417,13 +396,6 @@ "print(\"Classe Planner definie : decomposition de questions en plans d'analyse (3-5 etapes)\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La classe Planner est responsable de la décomposition des questions en plans d'analyse. Elle utilise le LLM pour générer un plan structuré avec 3 à 5 étapes exécutables. La méthode create_plan prend une question et un contexte, puis retourne un objet Plan contenant les étapes à suivre et le raisonnement sous-jacent. Ce composant est crucial pour transformer une requête utilisateur vague en une séquence d'actions précises et exécutables. La sortie confirme que la classe est correctement définie et prête à être utilisée dans la boucle DS-STAR." - ] - }, { "cell_type": "markdown", "id": "db065e42", @@ -522,13 +494,6 @@ "print(\"Classe Coder definie : generation de code Python a partir d'un plan d'analyse\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La classe Coder transforme un plan en code Python exécutable. Elle utilise le LLM pour générer du code qui implémente les étapes du plan. La méthode generate_code prend un Plan et un contexte, puis retourne une chaîne de caractères contenant le code Python à exécuter. Ce composant permet de passer de l'intention (le plan) à l'action (le code). La sortie indique que la classe Coder est définie et fonctionnelle, prête à générer du code à partir des plans produits par le Planner." - ] - }, { "cell_type": "markdown", "id": "88c4fe44", @@ -620,13 +585,6 @@ "print(\"Classe Executor definie : execution securisee de code Python avec capture stdout\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La classe Executor est chargée d'exécuter le code généré de manière sécurisée. Elle utilise un DataFrame pandas comme source de données et exécute le code dans un namespace contrôlé avec pandas, numpy, et d'autres utilitaires. La méthode execute_code capture stdout et gère les erreurs, retournant un ExecutionResult avec le succès/échec et les éventuelles sorties ou erreurs. Cette isolation est essentielle pour la sécurité : elle empêche le code généré d'accéder à des ressources non autorisées ou de modifier l'environnement d'exécution de manière inattendue." - ] - }, { "cell_type": "markdown", "id": "8c6cd29a", @@ -726,13 +684,6 @@ "print(\"Classe Verifier definie : validation des resultats (SUCCESS / NEEDS_REFINEMENT / FAILED)\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La classe Verifier valide les résultats produits par l'Executor. Elle utilise le LLM pour évaluer si le résultat répond correctement à la question initiale. La méthode verify prend la question et le ExecutionResult, puis retourne un VerificationStatus (SUCCESS, NEEDS_REFINEMENT ou FAILED) avec un feedback. Ce composant permet de détecter si la réponse est incomplète, incorrecte, ou si elle nécessite des précisions supplémentaires. La sortie confirme la définition de cette classe de vérification." - ] - }, { "cell_type": "markdown", "id": "13ac199c", @@ -860,13 +811,6 @@ "print(\"Classe DSStarAgent definie : orchestrateur Planner-Coder-Executor-Verifier avec boucle iterative\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Le DSStarAgent orchestre l'ensemble de la boucle Planner-Coder-Executor-Verifier. Il initialise les quatre composants et gère leur interaction itérative. La méthode analyze exécute la boucle complète : elle commence par créer un plan, puis génère le code correspondant, l'exécute, vérifie le résultat, et répète si nécessaire (jusqu'à max_iterations fois). Chaque itération affine le résultat en fonction du feedback du Verifier. La sortie confirme que l'orchestrateur est correctement initialisé avec les quatre composants essentiels." - ] - }, { "cell_type": "markdown", "id": "1060e324", @@ -1033,13 +977,6 @@ "df.head()" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture ancrée** : « Dataset reproductible : 200 lignes, 5 colonnes » — et les colonnes réelles, visibles dans l'aperçu : **date, product, region, revenue, units** (2024-01-01, A, Sud, 3909.28, 2...). Graine fixée : `default_rng(42)`. Ces noms exacts sont ce que le Planner doit relire dans le schéma avant de coder — l'erreur de la boucle suivante viendra précisément d'un nom mal restitué." - ] - }, { "cell_type": "markdown", "id": "98d61c5a", @@ -1131,13 +1068,6 @@ " print(f\"Erreur: {result.get('error', 'Inconnu')}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture ancrée** : La question posée au code, verbatim : « Quelle est la region avec le plus grand revenu moyen ? ». La boucle imprimée : [PLANNER] plan en 5 étapes, [CODER] génération, [EXECUTOR] exécution — puis « [ERROR] ['revenu'] » et « Erreur: Max iterations atteint ». Le KeyError `['revenu']` se lit tout seul : le code généré a appelé la colonne « revenu » là où le dataset dit « revenue » — l'orthographe du schéma est une partie du contrat, et la boucle à 1 itération ne s'en relève pas." - ] - }, { "cell_type": "markdown", "id": "c1c4cc05", @@ -1219,13 +1149,6 @@ ")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La fonction get_dataset_schema expose le schéma du dataset au Planner ADK. Elle retourne un dictionnaire avec le nombre de lignes, les colonnes disponibles et leurs types. Cette information permet au Planner de générer des plans qui tiennent compte de la structure réelle des données. La sortie Outil ADK prêt : get_dataset_schema expose 200 lignes et 5 colonnes confirme que l'outil est correctement configuré et peut être utilisé par le Planner pour créer des plans adaptés au dataset spécifique." - ] - }, { "cell_type": "markdown", "id": "d5bab19c", @@ -1402,13 +1325,6 @@ "print(\"Boucle ADK définie : Planner, Coder et Verifier utilisent de vrais Agent/Runner\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La fonction async adk_analyze exécute la boucle DS-STAR complète de manière asynchrone. Elle utilise les vrais composants ADK (Agent, Runner, Session) pour chaque étape. Le Planner utilise un Agent ADK avec un Runner pour créer le plan, le Coder utilise un autre Agent ADK pour générer le code, et le Verifier utilise un troisième Agent ADK pour valider le résultat. La sortie Boucle ADK définie : Planner, Coder et Verifier utilisent de vrais Agent/Runner confirme que l'implémentation utilise bien l'infrastructure ADK de Google plutôt que des simulations locales." - ] - }, { "cell_type": "markdown", "id": "f0bc8702", @@ -1508,20 +1424,6 @@ "print(f\"Sortie Executor:\\n{adk_result['output']}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture ancrée** : « PREUVE GOOGLE ADK RÉELLE » : planner-0 (session lab11-planner-0, 3 events, tool_calls=get_dataset_schema), coder-0 (1 event, aucun), verifier-0 (1 event, aucun) — puis le verdict qui compte : « Planner tool round-trip: True », « Succès: True », « Région attendue (calcul déterministe): Ouest », « Verdict LLM: SUCCESS » avec la sortie Executor : « La région avec le plus grand revenu moyen est Ouest avec un revenu moyen de 2800.6191304347826 ». Trois agents distincts, un seul fait un appel d'outil — et la réponse finale croise le calcul déterministe (Ouest) avec le verdict du LLM." - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture ancrée** : Le contre-exemple, même notebook, autre question (« Quelle region genere le plus de revenus ? ») : itération 1/2 — « [ERROR] Cannot describe a DataFrame without columns » ; itération 2/2 — « [OUTPUT] Le DataFrame est vide », « Aperçu du DataFrame après nettoyage : Empty DataFrame, Columns: [], Index: [] », verdict « [STATUS] failed: Resultat insuffisant », « Reussite: False, Iterations: 2 ». La boucle Planner-Coder-Executor-Verifier ne garantit pas le succès : ici le code généré a détruit le DataFrame, le Verifier l'a vu, et la sortie honnête est l'échec documenté — deux exécutions du même pipeline, deux verdicts opposés." - ] - }, { "cell_type": "markdown", "id": "8fc9d6d1", diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12-DS-Star-Workshop.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12-DS-Star-Workshop.ipynb index 6b4d7e8432..73bb75f6eb 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12-DS-Star-Workshop.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12-DS-Star-Workshop.ipynb @@ -115,13 +115,6 @@ "print(\"Imports OK : pandas, numpy, LLMClient et runtime Google ADK réel\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Tous les modules nécessaires sont disponibles : pandas, numpy, le client LLM et le runtime Google ADK, confirmant un environnement prêt pour l’exécution du pipeline DS-STAR.\n" - ] - }, { "cell_type": "markdown", "id": "1198781a", @@ -139,13 +132,6 @@ "`get_settings()` charge le provider actif sans afficher de clé ni d'endpoint sensible. Ce diagnostic précède les appels multi-agents : il permet d'attribuer les sorties au provider réellement configuré, tandis que le modèle ADK est construit par le runtime partagé." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Le fournisseur LLM actif est OpenAI, ce qui détermine quel modèle sera utilisé pour les appels d’agents dans le pipeline.\n" - ] - }, { "cell_type": "code", "execution_count": 2, @@ -610,13 +596,6 @@ "print(\"Compatibilité pédagogique Verifier conservée ; le pipeline utilise Verifier ADK\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Verbatim : « Compatibilité pédagogique Verifier conservée ; le pipeline utilise Verifier ADK » — la classe Verifier locale ne sert qu'à l'exercice BusinessVerifier ; dans le pipeline DS-STAR, la vérification est portée par un agent ADK à part entière." - ] - }, { "cell_type": "markdown", "id": "cell-13", @@ -640,13 +619,6 @@ "`max_iterations` borne le nombre de tentatives — donc le coût — et empêche une correction sans fin. Le défaut `2` laisse une seconde chance après un premier échec, et c'est la valeur utilisée dans les sections 7 et 8. Si toutes les itérations échouent, le pipeline rend un résultat explicite — erreur, verdict, code généré et preuve collectée — plutôt qu'un échec silencieux : l'appelant peut distinguer un succès métier d'une simple réponse textuelle plausible." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Verbatim : « Dataset cree: tmpyulx5vy9\\sales.csv », « 150 lignes, colonnes: ['date', 'product', 'region', 'revenue', 'units'] » — noms exacts à relire tels quels depuis le schéma ; une colonne francisée (« revenu » au lieu de « revenue ») casserait l'accès, et l'oracle Pandas de la section suivante est là pour l'attraper." - ] - }, { "cell_type": "code", "execution_count": 9, @@ -838,13 +810,6 @@ "print(\"DS-STAR prêt : Planner, Coder et Verifier utilisent de vrais Agent/Runner\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture :** Verbatim : « DS-STAR prêt : Planner, Coder et Verifier utilisent de vrais Agent/Runner » — les trois rôles sont des agents Google ADK réels, pas des complétions déguisées ; chaque analyse lancée ensuite produira ses propres sessions traçables (identifiants, événements, appels d'outils)." - ] - }, { "cell_type": "markdown", "id": "cell-15", @@ -1856,4 +1821,4 @@ }, "nbformat": 4, "nbformat_minor": 5 -} \ No newline at end of file +} diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.ipynb index 1c02997ce1..8b1009f8c3 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.ipynb @@ -79,13 +79,6 @@ "print(f\"Endpoint externe : {bool(provider.base_url)}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « Provider actif : openrouter », « Modele : openrouter/openai/gpt-4.1-mini », « Endpoint externe : True » — un modèle léger via passerelle pour ce lab. Le choix du modèle ne change rien à la question de la persistance de session ; seul le compte de jetons (Lab12d) en dépend." - ] - }, { "cell_type": "markdown", "id": "9423d8a3", @@ -108,13 +101,6 @@ "demande un **rappel** de ce contexte -- sans jamais le repeter dans la question." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Le tour 1 établit le contexte métier : le dataset 'patients-2026' contient 240 lignes et 12 colonnes. L'agent répond en décrivant la structure complète du dataset. Cette première interaction est cruciale car elle pose les bases de la conversation." - ] - }, { "cell_type": "code", "execution_count": 2, @@ -146,13 +132,6 @@ "print(tour1.response_text)" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Réponse du tour 1, verbatim : « Le dataset 'patients-2026' contient 240 lignes et 12 colonnes, ce qui donne un total de 2880 cellules. Chaque colonne a en moyenne 20 valeurs distinctes. Cela suggère une diversité de données suffisante dans chaque colonne, adaptée pour des analyses statistiques ou d'apprentissage machine. » Le détail à retenir : l'agent ne recopie pas l'énoncé — il a appelé `dataset_profile` et calculé la multiplication (240 × 12 = 2880) et le profil par colonne (20 valeurs distinctes en moyenne). Le contexte posé au tour 1 est plus riche que la question : c'est ce contenu-là que le tour 2 devra retrouver." - ] - }, { "cell_type": "code", "execution_count": 3, @@ -179,13 +158,6 @@ "print(tour2.response_text)" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "Le tour 2 démontre que l'agent ne conserve PAS le contexte entre appels isolés. Réponse, verbatim : « Pour répondre à cette question, j'ai besoin que tu me fournisses les dimensions (nombre de lignes et de colonnes) ou un extrait de ton dataset pour que je puisse en analyser la forme. Pourrais-tu me transmettre ces informations ? » L'agent demande à l'utilisateur de répéter ce qu'il vient de dire — le symptôme de l'absence de persistance sans ConversationRunner. Chaque appel isolé instancie une session neuve ; la question du tour 2 n'a jamais rencontré la réponse du tour 1." - ] - }, { "cell_type": "markdown", "id": "6bf7687c", @@ -254,13 +226,6 @@ "print(\" - self.session_id : identifiant stable, jamais regenere entre les tours\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Le docstring porte les deux contrats d'une phrase : « Execute plusieurs tours d'un agent dans la MEME session ADK » (C1b) et « Le cloisonnement reste celui du contrat C1 : deux ``ConversationRunner`` sont deux sessions distinctes, isolees l'une de l'autre ». Les deux attributs imprimés font tout le travail : « self.session_service : un seul InMemorySessionService pour TOUS les tours », « self.session_id : identifiant stable, jamais regenere entre les tours ». Aucune logique propre — l'assemblage réutilise les primitives publiques d'ADK ; ce qui manquait au tour isolé de la section 2, c'était uniquement la durée de vie de ces deux objets." - ] - }, { "cell_type": "markdown", "id": "b3a159a5", @@ -314,13 +279,6 @@ "print(t3.response_text)" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "La classe ConversationRunner gère l’exécution de plusieurs tours d’un agent dans la MÊME session ADK persistante. Elle maintient un InMemorySessionService dédié et un session_id unique pour chaque conversation, ce qui permet à l’agent de conserver intégralement le contexte métier entre chaque tour, sans que l’utilisateur ait besoin de répéter les informations. Cette persistance de contexte est particulièrement cruciale dans les applications conversationnelles." - ] - }, { "cell_type": "markdown", "id": "ece7500e", @@ -384,13 +342,6 @@ " print(f\" {i:2d}. [{event.author or '?':>8}] \")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : La chronologie imprimée montre la mécanique interne : événement 1 `[user]` (question du tour 1), événement 2 `[dataset_profile_agent]` , réponse profilée en 4 (« 240 lignes (exemples) et 12 colonnes (variables) »), question du tour 2 en 5, rappel en 6 (« Ton dataset s'appelait \"patients-2026\" »), question du tour 3 en 7, réponse calculée en 8 (« 240 × 12 = 2880 cellules »). L'événement 3 n'affiche aucun extrait (ni texte, ni appel) — le filtre d'impression ne le montre pas, mais il compte dans les 8. C'est exactement cet historique qu'ADK renvoie au LLM au tour suivant : la mémoire n'est pas dans le modèle, elle est dans cette liste." - ] - }, { "cell_type": "markdown", "id": "05c79a6f", @@ -470,13 +421,6 @@ "print(reponse_b.response_text[:300])" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : La réponse de B, verbatim : « Pour vous répondre précisément, j'aurais besoin que vous me fournissiez les informations sur votre dataset, notamment le nombre de lignes et de colonnes si vous les connaissez, ou bien que vous me donniez accès à ce dataset pour analyser sa forme ». C'est le symptôme exact de l'amnésie du tour 2 isolé (section 2) — mais ici, c'est le comportement ATTENDU : B n'a jamais reçu le contexte de A, et l'isolation C1 fait qu'il ne le recevra jamais. Persistance intra-session et amnésie inter-sessions sont les deux faces de la même mécanique de session." - ] - }, { "cell_type": "markdown", "id": "6993fe66", @@ -491,13 +435,6 @@ "`test_c1b_conversations_still_isolate`." ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « Evenements persistes dans la session apres 3 tours : 8 » — compteur imprimé pour la session A — puis le test croisé : « A contient 'secret-alpha' : True », « B contient 'secret-alpha' (fuite ?): False » ; la réponse de B le confirme en redemandant les informations du dataset. Persistance intra-session (8 événements accumulés sur 3 tours côté A) et isolation inter-sessions (aucune fuite du marqueur) : les deux faces du même contrat de session." - ] - }, { "cell_type": "markdown", "id": "83af5569", @@ -660,4 +597,4 @@ }, "nbformat": 4, "nbformat_minor": 5 -} \ No newline at end of file +} diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day6-MLE-Star/Lab13-Web-Search-SOTA.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day6-MLE-Star/Lab13-Web-Search-SOTA.ipynb index 403d36843a..e5ed8e9eec 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day6-MLE-Star/Lab13-Web-Search-SOTA.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day6-MLE-Star/Lab13-Web-Search-SOTA.ipynb @@ -692,13 +692,6 @@ "print(\"Classe MLEStarSearcher definie : pipeline complet WebSearch -> ExtractModel -> GenerateCode\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim : « Classe MLEStarSearcher definie : pipeline complet WebSearch -> ExtractModel -> GenerateCode ». Les trois étapes s'impriment chacune au run : « [WEB SEARCH] Recherche pour: image classification imagenet », « [EXTRACTOR] Extraction des modeles... », « [CODE GEN] Generation du code initial... » — une seule classe qui enchaîne retrieval, extraction LLM et génération de code." - ] - }, { "cell_type": "markdown", "id": "cell-14", @@ -796,13 +789,6 @@ " print(f\" Paper: {m.paper_url}\")" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim des « MODELES TROUVES » : « Vision Transformers » (« 90.5% top-1 accuracy on ImageNet »), « YOLOv9 » et « DINO » (tous deux « object detection benchmarks on the COCO dataset ») — pour « 2 resultats trouves » côté recherche. Lecture honnête, celle du notebook lui-même : deux modèles sur trois sont des détecteurs COCO, pas des classifieurs ImageNet, et « le RAG n'est pas magique — sa qualité est plafonnée par celle du retrieval amont » ; la section préconise un re-ranking par leaderboard. Le run démontre moins une découverte automatique du SOTA que la mécanique qui permettrait de l'approcher." - ] - }, { "cell_type": "markdown", "id": "interp-cell-15", @@ -915,13 +901,6 @@ " print(code[:800] + \"...\" if len(code) > 800 else code)" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "**Lecture** : Verbatim des imports générés : « import torch », « import torchvision », « from torchvision.models import vit_b_16, ViT_B_16_Weights », puis transformations (Resize 256, CenterCrop 224, Normalize mean=[0.485, 0.456, 0.405]) et chargement « torchvision.datasets.ImageNet(root='path/to/imagenet/train') ». Attention au statut : « le code produit n'est pas exécuté dans ce lab » (section 8) — squelette à chemin placeholder, « non validé », que le Lab 14 (ablation) doit raffiner. « Exécutable » serait un mot de trop : plausible, non prouvé." - ] - }, { "cell_type": "markdown", "id": "interp-cell-17", @@ -1375,4 +1354,4 @@ }, "nbformat": 4, "nbformat_minor": 5 -} \ No newline at end of file +} From a513d47292df0ca417de26742f3d3493c0145090 Mon Sep 17 00:00:00 2001 From: jsboige Date: Wed, 23 Sep 2026 03:28:12 +0200 Subject: [PATCH 2/2] fix(density,#17040): keep one anchored reading per output (ml) Restores, verbatim from 39c65577e4, the one reading whose cited numbers are all present in its owner output (Lab12e fe925809, turn-1 verbatim). The other six anchored outputs (3.6c 4bd22bad/1d72a52f/b823a35e/6de20b44, 3.6d 6941e205, 3.7 ce4b758a) were left unread: every candidate reading cites numbers/timings absent from the committed outputs (stale run), so nothing faithful was restorable there. Filler not restored. Co-Authored-By: Claude Sonnet 5 --- .../Day5-DS-Star/Lab12e-Session-Persistence.ipynb | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.ipynb index 8b1009f8c3..acd5e0bde8 100644 --- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.ipynb +++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day5-DS-Star/Lab12e-Session-Persistence.ipynb @@ -132,6 +132,13 @@ "print(tour1.response_text)" ] }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "**Lecture** : Réponse du tour 1, verbatim : « Le dataset 'patients-2026' contient 240 lignes et 12 colonnes, ce qui donne un total de 2880 cellules. Chaque colonne a en moyenne 20 valeurs distinctes. Cela suggère une diversité de données suffisante dans chaque colonne, adaptée pour des analyses statistiques ou d'apprentissage machine. » Le détail à retenir : l'agent ne recopie pas l'énoncé — il a appelé `dataset_profile` et calculé la multiplication (240 × 12 = 2880) et le profil par colonne (20 valeurs distinctes en moyenne). Le contexte posé au tour 1 est plus riche que la question : c'est ce contenu-là que le tour 2 devra retrouver." + ] + }, { "cell_type": "code", "execution_count": 3,