Ein Frischwaren-Betreiber kam mit einer klaren Frage zu uns: Könnt ihr die Nachfrage von morgen pro Gericht, pro Standort vorhersagen, genau genug, damit wir keine Marge mehr wegwerfen und mittags nicht mehr ausverkauft sind? Achtzehn Monate später sagt die Plattform in der Produktion mit 98% Genauigkeit voraus. Man nimmt an, der schwierige Teil sei das maschinelle Lernen gewesen. War er nicht.
Das Modell, das die Vorhersagen macht, ist ein Gradient-Boosted-Regressor mit ein paar angeschraubten Saisonalitäts-Features. Eine kompetente Data Scientist kann an einem Nachmittag etwas aus dieser Familie aufstellen. Wir hatten innerhalb von drei Wochen eine respektable erste Version — im Backtest genau genug, damit alle im Raum nickten.
Dann verbrachten wir fünf Monate damit, all das zu bauen, was aus «einem genauen Backtest» «eine Zahl, auf die eine Betriebsleiterin den Tag setzt» macht. Diese Lücke ist die ganze Arbeit, und fast niemand schreibt darüber, weil sie nicht glamourös ist. Also hier ist sie.
01Das Drei-Wochen-Modell
Die Nachfrage für ein stabiles, gut erfasstes Geschäft vorherzusagen, ist offen gesagt ein gelöstes Problem. Man hat ein Ziel (verkaufte Einheiten), einen Kalender und einen Stapel historischer Zeilen. Man konstruiert ein paar Dutzend Features — Wochentag, Lag-Fenster, gleitende Mittel, Feiertage, einen Wetter-Join — und lässt eine Boosting-Bibliothek die Interaktionen finden. An der Mathematik sterben die Projekte nicht.
Was die drei Wochen tatsächlich brachten, war die Gewissheit, dass das Signal überhaupt existierte. Der Backtest sagte uns, dass die Nachfrage bei sauberen Eingaben auf ein paar Prozentpunkte genau vorhersagbar war. Das ist das grüne Licht. Es ist nicht das Produkt.
Eine gute Backtest-Zahl ist das gefährlichste Artefakt im maschinellen Lernen. Sie sieht aus wie die Ziellinie und ist kaum mehr als der Startschuss. Backtests laufen auf Daten, die von einem Menschen bereinigt, gejoint und zeitlich ausgerichtet wurden, der die Antwort bereits kennt. Die Produktion hat keinen dieser Luxusgüter.
02Wohin die fünf Monate gingen
Hier ist die ehrliche Abrechnung der nächsten fünf Monate. Nichts davon ist Modellierung. Alles davon ist das, was das Modell nutzbar gemacht hat.
- Ingestion, die die Realität übersteht. Verkaufsfeeds kommen zu spät, doppelt oder gar nicht an. Ein POS startet neu und spielt den gestrigen Tag erneut ab. Wir bauten eine idempotente Ingestion, die sich sicher erneut ausführen lässt und Zeilen, denen sie nicht traut, in Quarantäne stellt, statt den Trainingsdatensatz zu vergiften.
- Ein Feature Store mit Gedächtnis. Die Features, auf denen das Modell trainiert, müssen zum Vorhersage-Zeitpunkt nur mit den Daten berechenbar sein, die man dann tatsächlich hätte — kein Blick in die Zukunft. Diese Point-in-Time-Korrektheit durchzusetzen, war Wochen an Arbeit und deckte zwei Lecks auf, die den ursprünglichen Backtest aufgebläht hatten.
- Backfill und Replay. Wenn die Historie eines Standorts falsch war, mussten wir jede nachgelagerte Vorhersage für diesen Standort neu aufbauen, ohne das Live-System abzuschalten. Replay ist Klempnerei, die niemand vorführt und jeder braucht.
- Monitoring vor Features. Wir lieferten Drift- und Freshness-Alarme aus, bevor wir die halbe UI auslieferten. Eine still falsche Vorhersage ist schlimmer als eine sichtbar fehlende.
- Das menschliche Override. Ein neuer Standort öffnet, ein Fest fällt an, eine Strasse wird gesperrt. Das Modell kann es nicht wissen. Planer brauchten einen sanktionierten Weg, die Zahl anzustupsen und das System aus dem Stups lernen zu lassen.
Das Modell beantwortet eine Frage. Die Plattform entscheidet, welche Frage, mit welchen Daten, für wen, und was passiert, wenn die Antwort falsch ist.
— Dazu, warum die Hülle die Arbeit ist03Der Datenvertrag
Das Wirksamste, das wir bauten, war keine Modellverbesserung. Es war ein Datenvertrag: ein expliziter, validierter Schema-Vertrag zwischen jeder vorgelagerten Quelle und unserer Pipeline. Spaltentypen, erlaubte Bereiche, Freshness-Fenster, Null-Richtlinien — alles deklariert, alles an der Tür geprüft.
Vor dem Vertrag konnte eine Vorhersage still degradieren, weil ein POS-Anbieter ein Währungsfeld von Cents auf Dollar änderte und niemand es uns sagte. Nach dem Vertrag wird diese Änderung bei der Ingestion mit einem benannten, eskalierten Fehler abgewiesen — und die letzte gute Vorhersage bleibt auf dem Bildschirm statt einer selbstbewusst falschen neuen.
# every source is validated at the door, not after it poisons training sales_daily: units: int >= 0 # reject negatives — Rückerstattungen gehen woanders hin revenue: decimal(10,2) # cents → in v3 markiert, jetzt erzwungen site_id: fk(sites) # unbekannter Standort → Quarantäne, On-Call eskalieren recorded_at: freshness <= 6h # veralteter Feed → letzte gute Vorhersage halten on_violation: quarantine + alert # niemals: still darauf trainieren
Das ist das unsexy Herz jedes Produktions-ML-Systems, das wir ausgeliefert haben. Das Modell ist eine Funktion; der Vertrag ist das, was garantiert, dass die Funktion mit den Eingaben gefüttert wird, die sie zu erwarten trainiert wurde. Überspringt man ihn, hat man keine Vorhersageplattform — man hat einen sehr teuren Zufallszahlengenerator, der meistens richtig liegt.
04Drift ist ein Feature, kein Versagen
Jedes Modell zerfällt. Geschmäcker verschieben sich, eine neue Speisekarte kommt, ein Konkurrent eröffnet gegenüber. Die Frage ist nie, ob sich die Welt unter dem Modell wegbewegt — sondern, ob man es aus einem Dashboard erfährt oder aus einem wütenden Anruf.
Wir behandeln Drift-Erkennung als erstklassiges Produkt-Feature. Die Plattform vergleicht kontinuierlich Live-Eingabeverteilungen und Live-Fehler mit den Trainings-Baselines. Wenn eines davon einen Schwellenwert überschreitet, tut sie drei Dinge, in dieser Reihenfolge:
- Sie sagt es jemandem — einem bestimmten Menschen, mit dem Standort, der Metrik und wie weit sie sich bewegt hat.
- Sie schützt die Ausgabe — indem sie die Konfidenzbänder verbreitert oder auf eine einfachere, robustere Baseline zurückfällt, statt einem Modell zu trauen, das jetzt extrapoliert.
- Sie plant ein Retrain — mit den neuen Daten, abgesichert hinter derselben Backtest-Hürde, die das Original nehmen musste.
Anhaltend in der Produktion, nicht nur im Backtest.
Leere Kühlschränke mittags, um mehr als die Hälfte reduziert.
Marge, die früher am Tagesende weggeworfen wurde.
Beachten Sie, dass die Schlagzeilen-Zahl — 98% — nicht die interessante ist. Die interessanten Zahlen sind die beiden daneben, denn die sind das, was das Geschäft spürt. Genauigkeit ist die Eingabe; weniger Verschwendung und weniger Fehlbestände sind die Ausgabe. Eine Plattform, die das Erste optimiert und das Zweite ignoriert, ist ein Wissenschaftsprojekt.
05Das Dashboard, das jemand um 8 Uhr morgens prüft
Die Vorhersage wird von einer Küchenleiterin zu Schichtbeginn konsumiert, auf einem Tablet, mit Kaffee, in neunzig Sekunden. Diese Einschränkung prägte mehr Entscheidungen als die Modellarchitektur.
Sie bedeutete, dass die Antwort eine Menge sein musste, keine Wahrscheinlichkeitsverteilung. Sie bedeutete, dass «Ich bin anderer Meinung, hier ist warum» ein Antippen sein musste. Sie bedeutete, dass der Bildschirm die gestrige Vorhersage gegenüber dem, was tatsächlich passiert ist zeigen musste, denn Vertrauen verdient man, indem man sichtbar rechenschaftspflichtig ist, nicht indem man selbstbewusst ist. Ein Modell, das der Person, die sich darauf verlässt, seine Erfolgsbilanz nicht zeigen kann, wird innerhalb einer Woche still ignoriert.
Nicht der F1-Score. Nicht der RMSE. Der Akzeptanztest war eine Küchenleiterin in Woche zwei, die sagte: «Ja, ich mache jetzt einfach, was es sagt.» Dieser Satz ist mehr wert als jede Offline-Metrik, und man verdient ihn nur, indem man die letzten neunzig Sekunden so sorgfältig entwirft wie das Modell.
06Notizen an unsere früheren Selbste
Wenn Sie kurz davor sind, etwas in dieser Form zu beginnen, hier ist, was wir dem Team sagen würden, das vor achtzehn Monaten anfing:
- Budgetieren Sie die Hülle, nicht das Modell. Nehmen Sie an, das Modell sei 15% des Aufwands, und planen Sie die anderen 85% bewusst. Die Teams, die Deadlines verpassen, sind die, die das Umgekehrte budgetiert haben.
- Schreiben Sie zuerst den Datenvertrag. Vor einem einzigen Feature. Er wird ein Leck in Ihrem Backtest aufdecken und Sie davor bewahren, eine Zahl auszuliefern, die Sie nicht verteidigen können.
- Liefern Sie Monitoring vor UI aus. Man kann nicht betreiben, was man nicht sehen kann, und eine falsche Vorhersage, die niemand bemerkt hat, ist der Versagensmodus, der Verträge kostet.
- Entwerfen Sie das Override. Menschen werden immer Dinge wissen, die das Modell nicht weiss. Geben Sie ihnen einen sanktionierten Hebel und lernen Sie daraus, sonst umgehen sie das ganze System in einer Tabelle.
- Machen Sie das Modell auf dem Bildschirm rechenschaftspflichtig. Zeigen Sie seine Historie neben seiner Vorhersage. Vertrauen ist ebenso eine UI-Entscheidung wie eine mathematische.
Das maschinelle Lernen war der einfache Teil. Wir sagen das nicht, um das Modell zu schmälern — es ist wirklich gut — sondern um darauf zu deuten, wo die Schwierigkeit tatsächlich liegt. Der Hype-Zyklus verkauft die drei Wochen. Die fünf Monate sind das, wofür Sie ein Engineering-Team wirklich bezahlen.
