TabPFN y TabICL contra XGBoost ajustado: el modelo que no entrena ganó en catorce de catorce tablas

La afirmación circula desde hace meses y es lo bastante concreta como para poder medirla: un modelo fundacional tabular predice sobre una tabla sin haber entrenado nunca en ella y aun así le gana al boosting ajustado.

Si eso es cierto, media década de práctica cambia de forma. Buscar hiperparámetros deja de ser un paso obligatorio y pasa a ser un lujo que a veces no compensa.

Así que la puse a prueba en mi propia tarjeta, con catorce datasets, cuatro contendores y el mismo cronómetro para todos.

Qué hacen exactamente estos modelos

Un modelo fundacional tabular se preentrena sobre millones de tablas sintéticas generadas a propósito. Cuando le llega una tabla nueva, no ajusta un solo peso: recibe las filas de entrenamiento como contexto y produce las predicciones en una pasada hacia adelante.

Es la misma idea del aprendizaje en contexto que ya conocemos de los modelos de lenguaje, movida de las palabras a las columnas. Por eso el verbo “entrenar” queda raro: en el código se sigue llamando fit, pero ahí dentro no hay descenso de gradiente, hay una copia de datos a la tarjeta.

Eso también explica por qué el costo aparece donde uno no lo espera. El ajuste es casi gratis y la predicción es la que paga, justo al revés que en un árbol.

Dicho así suena abstracto, así que acá está el viaje completo de una fila: llega una petición con una casilla vacía, el modelo la contrasta contra todo lo que ya pasó, la resuelve de una pasada y devuelve un futuro. Elige cualquiera de los seis casos que medí para verlo con sus datos reales:

Riesgo de impagoCampaña comercialReingreso clínicoReincidenciaDemanda eléctricaCribado molecular

La petición

El contexto

Una sola pasada

La predicción

Llega una solicitud de crédito

2 100 solicitudes ya resueltas · 10 columnas
clf_num/credit.csv

TabICL · sin ajustar nada · 0.8 s

¿Va a pagar?

pagano paga

AUC 0.8528
credit

Entra un contacto a la lista

2 100 llamadas ya hechas · 7 columnas
clf_num/bank-marketing.csv

TabICL · sin ajustar nada · 0.8 s

¿Vale la pena llamarlo?

contratano contrata

AUC 0.8699
bank-marketing

Se da de alta a un paciente

2 100 altas anteriores · 7 columnas
clf_num/Diabetes130US.csv

TabICL · sin ajustar nada · 0.8 s

¿Va a volver a ingresar?

vuelveno vuelve

AUC 0.6484
Diabetes130US

Se evalúa una causa

2 100 casos ya cerrados · 11 columnas
clf_cat/compas-two-years.csv

TabICL · sin ajustar nada · 0.6 s

¿Va a reincidir?

reincideno reincide

AUC 0.7329
compas-two-years

Cierra un período de mercado

2 100 períodos anteriores · 7 columnas
clf_num/electricity.csv

TabICL · sin ajustar nada · 0.8 s

¿Sube o baja el precio?

subebaja

AUC 0.8873
electricity

Llega una molécula candidata

2 100 moléculas ya ensayadas · 419 columnas
clf_num/Bioresponse.csv

TabICL · sin ajustar nada · 6.0 s

¿Provoca respuesta biológica?

activainerte

AUC 0.8667
Bioresponse

La petición

El contexto

Una sola pasada

La predicción

Llega una solicitud de crédito

2 100 solicitudes ya resueltas · 10 columnas
clf_num/credit.csv

TabICL · sin ajustar nada · 0.8 s

¿Va a pagar?

pagano paga

AUC 0.8528
credit

Entra un contacto a la lista

2 100 llamadas ya hechas · 7 columnas
clf_num/bank-marketing.csv

TabICL · sin ajustar nada · 0.8 s

¿Vale la pena llamarlo?

contratano contrata

AUC 0.8699
bank-marketing

Se da de alta a un paciente

2 100 altas anteriores · 7 columnas
clf_num/Diabetes130US.csv

TabICL · sin ajustar nada · 0.8 s

¿Va a volver a ingresar?

vuelveno vuelve

AUC 0.6484
Diabetes130US

Se evalúa una causa

2 100 casos ya cerrados · 11 columnas
clf_cat/compas-two-years.csv

TabICL · sin ajustar nada · 0.6 s

¿Va a reincidir?

reincideno reincide

AUC 0.7329
compas-two-years

Cierra un período de mercado

2 100 períodos anteriores · 7 columnas
clf_num/electricity.csv

TabICL · sin ajustar nada · 0.8 s

¿Sube o baja el precio?

subebaja

AUC 0.8873
electricity

Llega una molécula candidata

2 100 moléculas ya ensayadas · 419 columnas
clf_num/Bioresponse.csv

TabICL · sin ajustar nada · 6.0 s

¿Provoca respuesta biológica?

activainerte

AUC 0.8667
Bioresponse

Riesgo de impago

gana el fundacional

El caso más repetido de la banca: decidir a quién se le presta.

dataset	tamaño	TabICL	TabPFN	XGB ajustado
credit	3000 × 10	0.7667	0.7578	0.7533
heloc	3000 × 22	0.7222	0.7300	0.7078
default-of-credit	3000 × 20	0.6956	0.6967	0.6944

Los tres datasets van al modelo fundacional. En heloc TabPFN saca 0.022 y TabICL 0.014: en riesgo crediticio eso no es decoración.

Contexto: clf_num/credit.csv del banco inria-soda/tabular-benchmark, recortado a 3 000 filas con semilla 0 y partido 70/30 con estratificación.
sha256 22a759296600c39a56884dafd84eb346be018c537ff096adc8c2ae7e0520f2a9

Campaña comercial

gana el fundacional

A quién llamar primero cuando hay mil contactos y tiempo para cien.

dataset	tamaño	TabICL	TabPFN	XGB ajustado
bank-marketing	3000 × 7	0.7944	0.7967	0.7833

Único caso donde TabPFN queda por delante de TabICL. Los dos superan al boosting ajustado.

Contexto: clf_num/bank-marketing.csv del banco inria-soda/tabular-benchmark, recortado a 3 000 filas con semilla 0 y partido 70/30 con estratificación.
sha256 3433fecd416ce949692442882669881746e8a6b24b904a5f808cdcb196443e7e

Reingreso clínico

gana el fundacional

Registro hospitalario real: qué paciente vuelve a ingresar.

dataset	tamaño	TabICL	TabPFN	XGB ajustado
Diabetes130US	3000 × 7	0.5911	0.5933	0.5900

Por exactitud casi empatan, pero el área bajo la curva se abre fuerte: 0.6484 contra 0.6264. El ordenamiento de riesgo, que es lo que un triaje usa, mejora bastante más de lo que sugiere la exactitud.

Contexto: clf_num/Diabetes130US.csv del banco inria-soda/tabular-benchmark, recortado a 3 000 filas con semilla 0 y partido 70/30 con estratificación.
sha256 9be384ad7edbb9a98b509adb9cc08578e63bd87545b05d97d5147aa15b71385a

Reincidencia

gana el fundacional

El dataset que abrió el debate sobre sesgo algorítmico en tribunales.

dataset	tamaño	TabICL	TabPFN	XGB ajustado
compas-two-years	3000 × 11	0.6733	0.6767	0.6700

Gana el fundacional, y conviene decir que un modelo mejor acá no vuelve legítimo el uso: la discusión de este dataset nunca fue de exactitud.

Contexto: clf_cat/compas-two-years.csv del banco inria-soda/tabular-benchmark, recortado a 3 000 filas con semilla 0 y partido 70/30 con estratificación.
sha256 7e0bcef09ae633ad81e26b0a8f8f96dbc4ac3c29b9da0760d38ef2a75adde8d8

Demanda eléctrica

empate

Series de consumo y precio de un mercado eléctrico.

dataset	tamaño	TabICL	TabPFN	XGB ajustado
electricity	3000 × 7	0.8178	0.8111	0.8178

El empate. TabICL iguala al boosting ajustado hasta el cuarto decimal y TabPFN queda abajo. Es uno de los dos casos donde la ventaja no aparece.

Contexto: clf_num/electricity.csv del banco inria-soda/tabular-benchmark, recortado a 3 000 filas con semilla 0 y partido 70/30 con estratificación.
sha256 d6005007c4b1f7ba88cf91cb1f231969cce3e49c98d445338c0ab0342ead5d7e

Cribado molecular

depende del modelo

419 columnas de descriptores químicos: la tabla ancha.

dataset	tamaño	TabICL	TabPFN	XGB ajustado
Bioresponse	3000 × 419	0.7922	0.7567	0.7744

Acá se rompe TabPFN: 0.7567 es peor incluso que XGBoost sin ajustar, y le cuesta 18.1 segundos. TabICL aguanta y queda primero. El ancho de la tabla, no su largo, es lo que aprieta.

Contexto: clf_num/Bioresponse.csv del banco inria-soda/tabular-benchmark, recortado a 3 000 filas con semilla 0 y partido 70/30 con estratificación.
sha256 bd3d277821eb949df41219363f0386549019249776fccf7a9f08d3bec10b8727

Para qué sirve esto, en concreto

Los seis casos del diagrama no son ejemplos de folleto: son los datasets con los que medí. Pero conviene ampliar el mapa, porque “modelo fundacional tabular” suena a laboratorio y el problema que resuelve es de los más comunes que existen.

Una tabla es una hoja de cálculo: filas que son casos y columnas que son atributos. Y la tarea es siempre la misma, predecir una columna a partir de las otras:

• Una tabla de clientes con antigüedad, plan, consumo y reclamos, para estimar cuáles se van a ir el mes que viene.
• Un registro de transacciones con monto, comercio, hora y país, para marcar cuáles son fraude.
• Un historial de solicitudes de crédito con ingresos, deudas y comportamiento de pago, para estimar quién no va a pagar. De hecho, tres de los datasets que medí son exactamente eso: credit, heloc y default-of-credit.
• Lecturas de sensores de una máquina, para anticipar cuándo se va a romper.
• Fichas de pacientes con síntomas y análisis, para priorizar a quién se atiende primero. Diabetes130US, otro de los datasets, es un registro hospitalario real.

Esa es la mitad del trabajo de datos que se hace en cualquier empresa. Es también el terreno donde el aprendizaje profundo llevaba años perdiendo: para tablas, un buen gradiente potenciado sobre árboles seguía siendo la respuesta correcta, y la investigación que juntó estos datasets se titulaba justamente así, preguntando por qué los árboles todavía ganaban.

Qué cambia si la promesa se cumple

Hoy, resolver cualquiera de esos casos tiene un ritual: preparar los datos, elegir un modelo, buscar hiperparámetros, validar, repetir. La búsqueda es la parte aburrida y es la que consume horas de máquina y de persona. En este banco, la búsqueda de XGBoost tardó hasta 50 segundos por dataset; en un problema real con más filas y más combinaciones, son minutos u horas.

Un modelo fundacional tabular propone saltarse ese ritual completo. Le pasas la tabla, responde en un segundo, y ya. Sin elegir profundidad de árbol, sin tasa de aprendizaje, sin validación cruzada para decidir entre veinticinco candidatos.

Puesto en el caso concreto: en vez de dedicar la tarde a ajustar un modelo de fuga de clientes, tienes una respuesta en lo que tarda el café, y recién ahí decides si vale la pena afinar algo. Para explorar una tabla que acaba de llegar, o para tener una línea base honesta antes de invertir tiempo, es difícil de superar.

La pregunta, entonces, no es si la idea es atractiva. Es si el resultado aguanta cuando se mide.

Las reglas del banco

Un benchmark mal armado dice lo que uno quiera. Estas son las reglas que me impuse antes de ver un solo número:

Los datos son de terceros y del campo donde se pelea esta discusión. Usé el banco tabular de Grinsztajn, el suite reunido para el trabajo que preguntaba por qué los árboles seguían ganándole al aprendizaje profundo en tablas. Elegir los datasets uno mismo es la forma más fácil de fabricar el resultado que a uno le gusta.

XGBoost va ajustado, no de adorno. La afirmación dice “boosting ajustado”, así que compararlo con parámetros de fábrica sería un hombre de paja. Corrí dos versiones: una con parámetros razonables fijos y otra con búsqueda aleatoria de veinticinco combinaciones y validación cruzada de tres pliegues.

Mismo split, misma semilla, mismas columnas para todos. Las categóricas se codifican con enteros. No es el mejor tratamiento posible, pero es idéntico para los cuatro, que es lo que hace comparable el número.

Cinco semillas por dataset, y se reporta la mediana. Un solo split no distingue señal de suerte.

El tiempo de predicción incluye dos pasadas de inferencia, la de la clase y la de las probabilidades, porque el banco necesita las dos para calcular exactitud y área bajo la curva. Eso encarece justamente a los modelos fundacionales, que es donde vive su costo, así que los segundos que publico para ellos están inflados a su favor de nadie.

Se dejan dos núcleos libres. La máquina tiene otro trabajo encima, y un benchmark que se come la CPU entera mide la pelea por el planificador, no el modelo.

Todo corrió en una RTX 4070 Ti SUPER de 16 GB, con catorce núcleos para XGBoost.

Tres tropiezos antes del primer número

Publicar solo la tabla final sería mentir por omisión. Esto es lo que costó llegar a ella.

PyTorch apagó la GPU sin avisar

Instalé el entorno, corrí el banco, y la primera línea decía dispositivo: cpu. La tarjeta estaba libre y visible. El motivo:

2.13.0+cu130   driver 570.144   torch.cuda.is_available() → False

PyTorch se había resuelto a una compilación para CUDA 13.0 mientras el controlador de la máquina expone 12.8. En vez de fallar, desactiva la GPU en silencio y sigue por CPU. El aviso solo aparece si uno inspecciona torch.cuda.is_available() a mano.

Se arregla anclando la versión al índice correcto:

pip install --no-cache-dir \
  --index-url https://download.pytorch.org/whl/cu128 torch==2.9.1+cu128

Es la segunda vez este año que esta misma trampa me cuesta una corrida entera. Si un banco de pruebas con GPU da números sospechosamente lentos, ese es el primer lugar donde mirar.

La API de OpenML devolvió 504 en todos sus extremos

El plan original era tomar los datasets de OpenML, que es la fuente canónica de estas comparaciones. Falló completa durante la corrida:

https://api.openml.org/api/v1/json/data/31          → 504 (16.9 s)
https://www.openml.org/api/v1/json/data/31          → 504 (15.7 s)
https://api.openml.org/api/v1/json/data/features/31 → 504 (16.5 s)

Cuatro reintentos con espera creciente no sirvieron de nada: no era un problema de ritmo, era la pasarela caída. Cambié la fuente a los CSV del mismo banco alojados en HuggingFace, que resolvieron en 250 milisegundos. Es un recordatorio incómodo de cuánta investigación reproducible depende de un único servicio.

El modelo más citado ya no se descarga sin cuenta

Este es el hallazgo que más me interesa, porque no es técnico.

TabPFN es el nombre que aparece en casi toda la cobertura de este tema. Instalé la versión actual, la 8.3.0, y al primer fit:

TabPFNLicenseError: TabPFN requires a one-time license acceptance
to download model weights for local inference, but no interactive
terminal is available.

Para bajar los pesos hay que abrir un navegador, registrarse, aceptar la licencia en una pestaña de la web del fabricante y exportar un token de cuenta. El modelo fundacional tabular más conocido dejó de ser algo que se instala y se corre.

Hay dos salidas, y probé las dos:

• La serie 2.x de TabPFN todavía baja los pesos sin registrarse. Instalé la 2.2.1 en un entorno aparte y funcionó a la primera. Es la que aparece en las tablas de abajo.
• TabICL, del equipo Soda de Inria, tiene licencia BSD de tres cláusulas y descarga sin barrera alguna. Resultó ser, además, el mejor de los dos.

Los números

Catorce datasets, todos recortados a 3 000 filas para que la comparación sea homogénea. Exactitud como mediana de cinco semillas. La columna de segundos suma ajuste y predicción, que es el costo honesto de cada uno:

Contra el XGBoost ajustado, por exactitud:

• TabICL: doce victorias, un empate (electricity) y una derrota (albert). Diferencia media +0.0106.
• TabPFN 2.2.1: once victorias, un empate (albert) y dos derrotas (electricity y Bioresponse). Diferencia media +0.0075.

La exactitud, sin embargo, es una métrica tosca: depende del umbral y castiga distinto según cómo estén balanceadas las clases. El área bajo la curva es más informativa, y ahí el resultado se vuelve más nítido:

TabICL le gana al XGBoost ajustado en todos los datasets sin excepción. Incluso en albert, donde pierde por exactitud, tiene mejor AUC (0.7101 contra 0.7094). Ese detalle es justamente por qué conviene mirar las dos métricas: la exactitud decía “derrota” donde el ordenamiento de probabilidades decía “victoria por un pelo”.

Ahora bien, conviene calibrar el entusiasmo. Ganar catorce de catorce es una señal fuerte de consistencia, no de superioridad aplastante: la diferencia media es de una centésima. Nadie va a notar eso en un tablero. Lo que sí se nota es lo otro.

El costo está al revés de lo que uno espera

Mira otra vez las dos últimas columnas de la tabla. TabICL resuelve un dataset en menos de un segundo sin ajustar nada. El XGBoost ajustado tarda entre 0.7 y 27.2 segundos buscando hiperparámetros, y aun así queda abajo.

Ese es el argumento real, y no es la exactitud. Es que la parte cara del trabajo, la que consume tiempo de persona y de máquina, simplemente desaparece.

La sorpresa: la ventaja no se rompe con el tamaño

Aquí es donde yo esperaba desarmar la promesa. La objeción estándar a estos modelos es que solo funcionan en tablas de juguete, porque las filas de entrenamiento tienen que caber en el contexto del transformador.

Tomé jannis, que trae 57 580 filas, y lo recorté a tamaños crecientes. Tres semillas por tamaño:

La ventaja no se rompe, y en el extremo grande se consolida: +0.030 a las 32 000 filas. Y el reparto de tiempos se abre en la dirección contraria a la intuición: 11.7 segundos contra 50.3.

Conviene decir con precisión qué crece y qué no, porque la diferencia importa. Lo que sube de forma sostenida es la exactitud absoluta de TabICL: 0.7533, 0.7733, 0.7800, 0.7817, 0.7958, 0.8090, 0.8230, monótona en las siete medidas. La ventaja sobre XGBoost, en cambio, es irregular: 0.000, +0.020, +0.013, +0.009, +0.038, +0.024, +0.030. Sube y baja.

Y en 4 000 filas esa ventaja de +0.009 es menor que la dispersión entre las tres semillas (TabICL va de 0.768 a 0.799; el XGBoost ajustado, de 0.758 a 0.790), así que en ese punto no se distingue del ruido y no la cuento como victoria.

Donde sí es sólida es arriba: en 32 000 filas la peor semilla de TabICL (0.8216) queda por encima de la mejor de XGBoost (0.7950). Ahí no hay solapamiento posible.

El único lugar donde XGBoost gana limpio es el extremo pequeño, con 500 filas, donde la variabilidad entre semillas es tan alta que yo no apostaría nada a esa diferencia.

Si esperabas, como yo, que la curva se diera vuelta en algún punto, aquí no lo hace. Habría que subir bastante más para encontrarlo.

Dónde sí se rompen

Bioresponse es el dataset delator: 419 columnas.

TabPFN 2.2.1 cae a 0.7567, el peor de los cuatro contendores, por debajo incluso del XGBoost sin ajustar. Y le cuesta 18.1 segundos, veinticinco veces más que en un dataset normal. TabICL aguanta mucho mejor (0.7922, el mejor de los cuatro) pero también paga: 6.0 segundos contra los 0.8 habituales.

La lectura es que el ancho de la tabla, no su largo, es el eje que aprieta de verdad. Tiene sentido: el número de columnas entra en el costo de atención del transformador, y el preentrenamiento sintético cubre bien las tablas de decenas de columnas, no las de cientos.

Lo que esta medición no dice

Prefiero enumerar los límites que fingir que no existen:

• Solo clasificación binaria. No probé regresión ni multiclase.
• Techo de 3 000 filas en la tabla principal. El barrido de escala llega a 32 000, pero en un solo dataset.
• La búsqueda de hiperparámetros fue de veinticinco combinaciones. Un ajuste más agresivo cerraría parte de la brecha; cuánta, no lo sé, porque no lo medí.
• La búsqueda de XGBoost optimizó exactitud, y después lo comparo también por área bajo la curva. Es decir, el “catorce de catorce en AUC” es contra un boosting que no se ajustó para esa métrica. Ajustarlo para AUC probablemente lo mejore ahí; no lo medí.
• Las categóricas se codificaron con enteros para todos. Un tratamiento mejor favorecería a XGBoost más que a los otros.
• La codificación y el relleno de nulos se calcularon sobre la tabla completa, antes de partir. Es la misma fuga para los cuatro modelos, así que no cambia quién gana, pero infla un poco a todos y no debería hacerse así.
• Varias victorias por exactitud son menores que la variación entre semillas. Diabetes130US se gana por 0.0011 cuando la diferencia por semilla va de −0.011 a +0.049: ahí el signo depende de la semilla que toque. El conteo por área bajo la curva sí aguanta semilla por semilla; el de exactitud, en tres o cuatro datasets, no.
• Lo de la tabla ancha se apoya en un solo dataset. Bioresponse es el único con cientos de columnas, así que “el ancho es lo que aprieta” es una hipótesis con una observación, no una regla.
• La versión actual de TabPFN, la 8.3.0, quedó sin medir por la barrera de licencia. Los números de TabPFN son de la 2.2.1, dos series por detrás.
• La CPU estaba compartida con otro trabajo de la máquina. Eso afecta a los tiempos de XGBoost más que a los de la GPU, así que si algo, juega en contra de los modelos fundacionales en la comparación de tiempos.

Cuándo lo usaría y cuándo no

Lo usaría en cualquier tabla de entre mil y treinta mil filas con menos de cien columnas, donde el tiempo de la persona valga más que la última centésima. Un segundo de cómputo, cero ajuste, y un resultado que en mi medición fue consistentemente mejor. Para una exploración inicial es difícil de justificar no hacerlo.

No lo usaría en tablas muy anchas, donde se degrada y se encarece. Tampoco en producción sin GPU, ni donde haga falta un artefacto pequeño, inspeccionable y desplegable en un contenedor liviano: un árbol entrenado pesa kilobytes y corre en cualquier parte, mientras que aquí hay que cargar un transformador.

Y si el criterio incluye poder auditar de dónde salen los pesos, hoy la respuesta es TabICL. No por rendimiento, aunque también fue el mejor de los dos, sino porque es el que todavía se puede bajar y correr sin pedirle permiso a nadie.

---

Medido el 16 de agosto de 2026 en una RTX 4070 Ti SUPER de 16 GB, con torch 2.9.1+cu128, XGBoost 3.4.1, TabICL 2.1.1 y TabPFN 2.2.1. Datos del banco tabular inria-soda/tabular-benchmark. La tabla principal tomó 585 segundos y el barrido de escala, 514.

Fuentes

• Accurate predictions on small data with a tabular foundation model, Hollmann et al., Nature 637 (2025). El artículo de TabPFN v2, con el método de preentrenamiento sobre tablas sintéticas del que sale toda la idea.
• TabPFN: A Transformer That Solves Small Tabular Classification Problems in a Second, arXiv:2207.01848. El trabajo original de 2022, útil para ver qué cambió entre la primera versión y la actual.
• TabICL: A Tabular Foundation Model for In-Context Learning on Large Data, arXiv:2502.05564. El modelo del equipo Soda de Inria que ganó mi medición, con su propuesta para escalar a tablas grandes.
• soda-inria/tabicl. La implementación, con licencia BSD de tres cláusulas: se descarga sin registrarse.
• PriorLabs/TabPFN. El repositorio de TabPFN, donde se ve la barrera de licencia y token de cuenta que aparece a partir de la serie 8.