AWS zeigt, wie sich ein Suchagent mit Multi-Turn-RL auf SageMaker AI trainieren lässt
AWS hat eine Anleitung veröffentlicht, wie sich ein Suchagent mit Amazon SageMaker AI Multi-Turn Reinforcement Learning (MTRL) feintunen lässt. Der Beitrag beschreibt, wie ein Qwen3.6-27B-Modell lernt, über mehrere Runden zwischen Schlagwort- und Vektorsuche zu wählen, wobei die Qualität der Suchergebnisse als Reward dient.
- AWS beschreibt, wie sich ein Suchagent mit Amazon SageMaker AI Multi-Turn Reinforcement Learning (MTRL) feintunen lässt.
- Im Beispiel wird Qwen3.6-27B mit BM25- und Vektorsuche-Tools trainiert, als Reward auf Trajektorienebene dient nDCG@10.
- Läufe, die das Runden- oder Token-Limit erreichen, erhalten einen Reward von -1, um solche Fehler zu vermeiden.
- Laut AWS wurden nur drei Hyperparameter geändert, alle anderen blieben auf den Standardwerten.
- MTRL läuft serverlos mit Abrechnung pro Token und lässt sich mit MLflow, SageMaker-Endpoints und Amazon Bedrock nutzen.
Warum Multi-Turn-Training für Suchagenten
Laut AWS entscheidet ein Suchagent auf Basis eines großen Sprachmodells selbst, wonach er sucht, welche Retrieval-Strategie er nutzt und wann er aufhört. Dabei verfeinert er sein Vorgehen über mehrere Runden anhand dessen, was er bereits abgerufen hat. Dieses Verhalten zuverlässig hinzubekommen, ist schwierig. AWS zufolge kennt kein Basismodell von Haus aus die Tools oder die Umgebung eines Unternehmens, ein kleines Modell mit Prompting liefert selten verlässliches Multi-Turn-Verhalten, und ein Frontier-Modell funktioniert zwar oft, kostet aber mehr Latenz und Geld.
Als dritten Weg stellt AWS das Fine-Tuning vor: Ein kleines Modell lernt die eigenen Tools und die eigene Umgebung direkt. Die üblichen Methoden greifen aus Sicht von AWS zu kurz. Supervised Fine-Tuning ist auf Expertendemonstrationen idealer Multi-Turn-Verläufe angewiesen, die aufwendig zu sammeln sind und für ein konkretes Setup meist gar nicht existieren. Single-Turn-Reinforcement-Learning, etwa RL mit verifizierbaren Rewards (RLVR), bewertet jeweils nur eine Antwort und übersieht damit die Abhängigkeiten zwischen Entscheidungen über mehrere Runden hinweg.
Multi-Turn-Reinforcement-Learning optimiert den Agenten dagegen über den gesamten Verlauf, und der Reward muss lediglich widerspiegeln, ob das Endergebnis gut war. AWS ergänzt, dass ein kleineres, spezialisiertes Modell zudem schnellere und günstigere Inferenz ermögliche.
Was SageMaker AI MTRL bietet
Amazon SageMaker AI MTRL feintunt LLMs per Reinforcement Learning in Multi-Turn-Szenarien. Es behandelt eine agentische Aufgabe als Abfolge von Entscheidungen, erzeugt Trainingsdaten über Multi-Turn-Rollouts und optimiert das Modell mit Policy-Gradient-Algorithmen. AWS nennt folgende Funktionen:
- Modulare Agent-Umgebungs-Schnittstelle: Low-Code-Integration mit eigenen Rewards, Tool-Schleifen und Gesprächsformen.
- Serverlose Ausführung: Abrechnung pro Token, ohne GPU-Cluster bereitzustellen oder zu verwalten.
- Asynchrone Rollouts und Trajektoriensammlung: Generierung und Gradienten-Updates laufen parallel, mit begrenzter Off-Policy-Staleness.
- Native Algorithmenbibliothek: PPO, CISPO und Importance-Sampling-Losses, kombiniert mit gruppenbasierten Advantage-Schätzern wie GRPO, GRPO pass@k und RLOO.
- Fortsetzbares Training: Lange Läufe lassen sich auf mehrere Jobs aufteilen.
- Observability: Runde für Runde lassen sich Trajektorien und Rewards in MLflow einsehen, das von Amazon SageMaker AI verwaltet wird.
- Evaluierungsjobs: Reward-, pass@k- und Trajektorienmetriken vor dem Deployment auf einem SageMaker-AI-Endpoint oder in Amazon Bedrock.
Das Trainings-Setup
Das Beispiel nutzt Qwen3.6-27B in der Region US West (Oregon) (us-west-2). Der Agent verfügt über zwei Tools: die lexikalische Suche mit BM25, die exakte Schlagwort-Treffer findet, und die Vektorsuche, die Embeddings vergleicht und für semantische oder konzeptionelle Anfragen empfohlen wird. Die Zahl der Runden ist begrenzt, um übermäßig lange Antworten zu vermeiden und eine effiziente Suche zu fördern.
Die Trainingsdaten kombinieren sechs Datensätze: FRAMES, BRIGHT, Enterprise RAG, ESCI, Musique und MLQA. Getestet wird mit FreshStack, WixQA, BrowseComp-Plus und Wands. AWS reserviert 5 Prozent der Trainingsinstanzen jedes Datensatzes für die Validierung.
Als Reward dient nDCG@10, eine gängige Retrieval-Metrik, bei der 1,0 ein perfektes Ranking und 0,0 den Abruf keines relevanten Dokuments bedeutet. Er wird auf Trajektorienebene vergeben, nachdem der Agent seine komplette Suche beendet hat. Erreicht der Agent die maximale Rundenzahl oder in einer einzelnen Runde die maximale Zahl an Sampling-Tokens, erhält er einen Reward von -1. Laut AWS lenkt diese Strafe das Modell von solchen Fehlern weg, ohne dass handgefertigte Zwischen-Rewards nötig sind.
Für den Job selbst hat AWS nach eigenen Angaben drei Hyperparameter geändert und alles andere bei den Standardwerten belassen. Im Beispiel mit dem MultiTurnRLTrainer-SDK sind max_epochs auf 1, global_batch_size auf 128 und rollout_max_concurrency auf 32 gesetzt. Der vorliegende Quelltext bricht vor dem Ergebnisteil ab.
Was das für Unternehmensteams bedeutet
Der Beitrag positioniert MTRL als passend für Suchagenten, weil diese mit der Retrieval-Qualität ein klares Reward-Signal haben, eine Multi-Turn-Schleife aus Anfragen und Ergebnissen durchlaufen und in einer klar definierten Umgebung aus Suchwerkzeugen arbeiten. Für Teams ohne Expertendemonstrationen oder GPU-Cluster lautet das Angebot von AWS: ein konfigurationsarmer Weg zu einem kleinen Modell, das sich in der eigenen Umgebung zuverlässig verhält. Die Ergebnisse zu Retrieval-Qualität und Zuverlässigkeit, die AWS nach eigenen Angaben beobachtet hat, sind im hier vorliegenden Teil der Quelle nicht enthalten.
