🤖 machine learning

Where Should RL Post-Training Compute Go? Model Size, Search, Learning, and Feedback

Este artículo introduce un marco de contabilidad de FLOPs y el protocolo de diagnóstico RACE para demostrar que las estrategias óptimas de post-entrenamiento de RL bajo un presupuesto fijo no son universales, sino que dependen de una compleja interacción entre el tamaño del modelo, la profundidad de búsqueda, las actualizaciones de aprendizaje y los mecanismos de retroalimentación, instando a los investigadores a reportar asignaciones detalladas de cómputo en lugar de solo el total de FLOPs.

Autores originales: Patrick Wilhelm, Odej Kao

Publicado 2026-07-16

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Patrick Wilhelm, Odej Kao

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres un chef intentando crear la sopa más deliciosa del mundo, pero tienes un límite estricto de cuánta electricidad puede usar la estufa de tu cocina. Podrías gastar esa electricidad en una olla gigante y costosa que contenga mucha sopa a la vez, o podrías usar una olla más pequeña pero removerla durante horas. También podrías gastar energía en probar la sopa constantemente para ver si necesita sal, o en picar vegetales más rápido. En el mundo de la inteligencia artificial, específicamente al enseñar a programas informáticos a pensar y resolver problemas, los científicos se enfrentan a un rompecabezas similar. Tienen un "presupuesto" fijo de potencia informática (medido en una unidad llamada FLOPs, que es simplemente un recuento de cuántos cálculos matemáticos puede hacer la computadora). La gran pregunta es: si tienes una cantidad determinada de potencia, ¿dónde deberías gastarla? ¿Deberías usar un cerebro más grande y capaz para la IA? ¿Deberías dejar que la IA intente más conjeturas antes de aprender? ¿O deberías gastar más potencia en un "maestro" que califique el trabajo de la IA? Equivocarse en este equilibrio significa que la IA podría aprender lentamente o no aprender en absoluto, incluso si tienes mucha potencia disponible.

Este artículo, titulado "Where Should RL Post-Training Compute Go?" (¿A dónde debería ir el cómputo de post-entrenamiento de RL?), profundiza precisamente en esa cuestión. Los autores, Patrick Wilhelm y Odej Kao, tratan el presupuesto de energía de la computadora como una cantidad limitada de dinero que debe dividirse entre tres cosas principales: búsqueda (permitir que la IA pruebe muchas respuestas diferentes), aprendizaje (actualmente actualizar el cerebro de la IA basándose en esas respuestas) y retroalimentación (usar un programa separado para calificar qué tan buenas son esas respuestas). Descubrieron que no existe una única "mejor" forma de gastar el dinero. En cambio, la receta perfecta cambia dependiendo del tamaño del cerebro de la IA, del tipo de maestro que la califica y del tipo de prueba que quieras que la IA supere más tarde.

Los investigadores descubrieron que simplemente decir "usamos 100 unidades de potencia" no es suficiente para entender cómo se entrenó una IA. Es como decir que un chef usó 100 vatios de electricidad sin decirte si los gastó en la estufa, la licuadora o las luces. Si tienes un cerebro de IA pequeño, podrías obtener mejores resultados gastando la mayor parte de tu potencia en dejar que intente muchas respuestas diferentes (búsqueda). Pero si tienes un cerebro gigante y poderoso, esa misma cantidad de potencia podría solo comprarte unos pocos intentos, por lo que podrías necesitar gastar más en los pasos de aprendizaje reales. También descubrieron que el "maestro" importa mucho. Si el maestro es un verificador basado en reglas simples (como una clave de matemáticas), casi toda la potencia se destina a que la IA intente cosas. Pero si el maestro es otro programa de IA complejo, una enorme parte del presupuesto de potencia se consume simplemente por el maestro haciendo su trabajo, dejando menos para que la IA estudiante aprenda.

El artículo sugiere que la "mejor" forma de entrenar una IA depende enteramente de lo que estés tratando de lograr. Si quieres que la IA obtenga una puntuación alta en un examen de práctica específico, una mezcla de búsqueda y aprendizaje podría funcionar mejor. Pero si quieres que resuelva un problema completamente nuevo más tarde, una mezcla diferente podría ser mejor. Para ayudar a los científicos a descubrir esto sin desperdiciar millones de dólares en pruebas de ensayo y error, los autores introdujeron una herramienta llamada RACE. Piensa en RACE como una prueba de sabor rápida y barata. Ejecuta un experimento diminuto y de baja potencia para adivinar dónde está el "punto ideal" para gastar el presupuesto, de modo que los investigadores sepan qué experimentos a gran escala valen la pena hacer. Los autores aclaran que esto no es una garantía mágica de que la IA se volverá más inteligente; es solo una herramienta de diagnóstico para ayudarles a elegir la dirección correcta antes de comprometer todos sus recursos.

Al final, la conclusión principal es que "más potencia" no es la única respuesta. El movimiento más inteligente es ser un contador cuidadoso. Ya sea que estés entrenando a un robot para caminar o a una computadora para resolver problemas matemáticos, necesitas informar exactamente cómo dividiste tu energía entre el tamaño del cerebro, los intentos de práctica y el sistema de calificación. Porque, como muestran los autores, la misma cantidad de energía puede comprarte un tipo de inteligencia completamente diferente dependiendo de cómo la gastes.

Resumen Técnico: ¿Hacia dónde debería dirigirse el cómputo de post-entrenamiento de RL?

Planteamiento del Problema
El post-entrenamiento mediante Aprendizaje por Refuerzo (RL) se utiliza cada vez más para adaptar modelos fundacionales para el razonamiento, la planificación y los procesos de aprendizaje robótico basados en retroalimentación. Sin embargo, los análisis de escalado actuales suelen resumir el coste de estos procesos utilizando una única métrica agregada: el total de FLOPs. Este artículo sostiene que dicho reporte carece de la especificación suficiente. Bajo un presupuesto fijo de post-entrenamiento, la asignación de cómputo es un problema de asignación de recursos con restricciones que involucra cuatro dimensiones acopladas:

Tamaño del Modelo: La capacidad de la política que se está entrenando.
Búsqueda/Rollout: La generación de trayectorias candidatas.
Aprendizaje/Actualizaciones: La optimización basada en gradientes de la política.
Retroalimentación/Evaluación de Recompensa: El coste de inferencia de los modelos de recompensa o verificadores.

La pregunta central abordada es: Bajo un presupuesto fijo de FLOPs, ¿cómo debe distribuirse el cómputo entre estos componentes para maximizar el rendimiento? Los autores postulan que las políticas más grandes consumen más cómputo por token, lo que reduce la cantidad de rollouts y pasos de actualización posibles bajo el mismo presupuesto. Además, la introducción de mecanismos de retroalimentación aprendidos (por ejemplo, Modelos de Recompensa de Proceso o PRM) introduce un nuevo coste de cómputo que compite con los presupuestos de rollout y actualización, un compromiso que queda oculto al reportar únicamente el total de FLOPs.

Metodología
El estudio introduce un marco de contabilidad de FLOPs diseñado específicamente para GRPO (Group Relative Policy Optimization) en el post-entrenamiento. El cómputo total ( $C_{total}$ ) se descompone en tres términos distintos:
$C_{total} = C_{search} + C_{learning} + C_{reward}$
Donde:

$C_{search}$ : Generación de rollout autorregresiva.
$C_{learning}$ : Optimización de la política (contabilizando los parámetros del adaptador LoRA y los costes del backbone congelado).
$C_{reward}$ : Inferencia de recompensa o del verificador.

La variable de asignación principal es la fracción de actualización ( $\rho$ ), definida como la relación entre el cómputo de aprendizaje y el cómputo total. Los autores realizan experimentos utilizando políticas Qwen2.5 adaptadas con LoRA en el conjunto de datos de razonamiento matemático Polaris-53K. El diseño experimental incluye:

Etapa A: Variación de los tamaños de los modelos (1.5B, 3B, 7B) para estudiar la asignación de búsqueda-aprendizaje.
Etapa B y D: Comparación de diferentes sistemas de recompensa (dispersa, estructurada, densa, proxy-PRM y PRM real) para evaluar cómo el coste de la retroalimentación desplaza las fronteras de asignación.
Evaluación: Las métricas incluyen la recompensa nativa de entrenamiento, la precisión de pass@1 en problemas de razonamiento (GSM8K y MATH-500) y una puntuación de calidad de proceso de un "juez común".

Para abordar el alto coste de la búsqueda exhaustiva, los autores introducen RACE (Reward-Aware Compute Allocation), un protocolo de diagnóstico de rejilla piloto. RACE ejecuta pequeñas rejillas piloto de IsoFLOP para estimar las respuestas locales de la asignación de recompensa e identificar si un ajuste pertenece a un régimen de "mucha búsqueda" (search-heavy), "mucha actualización" (update-heavy) o "mucha recompensa" (reward-heavy). Los autores declaran explícitamente que RACE es una herramienta de diagnóstico para la identificación de regímenes, no una garantía de mejora en datos no vistos.

Contribuciones Clave

Marco de Contabilidad de FLOPs: Una descomposición formal del cómputo de post-entrenamiento de RL en componentes de rollout, actualización y evaluación de recompensa, permitiendo la comparación de ejecuciones que son mecánicamente diferentes a pesar de tener idénticos FLOPs totales.
Acoplamiento de Tamaño de Modelo y Asignación: Evidencia empírica de que la elección del modelo y la asignación de entrenamiento son inseparables. Bajo un presupuesto fijo, las políticas más grandes compran intrínsecamente menos actualizaciones y rollouts, alterando la frontera de asignación óptima.
Dependencia de la Recompensa y el Objetivo: Demostración de que la "mejor" asignación depende del sistema de recompensa (basado en reglas vs. PRM) y del objetivo de evaluación (recompensa nativa vs. precisión downstream vs. calidad de proceso). Por ejemplo, la retroalimentación basada en PRM desplaza la fracción de actualización óptima ( $\rho$ ) hacia valores más bajos porque una parte del presupuesto se consume por la inferencia del modelo de recompensa.
Protocolo RACE: Un método de diagnóstico para identificar regímenes de asignación mediante pequeñas rejillas piloto, destinado a guiar las ejecuciones de validación en lugar de reemplazarlas.

Resultados

Fronteras de Asignación Condicionales: La asignación óptima no es un punto fijo, sino una frontera condicional. Los ajustes con mucha búsqueda subutilizan la capacidad de aprendizaje, mientras que los ajustes con mucha actualización se ven limitados por la exploración.
Impacto del Sistema de Recompensa: Las recompensas basadas en reglas (dispersas, estructuradas, densas) tienden a favorecer regímenes de alta actualización ( $\rho \approx 0.72$ ). En contraste, la retroalimentación tipo PRM (proxy y real) desplaza la frontera de recompensa nativa hacia fracciones de actualización más bajas ( $\rho \approx 0.44–0.45$ ) porque el presupuesto fijo debe cubrir ahora la inferencia del modelo de recompensa.
Desacuerdo de Objetivos: Diferentes objetivos de evaluación seleccionan diferentes asignaciones óptimas.
- Recompensa Nativa: Favorece la asignación que maximiza la señal de retroalimentación específica utilizada durante el entrenamiento.
- Pass@1 Downstream: A menudo favorece regímenes de alta actualización (por ejemplo, el ajuste $a180$ ) a través de los sistemas de recompensa.
- Juez Común: A menudo alcanza su pico en regímenes de actualización media (por ejemplo, $a100$ ) para recompensas densas y de tipo PRM.
- Este desacuerdo indica que una receta que maximiza una métrica puede no maximizar otra.
Rendimiento de RACE: RACE identifica con éxito el régimen correcto (alta vs. baja actualización) en entornos de validación con alta precisión (tasa de 1.0 en el mismo régimen), pero no garantiza una mejora global de la recompensa en datos no vistos respecto a los modelos base.

Significancia y Reivindicaciones
El artículo afirma modestamente que el post-entrenamiento de RL es un problema de asignación de recursos con restricciones en lugar de una simple ley de escala. Los autores argumentan que reportar únicamente los FLOPs totales oculta los compromisos mecánicos entre la capacidad del modelo, la generación de experiencia y la evaluación de la retroalimentación.

La importancia radica en la recomendación a la comunidad de reportar un cómputo consciente de la asignación: los FLOPs totales junto con el desglose específico de los FLOPs de rollout, actualización y evaluación de recompensa, así como la fracción de actualización resultante $\rho$ . Esta transparencia es crucial para los sistemas de aprendizaje robótico, donde mejorar un módulo de razonamiento o de retroalimentación mediante el post-entrenamiento de RL implica decidir si se invierten los recursos limitados en modelos más grandes, una búsqueda más extensa o mecanismos de retroalimentación más fuertes. El artículo concluye que no existe una "mejor" receta universal; la asignación óptima depende conjuntamente del tamaño del modelo, el diseño de la recompensa y el objetivo específico de evaluación que se esté optimizando.

Resumen Técnico: ¿Hacia dónde debería dirigirse el cómputo de post-entrenamiento de RL?

Más como este