Multi-LLM PbRL

Multi-agente PbRL entrena agentes colaborativos LLM a partir de preferencias entre sus respuestas conjuntas. CoMLRL construye los datos de preferencia a partir de elementos de la tarea y aprende con uno de dos algoritmos: MARLHF ajusta un modelo de recompensa conjunto y luego entrena las políticas con RL, mientras que MADPO optimiza las políticas directamente a partir de las preferencias. MARLHFTrainer, MADPOTrainer, y sus variantes iterativas MARLHFIterTrainer y MADPOIterTrainer están disponibles de comlrl.trainers.preference.

Todas las cuatro instancias de trainers requieren actualmente num_turns=1 y respuestas conjuntas alineadas (joint_mode="aligned"). Una iteración del trainers es una ronda de recopilación de datos y entrenamiento, no un turno de diálogo.

Datos de preferencia#

Cada agente \( i\in\mathcal{I}=\{1,\ldots,n\} \) muestrea \( a_{i,t}\sim\pi_{\theta_i}(\cdot\mid h_{i,t}) \) de su historial local, y las respuestas forman la acción conjunta \( \mathbf{a}_t=\{a_{1,t},\ldots,a_{n,t}\} \) con el historial conjunto \( \mathbf{h}_t \). Con un solo turno (\( H=1 \)), \( h_{i,0} \) es la instrucción del agente \( i \) y \( \mathbf{a}_0 \) es la respuesta conjunta.

Los usuarios proporcionan elementos de tarea, no datos de preferencia. La muestra trainers recopila respuestas conjuntas, las puntúa con una función de oráculo y convierte las puntuaciones en pares de preferencia.

Función de oráculo#

La función de oráculo puntúa cada respuesta conjunta con un valor compartido. Por defecto, es la recompensa de la tarea reward_func, después de la opcional reward_processor; puede seguir reglas o llamar a un modelo de recompensa LLM, según se describe en Inicialización del entrenamiento. Ambos algoritmos aprenden solo de qué respuesta conjunta gana, por lo que los valores de la puntuación solo importan para elegir pares. En MARLHFIterTrainer, preference_scoring_reward="reward_model" hace que el modelo de recompensa más recientemente ajustado sea el oráculo para nuevas comparaciones, con la recompensa de la tarea como respaldo hasta que exista uno.

Criterio de preferencia#

Para cada elemento de tarea, cada agente muestrea las respuestas preference_num_candidates a su instrucción, y las respuestas con el mismo índice candidato forman una respuesta conjunta. De cualquier par de respuestas conjuntas con diferentes puntuaciones, la de puntuación más alta se prefiere: es el ganador \( w \), y la otra es el perdedor \( l \). Los empates se descartan. pair_selection y preference_pairs_per_sample deciden qué pares conserva cada tarea. En el entrenamiento iterativo, cada comparación es en cambio entre la respuesta conjunta de los agentes actuales y la respuesta conjunta del comparador en el mismo índice candidato, y cualquiera de los dos puede ganar.

Formato de datos#

Un par \( (\mathbf{h}_H^{w},\mathbf{h}_H^{l}) \) contiene los dos historiales conjuntos de una tarea. Cada par es un registro como el siguiente, con una entrada por agente en cada lista:

{
  "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 y loser_reward son las puntuaciones de referencia de las dos respuestas conjuntas, y candidate_reward_mean es la puntuación media de los candidatos comparados para la tarea. Los tres campos finales provienen del entrenamiento iterativo: raw_rewards contiene las puntuaciones del ganador y el perdedor antes de reward_processor, y target_raw_reward y comparator_raw_reward contienen las de las muestras de los agentes actuales y la muestra del comparador. La iterativa trainers escribe cada par de rondas en iteration_0001.json, iteration_0002.json, y así sucesivamente bajo preference_replay_dir, como {"iteration": 1, "num_pairs": ..., "pairs": [...]}.

Pipeline de entrenamiento#

Entrenar un sistema multi-agente cooperativo con LLM-basado en PbRL alterna entre recopilar datos de preferencias de los agentes actuales y aprender de ellos con MARLHF o MADPO.

• Base trainers (MARLHFTrainer, MADPOTrainer) recopilan los pares una vez, luego entrenan con ellos. Si ninguna tarea produce un par sin empate, el entrenamiento devuelve sin actualizar las políticas.
• Iterativo trainers (MARLHFIterTrainer, MADPOIterTrainer) repite el ciclo para num_iterations rondas. La ronda \( \nu \) compara los agentes actuales con el comparador, almacena las nuevas parejas como \( \mathcal{D}^{(\nu)} \), permite que el buffer de re-petición seleccione los pares de entrenamiento \( \mathcal{B}^{(\nu)} \) de esta y rondas anteriores, y los utiliza para el entrenamiento. MADPO ejecuta sus actualizaciones para num_train_epochs por ronda. MARLHF ajusta un modelo de recompensa recién inicializado en ellos y luego ejecuta el aprendizaje de políticas.

La evaluación siempre muestrea a partir de las políticas actuales y las califica con la recompensa de la tarea (reward_func y reward_processor), nunca con un modelo de recompensa aprendido.

Comparador#

En el entrenamiento iterativo, el comparador proporciona el otro lado de cada comparación. Los agentes y el comparador actuales responden a la misma tarea, y cada comparación con el mismo índice con un ganador claro bajo la función oracle se convierte en una pareja, sin importar qué lado gane.

comparator_policy elige la fuente del comparador:

• comparator_policy="current" (predeterminado): Pesos activos de actor, muestreados con un flujo de números aleatorios separado.

• comparator_policy="current_copy": Pesos actuales de actor, copiados a comparator_devices para cada fase de recopilación cuando difieren de los dispositivos actor.

• comparator_policy="model": Modelos explícitos de comparator_model_name o comparator_agents.

• comparator_policy="history": Un punto de control actor guardado de comparator_history_k iteraciones atrás; la política inicial hasta que exista.

• comparator_policy="api": Un punto final de modelo remoto.

La fuente history guarda puntos de control de política automáticamente. Los dos lados pueden muestrear diferentes números de candidatos; solo los índices presentes en ambos lados se comparan, y pair_selection="comparator_reward" no asume que el comparador gana. Por defecto, el comparador genera una respuesta por rol; con comparator_generation_mode="centralized", un modelo de comparador escribe cada respuesta del rol en una única respuesta conjunta, que se analiza en respuestas de rol antes de construir parejas.

Las fuentes de modelos pueden ser repositorios de modelos o puntos de control locales, según se describe en Entrenar Entidades:

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

API Comparadores#

Con comparator_policy="api", el comparador consulta un modelo remoto. comparator_api_format selecciona el formato de la solicitud:

• comparator_api_format="generic" (predeterminado): La solicitud incluye el prompt, índice actor, elemento de tarea, número de candidatos y configuraciones de generación; las respuestas se leen de comparator_api_response_field.

• comparator_api_format="openai": Completaciones de Chat, también utilizadas por puntos finales compatibles como DeepSeek.

• comparator_api_format="anthropic": Mensajes de Anthropic API (https://api.anthropic.com/v1/messages, ANTHROPIC_API_KEY).

• comparator_api_format="openai_responses" (alias responses o codex): Respuestas de OpenAI API (https://api.openai.com/v1/responses, OPENAI_API_KEY).

Los formatos Anthropic y Respuestas no tienen el parámetro n, por lo que envían una solicitud por cada candidato. Las solicitudes utilizan las indicaciones estándar centralizadas o descentralizadas.

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

Buffer de reproducción#

El buffer de reproducción selecciona las parejas almacenadas utilizadas para el entrenamiento en cada ronda. El conjunto de datos de la ronda actual se guarda primero, por lo que es elegible junto con rondas anteriores. preference_replay_mode establece qué rondas son elegibles:

• preference_replay_mode="current" (predeterminado): Todas las parejas del conjunto de datos actual, sin muestreo histórico.

• preference_replay_mode="nearest_k": Los últimos conjuntos de datos de rondas no vacías de preference_replay_k, incluyendo el actual.

• preference_replay_mode="all_history": Cada conjunto de datos no vacío de la ronda actual de la ejecución trainer.

• preference_replay_mode="lambda_decay": La misma historia, con un peso hacia rondas recientes.

Cada fila del diagrama muestra qué conjuntos de datos de ronda puede utilizar un modo y con qué fuerza se ponderan, con la ronda más reciente a la derecha.

nearest_k significa las rondas más recientes, no la recuperación de vecinos más cercanos. En nearest_k y all_history, los conjuntos de datos elegibles tienen el mismo peso independientemente de su tamaño, y los modos históricos muestrean de ellos en lugar de entrenar en cada pareja almacenada. Las parejas reproducidas se re-tokenizan a partir de los archivos de la ronda guardada. Establecer preference_replay_dir en una ejecución anterior solo no importa sus archivos, mientras que puntos de control de entrenamiento restauran el índice de reproducción y sus datos.

Decaimiento de Lambda#

Con la edad \( a=0 \) para los conjuntos de datos más recientes de \( K \), preference_replay_lambda (\( \lambda \)) establece los pesos de selección:

\( \lambda=0 \) conserva solo el conjunto de datos más reciente, los valores más pequeños favorecen las rondas más recientes, y \( \lambda=1 \) pondera cada conjunto de datos por igual.

Muestreo#

Los modos históricos asignan cada uno de los preference_replay_sample_size dibujos a un conjunto de datos según el peso, luego muestrean pares dentro de cada conjunto de datos. El muestreo continúa sin repetición cuando el número asignado no excede el tamaño del conjunto de datos; los números más grandes se alternan a través de copias aleatorias. La muestra combinada se mezcla. El tamaño de muestra predeterminado es el número de pares de la ronda actual, o el tamaño del conjunto de datos más reciente no vacío si la ronda actual está vacía.

current rechaza preference_replay_sample_size y preference_replay_lambda y acepta preference_replay_k solo como None o 1. La siguiente configuración, en cambio, muestrea 256 pares de todas las rondas, ponderados hacia las más recientes:

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 acepta las mismas opciones. Para reproducir solo las rondas más recientes, los usuarios pueden establecer preference_replay_mode="nearest_k" y el número de rondas a través de preference_replay_k.

MARLHF#

El Aprendizaje por Refuerzo Multiagente a partir de Retroalimentación Humana (MARLHF) ajusta un modelo de recompensa conjunta a los pares de preferencias, y luego entrena las políticas con RL utilizando la recompensa aprendida. Dado que el modelo de recompensa evalúa la respuesta completa del equipo, los actors aprenden a partir de una recompensa compartida.

Aprendizaje de Recompensas#

El JointRewardModel \( \widetilde{R}_{\psi}(\mathbf{h}_t,\mathbf{a}_t) \) lee todas las indicaciones y respuestas de los agentes como un solo texto y aplica una cabeza escalar al último estado oculto del causal-LM backbone en el último token no de relleno token. Minimiza la pérdida de Bradley–Terry sobre los pares de entrenamiento \( \mathcal{B} \):

donde \( \sigma \) es la función sigmoide. La pérdida eleva la puntuación del ganador en relación con la del perdedor; no regresa a las recompensas de la tarea. Entidades de Entrenamiento describe cómo se carga el modelo de recompensa.

Aprendizaje de Políticas#

Después del aprendizaje de recompensas, \( \widetilde{R}_{\psi} \) se fija y reemplaza la recompensa de la tarea. Las políticas muestrean nuevas respuestas conjuntas para cada tarea, \( \widetilde{R}_{\psi} \) las puntúan sin gradientes, y un MARL backend actualiza la política de cada agente para maximizar el retorno aprendido:

rl_algorithm selecciona el backend:

• rl_algorithm="magrpo" (por defecto): MAGRPO, con una base de media grupal.

• rl_algorithm="mareinforce": MAREINFORCE, con retornos brutos.

• rl_algorithm="marloo": MARLOO, con una base de leave-one-out.

• rl_algorithm="maremax": MAReMax, con una base de máximo grupal.

• rl_algorithm="maac": MAAC, con un modelo centralizado critic.

• rl_algorithm="iac": IAC, con-actor critics o adherido value heads.

Respuesta conjunta REINFORCE y Respuesta conjunta Actor-Critic describen estas actualizaciones, con \( \widetilde{R}_{\psi}(\mathbf{h}_t,\mathbf{a}_t) \) en lugar del modelo de recompensa \( r_t \). La regularización de referencia congelada opcional (KL, reference_kl_enabled, reference_kl_coef, reference_devices) se aplica solo al aprendizaje de la política: la estimación muestreada de KL de cada agente, escalada por reference_kl_coef, se resta de la señal de recompensa.

reward_model_name es requerido cuando actors son objetos de modelo sin identificador de modelo. MAAC y critic IAC también requieren fuentes critic explícitas o un identificador de modelo critic utilizable.

MADPO#

Optimización Directa de Preferencias Multi-Agente (MADPO) entrena las políticas directamente a partir de las parejas de preferencias, sin un modelo de recompensa ni una etapa RL. Su función de pérdida combina todas las preferencias de los agentes margins, de modo que cada política aprende del resultado del equipo.

La margin de cada agente es la diferencia entre sus probabilidades logarítmicas de las respuestas ganadora y perdedora, y la suma conjunta de margin de estas en todos los agentes:

MADPO minimiza

donde \( \eta>0 \) es dpo_beta (predeterminado 0.1). La recompensa de la tarea solo ordena cada par; la pérdida utiliza los log-probabilidades de las políticas. El gradiente para el agente \( i \) es

El peso \( \sigma(-\eta\,\Delta_{\boldsymbol{\theta}}) \) depende de la respuesta conjunta de margin, mientras que el gradiente fluye solo a través del \( i \)’s propio margin. En cada lote, trainer calcula todos los margins una vez sin gradientes, luego actualiza cada agente con su propio margin diferenciable más los margins desconectados de los demás

El objetivo es sin referencia: los ajustes heredados reference_kl_enabled, reference_kl_coef y reference_devices no añaden términos de referencia a la pérdida MADPO. Las métricas de entrenamiento turn_1/reward_mean y turn_1/expected_return promedian las recompensas candidatas registradas cuando se recopilaron los pares, por lo que no reflejan las políticas actualizadas

El puntaje descentralizado excluye la última finalización token después de recortar los rellenos, por lo que la log-probabilidad de cada agente margin omite ese token. El puntaje centralizado cubre la finalización conjunta completa