Neuronale Netzwerk-Architektur

Eaternity Forecast verwendet ein fortschrittliches transformerbasiertes neuronales Netzwerk mit Aufmerksamkeitsmechanismen zur Prognose des taeglichen Bedarfs fuer Restaurant-Menuepunkte. Dieses Dokument erklaert die technische Architektur und KI-Methodik.

Architektur-Ueberblick

Modelltyp: Transformer-Architektur

Forecast verwendet eine Transformer-Architektur, dieselbe grundlegende Technologie hinter modernen Sprachmodellen wie GPT und BERT, speziell angepasst fuer Zeitreihen-Bedarfsprognosen.

Warum Transformer fuer Bedarfsprognosen?

Traditionelle Prognosemethoden (ARIMA, exponentielle Glaettung) haben Schwierigkeiten mit:

• Komplexen Mehrfaktorbeziehungen
• Langreichweitigen zeitlichen Abhaengigkeiten
• Nicht-stationaeren Mustern
• Mehreren gleichzeitigen saisonalen Zyklen

Transformer zeichnen sich aus durch:

• Mustererkennung ueber verschiedene Zeitskalen (taeglich, woechentlich, saisonal)
• Aufmerksamkeitsmechanismen, die relevante historische Perioden identifizieren
• Mehrfaktorintegration (Wetter, Ereignisse, Menueaenderungen)
• Behandlung unregelmaessiger Muster (Feiertage, besondere Ereignisse)

Kernkomponenten

Eingabeschicht
    ↓
Temporale Einbettung
    ↓
Multi-Head Attention (×4 Schichten)
    ↓
Feed-Forward-Netzwerke
    ↓
Ausgabeprojektion
    ↓
Prognose + Konfidenzintervalle

Detaillierte Architektur

1. Eingabeschicht

Zweck: Rohdaten der Verkaeufe und externe Faktoren in numerische Darstellungen transformieren

Eingabemerkmale (pro Artikel, pro Tag):

Historische Verkaufsmerkmale

• Verkaeufe der letzten 7 Tage (taegliche Mengen)
• Verkaeufe der letzten 4 Wochen am gleichen Wochentag
• Durchschnittliche Verkaeufe des letzten Monats
• Verkaeufe am gleichen Datum im Vorjahr (falls verfuegbar)

Zeitliche Merkmale

• Wochentag (One-Hot-kodiert: Montag=1, Dienstag=2, usw.)
• Kalenderwoche (1-52)
• Monat (1-12)
• Ist Wochenende (binaer: 0/1)
• Ist Feiertag (binaer: 0/1)

Externe Merkmale

• Temperatur (°C, normalisiert)
• Niederschlag (mm, normalisiert)
• Wettervorhersage fuer den naechsten Tag
• Lokale Ereignisse (binaere Flags oder kategorisch)

Menue-Merkmale

• Artikelkategorie (Vorspeise, Hauptgang, Dessert, usw.)
• Preispunkt (normalisiert)
• Tage seit Artikeleinfuehrung (fuer neue Artikel)
• Artikelverfuegbarkeit (binaer: 0/1)

Beispiel Feature Engineering:

Eingabevektor fuer "Pasta Carbonara" am Mittwoch, 20. Januar 2024:

Historische Verkaeufe:
  [52, 48, 45, 51, 49, 0, 0]  # Letzte 7 Tage (0 = geschlossen)
  [49, 51, 48, 52]             # Letzte 4 Mittwoche
  47.3                          # Durchschnitt letzter Monat

Zeitlich:
  [0, 0, 1, 0, 0, 0, 0]        # Wochentag (Mi = Position 3)
  3                             # Kalenderwoche
  1                             # Monat (Januar)
  0                             # Ist Wochenende
  0                             # Ist Feiertag

Extern:
  8.2                           # Temperatur (°C)
  0.0                           # Niederschlag
  7.5                           # Prognosetemperatur morgen

Menue:
  [0, 1, 0, 0]                 # Kategorie (Hauptgang)
  14.50                         # Preis (normalisiert auf 0-1 Skala)
  450                           # Tage seit Einfuehrung
  1                             # Heute verfuegbar

2. Temporale Einbettung

Zweck: Zeitbasierte Muster und zyklische Beziehungen kodieren

Positionskodierung:

Verwendet sinusfoermige Funktionen zur Erfassung periodischer Muster:

PE(pos, 2i) = sin(pos / 10000^(2i/d_model))
PE(pos, 2i+1) = cos(pos / 10000^(2i/d_model))

Wobei:

• pos = Position in der Sequenz (Tagesnummer)
• i = Dimension
• d_model = Einbettungsdimension (256)

Warum sinusfoermige Kodierung?

• Erfasst mehrere Zyklen (taeglich, woechentlich, monatlich, jaehrlich)
• Modell lernt, welche Zyklen fuer jeden Artikel relevant sind
• Ermoeglicht Extrapolation ueber den Trainingszeitraum hinaus
• Behandelt unregelmaessige Abstands (Feiertage, geschlossene Tage)

Beispiel:

# Woechentliche Zykluskodierung fuer Wochentag
weekly_encoding = [
    sin(day_of_week / 7 * 2π),
    cos(day_of_week / 7 * 2π)
]

# Jaehrliche Zykluskodierung
annual_encoding = [
    sin(day_of_year / 365 * 2π),
    cos(day_of_year / 365 * 2π)
]

3. Multi-Head-Aufmerksamkeitsmechanismus

Zweck: Identifizieren, welche historischen Perioden fuer die aktuelle Prognose am relevantesten sind

Wie Aufmerksamkeit funktioniert:

Das Modell fragt: "Bei der Prognose fuer Mittwoch Mittag, auf welche vorherigen Tage soll ich achten?"

Aufmerksamkeitsformel:

Attention(Q, K, V) = softmax(QK^T / √d_k) V

Wobei:

• Q (Query): Was wir prognostizieren wollen (heutiger Bedarf)
• K (Keys): Zu beruecksichtigende historische Tage
• V (Values): Tatsaechliche Verkaeufe dieser Tage
• d_k: Dimension der Key-Vektoren

Multi-Head-Ansatz:

Statt eines Aufmerksamkeitsmechanismus verwenden wir 8 parallele Aufmerksamkeitskoepfe:

1. Kopf 1: Fokussiert auf Muster des gleichen Wochentags

   • "Mittwoche sind aehnlich zu vorherigen Mittwochen"

2. Kopf 2: Fokussiert auf aktuelle Trends

   • "Das Muster der letzten Woche setzt sich fort"

3. Kopf 3: Fokussiert auf saisonale Muster

   • "Aehnlich wie zu dieser Zeit letztes Jahr"

4. Kopf 4: Fokussiert auf Wetterkorrelationen

   • "Kalte Tage wie heute haben aehnlichen Bedarf"

5. Kopf 5: Fokussiert auf Ereignismuster

   • "Tage mit aehnlichen Ereignissen in der Naehe"

6. Kopf 6: Fokussiert auf Menuedynamik

   • "Tage mit aehnlicher Menuezusammensetzung"

7. Kopf 7: Fokussiert auf Preissensitivitaet

   • "Tage mit aehnlichen Preisstrategien"

8. Kopf 8: Fokussiert auf langfristige Trends

   • "Mehrmonatige Trendrichtung"

Beispiel Aufmerksamkeitsgewichte:

Prognose fuer Mittwoch, 20. Januar 2024 fuer Pasta Carbonara:

Kopf 1 (Wochentag) Aufmerksamkeit auf vorherige Mittwoche:
  13. Jan (letzter Mi):    0.35  (aktuellster, hoechstes Gewicht)
  6. Jan:                  0.28
  30. Dez:                 0.18
  23. Dez:                 0.12
  Andere Mittwoche:        0.07

Kopf 2 (aktueller Trend) Aufmerksamkeit auf letzte 7 Tage:
  19. Jan (gestern):       0.42
  18. Jan:                 0.24
  17. Jan:                 0.15
  16. Jan:                 0.10
  Aeltere:                 0.09

Kopf 3 (saisonal) Aufmerksamkeit auf letztes Jahr:
  21. Jan 2023:            0.55  (gleiches Datum letztes Jahr)
  14.-28. Jan 2023:        0.45  (umliegende Daten)

4. Feed-Forward-Netzwerke

Zweck: Nichtlineare Transformation und Merkmalskombination

Architektur:

Eingabe (256 Dimensionen)
    ↓
Lineare Schicht 1 (256 → 1024)
    ↓
ReLU-Aktivierung
    ↓
Dropout (0.1)
    ↓
Lineare Schicht 2 (1024 → 256)
    ↓
Dropout (0.1)
    ↓
Residualverbindung + Layer-Normalisierung

Warum zwei Schichten?

• Erweiterung (256→1024): Erzeugt hochdimensionalen Darstellungsraum
• Komprimierung (1024→256): Extrahiert relevanteste Merkmale

Dropout-Regularisierung:

Deaktiviert waehrend des Trainings zufaellig 10% der Neuronen, um Ueberanpassung zu verhindern:

• Modell lernt robuste Muster, keine Auswendiglernerei
• Verbessert Generalisierung auf neue Daten
• Kritisch fuer kleine Datensaetze (einige Restaurants, neue Artikel)

5. Schichtenstapelung

Vier Transformer-Bloecke sequentiell gestapelt:

Block 1: Erste Mustererkennung
    ↓
Block 2: Verfeinerte Musterextraktion
    ↓
Block 3: Hochrangiges Merkmalslernen
    ↓
Block 4: Finale Darstellung

Jeder Block enthaelt:

• Multi-Head-Aufmerksamkeitsschicht
• Layer-Normalisierung
• Feed-Forward-Netzwerk
• Residualverbindungen

Warum vier Schichten?

Balance zwischen:

• Komplexitaet: Mehr Schichten = mehr erkannte Muster
• Effizienz: Weniger Schichten = schnelleres Training und Inferenz
• Ueberanpassungsrisiko: Zu viele Schichten = Auswendiglernen statt echtem Lernen

Empirische Tests zeigten 4 Schichten als optimal fuer Restaurantbedarfsprognosen.

6. Ausgabeprojektion

Zweck: Gelernte Darstellung in Mengenprognose umwandeln

Quantil-Regressionsansatz:

Statt eines einzelnen Wertes gibt das Modell drei Quantile aus:

Lineare Schicht (256 → 3)
    ↓
Ausgaben:
  - 10. Perzentil (untere Grenze)
  - 50. Perzentil (Median/Punktschaetzung)
  - 90. Perzentil (obere Grenze)

Beispielausgabe:

{
  "item": "Pasta Carbonara",
  "date": "2024-01-20",
  "predictions": {
    "lower_bound": 45,      // 10. Perzentil
    "point_estimate": 52,   // 50. Perzentil (Median)
    "upper_bound": 59       // 90. Perzentil
  }
}

Warum Quantil-Regression?

• Erfasst Prognoseunsicherheit auf natuerliche Weise
• Liefert handlungsrelevante Konfidenzintervalle
• Robuster gegenueber Ausreissern als varianzbasierte Ansaetze
• Entspricht Entscheidungsbedarf (fuer Bereich vorbereiten, nicht einzelnen Wert)

Trainingsprozess

Datenvorbereitung

1. Datensammlung

Mindestanforderungen:

• 30 Tage historische Verkaufsdaten (90+ Tage empfohlen)
• Vollstaendige taegliche Aufzeichnungen (keine Luecken)
• Mengen auf Artikelebene

2. Datenvorverarbeitung

Normalisierung:

# Z-Score-Normalisierung fuer Mengen
normalized_quantity = (quantity - mean) / std_dev

# Min-Max-Normalisierung fuer externe Merkmale
normalized_temp = (temp - min_temp) / (max_temp - min_temp)

Behandlung fehlender Werte:

• Geschlossene Tage: Explizit markiert (nicht imputiert)
• Fehlende Verkaeufe: Forward-Fill bei weniger als 3 aufeinanderfolgenden Tagen
• Wetterdaten: Interpolation von nahen Stationen

Ausreissererkennung:

# Ausreisser identifizieren und markieren (aber nicht entfernen)
z_score = (quantity - rolling_mean) / rolling_std
if abs(z_score) > 3:
    flag_as_potential_outlier()

Ausreisser werden beibehalten, aber waehrend des Trainings geringer gewichtet.

3. Sequenzgenerierung

Eingabesequenzen verschiedener Laengen erstellen:

Kurzer Kontext (letzte 7 Tage):

[Tag-7, Tag-6, Tag-5, Tag-4, Tag-3, Tag-2, Tag-1] → [Prognose: Tag-0]

Mittlerer Kontext (letzte 4 Wochen):

[Woche-4-gleicher-Tag, Woche-3-gleicher-Tag, Woche-2-gleicher-Tag, Woche-1-gleicher-Tag] → [Prognose: heute]

Langer Kontext (saisonal):

[Monat-12-gleiches-Datum, Monat-6-gleiches-Datum, Monat-3-gleiches-Datum] → [Prognose: heute]

Trainingsalgorithmus

Verlustfunktion: Quantil-Verlust

Fuer jedes Quantil q (0.1, 0.5, 0.9):

L_q = (q - 1) * error  wenn error < 0  (Unterprognose)
      q * error        wenn error ≥ 0  (Ueberprognose)

Gesamtverlust = L_0.1 + L_0.5 + L_0.9

Warum dieser Verlust?

• Bestraft Unterprognose staerker fuer oberes Quantil (90.)
• Bestraft Ueberprognose staerker fuer unteres Quantil (10.)
• Ausgewogen fuer Median (50.)
• Stellt korrekte Quantilreihenfolge sicher (untere < Median < obere)

Optimierung

Optimierer: AdamW (Adam mit Gewichtsabnahme)

Hyperparameter:

learning_rate = 0.001       # Anfaengliche Lernrate
weight_decay = 0.01         # L2-Regularisierung
beta_1 = 0.9               # Momentum
beta_2 = 0.999             # Adaptive Lernrate
epsilon = 1e-8             # Numerische Stabilitaet

Lernratenplan: Kosinus-Annealing mit Aufwaermphase

# Aufwaermphase (erste 10% des Trainings)
lr = initial_lr * (step / warmup_steps)

# Kosinus-Annealing-Phase
lr = min_lr + 0.5 * (max_lr - min_lr) * (1 + cos(π * step / total_steps))

Vorteile:

• Schrittweises Aufwaermen verhindert fruehe Divergenz
• Kosinus-Abnahme ermoeglicht Feinabstimmung gegen Ende
• Mehrere Zyklen ermoeglichen das Entkommen aus lokalen Minima

Trainingsiterationen

Epochen: 100-200 je nach Datenmenge

Batch-Groesse: 32 Sequenzen

Validierungsaufteilung: 20% der Daten zurueckgehalten

Fruehes Stoppen:

if validation_loss_not_improved_for(patience=15_epochs):
    stop_training()
    restore_best_model()

Regularisierungstechniken

1. Dropout

• Aufmerksamkeits-Dropout: 0.1
• Feed-Forward-Dropout: 0.1
• Einbettungs-Dropout: 0.05

2. Gewichtsabnahme

• L2-Strafe auf Gewichte: 0.01
• Verhindert zu grosses Wachstum der Gewichte

3. Label Smoothing

• Leichtes Verwischen der Zielwerte
• Verbessert Kalibrierung der Konfidenzintervalle

4. Datenaugmentation

• Zufaelliges Jittern historischer Werte (±5%)
• Simuliert Messunsicherheit
• Verbessert Robustheit

Validierung und Testen

Training/Validierung/Test-Aufteilung

Historische Daten (180 Tage gesamt):
  - Training: Tage 1-126 (70%)
  - Validierung: Tage 127-162 (20%)
  - Test: Tage 163-180 (10%)

Walk-Forward-Validierung:

Statt zufaelliger Aufteilung, zeitliche Aufteilung verwenden:

• Nur auf vergangenen Daten trainieren
• Auf zukuenftigen Daten validieren
• Verhindert Datenleckage (Zukunft zur Vorhersage der Vergangenheit nutzen)

Leistungsmetriken

Mittlerer absoluter prozentualer Fehler (MAPE):

MAPE = (1/n) * Σ |ist - prognostiziert| / ist * 100%

Kalibrierungswert:

Erwartet: 80% der Istwerte innerhalb des Konfidenzintervalls
Tatsaechlich: Zaehlen, wie viele Istwerte in [untere, obere] fallen
Kalibrierung = Tatsaechliche Abdeckung / Erwartete Abdeckung

Quantil-Verlust:

QL = Σ alle Quantile (Quantilverlust wie oben definiert)

Inferenzprozess

Taegliche Prognosegenerierung

Zeitplan: Laeuft automatisch um 3:00 Uhr Ortszeit

Prozess:

1. Datensammlung (3:00-3:05 Uhr)

   • Gestrige endgueltige Verkaufsdaten abrufen
   • Wettervorhersage fuer naechste 7 Tage abrufen
   • Veranstaltungskalender fuer kommende Daten pruefen
   • Aktuelle Menuekonfiguration laden

2. Feature Engineering (3:05-3:10 Uhr)

   • Gleitende Durchschnitte und Trends berechnen
   • Zeitliche Merkmale kodieren
   • Externe Variablen normalisieren
   • Eingabesequenzen erstellen

3. Modellinferenz (3:10-3:15 Uhr)

   • Forward-Pass durch neuronales Netzwerk
   • Prognosen fuer naechste 7 Tage generieren
   • Konfidenzintervalle berechnen
   • Genauigkeitsmetriken berechnen

4. Nachbearbeitung (3:15-3:20 Uhr)

   • Prognosen auf ganze Zahlen runden
   • Geschaeftsregeln anwenden (Minimum=0, Maximum=Kapazitaet)
   • Ungewoehnliche Prognosen zur Ueberpruefung markieren
   • Genauigkeitsberichte generieren

5. Auslieferung (3:20-3:25 Uhr)

   • An API-Endpunkte pushen
   • Dashboard-Oberflaeche aktualisieren
   • E-Mail-Benachrichtigungen senden (falls konfiguriert)
   • Prognosen zur Nachverfolgung protokollieren

Latenz: weniger als 5 Minuten fuer typisches Restaurant (100 Menuepunkte)

Kontinuierliches Lernen

Wie sich das Modell ueber die Zeit verbessert:

Woechentliches Neutraining

Jeden Montag um 4:00 Uhr:

1. Verkaeufe der Vorwoche einbeziehen
2. Modell mit aktualisierten Daten neu trainieren
3. Leistungsverbesserungen bewerten
4. Aktualisiertes Modell bereitstellen, wenn Genauigkeit verbessert

Feedback-Integration

Benutzermeldungen zu Abweichungen fliessen ins Training zurueck:

• Spezielle Ereignisse manuell markiert
• Ungewoehnliche Umstaende dokumentiert
• Ueberschreibungsgruende analysiert
• Feature Engineering verbessert

Konzeptdrift-Erkennung

Ueberwachung auf Aenderungen in Bedarfsmustern:

if recent_accuracy < historical_accuracy - threshold:
    trigger_model_refresh()
    investigate_potential_concept_drift()

Haeufige Ursachen:

• Menueaenderungen
• Neue Konkurrenz
• Saisonale Uebergaenge
• Betriebliche Aenderungen

Erweiterte Funktionen

Mehrartikel-Korrelation

Cross-Item-Aufmerksamkeit:

Modell lernt Beziehungen zwischen Artikeln:

• Substitutionseffekte: "Wenn Lachs beliebt ist, sinkt Salatbedarf"
• Komplementaereffekte: "Dessertverkaeufe korrelieren mit Hauptgang-Volumen"
• Menuegestaltung: "Spezialangebote kannibalisieren regulaere Artikel"

Implementierung:

# Aufmerksamkeit nicht nur auf eigene Historie, sondern auch verwandte Artikel
attention_context = [
    item_own_history,
    substitute_items_history,
    complement_items_history,
    category_average_history
]

Ensemble-Prognosen

Mehrere Modellvarianten:

Mehrere Modelle mit unterschiedlichen Architekturen trainieren:

• Modell A: Transformer (primaer)
• Modell B: LSTM (rekurrente Basislinie)
• Modell C: Gradient Boosting (baumbasiert)

Gewichtete Kombination:

final_prediction = (
    0.70 * transformer_prediction +
    0.20 * lstm_prediction +
    0.10 * gbm_prediction
)

Gewichte durch historische Genauigkeit bestimmt.

Unsicherheitsquantifizierung

Quellen der Unsicherheit:

1. Aleatorisch (irreduzible Zufaelligkeit)

   • Gaesteverhalten inhaerent unvorhersehbar
   • Zufaellige Ereignisse (Wetterschwankungen)

2. Epistemisch (Modellunsicherheit)

   • Ungenuegend Trainingsdaten
   • Modellkapazitaetsbeschraenkungen
   • Neue Szenarien nicht im Trainingssatz

Konfidenz-Scoring:

confidence_score = f(
    data_quality,           # Wie sauber sind historische Daten?
    training_data_volume,   # Wie viele Daten verfuegbar?
    similarity_to_training, # Wie aehnlich ist Prognosetag zu Trainingstagen?
    model_agreement         # Stimmen Ensemble-Modelle ueberein?
)

Hoehere Konfidenz → engere Intervalle Niedrigere Konfidenz → weitere Intervalle

Transfer Learning

Standortuebergreifendes Lernen:

Fuer Restaurantketten:

• Auf Daten aller Standorte vortrainieren
• Auf Daten des einzelnen Standorts feinabstimmen
• Muster uebertragen (saisonal, Wetter, Ereignisse)
• Schnellerer Anlauf fuer neue Standorte

Vorteile:

• Prognosen fuer neue Standorte sofort verfuegbar
• Hoehere Anfangsgenauigkeit
• Schnellere Modellkonvergenz
• Gemeinsames Lernen in der gesamten Organisation

Modellleistung

Benchmarks

Genauigkeit vs. Basislinien:

Methode	MAPE	Anmerkungen
Eaternity Forecast	12,8%	Transformer-Architektur
Menschlicher Experten-Prognostiker	17,1%	25% weniger genau
Vorwoche gleicher Tag	22,4%	Naive Basislinie
4-Wochen-Durchschnitt	19,7%	Einfache statistische Basislinie
ARIMA	16,2%	Traditionelle Zeitreihe
LSTM	14,1%	Rekurrentes neuronales Netzwerk

Konfidenzintervall-Kalibrierung:

Erwartet: 80% der Istwerte innerhalb [untere, obere] Erreicht: 78,5% (gut kalibriert)

Rechenanforderungen

Training:

• GPU: NVIDIA RTX 4090 oder vergleichbar
• RAM: Mindestens 32 GB
• Trainingszeit: 2-6 Stunden (abhaengig vom Datenvolumen)
• Speicher: 5-20 GB pro Restaurant

Inferenz:

• CPU: Ausreichend fuer Echtzeit-Prognosen
• RAM: 8 GB
• Latenz: weniger als 100ms pro Prognose
• Speicher: weniger als 1 GB fuer bereitgestelltes Modell

Forschungsgrundlage

Akademische Referenzen

Forecast basiert auf begutachteter Forschung:

1. Transformer-Architektur

   • Vaswani et al. (2017) "Attention Is All You Need"
   • Urspruengliche Transformer-Arbeit fuer NLP

2. Zeitreihenprognose

   • Zhou et al. (2021) "Informer: Beyond Efficient Transformer for Long Sequence Time-Series Forecasting"
   • Temporale Transformer fuer Prognosen

3. Bedarfsprognose

   • Taylor & Letham (2018) "Forecasting at Scale" (Facebook Prophet)
   • Industrietaugliche Prognosesysteme

4. Quantil-Regression

   • Koenker & Bassett (1978) "Regression Quantiles"
   • Grundlegende Quantil-Regressionstheorie

5. Restaurantbetrieb

   • Miller et al. (2015) "Forecasting Restaurant Demand"
   • Domaenenspezifische Prognose-Herausforderungen

Zukuenftige Verbesserungen

Entwicklungsplanung

Q2 2024: Aufmerksamkeitsvisualisierung

• Zeigen, auf welche historischen Tage das Modell fokussiert
• Prognosen fuer Benutzer erklaeren

Q3 2024: Rezeptbasierte Prognose

• Zutatenbedarf direkt prognostizieren
• Integration mit Lagersystemen

Q4 2024: Kausalinferenz

• Auswirkungen von Menueaenderungen vor Umsetzung verstehen
• Werbeaktionseffekte simulieren

2025: Multimodales Lernen

• Social-Media-Stimmung einbeziehen
• Visuelle Menueanalyse
• Gaestebewertungs-Sentiment

Siehe auch

• Leistungsstudie — Validierungsergebnisse und Benchmarks
• Prognose-Konfidenz — Unsicherheit verstehen
• Implementierungsleitfaden — Bewaehrte Methoden fuer die Nutzung
• API-Referenz — Technische Integrationsdetails