La mayoría de la afinación enseña a un modelo a producir una mejor respuesta a una sola llamada. Las tareas agénticas son diferentes. Un agente que presenta un informe de gastos o triagea un ticket de soporte toma una secuencia de acciones, y cada paso depende de lo que sucedió antes. Rara vez hay una secuencia correcta para imitar, y la única retroalimentación confiable es si toda la secuencia tuvo éxito. La afinación supervisada no tiene etiquetas para eso, y el aprendizaje de refuerzo de un solo turno no puede acreditar una decisión tomada tres pasos antes del resultado.

El Aprendizaje de Refuerzo de Varios Turnos (MTRL) en Amazon SageMaker AI entrena modelos en exactamente esa señal. SageMaker AI envía llamadas a un agente que hospedas en Amazon Bedrock AgentCore, o en tu propia infraestructura, como Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Compute Cloud (Amazon EC2) o AWS Fargate, a través de un reenviador de AWS Lambda. El ejemplo aquí utiliza AgentCore. El agente llama al modelo de política que se está entrenando, actúa en tu entorno durante tantos turnos como necesite la tarea y informa una recompensa cuando finaliza el episodio. No especificas la trayectoria correcta, solo cómo puntuar el resultado.

Esta publicación utiliza Wordle, un juego en el que un jugador tiene seis intentos para adivinar una palabra oculta de cinco letras, como ejemplo. Después de cada intento, cada letra se vuelve verde si está en la posición correcta, amarilla si está en la palabra pero en una posición diferente, y gris si no está en la palabra. El juego se adapta a MTRL porque las reglas son pocas, cada intento depende de la retroalimentación del último y el resultado se puntuación de manera objetiva. Wordle es un ejemplo de enseñanza, y los modelos fronterizos ya lo juegan bien. En la práctica, utilizarías MTRL para hacer que un modelo pequeño y de bajo costo sea bueno en una tarea de varios pasos específica de tu negocio, como un flujo de trabajo interno que los modelos públicos nunca se entrenaron. La misma canalización se aplica a ese entorno.

En nuestra ejecución, MTRL tomó gpt-oss-20b de una tasa de resolución del 61 por ciento a una del 84 por ciento en palabras retenidas a su esfuerzo de razonamiento predeterminado, y del 15 por ciento al 69 por ciento en el esfuerzo bajo en el que se entrenó, por aproximadamente $339 en tokens de entrenamiento. En esta publicación, recorremos la canalización de extremo a extremo: implementar el agente y la recompensa en AgentCore, preparar el conjunto de datos, entrenar, monitorear en MLflow y evaluar en la configuración de servicio. También compartimos los errores de diseño de recompensa y los fallos de entrenamiento que encontramos. Tus conjuntos de datos, agente y modelo entrenado permanecen en tu cuenta de AWS y no se utilizan para entrenar los modelos base. Todo el código está en el repositorio aws-samples acompañante.

Visión general de la solución

El sistema tiene dos mitades. SageMaker AI posee el trabajo de entrenamiento y el modelo de política. AgentCore hospeda el agente, el entorno de Wordle y la función de recompensa. El siguiente diagrama muestra cómo se conectan.

Figura 1: MTRL en SageMaker AI, donde el trabajo de entrenamiento invoca al agente hospedado en AgentCore una vez por rollout para muestrear el modelo de política, jugar el juego y reportar una recompensa

Para cada rollout, el servicio MTRL invoca el runtime de AgentCore, una capacidad de Amazon Bedrock AgentCore, con una fila de entrenamiento, que contiene una palabra secreta. Un agente Strands en el runtime llama al modelo de política a través del endpoint OpenAI compatible del SageMaker Job Runtime. El modelo juega hasta seis intentos a través de una herramienta, guess_word, y después de cada intento, el entorno devuelve una retroalimentación por letra y un resumen de lo que se conoce. Cuando el juego termina, el agente devuelve una recompensa. Group Relative Policy Optimization (GRPO) utiliza la dispersión de recompensas en varios rollouts de la misma palabra para actualizar un adaptador de adaptación de bajo rango (LoRA) en el modelo de política.

Tres puntos de diseño son importantes para lo que sigue:

• El agente y la recompensa viven en un solo lugar. Un solo archivo Python desplegado en AgentCore contiene el entorno, la herramienta y la función de puntuación.
• El conjunto de datos solo lleva la palabra secreta. Las listas de palabras empaquetadas con el agente se construyen a partir de las listas de palabras de código abierto SCOWL y se utilizan solo para puntuar.
• La recompensa es dominante en el resultado. Una solución paga 1,05-1,55 dependiendo de la velocidad, una pérdida paga -0,5 y nunca hacer una suposición válida paga -1,5. Un pequeño término de modelado recompensa una buena estrategia dentro de cada nivel.

Modelos y regiones de AWS compatibles

MTRL es servidorless: selecciona un modelo base y el servicio provisiona la infraestructura de entrenamiento y muestreo. En el momento de la escritura, es compatible con los siguientes modelos base, cada uno entrenado con un adaptador LoRA:

Elegimos GPT-OSS-20B porque tiene el precio por token más bajo de los cuatro y su esfuerzo de razonamiento es controlable por solicitud. Consulte la documentación de MTRL para la lista actual.

Precios

No elige instancias ni dimensiona un cluster. Paga por millón de tokens en tres dimensiones, con precios según el modelo base:

• Prefill: tokens de entrada que el modelo de política procesa. Estos se acumulan en una tarea de varias vueltas, porque cada vuelta vuelve a leer el historial.
• Sample: tokens que el modelo de política genera, incluidos tokens de razonamiento.
• Train: tokens procesados en el paso hacia atrás que actualiza el adaptador LoRA.

La ejecución de 100 pasos consumió 491,6 millones de tokens prefill, 159,7 millones de tokens sample y 643,3 millones de tokens train en 105.486 despliegues en 12 horas y 40 minutos. A los precios de lista de GPT-OSS-20B en la región Este de EE. UU. (N. Virginia) (us-east-1) en el momento de la escritura, eso es aproximadamente $339:

La dimensión de entrenamiento domina y se escala con la longitud de la trayectoria, por lo que juegos más cortos y razonamientos menos verbosos reducen la factura. El tiempo de ejecución de AgentCore factura por separado por la vCPU y la memoria que utiliza el agente. Para esta ejecución, eso fue aproximadamente $79, según las métricas de uso de Amazon CloudWatch del tiempo de ejecución en los precios de lista de us-east-1. DescribeJob informa los recuentos de tokens bajo BillableTokenUsage. Consulte precios de Amazon SageMaker AI para las tarifas actuales.

Requisitos previos

Para seguir este tutorial, necesitas lo siguiente. Consulta también los requisitos previos de MTRL.

• Python 3.10 o posterior, uv, Node 20 o posterior, y la CLI de AgentCore (npm install -g @aws/agentcore). Consulta Introducción a Amazon Bedrock AgentCore para la instalación y los permisos de IAM que necesita la CLI.
• botocore 1.43.37 o posterior, en la máquina que lanza el trabajo. Esta es la primera versión que incluye la operación AgentRFT CreateJob.
• Dos roles de AWS Identity and Access Management (IAM), descritos en el Paso 1.
• Un bucket de Amazon Simple Storage Service (Amazon S3) en la misma región que el agente. El trabajo de entrenamiento también debe ejecutarse en esa región, porque CreateJob rechaza un ARN de tiempo de ejecución entre regiones.

Paso 1: Crear los roles de IAM

MTRL utiliza dos roles, y uno de ellos tiene una política de confianza que la documentación general de SageMaker AI no menciona.

Role de tiempo de ejecución del agente. agentcore deploy crea este rol para usted. Confía en bedrock-agentcore.amazonaws.com y necesita la política administrada AmazonSageMakerJobRuntimeAccess, que permite que el agente llame al modelo de política e informe recompensas. La pila de CDK en el repositorio de muestra adjunta esta política automáticamente.

Role del trabajo de entrenamiento. Usted crea este rol. Debe confiar en job.sagemaker.amazonaws.com con sts:AssumeRole y sts:TagSession, y necesita la política administrada AmazonSageMakerJobFullAccess.

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

Nota: El principal de confianza es job.sagemaker.amazonaws.com, no sagemaker.amazonaws.com. Con el principal genérico, CreateJob falla con “No se pudo asumir el rol”, y el mensaje nombra al principal correcto solo después de los reintentos.

Paso 2: Implementar el agente en Amazon Bedrock AgentCore

Clona el repositorio de muestra, establece su cuenta y región en Wordle/agentcore/aws-targets.json, e implementa:

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 construye las dependencias del agente para la plataforma Linux ARM64 del tiempo de ejecución, crea el rol de ejecución con AmazonSageMakerJobRuntimeAccess adjunto e implementa a través de AWS CloudFormation. Lo recomendamos sobre la carga de un paquete de código en la consola, donde es común obtener incorrectas las aproximadamente 700 MB de dependencias compiladas o el adjunto de la política. Anote el ARN de tiempo de ejecución en la salida para el trabajo de entrenamiento.

Figura 2: El runtime del agente Wordle en la consola de Amazon Bedrock AgentCore con estado Listo

El runtime lee dos variables de entorno de agentcore.json. REASONING_EFFORT=low establece reasoning_effort en cada solicitud al modelo de política. En nuestros trabajos de evaluación, el esfuerzo bajo utilizó de 63 a 83 por ciento menos tokens de muestra por juego que el esfuerzo medio. REASONING_PROMPT_HINT=true también agrega “Razonamiento: bajo” al prompt del sistema, que es cómo gpt-oss lee la configuración en su formato de chat Harmony. Ninguna variable da al modelo ninguna pista sobre la palabra secreta.

Figura 3: Variables de entorno de runtime que muestran REASONING_EFFORT establecido en bajo

El agente es un archivo, main.py. Simplificado, su punto de entrada se parece al siguiente. Para tu propia tarea, cambias el análisis de la tarea, las herramientas y la recompensa:

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

Importante: El decorador sagemaker_rft_handler no inicia un servidor HTTP por sí solo. Envuélvelo con BedrockAgentCoreApp y @app.entrypoint, con el decorador de punto de entrada más externo. Sin esto, cada invocación caduca después de 30 segundos.

Paso 3: Verificar el runtime

Antes de gastar tiempo de GPU, confirma que toda la cadena funciona con una carga útil con forma similar a la que envía el servicio de entrenamiento. El repositorio incluye una como 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"
  }
}

Se espera que el ARN de trabajo falso falle, y la forma en que falla es la prueba. Coloca tu propio ID de cuenta en él primero: para un ARN de trabajo en otra cuenta, el servicio devuelve un 403 antes de verificar si el trabajo existe, lo que parece una configuración de IAM rota. Desde el directorio de Wordle, ejecuta:

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

En los registros de Amazon CloudWatch del runtime, ve el agente analizar la solicitud, autenticarse en el punto de conexión de Job Runtime y recibir un error 400 que dice “No se pudo encontrar el trabajo”. Ese error confirma que el análisis, la autenticación y la informe de errores funcionan. El comando mismo imprime {“reward”: -1.5}, porque el agente nunca alcanzó el modelo de política. Un error 403 que dice “no autorizado para acceder a este recurso” significa que el ARN del trabajo aún tiene el nombre de otra cuenta. Un tiempo de espera de 30 segundos en su lugar significa que el servidor HTTP no se está iniciando (consulte la nota importante en el paso 2).

Paso 4: Preparar el conjunto de datos

El conjunto de datos MTRL no tiene respuestas de destino, transcripciones o etiquetas. Cada fila es una tarea que el agente intentará realizar. A continuación, se muestran las primeras tres filas del archivo de entrenamiento:

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

El servicio lee la columna prompt (o la primera columna) y pasa la cadena al agente tal como está, sin analizarla. Hicimos que la cadena fuera un pequeño objeto JSON con tres campos:

• prompt: la instrucción que el agente muestra al modelo de política, idéntica en cada fila.
• answer: la palabra secreta. Solo el entorno y la función de recompensa la utilizan. El modelo de política nunca la ve.
• id: un ID de fila para rastrear una ejecución en los registros hasta su fila de origen.

El repositorio de ejemplo make_dataset.py dibuja 640 palabras de entrenamiento (cinco lotes completos de 128) y 128 palabras de validación de la lista de respuestas sin superposición, por lo que la tasa de resolución de validación mide la generalización. El servicio también acepta Apache Parquet, matrices JSON y CSV. Cargue ambos archivos en 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/

Como el servicio nunca inspecciona la cadena prompt, una tarea de producción puede empaquetar una lista de mensajes completa, una configuración de herramientas o una especificación de recompensa en ella. Consulte la documentación de MTRL para obtener ejemplos, incluido cómo proteger el contenido sensible en la cadena.

Paso 5: Iniciar el trabajo de entrenamiento

El lanzador utiliza la clase MultiTurnRLTrainer del SDK sagemaker-train. Apúntelo al ARN de runtime del paso 2, el rol del paso 1, los conjuntos de datos del paso 4 y una aplicación MLflow para métricas. La aplicación MLflow es obligatoria, así que si no tiene una, créela primero con 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>

El lanzador anula tres hiperparámetros y deja todos los demás en el valor predeterminado de gpt-oss-20b. Establece sampling_max_tokens en 8192, el máximo del servicio, porque con el valor predeterminado de 4096, gpt-oss a menudo se quedaba sin tokens mientras razonaba, antes de su primera llamada a una herramienta. Establece max_epochs en 20 y max_steps en 100: 640 filas con el valor predeterminado global_batch_size de 128 son 5 pasos por época, y con el valor predeterminado group_size de 8, cada paso juega 1,024 juegos. El trabajo pasa por los estados Iniciando, Descargando y Pendiente antes de llegar a Entrenamiento. Después de que comienza el entrenamiento, el runtime de AgentCore comienza a recibir invocaciones de rollout.

Importante: No redepliegue el agente mientras un trabajo esté en ejecución. Redeployar reinicia el runtime, las rollouts en vuelo no reciben solicitudes de muestreo y el servicio falla todo el trabajo.

Paso 6: Monitorear el entrenamiento en MLflow

El servicio registra estadísticas de recompensa, token y turno en cada paso y ejecuta validación cada val_every pasos. La métrica a observar es val/reward/pass_at_1, la fracción de palabras retenidas resueltas. Cada resolución obtiene una puntuación de al menos 1.01, por lo que supera el umbral success_threshold del servicio de 1.0 y pass@1 lo cuenta. El siguiente gráfico se construye a partir de la historia de MLflow de esta ejecución:

Figura 4: Curvas de entrenamiento para la ejecución de 100 pasos, con la recompensa media por juego a la izquierda y la tasa de resolución de validación a la derecha

La recompensa de entrenamiento asciende a aproximadamente +0.57 dentro de 15 pasos y se mantiene allí. La recompensa de validación se mantiene más baja, en su mayoría debido a la temperatura 1.0 versus 0 en lugar de sobreajuste (ver Paso 7). La tasa de resolución de validación salta del 2 al 31 por ciento en los primeros 10 pasos, luego se mueve entre el 35 y el 48 por ciento. Con 128 palabras, esos cambios son en su mayoría ruido. No probamos si más pasos ayudan en la configuración de servicio.

Las trazas de OpenTelemetry del runtime en CloudWatch registran cada turno del modelo y llamada a una herramienta. Aquí hay un juego que el modelo entrenado jugó durante un trabajo de evaluación (esfuerzo medio, temperatura 1.0), con el razonamiento recortado. La palabra secreta era 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 del modelo entrenado desde las trazas del runtime de AgentCore. El modelo mantiene las letras verdes en su lugar, nunca reutiliza una letra gris y usa cada letra amarilla para descartar posiciones, aunque nada en los datos de entrenamiento le mostró cómo hacerlo.

Paso 7: Evaluar el modelo entrenado en la configuración de servicio

Una vez que el trabajo se completa, su página en SageMaker AI Studio muestra el estado y el grupo de paquetes de modelos que contiene el modelo entrenado. DescribeJob, con JobCategory establecido en AgentRFT, devuelve el ARN del paquete de modelos de salida y los recuentos de tokens facturables.

Figura 5: El trabajo de entrenamiento completado en SageMaker AI Studio en la pestaña Trabajos, Entrenamiento, RL de varias vueltas

Un trabajo de evaluación (JobCategory establecido en AgentRFTEvaluation) reproduce los prompts de evaluación a través del mismo entorno de ejecución AgentCore y recompensa, en el modelo base o el paquete entrenado, y registra eval/reward/pass_at_1 en MLflow. A diferencia de la validación de entrenamiento, puede establecer la temperatura. El lanzador del repositorio ejecuta las evaluaciones una tras otra, porque la cuota predeterminada permite un trabajo de evaluación a la vez (puede solicitar un aumento):

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>

Figura 6: Esfuerzo de razonamiento y temperatura de muestreo en cada etapa, donde el trabajo de entrenamiento fija la validación a temperatura 0 y el esfuerzo desplegado, mientras que los trabajos de evaluación le permiten elegir

Cada evaluación de 128 palabras tomó de cuatro a siete minutos. El esfuerzo de razonamiento proviene de las variables de entorno del agente, por lo que para cambiarlo, edita REASONING_EFFORT, vuelve a implementar y evalúa. Evaluamos ambos modelos a bajo y medio esfuerzo y a temperatura 0 y 1.0:

Figura 7: Modelo base versus modelo entrenado bajo cuatro configuraciones de descodificación, con la tasa de resolución a la izquierda y la recompensa media por juego a la derecha

El segmento gris de cada barra es el modelo base y el segmento azul es la ganancia del entrenamiento. El par de esfuerzo bajo y temperatura 0 es la validación del trabajo de entrenamiento en los pasos 0 y 100. El resultado entrenado de esfuerzo medio y temperatura 1,0 es el promedio de dos ejecuciones (80 y 88 por ciento).

A temperatura 0, ambos modelos a menudo terminan el juego sin resolver, en cualquier esfuerzo. Con muestreo activado, el esfuerzo medio agrega 15 puntos para el modelo entrenado y 46 para el modelo base. El adaptador agrega 14–54 puntos en cada configuración, por lo que lo que el entrenamiento enseñó se transfiere entre configuraciones.

La curva de validación del trabajo de entrenamiento en MLflow contó una historia diferente: alcanzó un máximo del 48 por ciento en el paso 90 y terminó en 37 por ciento, evaluado a temperatura 0. La referencia de hiperparámetros recomienda temperatura 0 para la evaluación porque la descodificación codiciosa hace que las curvas sean determinísticas y comparables entre ejecuciones. Informamos temperatura 1,0 porque así es como servimos el modelo. A esfuerzo medio y temperatura 1,0, el modelo entrenado resuelve el 84 por ciento de las palabras retenidas, en comparación con el 61 por ciento del modelo base.

Consejo: Evalúe en las configuraciones que servirá. La curva de entrenamiento dice que este adaptador termina en 37 por ciento. En las configuraciones de servicio, resuelve el 84 por ciento. Los trabajos de evaluación que muestran esto cuestan alrededor de $1,20 en tokens y tardan alrededor de una hora.

Paso 8: Limpieza

Los trabajos de entrenamiento y evaluación dejan de facturarse cuando se completan, pero el runtime de AgentCore, su rol de IAM, la aplicación de MLflow y los objetos de S3 persisten. Desde el directorio del proyecto:

# 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

Como agentcore remove all reescribe los archivos bajo agentcore/, ejecute git checkout -- agentcore/ si desea volver a implementar. Eliminar la pila de CloudFormation AgentCore-Wordle-default elimina los mismos recursos y deja los archivos intactos. El rol del trabajo de entrenamiento y los paquetes del modelo no se facturan.

Análisis detallado: Diseñar la recompensa

Nuestra recompensa necesitó una revisión y el error es común.

El primer diseño sumó la puntuación por suposición del proyecto wordle-lora-rl en todo el juego. Esa puntuación funciona allí porque cada suposición es una muestra de entrenamiento independiente. Sumada en una sola recompensa por juego, produjo dos inversiones que solo encontramos leyendo trazas:

• Un juego perdido pagó una recompensa positiva. Seis turnos de bonificaciones sumaron aproximadamente +0.49.
• Resolver en el turno 1 obtuvo una puntuación inferior a resolver en el turno 3. Una resolución en la primera suposición obtuvo +0.99 y una resolución en la tercera suposición obtuvo +1.61, porque los turnos adicionales recogieron más bonificaciones.

La solución separa un término de resultado dominante de un término de modelado pequeño y acotado:

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

El término de resultado se establece enteramente por cómo terminó el juego:

El término de modelado es esa puntuación por suposición, sumada en todo el juego:

• Penalizaciones por contradecir una letra verde, amarilla o gris conocida, por repetir una suposición y por palabras fuera del diccionario.
• Una bonificación de entropía para una palabra de apertura fuerte.
• Bonificaciones por intentar letras nuevas y por reducir el conjunto de posibilidades restantes.

La suma se recorta a [-1, 1] y se escala por 0.04 para una resolución y 0.15 para una pérdida, así que separa juegos con el mismo resultado pero nunca mueve un juego a otro nivel. Con valores de modelado típicos:

Una solución más rápida siempre supera a una más lenta, toda solución supera a toda pérdida y nunca jugar es el peor resultado. Nuestra primera solución utilizó un solo peso de 0.15, lo que permitió que una solución de adivinanza-3 con forma completa (+1.45) superara a una solución de adivinanza-2 con el mínimo (+1.25). Las cuentas de adivinanzas adyacentes están 0.1 aparte, por lo que un peso de solución más pequeño de 0.04 elimina la superposición, y la peor solución (+1.01) aún supera el umbral de éxito de 1.0. La forma aún importa porque GRPO aprende de la varianza de la recompensa dentro de un grupo, por lo que dos juegos perdidos que difieren en la consistencia de las pistas aún enseñan algo al modelo. Como aconseja la documentación de SageMaker AI, comience con una recompensa basada en el resultado, agregue forma de manera escasa y verifique la recompensa en trayectorias reales.

Análisis detallado: Qué salió mal, en el orden en que lo encontrarás

Cada uno de estos costó al menos una ejecución de entrenamiento.

• Token de portador bajo concurrencia. Acuñar un token con una sesión de botocore fresca por llamada agotó al proveedor de credenciales en 32 implementaciones concurrentes, y almacenar en caché tokens durante una hora devolvió errores 403 cuando las credenciales se rotaban. La solución es una sesión de autoactualización, una caché corta y una firma nuevamente en 403.
• Una implementación que nunca alcanza el modelo de política falla todo el trabajo. Cuando cada llamada de modelo en una implementación falló la autenticación, el servicio terminó el trabajo con “No se recibieron solicitudes de muestreo”. Devolver un estado de error también lo hace fallar, así que siempre devuelva una recompensa. Un juego donde el modelo se muestrea pero nunca hace una suposición válida está bien: obtiene -1.5, y la ejecución de 100 pasos tuvo 51 de ellos en aproximadamente 105,000 implementaciones.
• Llamadas de herramientas que se desvían hacia texto plano. Con una tasa de aprendizaje demasiado alta, el modelo escribió llamadas de herramientas como texto, cada implementación obtuvo la misma recompensa de piso y el gradiente desapareció. El agente ahora recupera suposiciones de texto sin formato con una pequeña penalización de formato.
• El plateau. La recompensa de entrenamiento dejó de aumentar después de aproximadamente el paso 15 y la validación dejó de mejorar después de aproximadamente el paso 30, aunque a temperatura 0 la validación subestima el modelo (Paso 7). Un plan de estudios que siembra juegos con suposiciones anteriores, o más implementaciones por palabra que el valor predeterminado group_size de 8, es lo que probaríamos a continuación.

Conclusión

MTRL en SageMaker AI entrena un modelo en el resultado de todo un episodio. Eso se ajusta a tareas agénticas, donde la trayectoria correcta es desconocida y solo el resultado puede ser evaluado. Usamos una sola recompensa a nivel de episodio. Cuando los pasos intermedios también pueden ser evaluados, MTRL también acepta una recompensa por turno a través de la API UpdateReward. En esta publicación, un modelo de 20B con peso abierto alcanzó una tasa de resolución del 84 por ciento en la configuración de servicio, en comparación con el 61 por ciento, por aproximadamente $339 en tokens de entrenamiento y aproximadamente $79 en uso de tiempo de ejecución de AgentCore. El 37 por ciento que informa la curva de entrenamiento es un artefacto de cómo el trabajo de entrenamiento evalúa la validación, así que evalúe en la configuración que utilizará para servir.