Most business prediction problems do not arrive as prose.
They arrive as rows: account attributes, transactions, sensor readings, test results, and a target column.
For this kind of data, gradient-boosted trees and other conventional methods remain hard to displace.
A new paper, Why Large Language Models Fail at Tabular Prediction, asks a much more useful question than “can an LLM classify a table?”: what, specifically, breaks as the task becomes more like ordinary tabular machine learning?
The answer from the authors’ controlled experiments is input dimensionality.
Their result matters because it separates a real limitation from several explanations that sound plausible but did not hold up in their tests.
The experiment was about prediction, not table chat The paper evaluates frontier LLMs in a pure inference setup: a model receives labeled examples and must predict labels for new rows in a single generation pass.
There is no fine-tuning, retrieval pipeline, tool calling, or agent loop to compensate for the base model.
This is deliberately narrow.
It asks whether a general-purpose language model can act as a direct tabular learner.
Across 31 benchmark datasets, the authors compare nine methods and 252 configured classical models.
That scope is important: a weak result on one CSV is easy to explain away as prompt design or a quirky dataset.
A consistent trend across many tasks is harder to dismiss.
The headline is not simply that LLMs lose to established tabular baselines.
It is that their accuracy declines as the number of input dimensions grows, while the classical baselines in the study stay stable or improve.
The paper therefore treats dimensionality as the central failure mode rather than an incidental property of difficult datasets.
Four popular explanations did not survive testing There are several standard reasons developers give for poor LLM performance on tables.
The researchers turn these into falsifiable hypotheses. “The classes overlap too much.” If the data are noisy or not cleanly separable, perhaps the model cannot infer a decision boundary.
The experiments indicate this is not enough to explain the gap: performance problems remain even when the signal is made easier to separate. “CSV destroys the table structure.” Turning columns and rows into a token sequence feels like an obvious mismatch.
But changing the serialization format did not fix the issue.
The model can access column information, yet it still fails on signals that should be simple. “Numbers are tokenized badly.” Numeric strings split into tokens in awkward ways, so perhaps magnitude comparisons are the culprit.
Lowering numeric precision and related interventions did not produce the expected recovery. “There are too many test rows in one prompt.” A prompt with many predictions might spread the model’s compute too thin.
Again, reducing that load was not the explanation.
None of these findings says formatting, numeric representation, or context length never matter in production.
They do.
The narrower point is that they do not account for the observed collapse in this direct-prediction setting.
That distinction should change how we debug these systems: switching from CSV to JSON is unlikely to solve a high-dimensional learning problem.
Dimensionality is a different kind of obstacle Tabular features are often heterogeneous and only weakly related: a customer’s region, account age, device type, transaction count, income band, and dozens of derived signals may each contribute a little.
As features accumulate, useful local similarity becomes difficult to identify.
This is one form of the familiar curse of dimensionality.
In two dimensions, the paper finds that LLM behavior resembles local methods such as low-k nearest neighbors or short-length-scale Gaussian processes.
In other words, the model’s predictions can look like a neighborhood-based decision rule.
The reported grid agreement reaches 91.6% for some such comparisons.
At higher dimensions, that res