KI gestützte Bedarfsprognose für eCommerce

Was das Demand Sensing von IKEA zeigt, und was nicht

Liegt ein Händler von der Größe IKEAs mit seiner Prognose daneben, stehen die Lager voller Regale, die niemand will, und dort, wo die beliebten stehen sollten, ist das Regal leer. IKEAs Antwort war Demand Sensing, ein KI Werkzeug aus einer dreijährigen Zusammenarbeit von IKEA Retail (Ingka Group), Inter IKEA Systems, Blue Yonder und weiteren Partnern. Laut Ingka analysiert es kurzfristige Muster der Nachfrage aus Eingaben wie Erkenntnissen über Kunden, Marktereignissen, Preisen, Kampagnen, lokalen Wetterberichten und äußeren wirtschaftlichen Faktoren, und bei IKEA Portugal wurde die Prognosegenauigkeit insgesamt um 5 % besser.¹

Die frühere Fassung dieses Artikels behauptete, das Werkzeug nutze "bis zu 200 Datenquellen pro Produkt" und habe manuelle Eingriffe "von 8 % auf 2 %" gesenkt. Keine der beiden Zahlen habe ich in einer Quelle von IKEA oder Ingka gefunden, die noch erreichbar ist, also sind beide gestrichen. Die 5 % reichen, um den Punkt zu machen.

Und der Punkt ist dieser: Die Techniken darunter sind kein Geheimnis. Die Modelle sind quelloffen, und die meisten Daten, die ein kleinerer Shop braucht, liegen schon in seiner Datenbank. Was einen Einkauf nach Bauchgefühl von einer Prognose unterscheidet, die du verteidigen kannst, ist nicht das Budget. Es ist die Methode: ein Vergleichsmaßstab, ein ehrlicher Test und eine Verbindung von der Prognose zur Bestellung beim Lieferanten.

Dieser Artikel vergleicht drei Ansätze, die ich nutze, SARIMA, Prophet und Gradient Boosted Trees wie XGBoost, erklärt, wann jeder seinen Platz verdient, und zeigt, wie du sie in einen Shop mit Rails und Solidus einbaust. Den breiteren Werkzeugkasten, von gleitenden Durchschnitten bis zu Methoden auf Grundlage von Expertenurteil, findest du im Leitfaden für Geschäftsprognosen. Die Methoden folgen Hyndman und Athanasopoulos, Forecasting: Principles and Practice, frei online lesbar.²

Durch den ganzen Artikel begleitet uns ein erfundenes Unternehmen. Muldenpfad Outdoor ist ein Shop für Outdoorausrüstung in Leipzig unter muldenpfad.example. Er verkauft Regenjacken, Wanderschuhe und Gaskartuschen, hat drei Jahre wöchentliche Verkaufshistorie und kauft bei Lieferanten mit zwei Wochen Lieferzeit. Niemand davon ist echt, und jede Zahl unten ist erfunden, damit jeder Schritt sichtbar wird.

Drei Lehren, die auch für einen kleineren Shop gelten

Die Daten, die du schon hast, sind mehr wert, als du denkst. Eine Solidus Datenbank enthält die Bestellhistorie, mit Tracking auf Grundlage von Einwilligung auch Produktaufrufe und Suchen, und dazu deinen eigenen Aktionskalender. Das reicht für eine brauchbare Prognose.

Äußere Signale zählen, aber nur manche. Wetter, Feiertage, Zahltage, deine eigenen Aktionen und deine eigenen Werbeausgaben bewegen alle die Nachfrage. Die Frage ist nicht, wie viele du einspeisen kannst, sondern welche du für die Wochen, die du prognostizierst, tatsächlich im Voraus kennst.

Prognostiziere auf der Ebene der Entscheidung. IKEA prognostiziert pro Produkt und Filiale. Ein Shop, der pro Produkt aus einem Lager nachbestellt, braucht eine Prognose pro Produkt und Woche, nicht pro Tag und Postleitzahl.

Ein Beispiel: Muldenpfad bestellt Jacken jeden Montag nach, und der Lieferant liefert zwei Wochen später. Die Prognose, auf die es ankommt, ist also der wöchentliche Absatz an Jacken für die nächsten drei Wochen. Eine tägliche Prognose wäre verrauschter und würde eine Frage beantworten, die niemand stellt.

Fang mit dem Vergleichsmaßstab an, den alle überspringen

Vor allem Klugen sollte jede Prognose mit den einfachsten möglichen verglichen werden. Hyndman und Athanasopoulos nennen vier einfache Methoden. Für einen Shop mit Saison zählt die saisonal naive Methode am meisten: Die Prognose für nächste Woche ist dieselbe Woche im Vorjahr.³ Schlägt ein Modell das nicht, hat es sich seinen Platz nicht verdient.

Ein Beispiel: In der ersten Oktoberwoche letzten Jahres hat Muldenpfad 118 Jacken verkauft. Die saisonal naive Prognose für die erste Oktoberwoche dieses Jahr lautet 118. Sie übersieht Wachstum, Wetter und Aktionen, und trotzdem ist sie in einem Geschäft, das nach dem Kalender läuft, erstaunlich schwer zu schlagen.

Drei Modelle, drei verschiedene Fragen

SARIMA, ein saisonales autoregressives integriertes Modell mit gleitendem Durchschnitt, erklärt jede Woche aus ihrer eigenen Vergangenheit: aus den jüngsten Werten (autoregressiv), aus den Differenzen, die einen Trend entfernen (integriert), aus den jüngsten Prognosefehlern (gleitender Durchschnitt) und aus denselben Termen eine Saison zurück.⁴ Es ist das statistische Arbeitspferd. Es passt zu Grundsortiment mit ruhigen, wiederkehrenden Mustern, und mit der SARIMAX Umsetzung in statsmodels kann es auch äußere Variablen aufnehmen, sogenannte exogene Regressoren.⁵

Prophet, veröffentlicht vom Core Data Science Team von Facebook und heute unter Meta gepflegt, schätzt ein additives Modell mit Trend, jährlicher und wöchentlicher Saisonalität und Feiertagseffekten und kommt mit fehlenden Daten und Brüchen im Trend gut zurecht.⁶ Feiertage werden als Tabelle übergeben, und zusätzliche Regressoren wie ein Merkmal für Aktionen lassen sich ergänzen, solange ihre Werte für die Historie und für die künftigen Termine bekannt sind.⁷ Es passt zu Produkten mit starken Saisons, Spitzen an Feiertagen und Lücken in der Historie, etwa Wochen, in denen ein Produkt ausverkauft war.

Gradient Boosted Trees, XGBoost oder LightGBM, sind allgemeine Modelle des maschinellen Lernens. Sie wissen nicht, was Zeit ist. Du gibst ihnen Merkmale, etwa den Absatz der letzten Woche, dieselbe Woche im Vorjahr, Preis, ein Merkmal für Aktionen, die Wettervorhersage und die Kalenderwoche, und sie lernen, wie diese zusammenspielen, auch dort, wo Effekte keine Geraden sind.

Die frühere Fassung dieses Artikels behauptete, XGBoost sei "der einzige Ansatz, der von Natur aus mehrere Eingangsmerkmale verarbeitet". Das war falsch. SARIMAX und Prophet nehmen beide äußere Variablen auf.⁵⁷ Was Bäume besser können, ist Wechselwirkungen finden, die niemand vorgegeben hat, zum Beispiel dass eine Aktion nur wirkt, wenn es gleichzeitig regnet.

Die Belege sind wissenswert. Im M5 Prognosewettbewerb, gebaut auf Zehntausenden Verkaufsreihen aus dem Handel, wurden die vorderen Plätze sowohl in der Wertung für Genauigkeit als auch in der für Unsicherheit von Einreichungen mit Gradient Boosted Trees beherrscht, allen voran LightGBM.⁸ Das ist ein Ergebnis für große Mengen verwandter Reihen mit vielen Merkmalen. Für eine einzelne Produktlinie mit drei Jahren Wochendaten sagt es sehr wenig.

Durchgerechnetes Beispiel: die Jacken von Muldenpfad durch jede Brille

SARIMA sieht eine Reihe, die sich alle 52 Wochen wiederholt, mit einem langsam steigenden Trend, der nach einer Differenz verschwindet. Seine Prognose für Oktober folgt dem letzten Oktober, vom Trend etwas angehoben.

Prophet sieht einen Trend, der um etwa 6 % im Jahr steigt, eine Jahressaison mit dem Höhepunkt im Oktober und November und dem Tiefpunkt im Juni, und den zusätzlichen Schub in Wochen mit Aktion und in Wochen mit Feiertag. Seine Prognose für Oktober ist Trend plus Oktobersaison.

Gradient Boosting sieht Merkmale. Der Absatz an Jacken steigt mit der Zahl der Regentage in der Vorhersage für die kommende Woche, springt bei einer Aktion und steigt noch mehr, wenn beides zusammenkommt. Seine Prognose für Oktober hängt davon ab, was Wettervorhersage und Aktionskalender sagen.

Alle drei liefern eine Zahl. Welcher Zahl du trauen kannst, ist die nächste Frage.

Wähl das Modell an Wochen, die es nie gesehen hat

Das Modell wird nach seinen Fehlern auf Daten gewählt, mit denen es nicht trainiert wurde. Das einfachste Maß ist der mittlere absolute Fehler:

$$\text{MAE} = \frac{1}{n}\sum_{t=1}^{n} \left| y_t - \hat{y}_t \right|$$

Dabei ist $\text{MAE}$ der mittlere absolute Fehler (mean absolute error), $n$ die Zahl der getesteten Wochen, $y_t$ der tatsächliche Absatz in Woche $t$, $\hat{y}_t$ die Prognose für diese Woche, und die senkrechten Striche nehmen die Größe jedes Fehlers, egal mit welchem Vorzeichen. Er hat dieselbe Einheit wie der Absatz, hier Jacken. Grundlagen: der Mittelwert

Hyndman und Athanasopoulos beschreiben die anderen üblichen Maße und ihre Fallen, darunter, dass prozentuale Fehler versagen, wenn der tatsächliche Absatz null ist oder nahe daran.⁹ Für ein einzelnes Produkt ist der MAE leicht zu lesen und schwer zu missbrauchen.

Der wichtige Teil ist, wie der Test läuft. Die frühere Fassung dieses Artikels hat jedes Modell auf der ganzen Historie geschätzt und dann seine angepassten Werte mit den letzten 20 % genau dieser Historie verglichen. Die Modelle kannten diese Wochen schon, also hat der Test ihnen geschmeichelt. Die ehrliche Methode ist die Kreuzvalidierung für Zeitreihen: ein wandernder Prognoseursprung, bei dem jede Prognose nur aus den Wochen davor entsteht.¹⁰ Die Klasse TimeSeriesSplit in der Bibliothek scikit-learn erzeugt genau diese Aufteilungen.¹¹

Durchgerechnetes Beispiel: vier Testwochen für die Jacken

Vier Testwochen, jede Prognose nur aus den Wochen davor. Der tatsächliche Absatz lag bei 100, 120, 90 und 110. Prophet hat 110, 115, 100 und 100 prognostiziert.

Die Fehler sind $|100 - 110| = 10$, $|120 - 115| = 5$, $|90 - 100| = 10$ und $|110 - 100| = 10$. Also ist $\text{MAE} = (10 + 5 + 10 + 10) / 4 = 8{,}75$ Jacken pro Woche.

Über ein ganzes Jahr wandernder Tests sind die Ergebnisse des Beispiels: saisonal naiv 14,0, SARIMA 11,2, Prophet 9,6 und Gradient Boosting 8,8 Jacken pro Woche. Alle drei Modelle schlagen den Maßstab, also verdienen alle drei einen Platz. Bei Gaskartuschen, einem ruhigen Grundsortiment ohne Wettereffekt, könnte derselbe Test SARIMA vorne zeigen und die Bäume ohne jeden Mehrwert.

Kombinierte Prognosen sind schwer zu schlagen

In der Praxis wähle ich nicht immer ein einziges Modell. Das Kombinieren von Prognosen hat eine lange Erfolgsgeschichte. Hyndman und Athanasopoulos zitieren den Überblick von Clemen, nach dem die Ergebnisse "virtually unanimous" sind, also nahezu einstimmig: Mehrere Prognosen zu kombinieren erhöht die Genauigkeit. Und sie halten fest, dass sich ein einfacher Durchschnitt als schwer zu schlagen erwiesen hat.¹²

Ein gängiger Weg, eine Kombination zu gewichten, ist der Kehrwert des Fehlers jedes Modells:

$$w_m = \frac{1 / \text{MAE}_m}{\sum_{k=1}^{K} 1 / \text{MAE}_k}$$

Dabei ist $w_m$ das Gewicht von Modell $m$, $\text{MAE}_m$ sein mittlerer absoluter Fehler in den wandernden Tests, $K$ die Zahl der Modelle, und die Summe im Nenner sorgt dafür, dass die Gewichte zusammen 1 ergeben. Ein Modell mit halbem Fehler bekommt das doppelte Gewicht. Grundlagen: Verhältnisse und Raten

Durchgerechnetes Beispiel: eine kombinierte Prognose für Oktober

Die Kehrwerte der Fehler sind $1 / 11{,}2 = 0{,}0893$ für SARIMA, $1 / 9{,}6 = 0{,}1042$ für Prophet und $1 / 8{,}8 = 0{,}1136$ für Gradient Boosting. Ihre Summe ist $0{,}3071$. Die Gewichte sind $0{,}0893 / 0{,}3071 = 0{,}29$, $0{,}1042 / 0{,}3071 = 0{,}34$ und $0{,}1136 / 0{,}3071 = 0{,}37$.

Für die erste Oktoberwoche prognostizieren die drei 120, 132 und 140 Jacken. Die gewichtete Kombination ist $0{,}29 \times 120 + 0{,}34 \times 132 + 0{,}37 \times 140 = 34{,}8 + 44{,}9 + 51{,}8 = 131{,}5$. Der einfache Durchschnitt ist $(120 + 132 + 140) / 3 = 130{,}7$. Weniger als eine Jacke Unterschied, und genau deshalb reicht der einfache Durchschnitt so oft. Ob die Kombination das beste einzelne Modell schlägt, beantwortet der wandernde Test, nicht eine Annahme.

Einbau in Rails und Solidus

Die Modelle laufen in Python, wo die Bibliotheken sind. Rails sammelt die Historie, übergibt sie als JSON und speichert das Ergebnis. Die Verkäufe kommen aus abgeschlossenen Bestellungen in Solidus:

module Forecasting
  class History
    def self.weekly_units(variant)
      Spree::LineItem
        .joins(:order)
        .merge(Spree::Order.complete)
        .where(variant_id: variant.id)
        .group(Arel.sql("DATE_TRUNC('week', spree_orders.completed_at)"))
        .sum(:quantity)
        .sort
        .map { |week, units| { ds: week.to_date.iso8601, y: units } }
    end
  end

  class Runner
    def forecast(variant, horizon_weeks: 3)
      payload = {
        history: History.weekly_units(variant),
        calendar: WeeklyCalendar.flags(variant, past_and_next: horizon_weeks), # Aktionen des Shops und Wochen mit Feiertagen in Sachsen
        horizon: horizon_weeks
      }
      output, status = Open3.capture2("python3", "forecast/run.py", stdin_data: payload.to_json)
      raise "forecast failed for #{variant.sku}" unless status.success?

      Forecast.create!(variant: variant, result: JSON.parse(output), generated_at: Time.current)
    end
  end
end

Die Daten gehen über die Standardeingabe hinein, statt wie in der früheren Fassung in den Python Quelltext kopiert zu werden, also kann ein Produktname mit einem Anführungszeichen das Skript nicht zerbrechen. Der Teil von run.py für Prophet nimmt das Merkmal für Aktionen und ein Merkmal für Feiertage als Regressoren auf, so wie es die Dokumentation verlangt:⁷

import json, sys
import pandas as pd
from prophet import Prophet

data = json.load(sys.stdin)
history = pd.DataFrame(data["history"])
history["ds"] = pd.to_datetime(history["ds"])
promos = pd.DataFrame(data["calendar"])  # ds, promotion, bank_holiday_week (0 oder 1), vergangene und künftige Wochen
promos["ds"] = pd.to_datetime(promos["ds"])
history = history.merge(promos, on="ds", how="left").fillna(0)

model = Prophet(yearly_seasonality=True, weekly_seasonality=False)
model.add_regressor("promotion")
model.add_regressor("bank_holiday_week")
model.fit(history)

future = model.make_future_dataframe(periods=data["horizon"], freq="W-MON")
future = future.merge(promos, on="ds", how="left").fillna(0)
forecast = model.predict(future).tail(data["horizon"])
print(forecast[["ds", "yhat", "yhat_lower", "yhat_upper"]].to_json(orient="records", date_format="iso"))

Zwei Korrekturen gegenüber der früheren Fassung. Sie hat das Modell angelegt und dann, wenn es Feiertage gab, ein zweites angelegt und die Einstellungen des ersten weggeworfen. Und sie hat einen Regressor für Aktionen ergänzt, ohne die Spalte mit den Aktionen in die Historie oder in die Tabelle der künftigen Wochen zu schreiben, was Prophet aber verlangt.⁷ Die wöchentliche Saisonalität ist aus, weil die Daten schon wöchentlich sind. Aus demselben Grund kommen die Feiertage als wöchentliches Merkmal: Die Feiertagseffekte von Prophet sitzen auf genauen Tagen, und ein Feiertag am Montag landet selten genau auf dem Datum, mit dem eine Verkaufswoche beschriftet ist.

Dasselbe Skript rechnet SARIMA mit statsmodels und die Bäume mit XGBoost, bewertet alle in wandernden Tests und gibt jede Prognose mit ihrem MAE zurück, damit Rails die Gewichte anwenden kann.

Aus einer Prognose wird ein Meldebestand

Eine Prognose, die in einem Dashboard liegt, ist Dekoration. Ihren Wert zeigt sie, wenn sie über eine Bestellung entscheidet. Und eine Prognose ist eine Spanne, keine Zahl: Hyndman und Athanasopoulos behandeln das Prognoseintervall als Teil der Prognose selbst.¹³ Prophet liefert standardmäßig eines mit 80 % Breite, das die Unsicherheit im Trend und das Rauschen in den Beobachtungen abdeckt, die Unsicherheit in der Saisonalität aber nur, wenn du die volle Stichprobenziehung laufen lässt.¹⁴

Die frühere Fassung dieses Artikels hat den Meldebestand, also den Lagerstand, bei dem nachbestellt wird, auf die prognostizierte Nachfrage über die Lieferzeit mal 1,15 gesetzt, ein fester Puffer von 15 %. Dieser Puffer übersieht, wie unsicher die Prognose tatsächlich ist: Für Gaskartuschen ist er zu viel und für Jacken in einem nassen Oktober zu wenig. Die bessere Regel nutzt das Intervall. Bestell nach, wenn der Bestand auf das obere Ende der Prognosespanne für die Lieferzeit fällt.

Durchgerechnetes Beispiel: wann die Jacken nachbestellt werden

Die Lieferzeit beträgt zwei Wochen. Die kombinierte Prognose für die nächsten zwei Wochen lautet 131 und 129 Jacken, also ist die erwartete Nachfrage über die Lieferzeit 260. Das obere Ende des 80 % Intervalls über dieselben zwei Wochen liegt bei 310. Ein zweiseitiges 80 % Intervall lässt 10 % oberhalb seines oberen Endes, also deckt ein Bestand von 310 die Nachfrage während der Lieferzeit in ungefähr neun von 10 Wochen, wenn das Intervall ehrlich ist.

Der Meldebestand liegt bei 310 Jacken. Die Differenz, $310 - 260 = 50$, ist der Sicherheitsbestand, den die Unsicherheit der Prognose selbst verlangt. Am Montag hat Muldenpfad 340 Jacken auf Lager, also keine Bestellung. Am Montag darauf sind es 296, unter 310, also geht die Bestellung raus.

Der feste Puffer hätte $260 \times 1{,}15 = 299$ gesagt. Diesmal nah dran, aber bei Gaskartuschen, wo das Intervall schmal ist, läge viel mehr auf Lager als nötig, und bei einem plötzlichen Kälteeinbruch für Jacken viel weniger. Prüf auch das Intervall ehrlich: Liegt der tatsächliche Absatz deutlich öfter als in einer von 10 Wochen über dem oberen Ende, ist das Intervall zu schmal, und mit ihm der Meldebestand.

module Inventory
  class ReorderPoint
    def self.for(variant, lead_time_weeks:)
      weeks = Forecasting::Runner.new.forecast(variant, horizon_weeks: lead_time_weeks).result
      expected = weeks.sum { |w| w["yhat"] }
      upper = weeks.sum { |w| w["yhat_upper"] } # obere Enden der Wochen zu summieren ist eine vorsichtige Abkürzung
      { expected: expected.round, reorder_point: upper.ceil, safety_stock: (upper - expected).ceil }
    end
  end
end

Die oberen Enden der einzelnen Wochen zu summieren, wie der Code es tut, überschätzt die Spanne über zwei Wochen leicht, weil auf eine schlechte Woche selten eine genauso schlechte folgt. Für einen Shop in der Größe von Muldenpfad irrt das auf der Seite der Lieferfähigkeit, und das ist meist die richtige Seite. Eine genaue Fassung simuliert die zwei Wochen gemeinsam.

Eine Einkaufsentscheidung, die ein Modell trifft, sollte sich auch hinterher erklären lassen: welches Modell, welche Eingaben, welches Intervall. Jede Prognose mit ihren Eingaben zu speichern, wie es der Runner tut, macht das möglich, wenn jemand im Januar fragt, warum der Shop 600 Jacken gekauft hat.

So fängst du an

1. Exportier den wöchentlichen Absatz pro Produkt aus Solidus oder deiner Plattform: Datum, Produkt, verkaufte Menge. Markier die Wochen, in denen ein Produkt ausverkauft war, denn null Verkäufe heißen dann null Bestand, nicht null Nachfrage.
2. Berechne die saisonal naive Prognose. Das ist die Latte.
3. Schätz Prophet mit den Feiertagen in Sachsen und deinem eigenen Aktionskalender und teste es mit wanderndem Ursprung.
4. Nimm SARIMA dazu. Schlägt es Prophet bei einem Produkt, ist das Muster dieses Produkts regelmäßig genug, dass einfacher besser ist.
5. Nimm Gradient Boosting erst dazu, wenn du äußere Merkmale hast, die du im Voraus kennst, etwa Preis, Aktionen und geplante Werbeausgaben.
6. Kombinier die Überlebenden, gewichtet oder einfach gemittelt, und prüf jeden Monat neu.
7. Verbinde die Prognose mit der Entscheidung: ein Meldebestand aus dem Intervall, ein Alarm zum Nachbestellen oder die Woche, in der du die Werbeausgaben erhöhst.

Der Abstand zwischen Bauchgefühl und Prognose ist keine raffinierte Technik. Es geht darum, den Daten, die du schon hast, bessere Fragen zu stellen und die Antworten dann an Wochen zu prüfen, die das Modell nie gesehen hat.

Quellen

Footnotes

1. Ingka Group, IKEA uses demand sensing to improve the customer offering, Ingka newsroom, 22. Dezember 2023, https://www.ingka.com/newsroom/ikea-uses-demand-sensing-to-improve-the-customer-offering/

2. Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice, 3. Auflage, OTexts, Melbourne, 2021, https://otexts.com/fpp3/

3. Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice, 3. Auflage, Abschnitt 5.2, Some simple forecasting methods, OTexts, 2021, https://otexts.com/fpp3/simple-methods.html

4. Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice, 3. Auflage, Kapitel 9, ARIMA models, OTexts, 2021, https://otexts.com/fpp3/arima.html

5. statsmodels, statsmodels.tsa.statespace.sarimax.SARIMAX, Dokumentation, abgerufen im November 2026, https://www.statsmodels.org/stable/generated/statsmodels.tsa.statespace.sarimax.SARIMAX.html

6. Meta, Prophet: forecasting at scale, Projektdokumentation, abgerufen im November 2026, https://meta.github.io/prophet/

7. Meta, Seasonality, holiday effects and regressors, Prophet Dokumentation, abgerufen im November 2026, https://meta.github.io/prophet/docs/seasonality,_holiday_effects,_and_regressors.html

8. Tim Januschowski, Yuyang Wang, Kari Torkkola, Timo Erkkilä, Hilaf Hasson und Jan Gasthaus, Forecasting with trees, International Journal of Forecasting, Band 38, Heft 4, 2022 (frei zugänglich), https://cdn.amazon.science/17/31/0d99831d4add92e711a56abc75f8/forecasting-with-trees.pdf

9. Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice, 3. Auflage, Abschnitt 5.8, Evaluating point forecast accuracy, OTexts, 2021, https://otexts.com/fpp3/accuracy.html

10. Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice, 3. Auflage, Abschnitt 5.10, Time series cross validation, OTexts, 2021, https://otexts.com/fpp3/tscv.html

11. scikit-learn, sklearn.model_selection.TimeSeriesSplit, Dokumentation, abgerufen im November 2026, https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.html

12. Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice, 3. Auflage, Abschnitt 13.4, Forecast combinations, OTexts, 2021, https://otexts.com/fpp3/combinations.html

13. Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice, 3. Auflage, Abschnitt 5.5, Distributional forecasts and prediction intervals, OTexts, 2021, https://otexts.com/fpp3/prediction-intervals.html

14. Meta, Uncertainty intervals, Prophet Dokumentation, abgerufen im November 2026, https://meta.github.io/prophet/docs/uncertainty_intervals.html