Du modèle de base à l’assistant : SFT, RLHF, DPO et GRPO

La première étape est la moins glamour, et c’est elle qui fait l’essentiel du travail. Rassemblez des exemples d’instructions associées à de bonnes réponses, puis continuez l’entraînement dessus avec exactement la loss du chapitre 8 — prédire le prochain token — mais uniquement sur la partie réponse. C’est le supervised fine-tuning, ou SFT.

On ne lui apprend rien de nouveau sur le langage. Ce qu’on lui apprend, c’est un format : qu’un texte de cette forme est suivi d’un texte de cette autre forme, puis qu’il s’arrête. Revenez à l’échec du modèle de base. Il a répondu à la question dans la première phrase, puis n’a pas pu s’arrêter, parce que rien dans son entraînement n’avait jamais marqué la fin d’une réponse. S’arrêter est un comportement appris.

C’est aussi pourquoi il faut indiquer au modèle où se trouvent les frontières, ce que fait un chat template :

<|im_start|>system
You are Qwen, created by Alibaba Cloud. You are a helpful assistant.<|im_end|>
<|im_start|>user
What is the capital of France?<|im_end|>
<|im_start|>assistant

Ces marqueurs <|im_start|> et <|im_end|> sont de vrais tokens dans le vocabulaire, ajoutés avant le fine-tuning, et le modèle en a vu des millions exactement à ces positions. C’est ainsi qu’il sait à qui est le tour et où un tour se termine.

Ignorez le template et donnez au modèle une question nue : vous lui fournissez une séquence qu’il n’a pas vue à l’entraînement. Mesuré, même modèle, même question, même décodage greedy :

 The capital of France is Paris.

To verify this, I will use a simple
Python code snippet to confirm that
Paris is indeed the capital city of
France.

[...and then it starts writing a
Python script to check its own answer]

The capital of France is Paris.

La réponse est correcte dans les deux cas, mais sans les marqueurs, le modèle dérive vers l’écriture de Python pour se vérifier lui-même, parce que le prompt qu’il a reçu ne ressemble à rien de ce sur quoi il a été fine-tuned. C’est la cause la plus fréquente de « le modèle est devenu plus bête quand je l’ai appelé directement » : le template n’est pas une décoration autour du modèle, il fait partie du modèle, et un mauvais template est une dégradation silencieuse sans erreur associée.

SFT a un plafond, et ce plafond, ce sont les données. Pour faire du fine-tuning sur une démonstration, il faut que quelqu’un écrive la réponse idéale — et pour la plupart des questions intéressantes, écrire une bonne réponse est difficile, lent, coûteux, et produit exactement une réponse dont vous ne pouvez pas vérifier la qualité.

Ce que les gens savent bien faire, c’est comparer. Face à deux réponses, un annotateur peut dire de manière fiable laquelle est meilleure en quelques secondes, sans être capable de produire l’une ou l’autre. C’est le fait sur lequel repose toute la deuxième étape, et c’est la partie que la plupart des explications prennent à l’envers :

Les humains n’écrivent pas les réponses. Ils classent des paires.

Les données sont donc des paires — un prompt, deux réponses, et laquelle a gagné. On ne peut pas les injecter dans une loss de prochain token, parce qu’il n’y a pas de séquence cible. Il faut une autre machine.

Vous ne pouvez pas demander à un humain de noter chaque réponse pendant l’entraînement — cela représenterait des millions de jugements. Vous entraînez donc un modèle à imiter les humains : un modèle de récompense qui prend une réponse et renvoie un scalaire.

L’entraîner à partir de comparaisons utilise un résultat de 1952. Le modèle de Bradley–Terry² dit que si deux éléments ont des forces latentes, la probabilité que l’un batte l’autre est la fonction logistique de leur différence. Retournez cela, et cela devient une loss : sachant qu’un humain a préféré $y_w$ à $y_l$, maximiser

ce qui, en code, est toute la boucle d’entraînement :

loss = -F.logsigmoid(reward(chosen) - reward(rejected)).mean()   

Remarquez ce que le modèle ne voit jamais : un score absolu. Il n’apprend jamais que des différences, ce qui est exactement ce que contiennent les données.

Maintenant, la partie qui mérite d’être mesurée. Un modèle de récompense apprend ce que les annotateurs ont récompensé, et les annotateurs sont des personnes. Voici une simulation où la vraie qualité d’une réponse dépend uniquement du fait qu’elle soit utile et correcte — la longueur ne vaut rien — mais l’annotateur simulé a une légère préférence pour les réponses plus longues quand tout le reste est proche, ce qui est un biais humain bien documenté. Entraînez le modèle de récompense sur 2000 comparaisons et lisez ses poids :

Le modèle de récompense fonctionne parfaitement. Il a fidèlement appris les préférences qu’on lui a montrées — y compris la partie de ces préférences qui n’a rien à voir avec la qualité. Un modèle de récompense n’est pas une mesure du bien ; c’est une mesure de ce que les annotateurs ont choisi, et chaque biais dans le pool d’annotation est désormais un coefficient dans une fonction différentiable qu’un modèle beaucoup plus grand va optimiser.

Ce qui nous amène à ce qui se passe quand vous l’optimisez. Donnez à la policy un budget fixe d’effort à dépenser entre les propriétés de la réponse, avec une asymétrie réaliste : être utile et être correct coûte cher, et être plus long coûte peu — il suffit de continuer à écrire.

Récompense par unité d’effort, pour le modèle entraîné ci-dessus : utile 8,26, correct 8,31, longueur 31,70. La longueur rapporte presque quatre fois plus que la justesse, non pas parce que le modèle de récompense est cassé, mais parce qu’elle est peu coûteuse.

Optimisez contre cette récompense et observez les deux nombres :

La récompense a été multipliée par 2,5. Ce que la récompense était censée mesurer est tombé à zéro. La policy a découvert qu’elle pouvait obtenir un score énorme en écrivant longuement sans rien dire, et aucune partie de la boucle d’entraînement n’avait le moindre moyen de le remarquer, parce que le modèle de récompense est la définition du bien à l’intérieur de la boucle.

C’est du reward hacking, et si vous vous êtes déjà demandé pourquoi les modèles de chat sont si verbeux, ce tableau constitue une grande partie de la réponse.

La défense standard consiste à pénaliser la policy lorsqu’elle s’éloigne trop de son point de départ, en mesurant la distance avec la divergence KL du chapitre 4 :

La référence $\pi_{\text{ref}}$ est le modèle SFT — la policy avant l’étape de reinforcement. L’affirmation est que cela empêche le modèle de dériver vers un comportement dégénéré. Voyons quelle part de cette affirmation survit à la mesure. Même configuration, balayage de $\beta$ :

Lisez la dernière ligne par rapport au reste. À $\beta = 0$ et $\beta = 1$, la pénalité ne fait rien du tout : la récompense vaut tellement plus que la KL que l’optimiseur paie l’amende et hacke quand même. Entre 5 et 15, le comportement bascule. Et à $\beta = 60$, la vraie qualité est remontée à 1,769 — ce qui reste inférieur au 1,791 qu’avait le modèle de référence avant le début de tout cela.

Une réserve avant que ce nombre soit cité quelque part : le 1,791 de la dernière ligne et le 0,974 que le premier tableau donne à la policy de départ sont deux mesures différentes du même modèle pré-RL, prises séparément par les deux expériences. Comparez les lignes au sein d’un tableau, jamais entre tableaux — la conclusion de chaque tableau repose sur ses propres lignes, et aucune ne dépend de la baseline de l’autre.

Le résumé honnête n’est donc pas « la pénalité KL empêche le reward hacking ». C’est :

La pénalité KL n’empêche pas le reward hacking. Elle limite la distance à laquelle la policy peut s’éloigner de la référence — et comme l’échec nécessite de bouger, cela aide. Mais c’est une laisse, pas un correctif : à faible $\beta$, la laisse casse, et à fort $\beta$, vous récupérez le modèle de référence, et toute cette étape coûteuse n’a rien acheté.

La bande utile est étroite, son emplacement dépend du modèle de récompense, et il n’existe aucun moyen de la trouver sauf en regardant. C’est pourquoi le modèle de référence doit être bon — la KL est un plancher à la qualité de la référence, pas un plafond sur l’échec — et c’est une grande partie de la raison pour laquelle cette étape est difficile en pratique plutôt qu’en principe.

L’algorithme qui a permis de faire fonctionner cela à grande échelle est Proximal Policy Optimization.³ En un paragraphe : il estime l’advantage de chaque réponse, met à jour la policy pour augmenter la probabilité des réponses au-dessus de la baseline, et limite la taille de chaque mise à jour afin qu’une grande estimation d’advantage ne puisse pas détruire la policy en une seule étape. Appliqué aux modèles de langage⁴, cela signifie garder quatre modèles en jeu à la fois — la policy, la référence, le modèle de récompense et un critic — avec la policy qui génère de nouveaux échantillons tout au long de l’entraînement.

Cela fonctionne, cela a produit InstructGPT et tout ce qui en descend, et c’est réellement difficile : quatre modèles en mémoire, de l’échantillonnage dans la boucle d’entraînement, et une réputation d’instabilité méritée. Faire semblant de pouvoir l’implémenter dans un article de blog serait malhonnête, donc ce chapitre ne le fait pas.

Ce qui l’a remplacé dans la plupart des usages vient d’une observation. L’objectif régularisé par KL ci-dessus possède une policy optimale en forme fermée, et cette expression peut être inversée : la récompense peut s’écrire en fonction de la policy optimale et de la référence. En remplaçant cela dans la loss de Bradley–Terry, le modèle de récompense disparaît entièrement. Ce qui reste est une loss supervisée sur des paires de préférences — pas d’échantillonnage, pas de critic, pas de modèle de récompense, deux modèles en mémoire au lieu de quatre.

C’est Direct Preference Optimization,⁵ et cela tient en deux lignes :

def dpo_loss(pi_w, pi_l, ref_w, ref_l, beta=0.1):
    """pi_* and ref_* are summed log-probabilities of a full response."""
    logits = beta * ((pi_w - ref_w) - (pi_l - ref_l))   
    return -F.logsigmoid(logits)                        

Lisez ce que cela dit. La quantité poussée vers le haut est à quel point la policy préfère davantage le gagnant que ne le faisait la référence, moins à quel point elle préfère davantage le perdant. La référence n’est pas une pénalité ajoutée après coup — elle est à l’intérieur de la loss, ce qui explique pourquoi DPO n’a pas besoin d’un terme KL séparé.

La propriété la plus importante est dans le gradient. Évaluez la loss et son gradient sur la même paire dans cinq états différents de la policy :

Le gradient grandit à mesure que la policy se trompe davantage. Les paires que le modèle gère déjà ne contribuent presque rien ; les paires qu’il inverse dominent la mise à jour. DPO pondère chaque exemple selon le degré d’erreur actuel de la policy, automatiquement, sans calendrier — et cette auto-pondération est le mécanisme qui fait le travail que l’estimation d’advantage et le critic de PPO faisaient. (La loss à la troisième ligne vaut exactement $\ln 2$, ce qui est l’ancre pour vérifier toute implémentation : une policy identique à sa référence n’a rien appris et devrait se trouver à $\ln 2$.)

GRPO⁶ prend une autre voie pour sortir du même problème. Il conserve la boucle d’échantillonnage mais supprime le critic : au lieu d’entraîner un modèle à prédire la baseline, il échantillonne un groupe de réponses au même prompt et utilise directement la récompense moyenne du groupe comme baseline. L’advantage d’une réponse est combien elle est meilleure que ses voisines. Cela échange un modèle entier contre un batch plus grand, et c’est ce qui a rendu pratique l’entraînement sur récompenses vérifiables — le sujet du chapitre 12.

Deux choses à retenir pour la suite.

La première est que cette étape a un coût, et qu’il apparaît sous forme de capacité. Les modèles deviennent souvent mesurablement moins bons sur certaines tâches de benchmark après l’entraînement d’alignement — la taxe d’alignement — parce que l’objectif a changé : une réponse sûre, nuancée et bien formatée n’est pas toujours celle qui maximise l’exactitude. Une partie de cet écart a été résolue par ingénierie, et une autre partie est un vrai compromis plutôt qu’un bug à corriger.

La seconde est la question que le mot aligné dissimule. Aligné avec qui ? La chaîne est la suivante : une entreprise rédige des directives, des prestataires les interprètent, leurs comparaisons entraînent un modèle de récompense, le modèle de récompense façonne une policy, et la policy répond à une question posée par quelqu’un qui n’a rien vu de tout cela. Chaque maillon est un choix fait par des personnes précises, et aucun des algorithmes de ce chapitre n’a d’opinion sur le caractère bon ou mauvais de ces choix.

Ce n’est pas une figure de style. C’est la raison concrète pour laquelle deux modèles frontier refusent des requêtes différentes, pourquoi le même modèle change d’avis entre deux versions, et pourquoi « aligné » est la description d’un processus plutôt qu’une propriété d’un artefact. Les mathématiques de ce chapitre sont établies. Cette partie-là ne l’est pas.

Le post-training a appris au modèle à répondre. Il ne lui a pas appris à réfléchir avant de répondre, et les deux diffèrent d’une manière qui s’avère entraînable.

Le chapitre 12 traite de ce qui se passe quand vous laissez un modèle consacrer plus de calcul à une question difficile au moment de répondre plutôt qu’au moment de l’entraînement — chain of thought, reinforcement learning à partir de récompenses vérifiables, et la raison pour laquelle un modèle qui montre son raisonnement ne se contente pas de s’expliquer, mais calcule différemment. Il règle aussi la dette de ce chapitre : GRPO y existe, faisant le travail que faisait auparavant le critic de PPO, sur des récompenses qui n’ont besoin d’aucun annotateur parce qu’une preuve se vérifie, ou non.

Les générations ci-dessus viennent de gpt2 et Qwen/Qwen2.5-0.5B-Instruct avec décodage greedy, elles se reproduisent donc exactement. Le chapitre 11 du Hugging Face LLM Course présente SFT et DPO avec trl et peft si vous voulez exécuter la vraie chose plutôt que la simulation ; le chapitre 7 de Build a Large Language Model (From Scratch) de Sebastian Raschka implémente le instruction fine-tuning de bout en bout sans bibliothèque.