L'art secret de bien préparer ses données pour l'IA : le guide ultime

POURQUOI LA PRÉPARATION DES DONNÉES EST LA CLÉ DE TOUT

Imaginez que vous avez construit la voiture de course la plus rapide du monde, mais que vous lui mettez des pneus de vélo. Peu importe la puissance du moteur, elle ne roulera jamais comme une vraie voiture de course. C'est exactement ce qui arrive avec l'apprentissage supervisé (supervised fine-tuning ou SFT en anglais).

Vous avez déjà évalué votre modèle de base (foundation model), et ses performances ne suffisent pas pour votre projet. Peut-être qu'il ne respecte pas votre schéma de sortie, qu'il confond les catégories de votre domaine, ou qu'il ne garde pas le ton adapté à votre application. La question n'est pas si vous devez personnaliser le modèle, mais comment le faire au mieux.

Ce guide part du principe que vous avez déjà décidé de personnaliser votre modèle et que vous cherchez à préparer vos données pour cette étape cruciale.

TROIS LEVIERS POUR PERSONNALISER VOTRE MODÈLE D'IA

Il existe trois méthodes principales pour adapter un modèle d'IA à vos besoins spécifiques. Chacune répond à un problème différent :

L'entraînement continu (Continued Pre-Training ou CPT) consiste à nourrir le modèle avec de gros volumes de textes non structurés dans votre domaine. Utilisez cette méthode quand le modèle ne connaît pas assez le vocabulaire, les concepts ou les schémas de données de votre secteur.

L'apprentissage supervisé (Supervised Fine-Tuning ou SFT) travaille avec des paires entrée-sortie soigneusement choisies pour modifier le comportement du modèle. Le SFT apprend au modèle à répondre comme vous le souhaitez : suivre des instructions, respecter des schémas, adopter un ton particulier ou produire des sorties structurées. Contrairement au CPT, cette méthode n'injecte pas de nouvelles connaissances, mais elle enseigne au modèle à utiliser ce qu'il sait déjà de la manière dont vous avez besoin. C'est ce qu'on appelle parfois l'hypothèse de l'alignement superficiel.

L'affinage par renforcement (Reinforcement Fine-Tuning ou RFT) optimise le comportement du modèle grâce à des signaux de récompense plutôt que par des démonstrations explicites. Cette méthode fonctionne quand vous pouvez évaluer la qualité des sorties de manière programmatique, mais que vous ne pouvez pas facilement montrer le cheminement de raisonnement à grande échelle.

Ces trois techniques ne sont pas exclusives. La séquence la plus courante en production est : CPT, puis SFT, puis RFT. D'abord, on élargit les connaissances du modèle, ensuite on façonne son comportement, et enfin on l'optimise grâce aux retours. En pratique, le CPT est moins utilisé et n'est nécessaire que quand le modèle de base manque de vocabulaire ou de connaissances critiques pour votre tâche.

POURQUOI CES MÉTHODES NE SONT PAS INTERCHANGEABLES

Prenons un exemple concret. Vous voulez créer un assistant qui aide à coder en Python. Votre modèle de base connaît déjà beaucoup de choses sur Python, mais il ne suit pas toujours les consignes de manière fiable. Dans ce cas :

Le CPT ne servirait à rien, car le modèle connaît déjà Python. Il a juste besoin d'apprendre à suivre vos instructions précises.

Le SFT est parfait pour cela : vous lui montrez des centaines d'exemples où il doit répondre à une question en Python en suivant un format strict.

Le RFT pourrait ensuite affiner encore le modèle en récompensant les réponses qui correspondent exactement à ce que vous attendez.

LA PRÉPARATION DES DONNÉES : LA PIERRE ANGULAIRE DE VOTRE PROJET

Ce premier article d'une série de deux se concentre sur les bases de la préparation des données pour le SFT : les contrôles de qualité, les exigences de formatage et la répartition entre ensembles d'entraînement et d'évaluation. Nous utilisons des extraits de code de la documentation d'Amazon Bedrock pour illustrer les concepts clés, mais les conseils restent applicables à n'importe quel modèle que vous choisissez.

Le deuxième article abordera des stratégies avancées : évaluation de la préparation des données, sélection et filtrage des sous-ensembles de données, augmentation des données et mélange de sources de données.

LA QUALITÉ PRIME SUR LA QUANTITÉ : UNE RÈGLE D'OR

Chaque réponse dans votre ensemble de données doit être un exemple parfait que vous seriez prêt à déployer en production. Des exemples incorrects peuvent enseigner au modèle de mauvaises habitudes difficiles à corriger ensuite. Ce risque est particulièrement élevé dans le SFT, où le modèle n'apprend pas de nouveaux faits, mais plutôt quels motifs imiter.

Une mauvaise démonstration sera imitée. Par conséquent, il vaut mieux avoir 100 exemples parfaits que 10 000 exemples médiocres. Des études comme LIMA ont montré que 1 000 exemples soigneusement sélectionnés peuvent donner des résultats comparables à des modèles entraînés sur des dizaines de milliers d'exemples. Une autre étude, AlpaGasus, a révélé que filtrer un ensemble d'instructions pour ne garder que les 20 % les plus propres permettait d'entraîner plus vite et d'obtenir de meilleurs scores que l'ensemble complet.

Si vos données sont annotées par des humains, mettez en place un processus de relecture multiple avant que les exemples n'entrent dans votre ensemble d'entraînement.

DIVERSITÉ ET COHÉRENCE : LES DEUX PILIERS D'UN BON ENSEMBLE DE DONNÉES

La diversité des données est l'un des meilleurs prédicteurs de succès pour le SFT. Des recherches sur l'évolutivité du SFT ont identifié deux propriétés qui déterminent la capacité du modèle à généraliser :

La couverture sémantique : la variété des domaines de tâches et des formulations de requêtes représentées. Par exemple, si votre modèle doit répondre à des questions sur la santé, il faut inclure des questions posées de différentes manières : « Quels sont les symptômes du diabète ? », « Comment reconnaître le diabète ? », « Quels signes doivent m'alerter pour le diabète ? ».

La profondeur d'information : la richesse des exemples individuels. Un exemple riche inclut non seulement la question et la réponse, mais aussi le raisonnement qui mène à cette réponse.

Un ensemble de données qui ne couvre qu'une petite partie de votre trafic réel produira un modèle qui performe bien sur cette partie, mais mal partout ailleurs.

COMMENT AUDITER VOTRE ENSEMBLE DE DONNÉES

Commencez par vérifier la variation des requêtes. Vos exemples doivent inclure les différentes façons dont les utilisateurs formulent la même intention. Un modèle entraîné uniquement sur « Résume ce document » ne saura pas gérer « Donne-moi les points clés ».

Ensuite, vérifiez la couverture des domaines et des sujets. Si votre tâche couvre plusieurs domaines, assurez-vous que chacun est représenté proportionnellement à sa fréquence dans la production. Par exemple, si 30 % de vos requêtes concernent la facturation, 40 % le support technique et 30 % les commandes, votre ensemble de données doit refléter ces proportions.

Examinez enfin la gamme de difficultés. Incluez des cas simples à côté de problèmes complexes et multi-étapes, en privilégiant la complexité réelle de votre trafic. Enfin, incluez explicitement des cas limites : entrées ambiguës, informations incomplètes et requêtes hors sujet, accompagnés des réponses que vous souhaitez que le modèle produise dans ces situations.

Une méthode pratique consiste à regrouper vos exemples par similarité d'embeddings et à inspecter les groupes résultants pour repérer les lacunes. Des groupes clairsemés ou manquants indiquent des zones où le modèle manquera de signaux d'entraînement. Par exemple, un ensemble de données de support client pourrait se diviser en groupes comme « réinitialisation de mot de passe », « questions de facturation » et « mises à jour de livraison ». Si les remboursements sont une demande fréquente en production mais qu'aucun groupe ne les couvre, cette zone vide représente votre lacune. Le modèle aura peu de signaux pour les conversations sur les remboursements, donc il faudra collecter ou rédiger des exemples sur ce sujet avant l'entraînement.

LA COHÉRENCE INTERNE : ÉVITER LES SIGNAUX CONTRADICTOIRES

Bien que la diversité soit cruciale, les exemples qui traitent du même type de situation doivent être cohérents entre eux. Des incohérences au sein d'un même type de tâche envoient des signaux contradictoires sur le bon comportement à adopter. Par exemple :

• Si des requêtes similaires reçoivent des réponses sous forme de liste à puces et d'autres sous forme de paragraphe, le modèle n'apprendra pas à adopter une structure de réponse fiable.
• Si vous avez besoin de réponses courtes de deux phrases, n'incluez pas de réponses de plusieurs paragraphes dans vos données d'entraînement.

Voici quelques exemples concrets de réponses incohérentes à éviter :

"Le client signale qu'il ne parvient pas à se connecter après avoir réinitialisé son mot de passe sur iOS 17. Le ticket est transmis au niveau 2."

Le client ne peut pas se connecter après avoir réinitialisé son mot de passe sur iOS 17.

Le ticket est transmis au niveau 2.

Ces deux réponses traitent de la même situation, mais avec des formats différents. Le modèle aura du mal à choisir le bon format pour sa réponse.

DUPLICATAS ET SURPOIDS : LE PIÈGE À ÉVITER

Les doublons ou les exemples presque identiques poussent le modèle à sur-apprendre ces motifs, ce qui gonfle leur importance par rapport au reste de l'ensemble de données. La duplication est moins critique dans le SFT que dans le pré-entraînement, mais elle peut s'infiltrer lorsque vous fusionnez des données de plusieurs annotateurs, combinez des ensembles de données de différents projets ou utilisez la Génération de données synthétiques. Dans ces cas, appliquez une déduplication exacte et sémantique avant l'entraînement.

CONTENU NOCIF OU BIASÉ : UN RISQUE À NE PAS SOUS-ESTIMER

Même si votre cas d'usage est étroit, le modèle peut internaliser des motifs problématiques à partir d'exemples inappropriés et les ressortir dans des contextes inattendus. Utilisez des classificateurs automatisés, comme Llama Guard, pour repérer le contenu problématique et le soumettre à une relecture humaine. Établissez des directives claires sur ce qui constitue des données d'entraînement acceptables dans votre domaine.

FORMATAGE : PLUS QU'UNE QUESTION DE SYNTAXE

Le formatage de vos données n'est pas qu'une question de syntaxe. La façon dont vous structurez vos exemples façonne le comportement appris par le modèle, car le SFT enseigne au modèle à répondre à une forme d'entrée spécifique, pas seulement à son contenu.

Incluez un message système dans vos exemples d'entraînement si vous prévoyez d'en utiliser un lors de l'inférence. Le message système établit le contexte, la persona et les contraintes qui façonnent le comportement du modèle. Si vos données d'entraînement n'incluent pas de messages système mais que vous en utilisez lors de l'inférence, vous créez un décalage de distribution qui peut dégrader les performances du modèle.

LE FORMAT JSONL CONVERSATIONNEL : LA NORME MODERNE

La plupart des pipelines SFT modernes, y compris les recettes Amazon Nova, utilisent un format JSONL conversationnel où chaque ligne est un objet JSON autonome représentant une conversation. Les modèles Amazon Nova 2.0 utilisent le format de l'API Converse :

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{"text": "You are a helpful coding assistant."}],
  "messages": [
    {
      "role": "user",
      "content": [{"text": "Write a Python function to check if a string is a palindrome."}]
    },
    {
      "role": "assistant",
      "content": [
        {
          "text": "def is_palindrome(s):\n    cleaned = s.lower().replace(' ', '')\n    return cleaned == cleaned[::-1]"
        }
      ]
    }
  ]
}

LES RÈGLES DE FORMATAGE À RESPECTER

Pour les modèles capables de raisonnement (comme Amazon Nova 2.0 avec reasoning_enabled: true), incluez les étapes intermédiaires de réflexion en utilisant le champ reasoningContent dans les tours de l'assistant. L'entraînement sur ces traces de raisonnement permet de transférer le comportement popularisé sous le nom de chain-of-thought (raisonnement étape par étape) d'une astuce de prompting à une capacité intégrée du modèle.

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{"text": "You are a financial analyst. Provide data-driven answers with supporting calculations."}],
  "messages": [
    {
      "role": "user",
      "content": [{"text": "Calculate YoY revenue growth. 2024: $4.2M, 2025: $5.1M"}]
    },
    {
      "role": "assistant",
      "content": [
        {
          "reasoningContent": {
            "reasoningText": {
              "text": "The user asks for year-over-year revenue growth. I need to calculate the percentage change: (new - old) / old x 100. That gives (5.1 - 4.2) / 4.2 x 100 = 21.43%."
            }
          }
        },
        {"text": "YoY revenue growth is approximately 21.4 percent: ($5.1M - $4.2M) / $4.2M x 100."}
      ]
    }
  ]
}

Les traces utiles doivent être :

• Fidèles à la réponse : le raisonnement doit effectivement mener à la réponse finale.
• Proportionnelles à la difficulté : les problèmes simples reçoivent des traces courtes, les problèmes complexes reçoivent des traces longues. Ce compromis est explicitement géré par la compression des traces sensible à la difficulté.
• Complètes : elles ne doivent pas sauter d'étapes intermédiaires que le modèle n'a pas encore apprises. Les justifications écrites par des experts omettent souvent des étapes que le modèle n'a pas encore assimilées.

La qualité prime sur la quantité : des études comme s1 et LIMO ont montré que moins de 1 000 démonstrations de raisonnement soigneusement sélectionnées peuvent déclencher un raisonnement solide dans un modèle de base capable. Le deuxième article de cette série explique comment obtenir ces traces à grande échelle grâce à la distillation et à l'auto-génération.

Utilisez du texte brut pour le contenu de raisonnement et gardez-le directement pertinent pour le processus de résolution de problèmes. Quand le raisonnement est activé pendant l'entraînement, il doit aussi l'être pendant l'inférence pour un comportement cohérent. Gardez à l'esprit que l'entraînement sur un ensemble de données sans raisonnement avec reasoning_enabled: true peut faire perdre au modèle ses capacités de raisonnement, car il apprend à générer des réponses sans appliquer de raisonnement.

L'APPEL D'OUTILS ET LES DONNÉES MULTIMODALES : ALLER PLUS LOIN

Le SFT permet d'entraîner des modèles pour l'appel d'outils (function calling) et la compréhension multimodale (documents, images, vidéo). Pour l'appel d'outils, les blocs toolUse apparaissent dans les tours de l'assistant et les blocs toolResult dans les tours de l'utilisateur, chacun faisant référence à un toolUseId unique :

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{"text": "You are an expert in composing function calls."}],
  "toolConfig": {
    "tools": [
      {
        "toolSpec": {
          "name": "getItemCost",
          "description": "Retrieve the cost of an item from the catalog",
          "inputSchema": {
            "json": {
              "type": "object",
              "properties": {
                "item_id": {
                  "type": "string",
                  "description": "The ASIN of item to retrieve cost for"
                }
              },
              "required": ["item_id"]
            }
          }
        }
      }
    ]
  },
  "messages": [
    {
      "role": "user",
      "content": [{"text": "How much does item id-456 cost?"}]
    },
    {
      "role": "assistant",
      "content": [
        {
          "toolUse": {
            "toolUseId": "getItemCost_0",
            "name": "getItemCost",
            "input": {"item_id": "id-456"}
          }
        }
      ]
    },
    {
      "role": "user",
      "content": [
        {
          "toolResult": {
            "toolUseId": "getItemCost_0",
            "content": [
              {"text": "{"name": "getItemCost", "results": {"cost": "$29.99"}}"}
            ]
          }
        }
      ]
    },
    {
      "role": "assistant",
      "content": [
        {"text": "Item id-456 costs $29.99."}
      ]
    }
  ]
}

LES CONTRAINTES POUR LES DONNÉES D'APPEL D'OUTILS

Pour les données multimodales, les blocs de contenu de document et d'image apparaissent dans les tours de l'utilisateur aux côtés du texte, avec des sources faisant référence à des emplacements Amazon Simple Storage Service (Amazon S3) :

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{"text": "You are a document analysis assistant."}],
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "document": {
            "format": "pdf",
            "name": "quarterly_report",
            "source": {"s3Location": {"uri": "s3:///report.pdf"}}
          }
        },
        {"text": "Summarize the key findings from this quarterly report."}
      ]
    },
    {
      "role": "assistant",
      "content": [
        {"text": "The quarterly report highlights three key findings."}
      ]
    }
  ]
}

RESTEZ FIDÈLE AU TEMPLATE DE CHAT DU MODÈLE

Chaque modèle de base est post-entraîné avec un template de chat spécifique : les séquences exactes de tokens qui délimitent les tours système, utilisateur et assistant. Vos données d'entraînement doivent correspondre exactement à ce template. Même une petite déviation force le modèle à apprendre un nouveau format d'entrée en plus du nouveau comportement, ce qui divise son budget d'apprentissage entre deux objectifs. Dans le pire des cas, un décalage de template fait ignorer au modèle son message système ou produit des sorties malformées lors de l'inférence.

LA RÉPARTITION ENTRE ENSEMBLES D'ENTRAÎNEMENT ET D'ÉVALUATION : UNE ÉTAPE INDISPENSABLE

Réservez 10 à 20 % de vos données comme ensemble d'évaluation. Ce n'est pas une option. Sans cet ensemble, vous ne pourrez pas distinguer un apprentissage réel du sur-apprentissage. L'ensemble d'évaluation doit être représentatif de votre distribution de production, pas une tranche aléatoire qui pourrait sous-représenter des catégories rares mais importantes.

Pour les petits ensembles de données (moins de 1 000 échantillons), utilisez une répartition stratifiée pour que chaque catégorie de tâche apparaisse dans les ensembles d'entraînement et d'évaluation. Pour les ensembles plus grands, une répartition aléatoire suffit généralement, mais vérifiez la distribution après coup.

Avant l'entraînement, établissez une performance de référence sur votre ensemble d'évaluation en utilisant le modèle non modifié. Cela vous donne une cible concrète à battre et vous aide à quantifier la valeur du SFT.

INVESTISSEZ DANS LA PRÉPARATION : LE TEMPS QUE VOUS Y CONSACREZ PAYERA

La préparation des données est l'activité la plus impactante dans tout workflow SFT. Les principes abordés ici — contrôles de qualité systématiques, formatage conforme aux schémas et répartition représentative entre ensembles d'entraînement et d'évaluation — s'appliquent que vous affiniez un modèle pour une tâche de classification étroite ou un système de dialogue multi-tours complexe.

Prenez le temps de bien préparer vos données en amont, et vos jobs d'entraînement convergeront plus vite, généraliseront mieux et éviteront le cycle coûteux de débogage des comportements du modèle qui remontent à des problèmes de données.

QUELLE EST LA PROCHAINE ÉTAPE ?

Dans le deuxième article de cette série, nous aborderons le côté avancé de la préparation des données pour le SFT : évaluer la préparation des données avec des courbes d'apprentissage, sélectionner des sous-ensembles de haute valeur, augmenter vos données et mélanger les sources de données pour éviter l'oubli catastrophique.

Pour commencer, consultez la console Amazon Bedrock pour explorer les options de personnalisation des modèles. Découvrez plus sur Amazon Nova sur la page de détails du service, consultez la documentation Amazon Nova pour les guides de personnalisation, et explorez le dépôt Amazon SageMaker HyperPod pour des configurations d'entraînement prêtes à l'emploi.

POUR ALLER PLUS LOIN

Lisez l'article « Personnaliser les modèles Amazon Nova avec l'affinage Amazon Bedrock » sur le blog AWS Machine Learning.