Entraîner un modèle de langage à partir de zéro n’est pas un exercice de force brute computationnelle. C’est un projet d’ingénierie avec des dizaines de décisions en chaîne où une erreur précoce peut invalider des semaines de calcul et des milliers d’euros de GPU. La plupart des guides expliquent le pipeline idéal (tokeniseur, jeu de données, préentraînement, ajustement fin), mais presque aucun ne s’arrête sur les échecs qui se produisent réellement lorsque quelqu’un tente de le mettre en pratique. Cet article couvre précisément cela : les erreurs les plus fréquentes et comment les détecter avant qu’il ne soit trop tard.
Erreurs dans la phase de données : l’origine de presque tout
1. Mesurer le jeu de données en gigaoctets plutôt qu’en tokens utiles
Une erreur courante consiste à se vanter de la taille d’un corpus sur disque. Un fichier compressé de 50 Go peut contenir moins de texte utile qu’il n’y paraît, et après déduplication et filtrage du boilerplate HTML, il peut ne rester qu’une fraction. Ce qui compte, c’est le nombre de tokens après la tokenisation réelle, pas le poids du fichier.
Comment l’éviter : tokenisez un échantillon représentatif (par exemple, 1 Go décompressé) avec le tokeniseur exact que vous allez utiliser, calculez le ratio tokens/caractère et extrapolez. Répétez le calcul après chaque phase de nettoyage. Si le corpus final n’atteint pas un volume raisonnable pour la taille du modèle, reconsidérez l’objectif avant de lancer l’entraînement.
2. Dédupliquer uniquement par correspondance exacte
La déduplication par hachage exact élimine les copies identiques, mais laisse passer les paraphrases, les modèles répétés et les fragments quasi dupliqués qui gonflent artificiellement certaines distributions. Le modèle finit par mémoriser des phrases récurrentes et générer des sorties répétitives.
Comment l’éviter : appliquez une déduplication floue par n-grammes ou par similarité de MinHash sur des blocs de documents. Vous n’avez pas besoin d’un système parfait : éliminer les doublons proches au niveau du paragraphe réduit déjà beaucoup le bruit.
3. Ignorer le mélange de domaines et le filtrage de qualité
Mélanger du web générique, du code, des articles scientifiques et des forums sans pondération produit des modèles qui imitent le ton d’un forum dans des réponses qui devraient être formelles. Il est également courant de ne pas filtrer le contenu toxique, le spam ou le texte généré automatiquement.
Comment l’éviter : définissez des proportions explicites par source, documentez l’origine de chaque bloc et appliquez des classificateurs de qualité légers. Selon la documentation officielle de plusieurs projets ouverts, le filtrage de qualité a plus d’impact sur le résultat final que l’ajout de données de faible qualité.
4. Contamination du jeu d’évaluation
C’est probablement l’erreur la plus silencieuse. Si votre jeu de validation ou vos benchmarks internes apparaissent, même partiellement, dans les données d’entraînement, les métriques mentent. Un modèle qui « s’améliore » à chaque évaluation peut simplement être en train de mémoriser.
Comment l’éviter : séparez les jeux d’évaluation avant de construire le corpus, conservez des empreintes (hachages de n-grammes) de ces jeux et vérifiez le chevauchement avec le jeu de données d’entraînement. S’il y a des correspondances, supprimez-les du corpus, pas du test.
Erreurs dans la tokenisation et l’architecture
5. Entraîner le tokeniseur avec un corpus qui ne représente pas le domaine final
Si le tokeniseur est entraîné uniquement en anglais et que le modèle est ensuite utilisé en espagnol ou sur du code, le nombre de tokens par mot explose, la fenêtre de contexte effective se réduit et le coût d’entraînement et d’inférence augmente sans que cela se remarque dans les métriques initiales.
Comment l’éviter : entraînez le tokeniseur avec un échantillon stratifié qui reflète les langues et domaines réels d’utilisation. Vérifiez avec du texte hors échantillon combien de tokens consomme une même phrase dans différentes langues ; s’il y a des différences abyssales, révisez le vocabulaire.
6. Choisir la taille du modèle sans budget de calcul clair
Un modèle plus grand n’est pas toujours meilleur pour un objectif concret, et il impose en outre des exigences de mémoire et de temps que beaucoup de projets sous-estiment. Lancer un préentraînement sans avoir calculé le coût total (heures de GPU, checkpoints, stockage, redémarrages) est une voie rapide vers l’échec.
Comment l’éviter : faites un test de mise à l’échelle avec un petit modèle pendant quelques heures, mesurez le débit réel sur votre matériel et extrapolez. Si le budget ne couvre pas l’entraînement complet plus au moins un redémarrage depuis un checkpoint, réduisez la taille.
7. Ne pas définir une longueur de contexte réaliste
Annoncer des contextes énormes sans données qui les exploitent génère des modèles qui performent moins bien sur de longues fenêtres que ce que suggère l’architecture. L’attention sur de longues séquences renchérit l’entraînement et, si le corpus est composé de documents courts, le modèle n’apprend jamais à l’utiliser.
Comment l’éviter : alignez la longueur de séquence sur la distribution réelle de vos documents. Si vous avez besoin d’un contexte long, incluez des données à structure longue et évaluez spécifiquement les tâches qui le requièrent.
Erreurs pendant le préentraînement
8. Ne pas surveiller la perte par domaine
La perte globale peut baisser tandis qu’un domaine concret se dégrade. Si le modèle surapprend le web générique et perd en capacité sur du code ou dans une langue spécifique, la métrique agrégée le masque.
Comment l’éviter : enregistrez la perte de validation ventilée par source. Un tableau de bord avec des courbes séparées par domaine détecte les déséquilibres bien avant la moyenne globale.
9. Checkpoints insuffisants ou mal gérés
Ne sauvegarder qu’à la fin est un pari. Les défaillances matérielles, les redémarrages du cluster ou l’instabilité numérique peuvent obliger à répéter des jours de calcul. Il est également courant de sauvegarder des checkpoints sans enregistrer la configuration exacte associée, ce qui rend impossible la reproduction de l’état.
Comment l’éviter : sauvegardez des checkpoints périodiques avec leur configuration, leur graine et l’état de l’optimiseur. Vérifiez que la reprise depuis un checkpoint fonctionne avant de lancer l’entraînement long.
10. Ignorer l’instabilité numérique
Les pics de perte, les gradients qui explosent ou les NaN intermittents sont des signaux que la configuration d’entraînement n’est pas stable. Beaucoup de projets les traitent comme du bruit et continuent, et le modèle final se retrouve dégradé d’une manière difficile à diagnostiquer.
Comment l’éviter : utilisez le découpage des gradients, révisez l’échelle d’initialisation et testez avec des séquences plus courtes avant de monter en échelle. Si des NaN apparaissent, arrêtez-vous et analysez ; ne redémarrez pas à l’aveugle.
Erreurs dans l’ajustement fin et l’évaluation
11. Confondre l’ajustement fin avec la solution à tout
L’ajustement fin ne corrige pas un préentraînement déficient. Si le modèle de base n’a pas la capacité ou les données suffisantes, l’ajustement fin ne fait que maquiller le résultat sur le jeu d’évaluation et généralise mal.
Comment l’éviter : évaluez le modèle de base avant d’ajuster. Si les métriques de base sont faibles, investissez dans les données et le préentraînement, pas dans davantage d’époques d’ajustement.
12. Évaluer uniquement avec des métriques automatiques
La perplexité et la précision sur des tâches synthétiques ne décrivent pas le comportement réel. Un modèle peut s’améliorer sur une métrique et devenir plus répétitif, plus dangereux ou moins utile en conversation.
Comment l’éviter : combinez les métriques automatiques avec des évaluations humaines sur un échantillon petit mais bien défini. Documentez les critères et vérifiez périodiquement s’ils mesurent toujours ce qui vous importe.
13. Ne pas documenter le processus
Sans registre des versions de données, des hyperparamètres et des résultats, chaque expérience est irreproductible. Ce n’est pas un détail académique : en production, quand quelque chose échoue, la traçabilité est ce qui permet de diagnostiquer.
Comment l’éviter : versionnez le jeu de données, la configuration et les checkpoints avec des identifiants clairs. Un registre minimal mais cohérent évite des semaines de confusion.
Un cas concret qui illustre le problème
Dans un projet réel d’ajustement d’un petit modèle pour des réponses techniques en espagnol, l’équipe a détecté que le modèle générait des réponses correctes mais avec un ton étrangement promotionnel. La cause ne se trouvait pas dans l’ajustement fin : le corpus de préentraînement incluait une proportion élevée de pages marketing et de blogs produits qui dominaient certains sujets. La perte globale était bonne et les métriques automatiques ne le détectaient pas. On a corrigé en rééquilibrant le mélange de domaines et en filtrant le contenu promotionnel, pas en ajoutant plus de données.
Ce type de problème ne se détecte qu’en lisant régulièrement les sorties réelles du modèle et en les comparant à ce qui est attendu, pas seulement en regardant les courbes de perte.
Ce que cet article ne couvre pas et pourquoi
Entraîner un LLM à partir de zéro à l’échelle industrielle nécessite une infrastructure distribuée, des stratégies de parallélisme et des optimisations de mémoire qui dépendent du matériel concret et du framework choisi. Ce qui est décrit ici se concentre sur les erreurs de jugement qui affectent toute échelle, depuis un petit modèle sur un seul GPU jusqu’à un projet plus important. Aucune de ces recommandations ne garantit des résultats : le comportement final dépend de l’interaction entre les données, l’architecture et la configuration, et il y a toujours de l’incertitude.
Si quelque chose caractérise ceux qui ont entraîné des modèles avec succès, c’est la prudence : ils partent du principe que le jeu de données a des problèmes, que les métriques peuvent tromper et que le premier entraînement ne sera pas le définitif. Planifier pour cette réalité fait gagner plus de temps que n’importe quelle optimisation prématurée.