BorisovAI prueba MoE en una RTX 4090 y muestra por qué la perplejidad distorsiona la evaluación de los LLM

BorisovAI ha publicado el análisis de 22 experimentos con una arquitectura MoE en la que los nuevos expertos se conectan como plugins sobre un modelo de lenguaje congelado. En una sola RTX 4090, el esquema mostró un cuadro casi perfecto desde el punto de vista de la ingeniería: degradación nula de las habilidades previas, enrutamiento preciso y una reducción notable de la perplejidad. Pero al evaluar el sistema con un benchmark de matemáticas, resultó que una métrica atractiva puede apuntar en una dirección totalmente equivocada.

Cómo se montó el esquema

El investigador congeló por completo el modelo base y añadió a cada capa MLP un pequeño experto entrenable, y por encima un enrutador de unos 37 000 parámetros. La lógica es sencilla: no se toca el backbone, se entrena la nueva habilidad por separado y después se ajusta solo el enrutador para que envíe los tokens adecuados al experto adecuado. Entrenar un dominio nuevo llevaba cerca de media hora: unos 15 minutos para el experto aislado y otros 15 para integrarlo en el sistema.

En tres escalas el esquema resultó muy convincente y casi sin contrapartidas:

• GPT-2 124M con 4 dominios redujo la perplejidad un 33,4 %
• Pythia-410M con 6 dominios redujo la perplejidad un 34,3 %
• Pythia-1B con 8 dominios redujo la perplejidad un 31,2 %
• La precisión del enrutamiento llegó al 96 % y la degradación de las habilidades previas se mantuvo en 0,000 %

Además, el autor probó varios trucos populares que se suelen recomendar para MoE. Las penalizaciones por balanceo de carga empeoraron el resultado entre un 11 % y un 27 %, y el entrenamiento conjunto de expertos y enrutador provocó un colapso de la calidad. Lo que mejor funcionó fue el balanceo sin pérdida auxiliar: mantuvo «vivos» a todos los expertos sin una función de pérdida adicional. En esta etapa todo parecía un argumento sólido a favor de los LLM modulares, donde se pueden conectar nuevas capacidades sin reentrenar por completo.

Dónde se rompió la métrica

Los problemas empezaron al trasladar la arquitectura a Qwen 2.5 3B e intentar añadir un experto matemático. Según las métricas internas, todo volvía a ser excelente: la perplejidad en textos matemáticos bajó un 23,9 %, la brecha entre dominios se multiplicó por 64,9 y el enrutador elegía al experto correcto casi sin errores. Pero en GSM8K, que mide precisamente la capacidad de resolver problemas de texto de nivel escolar, el modelo cayó del 74,4 % al 65,8 %.

«Un modelo que habla el lenguaje de las matemáticas no sabe en

absoluto resolver problemas».

Esta es la conclusión clave de todo el trabajo. El experto, entrenado con libros de texto y artículos, sí aprendió la estadística del lenguaje matemático: dónde suelen ir las fórmulas, qué términos aparecen juntos y cómo es un texto «correcto» de este campo. Pero GSM8K exige cadenas de razonamiento, no reconocer un estilo. Por eso la caída de la perplejidad no medía una mejora real del razonamiento, sino simplemente un mejor modelado del texto del dominio. El investigador revisó por separado las alternativas (descongelar las capas superiores, entrenamiento conjunto y un esquema en dos fases), pero todas las variantes se quedaron en torno a los mismos 8,4–8,6 puntos porcentuales por debajo.

Qué funcionó mejor

El giro llegó con la autodestilación. En lugar de textos matemáticos en bruto, el experto se entrenó con soluciones paso a paso que el propio modelo base ya había obtenido correctamente. Para ello se tomaron 750 problemas de GSM8K: el modelo resolvió 638 y con esas soluciones se armó un conjunto de datos de 119 000 tokens. Es 33 veces menos que el corpus de 4 millones de tokens de libros de texto y artículos, pero el formato resultó mucho más cercano a la inferencia real.

El resultado contradijo las expectativas. Tras este entrenamiento, GSM8K subió al 75,5 %: 1,1 puntos porcentuales por encima del modelo base y 9,7 puntos mejor que la variante con texto matemático en bruto. La perplejidad, en cambio, empeoró un 17,8 %. También se vio que hasta el empaquetado de los datos importa: el formato «pregunta/respuesta» dio entre 2 y 3 puntos más que el formato más académico «problema/solución». Es decir, conviene más entrenar al experto para la forma de su uso futuro que para un corpus abstractamente «de calidad».

El intento de convertir este enfoque en un ciclo de automejora no despegó. Las primeras ejecuciones apuntaban a un aumento del 75,5 % al 76,0 %, pero tras fijar la semilla y ampliar la muestra, el efecto resultó ser ruido estadístico. Con arranque en frío, el nuevo experto llegaba pronto a una meseta; con arranque en caliente, la calidad incluso caía, porque entre ciclos se repetían demasiados problemas y el experto sobreajustaba. El label smoothing también fracasó: en matemáticas restó otros 9 puntos aproximadamente.

Qué significa

Para los desarrolladores de LLM hay dos conclusiones prácticas. Primero, una arquitectura modular con expertos conectables sí puede añadir habilidades de dominio sin olvido catastrófico. Segundo, evaluar estos sistemas por perplejidad es arriesgado: puede mejorar justo cuando el modelo empieza a razonar peor. Si la tarea implica lógica, código o matemáticas, el criterio principal deben ser los benchmarks de comportamiento, y no solo métricas lingüísticas atractivas.