DPO : affiner un modèle avec des paires de préférences

La DPO (Direct Preference Optimization, optimisation directe des préférences) affine un modèle à partir de paires de réponses : pour une même demande, une réponse préférée et une réponse rejetée. Le modèle apprend à creuser l'écart entre les deux. C'est utile quand il est plus facile de dire « celle-ci est meilleure que celle-là » que d'écrire la réponse parfaite, par exemple pour un ton, un niveau de détail ou une façon de refuser.

D'où vient la méthode

Les assistants actuels sont en partie entraînés à partir de préférences humaines. Le glossaire d'Anthropic décrit ainsi le RLHF (apprentissage par renforcement à partir de retours humains) : des personnes classent plusieurs réponses, et l'entraînement pousse le modèle vers les réponses les mieux classées. Cette méthode passe par deux étapes : entraîner d'abord un modèle de récompense, puis affiner le modèle de langage par apprentissage par renforcement.

L'article « Direct Preference Optimization: Your Language Model is Secretly a Reward Model » de Rafael Rafailov et ses coauteurs (déposé le 29/05/2023) supprime ces deux étapes. Il ramène le problème à une simple perte de classification sur les paires de réponses. D'après ses auteurs, la méthode est stable, légère en calcul, ne demande pas de générer des réponses pendant l'entraînement, et donne des résultats équivalents ou meilleurs que les méthodes existantes sur les tâches testées (contrôle du sentiment, résumé, dialogue à un tour).

SFT ou DPO ?

Les deux se combinent : la bibliothèque TRL propose même une perte "sft" parmi les options de DPOTrainer. Le parcours SFT est décrit sur Fine-tuning avec Hugging Face.

Le format des paires

TRL attend un jeu de préférences, avec une demande explicite (format recommandé par la documentation) :

{"prompt": [{"role": "user", "content": "Résumez ce courriel client."}],
 "chosen": [{"role": "assistant", "content": "Le client demande un avoir sur la facture de mars."}],
 "rejected": [{"role": "assistant", "content": "Bonjour, voici un résumé détaillé de ce courriel..."}]}

Sur un jeu conversationnel, le gabarit de conversation du modèle est appliqué automatiquement. Les deux réponses doivent répondre à la même demande, et la différence entre elles doit porter sur ce que vous voulez enseigner, pas sur un détail accidentel. Pour la préparation générale des fichiers, voir Jeu de données.

Le code avec TRL

L'exemple de démarrage de la documentation (version 1.18.0, lue le 15/11/2026), avec un adaptateur LoRA :

from datasets import load_dataset
from trl import DPOTrainer
from peft import LoraConfig

trainer = DPOTrainer(
    "Qwen/Qwen3-0.6B",
    train_dataset=load_dataset("trl-lib/ultrafeedback_binarized", split="train"),
    peft_config=LoraConfig(),
)
trainer.train()

Sans ref_model, TRL prend comme modèle de référence l'état du modèle avant l'entraînement DPO : l'apprentissage mesure l'écart des réponses par rapport à ce point de départ.

Les réglages à connaître

precompute_ref_log_probs=True calcule à l'avance les probabilités du modèle de référence, ce qui évite de le garder en mémoire pendant l'entraînement.

Lire les indicateurs

En plus de la perte, TRL journalise des indicateurs propres à la DPO :

• rewards/chosen et rewards/rejected : la « récompense implicite » moyenne des réponses préférées et rejetées ;
• rewards/margins : l'écart moyen entre les deux ;
• rewards/accuracies : la part des paires où la réponse préférée obtient la meilleure récompense.

Une marge qui augmente montre que le modèle apprend vos préférences sur le jeu d'entraînement. Elle ne dit pas qu'il répond mieux en conditions réelles : comparez sur un jeu de test à part (Évaluer un modèle affiné).

Et sur les services gérés ?

Chez Google, la documentation du réglage supervisé de Gemini oriente les tâches de raisonnement en plusieurs étapes vers une autre méthode, le réglage par renforcement, décrite sur une page séparée. Sur un modèle à poids ouverts, la DPO avec TRL est une voie documentée et accessible pour enseigner des préférences.