Mehrfachturnspezifisches Reinforcement-Learning auf Amazon SageMaker AI: Ein praktischer Leitfaden

Die meisten Fine-Tuning-Prozesse bringen das Modell dazu, auf eine einzelne Anfrage eine bessere Antwort zu geben. Agentische Aufgaben sind jedoch anders. Ein Agent, der einen Ausgabenbericht erstellt oder ein Support-Ticket klassifiziert, führt eine Abfolge von Handlungen durch, und jeder Schritt hängt von dem vorherigen ab. Es gibt selten eine einzige richtige Abfolge, die man nachahmen könnte, und die einzige zuverlässige Rückmeldung ist, ob die gesamte Abfolge erfolgreich war. Das überwachte Feinjustieren hat keine Labels dafür, und das einstufige Reinforcement-Learning kann eine Entscheidung, die drei Schritte vor dem Ergebnis getroffen wurde, nicht anerkennen.

Multi-Turn-Reinforcement-Learning (MTRL) auf Amazon SageMaker AI trainiert Modelle genau an diesem Signal. SageMaker AI sendet Anweisungen an einen Agenten, den Sie auf Amazon Bedrock AgentCore oder auf Ihre eigene Infrastruktur wie Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Compute Cloud (Amazon EC2) oder AWS Fargate hosten, über einen AWS Lambda-Forwarder. Im Beispiel wird AgentCore verwendet. Der Agent ruft das trainierte Policy-Modell auf, handelt in Ihrem Umfeld so viele Turns wie die Aufgabe erfordert und berichtet bei Ende des Episods eine Belohnung aus. Sie legen nicht den richtigen Verlauf fest, sondern nur, wie das Ergebnis bewertet werden soll.

Dieser Beitrag verwendet Wordle, ein Spiel, in dem ein Spieler sechs Versuche hat, um ein verstecktes fünf Buchstabeniges Wort zu erraten. Nach jedem Versuch wird jeder Buchstabe grün, wenn er an der richtigen Position ist, gelb, wenn er im Wort ist, aber an einer anderen Position, und grau, wenn er nicht im Wort ist. Das Spiel eignet sich für MTRL, weil die Regeln einfach sind, jeder Versuch von den Ergebnissen des vorherigen abhängt und das Ergebnis objektiv bewertet werden kann. Wordle ist ein Lehrmodell, und Frontier-Modelle spielen bereits gut darin. In der Praxis würde man MTRL verwenden, um ein kleines, kostengünstiges Modell zu erstellen, das gut in einer mehrstufigen Aufgabe ist, die speziell für das Unternehmen relevant ist – wie beispielsweise ein internes Workflow, auf dem öffentliche Modelle nie trainiert wurden. Der gleiche Prozess gilt auch für diese Situation.

In unserem Testlauf erreichte MTRL das Lösungsergebnis bei gpt-oss-20b von 61 auf 84 Prozent für die übrigen Wörter bei der Standard-Reasoning-Kraft, und von 15 auf 69 Prozent bei niedriger Kraft – für etwa $339 an Trainings-Tokens. In diesem Artikel führen wir den gesamten Prozess end-to-end durch: die Verteilung des Agents und die Zuteilung der Belohnung an AgentCore, die Vorbereitung des Datensatzes, das Training, die Überwachung in MLflow sowie die Evaluation bei der Bereitstellung. Wir teilen auch die Fehler bei der Belohnendesign und den Trainingsfehlern mit. Ihre Datensätze, Agent und trainierten Modell bleiben in Ihrem AWS-Konto und werden nicht verwendet, um die Grundmodelle zu trainieren. Der gesamte Code befindet sich im begleitenden aws-samples-Repository.

Lösungsüberblick

Das System hat zwei Teile. SageMaker AI ist für die Trainingsaufgaben und das Policy-Modell zuständig. AgentCore hostet den Agenten, die Wordle-Umgebung und die Belohnungsfunktion. Das folgende Diagramm zeigt, wie sie miteinander verbunden sind.

Abbildung 1: MTRL auf SageMaker AI, bei der das Trainingsjob den von AgentCore gehosteten Agenten einmal pro Rollout ruft, um das Policy-Modell zu samplen, das Spiel zu spielen und eine Belohnung zu melden

Für jede Implementierung ruft der MTRL-Dienst den AgentCore-Runtime auf, einer Funktion von Amazon Bedrock AgentCore, mit einer Trainingszeile, die ein geheimes Wort enthält. Ein Strands-Agent im Runtime ruft das Policy-Modell über den OpenAI-kompatiblen Endpunkt des SageMaker Job Runtime auf. Das Modell macht bis zu sechs Versuche mit dem Tool guess_word und nach jedem Versuch gibt die Umgebung Feedback pro Buchstabe sowie eine Zusammenfassung dessen, was bekannt ist. Wenn das Spiel endet, gibt der Agent eine Belohnung zurück. Group Relative Policy Optimization (GRPO) nutzt die Verteilung der Belohnungen bei mehreren Implementierungen desselben Wortes, um einen Low-Rank Adaptation (LoRA) Adapter auf dem Policy-Modell zu aktualisieren.

Drei Designpunkte sind für das Folgende wichtig:

• Der Agent und die Belohnung befinden sich an einem Ort. Ein einzelnes Python-File, das auf AgentCore deployt wird, enthält die Umgebung, das Tool und die Bewertungsfunktion.
• Das Datenset besteht nur aus dem geheimen Wort. Die mit dem Agent gelieferten Wörterlisten stammen von den open-source SCOWL-Wörterlisten und werden ausschließlich zur Bewertung verwendet.
• Die Belohnung ist ausgehend vom Ergebnis dominant. Eine Lösung gibt 1,05–1,55, abhängig von der Geschwindigkeit, ein Verlust gibt -0,5, und das Fehlen einer gültigen Vermutung gibt -1,5. Ein kleiner Gestaltungsfaktor belohnt eine gute Strategie innerhalb jedes Levels.

Unterstützte Modelle und AWS-Regionen

MTRL ist serverlos: Sie wählen ein Basismodell und das Service bietet die Infrastruktur für das Training und das Sampling. Zum Zeitpunkt der Erstellung unterstützt es die folgenden Basismodelle, jedes mit einem LoRA-Adapter trainiert:

Wir haben GPT-OSS-20B gewählt, weil es den niedrigsten Preis pro Token der vier Modelle hat und die Rechenkraft für jede Anfrage kontrollierbar ist. Für die aktuelle Liste siehe die MTRL-Dokumentation.

Preise

Sie wählen keine Instanzen oder den Clustergröße aus. Sie zahlen pro Million Tokens in drei Dimensionen – der Preis wird durch das Basismodell festgelegt.

• Vorwerden: die Eingabestatene, die das Politikmodell verarbeitet. Diese sammeln sich bei einer mehrturnige Aufgabe, da jeder Turn den Historieinhalt erneut liest.
• Beispiel: Tokens, die das Policy-Modell erzeugt, einschließlich Rechentokens.
• Train: Tokens, die in der Rückwärtspass verarbeitet werden, aktualisieren den LoRA-Adapter.

Die 100-Schritte-Laufzeit verbrauchte 491,6 Millionen Vorfüllungen, 159,7 Millionen Beispiele und 643,3 Millionen Trainingstokens bei 105.486 Implementierungen in 12 Stunden und 40 Minuten. Bei den Listenpreisen von GPT-OSS-20B in der Region us-east-1 (USA Ost) zum Zeitpunkt des Schreibens beträgt das Preisniveau etwa 339 US-Dollar.

Die Trainierdimensión dominiert und skaliert mit der Länge der Trajektorie, sodass kürzere Spiele und weniger umfangreiche Berechnungen die Kosten senken. Die AgentCore-Laufzeit kostet separat für den vCPU und die Speichermenge, die der Agent verwendet. Für diese Laufzeit betrug das etwa $79, basierend auf den Amazon CloudWatch-Metriken des Laufzeitverkehrs in us-east-1. DescribeJob meldet die Anzahl der Tokens unter BillableTokenUsage. Für aktuelle Preise siehe Amazon SageMaker AI Pricing.

Voraussetzungen

Um diesen Schritt zu befolgen, benötigen Sie das folgende. Siehe auch die MTRL-Voraussetzungen.

• Python 3.10 oder neuer, uv, Node 20 oder neuer, sowie die AgentCore-CLI (npm install -g @aws/agentcore). Siehe Anfangen mit Amazon Bedrock AgentCore für die Installation und die IAM-Rechte, die die CLI benötigt.
• Botocore 1.43.37 oder neuer, auf der Maschine, die den Job startet. Dies ist die erste Version, die die Operation AgentRFT CreateJob enthält.
• Zwei AWS Identity and Access Management (IAM)-Rollen, wie in Schritt 1 beschrieben.
• Ein Amazon Simple Storage Service (Amazon S3)-Bucket in derselben Region wie der Agent. Die Trainingsaufgabe muss auch in dieser Region ausgeführt werden, da CreateJob einen interregionalen Runtime-ARN verweigert.

Schritt 1: Erstellen Sie die IAM-Rollen

MTRL verwendet zwei Rollen, und eine davon hat eine Vertrauenspolitik, die in der allgemeinen SageMaker AI-Dokumentation nicht erwähnt wird.

Agent-Runtime-Rolle. agentcore deploy erstellt diese Rolle für Sie. Sie vertraut bedrock-agentcore.amazonaws.com und benötigt die AmazonSageMakerJobRuntimeAccess-Gestionsempfehlung, durch die der Agent das Policy-Modell aufrufen und Belohnungen melden kann. Der CDK-Stapel im Beispielrepositorium bindet diese Policy automatisch an.

Training-Job-Rolle. Sie erstellen diese Rolle. Sie muss job.sagemaker.amazonaws.com sowohl mit sts:AssumeRole als auch mit sts:TagSession vertrauen, und sie benötigt die AmazonSageMakerJobFullAccess verwaltete Richtlinie.

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {"Service": "job.sagemaker.amazonaws.com"},
        "Action": ["sts:AssumeRole", "sts:TagSession"]
    }]
}

Anmerkung: Das Vertrauensprinzip ist job.sagemaker.amazonaws.com, nicht sagemaker.amazonaws.com. Bei dem generischen Prinzip scheitert CreateJob mit dem Fehler „Could not assume role“, und die Meldung nennt das richtige Prinzip erst nach Wiederholungen.

Schritt 2: Deplizieren Sie den Agenten in den Amazon Bedrock AgentCore

Klonen Sie den Beispiel-Repository, setzen Sie Ihren Account und Region in Wordle/agentcore/aws-targets.json und deponieren Sie:

git clone https://github.com/aws-samples/sample-multi-turn-rl-wordle
cd sample-multi-turn-rl-wordle/Wordle
agentcore validate
agentcore deploy

Der CLI erstellt die Abhängigkeiten des Agents für die Linux-ARM64-Plattform des Betriebssystems, schafft eine Ausführungsrolle mit AmazonSageMakerJobRuntimeAccess und deplomiert sie über AWS CloudFormation. Wir empfehlen dies gegenüber dem Hochladen eines Code-Pakets im Konsole, wo es häufig vorkommt, dass die etwa 700 MB umfassenden kompilierten Abhängigkeiten oder die Anbindung der Richtlinie falsch sind. Beachten Sie den ARN des Betriebssystems in der Ausgabe für die Trainingsaufgabe.

Abbildung 2: Der Wordle-Agent-Runtime in der Amazon Bedrock-AgentCore-Konsole mit Status „Ready“

Der Laufzeitprozess liest zwei Umgebungsvariablen aus agentcore.json. REASONING_EFFORT=low setzt reasoning_effort bei jeder Anfrage an das Policy-Modell. In unseren Bewertungsaufgaben verbrauchten Modelle mit niedrigem Aufwand 63 bis 83 Prozent weniger Beispieldaten pro Spiel als Modelle mit mittlerem Aufwand. REASONING_PROMPT_HINT=true fügt außerdem „Reasoning: low“ zum System-Prompt hinzu, wie gpt-oss die Einstellung in seinem Harmony-Chat-Format liest. Keine dieser Variablen gibt dem Modell irgendeine Hinweise auf das geheime Wort.

Abbildung 3: Laufzeitumgebungsvariablen zeigen, dass REASONING_EFFORT auf niedrig eingestellt ist

Der Agent ist ein einziges File, main.py. Einfach ausgedrückt sieht sein Eintrittspunkt wie folgt aus. Für Ihre eigene Aufgabe ändern Sie die Aufgabenparsing, die Tools und das Belohnungssystem:

app = BedrockAgentCoreApp()

@app.entrypoint  # outermost: starts the HTTP server AgentCore invokes
@sagemaker_rft_handler  # reports the returned reward to SageMaker AI
def handle_rollout(payload):
    prompt, answer = parse_task(payload["prompt"])
    game = WordleGame(answer)

    @tool
    def guess_word(guess: str) -> str:
        """Submit a 5-letter Wordle guess and get feedback."""
        return game.guess(guess)

    agent = Agent(model=build_model(), system_prompt=SYSTEM_PROMPT, tools=[guess_word])
    agent(prompt)
    return {"reward": game.final_reward()}

Wichtig: The sagemaker_rft_handler Der Dekorator startet keinen HTTP-Server allein. Umwickeln Sie ihn damit. BedrockAgentCoreApp und @app.entrypointMit dem Entrypoint-Decorator am äußersten Rand. Ohne diesen Decorator überschleppt jede Aufrufung nach 30 Sekunden.

Schritt 3: Überprüfen Sie den Laufzeitstatus

Bevor man Zeit mit dem GPU verbraucht, muss sichergestellt werden, dass die gesamte Kette mit einem Payload funktioniert, der der von dem Trainingsdienst gesendeten Art entspricht. Das Repository enthält ein solches Payload: Wordle/payload.json.

{
  "prompt": "{\"prompt\": \"Guess the 5-letter word\", \"answer\": \"beach\", \"id\": \"smoke-test\"}",
  "metadata": {
    "jobArn": "arn:aws:sagemaker:us-east-1:111122223333:job/AgentRFT/smoke-test",
    "rolloutId": "r1"
  }
}

Das falsche Job-ARN wird erwartet, dass es scheitert – und die Art und Weise, wie es scheitert, ist der Beweis. Geben Sie zuerst Ihren eigenen Account-ID ein: Für ein Job-ARN in einem anderen Account gibt der Dienst eine 403 zurück, bevor er überprüft, ob das Job existiert – was auf eine kaputte IAM-Einstellung hindeutet. Aus dem Wordle-Verzeichnis führen Sie aus:

ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
sed "s/111122223333/$ACCOUNT/" payload.json > /tmp/payload.json

aws bedrock-agentcore invoke-agent-runtime \
  --agent-runtime-arn <RUNTIME_ARN> \
  --runtime-session-id smoke-test-$(date +%s)000000000000000 \
  --payload fileb:///tmp/payload.json /dev/stdout

In den Amazon CloudWatch-Protokollen des Rundlaufs sieht man, dass der Agent den Prompt verarbeitet, sich an den Job-Rundlauf-Punkt authentifiziert und eine 400-Fehleranzeige mit dem Text „Kann keine Job nicht gefunden werden“ erhält. Diese Fehlermeldung bestätigt, dass die Verarbeitung, Authentifizierung und Fehlerberichterstattung funktionieren. Der Befehl selbst gibt {“reward”: -1.5} aus, da der Agent nie den Policy-Modellzugang erreichte. Die 403-Fehleranzeige mit dem Text „Nicht autorisiert, diesen Ressourcen zuzugreifen“ bedeutet, dass der Job ARN immer noch einen anderen Account bezeichnet. Ein 30-sekündiger Timeout bedeutet stattdessen, dass der HTTP-Server nicht gestartet wird (siehe die wichtige Anmerkung in Schritt 2).

Schritt 4: Bereiten Sie das Datenset vor

Das MTRL-Datenset enthält keine Zielantworten, Transkripte oder Labels. Jede Zeile ist eine Aufgabe, die der Agent ausführen muss. Hier sind die ersten drei Zeilen des Trainingsdateis:

{"prompt": "{\"prompt\": \"Guess the 5-letter word\", \"answer\": \"riser\", \"id\": \"wordle_train_0000\"}"}
{"prompt": "{\"prompt\": \"Guess the 5-letter word\", \"answer\": \"swoon\", \"id\": \"wordle_train_0001\"}"}
{"prompt": "{\"prompt\": \"Guess the 5-letter word\", \"answer\": \"dirty\", \"id\": \"wordle_train_0002\"}"}

Der Dienst liest die prompt-Spalte (oder die erste Spalte) und übermittelt den String wortwörtlich an Ihren Agenten, ohne ihn zu analysieren. Wir haben den String in ein kleines JSON-Objekt mit drei Feldern umgewandelt.

• Prompt: Die Anweisung, die der Agent dem Policy-Modell zeigt, ist in jeder Spalte identisch.
• Antwort: das geheime Wort. Nur die Umgebung und die Belohnungsfunktion verwenden es. Das Policy-Modell sieht es nie.
• id: Eine Zeile-ID zur Nachverfolgung einer Implementierung in den Protokollen bis zu ihrer ursprünglichen Zeile.

Der make_dataset.py des Beispielrepositors extrahiert 640 Trainingswörter (fünf volle Batches à 128) und 128 Validierungswörter aus der Antwortliste, ohne Überschneidungen, sodass die Lösungsrate der Validierung die Generalisierung misst. Der Dienst akzeptiert auch Apache Parquet, JSON-Arrays und CSV. Die beiden Dateien sollten an Amazon S3 hochgeladen werden:

uv run python make_dataset.py
aws s3 cp training-data.jsonl s3://<YOUR_BUCKET>/wordle-mtrl/train/
aws s3 cp validation-data.jsonl s3://<YOUR_BUCKET>/wordle-mtrl/validation/

Da der Dienst den prompt-String nie überprüft, kann eine Produktionsaufgabe eine vollständige Nachrichtenliste, Werkzeugkonfiguration oder Belohnungsbeschreibung darin enthalten. Siehe die MTRL-Dokumentation für Beispiele, einschließlich der Möglichkeit, sensible Inhalte im String zu schützen.

Schritt 5: Starten Sie die Trainingsaufgabe

Der Launcher verwendet die MultiTurnRLTrainer-Klasse aus dem sagemaker-train SDK. Geben Sie den Launcher auf den Runtime-ARN aus Schritt 2, die Rolle aus Schritt 1, die Datensätze aus Schritt 4 sowie eine MLflow-Anwendung für Metriken ein. Die MLflow-Anwendung ist erforderlich; falls Sie keine haben, erstellen Sie sie zuerst mit aws sagemaker create-mlflow-app.

uv run python run_mtrl_training.py \
  --model openai-reasoning-gpt-oss-20b \
  --agent-runtime-arn <RUNTIME_ARN> \
  --role-arn arn:aws:iam::<ACCOUNT>:role/<JOB_ROLE> \
  --train-dataset s3://<YOUR_BUCKET>/wordle-mtrl/train/training-data.jsonl \
  --val-dataset s3://<YOUR_BUCKET>/wordle-mtrl/validation/validation-data.jsonl \
  --s3-output-path s3://<YOUR_BUCKET>/wordle-mtrl/output/ \
  --mlflow-app-arn arn:aws:sagemaker:<REGION>:<ACCOUNT>:mlflow-app/<APP_ID>

Der Launcher überschreibt drei Hyperparameter und lässt alle anderen auf dem Standardwert von gpt-oss-20b bleiben. Er setzt sampling_max_tokens auf 8192 – die maximale Anzahl an Tokens für den Service – da bei dem Standardwert von 4096 gpt-oss oft bereits vor der ersten Tool-Aufruf-Phase durch die Anzahl der Tokens beim Denken fehlte. Er setzt max_epochs auf 20 und max_steps auf 100: Bei dem Standardwert von global_batch_size 128 sind 640 Zeilen gleich 5 Schritten pro Epoche, und bei dem Standardwert von group_size 8 spielen jeder Schritt 1.024 Spiele. Die Aufgabe verläuft durch Start, Download und Wartung, bevor sie zum Training gelangt. Nach dem Training beginnt die Laufzeit des AgentCore-Runtimes, Einsatzanfragen zu empfangen.

Wichtig: Redeplizieren Sie den Agenten nicht, während eine Aufgabe läuft. Die Redeplizierung startet das Betriebssystem neu, währendige Rollouts erhalten keine Sampling-Anfragen, und der Dienst scheitert bei der gesamten Aufgabe.

Schritt 6: Überwachen des Trainings in MLflow

Die Dienstleistung erfasst die Statistiken für Belohnungen, Tokens und Durchgänge bei jedem Schritt und führt eine Validierung alle val_every Schritte durch. Die Metrik, auf die geachtet wird, ist val/reward/pass_at_1, also der Anteil der verbleibenden Wörter, die gelöst wurden. Jeder Lösung erhält mindestens 1,01 Punkte, sodass die success_threshold des Dienstes von 1,0 überschritten wird und pass@1 gezählt wird. Die folgende Grafik basiert auf der MLflow-Historie dieser Ausführung:

Abbildung 4: Trainingskurven für die 100-Schritte-Run, mit der durchschnittlichen Belohnung pro Spiel auf der linken Seite und der Validierungslösungsrate auf der rechten Seite

Die Trainingsbelohnung steigt innerhalb von 15 Schritten auf etwa +0,57 und bleibt dort. Die Validierungsbelohnung bleibt niedriger – hauptsächlich wegen der Temperatur von 1,0 gegenüber 0, und nicht aufgrund von Overfitting (siehe Schritt 7). Die Lösungsrate bei der Validierung steigt in den ersten 10 Schritten von 2 auf 31 Prozent und bewegt sich anschließend zwischen 35 und 48 Prozent. Mit 128 Wörtern sind diese Schwankungen größtenteils Unsinn. Wir haben nicht getestet, ob mehr Schritte bei den Server-Einstellungen helfen.

Die OpenTelemetry-Traces des Runtimes in CloudWatch dokumentieren jede Modellumgebung und jede Tool-Aufruf. Hier ist ein Beispiel für das Spiel, das das trainierte Modell während einer Bewertungsaufgabe spielte (mittlerer Aufwand, Temperatur 1,0), mit gekürztem Argumentieren. Das geheime Wort war PASTE:

[model] Reasoning: [...] "CRANE" has 5 distinct letters: C,R,A,N,E. [...]
We'll guess "CRANE".
Tool call: guess_word(guess="CRANE")
[tool] Guess 1/6: CRANE -> C=gray, R=gray, A=yellow, N=gray, E=green
Current Knowledge:
- Correct Position (Green): _ _ _ _ E
- In Word, Wrong Position (Yellow): 'A' (at least 1)
- Not in Word (Gray): C, N, R
- Guesses Remaining: 5
[model] Reasoning: [...] "ALIVE": ends with E, includes A. Letters not C,N,R.
Tool call: guess_word(guess="ALIVE")
[tool] Guess 2/6: ALIVE -> A=yellow, L=gray, I=gray, V=gray, E=green
[model] Reasoning: [...] So positions not 1 or 3 for A. Positions left: 2,4
for A. [...] We might guess "HASTE"? [...]
Tool call: guess_word(guess="HASTE")
[tool] Guess 3/6: HASTE -> H=gray, A=green, S=green, T=green, E=green
[model] Reasoning: We have the word: _ASTE. [...] "PASTE" is a word. PASTE
fits. Also "WASTE" also fits [...] Choose "PASTE" maybe.
Tool call: guess_word(guess="PASTE")
[tool] Guess 4/6: PASTE --- all green. Correct, you solved it!

Ein Rollout eines trainierten Modells aus dem AgentCore-Runtime-Protokoll. Das Modell behält die grünen Buchstaben an ihren ursprünglichen Positionen bei, verwendet nie wieder graue Buchstaben und nutzt jeden gelben Buchstaben zur Ausschlussung von Positionen – obwohl nichts im Trainingsdatensatz zeigte, wie das gemacht werden soll.

Schritt 7: Bewerten Sie das trainierte Modell bei den Laufzeitumgebungen

Wenn die Aufgabe abgeschlossen ist, zeigt die Seite in SageMaker AI Studio den Status und die Modellpaketgruppe, die das trainierte Modell enthält. Die DescribeJob-Anfrage mit JobCategory auf AgentRFT liefert den ARN des ausgegebenen Modellpakets und die Anzahl der abrechnungsfähigen Tokens.

Abbildung 5: Die abgeschlossene Trainingsaufgabe in SageMaker AI Studio auf der Seite Jobs, Training, Multi-turn RL

Ein Evaluierungsjob (JobCategory auf AgentRFTEvaluation gesetzt>) führt Ihre Evaluationsanweisungen über das gleiche AgentCore-Runtime und die Belohnung aus, egal ob auf dem Basismodell oder dem trainierten Paket, und erzeugt eval/reward/pass_at_1 in MLflow. Im Gegensatz zur Trainingsvalidierung kann das Temperaturlevel eingestellt werden. Der Repository-Launcher führt die Evaluierungen nacheinander aus, da die Standardquoten eine einzelne Evaluierungsjob pro Zeitpunkt erlauben (Sie können eine Erhöhung beantragen):

uv run python run_mtrl_eval.py --runs base:1.0 trained:1.0 \
  --model-package-arn <OUTPUT_MODEL_PACKAGE_ARN> \
  --agent-runtime-arn <RUNTIME_ARN> \
  --role-arn arn:aws:iam::<ACCOUNT>:role/<JOB_ROLE> \
  --dataset s3://<YOUR_BUCKET>/wordle-mtrl/validation/validation-data.jsonl \
  --s3-output-path s3://<YOUR_BUCKET>/wordle-mtrl/eval/ \
  --mlflow-app-arn arn:aws:sagemaker:<REGION>:<ACCOUNT>:mlflow-app/<APP_ID>

Abbildung 6: Rechenanstrengung und Sampling-Temperatur in jeder Phase, wobei die Trainingsaufgabe die Validierung bei Temperatur 0 festlegt und die implementierte Anstrengung bei Bewertungsaufgaben es ermöglicht, die Wahl zu treffen

Jede 128-Wort-Bewertung dauerte vier bis sieben Minuten. Der Rechenaufwand resultiert aus den Umgebungsvariablen des Agenten, sodass man ihn ändern kann, indem man REASONING_EFFORT bearbeitet, neu deployt und dann bewertet. Wir haben beide Modelle bei niedrigem und mittlerem Rechenaufwand sowie bei Temperaturen von 0 und 1,0 evaluiert.

Abbildung 7: Basismodell versus trainiertes Modell unter vier Decodierungseinstellungen, mit Lösungsrate auf der linken Seite und durchschnittlicher Belohnung pro Spiel auf der rechten Seite

Der graue Abschnitt jedes Balkens ist das Basismodell und der blaue Abschnitt ist die Leistung durch Training. Das einfach zu realisierende Paar mit Temperatur-0 ist die Validierung des Trainingsjobs in Schritten 0 und 100. Das mittleren Aufwand erforderliche Ergebnis mit Temperatur-1,0 ist das Mittelwert der zwei Durchläufe (80 und 88 Prozent).

Bei einer Temperatur von 0 beenden beide Modelle oft das Spiel ohne Lösung, bei jedem Aufwand. Bei aktiviertem Sampling fügt eine mittlere Anstrengung dem trainierten Modell 15 Punkte und dem Basismodell 46 Punkte hinzu. Der Adapter fügt in allen Einstellungen 14–54 Punkte hinzu, sodass das Trainerende, was er gelehrt hat, in allen Einstellungen angewandt wird.

Die Validierungskurve des Trainingsjobs in MLflow erzählte eine andere Geschichte: Sie erreichte bei Schritt 90 einen Höchstwert von 48 Prozent und endete bei 37 Prozent, bei Temperatur 0. Die Referenz zu den Hyperparametern empfehlen eine Temperatur von 0 für die Evaluation, da das gierige Decodieren die Kurven deterministisch macht und vergleichbar sind zwischen den Runs. Wir berichten über eine Temperatur von 1,0, weil genau so das Modell bereitgestellt wird. Bei mittlerer Anstrengung und Temperatur 1,0 löst das trainierte Modell 84 Prozent der übrigen Wörter, gegenüber 61 Prozent für das Basismodell.

Tipp: Bewerten Sie die Einstellungen, bei denen Sie das Modul bereitstellen. Die Trainingskurve zeigt, dass dieses Adaptermodul bei 37 Prozent endet. Bei den Bereitstellungseinstellungen löst es 84 Prozent. Die Bewertungsaufgaben, die diesen Kosten von etwa 1,20 US-Dollar in Tokens entsprechen, dauern etwa eine Stunde.

Schritt 8: Reinigen

Die Trainings- und Evaluationstätigkeiten werden nach Abschluss nicht mehr abgerechnet, aber der AgentCore-Runzeitmodus, seine IAM-Rolle, die MLflow-Anwendung und die S3-Objekte bleiben erhalten. Aus dem Projektverzeichnis:

# 1. Agent runtime and its execution role. remove all resets the project config;
# the next deploy sees the empty state and tears down the deployed resources.
cd sample-multi-turn-rl-wordle/Wordle
agentcore remove all
agentcore deploy

# 2. MLflow app
aws sagemaker delete-mlflow-app --arn arn:aws:sagemaker:<REGION>:<ACCOUNT>:mlflow-app/<APP_ID>

# 3. Datasets, job output, and evaluation output
aws s3 rm s3://<YOUR_BUCKET>/wordle-mtrl/ --recursive

Da agentcore remove all die Dateien unter agentcore/ umschreibt, führen Sie git checkout -- agentcore/ aus, wenn Sie später erneut deployen möchten. Das Löschen des AgentCore-Wordle-default CloudFormation-Stacks entfernt dieselben Ressourcen und lässt die Dateien unberührt. Die Trainingsjob-Rolle und die Model-Pakete werden nicht berechnet.

Tiefe Untersuchung: Die Gestaltung der Belohnung

Unsere Belohnung musste nur einmal überarbeitet werden, und der Fehler ist ein allgemeiner Fehler.

Der erste Designvorschlag zählte die Punktzahl pro Vermutung aus dem wordle-lora-rl-Projekt über das gesamte Spiel zusammen. Diese Punktzahl funktioniert dort, weil jede Vermutung ein unabhängiges Trainingsbeispiel ist. Zusammengezählt zu einer Belohnung pro Spiel ergibt sich zwei Inversionen, die wir nur durch das Lesen der Spuren feststellen konnten:

• Ein verlorenes Spiel brachte eine positive Belohnung. Sechs Runden mit Bonusen ergaben zusammen etwa +0,49.
• Die Lösung in Runde 1 war niedriger als die Lösung in Runde 3. Eine Erstansatz-Lösung brachte +0,99, und eine Drittanzungs-Lösung brachte +1,61, da die zusätzlichen Runden mehr Boni einbrachten.

Die Lösung trennt einen dominanten Ergebnisbegriff von einem kleinen, begrenzten Gestaltungsbegriff:

reward = outcome + w * clip(shaping, -1, 1), w = 0.04 if solved, else 0.15

Der Ausgangsbegriff wird ganz entscheidend durch das Ende des Spiels bestimmt:

Der Formgebung-Term ist das Punktesystem nach Schätzung, summiert über das Spiel:

• Strafen für die Widersprüchlichkeit zu einem bekannten grünen, gelben oder grauen Buchstaben, für das wiederholte Vermuten sowie für Wörter, die außerhalb des Wortschatzes liegen.
• Ein Entropie-Bonus für ein starkes Anfangswort.
• Bonusen für das Ausprobieren neuer Buchstaben und für die Verkleinung der Anzahl der verbleibenden Möglichkeiten.

Die Summe wird auf den Bereich [-1, 1] reduziert und für eine Lösung um 0,04, für einen Verlust um 0,15 skaliert, sodass Spiele mit demselben Ergebnis getrennt werden, aber kein Spiel in eine andere Kategorie versetzt wird. Bei typischen Gestaltungswerten:

Eine schnelle Lösung ist immer besser als eine langsame, jede Lösung ist besser als jede Niederlage, und es ist das schlechteste Ergebnis, nie zu spielen. Unser erster Fix verwendete eine Gewichtung von 0,15, was es ermöglichte, eine Guess-3-Lösung mit voller Gestaltung (+1,45) zu gewinnen, während eine Guess-2-Lösung mit der Minimalwertung (+1,25) verlor. Die zugehörigen Guess-Werte liegen 0,1 auseinander, daher entfernt eine kleinere Lösungsgewichtung von 0,04 den Überschuss, und die schlechteste Lösung (+1,01) überwindet immer noch den Erfolgsschwellenwert von 1,0. Die Formung ist weiterhin wichtig, weil das GRPO von der Varianz der Belohnungen innerhalb einer Gruppe lernt. Somit lehren zwei verlorene Spiele, die in Bezug auf die Konsistenz der Hinweise unterschiedlich sind, dem Modell immer noch etwas. Wie die SageMaker AI-Dokumentation empfiehlt: Beginnen Sie mit einer belohnungsbasierten Erfolgsbilanz, fügen Sie die Formung sparsam hinzu und überprüfen Sie die Belohnung auf realen Trajektorien.

Tiefe Untersuchung: Was schiefgegangen ist, in der Reihenfolge, in der es auftritt

Jeder dieser Aufgaben kostet mindestens eine Trainingsrunde.

• Bearer-Token unter Konkurrenzfunktionen. Die Erzeugung eines Tokens mit einer neuen Botocore-Sitzung pro Anruf überlastete den Kreditkartenanbieter bei 32 gleichzeitigen Aktivitäten, und das Speichern der Tokens für eine Stunde führte zu 403-Fehlern, da die Kreditkarten aktualisiert wurden. Die Lösung besteht aus einer selbst-aktualisierenden Sitzung, einem kurzen Cache und einer erneuten Signierung bei 403.
• Eine Ausführung, die nie den Policy-Modell erreicht, scheitert an der gesamten Aufgabe. Wenn jede Modellanfrage in einer Ausführung Authentifizierung versagte, beendete das System die Aufgabe mit „Keine Sampling-Anfragen wurden empfangen.“ Ein Fehlstatus führt ebenfalls zum Scheitern, daher sollte immer eine Belohnung zurückgegeben werden. Ein Spiel, in dem das Modell gesampelt wird, aber nie eine gültige Schätzung erzeugt, ist in Ordnung: Es erhält -1,5 Punkte, und bei einer 100-Schritte-Runde waren 51 dieser Punkte in etwa 105.000 Ausführungen.
• Die Tool-Anrufe driften in reines Textformat. Bei einem zu hohen Lernraten schrieb das Modell Tool-Kommandos als Text, jede Ausführung erhielt denselben Ertrag, und der Gradient verschwand. Der Agent erholt sich nun von den Vermessungen aus Rohtext mit einer kleinen Formatierungsstrafe.
• Das Plateau. Die Trainingsbelohnung hörte nach etwa Schritt 15 auf zu steigen und die Validierung hörte nach etwa Schritt 30 auf zu verbessern, obwohl bei Temperatur 0 die Validierung das Modell unterschätzt (Schritt 7). Ein Curriculum, das Spiele mit vorherigen Annahmen startet oder mehr Ausführungen pro Wort bietet als der Standardwert group_size von 8, wäre das Nächste, was wir versuchen würden.

Schlussfolgerung

MTRL auf SageMaker AI trainiert ein Modell basierend auf den Ergebnissen eines gesamten Episods. Dies passt zu agentischen Aufgaben, bei denen die richtige Trajektorie unbekannt ist und nur das Ergebnis bewertet werden kann. Wir verwendeten eine Belohnung auf Ebene des einzelnen Episods. Wenn auch Zwischenschritte bewertet werden können, akzeptiert MTRL ebenfalls eine Belohnung pro Runde über die UpdateReward API. In diesem Beitrag erreichte ein offenes 20B-Modell bei den Bereitstellungsumständen eine Lösungsrate von 84 Prozent, gegenüber 61 Prozent, für etwa $339 in Trainingstokens und etwa $79 in AgentCore-Runtime-Kosten. Die 37 Prozent, die die Trainingskurve anzeigt, sind ein Effekt der Art und Weise, wie das Trainingsjob die Validierung bewertet, also bewerten Sie die Ergebnisse unter den Umständen, die Sie bereitstellen werden.

Die gleiche Pipeline gilt für interne Prozeduren, Tools und Workflows, auf denen die öffentlichen Modelle nie trainiert wurden.

Um zu beginnen, klonen Sie den Beispiel-Repository, befolgen die vorherigen Schritte und führen den Smoke-Test in Schritt 3 durch, bevor Sie die GPU-Zeit committen. Für die zugrunde liegenden APIs siehe die SageMaker AI MTRL-Dokumentation.

Über die Autoren