Google's TabFM learns to predict from data it has never trained on

Key points

• Google Research published TabFM in 2025, a foundation model that makes predictions on brand-new datasets without any per-dataset training.
• TabFM matched or beat heavily tuned traditional models on 51 public benchmark datasets across 38 classification and 13 regression tasks.
• The model was trained entirely on hundreds of millions of synthetic, computer-generated datasets, so it never ingested real customer or business data.
• Inference, meaning the step where the model actually makes a prediction, is heavier and slower than traditional approaches, which teams must plan for.
• Google researcher Weihao Kong told VentureBeat the model's main value is speed: high-quality predictions without a dedicated data science team.

Most of the world's business data lives in spreadsheets, databases, and financial ledgers. Getting an AI model to make useful predictions from that kind of data, whether forecasting customer cancellations or spotting fraudulent transactions, has always required a lot of manual work first.

Today, a team at Google Research published a new approach called TabFM. The name stands for Tabular Foundation Model, meaning a general-purpose AI system built to handle the kind of row-and-column data you would find in any spreadsheet.

The key claim: TabFM can predict outcomes on a dataset it has never seen before, without any custom training. You hand it your historical records and the new rows you want to understand, and it returns a prediction in one step.

Why is this harder than it sounds?

Traditional machine learning, the kind companies have relied on for years, requires a specialist to build a bespoke pipeline for every new dataset. That means cleaning messy data, encoding categories as numbers, running dozens of test configurations to find the best settings, and then monitoring the model after launch because real-world data keeps shifting. It is slow, expensive, and needs ongoing attention.

You might wonder: why not just ask an existing large language model, the technology behind chatbots like ChatGPT and Claude, to read the spreadsheet directly? The answer is that language models were built for text, not grids. A medium-sized table with a few thousand rows quickly fills up their memory. Numbers get mangled because the model chops them into odd fragments. And once a two-dimensional grid gets flattened into a single line of text, the model starts losing track of which number belongs to which column.

"That's why, today, it is far more effective to use an LLM to write the code that handles feature engineering than to ask the LLM to read the table itself," Kong said.

TabFM sidesteps this by keeping the table's grid structure intact throughout the whole process. It alternates attention, a technique where the model checks how each value relates to others, across both rows and columns at once. It then compresses each row into a compact summary before making its final prediction. The design draws on two earlier research models: TabPFN, developed by Prior Labs, which proved the concept but struggled with large tables, and TabICL, from France's national digital research institute, which added efficient compression to handle bigger datasets.

The model never trained on real business data at all. Google built it entirely on hundreds of millions of computer-generated, synthetic datasets, which means no private customer records were used.

On TabArena, a standard evaluation suite covering 51 diverse real-world datasets, TabFM's zero-shot predictions, meaning predictions made with no prior training on that data, matched or outperformed heavily tuned traditional models. Google is careful to note this does not mean TabFM wins every head-to-head against a specialist model built and optimised for one specific task.

There is a genuine trade-off. Traditional models are slow to build but fast and cheap to run. TabFM flips that. There is no training phase, but every prediction requires the model to re-read all your historical records as context. That is computationally heavy. For applications that need a response in single-digit milliseconds, like a real-time fraud check at a payment terminal, the latency may be a problem today.

For a small team that needs a working baseline model by next week rather than next quarter, the calculus looks very different.