34 Iterationen eines begrenzten AIOps-Verbesserungsloops

Einordnung: kein Recursive Self-Improvement

ANXEngine schreibt weder seine eigene Architektur autonom um noch trainiert es ein Basismodell ohne Grenzen weiter. Der hier untersuchte Prozess ist ein begrenzter, agentenunterstützter MLOps-Loop: Eine Hypothese wird vorab registriert, als kleinste testbare Änderung umgesetzt, gegen einen Kontrolllauf ausgewertet und anschließend behalten, verworfen oder pausiert.

Diese begriffliche Trennung ist wichtig. Recursive Self-Improvement impliziert meist, dass ein System seinen eigenen Verbesserungsprozess selbst verändert. ANXEngine automatisiert Teile von Hypothesenprüfung, Backfill, Training und Evaluation. Metriken, Budgets und Promotion Gates werden von Menschen definiert. Ein späterer Audit zeigte allerdings, dass der Weekly Cron diese beabsichtigte Kontrollgrenze nicht zuverlässig durchsetzte und Modelle automatisch promotete.

Systemkontext und Messziel

Der untersuchte Produktionspfad bewertet täglich das Störungsrisiko von rund 170 Netzwerkgeräten. Operative Tickets dienen als verzögerte, unvollständige Labels. Die Daten sind stark unausgewogen: Echte Störungen sind selten, Ticketanlage und technischer Beginn fallen nicht immer zusammen, und ein nützlicher Alarm muss vor dem Ticket entstehen.

Die Primärmetrik ist deshalb die Verbesserung der Precision-Recall-Area-under-Curve gegenüber statischen Regeln bei einem Vorhersagehorizont von einem Tag. Als gleichrangige Zielgrößen werden Anzahl und Median der echten Vorwarnungen gemessen. Recall@20 und die Leistung am Störungstag sind Guardrails. Eine Änderung gilt nur dann als Kandidat, wenn alle geforderten Bedingungen gemeinsam bestehen.

• Primär: Delta PR-AUC gegenüber statischen Regeln, Horizont ein Tag.
• Ko-primär: Anzahl echter Vorwarnungen und mediane Vorwarnzeit.
• Guardrails: Recall@20 und kein Rückschritt am Störungstag.
• Kontrolle: Champion und Challenger werden auf demselben aktuellen Datensatz neu gemessen.

Versuchsprotokoll

Jede Iteration beginnt mit einer vorab registrierten Hypothese. Der Loop darf nicht mitten im Lauf auf eine bequemere Idee wechseln. Datenaufbereitung, Training, Selection und Reporting werden getrennt. Ein Challenger wird neben einem Kontroll-Retrain mit unveränderten Features bewertet, damit ein Effekt nicht fälschlich der neuen Änderung zugeschrieben wird, obwohl er nur aus dem erneuten Training stammt.

• Hypothese und erwartete Metrik vor dem Lauf registrieren.
• Kleinste testbare Änderung implementieren.
• Training, Gate-Evaluation und Reportfenster zeitlich trennen.
• Challenger, Same-Data-Control und aktuellen Champion gemeinsam messen.
• Nur KEEP, wenn Ko-Primärmetriken und Guardrails gemeinsam bestehen.
• KEEP, REVERT oder PAUSE getrennt von der tatsächlichen Deployment-Aktion protokollieren.

Ergebnisse aus dem Experiment-Ledger

Die 34 Iterationen waren keine 34 Modellverbesserungen. Der überwiegende Wert entstand aus widerlegten Hypothesen und aus Lücken im Evaluationsdesign. Die Tabelle zeigt die wichtigsten beobachteten Entscheidungen; sie ist bewusst kein Leaderboard.

Failure Mode 1: Trainingsdaten sahen wie Evidenz aus

Der erste Ablauf trainierte auf Zeilen, die teilweise im späteren Fitnessfenster lagen. Das Modell erreichte dort PR-AUC-Werte zwischen 0,72 und 0,76. Nach einer sauberen zeitlichen Trennung blieb ungefähr 0,51. Das war kein kleiner Optimismusfehler, sondern ein anderer Versuchsgegenstand: Memorisation wurde als Vorhersageleistung berichtet.

Der korrigierte Ablauf verwendet getrennte Trainings-, Gate- und Reportfenster. Zusätzlich läuft ein Kontroll-Retrain mit den alten Features. Nur die Differenz zwischen Challenger und Kontrolle darf der Hypothese zugerechnet werden.

Failure Mode 2: Ein Holdout ist ein Verbrauchsgut

Auch ein unangetastetes Holdout verliert seine Unabhängigkeit, wenn Ergebnisse wiederholt in die nächste Hypothese einfließen. Nach jedem Blick enthält die Entwicklungsentscheidung Information über das Fenster. Dreizehn Tests am selben Tag zeigten nicht nur Kandidatenunterschiede, sondern auch drei Schwächen des Test-Harness selbst.

Der Loop bekam deshalb ein Query-Budget von acht Selection-Abfragen pro Fenster. Danach darf das Fenster nur noch als Gate-Historie dienen. Eine Promotion braucht zusätzlich einen nie abgefragten frischen Slice oder zwei unabhängig positive Fenster. Dieses Prinzip entspricht dem Problem adaptiver Datenanalyse, das Dwork und Kollegen im Reusable-Holdout-Ansatz beschreiben.

Failure Mode 3: Eine einzelne Metrik lässt sich gewinnen und das System trotzdem verschlechtern

Eine Probe-/Ramp-Featurefamilie verbesserte die Rangfolge sichtbar: Ein chronisch schwieriges Gerät sprang von Rang 37 auf Rang 7, und Precision@10 stieg von 0,50 auf 0,70. Gleichzeitig fiel die Zahl echter Vorwarnungen von vier auf zwei. Für das operative Ziel wäre das ein Rückschritt gewesen.

ANXEngine verwendet deshalb ein konjunktives Gate. Ein höherer Score darf einen Verlust bei Vorwarnzeit oder Recall nicht überstimmen. Damit wird verhindert, dass der Loop die leichteste Kennzahl optimiert und den eigentlichen Betriebsnutzen beschädigt.

Featuregewinn ist nicht automatisch eine Modell-Promotion

Trajectory- und SNMP-Health-Features erzeugten auf dem angereicherten Entwicklungs-Subset echte frühe Signale: vier Vorwarnungen mit einem Median von 5,5 Tagen gegenüber null beim Ausgangsmodell. Trotzdem wurde das dort trainierte Modell nicht produktiv geschaltet.

Auf der gesamten Flotte war der Vorteil kleiner, die Zahl ausgelöster Flags sank stark und Precision@10 wurde schlechter. Die Features durften weiter Daten sammeln, das Modell blieb unverändert. Diese Trennung zwischen Feature-Entscheidung und Modell-Promotion verhindert, dass ein lokaler Erfolg als globaler Rollout missverstanden wird.

Warum PAUSE ein regulärer Systemzustand ist

Ein autonomer Loop ohne No-op-Zustand behandelt jeden Lauf wie einen Auftrag zur Veränderung. Das erzeugt Aktivität, aber keine Evidenz. Der ANXEngine-Zustandsautomat kennt deshalb GATE_CLEARED, CYCLE_EXHAUSTED, DATA_STALE, BLOCKED und PAUSED_FRESH_DATA.

Bei fehlender Datenfrische wird nicht weiter optimiert. Der nächste Lauf wartet auf neue Labels oder ein benanntes Unblocking-Ereignis. Die beabsichtigte Architektur sah menschliche Freigaben für Promotionen vor; der Ledger-Audit fand jedoch automatische Cron-Promotionen. Das ist eine offene Governance-Lücke: Eine dokumentierte Freigaberegel ist noch keine technisch erzwungene Kontrollgrenze.

Grenzen dieser Research Note

Dies ist kein randomisierter öffentlicher Benchmark. Die Ergebnisse stammen aus einem einzelnen operativen System mit ticketbasierten Proxy-Labels. Das Entwicklungs-Subset enthält absichtlich schwierige und datenreiche Geräte und ist daher nicht repräsentativ für die gesamte Flotte. Positive Ereignisse sind kleinzahlig, und Ticketzeitpunkte bilden den technischen Störungsbeginn nur näherungsweise ab.

Rohdaten und das interne Ledger können wegen Kunden- und Betriebsdaten nicht veröffentlicht werden. Die Notiz dokumentiert den Ablauf, die aggregierten Resultate und die Entscheidungskriterien. Sie belegt nicht, dass dieselben Features oder Schwellwerte auf anderen Flotten funktionieren.

• Ein System, eine Flotte, keine externe Replikation.
• Verzögerte und unvollständige Ticket-Labels.
• Angereichertes Entwicklungs-Subset mit Selektionsrisiko.
• Kleine Zahl positiver Ereignisse je Fenster.
• Kein öffentliches Dataset und keine unabhängige Auditierung.

Reproduzierbarer Entscheidungsrahmen

Die konkreten Daten bleiben intern, der Entscheidungsrahmen ist übertragbar. Wer einen ähnlichen Loop betreibt, sollte nicht nur den besten Modellwert dokumentieren, sondern jede Abfrage, jedes negative Resultat und jeden Grund für eine unterlassene Promotion.

• Hypothese, Primärmetriken und Guardrails vorab festschreiben.
• Zeitlich getrennte Trainings-, Gate- und Reportfenster verwenden.
• Einen Same-Data-Control-Retrain neben dem Challenger ausführen.
• Selection-Abfragen pro Fenster budgetieren und protokollieren.
• Lokale Featuregewinne getrennt von Modell-Promotion bewerten.
• KEEP, REVERT, PAUSE und BLOCKED als gleichwertige Resultate speichern.
• Menschliche Freigabe für Promotion und externe Kommunikation technisch im Ausführungspfad erzwingen.