Multi-LLM PbRL

Multi-agent PbRL entraîne les agents collaboratifs LLM à partir des préférences entre leurs réponses conjointes. CoMLRL construit les données de préférence à partir des éléments de tâche et les apprend avec l’un des deux algorithmes : MARLHF s’adapte à un modèle de récompense conjoint et entraîne ensuite les politiques avec RL, tandis que MADPO optimise directement les politiques à partir des préférences. MARLHFTrainer, MADPOTrainer et leurs variantes itératives MARLHFIterTrainer et MADPOIterTrainer sont disponibles à partir de comlrl.trainers.preference.

Les quatre trainers nécessitent actuellement num_turns=1 et des réponses conjointes alignées (joint_mode="aligned"). Une itération de l’algorithme trainers est une phase de collecte et d’entraînement de données, et non une tourn de dialogue.

Données de préférence#

Chaque agent \( i\in\mathcal{I}=\{1,\ldots,n\} \) échantillonne \( a_{i,t}\sim\pi_{\theta_i}(\cdot\mid h_{i,t}) \) de son historique local, et les réponses forment l’action conjointe \( \mathbf{a}_t=\{a_{1,t},\ldots,a_{n,t}\} \) avec l’historique conjoint \( \mathbf{h}_t \). Avec une seule tourn (\( H=1 \)), \( h_{i,0} \) est la requête de \( i \) et \( \mathbf{a}_0 \) est la réponse conjointe.

Les utilisateurs fournissent des éléments de tâche, et non des données de préférence. L’échantillon trainers obtient des réponses conjointes, les évalue avec une fonction oracle, et transforme les scores en paires de préférence.

Fonction oracle#

La fonction oracle évalue chaque réponse conjointe avec une valeur partagée. Par défaut, il s’agit de la récompense de la tâche reward_func, après l’optionnel reward_processor; elle peut suivre des règles ou appeler un modèle de récompense LLM, comme décrit dans Initialisation de l’entraînement. Les deux algorithmes apprennent uniquement à partir de la réponse conjointe qui gagne, de sorte que les valeurs de score ne comptent que pour choisir des paires. Dans MARLHFIterTrainer, preference_scoring_reward="reward_model" fait que le modèle de récompense le plus récemment ajusté soit l’oracle pour de nouvelles comparaisons, avec la récompense de la tâche comme sauvegarde jusqu’à ce qu’il existe.

Critère de préférence#

Pour chaque élément de tâche, chaque agent échantillonne les réponses preference_num_candidates à sa requête, et les réponses avec le même index candidat forment une réponse conjointe. Parmi deux réponses conjointes avec des scores différents, celle avec le score le plus élevé est préférée : elle est la gagnante \( w \), et l’autre est la perdante \( l \). Les égalités sont rejetées. pair_selection et preference_pairs_per_sample décident quelles paires chaque tâche conserve. Dans l’entraînement itératif, chaque comparaison est au lieu entre la réponse conjointe des agents actuels et la réponse conjointe du comparateur au même index candidat, et chaque côté peut gagner.

Format des données#

Une paire \( (\mathbf{h}_H^{w},\mathbf{h}_H^{l}) \) contient les deux historiques de réponse conjointe d’une tâche. Chaque paire est un enregistrement comme suit, avec une entrée par agent dans chaque liste:

{
  "prompts": ["<agent 1 prompt>", "<agent 2 prompt>"],
  "winner_completions": ["<agent 1 response>", "<agent 2 response>"],
  "loser_completions": ["<agent 1 response>", "<agent 2 response>"],
  "winner_reward": 0.92,
  "loser_reward": 0.41,
  "candidate_reward_mean": 0.63,
  "raw_rewards": [0.92, 0.41],
  "target_raw_reward": 0.92,
  "comparator_raw_reward": 0.41
}

winner_reward et loser_reward sont les scores oracle des deux réponses conjointes, et candidate_reward_mean est le score moyen des candidats comparés pour la tâche. Les trois derniers champs proviennent de l’entraînement itératif : raw_rewards contient les scores du gagnant et du perdant avant reward_processor, et target_raw_reward et comparator_raw_reward contiennent ceux des agents et du comparateur actuels. L’itération trainers écrit les paires de chaque tour dans iteration_0001.json, iteration_0002.json, etc., sous preference_replay_dir, comme {"iteration": 1, "num_pairs": ..., "pairs": [...]}.

Pipeline d’entraînement#

L’entraînement d’un système multi-agent coopératif basé sur LLM avec PbRL alterne entre la collecte de données de préférence auprès des agents actuels et l’apprentissage à partir de celles-ci avec MARLHF ou MADPO.

• Base trainers (MARLHFTrainer, MADPOTrainer) collectent les paires une seule fois, puis entraînent sur celles-ci. Si aucune tâche ne produit une paire non liée, l’entraînement se termine sans mettre à jour les politiques.
• Boucle trainers (MARLHFIterTrainer, MADPOIterTrainer) répète le cycle pour num_iterations tours. Le tour \( \nu \) compare les agents actuels avec le comparateur, stocke les nouveaux paires comme \( \mathcal{D}^{(\nu)} \), permet au tampon de relecture de sélectionner les paires d’entraînement \( \mathcal{B}^{(\nu)} \) de ce tour et des tours précédents, et les utilise pour l’entraînement. MADPO effectue ses mises à jour pour num_train_epochs par tour. MARLHF ajuste un modèle de récompense nouvellement initialisé sur ces données, puis exécute l’apprentissage de la politique.

L’évaluation échantillonne toujours à partir des politiques actuelles et les évalue avec la récompense de la tâche (reward_func et reward_processor), et non avec un modèle de récompense appris.

Comparateur#

Dans l’entraînement itératif, le comparateur fournit le côté de chaque comparaison. Les agents actuels et le comparateur répondent à la même tâche, et chaque comparaison avec un vainqueur clair sous la fonction oracle devient un couple, quel que soit le vainqueur.

comparator_policy choisit la source du comparateur:

• comparator_policy="current" (par défaut): Poids actifs actor, échantillonnés avec un flux de nombres aléatoires distinct.

• comparator_policy="current_copy": Poids actuels actor, copiés vers comparator_devices pour chaque phase de collecte lorsque ceux-ci diffèrent des appareils actor.

• comparator_policy="model": Modèles explicites de comparator_model_name ou comparator_agents.

• comparator_policy="history": Un point de contrôle actor sauvegardé de comparator_history_k itérations en arrière; la politique initiale jusqu’à ce qu’elle existe.

• comparator_policy="api": Un point de terminaison de modèle distant.

La source history sauvegarde automatiquement les points de contrôle de la politique. Les deux côtés peuvent échantillonner différents nombres de candidats; seuls les indices présents des deux côtés sont comparés, et pair_selection="comparator_reward" ne suppose pas que le comparateur gagne. Par défaut, le comparateur génère une réponse par rôle; avec comparator_generation_mode="centralized", un modèle de comparateur écrit chaque réponse du rôle dans une réponse conjointe, qui est analysée en réponses de rôle avant que les paires ne soient construites.

Les sources de modèles peuvent être des référentiels de modèles ou des points de contrôle locaux, comme décrit dans Entraîner les entités:

comparator_policy=model
comparator_model_name=/path/to/comparator-checkpoint
comparator_generation_mode=centralized
comparator_centralized_agent_index=0
comparator_devices=cuda:1

Comparateurs API#

Avec comparator_policy="api", le comparateur interroge un modèle distant. comparator_api_format sélectionne le format de la requête:

• comparator_api_format="generic" (par défaut): La requête inclut le prompt, l’index actor, l’élément de tâche, le nombre de candidats et les paramètres de génération; les complétions sont lues à partir de comparator_api_response_field.

• comparator_api_format="openai": Complétion de Chat, également utilisé par des points de terminaison compatibles tels que DeepSeek.

• comparator_api_format="anthropic": Messages d’Anthropic API (https://api.anthropic.com/v1/messages, ANTHROPIC_API_KEY).

• comparator_api_format="openai_responses" (alias responses ou codex): Réponses OpenAI API (https://api.openai.com/v1/responses, OPENAI_API_KEY).

Les formats Anthropic et Réponses n’ont pas de paramètre n, ils envoient donc une requête par candidat. Les requêtes utilisent les invites de comparateur centralisées ou décentralisées standard.

comparator_policy=api
comparator_api_format=anthropic
comparator_api_url=https://api.anthropic.com/v1/messages
comparator_api_model=claude-sonnet-4-20250514
comparator_api_key_env=ANTHROPIC_API_KEY

Tampon de relecture#

Le tampon de relecture sélectionne les paires stockées utilisées pour l’entraînement à chaque étape. L’ensemble de données de la phase actuelle est enregistré en premier, ce qui le rend éligible ainsi que les phases précédentes. preference_replay_mode définit quelles phases sont éligibles:

• preference_replay_mode="current" (par défaut): Toutes les paires de la phase actuelle, sans échantillonnage historique.

• preference_replay_mode="nearest_k": Les derniers ensembles de données non vides preference_replay_k, y compris le dernier.

• preference_replay_mode="all_history": Chaque ensemble de données non vide de la phase actuelle de l’exécution trainer.

• preference_replay_mode="lambda_decay": Le même historique, avec une pondération vers les phases récentes.

Chaque ligne du diagramme montre quelles phases un mode peut utiliser et comment chaque phase est pondérée, avec la phase la plus récente à droite.

nearest_k signifie les phases les plus récentes, et non la récupération par voisin le plus proche. Dans nearest_k et all_history, les ensembles de données éligibles ont le même poids, quel que soit leur taille, et les modes historiques y échantillonnent plutôt que d’entraîner sur toutes les paires stockées. Les paires ré-tokenisées sont récupérées à partir des fichiers de la phase enregistrée. Définir preference_replay_dir sur une phase antérieure ne importe pas ses fichiers, tandis que les points de contrôle d’entraînement restaurent l’index de relecture et ses données.

Décroissance de Lambda#

Avec l’âge, \( a=0 \) pour les plus récents des ensembles de données \( K \), preference_replay_lambda (\( \lambda \)) définit les poids de sélection :

\( \lambda=0 \) conserve uniquement le dernier ensemble de données, les valeurs plus petites favorisent les dernières itérations, et \( \lambda=1 \) attribue le même poids à chaque ensemble de données.

Échantillonnage#

Les modes historiques attribuent chaque tirage preference_replay_sample_size à un ensemble de données selon un poids, puis échantillonnent des paires au sein de chaque ensemble de données. L’échantillonnage se poursuit sans répétition lorsque le nombre attribué ne dépasse pas la taille de l’ensemble de données ; les nombres plus importants passent en revue des copies mélangées. L’échantillon combiné est mélangé. La taille d’échantillonnage par défaut est le nombre de paires de la dernière itération, ou la taille de l’ensemble de données non vide le plus récent si la dernière itération est vide.

current rejette preference_replay_sample_size et preference_replay_lambda et accepte preference_replay_k uniquement si None ou 1. La configuration suivante échantillonne 256 paires de toutes les rondes, avec une pondération vers les dernières :

from comlrl.trainers.preference import MADPOIterConfig

args = MADPOIterConfig(
    num_agents=2,
    preference_replay_mode="lambda_decay",
    preference_replay_lambda=0.8,
    preference_replay_sample_size=256,
)

MARLHFIterConfig accepte les mêmes options. Pour rejouer uniquement les dernières rondes, les utilisateurs peuvent définir preference_replay_mode="nearest_k" et le nombre de rondes via preference_replay_k.

MARLHF#

L’apprentissage par renforcement multi-agents à partir des retours humains (MARLHF) ajuste un modèle de récompense conjoint aux paires de préférences, puis entraîne les politiques avec RL sur le modèle de récompense appris. Étant donné que le modèle de récompense évalue la réponse complète de l’équipe, des modèles actors apprennent à partir d’une récompense partagée.

Apprentissage de la récompense#

Le JointRewardModel \( \widetilde{R}_{\psi}(\mathbf{h}_t,\mathbf{a}_t) \) lit les invites et les réponses de tous les agents en tant que texte et applique une tête scalaire à l’état caché final du causal-LM backbone à la dernière position non-remplie token. Il minimise la perte de Bradley–Terry sur les paires d’entraînement \( \mathcal{B} \):

où \( \sigma \) est la fonction sigmoïde. La perte augmente la note du gagnant par rapport à la note du perdant ; elle ne se régresse pas vers les récompenses de la tâche. Entités d’entraînement décrit comment le modèle de récompense est chargé.

Apprentissage de la politique#

Après l’apprentissage de la récompense, \( \widetilde{R}_{\psi} \) est fixé et remplace la récompense de la tâche. Les politiques échantillonnent de nouvelles réponses conjointes pour chaque tâche, \( \widetilde{R}_{\psi} \) les évaluent sans gradients, et un MARL backend met à jour la politique de chaque agent pour maximiser le retour appris :

rl_algorithm sélectionne le backend :

• rl_algorithm="magrpo" (par défaut) : MAGRPO, avec une base de moyenne de groupe.

• rl_algorithm="mareinforce" : MAREINFORCE, avec des retours bruts.

• rl_algorithm="marloo" : MARLOO, avec une base de leave-one-out.

• rl_algorithm="maremax" : MAReMax, avec une base de maximum de groupe.

• rl_algorithm="maac": MAAC, avec un modèle centralisé critic.

• rl_algorithm="iac": IAC, avec-actor critics ou fixé value heads.

Réponse conjointe REINFORCE et Réponse conjointe Actor-Critic décrivent ces mises à jour, avec \( \widetilde{R}_{\psi}(\mathbf{h}_t,\mathbf{a}_t) \) à la place du modèle de récompense \( r_t \). La régularisation de référence optionnelle (KL, reference_kl_enabled, reference_kl_coef, reference_devices) s’applique uniquement à l’apprentissage de la politique : l’estimation de KL échantillée par chaque agent, mise à l’échelle par reference_kl_coef, est soustraite du signal de récompense.

reward_model_name est requis lorsque les objets de modèle actors n’ont pas d’identifiant de modèle. MAAC et critic séparés IAC nécessitent également des sources critic explicites ou un identifiant de modèle critic utilisable.

MADPO#

L’optimisation directe des préférences multi-agents (MADPO) entraîne les politiques directement à partir des paires de préférences, sans modèle de récompense ni étape RL. Sa fonction de perte combine toutes les préférences des agents margins, de sorte que chaque politique apprend de l’issue de l’équipe.

La margin de chaque agent est la différence entre ses probabilités logarithmiques des réponses gagnantes et perdantes, et la margin additionne ces valeurs pour tous les agents:

MADPO minimise

où \( \eta>0 \) est dpo_beta (par défaut 0,1). La récompense de la tâche ne commande qu’à chaque paire; la perte utilise les probabilités logarithmiques des politiques. Le gradient pour l’agent \( i \) est

Le poids \( \sigma(-\eta\,\Delta_{\boldsymbol{\theta}}) \) dépend de la réponse conjointe de l’équipe margin, tandis que le gradient ne traverse que la propre margin de l’agent \( i \). Dans chaque lot, le trainer calcule toutes les margins une fois sans gradients, puis met à jour chaque agent avec sa propre fonction différentiable margin plus les margins détachées des autres

L’objectif est sans référence : les paramètres hérités reference_kl_enabled, reference_kl_coef et reference_devices n’ajoutent aucun terme de référence à la perte MADPO. Les métriques d’entraînement turn_1/reward_mean et turn_1/expected_return calculent la moyenne des récompenses candidates enregistrées lors de la collecte des paires, de sorte qu’elles ne reflètent pas les politiques mises à jour

Le scoreur décentralisé exclut la dernière complétion token après avoir supprimé les rembourrages, de sorte que la probabilité logarithmique de chaque agent margin omet cette token. Le scoreur centralisé couvre la complétion conjointe complète