🔧 L'architecture est un seuil, pas un levier — ce que j'ai appris en optimisant un LLM français de 15M de paramètres 🇫🇷

---

👤 Contexte — où on en était

Si tu as lu le premier article : LLM français de 15M de paramètres, construit from scratch, en solo, sur une GTX 1080 Ti. Architecture style LLaMA, BPE 32k custom, Wikipedia français réécrit par IA. Coupure de courant à l'epoch 10/18.

Le modèle avait appris la forme, pas le fond. Il écrivait un français parfait, du markdown structuré, une grammaire fluide — mais hallucine les faits et dérive hors sujet après ~200 tokens.

Cet article est le suivi honnête : une semaine entière de mesure → correction → mesure, sans nouvelle architecture, sans GPU plus puissant. Juste extraire systématiquement tout ce qu'il reste dans le modèle 15M. La conclusion dès maintenant : l'architecture n'a jamais été le goulot d'étranglement. C'était les données et le décodage.

---

🪜 Le modèle mental — l'architecture est un seuil, pas un levier

Le plus grand changement de perspective de la semaine.

Tout le monde s'obsède sur l'architecture parce qu'elle est visible et copiable — RoPE, SwiGLU, GQA, papers, courbes. Les données et l'objectif d'entraînement sont sales, ennuyeux, invisibles. Alors on optimise ce qu'on voit — comme chercher ses clés sous le lampadaire parce que c'est là qu'il y a de la lumière.

Mais voilà la vérité à 15M de paramètres :

L'architecture est un seuil, pas un levier. En dessous d'un certain niveau elle te bloque. Au-dessus — et un transformer pre-norm propre avec weight tying est au-dessus — elle ne bouge presque plus le curseur. Le goulot migre vers les données et l'objectif.

J'ai donc construit une échelle de priorité, du ROI le plus élevé au plus faible :

L'insight clé : l'innovation (niveau 5) est inutile sans mesure (niveau 1). Une innovation qu'on ne peut pas quantifier, c'est de la foi, pas de la recherche. Donc on construit l'instrument d'abord.

---

🏗️ Niveau 0 — corriger les bugs d'architecture d'abord

Avant d'optimiser, j'ai audité gpt2.py. Plusieurs vrais bugs cachés en pleine vue — et un seul avait vraiment de l'importance.

Celui qui changeait réellement les sorties : repetition_penalty était à l'envers. Il divisait tous les logits par la pénalité. Pour un logit négatif, diviser le rend plus probable — exactement l'inverse de l'intention. Donc la feature censée réduire la répétition l'encourageait en partie. Sémantique HF : logit > 0 ? /penalty : *penalty. C'est le seul qui a visiblement amélioré la génération ; les autres sont des corrections de correction/stabilité.

Les suivants :

• 🐛 Pas de scaled init GPT-2 — les projections résiduelles n'étaient pas scalées par 1/√(2·n_layer), ce qui maintient la variance du residual stream bornée avec la profondeur. Affecte la stabilité de l'entraînement, seulement sur un run from scratch.
• 🐛 KV-cache n'utilisait jamais SDPA — la génération (use_cache=True) tombait sur l'attention manuelle lente. Correction de vitesse, pas de qualité.
• 🐛 Incompatibilité torch 2.3.1 — add_safe_globals n'existe pas avant la 2.4 ; from_pretrained crashait au chargement. Correction de crash.

Validé avec la suite de tests d'architecture (tests/test_architecture.py) : 10/10, dont "Flash vs Manual equivalence" et "KV-cache vs no-cache match". Le refactoring a changé comment les choses se calculent, pas ce qu'elles produisent.

---

🧹 Niveaux 1+2 — les données me mentaient

La réécriture du document packing

Le prepare_data.py original découpait chaque document en tranches de 450 tokens à des offsets arbitraires, paddait à 512 (~12% de padding gaspillé), sans marqueurs <bos>/<eos>.

La conséquence c'était la dérive thématique. Le modèle avait vu des millions de fragments coupés en pleine phrase, jamais un document entier, propre, délimité. Il n'avait donc jamais appris qu'un texte a un début, un développement et une fin.

Correction : document packing (style GPT-3 / LLaMA). Envelopper chaque doc dans <bos> … <eos>, tout concaténer en un flux continu de tokens, découper en blocs pleins de 768. Zéro padding, zéro coupure en pleine phrase, frontières de documents explicites.

Avant (chunking) :  354 148 blocs de 512, ~12% padding, pas de frontières
Après (packing)  :  349 490 blocs de 768, 0% padding, <bos>/<eos> partout
Tokens perdus    :  527 (0,000%)

Le corpus était plein d'emojis

En lisant les fichiers réels, c'est apparu : ~30% du corpus était pollué par des emojis décoratifs (un article de théologie avait un 🕌 ou ✨ après presque chaque proposition). Ajoutez des espaces insécables étroites (U+202F) partout et des guillemets droits avec un espacement bizarre.

scripts/clean_corpus.py : supprimer les emojis, normaliser les espaces spéciaux, convertir les guillemets droits " en guillemets français « » en les appairisant — tout en protégeant les blocs de code (tout ce qui est dans des fences ``` ou des backticks inline reste intact, donc le HTML class="x" survit).

Ça a récupéré ~3,5M tokens de bruit pur : 271,9M → 268,4M tokens de français réel.

La vérité dure sur les données

Puis j'ai lu assez de fichiers pour voir le vrai problème, celui qu'aucun nettoyage ne peut corriger :

Le corpus est la longue traîne de Wikipedia. Un fichier = un sujet, vu exactement une fois. Petits villages (Baranów, Oderaue), plantes obscures (Aruncus dioicus), inconnus. La qualité du texte est excellente — mais chaque fait est un hapax.

C'est pourquoi le modèle hallucine. Il voit Synlycostrobus une fois → il ne peut pas ancrer le fait → il invente. Structure cohérente (152k exemples de "comment écrire un article") mais faits ratés (chaque fait vu une seule fois). Pas un bug. La nature du corpus + le plafond à 15M.

J'ai 100k articles nettoyés supplémentaires prêts. Je ne les utilise pas à 15M — ils sont toujours en format un-sujet-par-fichier. On l'a déjà prouvé : passer de 20% → 60% des données a amélioré le style/PPL (30 → 17) mais pas la factualité. Plus d'hapax = plus de style, même hallucination. Mesurer avant d'agir.

---

📊 Niveau 1 — le harnais de mesure

Le multiplicateur. scripts/evaluate.py : donne-lui un checkpoint, il retourne des chiffres comparables :

• val_ppl — perplexité sur l'ensemble de validation
• repetition_3gram — % de trigrammes répétés (plus bas = mieux)
• distinct_2 — bigrammes uniques / total (diversité, plus haut = mieux)
• coherence_len — tokens générés avant la dérive (un heading # ou une boucle de répétition). Ça quantifie enfin la dérive que j'estimais à l'œil.

Un piège méthodologique dans lequel je suis tombé : le sampling sans seed fixe donnait des métriques bruitées (le même modèle oscillait entre cohérence 30 et 37). Inutilisable pour comparer deux modèles. Seed fixe → reproductible et réaliste.

L'avant/après sur les runs :

---

🐛 Le bug de dérive — deux tokens spéciaux, des heures de confusion

La meilleure histoire de débogage de la semaine.

Le modèle abandonnait le sujet du prompt en démarrant un nouveau document : prompt "…dans le département du Lot" → "# La commune d'Évreux, nichée dans les Alpes françaises…". Prose fluide et cohérente — sur un endroit complètement différent.

J'ai d'abord incriminé le token #. Faux. Après beaucoup de tests, deux causes cumulatives, toutes deux liées au document packing :

1. encode(add_special_tokens=True) ajoutait un <eos> à la FIN du prompt. Le modèle, entraîné sur …<eos><bos># Titre, lisait ça comme "ce document est terminé" → en démarrait un nouveau. C'était le déclencheur principal.
2. Le modèle pouvait émettre <bos> en cours de génération.

Le <bos> était invisible dans la sortie (décodé avec skip_special_tokens=True) mais déclenchait quand même le comportement "nouveau document" — ce qui m'a fait chercher le # pendant des heures.

Correction : supprimer le <eos> final du prompt, et interdire <bos> pendant le décodage (no_new_doc, activé par défaut). Résultat : le modèle reste sur Saint-Céré et conserve ses sections ## internes.

La leçon, maintenant bug #6 dans mon README : les tokens spéciaux de l'entraînement (<bos> texte <eos>) ne sont PAS ce qu'on veut à l'inférence (<bos> texte…). Un classique, mais brutal à trouver dans un codebase from scratch sans framework pour prévenir.

---

🎰 Niveau 3 — régler le sampling (le plus gros gain gratuit)

scripts/tune_sampling.py balaie (temperature, top_k, repetition_penalty) et tout mesure. Le résultat était spectaculaire :

repetition_penalty est LE levier. Passer de 1,2 → 1,3 a à peu près doublé la cohérence (38 → 76) et tué la répétition — et surtout, le texte est resté naturel (vérifié à l'œil, pas que par les métriques). Zéro réentraînement. Le plus grand saut de qualité de toute la semaine est venu d'une seule valeur de config.

⚠️ Note : en décodage greedy le même modèle répète massivement (rep 0,50), mais en sampling c'est propre (rep 0,07). Les petits modèles ont besoin du sampling — greedy les piège en boucles.

---

🧪 Niveau 5 — la campagne innovation (tout contraster)

C'est là que je suis passé en mode recherche. L'idée : le contrastive decoding pour pousser la qualité encore plus loin. J'ai mené une campagne complète.

Contrastive Decoding (Li et al. 2022)

logits = (1+λ)·expert − λ·amateur, avec la contrainte de plausibilité (α-masking). Trois variantes de contraste testées :

Le pattern : à 15M, le contraste n'aide que s'il y a un vrai écart de capacité. Trop proche (checkpoints, couches) = rien à soustraire. Trop loin (un amateur qui bafouille) = on soustrait du bruit. Il y a une fenêtre étroite.

Le bug qui a failli me donner un faux négatif

Le moment honnête. Mon premier run CD disait "échec total, tout dégrade." Un réflexe de relecteur m'a fait vérifier le code plutôt que de croire le résultat.

Le script CD n'appliquait pas le sampling optimal (rep_pen 1.3) — il comparait un CD non réglé contre une baseline non réglée, les deux en boucle. L'"échec" était un bug méthodologique, pas un résultat. Avec le même sampling des deux côtés, le CD classique aide légèrement.

Leçon : un résultat négatif d'un harnais buggé ne vaut rien. Toujours vérifier le code avant de publier la conclusion.

Éval qualitative — ce que les métriques ne voyaient pas

Les chiffres disaient "+1,9 cohérence". J'ai lu les vraies générations, baseline vs CD, sur des prompts factuels :

• Factualité : ❌ aucune amélioration — les deux inventent autant (capitale de la France ≠ Paris dans les deux cas).
• Propreté : ✅ le CD supprime les artefacts. Sur "La Seconde Guerre mondiale a duré de", la baseline produisait des emojis-chiffres parasites ("3⃣3⃣7⃣ ans") ; le CD non.
• Fluidité : ✅ le CD se lit légèrement mieux, des templates d'articles plus nets.

Le CD nettoie les tics de génération (l'amateur en a aussi → ils sont soustraits) mais ne peut pas créer de savoir que l'expert n'a pas. Exactement ce que la théorie prédit.

---

✅ Ce qui a marché

• 🧹 Document packing — a tué la dérive structurelle, la plus grande correction de données
• 🎰 repetition_penalty 1.3 — cohérence doublée, gratuit, une valeur de config
• 🐛 Correction des tokens spéciaux — le modèle reste sur son sujet
• 📊 Un harnais de mesure reproductible — chaque affirmation est falsifiable
• 🧪 CD classique — gain qualitatif petit mais réel

❌ Ce qui n'a pas marché (et c'est normal — c'est de la recherche)

• 📉 CD entre checkpoints — distributions trop corrélées
• 📉 DoLa — 8 couches c'est trop peu pour le contraste par couche
• 🎯 Factualité — irréductible à 15M sur un corpus longue traîne. Aucune astuce de décodage n'invente des faits.
• 📚 +100k articles — même format un-sujet-par-fichier, ne changera pas la factualité à cette taille

⚠️ Limites

• 15M paramètres reste un modèle de style, pas une base de connaissance
• Le corpus longue traîne plafonne la factualité quel que soit le décodage
• Les vrais gains factuels nécessitent soit du RAG soit un scale-up à 25-30M (avec les données supplémentaires) — un prochain chapitre

---

📋 Référence rapide — état final

---

🏁 Conclusion

Une semaine de travail et pas une ligne de nouvelle architecture. Les gains sont venus d'endroits ennuyeux : comment les données sont découpées, deux tokens spéciaux, un hyperparamètre de décodage. La recherche flashy (contrastive decoding, DoLa) a donné les plus petits gains — et l'un d'eux était presque un faux négatif causé par mon propre harnais buggé.

La vraie leçon ne concerne pas les LLM français. C'est que une fois que l'architecture passe le seuil, le goulot d'étranglement est partout sauf dans l'architecture. Mesurer d'abord. Lire ses propres données. Vérifier son code avant de croire ses conclusions. Le modèle n'a jamais été le problème.

Prochaine étape : le seul levier restant au niveau des données — scale-up à 25-30M avec le corpus élargi, sur du vrai cloud compute. Mais ça, c'est le prochain article. 🚀

---

❓ Q&R

— Tu as passé une semaine et la PPL est passée de 17,8 à… 17,8 ?

Exact — la PPL a plafonné, parce que le run 60% × 6 avait déjà atteint le plafond données du modèle. Les gains de la semaine sont dans la qualité de génération (cohérence doublée, dérive corrigée, artefacts supprimés), que la PPL ne capture pas. C'est exactement pourquoi j'ai construit un harnais multi-métriques plutôt que de faire confiance à la perplexité seule.

— Le contrastive decoding valait l'effort pour +1,9 de cohérence ?

En tant que feature produit, à peine. En tant que recherche, oui : ça produit un résultat propre et falsifiable sur quand le contraste aide à petite échelle (un écart de capacité est nécessaire), et l'histoire du débogage du faux négatif est plus instructive que le gain lui-même.

— Pourquoi ne pas simplement accepter le modèle et passer à autre chose ?

Parce que le but n'a jamais été le modèle — c'était comprendre chaque levier. Maintenant je sais, chiffres à l'appui, quels leviers bougent quoi. C'est transférable au run scale-up d'une façon que "ça a l'air mieux" ne permettrait jamais.

---

💡 Le saviez-vous ?

Un résultat négatif n'est fiable qu'à hauteur du harnais qui l'a produit. Mon premier run de contrastive decoding rapportait "échec total" — et c'était faux, parce que le code d'évaluation n'appliquait pas le même sampling des deux côtés. Un bug de mesure ne te donne pas une petite erreur ; il peut inverser entièrement ta conclusion.

---

Théo CHARLET

Diplômé du TSSR (Technicien en systèmes et réseaux informatiques) – Spécialisation IA/ML

Créateur d’AG-BPE (Attention-Guided Byte-Pair Encoding)

🔗 LinkedIn : https://www.linkedin.com/in/théo-charlet

🔎 RDTvlokip Search (mon moteur de recherche) : https://search.rdtvlokip.fr

🚀 À la recherche d'opportunités de stage

🔗 Site web : https://rdtvlokip.fr

🔗 GitHub du projet : https://github.com/RDTvlokip/GPT-2-French-From-Scratch