Ein Frischwaren-Betreiber kam mit einer sauberen Frage zu uns: Könnt ihr die Nachfrage von morgen vorhersagen — pro Gericht, pro Standort, genau genug, dass wir aufhören, Marge in den Abfall zu kippen, und aufhören, mittags leer dazustehen? Achtzehn Monate später prognostiziert die Plattform in Produktion mit 98% Genauigkeit. Man nimmt an, der harte Teil sei das Machine Learning gewesen. War er nicht.
Das Modell, das die Vorhersagen macht, ist ein Gradient-Boosting-Regressor mit ein paar angeschraubten Saisonalitäts-Features. Eine kompetente Data Scientistin stellt so etwas an einem Nachmittag hin. Wir hatten binnen drei Wochen eine respektable erste Version — genau genug im Backtest, dass alle im Raum nickten.
Dann verbrachten wir fünf Monate damit, alles zu bauen, was aus «einem genauen Backtest» «eine Zahl, auf die eine Betriebsleiterin ihren Tag verwettet» macht. Diese Lücke ist der ganze Job — und fast niemand schreibt darüber, weil sie unglamourös ist. Also hier.
Das Drei-Wochen-Modell
Nachfrageprognose für ein stabiles, gut dokumentiertes Geschäft ist, offen gesagt, ein gelöstes Problem. Man hat ein Ziel (verkaufte Einheiten), einen Kalender und einen Stapel historischer Zeilen. Man baut ein paar Dutzend Features — Wochentag, Lag-Fenster, gleitende Mittel, Feiertage, ein Wetter-Join — und lässt eine Boosting-Bibliothek die Wechselwirkungen finden. An der Mathematik sterben Projekte nicht.
Was uns die drei Wochen tatsächlich kauften, war die Gewissheit, dass das Signal überhaupt existiert. Der Backtest sagte: Die Nachfrage ist bei sauberen Eingaben auf wenige Prozentpunkte vorhersagbar. Das ist das grüne Licht. Es ist nicht das Produkt.
Die Falle:
Eine gute Backtest-Zahl ist das gefährlichste Artefakt im Machine Learning. Sie sieht aus wie die Ziellinie und ist kaum der Startschuss. Backtests laufen auf Daten, die ein Mensch bereinigt, verknüpft und zeitlich ausgerichtet hat — ein Mensch, der die Antwort schon kennt. Die Produktion hat keinen dieser Luxusposten.
Wohin die fünf Monate gingen
Hier die ehrliche Abrechnung der nächsten fünf Monate. Nichts davon ist Modellierung. Alles davon ist, was das Modell benutzbar machte.
- Ingestion, die die Realität überlebt. Verkaufs-Feeds kommen zu spät, doppelt oder gar nicht. Eine Kasse startet neu und spielt gestern noch einmal ein. Wir bauten idempotente Ingestion, die sich gefahrlos wiederholen lässt und Zeilen, denen sie nicht traut, in Quarantäne stellt, statt den Trainingsbestand zu vergiften.
- Ein Feature Store mit Gedächtnis. Die Features, auf denen das Modell trainiert, müssen zur Vorhersagezeit berechenbar sein — nur mit den Daten, die man dann tatsächlich hätte. Kein Blick in die Zukunft. Diese Punkt-in-der-Zeit-Korrektheit durchzusetzen war Wochen Arbeit und fing zwei Lecks, die den ursprünglichen Backtest aufgebläht hatten.
- Backfill und Replay. War die Historie eines Standorts falsch, mussten wir jede nachgelagerte Prognose dieses Standorts neu bauen, ohne das Live-System anzuhalten. Replay ist Rohrleitungsbau, den niemand vorführt und jeder braucht.
- Monitoring vor Features. Wir lieferten Drift- und Frische-Alarme aus, bevor die halbe Oberfläche stand. Eine still falsche Prognose ist schlimmer als eine sichtbar fehlende.
- Das menschliche Übersteuern. Ein neuer Standort öffnet, ein Fest landet, eine Strasse ist gesperrt. Das Modell kann es nicht wissen. Die Planer brauchten einen sanktionierten Weg, die Zahl anzustupsen — und das System musste aus dem Anstupsen lernen.
Das Modell beantwortet eine Frage. Die Plattform entscheidet, welche Frage, mit welchen Daten, für wen — und was passiert, wenn die Antwort falsch ist.
— Darüber, warum die Hülle die Arbeit ist
Der Datenvertrag
Das eine Ding mit dem grössten Hebel, das wir bauten, war keine Modellverbesserung. Es war ein Datenvertrag: ein explizites, validiertes Schema zwischen jeder vorgelagerten Quelle und unserer Pipeline. Spaltentypen, erlaubte Bereiche, Frische-Fenster, Null-Richtlinien — alles deklariert, alles an der Tür geprüft.
Vor dem Vertrag konnte eine Prognose still degradieren, weil ein Kassen-Anbieter ein Währungsfeld von Rappen auf Franken umstellte und niemand uns informierte. Nach dem Vertrag wird diese Änderung an der Ingestion abgewiesen — mit einem benannten, alarmierten Fehler — und die letzte gute Prognose bleibt auf dem Bildschirm statt einer selbstbewusst falschen neuen.
contract · sales_daily
# every source is validated at the door, not after it poisons training
sales_daily:
units: int >= 0 # reject negatives — refunds go elsewhere
revenue: decimal(10,2) # cents → flagged in v3, now enforced
site_id: fk(sites) # unknown site → quarantine, page on-call
recorded_at: freshness <= 6h # stale feed → hold last good forecast
on_violation: quarantine + alert # never: silently train on it
Das ist das unsexy Herz jedes Produktions-ML-Systems, das wir je ausgeliefert haben. Das Modell ist eine Funktion; der Vertrag garantiert, dass die Funktion die Eingaben bekommt, für die sie trainiert wurde. Lassen Sie ihn weg, haben Sie keine Prognoseplattform — sondern einen sehr teuren Zufallszahlengenerator, der meistens richtig liegt.
Drift ist ein Feature, kein Versagen
Jedes Modell zerfällt. Geschmäcker verschieben sich, eine neue Karte landet, ein Wettbewerber öffnet gegenüber. Die Frage war nie, ob die Welt sich unter Ihrem Modell wegbewegt — sondern ob Sie es aus einem Dashboard erfahren oder aus einem wütenden Anruf.
Wir behandeln Drift-Erkennung als vollwertiges Produktfeature. Die Plattform vergleicht kontinuierlich Live-Eingabeverteilungen und Live-Fehler mit den Trainings-Basislinien. Überschreitet eines eine Schwelle, tut sie drei Dinge, in dieser Reihenfolge:
- Sie sagt es jemandem — einem konkreten Menschen, mit Standort, Kennzahl und dem Ausmass der Bewegung.
- Sie schützt die Ausgabe — weitet Konfidenzbänder oder fällt auf eine einfachere, robustere Basislinie zurück, statt einem Modell zu trauen, das jetzt extrapoliert.
- Sie plant ein Retraining — mit den neuen Daten, hinter derselben Backtest-Messlatte, die das Original nehmen musste.
Prognosegenauigkeit —
In der Produktion gehalten, nicht nur im Backtest.
Ausverkäufe —
Leere Kühlschränke am Mittag, mehr als halbiert.
Überbestand —
Marge, die früher am Tagesende im Abfall landete.
Beachten Sie: Die Schlagzeilenzahl — 98% — ist nicht die interessante. Die interessanten Zahlen sind die zwei daneben, denn die spürt das Geschäft. Genauigkeit ist die Eingabe; weniger Abfall und weniger Ausverkäufe sind die Ausgabe. Eine Plattform, die das Erste optimiert und das Zweite ignoriert, ist ein Wissenschaftsprojekt.
Das Dashboard, das jemand um 8 Uhr prüft
Die Prognose konsumiert eine Küchenleiterin zu Schichtbeginn, auf einem Tablet, mit Kaffee, in neunzig Sekunden. Diese Randbedingung hat mehr Entscheidungen geprägt als die Modellarchitektur.
Sie hiess: Die Antwort musste eine Menge sein, keine Wahrscheinlichkeitsverteilung. Sie hiess: «Ich widerspreche, und zwar deshalb» musste ein Tipp sein. Sie hiess: Der Bildschirm musste die Prognose von gestern neben dem tatsächlichen Ergebnis zeigen — denn Vertrauen verdient man durch sichtbare Rechenschaft, nicht durch Zuversicht. Ein Modell, das der Person, die sich darauf verlässt, seine Bilanz nicht zeigen kann, wird binnen einer Woche still ignoriert.
Der echte Abnahmetest:
Nicht der F1-Score. Nicht der RMSE. Der Abnahmetest war eine Küchenleiterin in Woche zwei, die sagte: «Ja, ich nehme jetzt einfach, was es sagt.» Dieser Satz ist mehr wert als jede Offline-Metrik — und man verdient ihn nur, wenn man die letzten neunzig Sekunden so sorgfältig entwirft wie das Modell.
Notizen an unser früheres Ich
Wenn Sie etwas in dieser Form beginnen, ist das, was wir dem Team von vor achtzehn Monaten sagen würden:
- Budgetieren Sie die Hülle, nicht das Modell. Nehmen Sie an, das Modell ist 15% des Aufwands, und planen Sie die anderen 85% bewusst. Die Teams, die Termine reissen, sind die, die es umgekehrt budgetiert haben.
- Schreiben Sie den Datenvertrag zuerst. Vor dem ersten 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 der Oberfläche. Was man nicht sehen kann, kann man nicht betreiben — und eine falsche Prognose, die niemand bemerkte, ist der Fehlermodus, der Verträge kostet.
- Entwerfen Sie das Übersteuern. Menschen werden immer Dinge wissen, die das Modell nicht wissen kann. 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 eine UI-Entscheidung, so sehr wie eine mathematische.
Das Machine Learning war der einfache Teil. Wir sagen das nicht, um das Modell kleinzureden — es ist genuin gut —, sondern um dorthin zu zeigen, wo die Schwierigkeit wirklich wohnt. Der Hype-Zyklus verkauft die drei Wochen. Die fünf Monate sind, wofür man ein Engineering-Team wirklich bezahlt.
Die fünf Monate sind der Teil, für den es uns gibt — Datenleitungen, Evals, das unglamouröse Engineering um ein gutes Modell herum. Sagen Sie uns, wo Ihr Pilot feststeckt.
