Aller au contenu

Générer des données synthétiques pour entraîner un LLM

Générer des données synthétiques pour entraîner un modèle, pourquoi et comment ?

Générer des données synthétiques sert à combler un manque, un jeu de données réel trop petit, trop sensible, ou trop coûteux à annoter. Ce n'est pas une astuce pour aller plus vite, c'est une réponse à un manque mesuré. La règle ne change jamais. On ancre la génération sur du réel, on vérifie ce qu'on produit, et on ne touche jamais au jeu de test.

Dans cet article, je détaille pourquoi générer des données synthétiques pour l'entraînement, comment construire un pipeline qui tient la route (grounding, diversité, vérification, backreasoning), ce que montre le projet SYNTH de Pleias sur des modèles entraînés uniquement sur données synthétiques, le risque réel du model collapse, et la méthode que j'applique sur le terrain quand un dataset de classification est trop petit.

Entraînement, pas évaluation. Cet article traite les données synthétiques pour entraîner un modèle. Si votre besoin est de mesurer un RAG existant, générer des questions de test est un problème différent. J'y consacre un article dédié sur comment construire un dataset d'évaluation RAG. Les deux usages partagent des techniques, mais pas le même objectif ni les mêmes précautions.

Pourquoi générer des données synthétiques pour l'entraînement ?

Générer des données synthétiques se justifie dans des cas précis, pas comme réflexe par défaut. Quatre situations reviennent le plus souvent sur le terrain.

  • le jeu de données réel est trop petit pour représenter la diversité des cas rencontrés en production ;
  • les données réelles contiennent des informations personnelles ou sensibles qu'on ne peut pas exposer à un pipeline d'entraînement sans risque ;
  • les données disponibles ne sont pas librement réutilisables (licence, droit d'auteur, contrat client) ;
  • le volume nécessaire pour amorcer un entraînement dépasse ce qu'on peut annoter à la main dans un délai raisonnable.

Le levier confidentialité. La CNIL recommande de privilégier des données synthétiques ou agrégées quand la performance du modèle le permet, plutôt que d'exposer des données personnelles réelles à un pipeline d'entraînement (recommandations CNIL sur le développement des systèmes d'IA). Ça ne dispense pas de vérifier que la génération ne recrée pas indirectement des individus réels, mais ça réduit la surface d'exposition.

Le levier licence. Le projet SYNTH de Pleias, sur lequel je reviens plus bas, illustre cette logique jusqu'au bout. Chaque texte source utilisé comme seed est attribué et republié sous sa licence d'origine (CC-BY-SA), ce qui rend le dataset synthétique lui-même réutilisable légalement, pas seulement le modèle qui en sort (SYNTH: the new data frontier, Pleias).

Le levier volume. Gartner estimait dès 2021 que 60 % des données utilisées pour les projets IA et analytics seraient synthétiques d'ici 2024 (prévision Gartner, 2021). C'est une estimation de marché, pas une mesure, à prendre pour ce qu'elle est, un ordre de grandeur d'intention. Sur le terrain, la raison qui revient le plus est plus simple. Le jeu réel ne couvre tout simplement pas assez de cas.

Comment construire un pipeline de génération qui tient la route

Un pipeline de génération de données synthétiques repose sur trois piliers. Partir d'un fait réel, forcer la diversité des cas produits, et vérifier chaque exemple avant de l'utiliser. Sauter une de ces étapes, c'est prendre le risque de biaiser silencieusement le futur modèle.

Le grounding sur des seeds réelles, et les contraintes de diversité

Une seed, c'est le document ou le fait réel qui sert de point de départ à la génération. Pour SYNTH, Pleias est partie de 50 000 articles Wikipedia jugés "vitaux", puis les a étendus en une large collection de problèmes et de chemins de résolution, des exercices de mathématiques, de l'écriture, de l'extraction d'information, de la synthèse sourcée.

Sans contrainte, un LLM a tendance à produire toujours la même forme de réponse. Pleias introduit des contraintes aléatoires à différentes étapes du pipeline (angle de la question, format attendu, longueur de la réponse) pour forcer la diversité, plutôt que de laisser le générateur retomber sur ses tics.

Vérifier avec un LLM-as-a-judge et des contrôles formels

Générer ne suffit pas, il faut filtrer. Deux mécanismes se complètent. Des contrôles formels (le format est-il respecté, les champs attendus sont-ils présents) et un LLM-as-a-judge qui évalue la qualité de chaque exemple généré.

Pleias a mesuré qu'écarter les raisonnements bancals ("tortured reasoning traces") améliorait les performances du modèle final, même au prix d'un volume de données réduit. C'est le même principe que sur un dataset annoté à la main, mieux vaut moins d'exemples propres que beaucoup d'exemples douteux.

Le backreasoning, remonter du fait vers le raisonnement

Pleias appelle ça le backreasoning, ou traceback. Au lieu de générer une question puis sa réponse, le pipeline part d'un fait vérifiable, un passage précis d'un article Wikipedia par exemple, et remonte vers le raisonnement et la question qui y mènent.

Le modèle générateur agit comme s'il ne connaissait pas encore la réponse, et reconstruit le cheminement qui y conduit, plutôt que de répondre puis de justifier après coup. Ça change la nature de la donnée produite. Chaque affirmation factuelle peut être retracée jusqu'à une source vérifiable, ce qui rend le dataset auditable, et pas seulement plausible.

Le projet SYNTH de Pleias, des modèles entraînés uniquement sur des données synthétiques

Le laboratoire français Pleias a entraîné deux modèles, Baguettotron et Monad, exclusivement sur SYNTH, un corpus synthétique de moins de 200 milliards de tokens (SYNTH: the new data frontier). Selon Pleias, ce volume représente 10 à 50 fois moins de tokens que des modèles comparables, et le run final a demandé moins de 1 000 heures de calcul H100.

Modèle Paramètres Couches Compute (run final) Signal notable
Monad 56 millions 64 moins de 6 h sur 16 GPU H100 le plus petit modèle de langage "viable" documenté par Pleias à ce jour
Baguettotron 321 millions 80 moins de 1 000 h H100 signaux MMLU cohérents dès les 2 premières heures d'entraînement

Les deux modèles partagent une architecture en profondeur extrême, 64 et 80 couches pour des tailles de quelques centaines de millions de paramètres, un choix qui privilégie la profondeur sur la largeur pour muscler le raisonnement. SYNTH est aussi environ 20 % multilingue, avec du français, de l'allemand, de l'espagnol, de l'italien et du polonais. Le projet complet, génération comprise, a consommé environ 20 000 heures H100 sur le supercalculateur Jean Zay grâce à une allocation Genci.

Pleias présente Baguettotron comme le meilleur de sa catégorie de taille sur des benchmarks précis (MMLU, GSM8K, HotPotQA), pas meilleur en général. Soyons clairs, ce n'est pas un GPT-5 à la maison. C'est une preuve de méthode, sur un périmètre de raisonnement défini, obtenue avec un budget de calcul modeste comparé à celui des laboratoires frontière.

Ce niveau de documentation n'est pas accessoire, c'est ce que Pleias appelle la releasability, la capacité à republier légalement un dataset synthétique parce que le modèle générateur et les seeds sont attribués. Les modèles ouverts récents (Qwen, DeepSeek, GPT-OSS) ne restreignent plus l'usage de leurs sorties synthétiques, et chaque seed republiée l'est sous sa licence d'origine. Même à petite échelle, sur un dataset interne d'entreprise, noter quel modèle a généré quoi, avec quel prompt et quelle version, reste la seule façon de revenir en arrière si un biais apparaît plus tard.

Le model collapse, le risque quand on boucle sur ses propres sorties

Le model collapse est la dégradation progressive d'un modèle entraîné de façon répétée sur des données générées par des modèles précédents, sans jamais réintroduire de données réelles. Le papier de Shumailov et al., publié dans Nature en 2024, montre que ce mécanisme fait disparaître les cas rares de la distribution d'origine, de façon irréversible (AI models collapse when trained on recursively generated data, Nature 2024).

Le mécanisme est simple à comprendre. Chaque génération de modèle entraînée sur les sorties de la précédente amplifie ses propres erreurs et réduit la diversité de ce qu'elle produit. Répété plusieurs fois, sans jamais réinjecter de données réelles, ça converge vers une sortie appauvrie. Les auteurs observent l'effet sur des LLM, mais aussi sur des autoencodeurs variationnels et des mixtures de gaussiennes. Ce n'est pas un problème propre aux modèles de langage.

Les pipelines sérieux évitent ça par construction, pas par chance. Le grounding permanent sur des seeds réelles (Wikipedia pour SYNTH) empêche le pipeline de générer à partir de ses propres générations précédentes. La vérification qui filtre les mauvaises générations, plutôt que de les garder pour gonfler le volume, coupe une bonne partie des boucles d'erreurs avant qu'elles ne s'accumulent. Le model collapse arrive quand on entraîne naïvement, pas quand on ancre et qu'on vérifie.

Mon terrain, compléter un dataset de classification trop petit

Sur un projet de classification d'intentions, le jeu fourni tenait sur environ 90 exemples annotés, largement insuffisant pour couvrir la diversité des messages réels. La méthode que j'ai appliquée, générer pour compléter, jamais pour remplacer le test.

Concrètement, j'ai généré 20 à 30 exemples par classe, en français, en anglais et en mixte, en ciblant volontairement les cas durs, les prompts ambigus, les messages vides, les messages qui mélangent plusieurs intentions. Un dataset synthétique qui ne couvre que les cas faciles ne sert à rien, le modèle les gérait déjà.

Deuxième correction, j'ai reconstruit le contexte multi-tours, les dix derniers échanges entre l'utilisateur et l'assistant, au lieu de ne générer des exemples qu'à partir du premier message. Une intention se lit rarement dans une seule phrase isolée.

Enfin, séparation stricte entre le train augmenté (réel + synthétique), la validation, et un jeu de test holdout composé uniquement d'exemples réels, jamais générés. On serait tenté de gonfler le test aussi, ça donnerait des chiffres plus flatteurs. C'est justement ce qu'il ne faut pas faire. Un test pollué par du synthétique ne mesure plus rien d'utile. Comme pour le fine-tuning d'un SLM, on gagne le droit de générer, on ne se l'accorde pas par défaut.

Questions fréquentes sur les données synthétiques pour l'entraînement

Qu'est-ce que des données synthétiques en machine learning ? Ce sont des exemples d'entraînement générés artificiellement, le plus souvent par un LLM, plutôt que collectés ou annotés à la main. On les utilise pour compléter un dataset réel trop petit, réduire l'exposition de données personnelles, ou contourner des contraintes de licence. Les pipelines sérieux les ancrent sur des sources réelles pour éviter qu'elles dérivent du monde réel.

Pourquoi utiliser des données synthétiques pour entraîner un LLM ? Quatre raisons reviennent le plus souvent. Le jeu réel est trop petit, les données sont trop sensibles pour être exposées à un pipeline d'entraînement, les données disponibles ne sont pas librement réutilisables, ou le volume nécessaire dépasse ce qu'on peut annoter à la main.

Qu'est-ce que le model collapse et comment l'éviter ? C'est la dégradation d'un modèle entraîné de façon répétée sur des données générées par des modèles précédents, sans données réelles. Les cas rares disparaissent, de façon irréversible selon Shumailov et al. On l'évite en ancrant la génération sur des seeds réelles et en filtrant les mauvaises générations.

Combien de données synthétiques faut-il pour compléter un dataset réel ? Pas de règle fixe, mais 20 à 30 exemples générés par classe suffisent souvent sur une tâche de classification, à condition de couvrir les cas durs et de garder un jeu de test composé uniquement d'exemples réels.

Qu'est-ce que le backreasoning (ou traceback) en génération de données synthétiques ? Une méthode qui part d'un fait réel et remonte vers le raisonnement et la question qui y mènent, au lieu de générer d'abord une question puis sa réponse. Ça ancre la donnée synthétique dans du vérifiable.

Les données synthétiques remplacent-elles les données réelles ? Non, elles les complètent. Même SYNTH, qui entraîne des modèles uniquement sur du synthétique, ancre chaque exemple sur une source réelle. Le jeu de test doit toujours rester composé d'exemples réels.

Comment vérifier la qualité d'un dataset synthétique ? Des contrôles formels et un LLM-as-a-judge. Pleias a mesuré qu'écarter les mauvais raisonnements améliorait les performances finales, même au prix d'un volume de données plus faible.

Peut-on entraîner un modèle uniquement sur des données synthétiques ? Oui, Pleias l'a fait avec Baguettotron et Monad sur le corpus SYNTH. Mais c'est un résultat de recherche qui prouve une méthode sur un périmètre de raisonnement précis, pas un remplacement généralisé des données réelles.

Pour aller plus loin

Si mes articles vous intéressent, que vous avez des questions ou simplement envie de discuter de vos propres défis liés à l'IA, n'hésitez pas à m'écrire à anas@tensoria.fr, j'adore échanger sur ces sujets !

Vous vous demandez si générer des données synthétiques a du sens pour votre projet ? Découvrez mon activité de conseil sur tensoria.fr.

Vous pouvez aussi réserver un créneau d'échange ou vous abonner à ma newsletter :)

À propos de moi

Je suis Anas Rabhi, consultant Data Scientist freelance. J'accompagne les entreprises dans leur stratégie et mise en œuvre de solutions d'IA (RAG, Agents, NLP).

Découvrez mes services sur tensoria.fr ou testez notre solution d'agents IA heeya.fr.