fix(fine-tuning,#15263): FT-05 doc-honesty — qualify non-measured metrics, correct arXiv id, align GPU prose (markdown-only)

MyIA.AI.Notebooks/GenAI/FineTuning/FT-05-ModelMerging-Routing.ipynb

@@ -51,9 +51,11 @@
     "**GPU** : recommandé (CUDA) ; le notebook dégrade sur CPU avec un modèle\n",
     "plus petit (pré-requis complet en tête de notebook).\n",
     "\n",
-    "**Coût-bénéfice mesuré** : ~5 min sur RTX 3090 (25.8 GB VRAM pic, base\n",
-    "1.3B params × 2 adaptateurs LoRA 3.1M params). C'est l'ordre de grandeur\n",
-    "pour reproduire localement les chiffres de ce notebook.\n"
+    "**Coût-bénéfice** : le notebook est committé avec ses sorties produites par une\n",
+    "**GPU 8 Go** (`NVIDIA GeForce RTX 3070 Laptop GPU, 8.6 GB VRAM`, cf. cellule #1).\n",
+    "Le coût réel porte sur le fine-tuning des adaptateurs (FT-02/03/04) ; le **merge**\n",
+    "des task vectors est une addition vectorielle homogène (~3.1M params) qui tient\n",
+    "sur le portatif de la sortie committée — ni serveur ni GPU dédiée.\n"
    ]
   },
   {
@@ -1074,19 +1076,17 @@
     "tags": []
    },
    "source": [
-    "**Observation** : Chaque adaptateur repond mieux dans son domaine de specialisation. L'adaptateur A (Tech) produit des reponses plus coherentes sur les sujets techniques, et l'adaptateur B (Cuisine) sur les sujets culinaires.\n",
+    "**Lecture attendue** : chaque adaptateur devrait repondre mieux dans son domaine de specialisation — l'adaptateur A (Tech) sur les sujets techniques, l'adaptateur B (Cuisine) sur les sujets culinaires. À confirmer sur un jeu d'évaluation dédié.\n",
     "\n",
     "Le problème : si on deploie un chatbot generaliste, il faudrait servir les deux modèles. C'est ici que le **model merging** intervient.\n",
-    "**Observation** : chaque adaptateur répond mieux dans son domaine\n",
-    "que dans le domaine de l'autre (cf. test cross-domaine cellule #10).\n",
-    "C'est la preuve qualitative que les deux LoRA ont bien capturé des\n",
-    "spécificités distinctes — sans cela, la fusion n'aurait aucun\n",
+    "**Indice qualitatif (non mesuré)** : chaque adaptateur est attendu plus à l'aise dans son domaine que dans celui de l'autre — les 4 générations du test cross-domaine (cellule #10) suggèrent cette asymétrie sans l'établir de façon fiable. Au mieux un indice qualitatif que les deux LoRA ont pu capturer des spécificités distinctes — sans cela, la fusion n'aurait aucun\n",
     "intérêt (deux adaptateurs identiques se fusionnent trivialement).\n",
     "\n",
-    "**Métrique attendue** : Tech-adaptateur devrait scorer ~80 % sur QA\n",
-    "technique et ~30 % sur cuisine ; le pattern inverse pour\n",
-    "Cuisine-adaptateur. La **différence** entre les deux scores est le\n",
-    "**signal de spécialisation** capturé par le fine-tuning.\n"
+    "**Métrique non mesurée ici** : on pourrait s'attendre à ce que Tech-adaptateur\n",
+    "score plus haut sur QA technique que sur cuisine (et l'inverse pour\n",
+    "Cuisine-adaptateur). **Aucun score n'est calculé dans les sorties committées** —\n",
+    "la qualification reste qualitative. La différence de comportement attendue entre les deux domaines est le **signal de spécialisation** recherché ; les générations committées n'en offrent qu'un aperçu qualitatif ;\n",
+    "une mesure chiffrée exigerait un jeu d'évaluation dédié, hors scope ici.\n"
    ]
   },
   {
@@ -1116,7 +1116,7 @@
     "## 2. Les Task Vectors\n",
     "\n",
     "Avant de fusionner, il faut comprendre ce qu'on fusionne. Un **task\n",
-    "vector** (Ilharco et al. 2022, arXiv:2210.09316) est la **différence\n",
+    "vector** (Ilharco et al. 2022, arXiv:2212.04089) est la **différence\n",
     "de poids** entre l'adaptateur fine-tuné et le modèle de base :\n",
     "\n",
     "> `τ = θ_finetuned − θ_base`\n",
@@ -1520,7 +1520,7 @@
     "\n",
     "**Sortie obtenue** : Reponses du modèle fusionne avec interpolation lineaire.\n",
     "\n",
-    "| Aspect | Observation |\n",
+    "| Aspect | Lecture attendue (non mesurée) |\n",
     "|--------|-------------|\n",
     "| alpha = 0.5 | Melange egalitaire des deux expertises |\n",
     "| Qualite tech | Peut etre degradee par rapport a l'adaptateur A seul |\n",
@@ -1529,18 +1529,16 @@
     "**Points cles** :\n",
     "1. Le LERP est simple mais peut degrader les deux expertises\n",
     "2. Dans un espace de grande dimension, la moyenne de deux vecteurs peut \"dilater\" l'espace et perdre des informations\n",
-    "3. C'est pourquoi SLERP (section suivante) est souvent preferee\n",
+    "3. C'est pourquoi SLERP (section suivante) est souvent préférée dans la littérature — l'avantage en qualité n'est pas mesuré ici\n",
     "### Lecture du résultat : LERP\n",
     "\n",
-    "**Sortie obtenue** (cellule #16) : pour `α = 0.5`, le modèle\n",
-    "fusionné LERP répond de manière « intermédiaire » entre Tech et\n",
-    "Cuisine — il a perdu la spécialisation sur chaque domaine, mais\n",
-    "gagne en polyvalence.\n",
+    "**Sortie obtenue** (cellule #16) : pour `α = 0.5`, le LERP opère un mélange égalitaire des deux adaptateurs ; la lecture attendue est une réponse « intermédiaire » entre Tech et Cuisine — spécialisation affaiblie sur chaque domaine contre polyvalence — mais ce comportement n'est pas mesuré par les générations committées.\n",
     "\n",
-    "**Métrique attendue** : la perplexité sur Tech et sur Cuisine devrait\n",
-    "être **plus élevée** que les adaptateurs spécialisés respectifs\n",
-    "(mais plus basse que le modèle de base). C'est le **trade-off\n",
-    "spécialisation / polyvalence** du LERP.\n",
+    "**Métrique non mesurée ici** : la perplexité du LERP n'est **pas calculée**\n",
+    "dans les outputs committés (seules les générations sont imprimées). L'intuition\n",
+    "pédagogique — le LERP plus « mixte » que les spécialistes, donc une perplexité\n",
+    "plus « élevée » par domaine — reste un **exercice de lecture**, pas un résultat\n",
+    "mesuré. Cette tension est le **trade-off spécialisation / polyvalence** du LERP.\n",
     "\n",
     "**Hyperparamètre clé** : `α = 0.5` est le défaut, mais on peut\n",
     "biaiser vers Tech (`α = 0.7`) ou Cuisine (`α = 0.3`) si l'usage\n",
@@ -1786,26 +1784,23 @@
     "|--------|------|-------|\n",
     "| Preservation des directions | Non (dilation possible) | Oui (arc de grand cercle) |\n",
     "| Couches quasi-colineaires | N/A | Fallback automatique vers LERP |\n",
-    "| Qualite du melange | Moyenne, risque de degradation | Meilleure preservation des expertises |\n",
+    "| Qualite du melange (non mesurée) | Lecture attendue : moyenne, risque de dégradation | Lecture attendue : meilleure préservation des expertises |\n",
     "\n",
     "**Points cles** :\n",
-    "1. SLERP preserve les proprietes geometriques des deux task vectors\n",
+    "1. Propriété de l'algorithme : SLERP interpole sur l'arc de grand cercle, ce qui préserve les propriétés géométriques des deux task vectors\n",
     "2. Quand les vecteurs sont quasi-colineaires (même direction), SLERP retombe sur LERP\n",
     "3. C'est la méthode de merge la plus utilisee en pratique pour les modèles de grande taille\n",
     "\n",
     "> **Note technique** : En production, des outils comme Mergekit automatisent le merge SLERP sur des modèles complets (pas seulement LoRA).\n",
     "### Lecture du résultat : SLERP\n",
     "\n",
-    "**Sortie obtenue** (cellule #19) : avec `t = 0.5`, le modèle SLERP\n",
-    "produit des réponses qui ressemblent plus aux **deux domaines\n",
-    "préservés** que ne le fait LERP — sur les questions Tech, il reste\n",
-    "Tech ; sur Cuisine, il reste Cuisine. C'est la **propriété clef** du\n",
-    "SLERP.\n",
+    "**Sortie obtenue** (cellule #19) : avec `t = 0.5`, SLERP interpole sur l'arc de grand cercle entre les deux task vectors. La **propriété attendue** — meilleure préservation des deux expertises que LERP — est un résultat de la littérature, pas une observation de ce notebook : les générations committées (cellule #19) sont brèves et parfois incohérentes, elles ne l'établissent pas.\n",
     "\n",
-    "**Métrique attendue** : perplexité Tech et Cuisine du SLERP devrait\n",
-    "être **plus proche** des adaptateurs spécialisés que ne l'est LERP.\n",
-    "C'est ce qu'on observe empiriquement dans la littérature\n",
-    "(Ilharco et al. 2022, Wortsman et al. 2022).\n",
+    "**Métrique non mesurée ici** : la perplexité SLERP n'est **pas calculée** dans\n",
+    "les sorties committées. La propriété qualitative attendue (SLERP « reste Tech sur Tech, Cuisine sur Cuisine ») n'est pas établie par les générations committées ; la comparaison chiffrée\n",
+    "avec LERP reposerait sur une perplexité qu'on ne calcule pas ici. La littérature\n",
+    "(Ilharco et al. 2022, Wortsman et al. 2022) rapporte cette tendance — c'est une\n",
+    "**référence bibliographique**, pas une valeur mesurée dans ce notebook.\n",
     "\n",
     "**Implémentation de fallback** : si les normes des task vectors sont\n",
     "très différentes (un task vector domine l'autre), SLERP fallback\n",
@@ -2031,26 +2026,24 @@
     "\n",
     "**Sortie obtenue** : Reponses du modèle fusionne avec DARE (30% de dropout).\n",
     "\n",
-    "| Aspect | Observation |\n",
+    "| Aspect | Propriété de l'algorithme / lecture attendue |\n",
     "|--------|-------------|\n",
     "| Drop rate | 30% des poids de chaque task vector sont mis a zero |\n",
     "| Rescaling | Les poids restants sont multiplies par 1/(1-0.3) ~ 1.43 |\n",
-    "| Interference | Reduite par la suppression aleatoire des poids redondants |\n",
+    "| Interference (non mesurée) | Lecture attendue : réduite par la suppression aléatoire — le code mesure le taux de poids supprimés, pas les interférences |\n",
     "\n",
     "**Points cles** :\n",
     "1. DARE est très simple a implementer et ne necessite pas de calcul de signe\n",
     "2. Le rescaling preserve la magnitude attendue des modifications\n",
     "3. Un drop_rate plus eleve (0.5-0.7) reduit davantage les interferences mais peut perdre des informations utiles\n",
     "### Lecture du résultat : DARE\n",
     "\n",
-    "**Sortie obtenue** (cellule #22) : avec `drop_rate = 0.3`, le modèle\n",
-    "fusionné DARE performe **au niveau des adaptateurs spécialisés** sur\n",
-    "les deux domaines — c'est la « magie » du DARE, justifiée\n",
-    "théoriquement par le rescaling.\n",
+    "**Sortie obtenue** (cellule #22) : avec `drop_rate = 0.3`, DARE met à zéro 30 % des poids de chaque task vector puis recale la magnitude (rescaling). L'attente théorique — une performance proche des adaptateurs spécialisés sur les deux domaines — vient de la littérature ; ce notebook ne la mesure pas.\n",
     "\n",
-    "**Métrique attendue** : la qualité DARE devrait être ≈ 95-98 % de\n",
-    "la qualité de l'adaptateur spécialisé sur chaque domaine, et\n",
-    "nettement > à LERP/SLERP pour des domaines orthogonaux.\n",
+    "**Métrique non mesurée ici** : le rapport de qualité DARE (≈ 95-98 % du\n",
+    "spécialiste) n'est **pas calculé** dans les sorties — c'est un ordre de grandeur\n",
+    "de la littérature, proposé comme **lecture attendue**. Les seuls outputs committés\n",
+    "sont les générations ; aucune métrique de qualité n'y est mesurée.\n",
     "\n",
     "**Hyperparamètre** : `drop_rate ∈ [0.1, 0.5]` est l'intervalle\n",
     "raisonnable. Au-delà de 0.5, l'espacement devient trop sparse et la\n",
@@ -2779,41 +2772,40 @@
    "source": [
     "### Interpretation : Comparaison finale\n",
     "\n",
-    "**Résultats attendus** :\n",
+    "**Résultats attendus (hypothèses qualitatives — aucun classement mesuré, cf. Hypothèse à tester ci-dessous)** :\n",
     "\n",
     "| Approche | Tech | Cuisine | Commentaire |\n",
     "|----------|------|---------|-------------|\n",
     "| Adaptateur A | Bon | Faible | Specialise tech |\n",
     "| Adaptateur B | Faible | Bon | Specialise cuisine |\n",
     "| LERP | Moyen | Moyen | Melange egalitaire, degradation des deux |\n",
-    "| SLERP | Moyen+ | Moyen+ | Meilleur preservation que LERP |\n",
+    "| SLERP | Moyen+ | Moyen+ | Meilleur preservation que LERP (attendu) |\n",
     "| DARE | Variable | Variable | Dependant du dropout aleatoire |\n",
-    "| Routing | Bon | Bon | Selectionne le bon expert, meilleur résultat |\n",
+    "| Routing | Bon | Bon | Selectionne le bon expert, meilleur résultat (attendu) |\n",
     "\n",
     "**Points cles** :\n",
-    "1. Le **routing** offre les meilleurs résultats par domaine mais coute plus cher en VRAM\n",
-    "2. Le **SLERP** est le meilleur merge statique -- bon compromis entre les deux expertises\n",
-    "3. Le **DARE** est efficace quand on a beaucoup d'experts, mais moins bon avec seulement 2\n",
+    "1. Le **routing** est attendu le plus performant par domaine (hypothèse, non mesurée) mais coute plus cher en VRAM\n",
+    "2. Le **SLERP** est souvent cité comme le meilleur merge statique (littérature) ; l'hypothèse à tester ci-dessous privilégie DARE — non mesuré ici\n",
+    "3. Le **DARE** est efficace quand on a beaucoup d'experts, mais moins bon avec seulement 2 (littérature, non mesuré ici)\n",
     "4. En production, les approches peuvent etre combinees : merge SLERP pour les experts proches + routing pour les domaines très différents\n",
     "### Lecture du résultat : Comparaison finale\n",
     "\n",
-    "**Résultats attendus** (cellule #30) : tableau comparant les\n",
-    "différentes approches sur les 10 questions cross-domaine. **DARE\n",
-    "devrait être le meilleur merge**, suivi par SLERP puis LERP.\n",
+    "**Résultats attendus** (cellule #30) : tableau comparant les différentes\n",
+    "approches sur les 2 questions retenues (une tech, une cuisine). **Hypothèse à tester** : DARE devrait être le meilleur merge, suivi par SLERP puis LERP — classement attendu de la littérature, aucun classement mesuré dans ce notebook.\n",
     "\n",
-    "**Métrique de comparaison** : on utilise la **perplexité** du\n",
-    "modèle fusionné sur chaque question (plus basse = mieux). DARE\n",
-    "devrait obtenir une perplexité ≈ 5 % au-dessus du spécialiste\n",
-    "pur, là où LERP est 20-30 % au-dessus.\n",
+    "**Métrique non mesurée ici** : la **perplexité** des modèles fusionnés n'est\n",
+    "**pas calculée** dans les sorties committées (la cellule #30 ne compare que des\n",
+    "générations textuelles). L'ordre « DARE ≈ 5 % au-dessus du spécialiste, LERP\n",
+    "20-30 % au-dessus » est un **ordre de grandeur de la littérature**, non une\n",
+    "mesure issue de ce notebook.\n",
     "\n",
     "**Lecture critique** : les chiffres exacts dépendent de la **graine\n",
     "aléatoire** du fine-tuning (cellule #5 et #7) et de\n",
     "l'**initialisation** du classifieur de routing (cellule #26). Pour\n",
     "des conclusions publiables, il faut **4+ seeds** et un **intervalle\n",
     "de confiance** — au-delà du scope de ce notebook pédagogique.\n",
     "\n",
-    "**Conclusion pratique** : pour un déploiement rapide, **DARE avec\n",
-    "drop_rate = 0.3** est l'option sans regret.\n"
+    "**Conclusion pratique (sous réserve de mesure)** : faute de métrique dans ce notebook, **DARE avec drop_rate = 0.3** est un défaut raisonnable cité par la littérature — à valider sur un benchmark dédié avant tout déploiement.\n"
    ]
   },
   {
@@ -3193,16 +3185,12 @@
     "**sélection dynamique par token** — préférer un vrai MoE (Mixtral,\n",
     "DeepSeek-MoE).\n",
     "\n",
-    "**Coût-bénéfice mesuré** : pour 2 adaptateurs LoRA sur un base 1.3B,\n",
-    "le merge complet (DARE drop_rate=0.3) tourne en **~10 secondes** sur\n",
-    "RTX 3090. C'est le coût réel pour reproduire les chiffres de ce\n",
-    "notebook — l'investissement se porte sur le fine-tuning des\n",
-    "adaptateurs (FT-02/03/04), pas sur le merge.\n",
+    "**Coût-bénéfice structurel** : pour 2 adaptateurs LoRA sur un base 1.3B, le merge complet (DARE drop_rate=0.3) est une addition vectorielle sur ~3.1M params — négligeable devant le fine-tuning des adaptateurs (FT-02/03/04), quel que soit le matériel ; son coût exact dépend du GPU et des versions (non mesuré ici). L'investissement se porte sur le fine-tuning, pas sur le merge.\n",
     "\n",
     "**Limites assumées** : (1) les **métriques de qualité** (perplexité,\n",
-    "lm-eval-harness) sont **manuelles** dans ce notebook — pour des\n",
-    "conclusions publiables, il faudrait 4+ seeds et un intervalle de\n",
-    "confiance ; (2) le **routeur** est un proxy léger (embeddings moyens),\n",
+    "lm-eval-harness) ne sont **pas calculées** dans ce notebook — les outputs\n",
+    "committés ne contiennent que des générations ; pour des conclusions publiables,\n",
+    "il faudrait 4+ seeds et un intervalle de confiance ; (2) le **routeur** est un proxy léger (embeddings moyens),\n",
     "pas un vrai classifier de production ; (3) le **DARE drop_rate = 0.3**\n",
     "est un défaut raisonnable, pas un optimum universel.\n"
    ]