Drift

Kurzzusammenfassung

• Drift-Control beschreibt verbindlich, welche Drift-Arten überwacht und wie sie bewertet werden.
• Trigger-Thresholds sind je Drift-Typ messbar definiert und mit Eskalationsstufen gekoppelt.
• Der Eskalationspfad führt nachvollziehbar von Früherkennung bis zur Retrain-Entscheidung.
• Jede Drift-Eskalation erzeugt auditierbare Evidenz für Governance und Betriebsführung.

Ziel

Business-Nutzen: Standardisierte Drift-Steuerung reduziert Qualitätsverluste durch verzögertes Handeln und schafft konsistente Kriterien für retrain, hold oder continue.

Drift-Arten (verbindlich)

Drift-Art	Definition	Primärer Indikator	Sekundärer Indikator
Data Drift	Verschiebung in Eingangsverteilungen der Features	PSI/JS-Divergenz je Kernfeature	Anteil Out-of-Range/Null-Rate
Concept Drift	Änderung des Zusammenhangs zwischen Features und Zielgrösse	Degradation der Zielmetrik bei stabilen Inputs	Residual-Drift / Error-Segment-Shift
Label/Outcome Drift	Verschiebung in Ziel- oder Outcome-Verteilung	Class Balance Shift / Outcome Mix	Verzögerte Performance-Bestätigung
Operational Drift	Änderung im Serving-/Pipeline-Verhalten mit Einfluss auf Modelloutput	Inferenzlatenz + Timeout-Anstieg	Feature-Freshness-Lag

Trigger-Thresholds

Stufe	Kriterium (Beispiel-Mindeststandard)	Erwartete Aktion
Info	PSI 0.10-0.20 auf nicht-kritischen Features ODER leichte Zielmetrik-Schwankung innerhalb Warnband	Monitoring verdichten, Ticket erstellen
Warnung	PSI > 0.20 auf kritischem Feature ODER Zielmetrik > 5 % unter 30d-Baseline für 2 aufeinanderfolgende Fenster	Drift-Analyse starten, Owner informieren
Kritisch	PSI > 0.30 auf mehreren kritischen Features ODER Zielmetrik > 10 % unter Baseline ODER Guardrail-Verstoss	Incident + sofortige Eskalation, Retrain-Entscheid vorbereiten

Eskalationspfad bis Retrain-Entscheid

1. Erkennung (ServiceTask_Monitor): Drift-Signal überschreitet Trigger-Threshold.
2. Validierung (MLOps + Data Owner, ≤ 4h): Messfehler ausschliessen, betroffene Features/Segmente bestätigen.
3. Diagnose (ML Lead, ≤ 1 Arbeitstag): Ursache klassifizieren (Data, Concept, Label, Operational), Business-Impact quantifizieren.
4. Entscheidungsvorlage (Gateway_Retrain): Optionen continue, mitigate, retrain, rollback inkl. Risikoabwägung.
5. Freigabe (Governance Board bei Kritisch): Retrain-Start oder alternative Massnahme mit Frist und Owner.
6. Protokollierung: Ergebnis + Begründung in Decision Logging persistieren.

Kontrollen

Governance- und Risiko-Aspekte

• Drift-Indikatoren und Thresholds sind versioniert und pro Modellklasse freigegeben.
• Kritische Driftfälle benötigen dokumentierte Risikoentscheidung innerhalb definierter Triage-Zeit.
• Jede Retrain-Entscheidung referenziert Evidenz (Metrikfenster, Segmentanalyse, Impact-Bewertung).

Operative Checks

Check	Monitoring	Verantwortlich	Eskalation
Drift-Indikatoren je Modell aktiv	kontinuierlich + täglicher Drift-Report	MLOps	ML Lead
Threshold-Verletzungen triagiert	innerhalb SLA je Severity	On-Call + Model Owner	Incident Commander
Retrain-Entscheid dokumentiert	bei Warnung/Kritisch verpflichtend	Governance + Risk	Governance Board Chair

Entscheidung

• Drift-Art ist klassifiziert und Evidenz dokumentiert.
• Trigger-Threshold und Severity sind nachvollziehbar begründet.
• Eskalationspfad bis Gateway_Retrain ist vollständig durchlaufen und protokolliert.

BPMN-Kontext

• IDs: ServiceTask_Monitor, Gateway_Retrain
• Input-Bezug: Drift-Indikatoren aus Daten-, Modell- und Betriebsmetriken.
• Entscheidungsbezug: Gateway_Retrain trifft die verbindliche Massnahmeentscheidung.
• Output-Bezug: Retrain-Trigger, Mitigation-Plan oder begründetes Weiterlaufen.