Klassisches ML lebt: Warum Gradient-Boosted Trees bei tabellarischen Daten immer noch besser abschneiden als Deep Learning

Klassisches ML lebt: Warum Gradient-Boosted Trees bei tabellarischen Daten immer noch besser abschneiden als Deep Learning

Die meisten Daten, die darüber entscheiden, ob ein Unternehmen funktioniert, sind tabellarisch: Rechnungen, Schadensmeldungen, Transaktionen, Sensormesswerte, Bauelemente, Support-Tickets, Patientenakten. Und bei diesen Daten — den schlichten zweidimensionalen Tabellen, über die niemand Konferenzbeiträge schreibt — gewinnen Gradient-Boosted Decision Trees nach wie vor die Mehrheit realistischer Aufgaben. Das ist keine Nostalgie und kein Mangel an Vorstellungskraft. Es ist eine strukturelle Eigenschaft, wie Bäume und neuronale Netze den Merkmalsraum aufteilen — und das wurde von unabhängigen Gruppen in unabhängigen Benchmarks wiederholt gemessen.

Eine seriöse Ingenieurin wählt keine Modellfamilie, weil sie gerade en vogue ist. Sie wählt sie, weil sie erklären kann, warum sie gewinnt. Dieser Artikel verfolgt daher drei Ziele: Er legt die Belege ohne Beschönigung dar, erklärt den Mechanismus hinter dem Ergebnis und zieht dann die Grenze präzise — hier gewinnt der Baum noch, hier übernimmt Deep Learning tatsächlich, und hier erfahren Sie, wie Sie für Ihre eigene Tabelle innerhalb eines Nachmittags entscheiden können.

Die These — klar formuliert

Bei mittelgroßen tabellarischen Datensätzen — also von einigen hundert bis zu einigen zehntausend Zeilen mit einer Mischung aus numerischen und kategorialen Spalten — sind Boosted Trees (XGBoost, LightGBM, CatBoost) die stärkste Standardlösung. Nicht die aufregendste. Die stärkste. Und diese Position ist haltbar, weil drei unabhängige Forschungsstränge aus unterschiedlichen Richtungen zu diesem Ergebnis kamen.

• Grinsztajn, Oyallon und Varoquaux — „Why do tree-based models still outperform deep learning on typical tabular data?“ (NeurIPS 2022, Datasets and Benchmarks Track, arXiv:2207.08815). Die Autor:innen verglichen eine breite Palette von Baum-Ensembles mit verschiedenen neuronalen Architekturen über Dutzende tabellarischer Datensätze und kamen zu dem Schluss, dass baumbasierte Modelle bei typischen tabellarischen Daten nach wie vor die beste Methode sind — und, entscheidend, dass der Vorsprung kein Artefakt des Tuning-Aufwands ist. Sie gingen sogar weiter als die meisten Benchmark-Papers und formulierten Hypothesen, warum das so ist.
• Shwartz-Ziv und Armon — „Tabular Data: Deep Learning is Not All You Need“ (arXiv:2106.03253). Ihr Vergleich zeigte, dass XGBoost in den meisten Fällen besser abschnitt als tiefe tabellarische Modelle selbst ohne Hyperparameter-Tuning, und zusätzlich, dass Ensembles, die beide Ansätze kombinieren, besser abschneiden können als jeder für sich. Beide Teile dieser Erkenntnis sind relevant, und auf den zweiten komme ich am Ende zurück.
• Gorishniy, Rubachev, Khrulkov und Babenko — „Revisiting Deep Learning Models for Tabular Data“ (NeurIPS 2021, arXiv:2106.11959). Dieser Beitrag geht teilweise in eine andere Richtung — und genau deshalb lohnt er sich: Sorgfältig gestaltete, korrekt vorverarbeitete einfache Architekturen erwiesen sich als konkurrenzfähig zu spezialisierten Modellen. Wenn ein schlichtes MLP mit der richtigen Vorverarbeitung mit einer exotischen Architektur mithalten kann, war die exotische Architektur nie der eigentliche Werttreiber — sondern die Vorverarbeitung und die disziplinierte Gestaltung.

Dazu kommt die Übersichtsliteratur. Borisov et al., „Deep Neural Networks and Tabular Data: A Survey“ (arXiv:2110.01889) fasst etwa ein Jahrzehnt Arbeit in diesem Bereich zusammen und kommt zu dem differenzierten Schluss, den die meisten Diskussionen überspringen: Gradient-Boosted Trees dominieren bei mittelgroßen Daten, während tiefe Netze echte Vorteile bei großen Datensätzen und in multimodalen Szenarien zeigen. Diese Nuance ist der Kern dieses Artikels. Die Schlagzeile lautet „Bäume gewinnen“, der nützliche Teil ist die Grenze.

„Why do tree-based models still outperform deep learning on typical tabular data?“ — der Titel von Grinsztajn, Oyallon und Varoquaux, NeurIPS 2022. Jahre später lautet die beste Antwort, die das Feld zu bieten hat, immer noch: induktiver Bias, nicht Hyperparameter-Suche.

Warum: der Glattheits-Bias

Ein Entscheidungsbaum teilt jeweils nach einem Merkmal auf. Jeder Split ist ein Schwellenwert für eine einzelne Spalte, sodass der Entscheidungsbereich des Modells aus achsenparallelen Boxen im Merkmalsraum besteht. Diese Geometrie entspricht der Art und Weise, wie tabellarische Daten tatsächlich entstehen. Eine Regel wie „Lehne den Antrag ab, wenn der Betrag diese Bandbreite überschreitet und die Police vor weniger als neunzig Tagen eröffnet wurde“ besteht aus zwei Schwellenwerten für zwei Spalten. Bäume bilden das mit zwei Splits ab. Das ist kein Zufall — Geschäftsregeln und physikalische Beschränkungen werden als Schwellenwerte für einzelne Variablen formuliert, weil Menschen so darüber nachdenken.

Ein Multilayer-Perzeptron geht grundlegend anders vor. Es lernt lineare Kombinationen aller Merkmale gleichzeitig und wendet dann Nichtlinearitäten auf diese Kombinationen an. Dadurch ist das Netzwerk bemerkenswert gut darin, glatte, geteilte, verteilte Strukturen zu erkennen — und es ist rotationsinvariant: Eine lineare Kombination aus einem informativen und einem nicht-informativen Merkmal ist immer noch ein brauchbarer Input für die erste Schicht. Der Preis dafür ist, dass eine achsenparallele Grenze, die ein Baum mit drei Splits ausdrückt, von einem Netzwerk möglicherweise viele Schichten und deutlich mehr Parameter erfordert, um sie zu approximieren, weil das Netzwerk die Ausrichtung erst konstruieren muss.

Grinsztajn und Ko-Autor:innen fassen dies als Fehlpassung des induktiven Bias auf, und die Folge ist messbar: Neuronale Netze sind auf glatte Lösungen voreingenommen, während tabellarische Ziele häufig nicht glatt sind. Das Lehrbuchbeispiel ist das XOR-artige Ziel, bei dem das Label von einem Schwellenwert einer Variable in Kombination mit einem Schwellenwert einer anderen abhängt. Ein Baum trifft es mit einer Handvoll Splits. Ein MLP benötigt deutlich mehr Kapazität, um dieselbe Funktion abzubilden, da die wahre Grenze nichts mit einer linearen Kombination der Eingaben zu tun hat.

Das ist kein Versagen von Deep Learning. Es ist Deep Learning, das genau das tut, wofür seine Architektur entworfen wurde — Glattheit und gemeinsame Strukturen auszunutzen — in einem Kontext, in dem diese Designannahme teilweise nicht zutrifft. Die Interpretation als „Neuronale Netze sind schlecht für Tabellen“ verfehlt den Punkt und führt zur falschen Entscheidung. Die korrekte Lesart lautet: die Annahme ist das, was Sie kaufen, und hier zahlt sie sich nicht aus.

Warum: uninformative Features und heterogene Spalten

Zwei weitere Mechanismen aus derselben Forschungsarbeit sind im täglichen Einsatz relevanter als das Glattheitsargument, weil sie unmittelbar spürbar sind.

• Uninformative Features. Bäume selektieren implizit: Eine Spalte ohne Signal wird einfach nie für einen Split ausgewählt, und das Hinzufügen von fünfzig nutzlosen Spalten lässt die gewählte Struktur weitgehend unverändert. Neuronale Netze haben dieses Glück nicht. Jedes Eingabe-Feature fließt in die erste Schicht ein, sodass das Netzwerk aus dem Gradienten-Signal lernen muss, die irrelevanten zu unterdrücken — eine Aufgabe, die Kapazität und Trainingszeit kostet. Der Grinsztajn-Benchmark zeigt konkret, dass das Hinzufügen uninformativer Features die Performance neuronaler Netze stärker beeinträchtigt als die von Bäumen, was genau zu erwarten ist, wenn eine Familie über eingebaute Feature-Selektion verfügt und die andere nicht.
• Heterogene, gemischte Spaltentypen. Eine reale Tabelle besteht aus einer numerischen Spalte, einer kategorialen Spalte, einem Datum und einem Freitextfeld in derselben Zeile. Bäume akzeptieren diese Mischung nahezu nativ. Ein Entscheidungsbaum ist invariant gegenüber monotonen Transformationen eines einzelnen Features, sodass die Skalierung einer numerischen Spalte die Menge möglicher Splits nicht verändert. Neuronale Netze erfordern dagegen, dass der Entwickler jeden Typ explizit handhabt: Numerische Werte normalisieren, kategoriale Werte one-hot-encodieren oder embedden, Datumsangaben in zyklische oder ordinale Features umwandeln, entscheiden, wie mit fehlenden Werten umgegangen wird. Jeder dieser Schritte ist eine potenzielle Fehlerquelle und ein zusätzlicher Parameter, der abgestimmt werden muss. Die Folge ist nicht, dass Netze gemischte Tabellen nicht verarbeiten können — sie können es —, aber der Baum kommt mit deutlich weniger Designentscheidungen aus, und Designentscheidungen sind der Punkt, an dem Projekte tatsächlich Zeit verlieren.

Die operativen Gründe, die nie in die Zusammenfassung kommen

Das Modellierungsargument ist nur die halbe Wahrheit. Die andere Hälfte ist, dass ein Modell, das marginal genauer, aber schwerer auszuführen ist, häufig das falsche Modell für den Einsatz ist.

1. Trainingszeit und Hardware. Boosted Trees trainieren auf der CPU mit optimierter Histogramm-Splittung und sind schnell. Ein neuronales Netz benötigt in der Regel eine GPU, um in realistischem Maßstab praktikabel zu sein; ein Baum-Ensemble läuft problemlos auf derselben Maschine, auf der auch Ihr ETL-Prozess läuft. Für ein Modell, das täglich oder bei jedem Daten-Refresh neu trainiert wird, überwiegt dieser Unterschied einen Bruchteil eines Punktes im AUC.
2. Tuning-Aufwand. Gradient Boosting mit vernünftigen Defaults funktioniert ab Werk bemerkenswert gut. Shwartz-Ziv und Armon stellten explizit fest, dass XGBoost die Deep-Learning-Modelle selbst ohne Hyperparameter-Tuning schlug. Ein neuronales Modell hingegen kommt mit einer Lernrate, einem Schedule, einer Batch-Größe, einer Breite, einer Tiefe, einer Dropout-Rate und einem Optimierer — und seine Performance ist gegenüber allen diesen Parametern empfindlich.
3. Fehlende Werte und Ausreißer. Moderne GBDT-Implementierungen verarbeiten fehlende Werte nativ und sind robust gegenüber Ausreißern, da ihre Splits auf rangbasierten Schwellenwerten beruhen. Ein MLP benötigt Imputation, und Imputation ist eine Modellierungsentscheidung, die Sie anschließend gegenüber der datenverantwortlichen Stelle rechtfertigen müssen.
4. Interpretierbarkeit und Governance. Feature Importance, SHAP-Werte, Partial Dependence und — am wichtigsten — eine für Menschen lesbare Spur, welche Features eine bestimmte Vorhersage beeinflusst haben. Wenn Ihr Modell einem Risikoteam, einer Aufsichtsbehörde oder einem Kunden erklärt werden muss, liefert der Baum die Erklärung. Das ist kein weicher Vorteil. In regulierten Bereichen entscheidet es, welches Modell überhaupt eingesetzt werden darf.
5. Deployment-Oberfläche. Ein Boosting-Ensemble kompiliert zu einem kleinen Artefakt und liefert Vorhersagen in wenigen Millisekunden auf einem einzigen Kern, sodass es direkt in der Anwendung oder in der Analytics-Engine laufen kann, statt hinter einem dedizierten Inferenz-Service. Weniger bewegliche Teile, weniger Fehlerquellen, ein Problem weniger, das jemanden um 3 Uhr morgens aufweckt.

Die Ausnahmen: Wo Deep Learning tatsächlich gewinnt

Wenn Bäume immer gewinnen würden, wäre dies keine technische Entscheidung — es wäre eine Regel. Tun sie aber nicht. Die veröffentlichte Literatur und meine eigene Erfahrung stimmen weitgehend darin überein, wo die Grenze verläuft, und sie verläuft an fünf Stellen.

• Große Datenmengen. Die Fachliteratur ist sich einig, dass mit zunehmender Datensatzgröße — ab Hunderttausenden oder Millionen Zeilen — der Deep-Learning-Vorteil auftritt und sich dann vergrößert. Bäume haben eine endliche Kapazität, neue Daten zu nutzen, sobald die effektive Anzahl unterschiedlicher Entscheidungswege gesättigt ist; ein Netzwerk mit ausreichend Parametern verbessert sich weiter mit mehr Beispielen, sofern Sie die Rechenleistung bezahlen können. Wenn Ihre Tabelle groß ist und weiter wächst, ändert sich die Kalkulation tatsächlich.
• Multimodale Eingaben. Wenn die Zeile nicht nur Zahlen und Kategorien, sondern auch ein Bild, einen Audio-Clip, einen Textblock oder eine Graph-Nachbarschaft enthält, ist ein neuronales Netz die einzige ernsthafte Lösung — denn es kann eine gemeinsame Repräsentation über Modalitäten hinweg lernen. Borisov et al. weisen explizit darauf hin: Ein Baum kann keinen Absatz einbetten; ein Transformer schon, und dann schließen sich die tabellarischen Spalten derselben Repräsentation an und profitieren davon.
• Kategoriale Variablen mit hoher Kardinalität. Embeddings für eine Kategorie mit zehntausenden Ausprägungen — Benutzer-IDs, SKUs, Postleitzahlen, Geräte-Tags — sind eine Stärke neuronaler Netze, die Bäume nur umständlich abbilden können. Wenn Ihre Tabelle hauptsächlich ein dünn besetzter Identitätsraum ist, ist eine Embedding-Schicht das richtige Werkzeug und ein One-Hot-Baum-Split das falsche.
• Sequenzen und wiederholte Strukturen. Eine Tabelle, in der jede Entität viele zeittragende Zeilen hat, ist keine echte Tabelle; sie ist ein Sequenzproblem in Tabellenform. Sequenz- und Attention-Architekturen nutzen diese Struktur direkt. Grinsztajn und Co-Autor:innen weisen speziell auf den Fall hin, in dem Zeilen alles andere als unabhängig sind — und genau dort rechtfertigt sich ein neuronaler Ansatz.
• Multi-Task-Learning und gemeinsame Repräsentationen. Ein Modell so zu trainieren, dass es viele verwandte Ziele vorhersagt oder als gemeinsamer Encoder für mehrere nachgelagerte Köpfe dient, ist ein neuronales Muster. Bäume bearbeiten jeweils nur ein Ziel, und fünfzehn davon zu stapeln, um fünfzehn Köpfe zu bedienen, ist nicht dasselbe wie das Lernen einer gemeinsamen Repräsentation.

Die neue Wendung: tabellarische Foundation-Modelle

Die interessanteste jüngste Entwicklung ist, dass die Deep-Learning-Seite weitgehend aufhörte, den Baum mit einer besseren Architektur schlagen zu wollen, und das Problem aus einer anderen Richtung anging: Pre-Training. TabPFN (Hollmann et al., arXiv:2207.01848) ist ein Transformer, der auf synthetischen tabellarischen Aufgaben vortrainiert wurde und dann eine neue kleine Tabelle in einem einzigen Forward-Pass klassifiziert — ganz ohne aufgabenspezifisches Training. Die Autor:innen positionierten es für kleine Tabellen in der Größenordnung von tausend Zeilen, und die v2-Linie erweiterte den Ansatz auf größere und realistischere Tabellen; diese Nachfolgearbeit wurde 2025 in Nature veröffentlicht.

Das ist die richtige Art von Disruption, denn sie greift die eigentliche Schwäche neuronaler Methoden bei tabellarischen Daten an. Sie waren immer datenhungrig und arbeitsintensiv im Tuning. Ein vortrainiertes Prior entfernt sowohl den Hunger als auch den Großteil des Tunings: Man übergibt ihm die Tabelle, und er liefert die Antwort. Wenn sich tabellarische Foundation-Modelle weiter verbessern, sind sie das, was den „Bäume gewinnen“-Standard verdrängen wird — noch nicht, aber das ist die Richtung. Die ehrliche Einschätzung 2026 lautet, dass Gradient Boosting immer noch der etablierte Standard ist und die Foundation-Model-Linie der glaubwürdige Herausforderer. Wer behauptet, der Standard habe sich bereits gewandelt, liest Ankündigungen statt Benchmarks.

Ein Entscheidungsrahmen, den Sie an einem Nachmittag umsetzen können

Hier ist die Abfolge, die ich tatsächlich verwende. Sie dauert einen halben Tag, nicht nur eine Viertelstunde, und ist bewusst darauf ausgelegt, etwas auszuliefern.

1. Bauen Sie zuerst die Baseline — und zwar eine echte. LightGBM oder CatBoost mit sinnvollen Standardwerten, eine saubere Trainings-/Validierungsaufteilung, die die Zeitachse respektiert, wenn die Daten temporal sind, und eine Metrik, die zur Geschäftsentscheidung passt — nicht eine, die einfach zu berechnen ist. Überspringen Sie diesen Schritt nicht. Die Baseline ist die Zahl, die jeder spätere Ansatz übertreffen muss, und meiner Erfahrung nach ist sie viel schwerer zu schlagen, als die meisten erwarten.
2. Korrigieren Sie die Daten, bevor Sie das Modell korrigieren. Zeilenanzahl, Feature-Anzahl, fehlende Werte pro Spalte, Kardinalität pro kategorialer Variable und die zeitliche Struktur der Aufteilung. Ein großer Teil der „Deep Learning ist besser“-Ergebnisse entpuppt sich in der Praxis als „die Daten wurden sorgfältig bereinigt, während das neuronale Modell entstand“. Machen Sie die Bereinigung zu einem Teil beider Experimente, sonst ist der Vergleich bedeutungslos.
3. Stellen Sie die vier Grenzfragen. Ist die Tabelle groß und wächst auf Hunderttausende Zeilen an? Gibt es nicht-tabellarische Eingaben in derselben Pipeline? Sind die kategorialen Variablen so hochkardinal, dass Embeddings sinnvoll wären? Ist die Zeile eigentlich eine Sequenz für eine Entität? Jedes „Ja“ rückt neuronale Methoden in den Vordergrund.
4. Wenn alle vier Antworten „Nein“ lauten, hören Sie auf. Liefern Sie den Baum aus, nutzen Sie die verbleibende Zeit für Feature Engineering und die Datenpipeline, und verschieben Sie die Architekturdebatte auf ein Projekt, das sie braucht. Bei tabellarischen Daten bringt Feature Engineering immer noch mehr Performance als die Architektur — der unglamouröseste und ertragreichste Teil der Arbeit.
5. Wenn eine oder mehrere Antworten „Ja“ lauten, bauen Sie das neuronale Modell und vergleichen es mit der Baseline — nicht mit dem vorherigen neuronalen Modell. Bevor Sie es ausliefern, führen Sie die operative Checkliste durch: Trainingszeit pro Aktualisierung, Größe des Artefakts, Latenz-Budget und ob Sie eine einzelne Vorhersage der Person erklären können, die sie vertreten muss.
6. Erwägen Sie das Ensemble. Shwartz-Ziv und Armon fanden heraus, dass die Kombination beider Familien die Leistung gegenüber jeder einzelnen verbessern kann. Wenn der Baum einen halben Punkt zurückliegt und das Netz einen halben Punkt vorn liegt, kann ein gestapeltes oder gemitteltes Modell der eigentliche Gewinner sein — auf Kosten des Betriebs und der Überwachung zweier Systeme. Dieser Trade-off ist manchmal richtig und immer einen expliziten Hinweis wert.

Wie das in einem echten Stack aussieht

Auf dem kmail.at-Stack beginnt tabellarische Arbeit selten in einem Notebook. Sie beginnt in der Query-Engine. Die Analytics-Ebene läuft bereits mit DuckDB über Parquet-Spalten, was bedeutet, dass Trainings-Features und Inferenz-Features aus demselben SQL stammen können. Diese Single-Source-Disziplin beseitigt die häufigste Ursache dafür, dass ein gutes Baummodell in der Produktion unterdurchschnittlich performt: Train/Serve-Skew. Das Modell war in Ordnung; die Features, die es zur Inferenzzeit sah, wurden von einem anderen Codepfad erstellt.

Daten der gebauten Welt folgen derselben Logik. Ein BIM-Modell ist keine Zeichnung; es ist ein strukturierter Datensatz von Elementen mit Eigenschaften. Sobald dieser Datensatz in einer Tabelle landet — Elementtyp, Ebene, Material, Fläche, Kosten, Wartungsintervall —, werden die Vorhersageaufgaben klassisch: Kostenregression, Defektklassifikation, Anomalieerkennung bei Betriebsdaten. Das sind Gradient-Boosting-Probleme mit Erklärbarkeitsanforderungen, denn eine Facility-Managerin, die fragt „Warum wurde das markiert?“, braucht eine Antwort, kein Embedding-Vektor. Dasselbe gilt für agentische Systeme: Wenn ein Agent eine günstige, erklärbare, deterministische Entscheidung über strukturierte Fakten treffen muss — ist dieser Anspruch anomal, ist dieser Datensatz inkonsistent, widerspricht diese Spezifikation jenem Zeitplan —, ist ein Baum oft das richtige Werkzeug hinter dem Werkzeug, während das Sprachmodell für das Reasoning und die Schnittstelle zuständig ist.

Das entscheidende Muster ist nicht „Baummodelle verwenden“. Es ist, dass das Modell am Ende einer Pipeline sitzt und die Pipeline drumherum — Feature-Definitionen, Retraining-Rhythmus, Monitoring, Erklärungsoberfläche — entscheidet, ob das Modell nützlich ist. Ein marginal schlechteres Modell in einer gut instrumentierten Pipeline schlägt jedes Mal ein besseres Modell in einer fragilen Pipeline.

Wie man Benchmarks ehrlich durchführt

Die Literatur zu tabellarischen Daten vs. Deep Learning lässt sich leicht selektiv in beide Richtungen lesen. Wenn Sie den Vergleich selbst durchführen, halten Sie sich an ein paar Regeln.

• Gleiche Folds, gleiches Preprocessing-Budget. Wenn das neuronale Modell einen Tuning-Durchlauf erhält und der Baum mit Bibliotheksstandards arbeitet, messen Sie Ihren Aufwand, nicht Ihre Architekturen. Geben Sie beiden ein Budget und berichten Sie beide.
• Berichten Sie die Metrik, die entscheidet, nicht die, die einfach ist. Genauigkeit bei einer unausgewogenen Tabelle ist Theater. Verwenden Sie die Metrik, die sich in Geld, Risiko oder eingesparter Zeit niederschlägt, und berichten Sie die zugrundeliegende Konfusionsstruktur.
• Berichten Sie die Varianz über verschiedene Seeds. Baum-Ensembles sind relativ stabil; Deep-Learning-Modelle weniger. Eine Differenz von einem Bruchteil eines Prozents bei einem einzelnen Seed ist Rauschen, und auf Rauschen zu setzen, führt dazu, dass Teams ein neuronales Modell warten, das sich nie wirklich gerechnet hat.
• Messen Sie den gesamten Zyklus. Trainingszeit, Inferenz-Latenz und Retraining-Rhythmus. Ein Modell, das vier Stunden zum Retraining braucht, verändert Ihren Release-Prozess; ein Modell, das vier Minuten benötigt, tut das nicht.
• Zählen Sie die Design-Entscheidungen. Das ist die am wenigsten quantifizierte und meist entscheidende Variable dafür, welches Modell tatsächlich in den Betrieb geht. Jeder Parameter ist ein zukünftiger Bug und ein zukünftiger Wartungsaufwand.

Das Fazit

Gradient-Boosting-Bäume sind 2026 der richtige Standard für tabellarische Daten, und der Grund dafür ist induktiver Bias, nicht Trägheit: achsenparallele Splits, implizite Feature-Auswahl, native Handhabung gemischter Typen und fehlender Werte, ein CPU-freundlicher Trainingszyklus und eine Erklärungsoberfläche, die man einer Prüferin vorlegen kann. Deep Learning übernimmt genau dort, wo seine Annahmen zutreffen: große Tabellen, multimodale Zeilen, hochkardinale Embeddings, Sequenzen und geteilte Multi-Task-Repräsentationen. Tabellarische Foundation-Modelle sind der glaubwürdige Herausforderer dieses Standards — aber noch nicht der Standard.

Die eigentliche Entscheidung lautet also nicht „klassisch oder modern“. Es geht darum, ob Ihre Daten wie eine Tabelle oder wie eine Sequenz oder ein Wahrnehmungsproblem strukturiert sind. Tabellen erhalten Gradient-Boosting-Bäume. Alles andere erhält ein neuronales Netz, ein Foundation-Modell oder beides. Treffen Sie diese Entscheidung richtig, und der Großteil der Architekturdebatte erübrigt sich — was der Punkt ist. Die Architektur war nie das Schwierige; die Form der Daten war es.

Wählen Sie das Modell, das zur Form Ihrer Daten passt — nicht zum aktuellen Hype-Zyklus. Bei Tabellen ist diese Antwort seit Jahren stabil — und das Spannende ist zu wissen, wann sie nicht mehr gilt.

Quellen

• Grinsztajn, Oyallon, Varoquaux (2022): "Why do tree-based models still outperform deep learning on typical tabular data?" — NeurIPS 2022 Datasets and Benchmarks Track — https://arxiv.org/abs/2207.08815
• Shwartz-Ziv, Armon: "Tabular Data: Deep Learning is Not All You Need" — https://arxiv.org/abs/2106.03253
• Gorishniy, Rubachev, Khrulkov, Babenko (2021): "Revisiting Deep Learning Models for Tabular Data" — NeurIPS 2021 — https://arxiv.org/abs/2106.11959
• Borisov, Leemann, Seßler, Haug, Pawelczyk, Kasneci: "Deep Neural Networks and Tabular Data: A Survey" — https://arxiv.org/abs/2110.01889
• Hollmann, Müller, Eggensperger, Hutter: "TabPFN: A Transformer That Solves Small Tabular Classification Problems in a Second" — https://arxiv.org/abs/2207.01848
• TabPFN v2: Hollmann et al., veröffentlicht in Nature (2025) — die Nachfolgelinie, die den prior-fitted-Ansatz auf größere, realistischere Tabellen ausweitet.
• Kaggle State of Machine Learning and Data Science Survey: die branchenseitige Bestätigung, dass Gradient-Boosting-Implementierungen die Arbeit mit tabellarischen Daten dominieren — https://www.kaggle.com/kaggle-survey-2021

Wo dieser Artikel eine Zahl nennt, handelt es sich um einen Geltungsbereich oder eine Aussage aus dem zitierten Paper (etwa TabPFNs Small-Table-Regime). Wo er Praxis beschreibt — Aufwand für Tuning, Kosten für Deployment, die Struktur einer realen Pipeline —, ist dies als Praxis gekennzeichnet und stammt aus praktischer Arbeit, nicht aus einer Messung.