Fix(finetuning,#17073): audit FT-00a -- durees par epoch et ordres de grandeur float64 regroundes sur les sorties

MyIA.AI.Notebooks/GenAI/FineTuning/FT-00a-LoRA-from-scratch-Python.ipynb

@@ -21,7 +21,7 @@
     "\n",
     "**Prérequis** : bases de PyTorch (tenseurs, autograd, `nn.Linear`) et notions de fine-tuning — voir [FT-01](FT-01-Introduction-FineTuning-Python.ipynb).\n",
     "\n",
-    "**Durée** : ~30 min · **Niveau** : intermédiaire · **Matériel** : CPU suffit (les durées affichées sont mesurées sur GPU, ~6 s par epoch).\n",
+    "**Durée** : ~30 min · **Niveau** : intermédiaire · **Matériel** : CPU suffit (les durées affichées sont mesurées sur GPU, quelques secondes par epoch).\n",
     "\n",
     "**Position dans la série** : FT-01 à FT-06 utilisent `peft` et des modèles HuggingFace prêts à l'emploi. Ce notebook démonte le mécanisme — la décomposition `W' = W + (alpha/r) * B @ A`, l'initialisation `A ~ N, B = 0`, la propagation du gradient, la fusion — pour que les notebooks SOTA cessent d'être des boîtes noires. Les notebooks suivants restent la référence pour l'usage industriel : [FT-01](FT-01-Introduction-FineTuning-Python.ipynb) (LoRA avec `peft` sur GPT-2), [FT-02](FT-02-QLoRA-Quantization-Python.ipynb) (QLoRA 4-bit), [FT-06](FT-06-Vision-Language-LoRA-Python.ipynb) (vision-langage)."
    ]
@@ -114,7 +114,7 @@
    "source": [
     "### Lecture du résultat : l'environnement d'exécution\n",
     "\n",
-    "La mini-tâche de ce notebook (section 3) tient sur CPU comme sur GPU ; seule la durée change (~6 s par epoch sur RTX 3090, sensiblement plus sur CPU). Toutes les cellules suivantes s'exécutent telles quelles sur les deux — les **valeurs** mesurées (exactitudes, normes, dérive de fusion) sont celles produites par le run, pas des constantes recopiées."
+    "La mini-tâche de ce notebook (section 3) tient sur CPU comme sur GPU ; seule la durée change (quelques secondes par epoch sur RTX 3090, sensiblement plus sur CPU). Toutes les cellules suivantes s'exécutent telles quelles sur les deux — les **valeurs** mesurées (exactitudes, normes, dérive de fusion) sont celles produites par le run, pas des constantes recopiées."
    ]
   },
   {
@@ -951,7 +951,7 @@
     "### Lecture du résultat : la fusion est une réécriture, pas une identité\n",
     "\n",
     "- **float32** : la dérive est de l'ordre de `1e-6` — minuscule, mais **non nulle**, et elle n'est pas un bug : c'est le prix de la ré-association des opérations. À l'échelle de l'epsilon float32 (`1.2e-7`), une dérive de `1e-6` sur un vecteur de dimension 576 est exactement ce que l'arrondi d'association produit.\n",
-    "- **Le contrôle float64** confirme le diagnostic : la même comparaison en double précision tombe de près de trois ordres de grandeur plus bas. Si la dérive venait d'une erreur d'implémentation, elle ne bougerait pas avec la précision.\n",
+    "- **Le contrôle float64** confirme le diagnostic : la même comparaison en double précision tombe de près de neuf ordres de grandeur plus bas. Si la dérive venait d'une erreur d'implémentation, elle ne bougerait pas avec la précision.\n",
     "- **Le delta appris n'est pas petit** : `||delta W||` vaut une fraction substantielle de `||W||` (typiquement la moitié ici). Ce n'est pas un ajustement cosmétique — l'adaptateur a déplacé la couche pour de bon, et la fusion le conserve.\n",
     "\n",
     "Conséquence pratique : si un pipeline compare bit à bit un modèle avant et après fusion, il trouvera une différence — et il aura raison. La bonne garantie est « équivalent à l'epsilon de la précision près », pas « identique ». C'est la même famille de distinction que pour toute réécriture numérique : *équivalent* et *identique* sont deux claims différents, et seul le second se prouve bit à bit."
@@ -1219,4 +1219,4 @@
  },
  "nbformat": 4,
  "nbformat_minor": 5
-}
+}