Comment les modèles sont entraînés (et pourquoi vous ne le ferez pas)

Chaque modèle de chat que vous pouvez télécharger a traversé le même pipeline en trois stades. Vous ne ferez presque certainement jamais le stade un — c'est le territoire des centres de données — mais vous pourriez exécuter des cousins bon marché des stades deux et trois. Connaître les stades explique le comportement base vs instruct, pourquoi les modèles hallucinent, et ce qu'est réellement un modèle « fusionné » sur Hugging Face.

Stade 1 : le pré-entraînement — la partie chère

Un seul objectif à une échelle inimaginable : prédire le jeton suivant à travers des milliers de milliards de jetons de texte web, de code et de livres. C'est ici que connaissances et compétences entrent dans les poids, et ici que va l'écrasante majorité du calcul.

Le produit est un modèle base : brillant en continuation, inutile comme assistant. Interrogé, il répond — puis continue avec une autre question, une liste, un saut de page, parce que c'est ce que fait le texte sur internet.

Stade 2 : le fine-tuning supervisé (SFT)

De dizaines de milliers à quelques millions de paires (instruction → réponse) curatées, quelques GPU-jours. Une erreur d'arrondi à côté du pré-entraînement, mais cela recâble le comportement : répondre à l'instruction, dans un format utile, puis s'arrêter. C'est le stade qui transforme un modèle base en quelque chose avec qui l'on peut discuter.

Stade 3 : le réglage des préférences

• RLHF : des humains classent des paires de réponses ; un modèle de récompense apprend le classement ; la politique est optimisée contre la récompense (PPO). La recette classique, une machinerie lourde.
• DPO : saute le modèle de récompense et optimise directement les paires de préférences. Plus simple, stable, le chouchou de l'open source.
• Effet : style, utilité, refus, affirmations mieux étalonnées. Aussi la servilité — le modèle apprend que les gens récompensent l'accord.

À quoi ressemblent réellement les données de SFT — du JSONL simple de paires instruction/réponse, rien d'exotique :

{"instruction": "Résume le changelog en trois puces.", "response": "- Ajoute ..."}
{"instruction": "답변을 존댓말로 작성하세요.", "response": "네, 알겠습니다 ..."}

Des milliers voire des millions de celles-ci, quelques époques, et le modèle base apprend le format d'assistant.

Mêmes poids, stades différents

prompt: "Écris un haïku sur les GPU."

base (après le stade 1) :
  "Écris un haïku sur les GPU.
   Écris un sonnet sur les CPU.
   1. Choisis ton sujet avec soin..."       ← continue le document

instruct (stades 1+2+3) :
  "Mille cœurs s'éveillent,
   chacun chassant un jeton discret —
   les ventilateurs retiennent leur souffle."   ← répond, met en forme, s'arrête

Le suffixe du dépôt vous dit le stade : nom nu = base ; -instruct / -it / -chat = réglé (voir paramètres).

Un élément de vocabulaire de plus : la date de coupure des connaissances — la date à laquelle le corpus de pré-entraînement a été collecté. Interrogez sur quoi que ce soit de postérieur et vous obtenez soit un honnête « je ne sais pas », soit, pire, de la fiction assurée ; les deux sont des comportements corrects pour des poids figés (qu'est-ce qu'un LLM).

Entraînement vs fine-tuning : environ 1000× d'écart

Le fine-tuning ajuste les curseurs ; il n'ajoute pas de connaissances. Apprendre à un 7B le ton de votre entreprise : LoRA, une soirée. Lui apprendre vos 50k documents internes : c'est de la récupération, pas de l'entraînement (RAG, fine-tuning).

Ce que le fine-tuning peut et ne peut pas faire, pour bien le viser :

• Peut : format de sortie, ton, terminologie, style de refus, syntaxe d'appel d'outils, une tâche étroite faite de façon fiable.
• Peut : distiller une tâche étroite d'un grand modèle vers un petit.
• Ne peut pas (de façon fiable) : ajouter des faits nouveaux, corriger un raisonnement faible, étendre les dates de coupure, transformer un petit modèle en grand.
• Règle : si le problème est « il ne sait pas », utilisez la récupération ; si c'est « il ne se comporte pas bien », faites du fine-tuning.

Checkpoints, fusions, et ce que vous téléchargez

• L'entraînement sauvegarde des checkpoints en route ; les livraisons sont habituellement les poids finaux du stade instruct — vous recevez l'assistant fini, pas le processus qui l'a construit.
• Une « fusion » (merge) moyenne ou interpole plusieurs fine-tunes du même modèle base (model soups). Aucun entraînement n'a lieu ; c'est de l'arithmétique de poids qui atterrit souvent entre ses parents. Populaire sur Hugging Face, bon marché, parfois excellent.
• Une lignée floue signifie une licence floue : les fusions héritent des conditions de chaque parent (poids ouverts vs API fermées).
• Les poids base derrière un modèle de chat sont parfois publiés aussi — ne les prenez que pour des charges de complétion ou comme substrat de fine-tuning.
• Pourquoi les livraisons ouvertes s'arrêtent au stade final : les données de pré-entraînement et les checkpoints intermédiaires sont les actifs concurrentiels coûteux ; les poids finis sont la démo.
• Les modèles instruct communautaires partagent recettes et jeux de données de post-entraînement, d'où l'impression d'interchangeabilité : même base, même schéma des stades 2/3.
• Préférez les livraisons dont la fiche modèle liste données et stades ; un checkpoint final documenté vieillit mieux qu'un checkpoint vanté.

Voir aussi : fine-tuning · RAG · poids ouverts vs API fermées · paramètres