Accueil › Glossaire › Preference Tuning

Preference Tuning

Le preference tuning (ajustement par préférences, aussi appelé preference finetuning ou PreFT) est l’étape de post-entraînement qui aligne un LLM avec les préférences humaines en l’entraînant sur des données de comparaison (réponse A meilleure que réponse B), plutôt que sur des paires entrée-sortie fixes comme en fine-tuning supervisé.

Pourquoi le preference tuning est nécessaire

Le fine-tuning supervisé (SFT) apprend au modèle quoi répondre en lui montrant des exemples idéaux. Mais pour de nombreuses qualités importantes, il est plus facile de comparer deux réponses que de produire la réponse parfaite. C’est l’analogie classique : vous pouvez facilement dire quel film vous préférez entre deux, mais vous seriez incapable de réaliser le film qui incarne toutes vos préférences.

Le preference tuning exploite cette asymétrie. Au lieu de montrer au modèle la « bonne réponse », on lui montre deux réponses et on lui indique laquelle est meilleure. Le modèle apprend ainsi à ajuster ses probabilités de génération pour favoriser le type de réponse préféré par les humains.

Les qualités ciblées par le preference tuning sont typiquement subjectives et difficiles à capturer dans un dataset de SFT :

Utilité (helpfulness). La réponse est-elle réellement utile, complète et pertinente ?

Innocuité (harmlessness). La réponse évite-t-elle les contenus dangereux, offensants ou trompeurs ?

Honnêteté (honesty). Le modèle reconnaît-il ses limites et évite-t-il de fabriquer des informations ?

Ton et style. La réponse est-elle concise ou détaillée, formelle ou décontractée, empathique ou factuelle, selon ce qui est approprié ?

Calibration. Le modèle est-il capable de refuser les requêtes inappropriées tout en restant accessible sur les sujets légitimes ?

Les données de préférences

Le format standard des données de preference tuning est le triplet :

Les données de préférences se collectent de trois façons :

Annotation humaine directe. Des annotateurs comparent des paires de réponses générées par le modèle et choisissent la meilleure. C’est l’approche utilisée par InstructGPT/ChatGPT (OpenAI) et Claude (Anthropic). Elle est coûteuse mais produit les données les plus fiables pour l’alignement.

IA comme juge (RLAIF). Un LLM puissant (comme GPT-4 ou Claude) évalue les paires de réponses à la place des humains. C’est l’approche Constitutional AI d’Anthropic, où le modèle critique et révise ses propres sorties selon des principes prédéfinis. Elle réduit considérablement les coûts d’annotation tout en maintenant des performances comparables au feedback humain.

Récompenses vérifiables (rule-based). Pour les tâches à réponse déterministe (mathématiques, code), un script vérifie automatiquement si la réponse est correcte. La réponse correcte est « préférée », l’incorrecte est « rejetée ». C’est l’approche utilisée par DeepSeek-V3 pour le raisonnement mathématique (GRPO avec récompenses rule-based).

Les méthodes de preference tuning

RLHF (Reinforcement Learning from Human Feedback)

L’approche originale, popularisée par InstructGPT (OpenAI, 2022). Le pipeline se décompose en deux étapes :

Étape 1 : entraîner un reward model. Un modèle séparé est entraîné pour prédire les préférences humaines. Il prend un prompt et une réponse en entrée et produit un score scalaire. Le reward model est entraîné sur les paires de préférences en minimisant la loss de Bradley-Terry (pairwise ranking loss).

Étape 2 : optimiser le LLM avec PPO. Le LLM est optimisé par reinforcement learning pour maximiser les récompenses du reward model, sous contrainte de ne pas trop s’éloigner du modèle de référence (régularisation KL). L’algorithme PPO (Proximal Policy Optimization) est le plus couramment utilisé.

Le RLHF avec PPO est puissant mais complexe : il nécessite de maintenir quatre modèles en mémoire simultanément (le LLM courant, le modèle de référence, le reward model, et le value network de PPO), et le processus d’entraînement est notoirement instable et sensible aux hyperparamètres.

DPO (Direct Preference Optimization)

Proposé par Rafailov et al. (Stanford, 2023), le DPO est devenu l’alternative dominante au RLHF. L’idée clé : on peut reparamétriser le reward model dans la formulation RLHF de sorte que la politique optimale puisse être extraite en forme fermée, sans jamais entraîner un reward model séparé ni faire du reinforcement learning.

Concrètement, le DPO optimise directement le LLM avec une simple loss contrastive de classification :

# Pseudo-code simplifié de la loss DPO
# pi_theta : le modèle en cours d'entraînement
# pi_ref : le modèle de référence (SFT)
# y_w : réponse préférée (winner)
# y_l : réponse rejetée (loser)
# beta : coefficient de régularisation

log_ratio_w = log(pi_theta(y_w|x)) - log(pi_ref(y_w|x))
log_ratio_l = log(pi_theta(y_l|x)) - log(pi_ref(y_l|x))

loss = -log(sigmoid(beta * (log_ratio_w - log_ratio_l)))

Le DPO pousse le modèle à augmenter la probabilité relative de la réponse préférée par rapport au modèle de référence, tout en diminuant celle de la réponse rejetée. Le paramètre β contrôle la force de la régularisation (plus β est élevé, plus le modèle peut s’éloigner du modèle de référence).

Les avantages du DPO sont significatifs : pas de reward model séparé, pas de sampling on-policy, pas de reinforcement learning. L’entraînement se fait avec une simple loss supervisée, stable et bien comprise. Le DPO a été adopté par Llama 3, Zephyr, et de nombreux modèles open-source.

KTO (Kahneman-Tversky Optimization)

Le KTO (Ethayarajh et al., 2024) simplifie encore les données requises : au lieu de paires de préférences (A meilleur que B), il utilise un feedback unaire (cette réponse est bonne / cette réponse est mauvaise). C’est inspiré de la théorie des perspectives de Kahneman et Tversky : les humains évaluent les résultats par rapport à un point de référence, pas en termes absolus.

L’avantage pratique est considérable : collecter des thumbs up/thumbs down est beaucoup plus simple et moins coûteux que des comparaisons par paires. Le KTO est particulièrement adapté aux situations où les données de préférences pairées sont difficiles à obtenir.

ORPO (Odds Ratio Preference Optimization)

ORPO (Hong et al., 2024) va encore plus loin en éliminant le besoin d’un modèle de référence. Il utilise un objectif basé sur le rapport de cotes (odds ratio) pour contrôler la dérive du modèle, réduisant le nombre de passes nécessaires et simplifiant l’implémentation.

GRPO (Group Relative Policy Optimization)

Utilisé par DeepSeek pour l’entraînement de DeepSeek-V3 et DeepSeek-R1, le GRPO compare des groupes de réponses candidates et dérive des préférences relatives. Il élimine le besoin d’un modèle critique (critic model) de même taille que le LLM, ce qui réduit significativement le coût mémoire. Les scores de groupe servent de baseline pour l’optimisation.

SimPO (Simple Preference Optimization)

SimPO (Meng et al., 2024) utilise la longueur normalisée de la log-probabilité comme récompense implicite, sans modèle de référence. C’est l’une des variantes les plus récentes et les plus légères.

Comparatif des méthodes

Place dans le pipeline moderne

Le pipeline standard de développement d’un LLM suit aujourd’hui trois à quatre étapes :

1. Pré-entraînement : prédiction du prochain token sur des trillions de tokens. Produit le modèle de base.

2. SFT (instruction tuning + chat tuning) : fine-tuning supervisé sur des paires (instruction, réponse) et des conversations multi-tours. Enseigne les compétences de base : suivi d’instructions, format de dialogue.

3. Preference tuning : alignement avec les préférences humaines via DPO, RLHF, ou variante. Affine les qualités subjectives : utilité, sécurité, ton, concision.

4. RLVR (optionnel) : Reinforcement Learning from Verifiable Rewards. Entraînement par renforcement sur des tâches vérifiables (maths, code) pour améliorer le raisonnement. Utilisé par DeepSeek-R1 et les modèles de raisonnement.

L’ordre exact varie selon les laboratoires. DeepSeek-V3 utilise SFT puis GRPO avec un mélange de récompenses rule-based et model-based. Llama 3 utilise SFT puis DPO itératif. Certains pipelines intercalent plusieurs rounds de SFT et preference tuning.

DPO vs. RLHF : le débat

Le DPO a largement supplanté le RLHF-PPO dans l’écosystème open-source grâce à sa simplicité. Mais le débat reste ouvert sur lequel produit de meilleurs résultats.

Arguments pour le DPO : plus simple à implémenter et à débugger. Plus stable en entraînement (pas de reward hacking). Moins gourmand en mémoire (2 modèles au lieu de 4). Performances comparables ou supérieures au RLHF sur de nombreux benchmarks (sentiment, résumé, dialogue).

Arguments pour le RLHF : le reward model est réutilisable (on peut le tester, le stocker, le combiner avec d’autres). L’exploration on-policy permet de découvrir des comportements que le dataset offline ne contient pas. Certains travaux montrent que le RLHF surpasse le DPO sur des tâches complexes d’alignement. Les meilleurs modèles fermés (ChatGPT, Claude) utilisent encore des variantes de RLHF.

Le consensus pratique : pour la plupart des cas d’usage, le DPO offre le meilleur rapport qualité/effort. Le RLHF reste pertinent pour les laboratoires ayant les ressources de maintenir un pipeline complexe et cherchant à maximiser l’alignement sur des dimensions subtiles. Le pipeline moderne combine souvent les deux : DPO pour un alignement initial rapide, puis RLHF itératif pour affiner.

Implémentation pratique avec DPO

# Preference tuning avec DPO via HuggingFace TRL
from transformers import AutoModelForCausalLM, AutoTokenizer
from trl import DPOTrainer, DPOConfig
from datasets import load_dataset

# Charger le modèle SFT (déjà instruction-tuné)
model = AutoModelForCausalLM.from_pretrained("mistral-sft-checkpoint")
tokenizer = AutoTokenizer.from_pretrained("mistral-sft-checkpoint")

# Dataset de préférences : prompt, chosen, rejected
dataset = load_dataset("argilla/ultrafeedback-binarized-preferences")

# Configuration DPO
training_args = DPOConfig(
    output_dir="./mistral-dpo",
    beta=0.1,            # Force de la régularisation
    per_device_train_batch_size=2,
    num_train_epochs=1,
    learning_rate=5e-7,  # LR très faible pour le DPO
    bf16=True,
)

# Le DPOTrainer gère automatiquement le modèle de référence
trainer = DPOTrainer(
    model=model,
    args=training_args,
    train_dataset=dataset["train"],
    processing_class=tokenizer,
)
trainer.train()

Limites et problèmes connus

Reward hacking. Le modèle peut apprendre à exploiter des quirks du reward model (ou du dataset de préférences) plutôt que de véritablement s’améliorer. Par exemple, produire des réponses artificiellement longues si les annotateurs préfèrent les réponses longues, ou utiliser un ton excessivement prudent si la sécurité est surpondérée.

Données hors distribution. Le DPO, fonctionnant en mode offline, peut produire des comportements inattendus pour des prompts très différents de ceux du dataset de préférences. C’est l’un des avantages théoriques du RLHF on-policy : le modèle explore activement l’espace de réponses pendant l’entraînement.

Réduction de la diversité. Le preference tuning tend à réduire la diversité des sorties du modèle, car il pousse le modèle vers un « mode » de réponse préféré. Cela peut être problématique pour les tâches créatives.

Sensibilité aux données. La qualité des annotations de préférences est déterminante. Des annotateurs incohérents, biaisés, ou mal calibrés produisent un preference tuning de mauvaise qualité. L’utilisation de RLAIF (IA comme juge) réduit ce risque mais introduit les biais du modèle juge.

Verdict

Le preference tuning est l’étape qui fait passer un LLM de « capable » à « agréable à utiliser ». C’est la différence entre un modèle qui sait répondre correctement et un modèle qui répond de la façon que vous préférez. Sans preference tuning, les modèles sont souvent verbeux, inconsistants dans le ton, et mal calibrés sur les questions de sécurité.

Le DPO est devenu le choix par défaut pour l’écosystème open-source, grâce à sa simplicité et à son efficacité. Pour un praticien qui débute : commencez par un SFT solide, puis appliquez un DPO avec 1 000 à 5 000 paires de préférences de haute qualité, un β de 0,1, et un learning rate de 5e-7. Évaluez avec des métriques humaines ou LLM-as-judge, pas juste des benchmarks automatiques. Et surveillez le reward hacking : si votre modèle devient soudainement très « poli » mais vide de contenu, c’est un signe que le preference tuning a dérivé.