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

Dit paper introduceert AOI, een trainbaar multi-agent framework dat veilige, data-gedreven SRE-automatisering mogelijk maakt door gespecialiseerde kennis te distilleren via GRPO, een lees-schrijfgescheiden architectuur te hanteren voor veilige uitvoering, en mislukte trajecten om te zetten in leerzame supervisiessignalen voor continue verbetering.

De kern

Stel je voor dat je een gigantisch, complex gebouw hebt met duizenden apparaten, leidingen en beveiligingssystemen die allemaal tegelijk moeten werken. Dit is je cloud, de digitale infrastructuur waar onze apps en websites op draaien.

Helaas gaan dingen soms kapot. Een lamp gaat uit, een leiding loopt lek, of een beveiligingsdeur blijft openstaan. In het verleden moesten menselijke experts (SRE's) hier naar kijken, de oorzaak vinden en het repareren. Dat is lastig, want het gebouw is te groot en te snel veranderlijk voor één mens.

Nu willen we robots (AI-agenten) die dit voor ons doen. Maar er is een groot probleem: als je een robot de sleutels geeft om de deur te openen en het licht aan te zetten, kan hij per ongeluk de hele elektriciteitscentrale platleggen als hij een fout maakt. Bovendien leren robots vaak niet van hun fouten; als ze iets verkeerd doen, wordt dat gewoon weggegooid.

De auteurs van dit paper hebben AOI bedacht. Dat is een slimme, veilige manier om AI te laten werken in deze kritieke omgeving. Hier is hoe het werkt, vertaald naar een simpel verhaal:

1. De Drie Deuren: Waarnemer, Verkenners en Werknemers

Stel je voor dat je een team hebt dat een huis moet repareren, maar ze mogen niet zomaar alles aanraken. AOI splitst het werk op in drie strikt gescheiden rollen:

• De Waarnemer (Observer): Dit is de hoofdinspecteur. Hij mag alleen kijken, denken en plannen maken. Hij mag nooit iets aanraken of veranderen. Hij is als een detective die alleen met zijn ogen werkt.
• De Verkenners (Probe): Dit zijn de oogjes en oortjes. Ze mogen alleen informatie verzamelen (zoals "is het licht aan?" of "wat zegt de meter?"). Ze mogen niets veranderen.
• De Werknemers (Executor): Dit zijn de handen. Ze mogen alleen iets doen (zoals een schakelaar omzetten of een kraan dichtdraaien), maar alleen als de Waarnemer en Verkenners 100% zeker weten dat het veilig is.

Waarom is dit slim?
In oude systemen deed de robot alles tegelijk: kijken én doen. Als hij dacht "misschien helpt het om de stekker eruit te trekken", deed hij het direct. Soms was dat een ramp. Bij AOI moet de robot eerst bewijzen dat het nodig is voordat hij iets mag veranderen. Dit voorkomt dat de robot per ongeluk de hele fabriek platlegt.

2. De "Fouten-Boekhouder" (De Evolver)

Normaal gesproken zeggen we: "Oh, de robot heeft gefaald. Laten we die poging vergeten en een nieuwe proberen."
AOI doet iets anders. Het heeft een speciale Fouten-Boekhouder (de Evolver).

Stel je voor dat de robot probeert een kapotte kraan te repareren, maar hij gebruikt de verkeerde sleutel en maakt het erger.

• Oude manier: De robot probeert het opnieuw, hopend dat het nu lukt.
• AOI-methode: De Fouten-Boekhouder pakt die mislukte poging, kijkt er naar en zegt: "Kijk eens, je had de juiste sleutel, maar je draaide hem de verkeerde kant op. Laten we die fout opschrijven en een nieuwe instructie maken: 'Gebruik de sleutel, maar draai linksom'."

Deze nieuwe, verbeterde instructie wordt dan gebruikt als een stevig raamwerk voor de volgende poging. De robot leert dus niet alleen van zijn successen, maar vooral van zijn fouten. Hij maakt van elke mislukking een les die hij de volgende keer beter doet.

3. Het Resultaat: Een Slimme, Veilige Robot

Door deze twee trucjes te combineren (scheiden van kijken en doen, en leren van fouten), gebeurt er iets magisch:

• Veiligheid: De robot kan niet meer per ongeluk de wereld platleggen, omdat hij eerst moet "denken" voordat hij "doet".
• Snelheid: De robot wordt steeds slimmer. In tests bleek dat een klein, lokaal model (dat op een gewone server past) met deze methode beter presteerde dan de allerbeste, dure super-intelligente robots die we nu hebben.
• Betrouwbaarheid: Omdat de robot leert van zijn fouten, is hij minder wisselvallig. Soms lukt het hem in de eerste poging, soms in de tweede, maar door de "Fouten-Boekhouder" wordt hij steeds consistenter.

Samenvattend in één zin:

AOI is als het geven van een veiligheidsharnas en een dagboek aan een robot: het harnas zorgt dat hij niet per ongeluk iets kapot maakt (door te kijken voordat hij doet), en het dagboek zorgt dat hij elke keer slimmer wordt door zijn eerdere fouten te analyseren en te verbeteren, in plaats van ze te vergeten.

Hierdoor kunnen bedrijven nu veilig AI gebruiken om hun digitale systemen te bewaken en te repareren, zonder bang te hoeven zijn dat de AI de stekker eruit trekt.

Technische samenvatting

Probleemstelling

Grote Taalmodellen (LLM)-agenten bieden veelbelovende kansen voor het automatiseren van Site Reliability Engineering (SRE), maar hun implementatie in enterprise-omgevingen wordt gehinderd door drie fundamentele uitdagingen:

1. Beperkte toegang tot data: Propriëtaire operationele data kan vaak niet worden gedeeld voor training vanwege privacy- en beveiligingsrisico's.
2. Onveilige uitvoering: Agenten opereren in omgevingen met strikte machtigingen; het uitvoeren van schrijfbewerkingen ("write") zonder voldoende verificatie kan leiden tot onomkeerbare schade.
3. Onvermogen om te leren van falen: Gesloten systemen kunnen niet effectief verbeteren op basis van mislukte diagnosepaden. Traditionele methoden filteren mislukte trajecten vaak als ruis weg, in plaats van ze als leermomenten te gebruiken.

Daarnaast vereisen strikte beveiligingsprotocollen een scheiding tussen diagnostiek (lezen) en herstel (schrijven), terwijl kleinere, lokaal gedeployeerde modellen (<100B parameters) vaak ontbrekende expert-redeneervermogen hebben en statisch blijven.

Methodologie: AOI (Autonomous Operations Intelligence)

AOI is een trainbaar multi-agent framework dat geautomatiseerde operaties formuleert als een gestructureerd leerprobleem onder beveiligingsbeperkingen. Het systeem bestaat uit drie kerncomponenten:

1. Multi-Agent Runtime Architectuur (Veiligheid door Scheiding)

In plaats van één grote LLM te gebruiken, introduceert AOI een gespecialiseerd multi-agent systeem dat strikt onderscheid maakt tussen "lezen" en "schrijven":

• Observer: De centrale coördinator die hypothesen vormt en beslissingen neemt. Deze agent heeft geen directe toegang tot het systeem en kan geen commando's uitvoeren.
• Probe: Voert uitsluitend schrijfbewerkingen uit (bijv. kubectl get, logs bekijken). Deze agent kan de systeemstatus niet wijzigen.
• Executor: Voert schrijfbewerkingen uit (herstelacties). Deze agent werkt onder strikte whitelists en voert acties pas uit na voldoende bewijsverzameling door de Probe.
• Compressor: Comprimeert ruwe output naar een beknopte context om token-limieten te respecteren en "lost in the middle"-problemen te voorkomen.
• Dual-Timescale Memory: Behoudt coherentie over lange diagnosepaden door korte-termijn context (comprimeren) te combineren met lange-termijn samenvattingen van eerdere iteraties.

2. Trainbaar Diagnostisch Systeem (GRPO)

Om het redeneervermogen van een lokaal model (Qwen3-14B) te verbeteren zonder gevoelige data te onthullen, gebruikt AOI Group Relative Policy Optimization (GRPO):

• In plaats van absolute beloningen, vergelijkt GRPO een groep van $G$ kandidaat-acties binnen dezelfde context.
• Een LLM-judge scoort deze acties op zes dimensies (formaat, samenvatting, actie-type, context-instructie, namespace-accuraatheid, en vertrouwen).
• Dit stelt het model in staat om expertkennis te distilleren van geslaagde trajecten, zonder dat het model zelf de data hoeft te "zien" in de vorm van ruwe logs tijdens de inferentie.

3. Failure Trajectory Closed-Loop Evolver

Dit is de innovatieve component die mislukte diagnosepaden omzet in trainingsignalen:

• Repair: Voor mislukte trajecten genereert de Evolver een gecorrigeerd commando-sequence dat de fouten in het oorspronkelijke pad corrigeert (bijv. het juiste commando voor een verkeerde namespace).
• Augmentation: Voor geslaagde trajecten genereert de Evolver variaties om de trainingsdiversiteit te vergroten.
• Closed-Loop: De gecorrigeerde plannen worden als gestructureerde prompts ("diagnostische gids") teruggevoerd naar de Observer tijdens inferentie, waardoor het systeem continu leert van zijn eigen fouten binnen een gesloten omgeving.

Belangrijkste Bijdragen

1. Architecturale Veiligheid: Een bewezen framework dat "read" en "write" rechten strikt scheidt, wat onbevoegde staatmutaties voorkomt en voldoet aan enterprise-beveiligingsnormen.
2. Learning from Failure: Een mechanisme om mislukte diagnostische trajecten niet te verwerpen, maar te repareren en te gebruiken als trainingsdata via GRPO, waardoor het systeem zich continu kan verbeteren zonder externe expertinterventie.
3. Prestatie van Open-Source Modellen: Demonstreert dat een lokaal gedeployeerd 14B-parameter model (Qwen3-14B) met de juiste architectuur en training de prestaties van state-of-the-art gesloten modellen (zoals Claude Sonnet 4.5) kan evenaren of overtreffen in specifieke SRE-taken.

Resultaten

Het systeem is geëvalueerd op de AIOpsLab-benchmark (86 incident-scenario's in Kubernetes):

• Runtime Prestaties (zonder training): Alleen al de AOI-runtime bereikte een 66,3% success rate (best@5) op alle 86 taken. Dit is een verbetering van 24,4% ten opzichte van de vorige state-of-the-art (STRATUS, 41,9%).
• Generalisatie met GRPO: Een lokaal 14B-model, getraind met Observer-GRPO op slechts 23 taken, bereikte 42,9% (avg@1) op 63 onbekende taken met nieuwe fouttypen. Dit overtreft Claude Sonnet 4.5 (41,3%) zonder multi-run sampling.
• Impact van de Evolver: De Evolver slaagde erin om 37 eerder mislukte trajecten om te zetten in diagnostische richtlijnen. Dit verbeterde de end-to-end success rate (avg@5) met 4,8% en verlaagde de variantie tussen runs met 35%.
• Ablatie: De combinatie van Observer-GRPO en Evolver-prompten leverde de beste resultaten op, met name voor complexe Root Cause Analysis (RCA) taken.

Betekenis en Conclusie

Het paper toont aan dat strikte beveiligingsbeperkingen (zoals read-write scheiding) niet alleen veilig zijn, maar ook de diagnosecapaciteit kunnen verbeteren door te voorkomen dat agenten te vroeg ingrijpen. Cruciaal is het inzicht dat mislukte trajecten waardevolle supervisie zijn. Door mislukkingen te repareren en te hergebruiken, kan een systeem systematisch vaardigheden opbouwen zonder toegang tot gevoelige productiegegevens.

AOI bewijst dat kleine, lokaal gedeployeerde open-source modellen, wanneer ze worden ondersteund door een slimme multi-agent architectuur en een gesloten leerlus, concurrerend kunnen zijn met grote, gesloten modellen voor kritieke cloud-operaties. Dit opent de weg voor veilige, autonome SRE-systemen die continu leren van hun eigen ervaringen in productie-omgevingen.