SageMaker AI führt Multi-Turn Reinforcement Learning für agentische Modellanpassung ein

Serverloses Fine-Tuning für agentische Aufgaben: SageMaker AI führt Multi-Turn RL ein

Amazon SageMaker AI bietet ab sofort Multi-Turn Reinforcement Learning als neue serverlose Modellanpassungstechnik an. Das Verfahren zielt auf mehrstufige, agentische Aufgaben, bei denen ein Modell über mehrere Schritte hinweg Entscheidungen trifft – etwa Suchagenten, die selbstständig festlegen, wonach sie suchen, welche Retrieval-Strategie sie wählen und wann sie die Suche beenden. SageMaker AI verwaltet dabei den vollständigen Trainingsloop, von der Orchestrierung der Rollouts über die Sammlung der Trajektorien bis hin zum Training und zur Checkpoint-Verwaltung. Damit entfällt nach Angaben des Anbieters der Aufbau eigener Trainingsinfrastruktur, der bei agentischen Workloads oft Wochen in Anspruch nimmt. Der Grund dafür liegt in der Komplexität der benötigten Komponenten: Für das Training gegen eine eigene Agentenumgebung müssen Teams eine Infrastruktur aufbauen, die Rollouts parallelisiert, Trajektorien sammelt und speichert, Checkpoints verwaltet, die Agentenumgebung anbindet und die Policy-Updates mit den gesammelten Daten koordiniert. Diese Orchestrierung über viele verteilte Komponenten hinweg ist aufwändig zu implementieren und zu betreiben. Multi-Turn RL erweitert die bestehenden Anpassungsmethoden in SageMaker AI – Supervised Fine-Tuning, Reinforcement Learning from Verifiable Rewards und Reinforcement Learning from AI Feedback – um das Training gegen eine eigene Agentenumgebung. Die Technik ist als serverloses Angebot konzipiert: Kunden bringen ihren Agenten und eine Belohnungsfunktion mit, bezahlt wird nach verarbeiteten Token, ohne Leerlaufkosten für GPUs während langer Rollouts.

Vom Single-Turn zum Multi-Turn: Belohnung der gesamten Entscheidungssequenz

Der zentrale Unterschied zu bisherigen Fine-Tuning-Methoden liegt in der Art der Belohnung. Beim klassischen Single-Turn Reinforcement Learning – etwa RLHF oder RLAIF – wird eine einzelne Ausgabe bewertet. Ein Suchagent trifft jedoch über mehrere Turns hinweg voneinander abhängige Entscheidungen: Jede Aktion baut auf dem zuvor abgerufenen Kontext auf. Die Optimierung eines einzelnen Schritts isoliert zu betrachten, verfehlt daher die Anforderungen solcher Aufgaben. Multi-Turn RL trainiert das Modell stattdessen gegen seine eigene Agentenumgebung: Der Agent beobachtet den Zustand, führt eine Aktion aus, erhält eine Belohnung und wechselt in einen neuen Zustand. Dieser Zyklus wiederholt sich über viele Zeitschritte. Ziel ist es, eine Policy zu lernen, die die kumulative Belohnung über die gesamte Sequenz maximiert – nicht die Belohnung eines einzelnen Schritts. Auch Supervised Fine-Tuning stößt bei agentischen Aufgaben an Grenzen, weil es auf Experten-Demonstrationen idealer Multi-Turn-Trajektorien angewiesen ist, die für die jeweilige Umgebung meist nicht existieren und teuer zu sammeln sind. Multi-Turn RL reduziert den Bedarf an teuren Experten-Demonstrationen, weil das Training direkt in der Agentenumgebung erfolgt und die Qualität der gesamten Handlungssequenz als Lernsignal verwendet wird. Algorithmisch kommen dabei Policy-Gradient-Methoden zum Einsatz, die das Belohnungssignal über die gesamte Sequenz zurückpropagieren. SageMaker AI unterstützt laut Dokumentation Verfahren wie PPO, CISPO sowie gruppenbasierte Methoden wie GRPO und RLOO. Diese Algorithmen ermöglichen es dem Modell, Credit Assignment zu lernen: Es erkennt, welche frühen Entscheidungen in der Sequenz tatsächlich zum späteren Gesamtreward beigetragen haben, und passt seine Policy entsprechend an.

Verwalteter Trainingsloop und flexible Infrastruktur-Anbindung

Technisch übernimmt SageMaker AI die Orchestrierung der Rollouts, die Sammlung der Trajektorien, das eigentliche Training sowie die Verwaltung von Checkpoints. Der Agent selbst kann auf unterschiedlicher Infrastruktur laufen: auf der Amazon Bedrock AgentCore Runtime für vollständig verwaltetes Hosting, auf Amazon EKS, Amazon EC2 oder AWS Fargate – oder auf beliebiger Infrastruktur mit dem Framework der Wahl. Diese Entkopplung von Inferenz- und Trainingsinfrastruktur funktioniert so, dass die Rollouts – also die Ausführung des Agenten in seiner Umgebung – auf der vom Kunden gewählten Infrastruktur stattfinden, während die Policy-Updates auf der von SageMaker verwalteten Trainingsinfrastruktur laufen. Dadurch entstehen bei langen Rollouts keine GPU-Leerlaufzeiten auf der Trainingsseite: Die Trainings-GPUs werden nur dann genutzt, wenn tatsächlich ein Update der Modellgewichte ansteht, und nicht während der oft langen Phasen, in denen der Agent auf Antworten seiner Umgebung wartet. Diese Trennung schafft nach Angaben von AWS Skaleneffekte und senkt die Kosten, da keine teuren GPU-Ressourcen für das Warten auf Rollout-Ergebnisse blockiert werden. Zur Überwachung des Trainings ist MLflow-Tracking eingebaut, über das sich Metriken und Verläufe einsehen lassen. Für die Evaluierung trainierter Modelle stehen zudem rollout-basierte Metriken wie Pass@k und mittlere Belohnung zur Verfügung. Pass@k misst, wie häufig das korrekte Ergebnis unter den k besten Vorhersagen eines Rollouts liegt; die mittlere Belohnung ist der durchschnittliche Reward über alle Rollouts. Diese Metriken sind für Multi-Turn-RL-Modelle besonders relevant, weil sie die Qualität der gesamten Entscheidungssequenz bewerten und nicht nur einzelne Antworten. Die serverlose Abrechnung erfolgt nach verarbeiteten Token, nicht nach reservierter Rechenzeit. Damit richtet sich das Angebot an Teams, die agentische Modelle spezialisieren wollen, ohne eine eigene RL-Pipeline für Rollout-Orchestrierung, Trajektoriensammlung und Checkpointing aufbauen und betreiben zu müssen.

Prompt-Format und Datenschutzverantwortung beim Training

Der Trainingsdatensatz für Multi-Turn RL besteht aus einer Sammlung von Prompts. Jeder Prompt startet einen Rollout: Der Agent verarbeitet den Prompt, führt über einen oder mehrere Turns Aktionen aus und gibt am Ende eine Belohnung zurück. Die Qualität und Struktur des Datensatzes beeinflusst direkt, was das Modell lernt. Der RFT-Service erkennt die Prompt-Spalte anhand des Spaltennamens "prompt". Existiert eine solche Spalte nicht, wird die erste Spalte des Datensatzes verwendet. AWS empfiehlt, die Spalte eindeutig zu benennen, um Mehrdeutigkeiten zu vermeiden. Weitere Spalten können für eigene Tracking-Zwecke enthalten sein, werden vom Service jedoch nicht gelesen. Der Prompt-String wird unverändert an den Agenten übergeben – ohne Parsing, Validierung oder Transformation. Welches Format der Agent erwartet, hängt von dessen Implementierung ab: Ein einfacher Agent kann Klartext verarbeiten, ein komplexerer etwa einen JSON-String mit Konversationsverlauf, Tool-Konfiguration und Belohnungsspezifikation. Da der RFT-Service Prompts ohne Inspektion weiterleitet, liegt die Verantwortung für den Schutz sensibler Inhalte beim Kunden. AWS verweist darauf, Prompt-Daten vor der Speicherung zu kodieren oder zu verschlüsseln und die Dekodierung im Agenten vorzunehmen.

Positionierung: Kleine Modelle für spezialisierte Agenten – mit offenen Fragen

AWS positioniert Fine-Tuning als dritten Weg zwischen dem Prompting kleiner Modelle, das bei mehrstufigen Aufgaben selten zuverlässiges Verhalten liefert, und dem Einsatz von Frontier-Modellen, der mit höherer Latenz und Kosten verbunden ist. Nach Angaben des Unternehmens bringt man einem kleinen Modell die eigenen Tools und die Umgebung direkt bei und erhält so die Geschwindigkeit und Kosteneffizienz eines kleinen Modells mit der Zuverlässigkeit, die sonst ein Frontier-Modell erfordern würde. Multi-Turn RL soll dabei helfen, kleinere und kostengünstigere Modelle so zu spezialisieren, dass sie die Aufgaben-Genauigkeit größerer General-Purpose-Modelle auf der Ziel-Workload erreichen oder übertreffen. Der Mechanismus dahinter: Durch belohnungsbasierte Optimierung über komplette Entscheidungssequenzen lernt das Modell, welche frühen Entscheidungen zu guten Endergebnissen führen. Es nutzt das Umgebungs-Feedback effizienter, da der Bedarf an teuren Experten-Demonstrationen reduziert wird. Zudem reduziert die Spezialisierung auf eine Ziel-Workload die Abhängigkeit von der Over-Parameterisierung großer Modelle, sodass ein kleineres, feinabgestimmtes Modell vergleichbare oder bessere Genauigkeit erreichen kann. Diese Aussagen sind Herstellerangaben. Unabhängige Benchmarks, die feingetunte kleine Modelle mit Frontier-Modellen auf identischen Suchagenten-Aufgaben vergleichen, stehen noch aus. AWS selbst hat in einem Blogpost einen LLM-gestützten Suchagenten mit Multi-Turn RL auf SageMaker AI feinabgestimmt und teilt dort gemessene Verbesserungen bei Retrieval-Qualität und Zuverlässigkeit – auch diese Werte stammen aus der Anbieterperspektive. Die Einordnung in den breiteren Kontext agentischer Systeme und ihrer Infrastruktur-Anforderungen wird durch die laufende Diskussion um Webservices für KI-Agenten ergänzt, die grundlegende Architekturfragen solcher Systeme behandelt.