Start/Praxis/Tipps/MLOps-Retraining: Modelle vergessen nicht, sie bekommen Schocks
11. April 2026

Emmimal P Alexander hat auf Towards Data Science eine der meistgeteilten Annahmen der MLOps-Praxis empirisch gegen die Wand gefahren: Produktionsmodelle zerfallen nicht langsam wie menschliche Erinnerungen, sie werden von diskreten Schocks getroffen. Wer seinen Retraining-Zyklus an einer geschaetzten Halbwertszeit festmacht, optimiert gegen ein Modell, das es in vielen Domaenen gar nicht gibt.

Der geerbte Denkfehler

Hermann Ebbinghaus hat 1885 die Vergessenskurve an sich selbst gemessen und in R(t) = R_0 * exp(-lambda * t) gegossen. Die ML-Community hat sie uebernommen, weil die Analogie plausibel klingt: Ein Modell sieht in Produktion neue Muster, seine Performance verschlechtert sich kontinuierlich, also laesst sich eine Halbwertszeit schaetzen, also folgt ein Retraining-Kalender. Jede "retrain every 30 days"-Regel ist ein Abkoemmling dieser Annahme. Alexanders Einwand: Niemand hat je geprueft, ob Produktionsdaten diese Kurve ueberhaupt beschreiben.

Die empirische Widerlegung

Setup: Kaggle Credit Card Fraud Detection (Sparkov-generiert, 2019-2020). Ein LightGBM-Modell einmal trainiert, nie nachtrainiert. Der Test-Split umfasst 555.719 Transaktionen zwischen Juni und Dezember 2020 mit 2.145 Fraud-Cases (0,39 Prozent Prevalence). Ausgewertet wird Recall in woechentlichen Fenstern von 15.000 bis 32.000 Transaktionen, verworfen werden Wochen mit weniger als 30 Fraud-Cases wegen statistischer Unzuverlaessigkeit.

Die 26 qualifizierten Wochen zeigen kein Zerfallsmuster, sondern eine Zickzack-Linie. Woche 6 erreicht mit 0,9375 Recall den Peak. Woche 7 stuerzt auf 0,7500 ab -- ein Drop von 18,75 Prozentpunkten in sieben Tagen, ausgeloest durch eine Verdopplung des Fraud-Volumens (von 64 auf 152 Faelle). Woche 18 erholt sich spontan auf 0,9245, ohne Retraining. Woche 20 faellt wieder auf 0,7429, Woche 21 springt zurueck auf 0,9322.

Die exponentielle Zerfallskurve, gefittet auf diese Daten, liefert R² = -0.3091. Ein negatives R² bedeutet, dass der fittete Verlauf mehr Vorhersage-Fehler produziert als eine blosse Mittelwertlinie -- das Modell ist also nicht nur unbrauchbar, es ist aktiv irrefuehrend. Der pikante Zusatzbefund: Die aggregierte Metrik sieht gesund aus. Aktuelle Recall 0,8507, Baseline 0,8807, Retention 96,6 Prozent, implizite Halbwertszeit 2.108 Tage. Ein monatliches Dashboard wuerde ueberhaupt nichts melden.

Zwei Regime, eine Diagnose

Alexander schlaegt eine simple Dichotomie vor, die sich aus dem R² der gefitteten Kurve ableitet. Ist R² >= 0,4, liegt ein smooth regime vor -- dann beschreiben langsame demografische oder saisonale Verschiebungen die Realitaet gut genug, Halbwertszeit und Retraining-Kalender sind sinnvoll. Ist R² < 0,4, liegt ein episodic regime vor: Die Performance schaltet um, statt zu zerfallen. Neue Fraud-Ringe tauchen ueber Nacht auf, eine Plattform-Policy dreht Nutzerverhalten, ein Wettbewerber verschwindet und seine Kunden erscheinen mit veraenderten Verteilungen. Das sind Diskontinuitaeten, keine Punkte auf einer Kurve.

Fraud-Detection ist praktisch immer episodisch. Recommender, Demand Forecasting und Content Moderation ebenfalls. Wer eine Halbwertszeit kommuniziert, wo R² negativ ist, verkauft Scheingenauigkeit.

Shock-Detection statt Kalender

Die praktische Ablage ist kurz. Pro Woche ein Shock-Flag, sobald der aktuelle Recall mehr als acht Prozent unter dem Rolling-Mean der letzten vier Wochen liegt. Volume-weighted Recall als aggregierte Metrik, gewichtet mit der Fraud-Fallzahl pro Fenster. Retrain-Trigger nur dann feuern, wenn zwei aufeinanderfolgende Wochen unter einem Baseline-Schwellenwert liegen -- ein Zwei-Wochen-Filter reduziert Fehlalarme, ohne echte Regime-Wechsel zu verschlucken.

Die Schwellen sind Startpunkte, keine Gesetze, und werden gegen die Kostenasymmetrie der Domain kalibriert. Wer erst Tage spaeter echte Labels bekommt, braucht zusaetzlich einen Drift-Detektor auf den Input-Verteilungen -- PSI, KL-Divergenz oder CUSUM auf Features -- weil Recall-basierte Shocks erst mit Label-Latency sichtbar werden. Abgrenzung zur klassischen Drift-Literatur: Covariate Shift und Label Shift sind die Mechanismen, die Schocks erzeugen koennen, aber die episodische Beobachtung auf der Metrik-Seite ist unabhaengig davon, welche Drift darunter liegt. Man entscheidet zuerst, in welchem Regime man sich bewegt, dann erst welche Drift-Metrik man ueberwacht.

Uebertragung auf LLM-Systeme

Die Logik ist eins zu eins auf produktive LLM-Stacks uebertragbar. RAG-Indizes altern nicht gleichmaessig, sie werden durch Dokumenten-Updates geschockt: ein ueberarbeitetes Compliance-Handbuch, eine neue Preisliste, ein politisches Ereignis, das den Top-Content im Wiki verschiebt. Embedding-Drift durch Modellwechsel passiert im Moment des Deployments, nicht allmaehlich. Fine-tuning-Refreshes auf Synthetic Data haben dieselbe Regime-Struktur -- solange der Teacher sich nicht aendert, ist der Verlauf glatt; sobald der Teacher ein neues Verhaltensregime lernt oder ein Guardrail-Change durchschlaegt, schaltet die Qualitaet sprunghaft um. Die Distillations-Pipelines aus Knowledge Distillation erben damit dieselbe Observability-Frage: Loggt ihr woechentliche Eval-Scores fein genug, um einen Shock innerhalb einer Woche zu erkennen, oder mittelt ihr ueber Monate hinweg?

Ein LLM-Team, das seinen System-Prompt als Produkt behandelt (System-Prompt als Produkt), braucht eine Eval-Kadenz, die dieselben Regime-Wechsel sichtbar macht. Regression-Suites auf Wochenbasis, nicht auf Quartalsbasis. Fixtures, die nach jedem Provider-Update, jedem Prompt-Bump und jedem Retrieval-Reindex neu gemessen werden -- dasselbe Observability-Muster, das auch AI-Refactoring in Produktion (AI-Refactoring in der Produktion) erst verlaesslich macht.

Konsequenzen fuer die Praxis

Die Leitfrage aendert sich von "wann retrainiere ich" zu "woran erkenne ich einen Schock schnell genug". Granularitaet der Monitoring-Fenster ist damit eine Produktentscheidung, keine Detailfrage -- wer nur monatlich aggregiert, hat sich dagegen entschieden, Shocks zu sehen. Halbwertszeit-Kennzahlen in MLOps-Dashboards gehoeren mit einem Regime-Flag annotiert, sonst erzeugen sie falsches Sicherheitsgefuehl. Und automatisches Retraining auf Zeitbasis ist fuer episodische Domains die teuerste und sinnloseste Automatisierung der Pipeline: Es rechnet Compute ab, ohne die Shocks zu adressieren, und kaschiert das Fehlen echter Drift-Observability.

Das Zwei-Zeilen-Diagnostic forgetting_regime und fit_r_squared ist damit vermutlich die billigste Produktivitaetsverbesserung, die ein Team auf seinen bestehenden Metrik-Logs ausprobieren kann, bevor es die naechste Retraining-Pipeline baut.

Quellen

Nach oben