Modellüberwachung

1) Warum

Ziel ist es, die Qualität und Sicherheit der Modelllösungen in der Produktion unter Einhaltung von SLA/SLO, RG/AML/Legal und Budgets zu erhalten. Die Überwachung muss frühzeitig Degradationen (Daten, Kalibrierung, Latenz, Kosten) erkennen, die erwarteten Fehlerkosten minimieren und Reproduzierbarkeit/Audit sicherstellen.

2) Überwachungsbereiche (Karte)

1. Verfügbarkeit und Leistung: Latenz p95/p99, Fehlerrate, RPS, Autoscale.
2. Qualität der Vorhersagen: PR-AUC/KS (auf Online-Labels), Kalibrierung (ECE), expected-cost @ threshold.
3. Drift und Stabilität: PSI/KL durch Fics und Score, Wechsel von Verteilungen/Kategorien.
4. Abdeckung und Vollständigkeit: Anteil erfolgreich bedienter Anfragen, Anteil „leerer“ Fitch, Hit-Rate-Caches.
5. Slice/Fairness: Metriken nach Märkten/Anbietern/Geräten/Alter des Kontos.
6. Guardrails (RG/AML): Richtlinienverstöße, Interventionshäufigkeiten, false positives/negatives.
7. Kosten: cost/request, cost/feature, GPU/CPU-Uhr, small-files/IO (für batch/near-RT).
8. Daten/Verträge: Schema, Versionen, Äquivalenz online/offline.

3) SLI/SLO (Benchmarks für iGaming)

Latency p95: Personalisierung ≤ 150 ms, RG/AML-Alert ≤ 5 mit e2e.
Availability: ≥ 99. 9%.
Error-rate 5xx: ≤ 0. 5% für 5 min Fenster.
Coverage: ≥ 99% der Anfragen erhielten eine gültige Skore und Lösung.
Freshness Labels für die Online-Bewertung: D + 1 (täglich), für schnelle Proxies - ≤ 1 Stunde.
Drift PSI: fichi/scor <0. 2 (warning с 0. 1).
ECE-Kalibrierung: ≤ 0 05.
Expected-cost_live: nicht höher als das Basismodell + X% (Ziel X wählt das Unternehmen).

4) Signale und Formeln

4. 1 Drift

PSI: Wir fassen die Unterschiede der Verteilungen (train vs prod) über die Bins zusammen.
KL-Divergenz: empfindlich gegenüber „dünnen“ Schwänzen; Überwachung für Schlüssel fich/score.
KS für Scores (wenn Labels vorhanden sind): CDF-Differenz für Positive/Negative.

4. 2 Kalibrierung

4. 3 Expected-Cost

Wir minimieren (C = c_{fp}\cdot FPR + c_{fn}\cdot FNR) an der Arbeitsschwelle; Online zählen im Schiebefenster mit verschobenen Labels.

5) Quellen der Etiketten

Online Labels (schnelle Proxies): „7 Tage Einzahlung“ Event, Klick/Conversion, RG Fall abgeschlossen.
Pending Labels: Chargeback/Betrug (45-90 Tage), Langzeit-Churn/LTV.
Regeln: Speichern Sie as-of Zeit; Verwenden Sie keine Ereignisse „aus der Zukunft“.

6) Dashboards (minimale Zusammensetzung)

1. Betrieb: RPS, p50/p95/p99 Latenz, 4xx/5xx, Sättigung, autoscaling.
2. Qualität: Score-Distribution, PR-AUC (auf Proxy-Labels), ECE, Expected-Cost, KS.
3. Drift: PSI/KL nach Top-Fics, novelty Kategorien, missing-rate, feature-fetch latency.
4. Slice/Fairness: PR-AUC/ECE/expected-cost nach Märkten/Anbietern/Geräten.
5. Guardrails: RG/AML Verstöße, Interventionen/1k Anfragen, False-Stop-Rate.
6. Kosten: Kosten/Anfrage, CPU/GPU-Zeit, Cache-Hit-Rate, externe Lookups.

7) Alerting (Beispielregeln)

HighP95Latency: p95> 150 ms (5 min) → Seite SRE/MLOps.
ErrorBurst: 5xx > 0. 5% (5 min) → Rollback-Skript verfügbar.
PSI_Drift: PSI(amount_base) > 0. 2 (15 min) → warm-up retrain/canary rollback.
ECE_Bad: ECE > 0. 07 (30 min) → Kalibrierung/Schwellen neu zusammenbauen.
ExpectedCost_Up: + X% zum Benchmark (1 Tag) → ein Rollback/Überziehen in Betracht gezogen werden.
Slice_Failure: PR-AUC im R-Markt fiel> Y% (1 Tag) → Inhaber des Domain-Tickets.
Guardrails_Breach: Anteil aggressiver Offer> Cap → sofortiger Kill-Switch.

8) Logging und Tracing

Anforderungsprotokolle (Minimum): 'request _ id', 'trace _ id', 'model _ id/version', 'feature _ version', 'feature _ stats' (fehlende%, extremes), 'score', 'decision', 'threshold', 'policy _ id', 'guard _ mask', 'latency _ ms', „cost _ estimate“, (optional) Erklärungen (SHAP top-k).
OTel-трейсы: спаны `feature_fetch` → `preprocess` → `score` → `postprocess` → `guardrail`.
PII: nur Pseudonyme/Token; Maskierung durch Richtlinien, Schlüsselresidenz.

9) Online-Qualitätsbewertung

Schiebefenster für PR-AUC/KS durch schnelle Etiketten (Stunde/Tag).
Delayed Labels: Retrospektive Berichte D + 7/D + 30/D + 90, Anpassungen Expected-Cost.
Kalibrierung: Neubewertung von Isotonic/Platt auf D + 1, Auto-Refresh des Artefakts.

10) Schwellenwert und Entscheidungspolitik

Wir halten die Schwelle als config im Register; Online berechnen wir Expected-Cost und korrigieren innerhalb des zulässigen Bereichs (rate-limited).
Safety-Caps: obere/untere Aktionsgrenzen; manuelle override für Compliance.
Backtesting Schwellenwerte: nightly Simulation auf gestrigen Daten.

11) Slice & Fairness

Segmente: Markt/Gerichtsbarkeit, Anbieter, Gerät/ASN, Alter des Kontos, Depotstärke.
Metriken: PR-AUC, ECE, Expected-Cost, FPR/TPR-Differenz (Equalized Odds), Disparate Impact.
Aktionen: Kalibrierung/Schwelle durch Folien, Umschulung mit Gewichten, Überarbeitung von fitch.

12) Äquivalenz online/offline

Gleichheitstest: MAE/MAPE an der Kontrollprobe; alert bei Divergenz> Schwelle.
Versionierung: 'feature _ spec _ version', 'logic _ version'; WORM-Archiv.
Scheme-Verträge: Breaking-Change ist ohne Doppeleintrag verboten (v1/v2).

13) Guardrails (RG/AML)

Pre-/Post-Filter-Aktionen, Frequenzgrenzen, Cooldown, Verbotslisten.
Логи `policy_id/propensity/mask/decision`; Bericht über Verstöße.
Die Metrik time-to-intervene und false-intervention rate.

14) Vorfälle und Runbook

1. Latency↑/5xx↑: Überprüfen Sie externe Fitch-Anbieter → aktivieren Sie Cache/Timeouts → skalieren Sie → bei Bedarf Rollback.

2. PSI/ECE/Expected-cost verschlechtert: freeze-Verkehr (canary↓), aktivieren fallback-Schwellen/Modell, starten Sie die retrain.

3. Slice failure: temporäre slice-spezifische Schwelle, Ticket für den Domaininhaber.

4. Guardrails breach: Kill-Switch, Fallprüfung, Post-Sea.

15) Kosten und Leistung

Profiling: Zeitanteil im Feature-Fetch gegen Score gegen IO.
Cache-Strategien: TTL/eviction, „heiße“ Fiches im RAM, kalt - lazy.
Quantisierung/Optimierung des Modells: FP16/INT8 bei gleichbleibender Qualität.
Chargeback: Kosten/Anfrage, Kosten/Funktion nach Team/Markt.

16) Beispiele (Fragmente)

python thr_grid = np.linspace(0.01, 0.99, 99)
costs = [expected_cost(y_true, y_prob >= t, c_fp, c_fn) for t in thr_grid]
thr_best = thr_grid[np.argmin(costs)]

text model_inference_latency_ms_bucket feature_fetch_latency_ms_bucket model_request_total{code}
model_score_distribution_bucket psi_feature_amount_base ece_calibration expected_cost_live slice_pr_auc{slice="EEA_mobile"}

text
ALERT DriftDetected
IF psi_feature_amount_base > 0.2 FOR 15m

17) Prozesse und RACI

R (Responsible): MLOps (Beobachtbarkeit/Warnungen/Register), Data Science (Qualitätsmetriken/Kalibrierung/Schwelle), Data Eng (Daten/Verträge/Äquivalenz).
A (Accountable): Head of Data / CDO.
C (konsultiert): Compliance/DPO (PII/RG/AML/DSAR), Sicherheit (KMS/Audit), SRE (SLO/Incidents), Finanzen (Kosten).
I (Informed): Produkt/Marketing/Betrieb/Support.

18) Fahrplan

1. Basis SLI/SLO (latency/5xx/coverage) + Dashboard.

2. PSI für Top-10-Fich und Score-Distribution; ECE und Expected-Cost auf Proxy-Labels.

3. Entscheidungsprotokolle + OTel-Trails; Äquivalenztest online/offline.

4. Alerta HighP95Latency/PSI_Drift/ECE_Bad + runbook 'und

• Slice/Fairness-Panels, nightly backfill Metriken auf latenten Labels.
• Kalibrierautomatik und Schwellensimulator.
• Kosten-Dashboards und Quoten/Limits für Fiches/Replays.

• Auto-Relaut/Drift Retrain mit Kanarienkontrolle.
• WORM-Archive von Qualitätsberichten und Artefakten.
• Chaos-Überwachungstests und DR-Übungen.

19) Prod Readiness Checkliste

• SLI/SLO sind konsistent und promonitored auf shadow/canary ≥ 24h.
• PSI/KL, ECE, Expected-Cost und PR-AUC gelten als online; Schwellenwerte und Alerts sind gesetzt.
• Slice/Fairness-Panels enthalten; Segmentbesitzer sind zugewiesen.
• Logs/Trails komplett (Lösungen, Schwellenwerte, Masken), PII-Masking und Residency eingehalten.
• Äquivalenztest online/offline grün; Fich-Systeme unter Vertrag.
• Runbook ™ und One-Click Rollback geprüft; kill-switch для guardrails.
• Die Kosten sind in den Haushaltsplänen enthalten. Cache/Kontingente/Limits sind aktiv.
• Das WORM-Archiv der Metriken/Artefakte und Qualitätsberichte wird gespeichert.

20) Anti-Muster und Risiken

Es fehlen Online-Labels und eine retrospektive Auswertung.
Überwachung nur der ROC-AUC ohne Expected-Cost und Kalibrierung.
Ignoriere Slice/Fairness → versteckte Fehler in Regionen/Geräten.
Es gibt keine Äquivalenz von Online/Offline-Fit → „doppelte Realität“.
Null Guardrails: giftige Versäumnisse, RG/AML-Verstöße.
Keine Rollback/DR-Pläne, kein WORM-Archiv.

21) Das Ergebnis

Model Monitoring ist ein Frühwarn- und Risiko/Kosten-Management-System, nicht „einmal pro Woche schauen“. Geben Sie SLO ein, messen Sie Drift/Kalibrierung/erwartete Kosten, verfolgen Sie Slices und Guardrails, halten Sie Rollback/Kill-Switch-Tasten, automatisieren Sie Berichte und Retrains. So bleiben die Modelle bei jeder Daten- und Verkehrsturbulenz nützlich, ethisch und konform.