Cómo diseñar recompensas para RL multi-turn con Amazon Nova Forge
En tareas multi-turn, la función de recompensa define lo que el modelo aprende: un error sutil puede enseñar el comportamiento equivocado sin alertas claras. Este artículo explica cómo construir, ejecutar e instrumentar recompensas compuestas con Amazon Nova Forge, usando BYOO para evaluar episodios completos.
Introducción
En entrenamiento por refuerzo multi-turn, la función de recompensa no es solo una métrica: es la brújula que guía el comportamiento del modelo a lo largo de una conversación o una secuencia de acciones. Amazon Nova Forge ofrece herramientas para ejecutar recompensas personalizadas dentro de su propio entorno (Bring Your Own Orchestration, BYOO) o mediante una opción serverless. Este texto se centra en la ruta BYOO y en cómo diseñar recompensas compuestas que Group Relative Policy Optimization (GRPO) pueda aprender robustamente.
Por qué la recompensa importa más en multi-turn
A diferencia de tareas de una sola respuesta, en multi-turn el objetivo es optimizar la recompensa acumulada a lo largo de una trayectoria. Un componente de recompensa mal planteado puede mantenerse estable (y por tanto no aportar señal de aprendizaje) mientras parece que todo marcha bien en las curvas de entrenamiento. En esencia, la contribución efectiva de cada término de la recompensa depende de la variación que genere dentro de un grupo de rollouts: si un término toma el mismo valor en todas las muestras, no influye en la actualización del modelo.
RFT (reinforcement fine-tuning) frente a SFT (supervised fine-tuning)
Amazon Nova soporta múltiples formas de personalización, pero la RFT destaca porque enseña comportamientos mediante señales iterativas sobre las propias salidas del modelo. A diferencia de SFT, que requiere ejemplos curados y razonamientos anotados, RFT aprende de evaluaciones aplicadas a las respuestas generadas. En multi-turn, RFT optimiza la recompensa acumulada y puede enseñar a un agente a usar herramientas, ejecutar código o recuperarse de errores.
Nova Forge aplica GRPO: para cada conversación se generan K rollouts, se clasifican según la función de recompensa y el algoritmo utiliza los completions mejor rankeados para actualizar el modelo en función de la ventaja normalizada del batch.
Cómo ejecuta Nova Forge la lógica de recompensa
Para tareas de un solo turno, la recompensa puede registrarse como una función Lambda (reward_lambda_arn). Sin embargo, las conversaciones multi-turn y las evaluaciones prolongadas suelen superar el límite de invocación Lambda (15 minutos). En esos casos Nova Forge utiliza BYOO: ustedes ejecutan su entorno en un contenedor (por ejemplo, en Amazon ECS) y habilitan rollout.delegate: true. Nova Forge delega cada rollout a su entorno, que administra el simulador de usuario, el estado de la conversación, la ejecución segura de código y la verificación de resultados.
Al final, su contenedor devuelve un puntaje de recompensa agregado por muestra (aggregate_reward_score) y opcionalmente una lista de puntajes por componente (metrics_list).
Diseñando recompensas compuestas
Una función de recompensa compuesta permite evaluar múltiples dimensiones del comportamiento (exactitud, seguridad, eficiencia, uso correcto de herramientas, etc.). Recomendaciones prácticas:
- Definan objetivos claros y medibles por componente: cada término debe representar un criterio verificable.
- Asegúrense de que cada componente pueda variar entre rollouts. Si un componente es constante, no aportará señal de aprendizaje.
- Normalicen escalas: diferentes magnitudes entre componentes pueden hacer que uno domine al resto. Consideren pesos y normalización por rango observado.
- Prueben con conjuntos de escenarios representativos (incluyendo casos extremos) para exponer diferencias entre rollouts.
- Empiecen con reglas verificables (reinforcement learning with verifiable rewards) y consideren LLM-as-Judge solo cuando la evaluación sea inherentemente subjetiva.
Instrumentación y trazabilidad
Instrumentar cada parte de la recompensa es crítico para confiar en lo que realmente aprende el modelo. Devuelvan, además del aggregate_reward_score, un metrics_list con las puntuaciones por componente y registros de decisión que permitan auditar por qué una muestra recibió cierta calificación. Esto facilita detectar componentes que no varían o validan siempre de la misma manera.
Tener telemetría ayuda a identificar cuándo un término de alta ponderación no aporta señal (por ejemplo, siempre cero o siempre igual), un problema que puede pasar desapercibido si solo observan la recompensa total.
Ejecutando código generado por el modelo de forma segura
En muchas tareas multi-turn, el agente puede proponer fragmentos de código o llamadas a herramientas que deben ejecutarse para evaluar la respuesta. Recomendaciones de seguridad operativa:
- Ejecuten el código en un sandbox aislado con límites de recursos y tiempo de ejecución.
- Validen entradas y apliquen lista blanca de operaciones o bibliotecas permitidas.
- Registren la salida y cualquier excepción para que la recompensa pueda considerar fallos o recuperaciones.
- Definan políticas claras para el manejo de excepciones y errores transitorios.
Nova Forge espera que su contenedor gestione estas interacciones y devuelva una evaluación agregada; por eso es importante construir el entorno con controles de seguridad y registros exhaustivos.
Errores comunes y cómo detectarlos
Algunos fallos típicos en la definición de recompensas multi-turn:
- Componentes sin variación: un término siempre constante no aporta gradiente. Detecten esto revisando las distribuciones de metrics_list durante las primeras iteraciones.
- Sobrecarga de un componente: si un término domina por escala, el modelo optimizará solo eso. Ajusten pesos y normalizaciones.
- Dependencias ocultas entre componentes: dos métricas correlacionadas pueden enmascarar señales; prueben ablaciones para identificar contribuciones reales.
- Evaluadores inestables: si usan LLM-as-Judge, documenten y monitoreen la coherencia de sus juicios.
La instrumentación mencionada y logs por episodio son las herramientas principales para diagnosticar estos problemas antes de que comprometan el entrenamiento.
Requisitos prácticos y recursos
Para implementar este flujo con Nova Forge necesitan:
- Suscripción a Amazon Nova Forge y acceso al Nova Customization SDK y APIs de RFT multi-turn.
- Infraestructura multi-turn descrita en la Parte 1 de la serie: un clúster Amazon SageMaker HyperPod y un entorno administrado por el cliente en Amazon ECS.
- Un bucket en Amazon S3 para almacenar rollouts y checkpoints.
- El repositorio de ejemplo aws-samples/sample-nova-multi-turn-rl-infra, que incluye el entorno de recompensa y un walkthrough.
En el despliegue por defecto pueden habilitar el entorno personalizado ajustando cdk.json: pongan use_custom_env en “true” y custom_env_id con su ID de entorno antes de desplegar. Por defecto la pila usa un entorno integrado de ejemplo (wordle).
Conclusión
Diseñar funciones de recompensa para entrenamiento multi-turn es tanto un arte como una ingeniería: requiere claridad en los objetivos, instrumentación rigurosa y entornos de evaluación seguros. Amazon Nova Forge, con su soporte BYOO y GRPO, permite correr evaluaciones complejas en su propio espacio operativo, entregando tanto el puntaje agregado como métricas por componente para auditoría. En América Latina, donde las aplicaciones conversacionales y de automatización crecen rápido, invertir en recompensas bien diseñadas y trazabilidad desde el inicio reduce riesgos y acelera resultados útiles en producción.
Si siguen las prácticas descritas —componentes verificables, normalización, sandboxing para ejecución de código y métricas desagregadas— estarán en mejor posición para que la RFT impulse los comportamientos correctos sin sorpresas durante el despliegue.
Fuente original: AWS ML Blog