Le pré-préentraînement synthétique des LLM n’est pas rentable : à nombre égal de FLOPs, il fait moins bien que le texte ordinaire

L’idée est séduisante : avant de faire ingérer à un modèle de langage des téraoctets de données issues d’Internet, on lui offre un « échauffement » sur de la structure pure. Automates cellulaires, langages aux parenthèses correctement imbriquées, séquences générées de manière procédurale. En théorie, le modèle apprendrait à l’avance des motifs utiles, puis assimilerait plus rapidement le langage réel. C’est ce que l’on appelle le pré-préentraînement synthétique, ou PPT.

La nouvelle étude Rethinking Pre-Pretraining, signée Alexander Stern, Tim Rocktäschel, Akir Lokatelli et Laura Ruis, soumet cette idée à un test sans complaisance. Elle montre qu’une hypothèse élégante ne résiste pas à une comptabilité rigoureuse.

Où est le piège ?

La plupart des précédents articles consacrés au PPT comparaient les modèles sans tenir compte du volume de calcul consacré à l’étape synthétique. Les auteurs ont fixé un budget total de FLOPs : si une partie est dépensée sur les données synthétiques, il en reste moins pour le texte naturel. Dans ces conditions, le PPT n’a jamais surpassé un entraînement effectué uniquement sur du langage naturel.

Prenons un exemple chiffré. Avec 100M de tokens FineWeb et un budget de 1 × 10¹⁸ FLOPs, un entraînement conventionnel répétant le texte atteint 1.064 bit par octet (BPB) en validation — plus la valeur est basse, mieux c’est. Si l’on consacre entre 1% et 10% des calculs au PPT, la métrique se dégrade pour atteindre 1.068–1.076. L’écart est faible, mais sa direction est sans ambiguïté : vous avez dépensé davantage de calcul pour obtenir un résultat inférieur.

L’explication est simple. Lorsque le modèle passe au langage naturel, les gradients réécrivent rapidement les structures apprises sur les données synthétiques. C’est comme apprendre des ouvertures d’échecs, puis jouer aux dames pendant six mois.

D’où venaient les succès précédents ?

La partie la plus intéressante de l’étude analyse pourquoi le PPT paraissait utile. Les auteurs ont reproduit une expérience menée avec des automates cellulaires neuronaux (NCA), un modèle LLaMA de 400M de paramètres et OpenWebText. Le PPT fondé sur les NCA apportait un gain de 5,4% en perplexité.

Mais il suffit de remplacer l’initialisation des embeddings 𝒩(0, 1) par 𝒩(0, 0.02), la norme pour ce type de modèle, pour améliorer de 9,0% la baseline dépourvue de PPT. Ce changement efface entièrement le bénéfice des données synthétiques. Autrement dit, le PPT corrigeait en grande partie une mauvaise initialisation au lieu d’apporter des connaissances au modèle.

Les auteurs ont également proposé DeclRef, un corpus synthétique consacré à la recherche des valeurs de variables, ainsi que LLMTuna, un outil d’optimisation des hyperparamètres fondé sur un LLM. Le code des deux projets est disponible en open source sur GitHub.

Limites

Ces conclusions doivent être interprétées avec prudence. Tous les modèles comptent moins de 1B de paramètres, et on ignore si le PPT se comporte de la même manière à l’échelle de plusieurs dizaines de milliards de paramètres. Le test portant sur l’initialisation de LLaMA et les expériences de mélange des données ont été réalisés sans nouvelle recherche d’hyperparamètres ; un réglage fin pourrait donc modifier une partie des résultats.

Il faut aussi souligner qu’il s’agit d’un résultat négatif concernant une catégorie précise de méthodes. Il ne remet pas en cause l’utilité générale des données synthétiques, notamment pour poursuivre l’entraînement sur du code ou des mathématiques.

Conséquences pratiques

Si vous entraînez vos propres modèles, en particulier de petite taille, les conclusions sont les suivantes :

• N’ajoutez pas une étape de PPT synthétique au pipeline « au cas où ». Elle consomme du calcul et, d’après les données, ne rentabilise pas ce coût.
• Avant de croire à un gain spectaculaire apporté par une nouvelle astuce, vérifiez les fondamentaux : initialisation, learning rate et scheduler. Une baseline faible crée facilement une illusion de progrès.
• Comparez les méthodes avec un budget de FLOPs identique, et non avec le même nombre d’étapes ou de tokens de texte naturel.

La principale leçon dépasse le sujet lui-même : beaucoup d’« améliorations » en ML ne font en réalité que compenser une baseline mal réglée. Sans groupe de contrôle solide assorti d’un budget équitable, vous mesurez probablement vos propres insuffisances plutôt que la méthode.