Systèmes de Machine Learning

Pipeline de données synthétiques pour le fine-tuning métier

Un pipeline contrôlé pour générer, filtrer, versionner et évaluer des données synthétiques métier tout en maîtrisant contamination, règles et distribution.
11 avril 20265 min de lectureDonnées synthétiquesFine-tuning
Les données synthétiques sont utiles lorsque les exemples réels sont rares, sensibles, coûteux à labelliser ou incomplets sur des cas limites importants. Elles deviennent dangereuses lorsqu'une équipe génère un grand volume de textes plausibles en supposant que la quantité améliorera automatiquement le modèle. Un pipeline de production doit rendre trois éléments visibles : pourquoi chaque exemple existe, comment il a été généré et s'il améliore le comportement sur des tâches réelles indépendantes.

Définir d'abord le manque de couverture

Il ne faut pas commencer en demandant à un modèle de créer davantage d'exemples. Il faut construire une cartographie de couverture :
  • tâches cibles et formats de sortie ;
  • langues, domaines et profils utilisateurs ;
  • intentions fréquentes et rares ;
  • règles de sécurité et de refus ;
  • besoins en outils ou sorties structurées ;
  • clusters d'erreurs connus ;
  • exemples explicitement exclus de l'entraînement.
Chaque campagne de génération cible un manque documenté. Cette règle rend le jeu inspectable et empêche une catégorie volumineuse d'écraser des comportements plus rares mais critiques. Des exemples réels, documents métier, schémas et modèles écrits par des experts peuvent fournir les amorces. Ils doivent être versionnés et séparés selon leurs droits d'utilisation et leur sensibilité. Une source sensible ne doit jamais être envoyée à un générateur non approuvé ni être reproduite dans les sorties synthétiques.

Générer avec une provenance complète

Pour chaque enregistrement synthétique, il faut stocker :
  • la campagne et son objectif ;
  • l'identifiant de l'amorce ou du gabarit ;
  • le modèle générateur et sa configuration ;
  • la version du prompt ;
  • les paramètres de génération ;
  • la date de génération ;
  • la sortie brute et ses transformations ;
  • les résultats de validation ;
  • le statut de revue et la décision finale.
La génération structurée est préférable lorsque la cible possède un schéma. Lorsque c'est possible, les entrées et les sorties attendues sont générées séparément, puis leur cohérence est vérifiée. Pour la classification ou l'extraction, des modèles programmatiques peuvent offrir davantage de contrôle qu'une génération libre. La diversité doit être intentionnelle. On varie la forme linguistique, la longueur du contexte, l'ambiguïté et la difficulté sans modifier la sémantique cible. Un générateur qui paraphrase constamment le même cas facile crée du volume apparent sans information nouvelle.

Filtrer en plusieurs couches

Aucun score unique ne suffit. J'utilise des filtres successifs :
  • Contrôles de schéma : champs requis, types, plages et parseabilité.
  • Contrôles de politique : contenus sensibles, sujets interdits, instructions dangereuses et fuites de données.
  • Déduplication : similarité exacte, normalisée et sémantique face aux jeux d'entraînement et d'évaluation.
  • Contrôles de cohérence : réponse soutenue par le contexte, arguments d'outils valides, labels conformes aux règles.
  • Contrôles de difficulté et couverture : distribution alignée avec l'objectif de génération.
  • Échantillonnage expert : revue métier pour les catégories où l'automatisation est moins fiable.
Les modèles juges peuvent faciliter le tri, mais ne doivent pas être l'unique filtre lorsque la même famille de modèles a généré les données. L'accord entre deux modèles ne prouve pas la justesse métier.
Pipeline de données synthétiques reliant couverture, provenance de génération, contrôles qualité, revue experte, versionnement et évaluation protégée
Un jeu synthétique fiable conserve une provenance, des décisions de filtrage, une revue experte et une couverture d'évaluation inspectables pour chaque campagne.

Protéger la frontière d'évaluation

Les données synthétiques peuvent contaminer silencieusement l'évaluation. Si le générateur voit des exemples de test, des prompts d'évaluation ou des paraphrases proches, le score final peut mesurer la mémorisation du benchmark. Les jeux d'évaluation restent immuables et protégés. Les enregistrements générés sont dédupliqués face à toutes les partitions d'évaluation avant l'entraînement. Lorsqu'un ensemble synthétique dérive d'un cas réel, toutes les variantes associées sont regroupées afin qu'elles ne puissent pas se retrouver des deux côtés de la frontière entraînement-test. L'évaluation finale doit privilégier des tâches métier réelles et indépendantes. Des tests synthétiques peuvent vérifier des règles précises, mais ils ne prouvent pas la généralisation aux utilisateurs réels.

Versionner ensemble les données et l'entraînement

Un résultat de fine-tuning n'est reproductible que si l'équipe peut le relier précisément aux :
  • versions des sources et données synthétiques ;
  • configurations de filtrage ;
  • poids d'échantillonnage ;
  • tokenizer et modèle de base ;
  • code d'entraînement et hyperparamètres ;
  • jeux d'évaluation et versions des évaluateurs.
La qualité doit être suivie par segment, pas seulement via la fonction de perte à l'entraînement. Si la performance progresse sur la catégorie synthétique dominante mais régresse sur les cas limites réels, le pipeline a optimisé la mauvaise distribution. La checklist MLOps pour la production détaille les contrôles de lignée, les preuves de mise en production, la supervision et le retour arrière requis autour du modèle obtenu. Mon étude de cas publique Ecotopia présente le fine-tuning de quatre modèles Mistral avec QLoRA et la construction d'évaluations structurées pendant un prototype de hackathon de 48 heures. Elle ne prétend pas utiliser ce pipeline de données synthétiques. Le lien pertinent est la discipline consistant à comparer explicitement les comportements spécialisés plutôt qu'à traiter la fonction de perte du fine-tuning comme une métrique produit.

Évaluer la contribution de chaque tranche

Il faut conduire des comparaisons contrôlées :
  • référence sans données synthétiques ;
  • données réelles plus une tranche synthétique ;
  • accumulation des tranches dans un ordre documenté ;
  • différents poids d'échantillonnage ;
  • ablations des filtres ou stratégies de génération.
On mesure la qualité de la tâche, le comportement de sécurité, la calibration, la validité des sorties structurées et les régressions par segment. Les exemples qui modifient la prédiction dans un sens ou dans l'autre doivent être inspectés. Cette analyse révèle les catégories qui ajoutent du signal et celles qui créent des raccourcis. Le résultat peut montrer qu'un petit jeu soigneusement sélectionné est meilleur qu'un grand volume généré. Supprimer des données synthétiques peu utiles est une réussite du pipeline.

Déployer avec supervision et réversibilité

La démarche commence par un manque de couverture mesurable et un petit lot revu. Un modèle candidat est entraîné, comparé à la référence réelle et analysé avant d'augmenter la génération. Les données acceptées sont versionnées et le modèle précédent reste restaurable. En production, la supervision couvre les segments ciblés par les données synthétiques ainsi que les segments indépendants susceptibles de régresser. Les exemples réels corrigés sont collectés avec prudence, puis affectés à l'évaluation, à l'entraînement ou aux deux selon une politique de groupement contrôlée. Les données synthétiques deviennent utiles lorsqu'elles sont traitées comme des entrées logicielles versionnées, avec lignée et tests, pas comme du texte peu coûteux.

Sources et références

  1. Documentation NVIDIA NeMo CuratorComposants de curation et concepts de traitement à l'échelle
  2. Documentation Hugging Face DatasetsConstruction, transformation, versionnement et distribution des jeux de données
  3. Documentation Weights & Biases ReportsComparaison des expérimentations et reporting d'évaluation

Des principes aux systèmes livrés

Ces articles documentent mes méthodes de travail. Les études de cas montrent comment je les applique aux agents d'entreprise, au RAG et au MLOps.

Continuer l'exploration

Des notes complémentaires sur les choix d'architecture, d'évaluation et d'exploitation des systèmes IA en production.
11 avril 20265 min de lectureRAG multimodalIA documentaire

Playbook RAG multimodal : documents, images et tableaux

Un guide d'architecture orienté production pour analyser, indexer, retrouver, citer et évaluer du texte, des images et des tableaux dans un système RAG multimodal.