diff --git a/MyIA.AI.Notebooks/GenAI/FineTuning/FT-00a-LoRA-from-scratch-Python.ipynb b/MyIA.AI.Notebooks/GenAI/FineTuning/FT-00a-LoRA-from-scratch-Python.ipynb index 0ae06d59b91..067d4431bb6 100644 --- a/MyIA.AI.Notebooks/GenAI/FineTuning/FT-00a-LoRA-from-scratch-Python.ipynb +++ b/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 -} \ No newline at end of file +}