DPO (Direct Preference Optimization)

Qu’est-ce que le DPO ?

Le DPO (Direct Preference Optimization) est une méthode de fine-tuning qui enseigne au modèle à préférer certaines réponses à d’autres. Au lieu de montrer uniquement la bonne réponse, comme dans tout ce que nous avons fait jusqu’ici, vous montrez une paire : une réponse préférée et une réponse non préférée. Le modèle apprend à maximiser la probabilité de la première tout en minimisant celle de la seconde. La différence est plus profonde qu’il n’y paraît : en fine-tuning supervisé, vous décrivez une cible ; en DPO, vous décrivez une frontière.

Quand y recourir

Le DPO se justifie d’abord lorsque les nuances comptent, c’est-à-dire quand la différence entre une bonne et une excellente réponse est subtile. Deux réponses peuvent être toutes deux exactes, bien formatées et polies, et pourtant l’une seulement correspondra à ce que vous voulez servir ; cette distinction-là passe mal par l’exemple isolé, très bien par la comparaison. Il devient également l’outil naturel quand vous voulez éviter certains comportements : le fine-tuning supervisé n’a aucun moyen d’exprimer un contre-exemple, alors que le DPO montre explicitement au modèle ce qu’il ne faut pas faire.

Vient ensuite tout ce qui relève de l’alignement — sécurité, conformité, ton de marque —, des domaines où la formulation acceptable et la formulation problématique se ressemblent souvent à quelques mots près. Enfin, si vos équipes ont déjà produit des préférences humaines, par exemple des évaluateurs qui ont classé des réponses A contre B, vous disposez du corpus DPO sans avoir à le construire : ces classements sont vos paires.

Le format des données

Le format utilise la méthode dpo et remplace le tableau messages par trois clés : le contexte partagé dans input, puis les deux issues comparées. Observez ci-dessous que la réponse non préférée n’est pas une réponse absurde — elle est simplement défensive et ferme la conversation, là où la préférée reconnaît l’objection et propose une suite.

{
  "method": "dpo",
  "input": [
    {
      "role": "system",
      "content": "Vous êtes un assistant commercial professionnel."
    },
    {
      "role": "user",
      "content": "Votre produit est trop cher."
    }
  ],
  "preferred_output": [
    {
      "role": "assistant",
      "content": "Je comprends votre préoccupation sur le prix. Notre solution inclut le support premium, les mises à jour illimitées et une garantie de disponibilité 99,9 %. Comparé aux alternatives qui facturent ces services séparément, notre rapport qualité-prix est très compétitif. Puis-je vous montrer une analyse comparative ?"
    }
  ],
  "non_preferred_output": [
    {
      "role": "assistant",
      "content": "Ce n'est pas cher du tout, c'est le prix du marché. Si vous ne pouvez pas vous le permettre, nous avons un plan basique."
    }
  ]
}

La génération du fichier suit la même logique que pour le fine-tuning supervisé : une paire par ligne, encodage UTF-8, ensure_ascii=False. Les deux paires ci-dessous illustrent un même critère de préférence appliqué à deux situations différentes, ce qui est exactement ce que vous cherchez à obtenir sur l’ensemble du corpus.

import json

paires = [
    {
        "method": "dpo",
        "input": [
            {"role": "system", "content": "Assistant support client bienveillant."},
            {"role": "user", "content": "Votre service ne marche pas !"}
        ],
        "preferred_output": [
            {
                "role": "assistant",
                "content": "Je suis désolé pour ce désagrément. Pouvez-vous me décrire le problème que vous rencontrez ? Je vais faire mon maximum pour le résoudre rapidement."
            }
        ],
        "non_preferred_output": [
            {
                "role": "assistant",
                "content": "Ça marche très bien chez tout le monde. Avez-vous essayé de redémarrer votre ordinateur ?"
            }
        ]
    },
    {
        "method": "dpo",
        "input": [
            {"role": "system", "content": "Assistant support client bienveillant."},
            {"role": "user", "content": "Je veux un remboursement."}
        ],
        "preferred_output": [
            {
                "role": "assistant",
                "content": "Je comprends votre demande. Pouvez-vous me donner votre numéro de commande ? Je vais vérifier votre éligibilité au remboursement et vous guider dans la procédure."
            }
        ],
        "non_preferred_output": [
            {
                "role": "assistant",
                "content": "Les remboursements ne sont pas possibles après 14 jours. Lisez les CGV."
            }
        ]
    }
]

with open("dpo_training.jsonl", "w", encoding="utf-8") as f:
    for paire in paires:
        f.write(json.dumps(paire, ensure_ascii=False) + "\n")

print(f"Fichier DPO créé : {len(paires)} paires")

Lancer le job

L’upload ne change pas ; c’est le paramètre method passé à la création du job qui bascule l’entraînement en mode DPO.

from openai import OpenAI

client = OpenAI()

# Upload du fichier DPO
fichier = client.files.create(
    file=open("dpo_training.jsonl", "rb"),
    purpose="fine-tune"
)

# Créer le job avec la méthode DPO
job = client.fine_tuning.jobs.create(
    training_file=fichier.id,
    model="gpt-5.6-luna",
    method={
        "type": "dpo",
        "dpo": {
            "hyperparameters": {
                "beta": 0.1  # Contrôle la force de la préférence
            }
        }
    },
    suffix="dpo-support-v1"
)

print(f"Job DPO : {job.id}")

Le beta contrôle la force de la régularisation DPO, c’est-à-dire la liberté que vous laissez au modèle de s’écarter de son comportement d’origine. Un beta faible, entre 0.05 et 0.1, autorise le modèle à s’éloigner davantage du modèle de base pour suivre vos préférences : le changement est net, mais vous risquez d’emporter au passage des qualités que vous n’aviez pas l’intention de toucher. Un beta élevé, entre 0.2 et 0.5, maintient le modèle plus proche du modèle de base et produit des changements conservateurs — le bon réglage quand vous corrigez une inflexion de ton sur un modèle qui, par ailleurs, vous convient.

Construire des paires exploitables

La qualité d’un corpus DPO se juge sur les réponses non préférées bien plus que sur les préférées. Les deux réponses doivent être plausibles : si la non préférée est absurde, le modèle apprend à éviter l’absurdité, ce qu’il savait déjà faire, et vous n’avez rien obtenu. La différence doit donc être claire sans être caricaturale, et porter sur le critère que vous voulez vraiment enseigner. Variez ensuite les types de situations couvertes, faute de quoi votre modèle appliquera la préférence apprise à un contexte et à un seul.

La cohérence des jugements est l’autre moitié du travail, et elle se prépare avant la première paire. Définissez explicitement vos critères de préférence, faites évaluer par plusieurs personnes et ne gardez que les paires sur lesquelles elles sont d’accord — un désaccord entre évaluateurs signale une paire ambiguë, dont le modèle ne tirera qu’un signal contradictoire. Conservez enfin la trace écrite de ces critères. À la prochaine itération, menée par d’autres relecteurs, vous jugerez sur la même base au lieu de rejouer la discussion depuis le début.

Une dernière remarque sur l’enchaînement des méthodes. La stratégie la plus efficace consiste souvent à ne pas choisir : un fine-tuning supervisé d’abord, pour enseigner le format et le style de base, puis un DPO appliqué sur le modèle déjà fine-tuné pour en affiner les nuances. Chacune fait ce qu’elle sait faire, dans l’ordre où c’est utile.

Points clés à retenir

• Le DPO enseigne au modèle à préférer certaines réponses sur d’autres
• Le format utilise des paires preferred/non_preferred
• Le paramètre beta contrôle l’équilibre entre préférences et stabilité
• Le DPO est idéal pour les nuances de ton, la sécurité et l’alignement
• Combiner SFT puis DPO donne souvent les meilleurs résultats