El entrenamiento unificado elevó el resultado en HumanEval+ hasta un 24,96% pass@1

Entrenar hoy un modelo de lenguaje se parece a operar una fábrica con varias líneas de producción separadas. Primero, el modelo lee un corpus enorme de textos; después, aprende con datos más especializados; a continuación, se entrena para seguir instrucciones; y solo entonces recibe retroalimentación mediante RL. En cada transición cambian los datos, el código, la infraestructura y el equipo. Al mismo tiempo aparece un problema conocido: al mejorar una capacidad, el modelo puede olvidar parcialmente otra.

Los autores del trabajo Training Foundation Models with a Single Algorithm comprobaron si esta carrera de relevos podía convertirse en un único proceso continuo. Su respuesta es que las distintas etapas pueden representarse como entrenamiento sobre distribuciones objetivo de datos, mezclando los ejemplos en un flujo común y optimizando una sola función de pérdida de máxima verosimilitud ponderada por tokens. Incluso las actualizaciones de la política en RL se reducen aquí a ajustar las probabilidades de las respuestas teniendo en cuenta la recompensa obtenida.

Como se ve en un ejemplo sencillo

Imaginemos un modelo pequeño al que primero se enseña lenguaje común, después acertijos lógicos y, por último, programación. Un pipeline clásico ejecuta tres sesiones de entrenamiento consecutivas. Con Unified Training, el servidor de entrenamiento puede recibir simultáneamente ejemplos de los tres tipos, aunque en proporciones diferentes: muchos datos de lenguaje general, menos acertijos y una pequeña fracción de tareas con recompensa por producir código correcto.

El peso de cada flujo determina a qué presta más atención el modelo en ese momento. Los datos anteriores no desaparecen por completo, por lo que el modelo pierde con menos frecuencia capacidades ya adquiridas. Se parece menos a un graduado que cierra el libro después del examen y más a un profesional que sigue repasando poco a poco los fundamentos mientras practica.

En las tareas lógicas, el resultado dependió mucho de la composición de la mezcla: aproximadamente entre un 4% y un 39% pass@1 en tareas de un tamaño conocido. Las variantes por etapas obtuvieron entre un 12,24% y un 24,54%. En tareas nuevas con 12 personajes, el enfoque unificado logró aproximadamente un 1–13%, mientras que la variante por etapas seleccionada obtuvo un 5,58%. La dispersión es más importante aquí que el máximo llamativo: el propio algoritmo no elimina la necesidad de ajustar las proporciones de los datos.

En un experimento con un modelo de 0,76 mil millones de parámetros, el RL sobre matemáticas y posteriormente sobre código produjo un 23,67–24,96% pass@1 en HumanEval+ cuando la proporción de datos mezclados era de entre un 0,5% y un 5%. El entrenamiento secuencial convencional obtuvo un 22,94%. La diferencia es pequeña, pero muestra que conservar parte del flujo de datos anterior puede ayudar en la siguiente etapa de adaptación.

Donde termina la evidencia

La principal limitación del trabajo es la escala. Todos los experimentos se realizaron con modelos de menos de mil millones de parámetros. Además, para el modelo de 0,76B, la unificación solo se utilizó durante la etapa final de RL, no a lo largo de todo el recorrido desde el preentrenamiento hasta un asistente terminado. Por eso, todavía es pronto para afirmar que los pipelines separados ya no son necesarios.

Tampoco se encontró un calendario universal de mezcla. Una proporción resuelve mejor los acertijos conocidos, otra las tareas nuevas y una tercera el código. En un producto real, a esto se sumarían el coste computacional, la calidad del filtrado de datos, las latencias de un sistema asíncrono y los objetivos de seguridad en conflicto.

Que deben hacer los equipos

Los desarrolladores de modelos propios deberían considerar Unified Training una hipótesis de ingeniería verificable. No es necesario reescribir de inmediato todo el stack. Se puede comenzar con un experimento acotado: durante la etapa de SFT o RL, conservar una pequeña proporción de datos de la etapa anterior y comparar tanto la calidad de las nuevas capacidades como el grado de olvido en un conjunto fijo de pruebas.

Para los equipos de producto, puede resultar más útil otra idea: las fronteras entre preentrenamiento, ajuste fino y RL podrían ser una conveniencia organizativa, no una propiedad fundamental del aprendizaje. Si el resultado se reproduce en modelos más grandes, un único flujo asíncrono simplificaría la transferencia de datos entre etapas y permitiría cambiar las prioridades con mayor rapidez. Por ahora, el valor del trabajo no reside en la promesa de “un algoritmo para todo”, sino en el código, el modelo y el esquema experimental concreto que puede probarse con un conjunto propio de tareas.