TabICL v2 für Zeitreihen: Das In-Context-Learning-Modell im Vergleich mit XGBoost und Meta's Prophet

Foundation-Modelle wie TabICL v2 halten zunehmend Einzug in die Zeitreihenprognose. Doch wie schlägt sich ein solches Modell gegenüber etablierten Methoden wie XGBoost oder Meta’s Prophet? In diesem Beitrag fassen wir unsere Erkenntnisse und Benchmark-Ergebnisse zusammen.

Datenbasis & Feature-Engineering

Für unseren Test nutzen wir Realdaten zu Stickstoffdioxid (NO2). Die Daten wurden im stündlichen Intervall und an Messstationen, die sich in der Nähe von Verkehrsstraßen befinden, erhoben. Die Daten zeichnen sich durch ein starkes Tages- und Wochenendmuster (Verkehrsspitzen) sowie saisonale Unterschiede (höhere Werte im Winter) aus. Einen ausgeprägten langfristigen Trend gibt es nicht.

Da TabICL und XGBoost von Haus aus keine sequentiellen Zeitreihenstrukturen verarbeiten, haben wir beide Modelle mit einem ähnlichem Feature-Engineering ausgestattet:

• Kalender-Features: Stunde des Tages, Tag der Woche etc.
• Lag-Features (vergangene Beobachtungen der Zielvariable): 24h-, 48h- und 1-Wochen-Lags.
• Exogene Features: Windgeschwindigkeit, Windrichtung, Temperatur, Niederschlag und Kfz-Aufkommen.

Nur für TabICL verwendet:

• Saisonalität-Enkodierung: Sinus- und Kosinus-Transformationen zur Abbildung kontinuierlicher Perioden sowie automatische Detektion via Fourier-Analyse.

In der TabICL-Implementierung für Zeitreihen werden die Kalender-Features und die Saisonalitäts-Enkodierung automatisch erstellt.

Zu beachten ist außerdem, dass in einer produktiven Anwendung die exogenen Features zuerst selbst prognostiziert werden, um sie dann als Features zu verwenden. Für unsere Analyse verwenden wir die realisierten Werte.

Verglichene Modelle & Benchmark-Setup

Als Evaluationsmetrik nutzen wir den Mean Absolute Scaled Error (MASE). Ein Wert größer als 1,0 bedeutet, dass das Modell schlechter abschneidet als eine naive In-Sample-Baseline. Die Metrik wird z.B. auch im bekannten GIFT-Eval Benchmark für Zeitreihen genutzt. Außerdem zeigen wir die Ergebnisse für den normalen Mean Absolute Error (MAE). Wir mitteln den MASE über 5 Messstationen und alle Test-Folds unserer Rolling-Window Kreuzvalidierung (CV). Für die CV gehen wir wie folgt vor:

• Bestimme die Länge des Trainingszeitraums n
• Der erste Fold hat den 02.05.2023 als Testzeitraum und die n Beobachtungen davor als Trainingszeitraum
• Schiebe nun den Test- und Train-Zeitraum um einen Tag in die Zukunft
• Wiederhole dies bis 365 Tage abgedeckt sind und erhalte so die Train-Test-Folds
• Die Testfolds der CV decken somit ein ganzes Jahr ab.

Verglichen wurden:

• XGBoost (mit Feature-Engineering, Hyperparameter via Optuna getuned)
• TabICL (mit Feature-Engineering)
• TabICL minimal (ohne exogene Features und Lags)
• Meta Prophet (Additives Regressionsmodell, ohne exogene Features und Lags)
• Seasonal Naive Baseline

Ergebnisse im Überblick

Tabelle 1: Statistiken zur Verteilung der NO2-Werte pro Station und insgesamt. Zeitraum 2021-05-02 bis 2024-05-02. mad = Mean absolute deviation.

Tabelle 2: MASE für verschiedene Modelle und Längen des Trainingszeitraums. Gezeigt sind die Mittelwerte der MASE auf den Test-Folds von allen Stationen.

Tabelle 3: MAE für verschiedene Modelle und Längen des Trainingszeitraums. Analog zu Tabelle 2. Gezeigt sind die Mittelwerte der MAE auf den Test-Folds von allen Stationen.

Grafik 1: Barplot zum Modell-Vergleich der MASE-Werte für verschiedene Längen der Trainingshistorie.

Diskussion der Ergebnisse

• Kleine Historien (<= 6 Monate): Bei kleinen Datenkontexten hat TabICL einen Vorteil. Mit 3 Monaten Historie ist XGBoost etwa 4% schlechter, bei 1,5 Monaten knapp 5% schlechter.
• Mittlere Historie (1 Jahr): Mit einjährigem Kontext liegen XGBoost und TabICL nahzu gleich auf: XGBoost erzielt einen MASE von 0,522 und TabICL liegt bei 0,519.
• Volle Historie (2 Jahre): TabICL schlägt mit einem MASE von 0,478 XGBoost um ca. 4,6 %.
• TabICL out-of-the-box: Ohne manuelles Feature-Engineering schlägt TabICL sowohl Meta Prophet als auch die naive Baseline deutlich.
• Zweite Metrik MAE: Der Mean Absolute Error (MAE) bestätigt die Ergebnisse des MASE.
• Größe des TabICL-Vorteils: Beim 2-Jahres-Kontext ist die Differenz zu XGBoost im MAE rund 0,18. Dies lässt sich mit der Mean Absolute Deviation (MAD) über alle Stationen aus Tabelle 1 vergleichen. Ins Verhältnis gesetzt ergibt sich 0,18 / 8.01 = 0.02. Die Verbesserung beträgt also 2% davon, wie viel die Daten insgesamt schwanken.

Bei einem Jahr und weniger Daten ist das Muster klar: Je weniger Historie, desto größer ist der Vorteil von TabICL. Bei 2 Jahren Historie wird das Muster nicht fortgeführt und der Vorteil von TabICL steigt wieder, obwohl es mehr Daten gibt. Eine wahrscheinliche Erklärung: TabICL kann die Informationen des Extra-Jahres besser als XGBoost nutzen, um die jährliche Saison zu erfassen.

Stabilität der Prognosen: Die Standardabweichung (SD) des MAE über die 5 x 365 = 1825 CV-Folds liegt bei ca 2,5 sowohl für XGBoost als auch für TabICL. Bei einem MAE von ca. 4 sind also auch Abweichungen von 6,5 Einheiten zu erwarten, was leicht unter dem Bereich einer Standardabweichung der Daten liegt (siehe Tabelle 1).

In 57,5 % der Folds erzielt TabICL den kleineren Fehler. Somit ist TabICL im Mittel besser, aber dennoch kann es öfters zu Einzelfällen kommen, in denen XGBoost auf einem Fold gewinnt.

Erfahrungen zur Nutzbarkeit & Performance

Die Integration von TabICL über die Klasse TabICLForecaster und deren Methode predict_df funktioniert gut, aber erfordert etwas Einarbeitung. Im TabICL Repo wird mit zudem mit dem Parameter prediction_length gearbeitet. Übersichtlicher in der Nutzung finden wir es aber, wenn man stattdessen neben dem context_df den Parameter future_df nutzt. Darüber kann man ein pandas Dataframe übergeben. Das future_df muss eine target Spalte mit NA-Werten, eine timestamp Spalte mit den Zeitpunkten der Testbeobachtungen und - wenn auch im Kontext verwendet - die Werte der exogenen Features enthalten.

Vorteile

• Die TabICLForecaster-Klasse kümmert sich automatisch um Kalender-Features und Saisonalitäts-Transformationen. Dadurch kann TabICL auch ohne eigenes Feature-Engineering sofort angewendet werden.
• TabICL v2 ist open-source und lässt sich auch für kommerzielle Projekte kostenlos einsetzen (siehe Lizenz)

Nachteile bei Hardware-Anforderungen und Geschwindigkeit

• Geschwindigkeit: In unserer Kreuzvalidierung (CV) war TabICL etwa 17-mal langsamer als XGBoost, wenn auch Trainingszeiten mit einbezogen werden.
• Hardware-Anforderung: Auf einer NVIDIA L40S GPU läuft TabICL flüssig. Auf einem modernen Laptop mit CPU/GPU dauert ein CV-Durchlauf jedoch ca. 10x länger. Auf reiner CPU ist TabICL aktuell nur schwer praxisnah einsetzbar.
• Inferenz: Da beim In-Context-Learning Training und Inferenz nicht mehr klar getrennt sind, entstehen höhere Laufzeiten pro Vorhersage. Key-Value Caching bietet hier jedoch Potenzial, die Inferenzzeiten deutlich zu verringern.

Fazit: Wann nutzt man TabICL, wann XGBoost?

TabICL beweist, dass Tabular Foundation Modelle hervorragend als Out-of-the-Box-Baselines für Zeitreihen funktionieren. Mit geeignetem Feature-Engineering ist der Unterschied zu XGBoost jedoch gering. Ob sich der Gewinn an Prognosegüte lohnt, sollte anhand der praktischen Relevanz des Unterschiedes bewertet werden. Unsere allgemeinen Empfehlungen:

Wann TabICL die richtige Wahl ist:

• Wenige Trainingsdaten: Bei kurzer Trainingshistorie (< 3 bis 6 Monate, stündliche Daten, bis zu ~ 5K Beobachtungen) liefert TabICL in unserem Test dank Pretraining bessere Ergebnisse als XGBoost. Aber auch bei um die 18K Trainingsbeobachtungen sehen wir, dass TabICL kleine Vorteile bringen kann.
• Schnelle Baselines ohne Domain-Wissen: Wenn wenig Zeit für aufwändiges Feature-Engineering oder Hyperparameter-Tuning vorhanden ist, liefert TabICL "out-of-the-box" deutlich bessere Werte als Meta Prophet oder naive Baseline-Verfahren.
• Passende Hardware vorhanden: Eine leistungsfähige GPU ist verfügbar.
• Kleine Verbesserungen haben einen großen Hebel: In manchen Anwendungen können sehr kleine Verbesserungen skaliert einen großen Unterschied machen.

Wann man XGBoost nutzen sollte :

• Sehr große Datensätze (> 60.000 Beobachtungen): TabICL wurde laut den Entwickler*innen nicht für Datensätze mit mehr als 60K Datenpunkten vortrainiert. XGBoost hat diese Skalierungsbeschränkung nicht und verarbeitet auch Millionen von Zeilen problemlos.
• Eingeschränkte Ressourcen: Wenn keine GPU zur Verfügung steht oder die Deployment-Infrastruktur (z. B. Edge-Geräte) speicherbegrenzt ist.
• Hohe Geschwindigkeitsanforderungen: TabICL ist bislang nicht geeignet, wenn Inferenz- und Trainingszeiten im Millisekundenbereich liegen müssen, XGBoost dagegen schon.