LM2LM: Qwen3.8-27B supera a GPT-6-sol en ideas para mejorar LLM y es un 33% más barato

La idea de que una red neuronal mejore a otras redes neuronales se discute desde hace tiempo como vía hacia la automejora recursiva. El equipo de LM2LM ha mostrado una variante que funciona: entrenaron con RL a un modelo de lenguaje para que genere propuestas eficaces de mejora de LM. En la evaluación sobre tareas reservadas en ocho entornos de desarrollo, autorregresivos y de difusión, Qwen3.8-27B superó a GPT-6-sol. GPT-6-sol perdió incluso con 300 registros experimentales reales en el contexto, y la generación de datos con LM2LM salió un 33% más barata.

Por qué no se puede reunir una recompensa honesta por una idea

El principal obstáculo es económico. Para enseñar a un modelo a proponer buenas mejoras, el RL tiene que evaluar decenas de miles de propuestas. Cada una exige, en el límite, un entrenamiento completo del modelo. Si se calculan diez horas de GPU por ejecución, solo las recompensas consumirían cientos de miles de horas de GPU. Para la mayoría de los laboratorios es un presupuesto irreal, así que hace falta un sustituto barato.

Ese sustituto tiene su propio problema. La evaluación sustituta es fiable mientras la política genera propuestas parecidas a aquellas con las que se construyó el sustituto. Cuando la optimización empieza a desplazar la distribución de propuestas, la política encuentra las que el sustituto sobrestima. Es el reward hacking clásico: el modelo aprende a gustar al evaluador, no a mejorar modelos reales.

Un modelo del mundo para la investigación y la verificación con la realidad

LM2LM resuelve ambos problemas con dos elementos. El primero es el research world model (RWM): un LLM congelado al que se le da en el contexto el registro de experimentos reales. A partir de ellos predice qué mejora aportará una nueva propuesta. El RWM actúa como reward model para el RL y sustituye miles de entrenamientos completos por una sola llamada al modelo.

El segundo elemento es la verificación periódica. Las propuestas de la política actual que el RWM puntuó más alto se ejecutan de verdad, y los resultados medidos se añaden al contexto del RWM. Así el evaluador ve justo la zona del espacio de ideas hacia la que se ha desplazado la política y se recalibra donde ella corre el riesgo de engañarlo. Los candidatos más sospechosos, es decir, precisamente los que obtuvieron puntuaciones altas, se comprueban con una ejecución real.

Parámetros clave del trabajo:

• política: Qwen3.8-27B, entrenada con RL;
• reward model: LLM congelado (RWM) con registros experimentales reales en el contexto;
• línea base: GPT-6-sol, a la que se dieron 300 registros reales en el contexto;
• entornos: ocho entornos de desarrollo de LM, autorregresivos y de difusión;
• evaluación: ejecución real de las propuestas en tareas reservadas;
• ahorro: un 33% menos de coste en la generación de datos;
• generalización: transferencia a una familia de modelos que no apareció durante el entrenamiento.

Conviene destacar las condiciones de la comparación. GPT-6-sol recibió una pista potente, 300 registros reales, pero un modelo de menor escala con la capacidad entrenada resultó mejor de todos modos. Parece que es más eficaz transmitir la experiencia acumulada mediante el entrenamiento de la política que mediante un contexto largo en un modelo más general.

Dónde resulta útil en la práctica

Para los equipos que hacen muchos experimentos de entrenamiento de modelos, lo más valioso es que los registros de ejecuciones pasadas se convierten en un activo. Los apuntes sobre qué cambios de hiperparámetros, datos o arquitectura funcionaron pueden servir como contexto para el RWM y como fuente de señal de entrenamiento para el generador de ideas. Las ejecuciones caras se reservan solo para comprobar a los candidatos más prometedores.

También hay una conclusión prudente. El esquema funciona solo con disciplina: sin una comprobación regular con ejecuciones reales, el sustituto empezará a sobrestimar ideas y la política lo seguirá. El presupuesto para experimentos reales habrá que incluirlo en el pipeline como un gasto permanente. La transferencia a una familia de modelos desconocida indica que la experiencia acumulada no está atada a una sola arquitectura, pero cada equipo tendrá que verificarla igualmente en sus propios stacks.