AOI: Turning Failed Trajectories into Training Signals for Autonomous Cloud Diagnosis

Die Arbeit stellt AOI vor, ein trainierbares Multi-Agenten-Framework, das durch die Kombination von GRPO-basiertem Lernen auf lokalen Modellen, einer sicheren Trennung von Lese- und Schreibzugriffen sowie einem geschlossenen Regelkreis zur Umwandlung gescheiterter Trajektorien in Trainingsdaten die Automatisierung von SRE-Aufgaben in geschützten Unternehmensumgebungen signifikant verbessert.

Das Wesentliche

Stell dir vor, du hast einen hochintelligenten, aber etwas ungestümen digitalen Assistenten, der als IT-Feuerwehrmann in einer riesigen, komplexen Cloud-Fabrik arbeiten soll. Dieser Assistent ist ein KI-Modell (ein sogenannter "Large Language Model Agent").

Das Problem: In der echten Welt ist es gefährlich, ihm einfach die Schlüssel zur Fabrik zu geben. Wenn er aus Versehen einen falschen Knopf drückt, könnte die ganze Produktion stillstehen. Außerdem lernt er oft nicht aus seinen Fehlern, weil die Daten, die er braucht, streng geheim sind oder weil er Angst hat, etwas kaputtzumachen.

Die Forscher haben eine Lösung namens AOI (Autonomous Operations Intelligence) entwickelt. Hier ist die Erklärung, wie das funktioniert, mit ein paar einfachen Vergleichen:

1. Das Team aus drei Spezialisten (Die Architektur)

Statt einem einzigen KI-Assistenten, der alles selbst macht, hat AOI ein Team aus drei verschiedenen Charakteren gebildet, die strikte Regeln befolgen:

• Der Beobachter (Observer): Das ist der Stratege. Er sitzt in einem sicheren Raum, liest alle Berichte und denkt nach. Er darf aber niemals direkt in die Maschinen greifen. Er ist wie ein Arzt, der die Symptome analysiert, aber kein Skalpell in der Hand hat.
• Der Späher (Probe): Das ist der Augen-und-Ohr-Teil. Er darf nur schauen und abhören (z. B. Log-Dateien lesen, Status abfragen). Er darf nichts verändern. Er ist wie ein Detektiv, der nur Beweise sammelt, aber keine Verdächtigen verhaftet.
• Der Ausführende (Executor): Das ist der Handwerker. Er darf nur dann etwas tun (z. B. einen Server neu starten), wenn der Beobachter ihm explizit den Befehl gibt und alle Beweise gesammelt sind. Er trägt einen "Sicherheitsgurt" und darf nur bestimmte, erlaubte Werkzeuge benutzen.

Der Clou: Diese Trennung verhindert, dass der Assistent aus Versehen die Fabrik in die Luft jagt, während er noch versucht herauszufinden, was eigentlich los ist.

2. Lernen aus Fehlern (Der "Evolver")

Normalerweise werfen wir Fehler weg. Wenn der Assistent einen falschen Weg geht, sagen wir: "Nicht gut, versuchen wir es nochmal." Aber AOI macht etwas Geniales: Es nutzt die Fehler als Lehrmeister.

Stell dir vor, der Assistent versucht, ein kaputtes Auto zu reparieren, und zieht versehentlich die falsche Sicherung.

• Der Evolver ist wie ein erfahrener Mentor, der zusieht. Er nimmt den fehlerhaften Versuch, analysiert ihn und sagt: "Okay, du hast das richtige Problem gefunden, aber den falschen Hebel gezogen. Hier ist der korrekte Weg."
• Dieser Mentor wandelt den Fehler in eine korrigierte Anleitung um und gibt sie dem Assistenten für den nächsten Versuch.
• So lernt das System aus jedem Misserfolg, ohne dass ein echter Mensch eingreifen muss. Es ist, als würde ein Schüler aus seinen falschen Matheaufgaben lernen, indem der Lehrer ihm die richtige Lösung zeigt, bevor er die nächste Aufgabe macht.

3. Das Training (GRPO)

Um den "Beobachter" (den Stratege) schlauer zu machen, nutzen die Forscher eine spezielle Trainingsmethode namens GRPO.
Stell dir vor, der Stratege bekommt eine Aufgabe. Er denkt sich 4 verschiedene Wege aus, wie man sie lösen könnte. Ein "Richter" (eine andere KI) bewertet diese Wege.

• Der Stratege lernt nicht durch Bestrafung, sondern durch Vergleich: "Welcher der 4 Wege war am besten?"
• So verfeinert er sein Denken Schritt für Schritt, bis er wie ein erfahrener Senior-Ingenieur handelt, auch wenn er eigentlich nur ein kleineres, lokal laufendes Modell ist.

Warum ist das so wichtig?

Die Ergebnisse sind beeindruckend:

1. Sicherheit: Durch die strikte Trennung von "Schauen" und "Tun" passiert nichts, was nicht erlaubt ist.
2. Lernfähigkeit: Das System wird mit der Zeit besser, weil es aus seinen eigenen Fehlern lernt (durch den Evolver).
3. Leistung: Ein kleines, lokal laufendes Modell (das keine riesigen Server braucht) konnte durch diese Architektur sogar besser abschneiden als riesige, teure KI-Modelle, die keine solche Sicherheitsstruktur haben.

Zusammengefasst:
AOI ist wie ein sicherer, lernender Roboter-Teamleiter. Er hat einen Stratege, der denkt, einen Detektiv, der sucht, und einen Handwerker, der arbeitet. Wenn etwas schiefgeht, lernt ein Mentor aus dem Fehler und gibt dem Team eine bessere Anleitung für das nächste Mal. So wird die Cloud-Wartung sicherer, effizienter und lernt ständig dazu, ohne dass Menschen ständig eingreifen müssen.

Technische Zusammenfassung

1. Problemstellung

Die Automatisierung von Site Reliability Engineering (SRE) mittels Large Language Model (LLM) Agents stößt in Unternehmensumgebungen auf drei fundamentale Hindernisse:

• Datenschutz und Zugriffsbeschränkungen: Proprietäre Betriebsdaten können oft nicht für das Training externer Modelle genutzt werden.
• Sicherheitsrisiken bei der Ausführung: In genehmigungsgesteuerten Umgebungen ist die Ausführung von Aktionen (z. B. Änderungen am Systemzustand) durch strikte Sicherheitsrichtlinien eingeschränkt. Herkömmliche Agenten vermischen oft Diagnose („Read") und Reparatur („Write"), was zu unsicheren Zustandsänderungen führt.
• Unfähigkeit, aus Fehlern zu lernen: Geschlossene Systeme können ihre Leistung nicht verbessern, indem sie aus gescheiterten Diagnosepfaden lernen. Gescheiterte Versuche werden meist verworfen, anstatt als wertvolle Trainingssignale genutzt zu werden.

Zudem sind große Modelle (>100B Parameter) für den lokalen Einsatz in SRE-Umgebungen oft zu ressourcenintensiv, während kleinere, lokal deploybare Modelle (<100B) häufig über das notwendige Expertenwissen für komplexe Diagnoseaufgaben verfügen.

2. Methodik: Das AOI-Framework

Das Paper stellt AOI (Autonomous Operations Intelligence) vor, ein trainierbares Multi-Agenten-Framework, das diese Herausforderungen durch drei Kernkomponenten adressiert:

A. Trennung von Diagnose und Ausführung (Read-Write Separation)

AOI nutzt eine strikte Architektur mit vier spezialisierten Agenten, um das Prinzip der geringsten Berechtigungen (Least Privilege) durchzusetzen:

• Observer: Der zentrale Koordinator. Er plant die Diagnose, verfolgt Hypothesen und entscheidet über den nächsten Schritt. Er hat keinen direkten Zugriff auf die Umgebung und kann keine Befehle ausführen.
• Probe: Führt ausschließlich read-only-Operationen aus (z. B. kubectl get, logs). Er sammelt Beweise, ohne den Systemzustand zu verändern.
• Executor: Führt write-gated-Operationen (Reparaturen) aus. Er darf nur nach ausreichender Beweislage und Verifizierung durch den Observer Befehle ausführen.
• Compressor: Komprimiert die rohen Umgebungsdaten (Logs, Outputs) in einen kontexteffizienten Format für den Observer, um Token-Limits einzuhalten und „Lost-in-the-Middle"-Probleme zu vermeiden.

B. Trainierbarer Diagnostiker mit GRPO

Um die Leistung kleinerer, lokal deploybarer Modelle (hier: Qwen3-14B) zu steigern, wird Group Relative Policy Optimization (GRPO) eingesetzt.

• Ziel: Das Training des Observer-Agents, um Expertenwissen in das Modell zu destillieren.
• Vorgehen: Anstatt absolute Belohnungen zu nutzen, vergleicht GRPO eine Gruppe von Kandidaten-Antworten innerhalb eines Schritts. Ein LLM-Judge bewertet die Qualität der Entscheidung (z. B. Korrektheit der Aktion, Qualität der Zusammenfassung, Genauigkeit der Zielressource).
• Vorteil: Dies ermöglicht ein effizientes Fine-Tuning ohne externe Reward-Modelle und fördert das Lernen von Diagnosestrategien statt nur von Mustererkennung.

C. Closed-Loop Evolver für gescheiterte Trajektorien

Dies ist der innovativste Teil des Systems, der das Problem der Datenknappheit löst:

• Konzept: Ein Trajectory Evolver analysiert gescheiterte Diagnoseversuche (Failed Trajectories).
• Mechanismus: Anstatt diese Daten zu verwerfen, generiert der Evolver korrigierte Befehlssequenzen, die den Fehler beheben. Diese korrigierten Pfade dienen als strukturierte Prompts (diagnostische Leitlinien) für den Observer bei zukünftigen Versuchen.
• Lernzyklus: Das System nutzt GRPO, um aus den Fehlern zu lernen, welche Schritte „fast richtig" waren, und wandelt negative Beispiele in positive Supervisionssignale um. Dies schließt den Datenkreislauf innerhalb einer geschlossenen Umgebung.

3. Schlüsselbeiträge

1. Architektonische Sicherheit: Durch die strikte Trennung von Probe (Read) und Executor (Write) wird sichergestellt, dass keine unautorisierten Zustandsänderungen stattfinden, bevor eine Diagnose abgeschlossen ist.
2. Lernen aus Fehlern (Failure Trajectory Closed-Loop): Das System ist in der Lage, gescheiterte Diagnosepfade zu reparieren und als Trainingsdaten zu nutzen, was die Datenknappheit in SRE-Umgebungen überwindet.
3. Leistungsfähigkeit kleiner Modelle: Durch die Kombination aus sicherer Architektur und GRPO-Training erreicht ein 14B-Modell (Qwen3) Ergebnisse, die mit Frontier-Modellen (wie Claude Sonnet 4.5) konkurrieren oder diese übertreffen, ohne dass Multi-Run-Sampling nötig ist.

4. Ergebnisse (Evaluation auf AIOpsLab)

Die Evaluation erfolgte auf dem AIOpsLab-Benchmark mit 86 Incident-Szenarien in Kubernetes-Clustern:

• Architektonischer Gewinn (Runtime ohne Training):

  • AOI erreichte eine Best@5 Success Rate von 66,3 % über alle 86 Aufgaben.
  • Dies ist eine Steigerung von 24,4 Prozentpunkten gegenüber dem vorherigen State-of-the-Art (STRATUS mit 41,9 %).
  • Dies zeigt, dass die Trennung von Lese- und Schreibzugriffen sofortige Verbesserungen bringt.

• Generalisierung durch GRPO:

  • Ein auf nur 23 Aufgaben trainierter Observer (14B Modell) erreichte auf 63 gehaltenen Aufgaben (mit unbekannten Fehlertypen) eine Avg@1 von 42,9 %.
  • Dies übertrifft Claude Sonnet 4.5 (41,3 %) in der Single-Run-Leistung, obwohl das Open-Source-Modell deutlich kleiner ist.

• Effekt des Evolvers:

  • Der Evolver konnte 37 zuvor gescheiterte Trajektorien (43 % der Testfälle) in korrigierte Diagnosepläne umwandeln.
  • Dies verbesserte die End-to-End Avg@5 um 4,8 Prozentpunkte.
  • Die Varianz zwischen einzelnen Läufen (Run-to-Run Variance) wurde um 35 % reduziert, was die Zuverlässigkeit für den Produktionseinsatz erhöht.

5. Bedeutung und Fazit

Das Paper demonstriert, dass Sicherheitsbeschränkungen nicht nur als Hindernis, sondern als treibende Kraft für robustere Architekturen dienen können. Die Trennung von Diagnose und Ausführung verhindert Kaskadenfehler, während der geschlossene Lernkreislauf aus gescheiterten Versuchen die Datenbasis für das Training erweitert.

Die zentrale Erkenntnis ist, dass gescheiterte Trajektorien keine verschwendeten Supervisionssignale sind, sondern wertvolle Quellen für die Verbesserung von Diagnosestrategien. AOI ermöglicht es kleinen, lokal deploybaren Modellen, durch systematische Architektur und fortgeschrittene Optimierungstechniken (GRPO) die Lücke zu proprietären Frontier-Modellen zu schließen, was einen entscheidenden Schritt hin zu sicherer, autonomer Cloud-Diagnose in Unternehmen darstellt.