Optimisation des préférences

Cette skill suppose que finetuning-method-selection a déjà routé ici parce que la forme des données est des paires de préférences ou du feedback thumbs-up/down non apparié, pas des démonstrations (c'est lora-qlora-recipes) ni un signal de récompense vérifiable (c'est grpo-rlvr-training). Ce qui suit est la sélection de méthode au sein de la famille DPO, les preuves de l'importance réelle de cette sélection, le motif d'entraînement en production, et comment construire les paires en premier lieu.

Entrée : une décision de routage (optimisation des préférences) plus des paires de préférences ou du feedback non apparié, généralement à partir d'un checkpoint SFT. Format de sortie : un choix de méthode validé plus une config — les valeurs kwargs dans references/method-configs.md, pas du conseil libre — que llm-finetuning-training-engineer consomme directement.

Sélection de méthode

• DPO est le défaut sûr. Utilisez β=0.1 et un taux d'apprentissage de 5e-7 à 1e-6 pour 1–2 epochs. Ce LR est inférieur au LR SFT qui a produit le checkpoint aligné — porter un LR à l'échelle SFT dans une exécution DPO est la misconfiguration la plus courante ici, pas un cas limite.
• ORPO route quand la mémoire est la contrainte, ou quand il n'y a pas de checkpoint SFT séparé pour commencer — c'est sans référence et fusionne les objectifs SFT et préférence en une loss, en sautant le pass SFT séparé et le coût mémoire du modèle de référence que DPO entraîne.
• KTO route quand le feedback est un signal binaire non apparié (thumbs-up/down) plutôt que des paires de préférences appariées — ne forcez pas le feedback non apparié dans des paires synthétiques pour utiliser DPO à la place.
• SimPO corrige le biais de longueur de DPO mais ne rapporte que avec un sweeping discipliné — ses gains publiés sont un plafond rapporté sous un sweep accordé, pas une baseline qu'une seule config reproduira. Routez ici seulement quand il y a un budget de sweep; utilisez DPO sinon.
• RLHF classique (reward model + PPO) est retiré en dehors des labs de la frontier. N'y recourez pas dans un pipeline en production — chaque méthode ci-dessus est moins chère et mieux supportée pour les mêmes formes de données.

Exemples travaillés

• "Nous avons un checkpoint SFT et des données de préférences appariées et propres, pas de plainte sur le biais de longueur pour l'instant." → cas par défaut → DPO à β=0.1.
• "Les relecteurs cliquent thumbs-up/down par réponse; rien n'est apparié." → signal non apparié → KTO, pas DPO — ne synthétisez pas de paires pour forcer DPO sur des données non appariées.
• "Le budget GPU ne couvre pas un pass SFT séparé plus un modèle de référence DPO." → limité par la mémoire, pas de checkpoint séparé → ORPO.
• "La sortie DPO favorise les réponses plus longues quel que soit la qualité, et il y a du temps pour exécuter un sweep." → biais de longueur plus budget de sweep → SimPO. Sautez-le si le budget de sweep n'est pas vraiment là.

La vérité à faible levier

Une étude de 240-H100 en 2026 (arXiv 2603.19335) est l'evidence critère derrière le tableau ci-dessus: le choix de loss vaut environ 1 point de pourcentage de levier, l'échelle du modèle vaut environ 50. Zéro des 20 variantes DPO testées ont surpassé le vanilla DPO. Les classements s'inversent aussi avec l'échelle — une variante gagnante dans un petit pilot peut perdre à la taille en déploiement.

Deux conséquences pratiques :

• Ne dépensez pas une décision de routage en agonisant sur des bake-offs de variantes DPO. Le tableau ci-dessus est suffisant; la sélection plus profonde de variantes est peu levier comparée à la qualité des données et l'échelle.
• Validez à l'échelle de déploiement avant de faire confiance à un classement. Une exécution de comparaison de méthode sur un petit modèle pilot ne transfère pas à la classe de taille en production — revérifiez le gagnant une fois que l'échelle change.

C'est aussi pourquoi le tableau Sélection de méthode ci-dessus est délibérément court : il code le ~1pp de levier, pas un classement des variantes DPO que la même étude montre ne tient pas à travers l'échelle. Traitez tout conseil de sélection de variante qui n'est pas dans ce tableau — y compris le conseil qui prétend qu'une variante spécifique "gagne" — comme non prouvé jusqu'à ce qu'il soit validé à la taille de déploiement cible.

Motif en production : DPO itérative on-policy

Un single pass DPO hors-ligne sur un dataset de préférences statique est un point de départ, pas le motif en production. La policy dérape loin de la distribution à partir de laquelle les paires ont été échantillonnées au fur et à mesure que l'entraînement procède, et un dataset statique devient stale par rapport à cette dérive. Les pipelines en production exécutent DPO de façon itérative et on-policy à la place :

1. Échantillonnez des completions à partir du checkpoint de policy courant.
2. Notez ou classez les completions (reward model, juge, ou task grader).
3. Exécutez un pass DPO en utilisant le checkpoint courant comme modèle de référence.
4. Le checkpoint résultant devient à la fois la nouvelle policy et la nouvelle référence pour le prochain round.

Répétez. Le modèle de référence de chaque round est la sortie du round précédent, pas un checkpoint initial fixe — c'est ce qui garde le signal de préférence on-policy au lieu de scorer contre une distribution de plus en plus stale.

Un pass DPO single est toujours une itération raisonnable en premier lieu — ce n'est juste pas tout le pipeline. Planifiez au moins un autre round une fois que le premier checkpoint existe, plutôt que de traiter le pass un comme l'artefact fini.

Construction de paires

Construisez des paires DPO/ORPO à partir de trajectoires same-task passing-vs-failing — deux tentatives à la même task sous-jacente, pas des exemples best-and-worst non-liés tirés de différentes tasks. Dans cet ensemble de trajectoires, sélectionnez le membre rejeté à μ−2σ de la distribution de récompense, jamais le minimum. La construction naive de paires best-vs-worst (récompense max vs. minimum absolu) se dégrade à mesure que l'échelle augmente; la sélection μ−2σ est plus robuste à la même sensibilité à l'échelle que l'étude à faible levier a soulevée ci-dessus.

sorted_by_reward = sort(trajectories, key=reward)
chosen   = sorted_by_reward[-1]                # highest reward
mu, sigma = mean(rewards), stdev(rewards)
rejected = closest(sorted_by_reward, mu - 2 * sigma)
# NOT sorted_by_reward[0] — the absolute minimum
# is the naive best-vs-worst construction that
# degrades as scale increases.

Pour la mécanique de la transformation des traces notées en ces paires — y compris le rejection sampling et la sélection delta notée par juge — voir trace-to-training-data.

Références

Blocs de config TRL complets par méthode — DPOConfig, ORPOConfig, KTOConfig, et la grille de sweep SimPO — plus les wrappers Unsloth et une note de catastrophic-forgetting vivent dans references/method-configs.md. Ces configs utilisent les mêmes conventions d'API TRL actuelle établies dans le references/unsloth-trl-mapping.md de lora-qlora-recipes (processing_class, pas tokenizer=).

references/method-configs.md porte aussi la note catastrophic-forgetting : un taux d'apprentissage trop haut est la cause habituelle quand un checkpoint accordé aux préférences perd la capacité générale, et la correction est presque toujours de baisser le LR vers le bas de la plage dans le tableau Sélection de méthode ci-dessus avant de recourir à toute autre remédiation.

Skills liées : finetuning-method-selection route ici une fois que des paires de préférences ou du feedback non apparié existent ; lora-qlora-recipes produit le checkpoint SFT que DPO/KTO/SimPO alignent (le chemin fusionné ORPO peut le sauter) ; trace-to-training-data convertit les trajectoires passing/failing en paires que la section Pair Construction de cette skill consomme.