Modellevaluation ohne PII (Personally Identifiable Information)-Leakage (Modellevaluation Ohne Pii Leakage)

Modellevaluation ohne PII (Personally Identifiable Information)-Leakage

Offline eval sets use hashed vehicle ids and rounded coordinates so notebooks never become a privacy incident.

hashed ids · rounded geo · offline eval sets

Eval set ≠ production dump.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 OSRM
Open-Source Shortest-Path-Engine als empfohlene Routen-Baseline.

📦 Preferred Path
Tatsächlich gefahrene Route — aus Telemetrie rekonstruiert.

📦 Km Extension
Zusätzliche Kilometer der Preferred Path gegenüber OSRM.

📦 Wait Hotspot
Geocluster mit konzentrierten Warteereignissen.

Wer diese Schichten vermischt, erzeugt falsche Wahrheit in Analytics und auf der Karte.

Form des Problems

Offline eval sets use hashed vehicle ids and rounded coordinates so notebooks never become a privacy incident.

hashed ids · rounded geo · offline eval sets

Die Trennung, die trägt

Eval set ≠ production dump.

hashed ids · rounded geo · offline eval sets
        ↓
   explicit contract → frontend

Frontend-Brücke

Ops-Karten, Wait-Geofence-UI und MFEs konsumieren Read Models — nie rohes ERP/MySQL.

Die am häufigsten verwechselten Zuordnungen

❌ ERP-MySQL = Analytics-DB
✓ ERP ist Write-Store; Analytics lebt in PostGIS

❌ Karte vertraut blind public/Vendor-Routern
✓ Produktion braucht Ihre API/OSRM-Kante

❌ ML-Outputs mit PII loggen
✓ Eval und Serving achten Privacy

Checkliste zur Prüfung des eigenen Systems

1. Welcher Store ist Source of Truth?
2. Welchen API-Vertrag ruft das Frontend?
3. Was passiert bei Node-Verlust im Cluster?
4. Wie wird Lag dem Operator gezeigt?
5. Deny-list: Domain/Vendor-Leakage?

Was aus diesem Teil bleiben sollte

1. Polyglotte Stores dienen unterschiedlichen Lasten.
2. Frontends konsumieren saubere Read Models, nicht das ERP.
3. ML/OSRM braucht API-Vertrag vor der Karte.

Eine schöne Karte aus schmutziger Quelle bleibt eine Lüge.