El pre-preentrenamiento sintético de LLM no compensa: con los mismos FLOPs pierde frente al texto normal

La idea suena atractiva: antes de alimentar a un modelo de lenguaje con terabytes de internet, dale un «calentamiento» con estructura pura. Autómatas celulares, lenguajes con paréntesis correctamente anidados, secuencias generadas de forma procedimental. Se supone que el modelo aprenderá de antemano patrones útiles y luego dominará más rápido el lenguaje real. A esto se le llama pre-preentrenamiento sintético, o PPT.

Un trabajo reciente, Rethinking Pre-Pretraining (Alexander Stern, Tim Rocktäschel, Andrea Locatelli y Laura Ruis), pone a prueba esta idea sin concesiones. Y muestra que la hipótesis, tan elegante, no sobrevive a una contabilidad honesta.

Dónde está el problema

La mayoría de los artículos previos sobre PPT comparaban modelos sin tener en cuenta cuánto cómputo se había gastado en la etapa sintética. Los autores fijaron un presupuesto total de FLOPs: si una parte se destina a datos sintéticos, queda menos para el texto natural. En ese régimen, el PPT nunca superó al entrenamiento solo con lenguaje natural.

Un ejemplo con cifras. Tomemos 100M de tokens de FineWeb y un presupuesto de 1 × 10¹⁸ FLOPs. El entrenamiento habitual con repetición del texto da 1.064 bits por byte (BPB) en validación, donde menos es mejor. Si se dedica del 1 % al 10 % del cómputo al PPT, la métrica empeora hasta 1.068–1.076. La diferencia es pequeña, pero la dirección es inequívoca: se pagó con cómputo y se obtuvo una pérdida.

La explicación es sencilla. Cuando el modelo pasa al lenguaje natural, los gradientes sobrescriben rápidamente las estructuras aprendidas con datos sintéticos. Es como aprender aperturas de ajedrez y luego jugar a las damas durante medio año.

De dónde venían los éxitos anteriores

La parte más interesante del trabajo es el análisis de por qué el PPT parecía útil. Los autores reprodujeron el experimento con autómatas celulares (NCA) en un LLaMA de 400M de parámetros con OpenWebText. La mejora de perplejidad del PPT con NCA fue del 5,4 %.

Pero si se cambia la inicialización de los embeddings de 𝒩(0, 1) a 𝒩(0, 0.02), la estándar para estos modelos, el baseline sin ningún PPT mejora un 9,0 %. Eso anula por completo el beneficio de los datos sintéticos. Resulta que el PPT corregía en gran medida una mala inicialización, en lugar de aportar conocimiento al modelo.

Además, los autores propusieron un corpus sintético para la búsqueda de valores de variables (DeclRef) y la herramienta LLMTuna, un optimizador de hiperparámetros basado en LLM. El código de ambos proyectos está abierto en GitHub.

Limitaciones

Conviene leer las conclusiones con cautela. Todos los modelos tienen menos de 1B de parámetros y se desconoce si el PPT se comporta igual a escalas de decenas de miles de millones. La prueba con la inicialización de LLaMA y los experimentos de mezcla de datos se realizaron sin volver a ajustar los hiperparámetros, por lo que parte del resultado podría cambiar con un ajuste fino.

Cabe señalar aparte que se trata de un resultado negativo sobre una clase concreta de métodos. No invalida la utilidad de los datos sintéticos en general, por ejemplo para el ajuste fino en código o matemáticas.

Qué hacer en la práctica

Si entrenas tus propios modelos, sobre todo pequeños, las conclusiones son estas:

• No añadas una etapa de PPT sintético a tu pipeline «por si acaso». Cuesta cómputo y, a juzgar por los datos, no compensa.
• Antes de creer en una mejora vistosa de un nuevo truco, revisa lo básico: inicialización, learning rate, scheduler. Un baseline débil crea con facilidad la ilusión de progreso.
• Compara los métodos con el mismo presupuesto de FLOPs, no con el mismo número de pasos o de tokens de texto natural.

La lección principal va más allá del tema: muchas «mejoras» en ML en realidad corrigen un baseline mal configurado. Si no tienes un grupo de control sólido con un presupuesto honesto, lo más probable es que no estés midiendo el método, sino tus propias deficiencias.