El entrenamiento de modelos de inteligencia artificial ha evolucionado mucho en los últimos años, y el Aprendizaje por Refuerzo está en el centro de esa transformación.
Si antes los equipos dependían casi exclusivamente de prompts bien elaborados y bases de datos estáticas para hacer que un agente de IA funcionara como se esperaba, hoy existe un camino más robusto, que va más allá del ensayo y error y comienza a moldear el comportamiento del modelo desde adentro hacia afuera. 🔧
Esto importa sobre todo ahora, cuando empresas de diferentes sectores están buscando agentes especializados capaces de ejecutar tareas complejas con más precisión, ya sea clasificando alertas de seguridad, ejecutando análisis de datos, dando soporte al cliente o automatizando flujos por línea de comandos. Los modelos abiertos encajan muy bien en esta historia porque ofrecen más control sobre datos, propiedad intelectual y despliegue, mientras que el RL transforma los criterios de éxito de cada dominio en señales de entrenamiento concretas.
La buena noticia es que laboratorios de vanguardia ya demostraron en la práctica que este enfoque funciona a escala. OpenAI usó RL a gran escala para entrenar su serie de modelos o-series, DeepSeek-R1 demostró cómo el Group Relative Policy Optimization (GRPO) y las recompensas verificables pueden mejorar razonamiento, matemáticas y código, y NVIDIA fue aún más lejos con Nemotron 3 Super, que pasó por post-entrenamiento con RL en múltiples entornos, cubriendo 21 verificadores del NeMo Gym y 37 datasets, generando aproximadamente 1,2 millones de rollouts de entorno.
Qué es el Aprendizaje por Refuerzo en el contexto de agentes de IA
El Aprendizaje por Refuerzo es un enfoque de entrenamiento donde el modelo aprende a partir de intentos, recibiendo señales de recompensa o penalización dependiendo de la calidad de la respuesta generada. A diferencia del fine-tuning supervisado, donde proporcionas pares de entrada y salida correctos, en el RL el modelo explora diferentes salidas y va ajustando su comportamiento con base en lo que funciona mejor dentro de un conjunto de criterios definidos. Este ciclo de exploración y ajuste es lo que hace al RL tan poderoso para desarrollar agentes especializados, porque el modelo aprende a optimizar resultados en vez de simplemente imitar ejemplos.
Una analogía ayuda bastante aquí: piensa en el modelo como el cerebro del agente, en el framework del agente como su cuerpo y en las herramientas como el espacio de trabajo donde puede actuar. Mejorar el framework o agregar herramientas ayuda en muchos casos, pero no siempre cambia el comportamiento del modelo en sí. Si el agente repite los mismos errores al llamar herramientas, falla en flujos largos, formatea salidas de forma incorrecta o elige estrategias equivocadas, necesitas una señal de entrenamiento. Y es exactamente ahí donde el RL encuentra su espacio. 🎯
En la práctica, lo que diferencia este enfoque es la presencia de un verificador, que puede ser un sistema automatizado, una función matemática o incluso otro modelo, responsable de evaluar si la salida del agente alcanzó el objetivo esperado. Este verificador puede tomar varias formas: pruebas automatizadas, ejecución de herramientas, validación de schema, simuladores, modelos de recompensa, revisión al estilo LLM-as-judge, etiquetas de preferencia humana o cualquier otro feedback específico de la tarea. Cuando ese verificador logra operar de forma confiable y a escala, el ciclo de entrenamiento de modelos se vuelve mucho más eficiente, porque no necesitas anotadores humanos para cada ejemplo.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
DeepSeek-R1 es un ejemplo concreto de esto. Al usar recompensas basadas en corrección verificable para tareas de matemáticas y código, el modelo logró desarrollar comportamientos emergentes de razonamiento sin necesitar supervisión humana en cada paso del entrenamiento. Esto no significa que los humanos salieron del proceso, sino que su papel cambió: en vez de etiquetar cada respuesta individualmente, pasaron a diseñar los criterios y los verificadores que guían el aprendizaje del agente a lo largo de miles de iteraciones.
RAG, prompting, SFT y RL: cuándo usar cada enfoque
Un error común es comenzar el proyecto preguntando qué algoritmo usar. La pregunta más productiva es otra: qué comportamiento quiero potenciar y cómo voy a medirlo. A partir de esa respuesta, resulta mucho más fácil elegir la técnica correcta para cada situación. Mira cómo diferentes escenarios piden soluciones diferentes:
- Si el modelo carece de datos del dominio, comienza con RAG o inyección de datos.
- Si no sigue un formato específico, prueba prompting y después SFT.
- Si necesita imitar ejemplos, usa SFT, con LoRA o QLoRA para adaptación eficiente.
- Si tienes salidas preferidas versus rechazadas, el DPO es el camino.
- Si puedes verificar el éxito de forma algorítmica, ve con RLVR con GRPO.
- Si necesitas alineación con preferencias humanas más sutiles, apuesta por RLHF o modelado de recompensa.
- Si el agente falla en flujos largos con muchas llamadas a herramientas, actualizaciones de estado o turnos de conversación, lo ideal es RL basado en entorno con recompensas a nivel de trayectoria.
Entendiendo SFT, DPO, RLVR y RLHF en la práctica
El SFT tiene sentido cuando cuentas con demostraciones del comportamiento deseado, como seguir instrucciones, conversaciones de múltiples turnos, schemas de salida, formatos de llamadas a herramientas o flujos de dominio. El DPO entra en escena cuando tienes pares de preferencia, donde una respuesta es claramente mejor que otra. El RLHF está indicado cuando preferencias humanas más sutiles no pueden capturarse con reglas y cuentas con estructura para datos de preferencia, modelos de recompensa e infraestructura de entrenamiento cuidadosa. Por su parte, el RLVR brilla cuando la corrección puede verificarse algorítmicamente, como JSON válido, comandos de CLI correctos, pruebas que pasan, respuestas matemáticas exactas o llamadas a herramientas exitosas.
Para uso verificable de herramientas y flujos de agentes, un camino común de partida suele ser: aplicar SFT si es necesario, después GRPO con recompensas verificables, evaluar, inspeccionar los fallos y repetir el ciclo. La mejor técnica siempre depende del tipo de señal que tengas disponible.
Por qué GRPO es un buen punto de partida
Para flujos de RLVR, el GRPO suele ser bastante práctico como punto inicial. Genera múltiples completaciones por prompt, puntúa cada una con un verificador y actualiza el modelo con base en el desempeño relativo dentro del grupo. Comparado con el RLHF al estilo PPO, el GRPO tiene menos piezas móviles y funciona naturalmente con recompensas basadas en reglas, lo que lo convirtió en un estándar para muchos ejemplos de RL agéntico.
Variantes más nuevas siguen surgiendo a medida que los sistemas de entrenamiento maduran. El DAPO construye sobre el GRPO con muestreo dinámico y clipping asimétrico para preservar señal de aprendizaje útil y diversidad de exploración, mientras que el GSPO optimiza a nivel de secuencia en vez de a nivel de token, mejorando la estabilidad del entrenamiento, especialmente para modelos Mixture-of-Experts (MoE).
Cuándo tiene sentido usar RL para entrenar agentes
No todos los casos de uso justifican el esfuerzo de montar un pipeline de Aprendizaje por Refuerzo. El punto de partida para evaluar esto es verificar si el dominio de actuación del agente posee resultados verificables de forma confiable. Si puedes crear una función o un sistema que diga objetivamente si la respuesta del agente fue buena o mala, tienes el ingrediente principal para comenzar. Tareas como ejecución de código, análisis de datos estructurados, clasificación de alertas con criterios bien definidos y generación de queries SQL son ejemplos donde esa verificación es bastante factible.
Por otro lado, dominios donde la calidad de la respuesta es altamente subjetiva, como producción creativa libre o respuestas abiertas de soporte emocional, todavía dependen mucho más de enfoques supervisados o de RLHF con feedback humano directo. El RL puro brilla realmente cuando el criterio de éxito puede expresarse de forma objetiva y cuando el espacio de acciones del agente está suficientemente delimitado para que el entrenamiento converja sin disparar el costo computacional. Esa claridad de alcance es lo que separa proyectos exitosos de experimentos costosos que no avanzan.
Vale reforzar un detalle importante: el RL funciona mejor cuando el modelo a veces ya consigue producir el comportamiento correcto, pero no lo hace de forma confiable. Si la recompensa está mal diseñada, el RL va a optimizar el comportamiento equivocado con la misma eficiencia con la que optimizaría el correcto. Por eso, comenzar por la evaluación antes del entrenamiento es una práctica que ahorra mucho tiempo y recursos más adelante.
Cómo montar un ciclo mínimo de entrenamiento verificable
Un ciclo mínimo de entrenamiento con Aprendizaje por Refuerzo para agentes especializados puede resumirse en siete componentes: el modelo de política que estás entrenando, la tarea que sirve de entrada, la acción que el modelo produce como salida, el entorno que ejecuta esa acción y devuelve feedback, el verificador que puntúa el éxito, los rollouts que son los intentos muestreados del modelo actual y, por último, la actualización de política que ajusta los pesos para aumentar la probabilidad de mejores salidas. Cada uno de estos elementos necesita estar bien definido antes de iniciar cualquier ronda de entrenamiento, porque fallos en cualquiera de ellos van a comprometer el proceso entero.
El entorno puede ser tan simple como un sandbox de ejecución de código Python o tan complejo como un simulador de infraestructura de red. Para tareas de turno único más simples, un dataset estático puede ser suficiente. Pero para RL agéntico que abarca flujos de múltiples pasos y múltiples turnos, necesitas un entorno que defina dataset, framework del agente, verificador y estado. Un agente de código que se ejecuta durante mucho tiempo puede necesitar varias llamadas a herramientas antes de que las pruebas pasen, mientras que un agente de análisis de datos puede necesitar inspeccionar archivos, ejecutar queries, generar gráficos y validar resultados.
El NeMo Gym de NVIDIA es un ejemplo de cómo esto puede estructurarse a escala, ofreciendo una forma reproducible de construir entornos que conectan agentes, modelos, sistemas externos, herramientas y verificadores, con tutoriales para escenarios de paso único, múltiples pasos, entornos con estado, casos del mundo real y verificación al estilo LLM-as-judge. Esto reduce bastante el trabajo de ingeniería necesario para montar este pipeline desde cero.
Diseño de recompensa: empieza simple
El diseño de recompensa es donde muchos proyectos de RL terminan complicándose sin necesidad. El consejo de oro es empezar con la recompensa más simple que demuestre que el loop funciona. Para RLVR, esto puede ser tan directo como una recompensa binaria: más uno si la salida pasa el verificador, cero en caso contrario. Señales intermedias solo deben agregarse cuando realmente midan progreso genuino, como puntuar la elección de la herramienta correcta, la producción de un artefacto intermedio válido o la aprobación de una prueba parcial.
Las buenas funciones de recompensa tienen tres propiedades esenciales: miden la tarea real, son difíciles de engañar y fallan de forma visible cuando están equivocadas. Antes de entrenar, ejecuta tu función de recompensa contra 50 a 100 salidas del modelo e inspecciona las puntuaciones manualmente. Si la recompensa discrepa de tu juicio, el problema está en la recompensa, y es ella la que necesita corregirse primero. El exceso de shaping puede enseñar al modelo a optimizar el checklist en vez de resolver la tarea de verdad.
Herramientas que usamos a diario
Planificando el costo de cómputo para entrenamiento y rollouts
El costo del RL viene de dos cargas de trabajo principales: los rollouts y el entrenamiento. Ambos se ven afectados por tamaño de batch, tamaño del modelo y longitud de las secuencias. El costo de rollout escala específicamente con el número de llamadas a herramientas, turnos de conversación y pasos de entorno, mientras que el costo de entrenamiento escala con el tamaño del dataset y el número de actualizaciones de política. Software de inferencia como vLLM ayuda a reducir la latencia de los rollouts, mientras que los frameworks de entrenamiento mejoran la tasa de transferencia.
Las necesidades de GPU varían bastante según el caso. Un experimento pequeño basado en adaptadores, con modelos en el rango de 1B a 8B parámetros, puede comenzar en una sola GPU moderna o en un nodo pequeño con múltiples GPUs. Modelos más grandes, fine-tuning completo, tareas de contexto largo, alto conteo de rollouts o entornos agénticos de múltiples pasos van a necesitar varias GPUs. Cuando el cómputo es limitado, el camino es reducir primero el tamaño del modelo, el número máximo de tokens, las generaciones por prompt y la cantidad de entornos en paralelo. Empezar pequeño siempre es una buena estrategia, porque los modelos más pequeños son excelentes para depurar datos, verificadores, entornos y el propio loop de entrenamiento.
Herramientas del ecosistema NVIDIA para llevarlo a la práctica
NVIDIA construyó un ecosistema bastante completo para quienes quieren trabajar con entrenamiento de modelos usando Aprendizaje por Refuerzo. NeMo RL ofrece componentes para post-entrenamiento escalable con RL, incluyendo soporte a algoritmos como GRPO, además de integración nativa con los verificadores del NeMo Gym. Esto significa que puedes montar un pipeline completo de extremo a extremo sin necesidad de integrar varias herramientas diferentes de proveedores distintos, lo que reduce significativamente la complejidad operativa del proyecto. El ecosistema además se conecta con herramientas populares de la comunidad, como OpenRLHF, SGLang, Unsloth, veRL y vLLM.
NeMo Gym, específicamente, funciona como una colección de entornos y verificadores listos para usar en tareas que van desde matemáticas y código hasta uso de herramientas y razonamiento estructurado. Los 21 verificadores utilizados en el entrenamiento de Nemotron 3 Super cubren una gama amplia de competencias, lo que permitió que el modelo desarrollara capacidades robustas en múltiples dominios dentro de un único proceso de post-entrenamiento. Para equipos que están comenzando con RL, estos verificadores preconstruidos son un punto de partida valioso porque eliminan la necesidad de construir este componente crítico desde cero.
Además, el NeMo Data Designer ayuda en la generación de datos sintéticos, permitiendo crear datasets estructurados de tareas desde cero o a partir de datos semilla, controlar relaciones entre campos y validar salidas contra especificaciones. Esto es especialmente útil cuando los ejemplos reales son escasos, ya que puedes generar variantes de tareas, casos de borde y escenarios de llamadas a herramientas, filtrando todo después con validadores o revisión automatizada. Vale recordar que los datos sintéticos no son verdad absoluta: mantén un pequeño conjunto semilla con calidad humana, deduplica de forma agresiva e inspecciona los casos de fallo antes de usarlos como datos de entrenamiento. 🚀
El camino hacia agentes especializados de alto rendimiento pasa por el dominio de estas técnicas de Aprendizaje por Refuerzo, y el ecosistema de herramientas disponible hoy hace ese camino más accesible de lo que era hace pocos años. Piensa en este proceso como un flywheel de mejora continua: los fallos en producción se convierten en evaluaciones, las evaluaciones se convierten en entornos, los entornos generan recompensas, las recompensas mejoran el modelo y el siguiente modelo se prueba antes de cualquier despliegue. El ingrediente que sigue marcando la diferencia es la claridad sobre lo que el agente necesita hacer y cómo medir si lo está haciendo bien, porque sin recompensas verificables bien definidas, hasta el mejor pipeline de entrenamiento va a perder el rumbo.
