Fine-tuning et post-training (LoRA, DPO, RLHF)

Un grand modèle de langage pré-entraîné « connaît » énormément de choses, mais il ne sait pas spontanément suivre des instructions, adopter un ton, ni respecter vos contraintes métier. Le post-training — tout ce qui vient après le pré-entraînement — transforme ce réservoir de connaissances en assistant utile. Cet article décortique cette chaîne : l'affinage supervisé (SFT), l'optimisation des préférences (RLHF puis DPO), et les techniques qui rendent l'affinage abordable (LoRA, QLoRA). On finit par la question pratique : faut-il vraiment affiner, ou un bon prompt et du RAG suffisent-ils ?

Le fil rouge de l'article tient en une phrase : le post-training ne crée pas de connaissances, il sculpte un comportement. Le pré-entraînement a déjà rempli le modèle de faits et de schémas ; le post-training choisit lesquels mettre en avant, sous quelle forme, et avec quelles limites. Garder cette distinction en tête évite la plupart des erreurs coûteuses — à commencer par celle d'affiner pour « apprendre des faits » alors que le RAG ferait le travail mieux et moins cher.

Le pipeline de post-training en trois temps

La recette moderne d'un assistant aligné enchaîne trois étapes distinctes, chacune avec son objectif et ses données.

1. Pré-entraînement : le modèle de base apprend à prédire le token suivant sur un corpus web massif. Il acquiert grammaire, faits, raisonnement implicite — mais c'est un complèteur de texte, pas un interlocuteur.
2. SFT (Supervised Fine-Tuning) : on affine le modèle sur des démonstrations (couples instruction → réponse idéale), souvent écrites par des humains. C'est l'instruction tuning : le modèle apprend le format « on me demande, je réponds ».
3. Optimisation de préférence (alignement) : on apprend à partir de comparaisons (réponse préférée ≻ réponse rejetée) pour affiner le style, la sûreté, l'utilité. Deux grandes voies coexistent : RLHF (un modèle de récompense + de l'apprentissage par renforcement) et DPO (optimisation directe, sans RL).

Figure : le pipeline de post-training et ses deux voies d'alignement (RLHF vs DPO). Diagramme original.

La clé : ces étapes sont cumulatives. On part d'un modèle de base, on fait du SFT dessus, puis on aligne par préférence sur le modèle SFT. Chaque étape suppose la précédente — sauter le SFT pour passer directement à la préférence donne presque toujours un alignement instable, parce qu'on optimise un modèle qui ne sait pas encore tenir le format de dialogue.

Pourquoi cette séparation ? Parce que les deux signaux d'apprentissage sont de natures différentes :

• Le SFT répond à « à quoi ressemble une bonne réponse » : il a besoin d'exemples positifs (des démonstrations), et il apprend par imitation, comme tout apprentissage supervisé classique.
• L'optimisation de préférence répond à « laquelle de deux réponses est meilleure » : elle a besoin de comparaisons, un signal bien moins coûteux à produire (juger est plus facile qu'écrire) et qui capture des nuances de goût qu'aucune démonstration ne saurait exprimer.

C'est cette complémentarité qui fait la force du pipeline : on enseigne d'abord le comportement de base, puis on le polit par préférence. On peut résumer les trois étapes ainsi :

Étape	Signal	Données	Ce qu'on apprend
Pré-entraînement	Token suivant	Corpus web brut	Langue, faits, raisonnement implicite
SFT	Imitation	Démonstrations (instruction → réponse)	Le format et le comportement de base
Préférence	Comparaison	Paires (préférée ≻ rejetée)	Le style fin, la sûreté, l'utilité

Full fine-tuning vs PEFT

Affiner un modèle, dans le cas le plus simple, signifie mettre à jour tous ses poids par descente de gradient. C'est le full fine-tuning. Le problème est la mémoire. Pour un modèle de 7 à 70 milliards de paramètres, il faut stocker simultanément :

• les poids eux-mêmes ;
• les gradients (un par poids) ;
• les états de l'optimiseur — Adam garde deux moments (moyenne et variance) par paramètre.

En 16 bits, cela représente facilement quatre fois ou plus la taille du modèle en VRAM, sans compter les activations. Un petit calcul fixe les idées :

Modèle 7B en full fine-tuning, Adam, mixed precision :
  poids (fp16)            : 7 G × 2 o  = 14 Go
  gradients (fp16)        : 7 G × 2 o  = 14 Go
  états Adam (m, v, fp32) : 7 G × 8 o  = 56 Go
  copie maître fp32       : 7 G × 4 o  = 28 Go
  -----------------------------------------------
  ≈ 112 Go, hors activations

Affiner un 13B en pleine précision dépasse vite les 24 Go d'un GPU grand public ; un 70B exige un cluster. Le coût d'entrée est donc prohibitif pour la plupart des équipes.

Le PEFT (Parameter-Efficient Fine-Tuning) répond à ce problème : on gèle la grande majorité des poids et on n'entraîne qu'un petit nombre de paramètres ajoutés. Les bénéfices sont en cascade :

• Mémoire : pas de gradients ni d'états d'optimiseur pour les poids gelés — c'est l'essentiel de l'économie (les états d'optimiseur, le plus gros poste ci-dessus, disparaissent presque entièrement).
• Stockage : on ne sauvegarde que les petits adaptateurs (quelques Mo), pas une copie complète du modèle par tâche.
• Modularité : on peut charger/décharger des adaptateurs à la volée, voire en servir plusieurs sur le même modèle de base partagé.
• Vitesse d'itération : moins de paramètres à mettre à jour = des cycles d'expérimentation plus courts et moins chers.

Au-delà de LoRA, la famille PEFT inclut des méthodes comme les adapters en série, le prefix tuning (on apprend des « pseudo-tokens » de contexte) ou BitFit (on n'entraîne que les biais). Mais LoRA s'est imposée comme le standard de fait, par son équilibre simplicité/qualité et son absence de surcoût à l'inférence. C'est elle que nous détaillons.

LoRA : la math de l'adaptation de bas rang

LoRA (Low-Rank Adaptation, Hu et al., 2021) repose sur une hypothèse forte et vérifiée empiriquement : la mise à jour des poids nécessaire pour s'adapter à une tâche est de rang intrinsèquement faible. Autrement dit, ΔW — la différence entre les poids affinés et les poids de base — peut être bien approchée par un produit de deux petites matrices.

Pour une matrice de poids gelée W de taille d × d, LoRA n'apprend pas ΔW directement (ce serait d² paramètres), mais le factorise :

ΔW = B · A
  où  A ∈ ℝ^(r × d)   (init. gaussienne)
      B ∈ ℝ^(d × r)   (init. à zéro)
      r ≪ d           (rang faible, typiquement 4 à 64)

Passe avant :  h = W·x + (α / r) · B · A · x

Décortiquons :

• Le rang r contrôle la capacité de l'adaptateur. rang(B·A) ≤ r, donc petit r = peu de paramètres (2·r·d au lieu de d²). Pour GPT-3 175B, le papier rapporte jusqu'à 10 000× moins de paramètres entraînables et 3× moins de VRAM, à qualité égale ou supérieure au full fine-tuning.
• α (alpha) est un facteur d'échelle. Le ratio α/r règle l'amplitude de la mise à jour ; en pratique on fixe souvent α = 2r (ou on ajuste α/r comme un learning rate de l'adaptateur).
• L'initialisation est volontaire : A est gaussienne, B est à zéro. Au début, B·A = 0, donc l'adaptateur ne perturbe pas le modèle — l'entraînement démarre exactement à partir du modèle pré-entraîné.
• Quelles couches ? Le papier original applique LoRA aux matrices de projection query et value de l'attention. La pratique courante aujourd'hui cible aussi key, output et les couches MLP — plus de cibles = plus de capacité, plus de coût.

Figure : structure de LoRA — W + (α/r)·B·A, avec A et B seules entraînées. Diagramme original.

Un exemple chiffré rend l'économie tangible. Prenons une seule matrice de d = 4096 :

Full fine-tuning de cette matrice :  d²     = 4096 × 4096   ≈ 16,8 M paramètres
LoRA, rang r = 8 :                   2·r·d  = 2 × 8 × 4096  ≈ 65,5 k paramètres
                                     → ~256× moins de paramètres entraînables

Atout décisif : aucune latence ajoutée à l'inférence. Contrairement aux adaptateurs « en série », on peut fusionner B·A dans W (W' = W + (α/r)·B·A) avant le déploiement. Le modèle servi a exactement la même forme que l'original. Et puisque chaque adaptateur ne pèse que quelques mégaoctets, on peut en entraîner un par tâche et les permuter — un même modèle de base servant des dizaines de spécialisations.

Comment choisir le rang ? Quelques repères pratiques :

• Pour une tâche étroite (un format, un style précis), r = 4 à 8 suffit souvent.
• Pour une adaptation plus large (un domaine entier, un comportement riche), montez à r = 16 à 64.
• Augmenter r au-delà donne des rendements décroissants et rapproche du coût d'un full fine-tuning sans en garantir le gain.

Le rang est donc le principal levier capacité/coût ; on le règle empiriquement, en surveillant la performance sur un jeu de validation. Une heuristique stable : commencer à r = 16, α = 32, cibler query/key/value/output plus les projections MLP, puis ajuster selon la courbe de validation plutôt qu'à l'aveugle.

QLoRA : affiner un modèle quantifié en 4 bits

LoRA réduit les paramètres entraînables, mais il faut toujours charger le modèle de base en mémoire. QLoRA (Dettmers et al., 2023) s'attaque à ce dernier mur en quantifiant le modèle de base en 4 bits, tout en gardant les adaptateurs LoRA en plus haute précision. Le gradient rétro-propage à travers le modèle gelé 4-bit jusque dans les adaptateurs. Trois innovations rendent cela possible sans perte de qualité :

• NF4 (4-bit NormalFloat) : un type de données 4 bits optimal au sens de l'information pour des poids distribués normalement (ce qui est le cas des poids d'un réseau). Plutôt qu'une grille linéaire, NF4 place ses 16 niveaux de quantification selon les quantiles d'une loi normale, de sorte que chaque bin reçoive un nombre attendu égal de valeurs — la quantification est ainsi adaptée à la forme réelle de la distribution des poids.
• Double quantification : on quantifie les constantes de quantification elles-mêmes. Comme on quantifie par blocs (chaque bloc a sa propre constante d'échelle), ces constantes finissent par peser ; les requantifier grappille encore quelques dixièmes de bit par paramètre.
• Paged optimizers : on utilise la mémoire unifiée NVIDIA pour absorber les pics de mémoire de l'optimiseur (par exemple sur de longues séquences ou pendant le gradient checkpointing), en paginant vers la RAM CPU au lieu de planter sur un OOM.

Résultat : QLoRA affine un modèle de 65 milliards de paramètres sur un seul GPU de 48 Go, en conservant la performance d'un affinage 16-bit. La famille Guanaco ainsi obtenue a atteint 99,3 % de la performance de ChatGPT sur le benchmark Vicuna après seulement 24 h d'entraînement sur un GPU. C'est ce qui a démocratisé l'affinage sérieux sur du matériel modeste.

Une nuance importante : la quantification 4-bit ne concerne que le stockage du modèle gelé. Au moment du calcul, les poids NF4 sont déquantifiés à la volée vers un type plus précis (bf16) pour la multiplication, puis le résultat se combine aux adaptateurs LoRA en pleine précision. On échange donc un peu de calcul (déquantification) contre une économie massive de mémoire — un compromis presque toujours gagnant pour l'affinage.

SFT et instruction tuning : la donnée d'abord

Avant toute optimisation de préférence, le SFT pose les fondations. On y affine le modèle sur des couples (instruction, réponse) qui démontrent le comportement voulu : répondre poliment, suivre un format, refuser une demande dangereuse, raisonner étape par étape.

La leçon constante de la littérature et de la pratique : la qualité des données prime sur la quantité. Quelques milliers d'exemples soignés, diversifiés et corrects battent des centaines de milliers d'exemples bruités. Points d'attention :

• Diversité des instructions (tâches, longueurs, domaines) pour éviter le surajustement à un format.
• Cohérence du style des réponses : le modèle imite ce qu'il voit, défauts compris.
• Masquage de la perte sur le prompt : on n'entraîne souvent la perte que sur les tokens de réponse, pas sur l'instruction.
• Format de chat : on respecte le gabarit attendu par le modèle (balises de rôle système/utilisateur/assistant), sous peine d'apprendre un format incohérent avec l'inférence.

Concrètement, un exemple de SFT au format chat ressemble à ceci ; seuls les tokens de la réponse de l'assistant comptent dans la perte :

<|system|> Tu es un assistant concis et factuel.
<|user|>   Résume en une phrase ce qu'est LoRA.
<|assistant|> LoRA affine un modèle en n'entraînant que deux petites
              matrices de bas rang, le reste des poids restant gelé.
   ▲ perte calculée uniquement ici (tokens de réponse)

D'où viennent ces données ? Trois sources, souvent mêlées :

• Annotation humaine : la plus coûteuse, mais la plus fiable pour le ton et la sûreté.
• Données existantes recyclées : tickets de support, FAQ, transcriptions, reformulés en couples instruction/réponse.
• Distillation : on génère des réponses avec un modèle plus fort, puis on filtre les meilleures — économique, mais attention aux conditions de licence et à la propagation des biais du modèle enseignant.

RLHF : modèle de récompense + PPO, à la InstructGPT

Après le SFT, comment encoder des préférences subtiles (« cette réponse est plus utile que celle-ci ») qu'on ne sait pas écrire comme une démonstration ? Réponse historique : le RLHF (Reinforcement Learning from Human Feedback), popularisé par InstructGPT (Ouyang et al., 2022). Trois étapes :

1. SFT (déjà vu) : point de départ.
2. Modèle de récompense (RM) : on collecte des humains qui classent plusieurs réponses du modèle à un même prompt. On entraîne un modèle séparé (le RM) à prédire un score scalaire de préférence, via un modèle de Bradley-Terry sur les paires.
3. RL par PPO : on optimise la politique (le LLM) pour maximiser la récompense prédite par le RM, avec une pénalité KL qui empêche la politique de trop s'éloigner du modèle SFT (sinon elle « triche » en exploitant les failles du RM — le reward hacking).

Le modèle de récompense s'entraîne lui-même par une perte de préférence simple, qui pousse le score de la réponse préférée y_w au-dessus de celui de la rejetée y_l :

L_RM = − log σ( r(x, y_w) − r(x, y_l) )

  r(x, y) : score scalaire prédit par le RM
  σ       : sigmoïde (modèle de Bradley-Terry)

L'objectif de la phase RL combine ensuite récompense et pénalité KL :

maximiser  E[ r(x, y) ]  −  β · KL( π_θ(·|x) ‖ π_ref(·|x) )

Le résultat marquant : un InstructGPT de 1,3 milliard de paramètres a été préféré à GPT-3 175B par les évaluateurs humains, malgré 100× moins de paramètres. L'alignement compte autant que l'échelle.

Le revers : le pipeline RLHF est lourd. Concrètement, il faut :

• maintenir plusieurs modèles en mémoire simultanément (la politique entraînée, le modèle de récompense, le modèle de référence pour la pénalité KL, et le critique de valeur de PPO) ;
• échantillonner des réponses depuis la politique en boucle d'entraînement, ce qui est lent ;
• composer avec un RL instable et très sensible aux hyperparamètres (taux d'apprentissage, coefficient KL, fenêtre de clipping de PPO).

À cela s'ajoute le risque de reward hacking : la politique trouve des réponses qui maximisent le score du RM sans être réellement meilleures (réponses trop longues, flatteuses, ou exploitant un angle mort de l'annotation). La pénalité KL bride ce phénomène, mais ne l'élimine pas. C'est cette complexité qui a motivé la recherche d'alternatives plus simples — et DPO en est la plus marquante.

DPO : l'optimisation directe des préférences

DPO (Direct Preference Optimization, Rafailov et al., 2023) part d'une observation élégante : le problème d'optimisation sous contrainte que RLHF résout par PPO admet une solution analytique en forme close. La politique optimale s'écrit π*(y|x) ∝ π_ref(y|x) · exp( r(x,y) / β ). En inversant cette relation, on exprime la récompense implicite comme une fonction de la politique elle-même — d'où le sous-titre du papier, « votre modèle de langage est secrètement un modèle de récompense » :

r(x, y) = β · log( π_θ(y|x) / π_ref(y|x) )  +  β · log Z(x)

En injectant cette récompense implicite dans le modèle de Bradley-Terry, la constante de partition Z(x) s'annule entre les deux réponses d'une même paire. Conséquence : on n'a plus besoin d'entraîner un RM séparé ni de faire du RL. La perte devient une simple classification supervisée sur les paires de préférence :

Pour une paire (y_w préférée, y_l rejetée) et un prompt x :

L_DPO = − log σ(  β · [ log( π_θ(y_w|x) / π_ref(y_w|x) )
                       − log( π_θ(y_l|x) / π_ref(y_l|x) ) ]  )

  π_θ   : la politique entraînée
  π_ref : la politique de référence (le modèle SFT gelé)
  β     : tempère l'écart toléré par rapport à π_ref (rôle de la pénalité KL)
  σ     : sigmoïde (modèle de Bradley-Terry)

Intuitivement : DPO augmente la probabilité relative de la réponse préférée et diminue celle de la rejetée, le tout pondéré par l'écart à la référence. Le gradient pèse implicitement plus fort sur les paires où le modèle se trompe le plus (où il préfère, à tort, la réponse rejetée), ce qui donne un signal d'apprentissage auto-ajusté. Pas de boucle RL, pas de RM, juste une passe de gradient sur des paires. Le papier montre que DPO égale ou dépasse PPO sur le contrôle du sentiment, le résumé et le dialogue, tout en étant bien plus simple et stable à entraîner.

Les avantages concrets de DPO :

• Deux modèles seulement en mémoire (la politique et la référence gelée), contre quatre pour le RLHF complet.
• Pas d'échantillonnage en boucle : on s'entraîne directement sur un jeu de paires figé.
• Entraînement déterministe et stable, comme tout apprentissage supervisé.

Ses limites : DPO apprend hors-ligne sur des préférences fixes, là où le RLHF en ligne peut continuer à explorer ; et le choix de β reste sensible (trop petit, le modèle dérive ; trop grand, il n'apprend presque rien). En pratique, DPO est devenu le défaut pragmatique pour l'alignement par préférence — souvent combiné à LoRA pour rester économe, ce qui donne une boucle complète SFT → DPO entièrement réalisable sur un GPU unique. Toute une famille de variantes a suivi (IPO, KTO, ORPO, SimPO) pour corriger des cas pathologiques de DPO, mais l'idée centrale — optimiser la préférence sans RL — reste la même.

Au-delà : RLAIF, Constitutional AI, GRPO

La famille s'est élargie :

• RLAIF / Constitutional AI : remplacer (en partie) le feedback humain par du feedback d'IA. Un modèle critique évalue et révise les réponses selon une « constitution » — un ensemble de principes écrits explicites. L'intérêt est triple :
  • coût : l'annotation à grande échelle devient quasi gratuite ;
  • cohérence : les principes sont appliqués uniformément, sans la variance des annotateurs humains ;
  • sûreté : on évite d'exposer des humains à des contenus toxiques pour les étiqueter. Le risque est que les biais et angles morts du modèle critique se propagent ; on garde donc souvent un noyau de supervision humaine.
• GRPO (Group Relative Policy Optimization, DeepSeekMath, 2024) : une variante de PPO qui supprime le critique de valeur. Pour chaque prompt, on échantillonne un groupe de G réponses, on calcule la récompense de chacune, et on normalise au sein du groupe pour estimer l'avantage relatif de chaque réponse :

  Pour un groupe de récompenses {r_1, …, r_G} :
    A_i = ( r_i − moyenne(r) ) / écart-type(r)

  L'avantage A_i remplace l'estimation produite par le critique de valeur de PPO. Avantages :
  • moins de mémoire : un modèle de moins à entraîner (pas de critique séparé) ;
  • plus de stabilité : la normalisation amortit les récompenses bruitées ou éparses ;
  • idéal pour les récompenses vérifiables : en maths ou en code, on sait dire automatiquement si une réponse est correcte, sans annotateur. C'est l'algorithme derrière les modèles de raisonnement comme DeepSeek-R1.

Où trouver les données de préférence

L'optimisation de préférence (DPO comme RLHF) a besoin de paires (réponse préférée, réponse rejetée). On les obtient typiquement ainsi :

• Génération + classement humain : on échantillonne plusieurs réponses du modèle SFT pour un même prompt, puis des humains les ordonnent. C'est la source de référence pour le ton et la sûreté.
• Paires issues de logs : une réponse régénérée et acceptée par l'utilisateur (pouce levé) vs une rejetée (pouce baissé) — un signal gratuit et continu en production.
• Paires synthétiques (RLAIF) : un modèle juge génère le verdict de préférence à grande échelle, ce qui démultiplie le volume au prix d'un biais possible du juge.

La diversité des prompts et la fiabilité du signal de préférence comptent plus que le volume brut : des paires ambiguës ou contradictoires (où même un humain hésite) n'apportent qu'un gradient bruité et peuvent dégrader le modèle. Mieux vaut un jeu de paires plus petit mais nettement tranché.

Affiner, ou pas ? Fine-tuning vs RAG vs prompt engineering

C'est la décision la plus importante — et la plus souvent ratée. Règle générale :

• Prompt engineering d'abord : le moins cher, instantané, sans entraînement. Suffit pour beaucoup de cas (format, ton, tâches one-shot/few-shot).
• RAG (Retrieval-Augmented Generation) pour la connaissance : si le besoin est « le modèle doit connaître MES documents / des faits à jour », le RAG injecte le contexte au moment de la requête. Affiner n'apprend pas de nouveaux faits de façon fiable — et les faits changent.
• Fine-tuning pour le comportement : si le besoin est « le modèle doit se comporter d'une certaine façon » (style de marque, format strict, tâche spécialisée, latence/coût réduits via un petit modèle spécialisé), l'affinage est le bon outil.

Besoin	Outil recommandé	Pourquoi
Format, ton, exemples ponctuels	Prompt engineering	Instantané, zéro entraînement
Faits à jour, documents privés	RAG	Le contexte change sans réentraîner
Style stable, format strict, tâche pointue	Fine-tuning	Le comportement est gravé dans les poids
Petit modèle spécialisé peu coûteux	Fine-tuning (+ distillation)	Latence et coût d'inférence réduits

Formule mnémotechnique : RAG pour ce que le modèle doit savoir, fine-tuning pour comment il doit agir. Les deux se combinent très bien — un modèle affiné au comportement métier qui interroge une base RAG à jour est un patron très courant.

Pièges : oubli catastrophique, éval, qualité des données

• Oubli catastrophique : un affinage trop agressif fait perdre des capacités générales (le modèle « oublie » ce qu'il savait hors de votre tâche). PEFT/LoRA atténue le risque, car les poids de base restent gelés ; gardez un learning rate modéré, limitez le nombre d'époques, et mélangez des données généralistes si besoin.
• Évaluation : sans benchmark clair (idéalement automatisable) défini avant d'affiner, vous ne saurez pas si vous progressez. Mesurez sur un jeu de validation tenu à l'écart, jamais sur les exemples d'entraînement, et comparez systématiquement au modèle de base et à une simple baseline de prompt.
• Qualité et fuite des données : des étiquettes bruitées s'apprennent comme telles ; une fuite train/test gonfle artificiellement les scores. Dédupliquez, vérifiez à la main un échantillon, et privilégiez toujours la qualité sur le volume.
• Sur-spécialisation : un modèle affiné sur une distribution étroite devient fragile hors de celle-ci. Prévoyez des exemples adverses et des cas limites dans le jeu d'entraînement.
• Hyperparamètres LoRA mal réglés : un α/r trop grand fait diverger l'entraînement ; trop petit, l'adaptateur n'apprend presque rien. Surveillez la perte de validation, pas seulement celle d'entraînement.

Une recette de bout en bout, en bref

Pour fixer les idées, une boucle moderne et abordable ressemble à ceci :

1. Charger le modèle de base quantifié en 4-bit (NF4).
2. Faire du SFT avec LoRA sur quelques milliers de démonstrations de qualité.
3. Faire du DPO avec LoRA sur des paires de préférence pour polir style et sûreté.
4. Fusionner les adaptateurs dans les poids et évaluer sur un jeu tenu à l'écart.
5. Déployer — ou itérer si l'éval n'est pas concluante.

L'ensemble tient sur un seul GPU, ce qui était impensable avant LoRA/QLoRA et DPO.

En somme : le post-training est une chaîne (SFT → préférence) que LoRA/QLoRA rendent abordable, et où DPO a largement simplifié l'alignement face au RLHF classique. Mais la meilleure optimisation reste de ne pas affiner quand un prompt et du RAG suffisent.