Was monitorst du bei einem Modell in Produktion, und was löst tatsächlich einen Pager aus?

Monitore drei Ebenen: Service-Gesundheit (Latenz, Fehlerrate, Durchsatz), Datengesundheit (Input-Verteilungen, Null- und Unknown-Category-Raten, Feature-Frische) und Modellgesundheit (Vorhersageverteilung und, sobald Labels da sind, Performance). Alarmier auf Service-Ausfälle und kaputte Input-Pipelines, weil die sofort handhabbar sind. Langsame Drift gehört auf ein Dashboard und in ein Review, nicht um 3 Uhr nachts auf den Pager.

Ich denke in drei Ebenen. Service-Ebene ist das Übliche, p99-Latenz, Fehlerrate, Durchsatz, und das alarmiert, denn ein Modell, das Fehler zurückgibt, ist ein Ausfall wie jeder andere. Auf der Datenebene leben die echten ML-Vorfälle: Input-Feature-Verteilungen, Null-Raten, Unknown-Category-Raten und Feature-Frische, also wie alt der neueste Wert im Online Store ist. Frische ist das, was mich am meisten kümmert, denn ein kaputter Upstream-Job wirft keinen Fehler, er liefert einfach die Werte von gestern und das Modell gibt weiter selbstbewussten Unsinn zurück. Das alarmiert. Modellebene ist die Vorhersageverteilung und, sobald Labels da sind, die tatsächliche Performance. Eine scharf verschobene Vorhersageverteilung ist einen Alarm wert; langsame Drift ist ein Dashboard-Punkt und ein Gespräch, kein Pager, denn wenn du jemanden für allmähliche Drift weckst, liest innerhalb eines Monats niemand mehr die Alarme. Was das alles prägt, ist Label-Verzögerung. Wenn Ground Truth Wochen braucht, kann ich Genauigkeit nicht nahezu in Echtzeit monitoren, ich stütze mich also auf Input- und Output-Verteilungen als Proxys und sage klar, dass es Proxys sind.