Leçon 2 — Les trois étapes de l'entraînement
Un modèle utilisable n'est pas produit en une fois. Trois étapes successives le fabriquent, et chacune explique une partie de son comportement. Savoir laquelle explique quoi est très utile pour diagnostiquer un problème.
Étape 1 — Le pré-entraînement
Ce qui se passe : le modèle apprend à prédire le token suivant sur un corpus gigantesque — pages web filtrées, livres, articles scientifiques, code source, documentation. Les volumes se comptent en milliers de milliards de tokens.
Ce que cela coûte : c'est l'essentiel de la dépense, souvent plus de 99 % du calcul total. Pour un grand modèle, plusieurs milliers de cartes graphiques mobilisées pendant des semaines à des mois, pour un budget qui se compte en dizaines de millions d'euros. Une poignée d'organisations dans le monde peut se le permettre.
Ce qui en sort : un modèle de base, ou modèle de fondation. Il est étonnant et inutilisable tel quel.
Inutilisable pourquoi ? Parce qu'il fait exactement ce qu'on lui a appris : continuer du texte. Posez-lui une question, il ne répond pas — il produit d'autres questions du même genre, parce que dans son corpus, une question est souvent suivie d'autres questions.
C'est un point important et rarement compris : le comportement « assistant qui répond » n'est pas le produit du pré-entraînement.
Le filtrage du corpus compte énormément, et c'est l'un des principaux facteurs de différenciation entre modèles de taille comparable. Déduplication, retrait des contenus de faible qualité, équilibrage entre domaines, proportion de code — le code améliore mesurablement les capacités de raisonnement, même sur des tâches non informatiques. Les recettes précises sont l'un des secrets les mieux gardés du secteur.
Étape 2 — Le réglage par instructions
Ce qui se passe : on poursuit l'entraînement sur un jeu bien plus petit — quelques dizaines de milliers d'exemples — mais soigneusement construit. Chaque exemple est une paire demande-réponse de qualité : une consigne, et la réponse qu'un bon assistant aurait produite.
Ce que cela change : le modèle apprend le format de l'échange. Il comprend qu'une question attend une réponse, qu'une consigne attend une exécution, qu'une demande de résumé attend un résumé. Il apprend aussi à suivre des contraintes de forme.
Ce que cela coûte : très peu, comparé au pré-entraînement — quelques milliers d'euros de calcul. En revanche, la constitution du jeu de données est coûteuse en travail humain qualifié, et c'est là que se joue la qualité.
C'est l'étape qui a transformé une curiosité de laboratoire en produit grand public. Le modèle de base existait depuis longtemps ; le réglage par instructions l'a rendu utilisable par tout le monde.
Étape 3 — L'alignement sur préférences
Ce qui se passe : on ne dispose plus d'une « bonne réponse » unique, parce que sur beaucoup de demandes il n'y en a pas. On procède donc par comparaison. Des annotateurs voient deux réponses et disent laquelle ils préfèrent.
La méthode historique, RLHF — apprentissage par renforcement à partir de retours humains —, entraîne d'abord un modèle de récompense à prédire ces préférences, puis optimise le modèle de langue contre cette récompense. Des méthodes plus récentes comme DPO obtiennent un résultat comparable en optimisant directement sur les paires de préférences, sans passer par le renforcement, ce qui est bien plus simple et stable.
Ce que cela change : le ton, la structure des réponses, la prudence sur les sujets sensibles, le refus de certaines demandes, la tendance à nuancer.
Ce que cela coûte : l'annotation de préférences est lente et demande des annotateurs formés. C'est un poste significatif.
L'alignement dégrade parfois les performances brutes. Un modèle fortement aligné devient prudent, ajoute des mises en garde, refuse des demandes légitimes qui ressemblent superficiellement à des demandes problématiques. C'est la taxe d'alignement, et c'est l'une des raisons pour lesquelles certains praticiens préfèrent des modèles moins alignés pour des usages techniques encadrés.
Où se situe ce que vous pouvez faire
Les trois étapes ci-dessus sont hors de portée d'une organisation ordinaire. Ce qui est accessible, en revanche, est le fine-tuning d'un modèle déjà entraîné.
Le fine-tuning complet réajuste tous les paramètres. Il demande beaucoup de mémoire et de calcul, et reste réservé aux cas où l'écart avec le comportement souhaité est important.
Le fine-tuning à paramètres efficaces, dont LoRA est la méthode dominante, n'entraîne que de petites matrices additionnelles insérées dans le modèle. Les avantages sont décisifs : cela tourne sur une seule carte graphique, produit un fichier de quelques dizaines de mégaoctets, s'entraîne en quelques heures, et permet de conserver plusieurs adaptateurs pour un même modèle de base.
Ce dont vous avez besoin : entre quelques centaines et quelques milliers d'exemples de qualité. La qualité domine largement la quantité — mille exemples cohérents battent dix mille exemples approximatifs.
Ce que le fine-tuning apporte réellement : un format de sortie stable, un ton propre à votre organisation, une terminologie métier, une tâche répétitive exécutée de façon fiable, et une réduction de la longueur des consignes puisque le comportement est intégré.
Ce que le fine-tuning n'apporte pas : de la connaissance factuelle fiable. C'est l'erreur la plus répandue. Affiner un modèle sur votre documentation ne le rend pas capable de répondre exactement sur son contenu : il apprend le style de votre documentation, pas ses faits. Pour la connaissance, il faut le RAG, objet de la leçon 3.
Un affinage trop agressif — taux d'apprentissage trop élevé, trop d'époques sur un petit jeu — détruit les capacités générales du modèle. Il devient bon sur vos exemples et mauvais partout ailleurs. Gardez toujours un jeu d'évaluation de tâches générales pour détecter cette dégradation, qui ne se voit pas sur vos propres métriques.
Le tableau récapitulatif
| Pré-entraînement | Instructions | Alignement | Votre fine-tuning | |
|---|---|---|---|---|
| Objectif | prédire le token suivant | répondre à une demande | correspondre aux préférences | comportement spécifique |
| Volume de données | milliers de milliards de tokens | dizaines de milliers d'exemples | dizaines de milliers de comparaisons | centaines à milliers d'exemples |
| Part du coût total | plus de 99 % | faible | faible | négligeable |
| Accessible à vous | non | non | non | oui |
| Ce que cela produit | modèle de base | assistant | assistant policé | assistant spécialisé |
Et la distillation
Un dernier procédé mérite une mention, parce qu'il explique l'existence de nombreux modèles ouverts performants.
La distillation consiste à entraîner un petit modèle à imiter les sorties d'un grand. Le petit modèle apprend non seulement les réponses mais la façon dont le grand modèle répartit ses probabilités, ce qui transmet plus d'information qu'un simple exemple.
Le résultat est souvent remarquable : un modèle dix fois plus petit conserve une grande partie des capacités du modèle enseignant sur un périmètre donné. C'est ce qui rend possible d'exécuter localement des modèles très corrects.
Sa limite : le modèle distillé hérite aussi des erreurs de son enseignant, et il ne peut pas le dépasser.
À retenir
- Trois étapes : pré-entraînement (plus de 99 % du coût), réglage par instructions, alignement sur préférences.
- Le pré-entraînement produit un modèle qui continue du texte, pas un assistant : le comportement conversationnel vient de l'étape 2.
- L'alignement donne le ton et la prudence, au prix d'une possible dégradation des performances brutes.
- Ce qui vous est accessible est le fine-tuning, et LoRA le rend faisable sur une seule carte graphique.
- Le fine-tuning apporte du comportement, pas de la connaissance factuelle : c'est l'erreur la plus fréquente.
- Un affinage trop agressif provoque un oubli catastrophique ; gardez une évaluation générale.
- La distillation explique la qualité des petits modèles ouverts, et transmet aussi leurs erreurs.
Leçon suivante — Le RAG : ancrer les réponses dans vos documents →