Tabular Foundation Models Still Need One Thing: Multi-Table Aggregation

https://wesmadrigal.github.io/GraphReduce/tutorial_auto_feature_engineering/

by madman2890 • 5 months ago

2 1 5 months ago

wesmadrigal.github.io

madman2890• 5 months ago

Tabular foundation models like TabPFN and related work are extremely promising. They’re starting to show strong results on many classical tabular ML benchmarks and can reduce the amount of manual modeling work required from data scientists. However, there is a structural reality of enterprise data that these models don’t remove. Most real-world machine learning problems are not stored in a single clean table. Instead they live across dozens or hundreds of relational tables: orders, customers, events, transactions, shipments, products, logs, etc. Each table captures part of the signal, often with one-to-many relationships, time dependencies, and high cardinality entities. Before any tabular model can be trained, those signals have to be integrated. In practice this means: Traversing relational graphs of tables Aggregating child tables to parent entities Handling time windows and temporal leakage Collapsing many-to-many relationships into meaningful features Producing a single wide training dataset This step is usually the most time-consuming part of the entire ML workflow. Even if the model itself becomes automated via a tabular foundation model, the data still has to be prepared. This is where GraphReduce comes in. GraphReduce treats the relational database as a graph of entities and relationships. Instead of manually writing large SQL pipelines, the user defines the nodes (tables) and their relationships. GraphReduce then walks the graph and performs the required aggregations automatically, generating a single training dataset.

Tabular Foundation Models Still Need One Thing: Multi-Table Aggregation

Related Stories