AWS zeigt Multi-Turn Reinforcement Learning auf SageMaker AI am Beispiel eines Wordle-Agenten

Warum mehrstufige Aufgaben einen anderen Trainingsansatz brauchen

AWS argumentiert, dass die meisten Feinabstimmungen auf eine bessere Antwort auf einen einzelnen Prompt zielen. Agentenaufgaben wie das Einreichen einer Spesenabrechnung oder die Priorisierung eines Support-Tickets bestehen dagegen aus einer Abfolge von Aktionen, bei der jeder Schritt von den vorherigen abhängt. Es gibt selten eine einzige korrekte Abfolge, die sich nachahmen ließe, und verlässliches Feedback liefert nur die Frage, ob die gesamte Abfolge erfolgreich war.

Laut dem Beitrag fehlen dem überwachten Fine-Tuning für diesen Fall die Labels, und Single-Turn-Reinforcement-Learning kann eine Entscheidung, die drei Schritte vor dem Ergebnis fiel, nicht angemessen bewerten. MTRL auf SageMaker AI ist darauf ausgelegt, mit dem Signal am Ende einer Episode zu trainieren. Man gibt nicht die richtige Trajektorie vor, sondern nur, wie das Ergebnis bewertet wird.

SageMaker AI sendet Prompts über einen AWS-Lambda-Forwarder an einen Agenten, der auf Amazon Bedrock AgentCore oder auf eigener Infrastruktur wie Amazon EKS, Amazon EC2 oder AWS Fargate läuft. Der Agent ruft das zu trainierende Policy-Modell auf, agiert in der Umgebung über beliebig viele Runden und meldet am Ende der Episode eine einzige Belohnung.

So funktioniert das Wordle-Beispiel

AWS wählte Wordle, weil es nur wenige Regeln gibt, jeder Rateversuch vom Feedback des vorherigen abhängt und sich das Ergebnis objektiv bewerten lässt. Das Unternehmen betont, Wordle sei ein Lehrbeispiel, und Frontier-Modelle spielten es bereits gut. In der Praxis solle MTRL ein kleines, kostengünstiges Modell bei einer mehrstufigen, unternehmensspezifischen Aufgabe leistungsfähig machen, etwa bei einem internen Workflow, auf den öffentliche Modelle nie trainiert wurden.

Das System besteht aus zwei Hälften. SageMaker AI verantwortet den Trainingsjob und das Policy-Modell, AgentCore hostet den Agenten, die Wordle-Umgebung und die Belohnungsfunktion. Für jeden Rollout ruft der MTRL-Dienst die AgentCore-Runtime mit einer Trainingszeile auf, die ein geheimes Wort enthält. Ein Strands-Agent ruft das Policy-Modell auf und spielt über ein einziges Tool, guess_word, bis zu sechs Rateversuche. Group Relative Policy Optimization (GRPO) nutzt anschließend die Streuung der Belohnungen über mehrere Rollouts desselben Wortes, um einen Low-Rank-Adaptation-Adapter (LoRA) auf dem Policy-Modell zu aktualisieren.

Die Belohnung ist stark ergebnisorientiert. Ein Sieg bringt je nach Geschwindigkeit 1,05 bis 1,55, eine Niederlage -0,5, und wer nie einen gültigen Tipp abgibt, erhält -1,5. Ein kleiner Shaping-Term belohnt innerhalb jeder Stufe gute Strategie. AWS erklärt zudem, dass Datensätze, der Agent und das trainierte Modell im AWS-Konto des Kunden bleiben und nicht zum Training der Basismodelle verwendet werden.

Ergebnisse, unterstützte Modelle und Kosten

In AWS' Lauf steigerte MTRL gpt-oss-20b bei unbekannten Wörtern mit dem Standard-Reasoning-Aufwand von 61 auf 84 Prozent und beim niedrigen Aufwand, auf dem trainiert wurde, von 15 auf 69 Prozent. AWS wählte GPT-OSS-20B, weil es von den vier unterstützten Modellen den niedrigsten Preis pro Token hat und sich sein Reasoning-Aufwand pro Anfrage steuern lässt.

MTRL ist serverlos: Nutzer wählen ein Basismodell, und der Dienst stellt die Infrastruktur bereit. Zum Zeitpunkt der Veröffentlichung werden folgende Modelle unterstützt, jeweils mit einem LoRA-Adapter trainiert:

• Amazon Nova 2 Lite: USA Ost (Nord-Virginia) und USA West (Oregon)
• GPT-OSS-20B: USA Ost (Nord-Virginia) und USA West (Oregon)
• Gemma 4 31B (instruction-tuned): USA West (Oregon)
• Qwen 3.6 27B: USA West (Oregon)

Die Abrechnung erfolgt pro Million Tokens in drei Dimensionen: Prefill, Sample und Train. Der Lauf über 100 Schritte verbrauchte 491,6 Millionen Prefill-, 159,7 Millionen Sample- und 643,3 Millionen Train-Tokens bei 105.486 Rollouts in 12 Stunden und 40 Minuten. Zu den Listenpreisen von GPT-OSS-20B in us-east-1 beliefen sich die Gesamtkosten auf 338,50 US-Dollar, davon entfielen 231,59 US-Dollar auf Train-Tokens. Die AgentCore-Runtime wird separat berechnet und kostete laut AWS für diesen Lauf etwa 79 US-Dollar.

Voraussetzungen für die Einrichtung und Bedeutung für Teams

Die Anleitung setzt Python 3.10 oder höher, uv, Node 20 oder höher und die AgentCore CLI voraus. Hinzu kommen botocore 1.43.37 oder höher, laut AWS die erste Version mit der Operation AgentRFT CreateJob, sowie ein Amazon-S3-Bucket in derselben Region wie der Agent. Regionsübergreifende Runtime-ARNs werden von CreateJob abgelehnt.

Beteiligt sind zwei IAM-Rollen. Die Rolle der Agent-Runtime wird von agentcore deploy erstellt. Die Rolle des Trainingsjobs muss job.sagemaker.amazonaws.com mit sts:AssumeRole und sts:TagSession vertrauen. AWS warnt, dass die Verwendung des generischen Prinzipals sagemaker.amazonaws.com dazu führt, dass CreateJob mit "Could not assume role." fehlschlägt.

Für Teams, die Agenten entwickeln, zeigt der Beitrag einen Weg, ein kleines Modell auf einen unternehmensspezifischen Workflow zu trimmen, und zwar nur mit einer Bewertungsfunktion statt mit gelabelten Trajektorien. AWS weist darauf hin, dass die Train-Dimension die Kosten dominiert und mit der Länge der Trajektorie wächst, sodass kürzere Aufgaben und weniger ausführliches Reasoning die Rechnung senken. Das Unternehmen teilt außerdem die Fehler beim Belohnungsdesign und die Trainingsprobleme, auf die es gestoßen ist, und stellt den gesamten Code in einem aws-samples-Repository bereit.