Datenquellen: Wetter und Veranstaltungen
Die AI-Ops-Nachfrageprognose ist auf vier Datenquellen konditioniert. Drei sind extern; eine ist Ihre eigene Fahrthistorie. Diese Seite erklärt, was sie sind, wo sie liegen und was passiert, wenn eine davon nicht erreichbar ist.
Historische Fahrten
Die Grundlage der Prognose ist Ihre eigene rides-Tabelle. Genauer liest die Feature-Pipeline aus ride_events_ts, einer materialisierten View, die Fahrtstarts in H3-Hex × 1-Stunden-Buckets aggregiert.
- Training-Lookback ist mindestens 90 Tage, maximal 365 Tage.
- Ein Wochenlag-Feature (Fahrten in derselben Hex-Zelle vor 168 Stunden) erfasst die Wochentag-Saisonalität.
- Subaccount-Fixeffekte erlauben dem globalen Modell, sich an die Basismenge jedes Operators anzupassen.
Hat der Subaccount weniger als 14 Tage Fahrten, fällt das Modell auf eine globale "Stadt-Dichte-Stufen"-Baseline zurück. Das Empfehlungssystem bleibt verborgen, bis 30 Tage Historie verfügbar sind.
Wetter: Tomorrow.io
Wetter wird von Tomorrow.io bezogen. Wir haben uns für die hyperlokale Genauigkeit und den Preis in unserem Volumen entschieden.
Drei Features werden extrahiert:
temp_c— Temperatur in Celsiusprecip_prob— Niederschlagswahrscheinlichkeit (0,00 bis 1,00)wind_kph— Windgeschwindigkeit in km/h
Wetterbeobachtungen werden in der Tabelle weather_observations zwischengespeichert, geschlüsselt nach H3-Hex × Stunde. Der Cache wird über Subaccounts derselben Stadt geteilt, sodass wir nicht für doppelte Abrufe zahlen.
Wenn Tomorrow.io ausfällt
Der weather.ts-Client degradiert sanft auf einen Klimatologie-Stub, wenn TOMORROW_IO_API_KEY nicht gesetzt oder die API nicht erreichbar ist. Der Stub nutzt langjährige Durchschnitte nach Stunde-der-Woche.
Dauert der Ausfall länger als 2 Stunden, feuert eine Sentry-Warnung. Das Modell erzeugt während des Ausfalls weiterhin Prognosen, aber die Genauigkeit sinkt für Zellen, in denen Wetter das dominante Signal ist.
Veranstaltungen: PredictHQ
Lokale Veranstaltungen (Konzerte, Sport, Festivals) verschieben die Nachfrage erheblich. Wir beziehen sie von PredictHQ, das den Veranstaltungseinfluss pro Ort bewertet.
Für jede Hex × Stunde berechnet die Feature-Pipeline ein einzelnes event_count-Feature: die Anzahl der einflussreichen Veranstaltungen innerhalb der Zelle in dieser Stunde.
Wenn PredictHQ ausfällt
Der events.ts-Client fällt auf einen deterministischen, zyklischen Stub zurück, wenn PREDICTHQ_API_KEY nicht gesetzt ist oder die API fehlschlägt. Der Stub liefert event_count = 0 mit einer kleinen Wochentagsmodulation.
Während eines Veranstaltungs-API-Ausfalls erzeugte Empfehlungen werden in der Audit-Tabelle als "weather/events incomplete" gekennzeichnet, damit Sie wissen, dass das Modell mit degradierten Eingaben lief.
Feiertage
Eine handgepflegte holiday_calendar-Tabelle hält nationale Feiertage je Land. Phase 1 deckt ab:
- Vereinigte Staaten
- Kanada
- Vereinigtes Königreich
- Deutschland
- Mexiko
Märkte außerhalb dieser Länder fallen auf is-weekend zurück, was den Großteil des feiertagsähnlichen Effekts erfasst.
Um ein Land zu ergänzen, fügen Sie Zeilen in holiday_calendar mit Ländercode, Datum und Feiertagsnamen ein. Die Feature-Pipeline nimmt es beim nächsten Stundenlauf auf.
Modal (Inference-Engine)
Die trainierten LightGBM-Modelle leben auf Modal, einer Python-Runtime-Plattform. Das nächtliche Training:
- Holt alle
demand_features-Zeilen der letzten 90 Tage. - Trainiert drei Regressoren — einen pro Horizont (1h, 4h, 24h).
- Serialisiert sie als
forecast-{subaccount}-h{horizon}.txt-Artefakte. - Schreibt ein Manifest mit Modellversionen und Per-Subaccount-MAPE.
Die Inference wird als /predict-Web-Endpunkt bereitgestellt, den der Next.js-Inference-Cron per POST anruft.
Wenn Modal ausfällt
Die forecasting.ts-Bibliothek fällt auf einen reinen TypeScript-Gradient-Boosting-Regressor zurück, der bei jedem Inference-Aufruf in-process trainiert. Er ist langsamer (Subaccounts mit mehr als 5.000 Feature-Zeilen brauchen über eine Sekunde) und ungenauer, aber die Prognose-Pipeline läuft weiter. Modal-Absenz wird protokolliert, ist aber für Kunden nicht sichtbar.
Frische der Features
Jede Pipeline-Schicht schreibt einen Frische-Zeitstempel:
weather_observations.fetched_at— wann Tomorrow.io zuletzt abgefragt wurdedemand_features.feature_built_at— wann die Feature-Zeile zusammengebaut wurdedemand_forecasts.created_at— wann das Modell die Prognose schriebmodel_runs.completed_at— wann der letzte Training-Lauf endete
Ist einer dieser Werte um mehr als 90 Minuten veraltet, zeigt das Dashboard das Stale-Forecast-Banner (siehe Nachfragekarte).
Eine Prognose nachvollziehen
Um zu sehen, was eine bestimmte Prognose für eine bestimmte Hex × Stunde gespeist hat:
SELECT * FROM demand_features
WHERE subaccount_id = '<uuid>'
AND h3_index = <bigint>
AND bucket_start = '<zeitstempel>';
Verknüpfen Sie anschließend mit weather_observations und dem Veranstaltungs-Feature für denselben Schlüssel. Die Zeile hat auch eine model_version, die zu demand_forecasts.model_version passt, sodass Sie genau das trainierte Artefakt zurückverfolgen können, das die Prognose erzeugt hat.
Verwandt
- Nachfragekarte — wie die Daten gerendert werden.
- Fehlerbehebung — was bei einer degradierten Quelle zu tun ist.