Por qué los LLM fallan en predicción tabular (paper 2026)

En pocas palabras: Un estudio de 2026 de CWI, Leiden University y TU Eindhoven comprobó que los LLMs fallan en predicción tabular por culpa de la dimensionalidad. Con más de 16 columnas colapsan: rinden igual o peor que adivinar la clase mayoritaria, sin importar el formato ni la tokenización.

Si alguna vez intentaste usar ChatGPT o Claude para clasificar datos de una planilla de Excel con 20 columnas y el resultado fue un desastre, no era tu prompt el problema. Un estudio publicado en 2026 por investigadores de CWI, Leiden University y TU Eindhoven confirmó lo que muchos sospechábamos: los modelos de lenguaje colapsan en predicción tabular apenas la cantidad de columnas supera las 16. Y no es por el formato, ni por la tokenización, ni por cómo armás el batch de prueba. Es la dimensionalidad, punto.

El paper, titulado Why Large Language Models Fail at Tabular Prediction, evaluó sistemáticamente cinco hipótesis y descartó cuatro. La única que sobrevivió al escrutinio experimental fue la hipótesis de dimensionalidad (H5): el rendimiento del LLM se desploma cuando hay muchas columnas, mientras que los modelos clásicos —bosques aleatorios, kNN, procesos Gaussianos— mejoran o se mantienen. A partir de d=16, el LLM rinde igual o peor que adivinar la clase mayoritaria. Sí, leíste bien.

La predicción tabular con LLM es el intento de usar modelos de lenguaje grande —como GPT-4, Claude o Gemini— para clasificar filas en bases de datos estructuradas, del estilo “dado el historial de un cliente, ¿compra o no compra?”. El paper de 2026 demuestra que estos modelos, entrenados para lenguaje natural, fallan de forma estrepitosa cuando las tablas tienen más de 16 columnas, sin importar cómo formatees los datos o qué prompt uses. Es un límite estructural, no una cuestión de ajuste fino.

¿Qué dice el estudio de 2026 sobre el colapso de los LLM con tablas?

El paper de CWI, Leiden University y TU Eindhoven (2026) puso a prueba una sospecha que circulaba hace rato entre quienes trabajamos con datos: los LLM no entienden tablas como creemos. Los investigadores diseñaron un benchmark controlado con datasets sintéticos donde la dimensionalidad —la cantidad de columnas o features— era la única variable que cambiaba. ¿El resultado? Hasta 16 columnas, el LLM zafa. Pasado ese umbral, se cae a pedazos.

Lo más llamativo es que el LLM sí lee la tabla completa —los investigadores verificaron que puede recuperar información hasta aproximadamente 60 columnas sin problema— pero no logra combinarlas para tomar una decisión de clasificación. Es como si pudiera leer cada celda pero no pudiera razonar sobre las relaciones entre columnas cuando hay muchas. Ojo: no es un tema de contexto máximo ni de ventana de atención, es algo más profundo que todavía no se entiende del todo.

¿Por qué se pensaba que los LLM fallan y qué se descartó?

Antes de este paper, circulaban cuatro explicaciones populares para el mal desempeño de los LLM en datos tabulares. Los investigadores las evaluaron una por una con experimentos controlados, y las cuatro quedaron en el camino. La única que se sostuvo fue la quinta: la dimensionalidad pura y dura. Veamos cada hipótesis y qué pasó con ella.

H1 — Solapamiento entre clases: la idea era que los LLM fallan cuando las clases se superponen en el espacio de features. Falso. Los experimentos mostraron que el colapso ocurre incluso cuando las clases son perfectamente separables. No depende de qué tan mezcladas estén.

H2 — Formato CSV linealizado: se sospechaba que representar la tabla como texto plano confunde al modelo. Falso también. Probaron con distintos formatos de serialización y el resultado fue el mismo desplome a partir de 16 columnas. Sobre eso hablamos en nuestra guía sobre modelos de lenguaje.

H3 — Tokenización numérica: la segmentación de números en sub-tokens (un 3.14159 partido en varios tokens) supuestamente arruinaba la representación. Los investigadores ajustaron la precisión numérica y manipularon la tokenización, y no cambió nada. La caída seguía ahí.

H4 — Tamaño del lote de prueba: ¿y si el problema es que el modelo no procesa bien muchas filas juntas? Probaron lotes de distintos tamaños y el patrón de colapso persistió. No era el batch.

H5 — Dimensionalidad: a diferencia de las otras cuatro, esta hipótesis se confirmó en todos los experimentos. La precisión cae sistemáticamente cuando la cantidad de columnas crece, y solo le pasa al LLM. Los modelos clásicos no sufren este efecto; al contrario, aprovechan las columnas extra para mejorar sus predicciones.

Hipótesis	Descripción	Resultado
H1 – Solapamiento	El LLM falla por clases mezcladas	Falsificada
H2 – Formato CSV	La serialización de la tabla confunde al modelo	Falsificada
H3 – Tokenización	La forma de tokenizar números arruina la representación	Falsificada
H4 – Tamaño de lote	Procesar muchas filas juntas degrada el rendimiento	Falsificada
H5 – Dimensionalidad	La cantidad de columnas causa el colapso	Confirmada

¿Qué tan malo es el desempeño de los LLM con tablas de muchas columnas?

Acá viene el dato que te va a hacer reconsiderar ese pipeline que armaste con GPT-4 para clasificar leads. Los investigadores compararon nueve métodos distintos —desde procesos Gaussianos y kNN hasta bosques aleatorios y el propio LLM— y el resultado fue demoledor: el LLM es el único método que empeora cuando agregás columnas. Todos los demás mejoran o se mantienen estables. Pasado d=16, la precisión del LLM cae por debajo del baseline de adivinar la clase mayoritaria (el “majority class classifier”, que es básicamente decir siempre la misma clase).

Pensalo así: si tenés una tabla con 30 columnas y el 70% de las filas son de clase A, el LLM va a tener una precisión igual o peor al 70% que obtendrías diciendo “clase A” para todo sin mirar los datos. Estás gastando tokens, tiempo y plata en una predicción que es peor que no hacer nada. Y sí, los modelos clásicos en esa misma tabla con 30 columnas están arriba del 90% de precisión sin sudar. La diferencia es ridícula.

El experimento de proyecciones aleatorias que usaron es brillante en su simpleza: generaron datasets donde cada columna nueva aporta información relevante para la clasificación. Si el modelo razonara correctamente, debería aprovechar esa información extra. Los GP, kNN, árboles y bosques lo hacen. El LLM, no. Es más, cuantas más columnas le das, peor le va —como si la información adicional lo confundiera en vez de ayudarlo. Esto se conecta con lo que analizamos en la guía completa de GPT.

¿Cómo se comporta un LLM en tablas de solo dos columnas?

Este hallazgo es de los más interesantes del paper, y te lo cuento porque le da un giro a la narrativa de “los LLM no sirven para tablas”. En datasets de apenas dos dimensiones (dos columnas predictoras), el LLM se comporta exactamente como un clasificador por distancia: sus fronteras de decisión coinciden en un 91-92% con las de un proceso Gaussiano y un kNN con k=1, según los experimentos reportados en PNAS Nexus (2026).

Las diferencias entre el LLM y los modelos clásicos aparecen solo en dos situaciones muy concretas: en la frontera de decisión (donde cualquier modelo razonable duda) y en zonas donde los datos de entrenamiento son ambiguos. Fuera de eso, dibujan la misma raya en la arena. Esto sugiere que el LLM sí aprendió algo parecido a una métrica de distancia durante su entrenamiento —probablemente porque el lenguaje natural está lleno de relaciones de similitud— pero esa capacidad se diluye cuando la dimensionalidad crece y exige razonar sobre combinaciones de atributos.

Es un dato que invita a preguntarse: ¿y si el problema no es que los LLM sean intrínsecamente malos para tablas, sino que su mecanismo de razonamiento actual no escala con la dimensionalidad? Los autores del paper dejan esto como pregunta abierta, y la verdad es que tiene sentido. Si en 2D funciona como un kNN, el potencial está ahí. Lo que falta es entender por qué se rompe después.

¿Hay algún modelo clásico que imite al LLM en altas dimensiones?

Los investigadores hicieron algo que me parece genial: intentaron encontrar un modelo clásico que reprodujera las predicciones del LLM en alta dimensionalidad, para entender qué está haciendo el modelo internamente. Probaron 252 configuraciones distintas de modelos tradicionales. ¿El que más se pareció al LLM? Apenas un 64.8% de acuerdo. Para que te des una idea, eso es como decir que ni la mejor imitación llega a dos tercios de lo que hace el LLM.

Acá es donde la cosa se pone rara. Como no encontraban un modelo que imitara al LLM, probaron agregar ruido artificial que aumentara con la dimensionalidad —la hipótesis siendo que quizás el LLM está tomando decisiones cada vez más ruidosas cuando hay muchas columnas. ¿La mejora con este truco? 0.64 puntos porcentuales. Nada. El comportamiento del LLM en alta dimensión sigue siendo una caja negra que ningún modelo conocido puede replicar. Los autores del paper de CWI (2026) concluyen honestamente que no saben qué mecanismo interno produce este colapso.

Para un investigador, esto es un problema abierto fascinante. Para vos que estás en producción, es una señal de alarma: si ni siquiera los que estudian esto a fondo pueden explicar qué pasa internamente, ¿vas a confiar una decisión de negocio a un modelo cuyo razonamiento nadie entiende?

¿Qué modelos funcionan mejor que los LLM para datos tabulares?

La respuesta corta: prácticamente cualquier modelo clásico. La respuesta con respaldo experimental: los investigadores compararon nueve métodos en el mismo benchmark donde los LLM colapsan, y estos fueron los resultados con datasets de más de 16 columnas:

• Procesos Gaussianos (GP): mantienen precisión alta sin importar cuántas columnas agregues. Ideales si tenés pocas filas pero muchas columnas.
• k-Nearest Neighbors (kNN): comportamiento similar al GP, con la ventaja de ser trivial de implementar y explicar.
• Bosques aleatorios y árboles de decisión: los caballitos de batalla para datos tabulares. No solo no se caen, sino que mejoran su precisión con cada columna relevante que les tires.
• Regresores logísticos: simples y efectivos. En alta dimensionalidad con datos linealmente separables, son un golazo.
• XGBoost: (no mencionado explícitamente en el paper pero ampliamente validado en benchmarks tabulares) consistentemente rankea entre los mejores para datos estructurados.

Lo que me parece clave del paper es que no encontraron ninguna configuración de prompt, formato ni preprocesamiento que salvara al LLM del colapso dimensional. Así que la recomendación es tajante: para clasificación tabular, los modelos clásicos son superiores, más baratos y más predecibles. El LLM para otra cosa. Cubrimos ese tema en detalle en el análisis detallado de ChatGPT.

¿Cuántas columnas puede procesar un LLM en una tabla sin perder precisión?

El paper identifica el punto de quiebre alrededor de las 16 columnas. Hasta ahí, el LLM mantiene una precisión comparable a los modelos clásicos. Pasado ese umbral, el rendimiento se degrada progresivamente hasta volverse inútil —literalmente peor que adivinar siempre la clase más frecuente. Y esto es independiente del modelo específico: los investigadores probaron con distintos LLMs y el patrón de colapso se mantuvo consistente.

Ojo con interpretar esto como “16 columnas es el máximo universal”. El número exacto puede variar según la complejidad de las relaciones entre columnas, la cantidad de ruido en los datos y el modelo específico. Pero la tendencia es clara e ineludible: a más columnas, peor precisión. Solo le pasa al LLM.

¿Hay LLM especializados en datos tabulares? ¿Funcionan mejor?

Existen intentos como TabLLM y TabPFN —modelos que adaptan arquitecturas de lenguaje o transformers específicamente para datos tabulares— pero el paper de 2026 se enfoca en LLMs de propósito general (tipo GPT-4 y Claude) usados sin fine-tuning específico para tablas. Estos modelos especializados no sufren el mismo colapso dimensional porque justamente fueron entrenados para manejar datos estructurados, pero su adopción está lejos de ser masiva y su desempeño en benchmarks reales sigue estando por debajo de un buen XGBoost bien tuneado en la mayoría de los casos.

La pregunta que muchos se hacen es si vale la pena usar un TabLLM cuando un bosque aleatorio te da mejores resultados en menos tiempo y sin GPU. Mi respuesta: salvo que tengas un caso muy específico donde el modelo necesite razonar sobre el significado semántico de las columnas (ej. nombres de productos, descripciones cortas mezcladas con datos numéricos), no vale la pena. Y aún en esos casos, un pipeline de embeddings + XGBoost probablemente rinda mejor.

Errores comunes al usar LLM para predicción tabular

Después de ver este paper, me doy cuenta de que varios errores son más frecuentes de lo que pensaba. Estos son los que veo todo el tiempo en equipos de datos que intentan meter LLMs donde no van:

1. Insistir con prompts más largos o “mejores”. El paper demuestra que el formato del prompt no cambia el colapso dimensional. Si tu LLM falla con 20 columnas, no es que necesitás un prompt más descriptivo o ejemplos few-shot: el problema es estructural. Dicho de otra forma: estás gastando tokens en algo que el modelo no puede resolver. Lo explicamos a fondo en nuestro artículo sobre Claude.

2. Confundir “leer” con “razonar”. Que el LLM pueda recuperar datos de una tabla de 50 columnas no significa que pueda clasificar usando esas 50 columnas. El paper muestra que la lectura es buena hasta ~60 columnas, pero la clasificación muere a las 16. Son dos capacidades distintas, y muchos equipos asumen que si el modelo “entiende” la tabla, va a poder predecir. No es así.

3. Usar al LLM como benchmark único. Si estás comparando pipelines y tu baseline es un LLM, estás midiendo contra un método que colapsa en alta dimensión. Es como correr una maratón contra alguien que se cae a los 5 kilómetros —vas a ganar, pero no aprendiste nada útil. Siempre incluí un bosque aleatorio o un XGBoost en tus benchmarks tabulares.

4. Ignorar que los modelos clásicos mejoran con más columnas. Hay un sesgo cognitivo acá: como los LLMs son “inteligentes” y “razonan”, tendemos a asumir que van a aprovechar mejor la información que un modelo estadístico tonto. El paper demuestra exactamente lo contrario: los modelos “tontos” son los que aprovechan las columnas extra; el LLM se ahoga con ellas.

Preguntas Frecuentes

¿Por qué los modelos de lenguaje grandes no funcionan con datos de tablas?

Según el estudio de 2026, el problema es la dimensionalidad: los LLM colapsan cuando la tabla tiene más de aproximadamente 16 columnas. No importa el formato del prompt, la tokenización ni cómo serialices los datos —el rendimiento cae sistemáticamente con cada columna adicional, mientras que los modelos clásicos como bosques aleatorios o XGBoost mejoran o se mantienen estables.

¿Qué tan bien clasifican los LLM datos tabulares comparado con otros modelos?

En tablas con pocas columnas (2 a 16), los LLM clasifican de forma comparable a un kNN o un proceso Gaussiano, con un 91-92% de acuerdo en fronteras de decisión. Pasadas las 16 columnas, su precisión cae por debajo del baseline de adivinar la clase mayoritaria, mientras que los modelos clásicos mantienen precisiones superiores al 90%. La diferencia es abismal en datasets con más de 20 columnas.

¿Cuántas columnas puede procesar un LLM en una tabla sin perder precisión?

El umbral identificado en el paper de 2026 es de aproximadamente 16 columnas. Por debajo de ese número, la precisión del LLM es comparable a la de modelos clásicos. A partir de d=16, el rendimiento se degrada de forma progresiva. El LLM puede leer tablas de hasta 60 columnas, pero no puede razonar con esa cantidad de atributos para clasificar.

¿Qué alternativas hay a los LLM para clasificación en datos tabulares?

Los modelos clásicos de machine learning son superiores para datos tabulares: bosques aleatorios, XGBoost, procesos Gaussianos, kNN y regresores logísticos no solo no sufren el colapso dimensional, sino que mejoran su precisión cuando agregás columnas relevantes. Son más rápidos de entrenar, no requieren GPU y sus predicciones son interpretables. Para datos estructurados, no hay competencia real con los LLM de propósito general.

¿Mejorar el prompt o el formato de los datos puede solucionar el problema?

No. El paper evaluó explícitamente si el formato de serialización (CSV linealizado, tablas en markdown, etc.), la tokenización de números o el tamaño del lote de prueba influían en el rendimiento. Ninguno de estos factores cambió el patrón de colapso. El problema es estructural y está ligado a la dimensionalidad, no a cómo presentás los datos. Cambiar el prompt no va a salvar un pipeline con 30 columnas.

Conclusión

El paper de 2026 es un baldazo de agua fría para cualquiera que haya pensado en reemplazar pipelines de machine learning tradicional con un llamado a la API de GPT-4. Los LLM no están ni cerca de ser competentes en predicción tabular cuando hay más de un puñado de columnas, y el problema no se arregla con mejores prompts ni formatos más astutos: es un límite fundamental de cómo estos modelos procesan la información dimensional.

Lo que me parece más valioso del estudio es que no se queda en el “no funciona”, sino que identifica qué no funciona, descarta explicaciones fáciles y deja planteadas preguntas honestas sobre lo que todavía no se entiende. Para los equipos de datos en producción, el mensaje es práctico y directo: usen los LLM para lo que son buenos —lenguaje, generación, resumen— y dejen la clasificación tabular en manos de los bosques aleatorios y el XGBoost, que para eso nacieron y nunca dejaron de funcionar.

Si estás armando infraestructura para ciencia de datos en producción y necesitás hostear modelos clásicos sin renegar con servidores, en Donweb tienen VPS y cloud con soporte local que zafa bastante para equipos chicos y medianos. No necesitás una GPU de USD 10K para correr un Random Forest, y con un par de cores bien configurados podés tener tu pipeline predictivo funcionando en producción sin depender de APIs de terceros que colapsan a las 16 columnas.

Fuentes

• Why Large Language Models Fail at Tabular Prediction — arXiv (2026): paper oficial con los experimentos de colapso dimensional, falsificación de hipótesis y comparación con 252 modelos clásicos.
• PNAS Nexus — doi.org/10.1093/pnasnexus/pgag197 (2026): publicación revisada por pares con los hallazgos sobre comportamiento del LLM en dos dimensiones y análisis de fronteras de decisión.
• CWI Institutional Repository — ir.cwi.nl/pub/36075 (2026): PDF completo del estudio con benchmarks, tablas comparativas y los nueve métodos evaluados contra el LLM.