DPO vs RLHF : pourquoi l’optimisation directe des préférences gagne pour les petites équipes

Si tu es une petite équipe essayant d’aligner un modèle de langage, RLHF est probablement excessif. DPO fait le même travail avec moins d’infrastructure, moins de calcul et moins de pièces mobiles. Voici pourquoi.

Le problème du pipeline RLHF

RLHF nécessite trois modèles exécutés simultanément : le modèle de langage que tu entraînes, un modèle de récompense entraîné sur les préférences humaines et un modèle de référence pour les contraintes de divergence KL. Tu dois d’abord entraîner le modèle de récompense, puis l’utiliser pour générer des signaux de récompense pour l’entraînement PPO du modèle de langage.

Pour les opérations à l’échelle d’OpenAI, ce pipeline est gérable. Pour une équipe de trois personnes avec quelques GPU, c’est un cauchemar. Le modèle de récompense seul exige un calcul significatif pour l’entraîner et le valider. L’entraînement PPO est notoirement instable. L’espace des hyperparamètres est énorme. Et le débogage exige de comprendre l’interaction entre trois modèles distincts.

La plupart des petites équipes qui tentent RLHF passent plus de temps à combattre l’infrastructure qu’à améliorer leur modèle. Ce n’est pas une bonne utilisation des ressources limitées.

Ce que DPO change

DPO élimine entièrement le modèle de récompense. Au lieu d’entraîner un modèle séparé pour prédire les préférences humaines puis utiliser ces prédictions pour entraîner le modèle de langage, DPO utilise les données de préférence directement. Le modèle de langage lui-même sert de modèle de récompense implicite.

Les maths sont élégantes. DPO réparamètre l’objectif RLHF pour montrer que la politique optimale sous RLHF peut être exprimée comme une simple fonction des propres probabilités logarithmiques du modèle de langage. Aucun modèle de récompense séparé nécessaire. Pas de PPO. Pas d’instabilité.

En pratique, l’entraînement DPO ressemble à un fine-tuning supervisé avec une fonction de perte spéciale. Tu alimentes le modèle avec des paires de réponses — l’une préférée, l’autre non — et la fonction de perte ajuste les poids du modèle pour augmenter la probabilité de générer la réponse préférée par rapport à celle rejetée.

L’avantage des petites équipes

Pour les petites équipes, les avantages de DPO sont concrets et significatifs.

Réduction du calcul. DPO nécessite environ un tiers du calcul d’un entraînement RLHF équivalent. Tu entraînes un modèle au lieu de gérer trois. Pour les équipes fonctionnant sur des GPU de consommateur ou des budgets cloud limités, c’est la différence entre faisable et impossible.

Stabilité. L’entraînement PPO est notoirement capricieux. Les petits changements dans les hyperparamètres peuvent produire des résultats radicalement différents. L’entraînement DPO est stable. La fonction de perte est bien comportée. La sensibilité des hyperparamètres est faible. Tu peux itérer rapidement sans passer des jours à déboguer les instabilités d’entraînement.

Simplicité. Le pipeline RLHF a plusieurs modes de défaillance. Le modèle de récompense peut être mal étalonné. La contrainte KL peut être trop serrée ou trop desserrée. L’optimisation PPO peut diverger. DPO a un mode de défaillance : les mauvaises données. Corrige les données, corrige le modèle.

Itération plus rapide. Avec DPO, tu peux passer de nouvelles données de préférence à un modèle entraîné en heures au lieu de jours. Cela signifie plus d’expériences, des boucles de retour plus rapides et une amélioration plus rapide. Pour les petites équipes, la vitesse d’itération est tout.

Quand RLHF a encore du sens

DPO n’est pas strictement supérieur. RLHF a des avantages dans des contextes spécifiques.

Réutilisation du modèle de récompense. Si tu as besoin d’évaluer plusieurs modèles différents par rapport aux mêmes critères de préférence, entraîner un modèle de récompense une fois et le réutiliser est efficace. DPO nécessite une réentraînement pour chaque modèle.

Apprentissage en ligne. RLHF peut incorporer les nouveaux retours en temps réel via le modèle de récompense. DPO nécessite un réentraînement par lot. Pour les applications qui ont besoin d’une adaptation continue, RLHF est plus flexible.

Échelle. À très grande échelle, la complexité supplémentaire de RLHF est amortie sur les budgets de calcul massifs. Le modèle de récompense devient une ressource partagée. L’instabilité de PPO est gérée par de grandes équipes de spécialistes. Si tu es Google ou Anthropic, la surcharge est gérable.

Mais pour tous les autres — les startups, les laboratoires de recherche, les chercheurs indépendants, les projets open source — DPO est le choix pragmatique.

La mise en garde sur la qualité des données

La simplicité de DPO met toute la pression sur la qualité des données. Avec RLHF, un modèle de récompense médiocre peut partiellement compenser les données de préférence bruyantes. Avec DPO, garbage in signifie garbage out. Il n’y a pas de modèle intermédiaire pour lisser les choses.

C’est en réalité une caractéristique, pas un bug. Cela force les petites équipes à se concentrer sur ce qui importe le plus : la qualité de leurs données d’entraînement. Un petit dataset DPO soigneusement organisé surpassera un grand dataset bruyant. Le coût par paire est plus élevé. Le coût total est dramatiquement plus bas. Et les résultats sont meilleurs.

Chez Laeka, nous avons découvert que 500-1000 paires DPO de haute qualité, annotées par des praticiens contemplatifs avec des explications diagnostiques, produisent un meilleur alignement que 50 000 paires crowdsourcées. Le coût par paire est plus élevé. Le coût total est dramatiquement plus bas. Et les résultats sont meilleurs.

Commencer

Si tu es une petite équipe envisageant un entraînement à l’alignement, voici le chemin pratique.

Commence avec un modèle de base que tu veux aligner. Qwen, Llama, Mistral — n’importe quoi qui correspond à ton cas d’utilisation. Génère des réponses à tes prompts cibles. Fais évaluer les paires de réponses par des humains et indique la préférence, avec de brèves explications du pourquoi. Formate les données en triplets DPO : prompt, réponse choisie, réponse rejetée.

Utilise la bibliothèque TRL de HuggingFace. Elle a un entraîneur DPO qui fonctionne directement. Définis ton paramètre bêta entre 0,1 et 0,5 (commence par 0,1). Entraîne pendant 1-3 epochs. Évalue. Itère.

Tout le processus peut s’exécuter sur un seul A100 ou même un GPU de consommateur avec QLoRA. Aucune infrastructure de modèle de récompense. Pas de maux de tête PPO. Pas de pipeline à trois modèles. Juste des données, une fonction de perte et un modèle qui s’améliore mesurément.

DPO ne résoudra pas tous tes problèmes d’alignement. Mais pour les petites équipes, il résout les bons aux bons coûts. Commence là. Augmente l’échelle si tu dois. La plupart des équipes n’auront pas besoin.

Laeka Research — laeka.org