Appendice · RLHF et DPO

Le chapitre 17 enseigne la forme du chat via SFT. Le chapitre 21 livre un assistant spécialisé. Aucun n’apprend au modèle ce que les humains préfèrent entre deux réponses également bien formées.

Ce troisième axe — preference tuning — est ce qui sépare « suit le template » de « la réponse que tes utilisateurs auraient choisie ». Cet appendice est conceptuel, pas hands-on. Le vrai preference tuning demande des données de préférence qu’on n’a pas et une infra qui dépasse le scope. Mais le mécanisme est petit une fois qu’on a fait le SFT, et le nommer permet de lire la littérature LLM moderne sans surprise.

1. Le setup

Après le SFT, ton modèle produit des réponses plausibles. Plausible est nécessaire, pas suffisant. Pour « explique le tri à bulles », deux réponses peuvent suivre la même forme :

• A : « Le tri à bulles parcourt la liste, compare les éléments adjacents, les échange si besoin. Complexité O(n²). »
• B : « Voici comment ça marche c’est un algo de tri qui trie en échangeant les trucs. »

Les deux respectent le template SFT. A est ce qu’un humain attentif préfère. Le SFT ne sait pas exprimer « préfère A à B » — il ne fait que de l’imitation.

Le preference learning comble ce trou :

1. Collecter des paires de préférence : un humain note A vs B sur le même prompt.
2. Entraîner un modèle — ou une loss astucieuse — qui capture « A meilleur que B ».
3. Mettre à jour le modèle SFT pour produire plus de réponses « A-like ».

Deux branches : RLHF (reward model + RL) et DPO (saute le reward model avec une loss élégante). Le RLHF est arrivé en premier ; DPO (2023) est la simplification que l’open source a largement adoptée.

2. RLHF — la recette originale

InstructGPT (2022) et les premiers ChatGPT ont utilisé ça. Trois étapes par-dessus le SFT :

a. Entraîner un reward model

Prends le modèle SFT. Ajoute une tête scalaire : même backbone, mais la dernière couche sort un seul nombre. Entraîne sur des paires de préférence avec une loss de marge :

$$\mathcal{L}_{\text{RM}} = -\log \sigma\big(r(\text{prompt}, \text{A}) - r(\text{prompt}, \text{B})\big)$$

Ça pousse le reward de la réponse préférée plus haut que celui de la rejetée. Après assez de paires, le reward model est une fonction de score « human-preferred ».

b. La boucle PPO

La policy (le modèle SFT) génère des réponses. Chaque réponse reçoit un reward du reward model figé. La policy est mise à jour par PPO — une méthode RL qui pousse vers les rewards plus élevés tout en restant proche du SFT (sinon ça part en reward hacking).

Le terme KL contre le SFT est le régularisateur :

$$\mathcal{L}_{\text{PPO}} \approx -\mathbb{E}\big[r(\text{prompt}, \text{response})\big] + \beta \cdot \text{KL}(\pi_{\text{policy}} \,\|\, \pi_{\text{SFT}})$$

Sans KL, la policy s’effondre vers ce qui maximise le reward — souvent du non-sens que le reward model adore par défaut de ses propres biais.

c. Pourquoi c’est pénible

• Deux modèles supplémentaires à entraîner.
• Beaucoup de knobs PPO qui interagissent.
• Reward hacking, vrai mode d’échec.
• Coût compute = plusieurs fois le SFT.

La plupart des pipelines open source SFT post-2023 sautent le RLHF pour ces raisons.

3. DPO — direct preference optimization

Rafailov et al. (2023) ont remarqué un truc élégant : sous certaines hypothèses, la policy RLHF optimale a une forme close qui n’implique que le SFT et les paires de préférence. Pas de reward model. Pas de RL. Une seule loss.

La loss DPO par triplet (prompt, chosen, rejected) :

$$\mathcal{L}_{\text{DPO}} = -\log \sigma\Big(\beta\big[\log \pi_\theta(\text{chosen}) - \log \pi_\theta(\text{rejected}) - \log \pi_{\text{ref}}(\text{chosen}) + \log \pi_{\text{ref}}(\text{rejected})\big]\Big)$$

En mots : pousse le modèle pour que l’écart entre log-prob de (chosen) et (rejected) grandisse, relativement au même écart sous une référence figée (le SFT). Le β est la température KL.

Opérationnellement :

• Un modèle, pas trois. La référence = le checkpoint SFT, figé.
• Une loss qui se calcule exactement comme le SFT, sur un triplet au lieu d’une paire.
• Pas de RL — même loss.backward() qu’à l’appendice backprop.
• Mêmes hyperparams que le SFT, plus β (typiquement 0.1).

DPO est ce qu’utilisent la plupart des modèles open source instruct sortis depuis mi-2023 : Llama-3-Instruct, Mistral-Instruct, Zephyr, Tulu, OLMo-Instruct. Le code = ~100 lignes par-dessus la loop SFT du chapitre 17.

4. Pourquoi ce livre s’arrête au SFT

Trois raisons :

• Données. Les paires de préférence coûtent cher. HH-RLHF d’Anthropic = 170k paires de contractors. Les remplacements open comme UltraFeedback existent mais sont bruyants.
• Rendement marginal à petite échelle. Un modèle 14M ou 124M qui galère déjà sur les faits gagne moins à être preference-tuné qu’à recevoir plus de pré-entraînement ou plus de SFT de domaine.
• Scope. Le contrat du livre = construire l’architecture et sentir chaque pièce. Le preference tuning ajoute de l’infra (logging des paires, reward serving, sweeps β) sans ajouter de mécanisme conceptuel nouveau au-delà du SFT.

Si tu veux preference-tuner après le capstone du ch.21, la recette pratique :

1. Le modèle SFT du ch.21 sert à la fois de policy et de référence.
2. Collecte 500-2000 paires (toi en évaluant tes propres outputs, ou distillé d’un modèle plus gros).
3. Branche dans DPOTrainer de Hugging Face TRL, ~30 lignes.

5. À retenir

• SFT enseigne la forme ; le preference tuning enseigne le choix entre deux réponses bien formées.
• RLHF = reward model + PPO. Recette originale, puissante mais pénible.
• DPO = une loss, pas de reward model, pas de RL. Dominante en open source depuis 2023.
• Le mécanisme tient en tête : loss de marge sur les différences de log-prob, régularisée par le SFT.
• Les données sont le moat, pas l’algo.

Pour aller plus loin

• Christiano et al. (2017), « Deep RL from Human Preferences ».
• Ouyang et al. (2022), InstructGPT.
• Rafailov et al. (2023), DPO — court, à lire après le ch.17.
• DPOTrainer de Hugging Face TRL.