Transformer explicado: quedó bajo tres modelos más simples, y entre las candidatas de arriba la rejilla ordenó al revés
Qué es un Transformer, qué hace la atención y cuándo falla, medido con clima diario de siete ciudades de Chile entre 1984 y 2026. La red elegida tiene 9.633 parámetros y 49 KB, y quedó por debajo del boosting, del bosque y de una red de una capa. Lo que más enseña no es el ranking: entre las seis arquitecturas que competían, el orden de la validación se invirtió en la prueba.
Una red de 9.633 parámetros y 49 KB llegó a AUC 0,876 en la prueba de 2016-2026. Un boosting de 2,1 MB llegó a 0,883, un bosque de 124 MB a 0,882 y una red de una capa oculta, de 81 KB, a 0,883. La diferencia pareada contra las tres no cruza el cero con ninguna de las semillas que probé. El Transformer, el modelo que hoy sostiene todo lo demás, quedó abajo en quince columnas de clima.
Es la undécima y última entrega de la serie, con los mismos datos diarios de NASA POWER de siete ciudades de Chile que usé en Random Forest, regresión lineal, K-Means, regresión logística, árbol de decisión, gradient boosting, SVM, KNN, Naive Bayes y red neuronal. La pregunta sigue siendo si lloverá al menos 1 mm mañana. Entrené con 1984-2012 y evalué en 2016-2026, en un contenedor con 8 CPU, PyTorch 2.9.1 sobre CPU y scikit-learn 1.7.2.
El contrato, porque en este post importa más que en los anteriores: la arquitectura se eligió sin mirar la prueba. La duración de cada ajuste salió de un tramo interno al período de entrenamiento, 2008-2009; la arquitectura se eligió midiendo en 2010-2012, una lectura por candidata; y la prueba se leyó una vez con la elegida. Todo lo demás que aparece sobre 2016-2026 es descriptivo y no eligió nada. Hubo además dos lecturas anteriores de la prueba, con otras dos arquitecturas, y están publicadas más abajo en vez de escondidas.
¿Qué es un Transformer sobre una tabla?
Los pesos w y b se aprenden por columna, así que cada una tiene su propia forma de convertir un número en un vector. No hay ventana de tiempo ni orden entre columnas: el modelo ve exactamente la misma información que los otros diez de la serie. El token [CLS] parte como un vector aprendido, recoge del resto por la atención, y de él sale la probabilidad de lluvia.
Cada columna se convierte en un vector propio: token = valor × w + b, donde w y b se aprenden por columna. Quince columnas dan quince tokens. Se les suma un token [CLS] que no viene de los datos, la atención deja que cada token mire a los demás y decida cuánto pesa cada uno, y la predicción sale del [CLS]. Es la arquitectura que Vaswani y coautores publicaron en 2017 para traducir, adaptada a tablas por Gorishniy y coautores en 2021.
No hay ventana de tiempo ni orden entre columnas, a propósito: así el modelo ve exactamente la misma información que los otros diez de la serie. Darle los últimos días habría sido darle datos que ninguno de los demás tuvo.
Una diferencia con el artículo original que conviene declarar: ellos quitan la normalización del primer bloque y acá la dejé en todos. Esa decisión, que parece menor, es la que explica la sección de las unidades.
La rejilla que no sobrevivió a la prueba
correlación de rangos 0,63 · lineal 0,84 · n 11correlación de rangos -0,49 · lineal -0,39 · n 6
Con las 11, la validación parece acertar: correlación de rangos 0,63 y lineal 0,84, sostenida por las de ancho 256 que quedan al fondo en los dos períodos. Al sacarlas, el orden entre las 6 que competían se invierte: -0,49. Sus movimientos van de -0,0010 a 0,0034 sin relación con lo que la validación había ordenado: d128_b4 (534.273 parámetros) venía 7ª en validación y termina primera, mientras la mejor en validación (d64_b4) queda en 0,8801, por debajo. La elegida (d32_b1, 9.633 parámetros) se mueve -0,0003. La búsqueda separó lo que no competía y no ordenó lo que sí.
Probé once arquitecturas, de 2.769 a 2.117.121 parámetros, moviendo un eje a la vez: el ancho del token y la cantidad de bloques, con dieciséis dimensiones por cabeza. Cada una con tres semillas, la duración fijada en el tramo interno y una sola lectura de 2010-2012.
En validación el orden fue claro: arriba las de ancho 64, con 0,8802 la mejor, y abajo las de ancho 256, que se desploman a 0,872 y dos de las cuales se detienen a las cuatro épocas. Parece la conclusión del post anterior, que crecer no ayuda.
En la prueba ese orden se deshace, y conviene ser preciso sobre dónde. Mirando las once juntas, la validación acertó: la correlación de rangos entre los dos períodos es 0,63 y la lineal 0,84, porque las tres de ancho 256 quedan abajo en los dos y sostienen esa relación. Lo que la validación separó bien fue lo que no competía.
Entre las seis que sí competían, las de ancho 64 y 128, el orden no se mantiene: se invierte. La correlación de rangos entre ellas es −0,49. Las tres arquitecturas de ancho 256 suben entre 0,0025 y 0,0038, y entre las seis de arriba los movimientos van de −0,0010 a +0,0034 sin relación con lo que la validación había ordenado: la de 534.273 parámetros sube 0,0034 y pasa de séptima a primera, mientras la mejor de la validación baja y termina tercera.
No es un fallo del banco: es el resultado. En esta tabla y con este presupuesto, la búsqueda distinguió con claridad lo que no competía y no logró ordenar lo que sí competía.
El margen que la validación no podía resolver
Los dos intervalos cruzan el cero y los dos son más anchos que el margen que debían respetar: 0,0037 contra 0,0055, dos a tres veces 0,002. La regla no eligió una arquitectura peor: eligió la más chica entre arquitecturas que este período no puede distinguir, que es para lo que existe. Lo que hay que cambiar la próxima vez es de dónde sale el margen: lo puse en el orden del ruido de la semilla, unos 0,001, cuando debía salir del error de muestreo de la validación. Una advertencia: el intervalo del AUC absoluto mide 0,071 de ancho en promedio, veinte veces más, y usar ese para comparar arquitecturas sería falso, porque al comparar dos sobre las mismas filas el ruido común se cancela.
La regla estaba escrita antes de correr: entre las arquitecturas a menos de 0,002 de AUC de la mejor, quedarse con la más chica. Eligió una de 9.633 parámetros donde la mejor tenía 136.065, y sacrificó 0,0018 de AUC en validación por catorce veces menos parámetros.
El problema es que 0,002 era más fino de lo que esa validación puede medir. Remuestreando los bloques ciudad-año, el intervalo de la diferencia entre la elegida y la mejor va de −0,0045 a +0,0010: un ancho de 0,0055, casi tres veces el margen, y cruza el cero. Contra la segunda, el intervalo mide 0,0037 y también cruza.
Eso no invalida la regla, la explica: eligió la más chica entre arquitecturas que la validación no podía distinguir, que es exactamente para lo que sirve. Lo que hay que corregir para la próxima es de dónde sale el margen. Lo puse en el orden del ruido que mueve la semilla, unos 0,001, cuando debía salir del error de muestreo de la validación, que es cinco veces mayor.
Un detalle que casi me cuesta caro: el intervalo del AUC absoluto en validación mide 0,071 de ancho, veinte veces más. Es tentador usarlo para decir que la validación no distingue nada, y sería falso: al comparar dos arquitecturas sobre las mismas filas, el ruido de la muestra se cancela, y el único número honesto es el de la diferencia pareada.
La atención no es la importancia
Coinciden en la primera: lluvia de hoy se lleva 0,241 de la atención contra los 0,067 del reparto uniforme, y permutarla cuesta 0,103. De ahí para abajo se separan. cambio de presión recibe 0,097 de atención y cuesta 0,029, mientras viento (coseno) recibe 0,067 y cuesta 0,034: más daño con menos atención. punto de rocío recibe 0,062 y permutarla cuesta 0,002, o sea nada. Las cinco primeras por atención y las cinco primeras por daño no son el mismo conjunto.
La atención del [CLS] sobre las quince columnas se puede leer, y es la parte más vistosa del modelo. En la red elegida, la lluvia de hoy se lleva 0,241 cuando el reparto uniforme sería 0,067, y es también la columna cuya permutación más daño hace: el AUC cae 0,103. Ahí coinciden.
De ahí para abajo dejan de coincidir. El cambio de presión recibe 0,097 de atención y al permutarlo el AUC cae 0,029; la latitud recibe 0,095 y cae 0,036; el coseno del viento recibe 0,067 y cae 0,034, más que el cambio de presión con menos atención. El punto de rocío recibe 0,062 y permutarlo cuesta 0,002, o sea nada. Las cinco primeras por atención y las cinco primeras por daño no son el mismo conjunto.
Es lo que Jain y Wallace mostraron en 2019: los pesos de atención explican cómo se mezcla la información, no cuánta falta le hace al modelo. Un mapa de atención es una descripción del mecanismo, no una medida de importancia.
Quitarle la atención no la empeoró
Dieciocho diferencias pareadas, una por semilla, que van de -0,0063 a 0,0044, 8 de ellas positivas, y el signo cambia entre arquitecturas y hasta entre semillas de la misma. En la elegida (d32_b1) los dos reemplazos ganan; en d64_b4 los dos pierden; en d128_b2 se contradicen entre sí. El reemplazo de pesos iguales conserva V y la proyección de salida, así que los parámetros que corren son los mismos; el promedio crudo se los salta, y por eso es el control más débil. En quince columnas de clima, la atención no mueve el AUC más de lo que lo mueve cambiar la semilla.
Si la atención es la pieza que define al Transformer, la pregunta obvia es qué pasa sin ella. Probé dos reemplazos, en tres arquitecturas y con tres semillas cada uno: uno que mantiene todo el bloque pero reparte los pesos por igual entre los dieciséis tokens, las quince columnas y el [CLS], y otro que directamente promedia los tokens y se salta las proyecciones.
En la arquitectura elegida, quitarla mejora: 0,0026 con pesos iguales y 0,0040 con el promedio. En la de 136.065 parámetros empeora, 0,0048 y 0,0011. En la de 269.313 va en direcciones distintas según el reemplazo. Y dentro de una misma arquitectura hay semillas que cambian el signo.
Seis diferencias de medianas que van de −0,005 a +0,004, sin un signo estable, dicen una sola cosa, y no es que la atención estorbe: en quince columnas de clima, la atención no mueve el AUC más de lo que lo mueve cambiar la semilla.
La capa que la salva de la trampa y le apaga una columna
Sin escalar, el token crudo viaja 7,62 y lo que llega a la atención viaja 0,011: el logit se mueve 0,00017. En pascales el token crudo viaja 7.652 y el logit no se mueve nada. Estandarizada, el token normalizado viaja 9,84 y el logit cambia 0,59. El coseno entre tokens normalizados de días distintos da 1,000000 sin escalar contra 0,997476 estandarizado: la columna entra y dice lo mismo todos los días. Al quitar esa primera normalización la trampa vuelve a morder: el AUC cae a 0,573 en pascales contra 0,874 en kPa.
La trampa de unidades de la serie consiste en escribir la misma presión en pascales en vez de kilopascales, sin escalar. Al SVM lo hundía, a la red neuronal le disparaba la pérdida a 6,81. Acá no pasa nada: 0,8688 en kilopascales y 0,8688 en pascales, iguales hasta el cuarto decimal.
Mi primera explicación fue que cada columna tiene su propio peso y absorbe la escala. La medición la desmintió: el peso de la presión mide 0,5108 en kilopascales y 0,5128 en pascales, y sigue en 0,5128 multiplicando por un millón y por mil millones. No se encoge. Nadie compensa nada.
Lo que pasa es otra cosa. Con los pesos congelados, moviendo la presión de su mínimo a su máximo, el token crudo se desplaza 7,6 unidades y el token ya normalizado se mueve 0,011. El logit de salida cambia en 0,0002. En pascales el token crudo se desplaza 7.651 y el normalizado 0,00001: el logit no cambia nada. Estandarizando la columna, en cambio, el token normalizado se mueve 9,8 y el logit cambia 0,59.
La normalización previa a la atención, la que Ba, Kiros y Hinton propusieron en 2016, recibe un token cuyo valor típico es enorme frente a su variación entre días, y devuelve prácticamente el mismo vector para todas las filas: el coseno entre tokens normalizados de días distintos da 1,000000. La columna entra, pero no dice nada. Y se comprueba quitando esa capa: sin ella, la misma trampa hunde el AUC de 0,874 a 0,573.
Así que la pieza que protege al modelo del cambio de unidades es la misma que le apaga la columna. Escalar sigue siendo obligatorio, aunque la trampa ya no haga daño.
Probabilidades que se van para arriba
La red terminó con pérdida logarítmica 0,356, la peor de los modelos que compiten arriba: el boosting queda en 0,332. Predijo 27,3 % de lluvia en promedio cuando llovió el 20,3 % de los días. Por tramos: entre los días a los que les dio entre 0,6 y 0,7 predijo 0,648 y llovió el 0,491; entre 0,2 y 0,3 predijo 0,249 y llovió el 0,135. Recién en la banda más alta, con 568 días, se acerca: 0,938 contra 0,907. Para ordenar días sirve; para leer el número como probabilidad, no sin calibrar.
Con las 74.145 filas, la red terminó con pérdida logarítmica 0,356, la peor de los modelos que compiten arriba: el boosting queda en 0,332 y la red neuronal en 0,338. Predijo 27,3 % de lluvia en promedio cuando llovió el 20,3 %.
Por tramos se ve dónde: entre los días a los que les dio entre 0,6 y 0,7 predijo 0,648 y llovió el 0,491; entre 0,2 y 0,3 predijo 0,249 y llovió el 0,135. Sobreestima en casi toda la escala, y recién en la banda más alta se acerca. Para ordenar días sirve; para leer el número como probabilidad, no sin calibrar.
El costo
A un cuarto del tiempo real.
Las 27.256 filas, en tiempo real.
Todo de la misma corrida de un hilo. Serializado, el Transformer ocupa 49 KB, la red neuronal 81 KB, el boosting 2,1 MB y el bosque 124 MB, sin contar que el Transformer necesita PyTorch al lado. Puntuar una fila tomó 0,62 ms al Transformer, 0,42 a la red y 3,11 al boosting. En la corrida de costo, el ajuste con ocho hilos bajó de 41,3 s a 23,9 s: acá los hilos sí ayudan, al revés que en la red neuronal y en la SVM.
Es el modelo más caro de entrenar de los once y el tercero más lento al puntuar, para quedar 0,007 por debajo del mejor. A cambio es el más liviano de los cuatro que compiten arriba, y el cuarto de los once, aunque ese número engaña: los 49 KB son los pesos, y al lado hay que instalar PyTorch.
Para números, y el techo que no rompe
Para predecir la máxima de mañana, el Transformer erró por 1,56 °C en promedio, entre el boosting (1,44 °C) y la regresión lineal (1,70 °C).
La prueba de extrapolación de la serie lo deja peor parado que a nadie. Entrenado solo con las filas de abril a septiembre de Santiago y preguntado por los veranos de diciembre a febrero, predijo como máximo 23,09 °C cuando la máxima de mañana más alta que vio al entrenar era 32,97 °C, y erró por 6,71 °C. El boosting, que tampoco se sale, llegó a 29,56 °C y erró por 5,48 °C. La regresión lineal se fue hasta 36,97 °C y erró por 1,72 °C. La red neuronal del post anterior llegaba a 38,1 °C.
Es coherente con lo de la normalización: tokens normalizados acotados producen salidas acotadas. No lo mido directamente, así que lo dejo como coherente y no como demostrado.
Las dos lecturas anteriores, que no escondo
Antes de esta rejilla hubo otra, con un error de protocolo: usaba el AUC de 2010-2012 para dos cosas a la vez, detener cada ajuste y elegir entre candidatas. Eso es un máximo sobre veinte evaluaciones por época y después un máximo sobre ocho candidatas, sobre el mismo ruido. Es el sesgo de selección que Cawley y Talbot documentaron en 2010.
Aquella rejilla eligió una arquitectura de 269.313 parámetros con 0,8851 en validación. Al repetir el ajuste diez veces cambiando solo la semilla, el AUC se movía entre 0,8785 y 0,8851, y la semilla con la que había corrido toda la rejilla resultó ser la mejor de las diez. Con el protocolo corregido, esa misma arquitectura da 0,8791 y su rango entre semillas es 0,0015. No comparo las dos cifras de frente, porque una sale de diez semillas y la otra de tres y un rango crece con la cantidad de sorteos; lo que sí se puede decir es que buena parte de aquel 0,0066 no era el entrenamiento moviéndose, sino el procedimiento quedándose con el mejor de veinte momentos y de ocho candidatas.
Esa arquitectura se reajustó y se leyó en la prueba: dio 0,8805, con 200,7 s de reajuste. Después corregí el protocolo pero todavía sin medir el borde inferior de la rejilla, y con esa segunda regla la elegida fue otra, de 35.649 parámetros, que en la prueba dio 0,8810; ahí las diferencias contra la red neuronal, el boosting y el bosque cruzaban el cero con una de las tres semillas, así que no se distinguían de forma consistente.
Con la rejilla completa, incluido el borde inferior, la elegida es la de 9.633 parámetros y la prueba da 0,876, sin que ninguna diferencia cruce el cero con ninguna semilla. Los números más favorables salieron de los procedimientos peores, y por eso el procedimiento se fija antes y no se cambia después de ver el resultado.
Dónde vive un Transformer en un sistema real
Medido con un hilo sobre las 74.145 filas: 9.633 parámetros, 41,3 s de ajuste y 49 KB serializados, puntúa una fila en 0,62 ms y todo el período de prueba en 0,362 s, con AUC 0,8760 y pérdida logarítmica 0,3555. El boosting llega a AUC 0,8830 en 2,6 s. Con ocho hilos el ajuste baja a 23,9 s, así que acá los hilos sí ayudan. Y el artefacto no es el archivo: esos 49 KB son los pesos, con PyTorch para instalar al lado.
- Fuera de la tabla. Donde esta arquitectura se despega es en texto, imágenes, audio o series largas, donde el orden y el contexto son la señal. Quince columnas numéricas no son ese problema.
- El preprocesamiento dentro del artefacto. No porque la trampa de unidades haga daño, sino porque sin escalar una columna puede entrar apagada y no enterarse nadie.
- PyTorch al lado. Los pesos pesan 49 KB y el entorno que los ejecuta, cientos de megas. El artefacto no es el archivo.
- Semilla fija y varias corridas. Con tres semillas por arquitectura, la diferencia entre dos arquitecturas vecinas cabe dentro del ruido.
Cuándo lo elegiría: cuando el problema deja de ser una tabla. Cuándo no: para quince columnas numéricas donde un boosting llega más arriba en un dieciseisavo del tiempo.
Once modelos, la misma tabla
Acá termina la serie. Once algoritmos sobre las mismas 74.145 filas y la misma pregunta, y el techo quedó cerca de 0,883: lo alcanzan el boosting, la red neuronal y el bosque, y el Transformer se quedó 0,007 abajo.
Lo que separó a los modelos no fue el AUC. Fue el costo de entrenar y de puntuar frente a la precisión que se gana, el tamaño del artefacto, si hay que escalar, si hay que elegir tamaño, cuánto los mueve la semilla, y cuánto hay que medir para poder elegir con honestidad. El costo de entrenar y puntuar contra la precisión es justo lo que Grinsztajn y coautores midieron en 2022 a lo largo de muchos conjuntos tabulares; el resto, ahora, con datos propios.
Y lo que me llevo de los once no es cuál ganó. Son los dos hallazgos que aparecieron al medir con cuidado: que un procedimiento mal armado entrega el número más favorable, y que una rejilla puede separar con claridad lo que no compite y a la vez no ordenar lo que sí compite.
Límites de todo lo anterior: una sola tabla, CPU, un optimizador y un paso de aprendizaje, tres semillas por arquitectura, y un presupuesto de sesenta épocas.
Fuentes
- Vaswani, A. et al. (2017). «Attention Is All You Need». NeurIPS 2017.
- Gorishniy, Y., Rubachev, I., Khrulkov, V. y Babenko, A. (2021). «Revisiting Deep Learning Models for Tabular Data». NeurIPS 2021. Es el FT-Transformer del que sale esta variante.
- Jain, S. y Wallace, B. C. (2019). «Attention is not Explanation». NAACL 2019.
- Ba, J. L., Kiros, J. R. y Hinton, G. E. (2016). «Layer Normalization».
- Cawley, G. C. y Talbot, N. L. C. (2010). «On Over-fitting in Model Selection and Subsequent Selection Bias in Performance Evaluation». JMLR, 11, 2079–2107.
- Grinsztajn, L., Oyallon, E. y Varoquaux, G. (2022). «Why do tree-based models still outperform deep learning on typical tabular data?». NeurIPS Datasets and Benchmarks.
- Loshchilov, I. y Hutter, F. (2019). «Decoupled Weight Decay Regularization». ICLR 2019. Es el AdamW que usa el banco.
- NASA POWER, Daily API y fuentes de datos.
Comentarios
Todavía no hay comentarios. El primero es tuyo.