Multi-LLM PbRL

Multi-Agent PbRL trainiert kollaborierende LLM Agenten aus Präferenzen zwischen ihren gemeinsamen Antworten. CoMLRL erstellt die Präferenzdaten aus Aufgaben-Items und lernt daraus mit einem von zwei Algorithmen: MARLHF passt ein gemeinsames Belohnungsmodell an und trainiert dann die Richtlinien mit RL, während MADPO die Richtlinien direkt aus den Präferenzen optimiert. MARLHFTrainer, MADPOTrainer und ihre iterativen Varianten MARLHFIterTrainer und MADPOIterTrainer sind von comlrl.trainers.preference erhältlich.

Alle vier trainers benötigen derzeit num_turns=1 und eine abgestimmte gemeinsame Antwort (joint_mode="aligned"). Eine Iteration des iterativen trainers ist eine Runde der Datenerfassung und des Trainings, nicht ein Dialogschritt.

Präferenzdaten#

Jeder Agent \( i\in\mathcal{I}=\{1,\ldots,n\} \) entnimmt \( a_{i,t}\sim\pi_{\theta_i}(\cdot\mid h_{i,t}) \) aus seiner lokalen Historie, und die Antworten bilden die gemeinsame Aktion \( \mathbf{a}_t=\{a_{1,t},\ldots,a_{n,t}\} \) mit der gemeinsamen Historie \( \mathbf{h}_t \). Bei einem einzelnen Schritt (\( H=1 \)) ist \( h_{i,0} \) der Prompt von \( i \) und \( \mathbf{a}_0 \) ist die gemeinsame Antwort.

Benutzer geben Aufgaben ein, nicht Präferenzdaten. Das trainers entnimmt gemeinsame Antworten, bewertet sie mit einer Oracle-Funktion und wandelt die Bewertungen in Präferenzpaare um.

Oracle-Funktion#

Die Oracle-Funktion bewertet jede gemeinsame Antwort mit einem gemeinsamen Wert. Standardmäßig ist dies die Aufgabenbelohnung reward_func, nach der optionalen reward_processor; sie kann Regeln befolgen oder ein LLM Belohnungsmodell aufrufen, wie in Trainingsinitialisierung beschrieben. Beide Algorithmen lernen nur aus dem, welcher gemeinsame Antwort gewinnt, daher spielen die Werte nur bei der Auswahl von Paaren eine Rolle. In MARLHFIterTrainer macht preference_scoring_reward="reward_model" das zuletzt angepasste Belohnungsmodell zur Oracle für neue Vergleiche, wobei die Aufgabenbelohnung als Fallback verwendet wird, bis eines existiert.

Präferenzkriterium#

Für jedes Aufgabenitem entnimmt jeder Agent preference_num_candidates Antworten auf seinen Prompt, und Antworten mit dem gleichen Kandidatenindex bilden eine gemeinsame Antwort. Von zwei gemeinsamen Antworten mit unterschiedlichen Bewertungen wird die höher bewertete bevorzugt: sie ist der Gewinner \( w \) und die andere ist der Verlierer \( l \). Gleichstände werden verworfen. pair_selection und preference_pairs_per_sample entscheiden, welche Paare jede Aufgabe behalten. Bei iterativen Trainings ist jede Verknüpfung stattdessen zwischen der aktuellen gemeinsamen Antwort der Agenten und der gemeinsamen Antwort des Vergleichers mit dem gleichen Kandidatenindex, wobei jede Seite gewinnen kann.

Datenformat#

Ein Paar \( (\mathbf{h}_H^{w},\mathbf{h}_H^{l}) \) enthält die beiden gemeinsamen Historien einer Aufgabe. Jedes Paar ist ein Datensatz wie der folgenden, mit einem Eintrag pro Agent in jeder 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 und loser_reward sind die Oracle-Scores der beiden gemeinsamen Antworten, und candidate_reward_mean ist der Mittelwert der für die Aufgabe verglichenen Kandidaten. Die letzten drei Felder stammen aus iterativer Schulung: raw_rewards enthält die Scores des Gewinners und des Verlierers vor reward_processor, und target_raw_reward und comparator_raw_reward enthalten die Scores der aktuellen Agenten- und des Comparator-Samples. Die iterative trainers schreibt die Paare jeder Runde in iteration_0001.json, iteration_0002.json usw. unter preference_replay_dir, wie {"iteration": 1, "num_pairs": ..., "pairs": [...]}.

Trainingspipeline#

Training eines kooperativen LLM-basierten Mehr-Agenten-Systems mit PbRL wechselt zwischen dem Sammeln von Präferenzdaten von den aktuellen Agenten und dem Lernen daraus mit MARLHF oder MADPO.

• Basis trainers (MARLHFTrainer, MADPOTrainer) sammeln die Paare einmal und trainieren dann darauf. Wenn keine Aufgabe ein nicht-gleichzusammengeführtes Paar erzeugt, kehrt das Training ohne Aktualisierung der Richtlinien zurück.
• Iteratives trainers (MARLHFIterTrainer, MADPOIterTrainer) wiederholen den Zyklus für num_iterations Runden. Runde \( \nu \) vergleicht die aktuellen Agenten mit dem Vergleichsmechanismus, speichert die neuen Paare als \( \mathcal{D}^{(\nu)} \), lässt den Wiedergabepuffer die Trainingspaare \( \mathcal{B}^{(\nu)} \) aus dieser und früheren Runden auswählen und trainiert darauf. MADPO führt seine Updates für num_train_epochs pro Runde durch. MARLHF passt ein neu initialisiertes Belohnungsmodell darauf an und führt dann das Policy-Lernen durch.

Bewertung sammelt immer von den aktuellen Richtlinien und bewertet diese mit der Aufgabenbelohnung (reward_func und reward_processor), niemals mit einem gelernten Belohnungsmodell.

Vergleicher#

Beim iterativen Training liefert der Vergleicher die andere Seite des Vergleichs. Die aktuellen Agenten und der Vergleicher reagieren auf die gleiche Aufgabe, und jeder Vergleich mit einem klaren Gewinner unter der Oracle-Funktion wird zu einem Paar, unabhängig davon, welcher Seite es zugesprochen wird.

comparator_policy wählt die Quelle des Vergleichers:

• comparator_policy="current" (Standard): Aktuelle actor-Gewichte, die mit einem separaten Zufallszahl-Stream abgetastet werden.

• comparator_policy="current_copy": Aktuelle actor-Gewichte, die an comparator_devices kopiert werden, wenn sie sich von actor unterscheiden.

• comparator_policy="model": Explizite Modelle von comparator_model_name oder comparator_agents.

• comparator_policy="history": Ein gespeichertes actor-Checkpoint von comparator_history_k Iterationen zurück; die anfängliche Richtlinie, falls vorhanden.

• comparator_policy="api": Ein Remote-Modell-Endpunkt.

Die history-Quelle speichert Richtlinien-Checkpoints automatisch. Die beiden Seiten können unterschiedliche Anzahl von Kandidaten abtasten; nur die Indizes, die auf beiden Seiten vorhanden sind, werden verglichen, und pair_selection="comparator_reward" geht davon aus, dass der Vergleicher gewinnt. Standardmäßig generiert der Vergleicher eine Antwort pro Rolle; mit comparator_generation_mode="centralized" schreibt ein Vergleicher-Modell jede Rollenantwort in eine gemeinsame Antwort, die dann in Rollenantworten aufgeteilt wird, bevor Paare erstellt werden.

Modellquellen können Modell-Repositories oder lokale Checkpoints sein, wie in Training Entities beschrieben:

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

API Comparators#

Mit comparator_policy="api" fragt der Comparator ein Remote-Modell ab. comparator_api_format wählt das Anfrageformat:

• comparator_api_format="generic" (Standard): Die Anfrage enthält den Prompt, actor-Index, das Task-Item, die Anzahl der Kandidaten und die Generierungseinstellungen; die Ergebnisse werden von comparator_api_response_field gelesen.

• comparator_api_format="openai": Chat Completions, auch von kompatiblen Endpunkten wie DeepSeek verwendet.

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

• comparator_api_format="openai_responses" (Alias responses oder codex): OpenAI Antworten API (https://api.openai.com/v1/responses, OPENAI_API_KEY).

Die Anthropic- und Responses-Formate haben keinen n-Parameter, daher wird für jeden Kandidaten eine Anfrage gesendet. Anfragen verwenden die standardmäßigen zentralisierten oder dezentralisierten Comparator-Prompts.

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

Wiederholungs-Puffer#

Der Wiederholungs-Puffer wählt die gespeicherten Paare aus, die für das Training in jeder Runde verwendet werden. Der aktuelle Datensatz der aktuellen Runde wird zuerst gespeichert, so dass er zusammen mit früheren Runden verwendet werden kann. preference_replay_mode legt fest, welche Runden verwendet werden können:

• preference_replay_mode="current" (Standard): Alle Paare aus der aktuellen Runde, ohne historische Stichproben.

• preference_replay_mode="nearest_k": Die neuesten, nicht leeren Rund-Datensätze von preference_replay_k, einschließlich des aktuellen.

• preference_replay_mode="all_history": Jedes nicht leere Datensatz der aktuellen trainer-Ausführung.

• preference_replay_mode="lambda_decay": Derselbe Verlauf, gewichtet auf aktuelle Runden.

Jede Zeile des Diagramms zeigt, aus welchen Runden-Datensätzen ein Modus auswählen kann und wie stark jedes gewichtet ist, wobei die neueste Runde rechts steht.

nearest_k bedeutet die kürzesten Runden, nicht Nearest-Neighbor-Retrieval. In nearest_k und all_history haben berechtigte Datensätze die gleiche Gewichtung, unabhängig von der Größe, und historische Modi stichproben diese, anstatt von jedem gespeicherten Paar zu trainieren. Wiederholte Paare werden aus den gespeicherten Runden-Dateien neu tokenisiert. Das Festlegen von preference_replay_dir auf eine frühere Ausführung importiert allein nicht ihre Dateien, während Trainings-Checkpoints den Wiederholungs-Index und seine Daten wiederherstellen.

Lambda Decay#

Mit zunehmendem Alter, \( a=0 \) für die neuesten von \( K \) geeigneten Datensätzen, preference_replay_lambda (\( \lambda \)) legt die Auswahlgewichte fest:

\( \lambda=0 \) behält nur den neuesten Datensatz bei, kleinere Werte bevorzugen kürzere Runden, und \( \lambda=1 \) gewichtet jeden Datensatz gleich.

Sampling#

Historische Modi weisen jeden der preference_replay_sample_size-Auszüge anhand des Gewichts einem Datensatz zu, und anschließend werden Paare innerhalb jedes Datensatzes ausgewählt. Das Sampling erfolgt ohne Wiederholung, wenn die zugewiesene Anzahl die Datensatzgröße nicht überschreitet; größere Zahlen durchlaufen verschachtelte Kopien. Die kombinierte Stichprobe wird gemischt. Die Standard-Stichprobengröße entspricht der Anzahl der Paare der aktuellen Runde oder der Größe des neuesten nicht leeren Datensatzes, falls die aktuelle Runde leer ist.

current lehnt preference_replay_sample_size und preference_replay_lambda ab und akzeptiert preference_replay_k nur als None oder 1. Die folgende Konfiguration wählt stattdessen 256 Paare aus allen Runden aus, wobei die jüngeren bevorzugt werden:

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 akzeptiert die gleichen Optionen. Um nur die neuesten Runden abzufragen, können Benutzer preference_replay_mode="nearest_k" und die Anzahl der Runden über preference_replay_k festlegen.

MARLHF#

Multi-Agent Reinforcement Learning from Human Feedback (MARLHF) passt ein gemeinsames Belohnungsmodell zu den Präferenzpaaren an, trainiert dann die Richtlinien mit RL anhand des gelernten Belohnungsmodells. Da das Belohnungsmodell die vollständige Antwort des Teams bewertet, lernen separate actors aus einem gemeinsamen Belohnungsmodell.

Belohnungs-Lernen#

Der JointRewardModel \( \widetilde{R}_{\psi}(\mathbf{h}_t,\mathbf{a}_t) \) liest alle Anfragen und Antworten der Agenten als einen Text und wendet eine skalare Kopf auf den letzten verborgenen Zustand des kausalen LM backbone im finalen Nicht-Padding token an. Es minimiert den Bradley–Terry-Verlust über die Trainingspaare \( \mathcal{B} \):

wobei \( \sigma \) die Sigmoid-Funktion ist. Der Verlust erhöht den Score des Gewinners relativ zum Score des Verlierers; er regressiert nicht auf die Aufgabenbelohnungen. Trainings-Entitäten beschreiben, wie das Belohnungsmodell geladen wird.

Richtlinien-Lernen#

Nach dem Präferenzlernen wird \( \widetilde{R}_{\psi} \) festgelegt und ersetzt den Task-Reward. Die Policies sampeln neue gemeinsame Antworten für jede Aufgabe, \( \widetilde{R}_{\psi} \) bewerten diese ohne Gradienten, und ein MARL-Backend aktualisiert die Policy jedes Agents, um den gelernten Return zu maximieren:

rl_algorithm wählt das Backend:

• rl_algorithm="magrpo" (Standard): MAGRPO, mit einer Gruppen-Mean-Baseline.

• rl_algorithm="mareinforce": MAREINFORCE, mit Roh-Returns.

• rl_algorithm="marloo": MARLOO, mit einer Leave-One-Out-Baseline.

• rl_algorithm="maremax": MAReMax, mit einer Gruppen-Maximum-Baseline.

• rl_algorithm="maac": MAAC, mit einem zentralen critic.

• rl_algorithm="iac": IAC, mit pro-actor critics oder angehängtem value heads.

Multi-Agent REINFORCE und Multi-Agent Actor-Critic beschreiben diese Aktualisierungen, wobei \( \widetilde{R}_{\psi}(\mathbf{h}_t,\mathbf{a}_t) \) anstelle von \( r_t \) verwendet wird. Optionale, gefrorene Referenz-KL-Regularisierung (reference_kl_enabled, reference_kl_coef, reference_devices) gilt nur für das Lernen der Richtlinien: Der von jedem Agenten abgeleitete KL-Schätzwert, skaliert mit reference_kl_coef, wird von seinem Belohnungsignal abgezogen.

reward_model_name ist erforderlich, wenn actors Modellobjekte ohne Modell-ID sind. MAAC und separate critic IAC benötigen ebenfalls explizite critic-Quellen oder eine nutzbare critic-Modell-ID.

MADPO#

Mehr-Agenten-Direkte Präferenzoptimierung (MADPO) trainet die Richtlinien direkt aus den Präferenzpaaren, ohne ein Belohnungsmodell oder eine RL Stufe. Ihre Verlustfunktion kombiniert die Präferenzen aller Agenten margins, so dass jede Richtlinie aus dem Ergebnis des Teams lernt.

Die margin jedes Agenten ist die Differenz zwischen seinen Log-Wahrscheinlichkeiten für die gewinnende und die verlorene Antwort, und die gemeinsame margin summiert diese über alle Agenten:

MADPO minimiert

wobei \( \eta>0 \) dpo_beta ist (Standard 0,1). Die Aufgabenbelohnung ordnet nur jedes Paar; die Verlustfunktion verwendet die Log-Wahrscheinlichkeiten der Richtlinien. Der Gradient für den Agenten \( i \) ist

Der Wert \( \sigma(-\eta\,\Delta_{\boldsymbol{\theta}}) \) hängt von der gemeinsamen Antwort des Teams margin ab, während der Gradient nur durch den eigenen \( i \) margin fließt. In jeder Batch berechnet trainer alle margins einmal ohne Gradienten, aktualisiert dann jeden Agenten mit seinem eigenen differenzierbaren margin plus den detacheten margins der anderen.

Das Ziel ist referenzfrei: die geerbten reference_kl_enabled, reference_kl_coef und reference_devices-Einstellungen fügen der MADPO-Verlustfunktion keine Referenzterme hinzu. Die Trainingsmetriken turn_1/reward_mean und turn_1/expected_return berechnen den Durchschnitt der Kandidatenbelohnungen, die bei der Erfassung der Paare aufgezeichnet wurden, und spiegeln daher nicht die aktualisierten Richtlinien wider

Der dezentrale Scorer schließt die letzte Vervollständigung token aus, nachdem Padding entfernt wurde, sodass jede Agents margin den Log-Wahrscheinlichheitswert dieser token nicht berücksichtigt. Der zentrale Scorer deckt die vollständige gemeinsame Vervollständigung ab.