Tabular Foundation Models schlagen getuntes XGBoost in eigenem Benchmark

Kann ein Modell auf einer Tabelle vorhersagen, auf der es nie trainiert wurde — und dabei ein hyperparameter-optimiertes XGBoost schlagen? Efrain Garay hat die monatelang kursierende Behauptung auf eigener Hardware nachgemessen: 14 Datasets des Grinsztajn-Benchmarks, identischer Split, dieselbe Stoppuhr für alle Kandidaten. Das Ergebnis: Das tabellarische Foundation-Modell gewinnt, und zwar auf allen 14 Tabellen.

Wie Tabular Foundation Models funktionieren

TabPFN und TabICL sind auf Millionen synthetischer Tabellen vorab trainiert. Kommt eine neue Tabelle, wird kein einziges Gewicht angepasst: Die Trainingszeilen dienen als Kontext, die Vorhersage entsteht in einem einzigen Forward-Pass. Das ist dasselbe In-Context-Learning, das wir von Sprachmodellen kennen — nur mit Spalten statt Wörtern. Der Code heißt zwar fit, aber im Inneren gibt es keinen Gradientenabstieg, sondern nur einen Datenimport auf die GPU. Das kehrt die Kostenstruktur um: Fitten ist nahezu gratis, die Praediktion zahlt — exakt umgekehrt wie beim Baumensemble.

Die Messergebnisse im Detail

• Kreditrisiko (credit, heloc, default-of-credit): Foundation-Modell gewinnt alle drei; auf heloc liegt TabICL mit 0,7667 AUC vorn.
• Klinik (Diabetes130US): Fast Gleichstand bei Accuracy — aber die AUC öffnet sich deutlich (0,6484 gegen 0,6264). Für Triage entscheidet die Risikoreihenfolge, nicht die Trefferquote.
• Kampagnen (bank-marketing): Der einzige Fall, wo TabPFN vor TabICL liegt — beide schlagen getuntes Boosting.
• Bioresponse (419 Spalten): Hier bricht TabPFN ein (0,7567 — schlechter als ungetuntes XGBoost). TabICL hält und gewinnt. Die Breite der Tabelle, nicht ihre Länge, ist der Schwachpunkt.
• Skalierung: Der Vorsprung hält bis 32.000 Zeilen — die Vermutung, er breche dort, bestätigt sich nicht.

Ehrliche Einschränkungen

Der Autor legt die Schwächen offen: XGBoost wurde auf Accuracy getunt, nicht auf AUC — ein AUC-Getuning könnte es dort verbessern. Kategoriale Features wurden für alle gleich per Integer-Encoding behandelt, was Boosting eher benachteiligt. Mehrere Accuracy-Siege sind kleiner als die Variation zwischen Seeds. Und TabPFN wurde in Version 2.2.1 gemessen, zwei Serien hinter der aktuellen 8.3.0, da diese nur noch mit Konto herunterladbar ist — bei TabICL lässt sich die BSD-lizenzierte Version weiterhin frei beziehen.

Faustregel für die Praxis

Einsetzen lohnt sich bei Tabellen von 1.000 bis 30.000 Zeilen und weniger als 100 Spalten, wenn die Zeit des Teams mehr wert ist als das letzte Hundertstel Performance. Nicht einsetzen: bei sehr breiten Tabellen, ohne GPU in Produktion, oder wenn ein auditiertes, kilobyte-kleines Artefakt in einem schmalen Container laufen soll — dort bleibt der trainierte Baum ungeschlagen.

Quelle: Efrain Garay