Apprentissage par renforcement multi-tours sur Amazon SageMaker AI : un guide pratique

La plupart des fine-tunings apprennent à un modèle à produire une meilleure réponse à une invite unique. Les tâches agentiques sont différentes. Un agent qui remplit une note de frais ou trie un ticket de support accomplit une séquence d'actions, et chaque étape dépend de ce qui a précédé. Il existe rarement une seule séquence correcte à imiter, et le seul retour fiable est de savoir si la séquence entière a réussi. Le fine-tuning supervisé n'a pas de libellés pour cela, et l'apprentissage par renforcement en un seul tour ne peut créditer une décision prise trois étapes avant le résultat.

L'apprentissage par renforcement multi-tours (MTRL) sur Amazon SageMaker AI entraîne des modèles précisément sur ce signal. SageMaker AI envoie des invites à un agent que vous hébergez sur Amazon Bedrock AgentCore, ou sur votre propre infrastructure, telle qu'Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Compute Cloud (Amazon EC2) ou AWS Fargate, via un Transitaire AWS Lambda. L'exemple ici utilise AgentCore. L'agent appelle le modèle de politique en cours d'entraînement, agit dans votre environnement sur autant de tours que la tâche le nécessite, et rapporte une récompense lorsque l'épisode se termine. Vous ne spécifiez pas la trajectoire correcte, seulement comment noter le résultat.

Cet article utilise Wordle, un jeu dans lequel un joueur a six tentatives pour deviner un mot caché de cinq lettres, comme exemple. Après chaque essai, chaque lettre devient verte si elle est à la bonne position, jaune si elle figure dans le mot mais à une autre position, et grise si elle n'est pas dans le mot. Ce jeu convient au MTRL car les règles sont peu nombreuses, chaque essai dépend du retour d'information du précédent, et le résultat est évalué de manière objective. Wordle est un exemple pédagogique, et les modèles de pointe y jouent déjà bien. En pratique, vous utiliseriez le MTRL pour rendre un petit modèle peu coûteux performant sur une tâche en plusieurs étapes propre à votre entreprise, comme un flux de travail interne sur lequel les modèles publics n'ont jamais été entraînés. Le même pipeline s'applique à ce cas de figure.

Dans notre exécution, MTRL a fait passer gpt-oss-20b d'un taux de résolution de 61 à 84 pour cent sur des mots tenus à l'écart à son effort de raisonnement par défaut, et de 15 à 69 pour cent à l'effort faible auquel il a été entraîné, pour environ 339 $ en jetons d'entraînement. Dans cet article, nous parcourons le pipeline de bout en bout : déploiement de l'agent et de la récompense sur AgentCore, préparation du jeu de données, entraînement, supervision dans MLflow et évaluation aux paramètres de service. Nous partageons également les erreurs de conception de récompense et les échecs d'entraînement que nous avons rencontrés. Vos jeux de données, votre agent et votre modèle entraîné restent dans votre compte AWS et ne sont pas utilisées pour entraîner les modèles de base. Tout le code se trouve dans le dépôt aws-samples.

Présentation de la solution

Le système comporte deux moitiés. SageMaker AI gère la tâche d'entraînement et le modèle de politique. AgentCore héberge l'agent, l'environnement Wordle et la fonction de récompense. Le diagramme suivant montre comment ils sont connectés.

Figure 1 : MTRL sur SageMaker AI, où la tâche d'entraînement invoque l'agent hébergé sur AgentCore une fois par déploiement (rollout) pour échantillonner le modèle de politique, jouer au jeu et rapporter une récompense

Pour chaque déploiement, le service MTRL invoque le runtime AgentCore, une capacité d'Amazon Bedrock AgentCore, avec une ligne d'entraînement, qui contient un mot secret. Un agent Strands dans le runtime appelle le modèle de politique via le point de terminaison compatible OpenAI du SageMaker Job Runtime. Le modèle joue jusqu'à six essais à travers un outil, guess_wordet après chaque tentative, l'environnement renvoie un retour lettre par lettre ainsi qu'un résumé de ce qui est connu. Lorsque la partie se termine, l'agent reçoit une récompense. Group Relative Policy Optimization (GRPO) « utilise la répartition des récompenses à travers plusieurs déploiements (rollouts) du même mot pour mettre à jour une adaptation à bas rang (Low-Rank Adaptation, «LoRA) adaptateur sur le modèle de politique.

Trois points de conception comptent pour ce qui suit :

• L'agent et la récompense résident en un seul endroit. Un fichier Python unique déployé sur AgentCore contient l'environnement, l'outil et la fonction de scoring.
• Le jeu de données ne contient que le mot secret. Les listes de mots fournies avec l'agent sont construites à partir du SCOWL listes de mots et ne sont utilisées que pour le score.
• La récompense est dominée par le résultat. Une résolution rapporte 1.05–1.55 selon la vitesse, une défaite rapporte -0.5, et ne jamais faire de devinette valide rapporte -1.5. Un petit terme de modelage récompense une bonne stratégie au sein de chaque palier.

Modèles pris en charge et Régions AWS

MTRL est serverless : vous choisissez un modèle de base et le service provisionne l'infrastructure d'entraînement et d'échantillonnage. Au moment de la rédaction, il prend en charge les modèles de base suivants, chacun entraîné avec un adaptateur LoRA :

Nous avons choisi GPT-OSS-20B parce qu’il présente le prix par token le plus bas des quatre et que son effort de raisonnement est contrôlable par requête. Consultez la documentation MTRL pour la liste actuelle.

Tarification

Vous ne choisissez pas d’instances ni ne dimensionnez un cluster. Vous payez par million de tokens selon trois dimensions, au tarif du modèle de base :

• Préremplissage (Prefill) : tokens d’entrée que le modèle de politique traite. Ceux-ci s’accumulent dans une tâche multi-tours, car chaque tour relit l’historique.
• Échantillonnage (Sample) : tokens que le modèle de politique génère, y compris les tokens de raisonnement.
• Entraînement (Train) : tokens traités lors de la passe arrière qui met à jour l’adaptateur LoRA.

L’exécution de 100 étapes a consommé 491.6 millions de tokens de préremplissage, 159.7 millions de tokens d’échantillonnage et 643.3 millions de tokens d’entraînement sur 105,486 rollouts en 12 heures 40 minutes. Aux GPT-OSS-20B tarifs publics de la Région USA Est (Virginie du Nord) (us-east-1) au moment de la rédaction, cela représente environ 339 $ :

La dimension d’entraînement domine et évolue avec la longueur des trajectoires, donc des parties plus courtes et un raisonnement moins verbeux réduisent la facture. Le runtime AgentCore facture séparément le vCPU et la mémoire utilisés par l’agent. Pour cette exécution, cela représentait environ 79 $, d’après les métriques d’utilisation Amazon CloudWatch du runtime aux tarifs publics de us-east-1. DescribeJob rapporte le nombre de tokens sous BillableTokenUsage. Consultez Amazon SageMaker AI pricing pour les tarifs actuels.

Prérequis

Pour suivre cette procédure pas à pas, vous avez besoin des éléments suivants. Voir aussi les prérequis MTRL.

• Python 3.10 ou version ultérieure, uv, Node 20 ou version ultérieure, et la CLI AgentCore (npm install -g @aws/agentcore). Voir Premiers pas avec Amazon Bedrock AgentCore pour l’installation et les autorisations IAM dont la CLI a besoin.
• botocore 1.43.37 ou version ultérieure, sur la machine qui lance le travail. Il s’agit de la première version qui inclut l’opération AgentRFT CreateJob .
• Deux rôles AWS Identity and Access Management (IAM), décrits à l’étape 1.
• Un compartiment Amazon Simple Storage Service (Amazon S3) dans la même Région que l’agent. Le travail d’entraînement doit également s’exécuter dans cette Région, car CreateJob rejette un ARN d’exécution inter-Régions.

Étape 1 : Créer les rôles IAM

MTRL utilise deux rôles, et l’un d’eux possède une politique de confiance que la documentation générale de SageMaker AI ne mentionne pas.

Rôle d’exécution de l’agent. agentcore deploy crée ce rôle pour vous. Il fait confiance à bedrock-agentcore.amazonaws.com et nécessite la politique gérée AmazonSageMakerJobRuntimeAccess , qui permet à l’agent d’appeler le modèle de politique et de signaler les récompenses. La pile CDK dans le dépôt d’exemple joint automatiquement cette politique.

Rôle du travail d’entraînement. Vous créez celui-ci. Il doit faire confiance à job.sagemaker.amazonaws.com avec à la fois sts:AssumeRole et sts:TagSession, et il nécessite la politique gérée AmazonSageMakerJobFullAccess .

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

Remarque : Le principal de confiance est job.sagemaker.amazonaws.com, et non sagemaker.amazonaws.com. Avec le principal générique, CreateJob échoue avec « Could not assume role », et le message ne nomme le principal correct qu’après plusieurs tentatives.

Étape 2 : Déployer l’agent sur Amazon Bedrock AgentCore

Clonez le dépôt d’exemple, définissez votre compte et votre Région dans Wordle/agentcore/aws-targets.json, puis déployez :

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

La CLI compile les dépendances de l’agent pour la plateforme Linux ARM64 de l’exécution, crée le rôle d’exécution avec AmazonSageMakerJobRuntimeAccess joint, et déploie via AWS CloudFormation. Nous la recommandons plutôt que le téléchargement d’un package de code sur la console, où il est fréquent de se tromper sur les environ 700 Mo de dépendances compilées ou sur la pièce jointe de la politique. Notez l’ARN d’exécution dans la sortie pour le travail d’entraînement.

Figure 2 : L’exécution de l’agent Wordle dans la console Amazon Bedrock AgentCore avec le statut Ready

L'environnement d'exécution lit deux variables d'environnement à partir de agentcore.json. REASONING_EFFORT=low définit reasoning_effort à chaque requête adressée au modèle de politique. Dans nos tâches d'évaluation, l'effort faible a utilisé 63 à 83 pour cent de tokens d'échantillon en moins par partie que l'effort moyen. REASONING_PROMPT_HINT=true ajoute également « Reasoning: low » au prompt système, ce qui correspond à la manière dont gpt-oss lit ce paramètre dans son format de chat Harmony. Aucune de ces deux variables ne donne au modèle le moindre indice sur le mot secret.

Figure 3 : Variables d'environnement d'exécution montrant REASONING_EFFORT réglé sur low

L'agent est un seul fichier, main.py. Sous forme simplifiée, son point d'entrée ressemble à ce qui suit. Pour votre propre tâche, vous modifiez l'analyse de la tâche, les outils et la récompense :

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()}

Important : Le sagemaker_rft_handler le décorateur ne démarre pas de serveur HTTP par lui-même. Enveloppez-le avec BedrockAgentCoreApp et @app.entrypoint, avec le décorateur de point d'entrée le plus à l'extérieur. Sans cela, chaque invocation expire après 30 secondes.

Étape 3 : Vérifier l'environnement d'exécution

Avant de dépenser du temps de GPU, vérifiez que toute la chaîne fonctionne avec une charge utile de même forme que celle qu'envoie le service d'entraînement. Le dépôt en inclut une dans 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"
  }
}

L'ARN du faux poste est censé échouer, et la manière dont il échoue en est la preuve. Insérez d'abord votre propre ID de compte : pour un ARN de poste dans un autre compte, le service renvoie une erreur 403 avant de vérifier si le poste existe, ce qui ressemble à une configuration IAM défectueuse. Depuis le répertoire Wordle, exécutez :

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

Dans les journaux Amazon CloudWatch du runtime, vous voyez l'agent analyser le prompt, s'authentifier auprès du point de terminaison du Job Runtime et recevoir une erreur 400 indiquant « Could not find job ». Cet échec confirme que l'analyse, l'authentification et le signalement des erreurs fonctionnent. La commande elle-même affiche {“reward”: -1.5}, car l'agent n'a jamais atteint le modèle de politique. Une erreur 403 indiquant « not authorized to access this resource » signifie que l'ARN du travail désigne toujours un autre compte. Un délai d'attente de 30 secondes signifie plutôt que le serveur HTTP ne démarre pas (voir la remarque Important à l'Étape 2).

Étape 4 : Préparer le jeu de données

Le jeu de données MTRL ne contient ni réponses cibles, ni transcriptions, ni étiquettes. Chaque ligne correspond à une tâche que l'agent doit tenter d'accomplir. Voici les trois premières lignes du fichier d'entraînement :

{"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\"}"}

Le service lit le prompt colonne (ou la première colonne) et transmet la chaîne à votre agent telle quelle, sans l'analyser. Nous avons fait de cette chaîne un petit objet JSON avec trois champs :

• prompt : l'instruction que l'agent montre au modèle de politique, identique sur chaque ligne.
• answer : le mot secret. Seuls l'environnement et la fonction de récompense l'utilisent. Le modèle de politique ne le voit jamais.
• id : un identifiant de ligne permettant de retracer un rollout dans les journaux jusqu'à sa ligne d'origine.

Le dépôt d'exemple make_dataset.py tire 640 mots d'entraînement (cinq lots complets de 128) et 128 mots de validation de la liste de réponses sans chevauchement, de sorte que le taux de résolution sur la validation mesure la généralisation. Le service accepte également Apache Parquet, les tableaux JSON et le CSV. Téléchargez les deux fichiers vers Amazon S3 :

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/

Comme le service n'inspecte jamais la chaîne prompt , une tâche de production peut y regrouper une liste complète de messages, une configuration d'outils ou une spécification de récompense. Consultez la documentation MTRL pour des exemples, notamment sur la façon de protéger du contenu sensible dans la chaîne.

Étape 5 : Lancer le travail d'entraînement

Le lanceur utilise la classe MultiTurnRLTrainer du SDK sagemaker-train . Pointez-la vers l'ARN du runtime de l'Étape 2, le rôle de l'Étape 1, les jeux de données de l'Étape 4 et une application MLflow pour les métriques. L'application MLflow est obligatoire ; si vous n'en avez pas, créez-en d'abord une avec 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>

Le lanceur remplace trois hyperparamètres et laisse tous les autres à leur valeur par défaut de gpt-oss-20b. Il définit sampling_max_tokens à 8192, le maximum du service, car à la valeur par défaut de 4096, gpt-oss manquait souvent de jetons pendant le raisonnement, avant son premier appel d’outil. Il définit max_epochs à 20 et max_steps à 100 : 640 lignes à la valeur par défaut global_batch_size de 128 font 5 étapes par époque, et avec la valeur par défaut group_size de 8, chaque étape joue 1,024 jeux. Le travail passe par Starting, Downloading et Pending avant d’atteindre Training. Une fois l’entraînement lancé, votre runtime AgentCore commence à recevoir des invocations de rollout.

Important : Ne redéployez pas l’agent pendant qu’un travail est en cours. Le redéploiement redémarre le runtime, les rollouts en cours ne voient aucune requête d’échantillonnage, et le service fait échouer tout le travail.

Étape 6 : Suivre l’entraînement dans MLflow

Le service consigne les statistiques de récompense, de jetons et de tours à chaque étape et exécute une validation tous les val_every étapes. La métrique à surveiller est val/reward/pass_at_1, la fraction des mots de réserve résolus. Chaque résolution rapporte au moins 1.01, ce qui dépasse le seuil success_threshold du service de 1.0 et pass@1 la compte. Le graphique suivant est construit à partir de l’historique MLflow de cette exécution :

Figure 4 : Courbes d’entraînement pour l’exécution de 100 étapes, avec la récompense moyenne par jeu à gauche et le taux de résolution en validation à droite

La récompense d’entraînement grimpe à environ +0.57 en 15 étapes et s’y maintient. La récompense en validation reste plus basse, principalement à cause de la température 1.0 contre 0 plutôt que d’un surapprentissage (voir Étape 7). Le taux de résolution en validation passe de 2 à 31 pour cent au cours des 10 premières étapes, puis évolue entre 35 et 48 pour cent. Avec 128 mots, ces variations relèvent surtout du bruit. Nous n’avons pas testé si davantage d’étapes aident aux réglages de service.

Les traces OpenTelemetry du runtime dans CloudWatch enregistrent chaque tour de modèle et chaque appel d’outil. Voici un jeu joué par le modèle entraîné lors d’un travail d’évaluation (effort moyen, température 1.0), avec le raisonnement retiré. Le mot secret était 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!

Un rollout du modèle entraîné issu des traces du runtime AgentCore. Le modèle conserve les lettres vertes en place, ne réutilise jamais une lettre grise et utilise chaque lettre jaune pour éliminer des positions, alors que rien dans les données d’entraînement ne lui a montré comment faire.

Étape 7 : Évaluer le modèle entraîné aux réglages de service

Lorsque le travail se termine, sa page dans SageMaker AI Studio affiche le statut et le groupe de packages de modèles contenant le modèle entraîné. DescribeJob, avec JobCategory défini sur AgentRFT, renvoie l'ARN du package de modèles de sortie et le nombre de jetons facturables.

Figure 5 : Le travail d'entraînement terminé dans SageMaker AI Studio sur l'onglet Jobs, Training, Multi-turn RL

Un travail d'évaluation (JobCategory défini sur AgentRFTEvaluation) joue vos invites d'évaluation via le même runtime AgentCore et la même récompense, sur le modèle de base ou le package entraîné, et journalise eval/reward/pass_at_1 dans MLflow. Contrairement à la validation de l'entraînement, vous pouvez définir la température. Le lanceur du dépôt exécute les évaluations dos à dos, car le quota par défaut n'autorise qu'un seul travail d'évaluation à la fois (vous pouvez demander une augmentation):

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>

Figure 6 : Effort de raisonnement et température d'échantillonnage à chaque étape, où le travail d'entraînement fixe la validation à température 0 et l'effort déployé, tandis que les travaux d'évaluation vous laissent le choix

Chaque évaluation de 128 mots a pris quatre à sept minutes. L'effort de raisonnement provient des variables d'environnement de l'agent ; pour le modifier, vous éditez REASONING_EFFORT, redéployez et évaluez. Nous avons évalué les deux modèles à effort faible et moyen, et à température 0 et 1.0 :

Figure 7 : Modèle de base par rapport au modèle entraîné sous quatre paramètres de décodage, avec le taux de résolution à gauche et la récompense moyenne par partie à droite

Le segment gris de chaque barre est le modèle de base et le segment bleu est le gain apporté par l'entraînement. La paire effort faible, température 0 correspond à la validation du travail d'entraînement aux étapes 0 et 100. Le résultat entraîné effort moyen, température 1.0 est la moyenne de deux exécutions (80 et 88 pour cent).

À température 0, les deux modèles terminent souvent la partie sans résolution, quel que soit l'effort. Avec l'échantillonnage activé, l'effort moyen ajoute 15 points pour le modèle entraîné et 46 pour le modèle de base. L'adaptateur ajoute 14 à 54 points dans chaque configuration, donc ce que l'entraînement a enseigné se transfère d'une configuration à l'autre.

La courbe de validation propre du travail d'entraînement dans MLflow racontait une autre histoire : elle a culminé à 48 pour cent à l'étape 90 et s'est terminée à 37 pour cent, notée à température 0. La référence des hyperparamètres recommande la température 0 pour l'évaluation, car le décodage glouton rend les courbes déterministes et comparables entre les exécutions. Nous rapportons la température 1.0 parce que c'est ainsi que nous servons le modèle. À effort moyen et température 1.0, le modèle entraîné résout 84 pour cent des mots retenus, contre 61 pour cent pour le modèle de base.

Astuce : Évaluez aux paramètres auxquels vous servirez le modèle. La courbe d'entraînement indique que cet adaptateur se termine à 37 pour cent. Aux paramètres de service, il résout 84 pour cent. Les travaux d'évaluation qui le montrent coûtent environ 1.20 $ en jetons et ont pris environ une heure.

Étape 8 : Nettoyage

Les travaux d'entraînement et d'évaluation cessent d'être facturés une fois terminés, mais le runtime AgentCore, son rôle IAM, l'application MLflow et les objets S3 persistent. Depuis le répertoire du projet :

# 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

Parce que agentcore remove all réécrit les fichiers sous agentcore/, exécutez git checkout -- agentcore/ si vous souhaitez redéployer plus tard. La suppression de la pile AgentCore-Wordle-default CloudFormation supprime les mêmes ressources et laisse les fichiers intacts. Le rôle du travail d'entraînement et les packages de modèles ne sont pas facturés.

Analyse approfondie : Concevoir la récompense

Notre récompense a nécessité une révision, et l'erreur est une erreur courante.

La première conception additionnait la notation par essai du wordle-lora-rl sur l'ensemble de la partie. Ce fonctionnement du scoring fonctionne là-bas car chaque devinette est un échantillon d'entraînement indépendant. Additionné en une seule récompense par partie, il a produit deux inversions que nous n'avons découvertes qu'en lisant les traces :

• Une partie perdue rapportait une récompense positive. Six tours de bonus s'additionnaient pour atteindre environ +0.49.
• Résoudre au tour 1 rapportait moins que résoudre au tour 3. Une résolution dès la première devinette rapportait +0.99 et une résolution à la troisième devinette rapportait +1.61, car les tours supplémentaires accumulaient plus de bonus.

La correction sépare un terme de résultat dominant d'un petit terme de façonnage borné :

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

Le terme de résultat est déterminé entièrement par la façon dont la partie s'est terminée :

Le terme de façonnage est ce score par devinette, additionné sur la partie :

• Des pénalités pour avoir contredit une lettre verte, jaune ou grise connue, pour avoir répété une devinette, et pour des mots hors du dictionnaire.
• Un bonus d'entropie pour un mot d'ouverture fort.
• Des bonus pour avoir essayé de nouvelles lettres et pour avoir réduit l'ensemble des possibilités restantes.

La somme est bornée à [-1, 1] et multipliée par 0.04 pour une réussite et 0.15 pour une défaite, de sorte qu'elle distingue les parties ayant le même résultat mais ne fait jamais passer une partie dans un autre niveau. Avec des valeurs de façonnage typiques :

Une résolution rapide bat désormais toujours une résolution plus lente, chaque résolution bat chaque défaite, et ne jamais jouer est le pire résultat. Notre première correction utilisait un poids unique de 0.15, ce qui permettait à une résolution en tentative 3 avec façonnage complet (+1.45) de dépasser une résolution en tentative 2 avec le minimum (+1.25). Les nombres de tentatives adjacents sont distants de 0.1, donc un poids de résolution plus petit de 0.04 supprime ce chevauchement, et la pire résolution (+1.01) dépasse toujours le seuil de succès de 1.0. Le façonnage reste important car GRPO apprend à partir de la variance des récompenses au sein d'un groupe, ainsi deux parties perdues différant par la cohérence des indices apprennent quand même quelque chose au modèle. Comme le conseille la documentation SageMaker AI, commencez par une récompense basée sur le résultat, ajoutez du façonnage avec parcimonie et vérifiez la récompense sur des trajectoires réelles.

Analyse approfondie : Ce qui s'est mal passé, dans l'ordre où vous le rencontrerez

Chacun de ces problèmes a coûté au moins une exécution d'entraînement.

• Jetons Bearer sous concurrence. La création d'un jeton avec une nouvelle session botocore à chaque appel a affamé le fournisseur d'identifiants à 32 rollouts concurrents, et la mise en cache des jetons pendant une heure renvoyait des erreurs 403 lorsque les identifiants tournaient. La solution est une seule session auto-rafraîchie, un cache court, et une re-signature en cas de 403.
• Un rollout qui n'atteint jamais le modèle de politique fait échouer toute la tâche. Lorsque chaque appel de modèle dans un rollout échouait à l'authentification, le service terminait la tâche avec « No sampling requests were received. » Renvoyer un statut d'erreur la fait échouer aussi, alors renvoyez toujours une récompense. Une partie où le modèle est interrogé mais ne fait jamais de tentative valide est acceptable : elle obtient -1.5, et l'exécution de 100 étapes en comptait 51 sur environ 105,000 rollouts.
• Les appels d'outils dérivent en texte brut. À un taux d'apprentissage trop élevé, le modèle écrivait les appels d'outils en texte, chaque rollout recevait la même récompense plancher, et le gradient disparaissait. L'agent récupère désormais les tentatives à partir du texte brut avec une légère pénalité de formatage.
• Le plateau. La récompense d'entraînement a cessé d'augmenter après environ l'étape 15 et la validation a cessé de s'améliorer après environ l'étape 30, bien qu'à température 0 la validation sous-estime le modèle (Étape 7). Un programme qui amorce des parties avec des tentatives antérieures, ou davantage de rollouts par mot que la valeur par défaut group_size de 8, est ce que nous essaierions ensuite.

Conclusion

MTRL sur SageMaker AI entraîne un modèle sur le résultat d'un épisode complet. Cela convient aux tâches agentiques, où la bonne trajectoire est inconnue et seul le résultat peut être noté. Nous avons utilisé une seule récompense au niveau de l'épisode. Lorsque des étapes intermédiaires peuvent aussi être notées, MTRL accepte également une récompense par tour via l' API UpdateReward. Dans cet article, un modèle ouvert de 20B a atteint un taux de résolution de 84 pour cent aux paramètres de service, contre 61 pour cent auparavant, pour environ 339 $ de jetons d'entraînement et environ 79 $ d'utilisation du runtime AgentCore. Les 37 pour cent que la courbe d'entraînement rapporte sont un artefact de la façon dont la tâche d'entraînement note la validation ; évaluez donc aux paramètres que vous servirez.

Le même pipeline s'applique aux procédures internes, aux outils et aux flux de travail sur lesquels les modèles publics n'ont jamais été entraînés.

Pour commencer, clonez le dépôt d'exemple, suivez les étapes précédentes et exécutez le test de fumée à l'Étape 3 avant d'engager du temps GPU. Pour les API sous-jacentes, consultez la documentation MTRL de SageMaker AI.

À propos des auteurs