# Suchagenten mit Multi-Turn-RL auf Amazon SageMaker AI trainieren - Source: MechNext — https://mechnext.eu/de/article/29-training-a-search-agent-with-multi-turn-rl-on-amazon-sagemaker-ai - Published: 2026-10-04 - Updated: 2026-10-04 - Category: Industry News - Language: de (Markdown in other languages: ?lang=en, ?lang=sk, ?lang=pl, ?lang=zh, ?lang=ru) > Ein AWS-Artikel beschreibt einen Agenten, der über mehrere Schritte Suchanfragen und Werkzeuge auswählt, und berichtet Ergebnisse aus vier zurückgehaltenen Benchmarks. Ein AWS-Artikel beschreibt einen Suchagenten, der Entscheidungen über mehrere Interaktionsrunden hinweg trifft. Der Agent wählt selbstständig aus, wonach er sucht, welche Abrufstrategie er verwendet und wann er aufhört. Der Trainingsansatz betrachtet daher eine vollständige Folge von Entscheidungen statt nur einer einzelnen Antwort. Jede Wahl gehört zu einer Trajektorie, die schließlich die abgerufenen Dokumente hervorbringt. Der Artikel richtet das Training auf diesen gesamten Suchprozess aus. Vorgestellt wird Amazon SageMaker AI MTRL, ein Ansatz für Reinforcement Learning über mehrere Gesprächsrunden. Laut Artikel trainiert MTRL den Agenten mit Multi-Turn-Rollouts über die vollständige Entscheidungsfolge und mit Policy-Gradient-Algorithmen. Unterstützt werden benutzerdefinierte Belohnungen, Werkzeugschleifen und mehrstufige Gesprächsformen. Der beschriebene Dienst umfasst außerdem serverlose Ausführung sowie die asynchrone Sammlung von Rollouts und Trajektorien. Zu den aufgeführten Algorithmusoptionen gehören PPO, CISPO und Verluste auf Basis von Importance Sampling. Als weitere Funktionen nennt der Artikel fortsetzbares Training, Beobachtbarkeit der Trajektorien und Evaluierungsjobs. ### Entscheidungen innerhalb einer Suchtrajektorie Im beschriebenen Aufbau kann der Agent eine weitere Suche wählen oder den Vorgang beenden. Das Beispiel ordnet unterschiedliche Abrufmethoden verschiedenen Anfragearten zu: BM25 für die lexikalische Suche nach exakten Begriffen oder Kennungen und Vektorsuche für semantische oder konzeptionelle Anfragen. Für einen Agenten mit mehreren Schritten ist diese Unterscheidung relevant, weil er sowohl die Suchstrategie auswählt als auch entscheidet, ob ein weiterer Schritt nötig ist. Der Artikel behandelt diese Wahlmöglichkeiten als zusammenhängende Folge und nicht als voneinander losgelöste Suchvorgänge. Als Belohnung im Training diente nDCG@10 auf Trajektorienebene. Sie beruhte darauf, wie gut die am Ende abgerufenen Dokumente mit den Ground-Truth-Ergebnissen übereinstimmten. Die genannte Belohnung spiegelt somit die Qualität der Dokumente am Ende des Suchverlaufs wider und verknüpft das Trainingsziel mit der Abrufqualität im beschriebenen Versuch. Daraus folgt nicht, dass jeder einzelne Schritt gleich bewertet wird oder dass BM25 beziehungsweise Vektorsuche für jede Anfrage geeignet wäre. Der Artikel ordnet sie ausdrücklich exakten Begriffen beziehungsweise semantischen oder konzeptionellen Anfragen zu. ### Trainingsgrenzen und berichtete Ergebnisse Der Artikel berichtet, dass das Erreichen der maximalen Zugzahl oder des Sampling-Token-Limits pro Zug eine Belohnung von -1 ergab. Außerdem nennt er die geänderten Hyperparameter des beschriebenen Trainings: max_epochs betrug 1, global_batch_size 128 und rollout_max_concurrency 32. Diese Angaben beschreiben die dort verwendete Konfiguration. Sie belegen nicht, dass dieselben Grenzen und Einstellungen für jeden Agenten oder jede Aufgabe passen. Auf vier zurückgehaltenen Benchmarks verbesserte sich nDCG@10 laut Artikel bei dreien. BrowseComp-Plus legte um 23,7 Prozent und WixQA um 18,4 Prozent zu. Bei Wands fiel der Zuwachs kleiner aus, während FreshStack einen leichten Rückgang verzeichnete. Für BrowseComp-Plus sank die berichtete Fehlerrate von 22,89 auf 0,68 Prozent. Die Werte zeigen unterschiedliche Ergebnisse je Benchmark: Der Bericht umfasst sowohl Verbesserungen als auch einen Rückgang. Es handelt sich um Resultate der beschriebenen Auswertung; sie belegen nicht, dass alle Suchaufgaben dasselbe Muster zeigen. ### Ein praktischer Ablauf Der Artikel empfiehlt, den Datensatz im geforderten Format vorzubereiten, eine Belohnungsfunktion anhand der aufgabenspezifischen Metrik zu definieren, mit Standardkonfigurationen zu beginnen und anschließend auszuwerten und zu iterieren. Diese Schritte verbinden die Trainingskonfiguration mit dem Ergebnis, das ein Team beurteilen möchte. Wird eine Aufgabe anhand der abgerufenen Dokumente bewertet, sollte die Belohnung die relevante Aufgabenmetrik widerspiegeln. Auswertung und Iteration bieten dann die Möglichkeit, auf beobachtete Ergebnisse zu reagieren, etwa auf die Zuwächse bei BrowseComp-Plus und WixQA und den leichten Rückgang bei FreshStack. Der praktische Rahmen besteht darin, Suche als Folge von Aktionen zu betrachten und Training wie Auswertung an dieser Folge auszurichten. MTRL bietet laut Beschreibung Unterstützung für eigene Belohnungen, Werkzeuginteraktionen und das Sammeln von Trajektorien. Die Benchmark-Ergebnisse zeigen zugleich, dass gemessene Veränderungen je nach Evaluierungsdatensatz variieren können. Der Artikel behauptet nicht, dass jeder Agent oder jeder Datensatz dieselben Zugewinne erzielt. Seine Empfehlungen betonen stattdessen die Datenaufbereitung, eine an die Aufgabenmetrik gekoppelte Belohnung und wiederholte Auswertung. Zusammen zeigen diese Punkte, wie das beschriebene Multi-Turn-Training die Suchentscheidungen des Agenten mit der Qualität seiner endgültig abgerufenen Dokumente verbindet.