Observability för ML-system

En ML-tjänst kan vara uppe och samtidigt fel. Därför två sorters mätning:

Systemhälsa (som vilken tjänst som helst): felkvot, latens p50/p95/p99, genomströmning, kö, resursanvändning.

Modellhälsa (det speciella):

Mått	Fångar
Förutsägelsefördelning	modellen börjar svara annorlunda
Indatafördelning (drift)	världen har ändrats
Kvalitet på stickprov	mänsklig granskning av 1 %
Avstå-andel / låg konfidens	modellen blir osäker
Kostnad per anrop och per löst uppgift	budget
Andel fallback / degraderat läge	beroenden krånglar

Poängen: kvalitetsförsämring syns i fördelningarna innan den syns i klagomål — om du mäter dem.

import time, json, logging
log = logging.getLogger("ml")

def loggad_prediktion(modell, x, request_id):
    t0 = time.perf_counter()
    p = modell.predict_proba(x)[0]
    latens = (time.perf_counter() - t0) * 1000
    log.info(json.dumps({                    # strukturerad logg — ingen persondata
        "request_id": request_id, "modell": modell.version,
        "latens_ms": round(latens, 1), "konfidens": round(float(p.max()), 3),
        "klass": int(p.argmax()), "features_hash": hash_features(x),
    }))
    return p

# Drift: jämför fördelningen den senaste dagen med referensperioden
from scipy.stats import ks_2samp
def driftlarm(referens, senaste, alfa=0.01):
    stat, p = ks_2samp(referens, senaste)
    return {"drift": p < alfa, "p": round(float(p), 5), "ks": round(float(stat), 3)}

Larm som går att agera på — tre regler: larma på symptom användaren märker (p95-latens, felkvot), inte på varje avvikelse; varje larm ska ha en runbook; och ett larm som inte lett till åtgärd på tre månader ska tas bort. Larmtrötthet är farligare än inget larm.