Bei der Bedarfsprognose schlägt klassisches ML noch immer ein LLM

Ein Einkäufer kopiert die Monatsabsätze eines Produkts über ein Jahr in einen Chat-Assistenten und fragt, wie viele Einheiten er für das nächste Quartal bestellen soll. Die Antwort ist eine einzelne, selbstbewusste Zahl mit einer vernünftig klingenden Erklärung: etwas Saisonalität, ein leichter Aufwärtstrend, und ein Sicherheitspuffer ist eingerechnet. Der Einkäufer bestellt.

Die Zahl mag sogar nah dran sein. Das ist nicht das Problem. Das Problem ist, dass niemand weiß, wie nah sie wahrscheinlich ist, weil sich an ihr nichts messen lässt. Es gibt keinen Nachweis, wie diese Methode im vergangenen Jahr abgeschnitten hätte, keine Fehlerspanne und kein Wissen über die Aktion, die für nächsten Monat geplant ist, über die drei Wochen, in denen der Artikel ausverkauft war, oder über die neue Lieferzeit des Lieferanten.

Bedarfsprognose ist ein statistisches Problem über Zahlen im Zeitverlauf, mit bekannter Struktur: Trend, Saisonalität, Aktionen, Preisänderungen und Fehlbestände, die echte Nachfrage verdecken. Klassische Verfahren wurden für genau diese Struktur gebaut. Exponentielle Glättung, ARIMA-artige Modelle und Gradient-Boosted Trees auf gut gewählten Merkmalen sind günstig im Betrieb, und vor allem lässt sich ihr Fehler an der Historie messen, bevor ihnen jemand vertraut. Ein universelles Sprachmodell erzeugt wahrscheinlichen Text. Eine Zahl in diesem Text kommt ohne Fehlerbalken und ohne Backtest.

Wo die Frage an ein Chatmodell schiefgeht

Kein Backtest. Sie wissen nicht, wie falsch die Methode mit den Daten des Vorjahres gelegen hätte, und können sie deshalb mit nichts vergleichen – nicht einmal damit, gar nichts Kluges zu tun.

Absatz ist nicht Nachfrage. Als das Regal leer war, lag der Absatz bei null, die Nachfrage nicht. Ein Modell, das rohe Absatzhistorie liest, lernt entgangene Nachfrage als geringe Nachfrage. Prognose-Pipelines behandeln Fehlbestände ausdrücklich; eine eingefügte Tabelle nicht.

Was in einen Prompt passt, ist nicht die Historie. Ein echtes Sortiment umfasst viele Artikel an vielen Standorten, mit einer Hierarchie von Kategorien, die Muster teilen. Das passt nicht in ein Gespräch, also prognostiziert das Modell jeden Artikel isoliert aus dem Wenigen, das es zu sehen bekam.

Jedes Mal eine andere Antwort. Sprachmodelle ziehen ihre Ausgabe als Stichprobe. Fragen Sie zweimal, bekommen Sie womöglich zwei Zahlen, und es gibt keinen begründeten Weg, zwischen ihnen zu wählen.

Erklärungen, die richtig klingen. Das Modell erwähnt Saisonalität, ob die Daten welche enthalten oder nicht, weil Prognosen meist Saisonalität erwähnen. Die Erklärung ist ein Stil, keine Analyse.

Kosten und Tempo im großen Maßstab. Jeden Artikel jede Woche durch ein großes Modell zu schicken, kostet weit mehr als ein klassisches Modell, das bequem auf gewöhnlicher Hardware läuft.

Wohin welches Modell gehört

Klassische Modelle liefern die Zahlen. Beginnen Sie mit naiven Baselines: derselbe Zeitraum im Vorjahr und der Durchschnitt der letzten Perioden. Probieren Sie dann exponentielle Glättung und ein Gradient-Boosting-Modell mit Merkmalen für Preis, Aktionen, Kalender und Fehlbestände. Behalten Sie, was die Baselines im Backtest schlägt, und messen Sie weiter.

Das Sprachmodell sammelt und erklärt. Es liest die E-Mail des Lieferanten, die eine längere Lieferzeit ankündigt, und macht daraus einen Parameter. Es verwandelt den vom Vertrieb geschriebenen Aktionsplan in Merkmale, die die Prognose nutzen kann. Es erklärt dem Einkäufer eine Prognose in einfachen Worten und entwirft die Bestellung zur Freigabe. Dort sind Sprachmodelle stark, wie in wo sich Sprachmodelle bezahlt machen dargelegt.

Foundation-Modelle für Zeitreihen sind eine eigene Kategorie. Modelle, die speziell auf Zeitreihen vortrainiert sind, sind keine Chat-Assistenten, und einige davon sind einen Test wert. Behandeln Sie sie wie jeden anderen Kandidaten: dieselbe Baseline, derselbe Backtest, und behalten Sie sie nur, wenn sie auf Ihren Daten gewinnen.

Ein Mensch entscheidet über die Bestellung. Die Prognose, ihre Unsicherheit und die Randbedingungen (Mindestbestellmenge, Haltbarkeit, Budget) werden zu einem Bestellvorschlag. Jemand, der dafür verantwortlich ist, gibt ihn frei.

Auf diese Kette sind die Module von Hurukan ausgelegt. Bestände, Reservierungen und Inventuren in Lager und Logistik liefern die Historie und die Fehlbestände; der Einkauf macht aus einer Prognose einen Bestellvorschlag, der auf Freigabe wartet. Die Ebene Superintelligenz leitet jede Aufgabe an die passende Art von Modell weiter: ein Sprachmodell zum Lesen und Entwerfen, ein Prognosemodell für die Zahlen. Das System ist im Aufbau. Ein solches Prognosemodell ist zudem ein gutes Beispiel für ein Modell, das auf Ihrer eigenen Hardware laufen kann, wie in kleine Modelle auf eigener Hardware besprochen.

Ein Test, den Sie heute machen können

Nehmen Sie ein Produkt mit mindestens zwei Jahren Historie. Halten Sie die jüngsten drei Monate zurück und tun Sie so, als kennten Sie sie nicht.

Prognostizieren Sie diese drei Monate auf drei Arten, nur mit den Daten vor dem zurückgehaltenen Zeitraum:

1. Dieselben drei Monate des Vorjahres.
2. Der Durchschnitt der drei Monate unmittelbar davor.
3. Ihre aktuelle Methode, ob Planungswerkzeug, Tabelle oder Chat-Assistent.

Vergleichen Sie jede Prognose mit dem, was tatsächlich geschah, anhand des mittleren absoluten Fehlers je Monat.

Schlägt Ihre aktuelle Methode nicht beide naiven Baselines, hilft kein Modell-Upgrade, bevor das verstanden ist. Was auch immer gewinnt: Sie haben jetzt eine Zahl dafür, wie sehr es typischerweise danebenliegt, und genau diese Zahl macht eine Prognose brauchbar. Sie sagt Ihnen, wie viel Sicherheitsbestand Sie halten sollten und wie weit Sie der nächsten Zahl trauen können.