🤖 AI

A Topology-Aware, Memory-Centric Architecture that Separates Root-Cause Derivation from Root-Cause Explanation

Dit artikel introduceert OPS CORTEX, een topologiebewuste, geheugencentrische architectuur die de deterministische afleiding van de grondoorzaak ontkoppelt van LLM-gebaseerde uitleg door een persistente, gestructureerde representatie van systeemgedrag en afhankelijkheden te behouden om de uitdagingen van foutpropagatie in moderne microservice-deployments aan te pakken.

Oorspronkelijke auteurs: Momil Seedat

Gepubliceerd 2026-06-23

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Momil Seedat

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je de kapitein bent van een enorm, hoogtechnologisch ruimteschip. Plotseling gaan er overal alarmen af. Lampen knipperen rood. Het schip schudt.

Het Probleem:
In moderne computersystemen (microservices genoemd), wanneer er iets kapot gaat, zijn de alarmen makkelijk te activeren maar moeilijk te begrijpen. Het is alsof er 50 verschillende sensoren tegelijk "Brand!" schreeuwen. Het echte probleem is niet dat de sensoren niet werken; het is dat de mens in charge (de engineer) overweldigd wordt. Zij moeten uitzoeken:

Welke sensor is het echte vuur?
Welke sensoren reageren slechts op de rook van het eerste vuur?
Waarom gebeurde dit nu en niet gisteren?

Meestal vergeet het computersysteem alles op het moment dat het alarm stopt. Het heeft geen geheugen van hoe "normaal" eruitziet op een dinsdag om 3 uur 's nachts, of hoe de onderdelen van het schip met elkaar verbonden zijn. Dus moet de engineer elke keer opnieuw de detective spelen, vaak terwijl het systeem nog steeds aan het crashen is.

De Oplossing: OpsCortex (Het "Operationele Geheugen")
De paper introduceert OpsCortex, een nieuwe manier om deze systemen te draaien. In plaats van te proberen de computer "slimmer" te maken met een gigantisch brein (zoals een supergeavanceerde AI) om het antwoord te raden, zeggen de auteurs: "Geef het systeem een geheugen."

Zie OpsCortex als een supergeorganiseerd, langetermijngeheugen voor het computersysteem. Het is gebouwd als een vier verdiepingen tellende bibliotheek:

Het Werkblad (Tier 1): Dit is het "Nu". Het bevat de huidige temperatuur, snelheid en meldingen. Het is als een briefje op een bureau dat elke paar uur wordt weggegooid.
De Live Kaart (Tier 2): Dit is een tekening van hoe alle computer-services met elkaar communiceren. Als Service A met Service B praat, weet deze kaart dat. Het wordt constant bijgewerkt.
Het Fotoalbum (Tier 3): Elke minuut maakt het systeem een "snapshot" van de hele kaart en slaat deze op. Hierdoor kun je terugkijken en zien: "Oh, de verbinding werd 5 minuten geleden verbroken, niet 1 seconde geleden."
De Encyclopedie (Tier 4): Dit is het permanente brein. Het onthoudt: "Op dinsdagen om 3 uur 's nachts vertraagt het systeem meestal een beetje, en dat is normaal." Het onthoudt ook eerdere rampen en hoe ze werden opgelost.

Hoe het werkt: De "Detective en de Vertaler"
De paper betoogt dat het vinden van de oorzaak van een probleem en het uitleggen ervan twee verschillende taken zijn. OpsCortex splitst deze taken op:

Stap 1: De Detective (Deterministische Logica):
Eerst gebruikt het systeem eenvoudige, harde wiskundige regels (zoals een detective die een spoor van voetstappen volgt). Het kijkt naar de "Live Kaart" en vraat: "Welke service ging er eerst kapot?" en "Met welke services is deze verbonden?"
- Analogie: Als een domino steen valt en een rij van 10 anderen omver werpt, raadt de wiskunde niet. Het wijst simpelweg naar de eerste domino die viel. Dit is 100% betrouwbaar en snel.
Stap 2: De Vertaler (De AI/LLM):
Pas nadat de Detective de boosdoener heeft gevonden, roept het systeem de "AI Vertaler" op.
- Analogie: De AI wordt niet gevraagd om te raden wie het gedaan heeft. In plaats daarvan overhandigt de Detective de AI een dossier met bewijsmateriaal (de kaart, de tijdlijn, de eerste domino) en zegt: "Dit is wat er is gebeurd. Schrijf nu een rapport voor de menselijke kapitein in gewone taal en vertel hen hoe ze het kunnen oplossen."
- Dit maakt de AI veel beter in haar werk, omdat ze niet aan het gissen is, maar simpelweg feiten uitlegt.

Waarom dit beter is (De "Stilte"-truc)
Het systeem leert ook om "ruis" te negeren.

Het Probleem: Elke nacht voert een computer misschien een grote, trage taak uit die eruitziet als een crash, maar eigenlijk normaal is. Oude systemen zouden elke nacht "ALARM!" schreeuwen.
De OpsCortex Fix: Het systeem leert: "Oh, dit gebeurt elke nacht om 2 uur 's nachts. Dat is normaal." Het wordt stil.
Het Veiligheidsnet: Maar als diezelfde taak plotseling trager is dan gebruikelijk, of als het om 2 uur 's middags gebeurt in plaats van 2 uur 's nachts, herinnert het systeem zich: "Wacht, dit is niet het gebruikelijke patroon!" en gaat het alarm af.

Bewijs uit de Praktijk
De auteurs testten dit op een nep webshop. Ze braken het op 8 verschillende manieren (zoals het laten oplopen van een wachtrij of het overbelasten van een service).

Toen ze het testten tegen echte rampen (zoals de Slack-storingen vermeld in de paper), loste het ontwerp direct de problemen op waar die bedrijven mee te maken kregen:
- Slack 2021: Hun eigen dashboard ging kapot omdat het vertrouwde op hetzelfde defecte netwerk. OpsCortex heeft dat dashboard niet nodig; het heeft zijn eigen permanente geheugen (Tier 4), zodat het nog steeds kan werken zelfs als de hoofdinstrumenten falen.
- Slack 2022: Een kleine wijziging veroorzaakte een enorme crash tijdens de piekuren. OpsCortex herinnert zich hoe "piekverkeer" er normaal gesproken uitziet, zodat het de afwijking richting een ramp ziet aankomen voordat het alarm zelfs maar afgaat.

De Kernboodschap
De paper beweert dat het grootste probleem bij het repareren van computersystemen niet het gebrek aan betere sensoren of slimmere AI is. Het is dat we een gebrek aan geheugen hebben.

OpsCortex zegt: "Laten we een systeem bouwen dat onthoudt wat normaal is, onthoudt hoe dingen verbonden zijn, en onthoudt hoe fouten uit het verleden zijn gemaakt." Door dit te doen, kan het de hoofdoorzaak vinden met eenvoudige wiskunde, en vervolgens AI gebruiken om het helder uit te leggen. Dit maakt het systeem goedkoper, rustiger en veel sneller in het zelf repareren.

Technische Samenvatting: OpsCortex – Operationeel Geheugen voor Zelfdiagnostische Microservicesystemen

Probleemstelling

Moderne microservices-architecturen kampen met een kritieke asymmetrie: foutdetectie is volwassen en geautomatiseerd, maar de lokalisatie van de grondoorzaak en de verklaring blijven handmatig, traag en gevoelig voor contextverlies. Wanneer fouten zich voortplanten door service-afhankelijkheden, veroorzaken ze "alert floods" die engineers overweldigen. De geïdentificeerde kernuitdagingen zijn:

Alert Fatigue (Alertmoeheid): Drempelwaarde-gebaseerde systemen zijn geheugenloos; ze kunnen geen onderscheid maken tussen onschuldige terugkerende gebeurtenissen (bijv. nachtelijke batchjobs) en echte crises.
Verlies van Context: Cruciale diagnostische gegevens — zoals de live call graph, tijdstip-specifieke baselines en recente configuratiewijzigingen — zijn vaak vluchtig of verspreid, waardoor diagnose een vorm van "archeologie" wordt.
Het Cascadeprobleem: Foutsignalen zijn topologisch en temporeel (wie ging er eerst kapot en hoe verspreidde de schade zich), maar platte alertstromen verwerpen deze structuur, waardoor het moeilijk is om de grondoorzaak te onderscheiden van de downstream-slachtoffers.

Het artikel betoogt dat het ontbrekende ingrediënt in autonome operaties niet betere anomaliedetectoren of grotere Large Language Models (LLMs) zijn, maar operationeel geheugen: een persistente, gestructureerde representatie van systeemgedrag, afhankelijkheden en historische fouten.

Methodologie

OpsCortex is een multi-agent prototype dat operationeel geheugen organiseert in een vierlaagse architectuur en de afleiding van de grondoorzaak scheidt van de verklaring.

1. Vierlaagse Operationele Geheugenarchitectuur

Het systeem gelaagd het geheugen op basis van levensduur en doel om ervoor te zorgen dat het systeem nooit "blind" is bij een herstart:

Tier 1 (Hot Working Memory - Redis): Slaat huidige metriekwaarden, sliding windows en alertstromen op met een korte Time-To-Live (TTL). Dit vertegenwoordigt het "heden" van het systeem.
Tier 2 (Live Dependency Graph - NetworkX): Een in-process, drie-niveau gerichte graaf (Service → Categorie → Metriek) met CALLS-randen. Status plant zich omhoog voort (de slechtste metriek bepaalt de status van de categorie, enz.), voor snelle traversatie.
Tier 3 (Snapshot History - Neo4j): Serialiseert de volledige graaf elke 60 seconden. Dit stelt het systeem in staat om te analyseren hoe de staat veranderde in de minuten voorafgaand aan een incident, waardoor onderscheid kan worden gemaakt tussen langzame lekkages en plotselinge crashes.
Tier 4 (Permanent Brain - SQLite): De "geleerde" staat. Het slaat per service/metriek/uur/weekdag baselines op, bevestigde call-randen met betrouwbaarheidscounts, registers voor structurele ruis en de volledige incidentgeschiedenis. Bij een cold start reconstrueert deze laag de graaf en baselines voordat nieuwe telemetrie binnenkomt, zodat het systeem kennis behoudt over herstarts heen.

2. De "Afleiden, Dan Verklaren" Pipeline

Het diagnoseproces is bewust gesplitst in twee fasen om de sterke punten van deterministische logica en generatieve AI te benutten:

Fase 1: Deterministische Afleiding:
- Grondoorzaak Berekening: Het systeem voert een Breadth-First Search (BFS) uit over bevestigde CALLS-randen om alle services te identificeren die verbonden zijn met een fout.
- Temporele Ordening: De grondoorzaak wordt geïdentificeerd als de service die als eerste de alertdrempel overschreed ( $arg \min t_{amber}$ ). Dit scheidt de oorzaak van de slachtoffers.
- Ruisafhandeling (Suppress-Then-Detect): Het systeem leert structurele ruis (bijv. onschuldige nachtelijke jobs) te herkennen en onderdrukt alerts hiervoor. Echter, onderdrukking wordt overruled door plotselinge pieken (zelf z-score), geleidelijke drift (trend z-score) of gecorreleerde anomalieën in peer-services.
- Tijdbewuste Baselines: Detectie gebruikt baselines gegroepeerd per (service, metriek, uur, weekdag) om rekening te houden met normale cyclische variaties.
Fase 2: Generatieve Verklaring:
- Een LLM wordt pas aangeroepen nadat de deterministische laag de grondoorzaak heeft geïdentificeerd en bewijslast heeft samengesteld (foutpad, z-scores, Isolation Forest scores, statusprogressie).
- De taak van de LLM is beperkt tot het verklaren, bevestigen en aanbevelen van oplossingen op basis van het verstrekte bewijs, in plaats van het afleiden van causaliteit uit ruwe telemetrie.
- Patroonherkenning: Als een nieuw incident overeenkomt met een bekende signatuur uit het permanente brein, reconstrueert het systeem de vorige diagnose en omzeilt het de LLM volledig, wat de kosten en variantie vermindert.

Belangrijkste Bijdragen

Vierlaagse Geheugenarchitectuur: Een ontwerp dat de huidige staat, live topologie, veranderingsgeschiedenis en permanente kennis scheidt, waardoor contextverlies tijdens herstarts wordt voorkomen.
Tweefasige Grondoorzaak-methode: Een deterministische aanpak (BFS + temporele ordening) die de oorzaak berekent, waarbij de LLM strikt wordt beperkt tot de rol van verklaring met vooraf samengesteld bewijs.
Geleerde Suppress-Then-Detect Lifecycle: Een mechanisme dat structurele ruis stillegt terwijl het deze dynamisch overrulet wanneer er sprake is van echte degradatie (pieken of drift).
Expliciete Failure Mode Mapping: Een directe architecturale mapping waarbij elke ontwerpkeuze een specifiek falingsscenario adresseert dat is waargenomen in gedocumenteerde productie-incidenten (Slack 2021 en 2022 outages).

Resultaten en Validatie

Het prototype werd gevalideerd op een geïnstrumenteerde e-commerce benchmark met acht injecteerbare foutscenario's, inclusclusief request surges, queue lag, cascade failures en resource exhaustion.

Leergedrag: Het systeem demonstreerde succesvol het vermogen om onschuldige terugkerende patronen (batchjobs) te leren en te onderdrukken, terwijl het ze onmiddellijk detecteert en de onderdrukking opheft wanneer ze verslechteren.
Patroon Bypass: Het systeem identificeerde bekende patronen succesvol om de LLM te omzeilen, wat de efficiëntiewinst aantoont naarmate het systeem "leert".
Scope van Validatie: De auteurs geven expliciet aan dat dit een validatie is van het mechanisme end-to-end, en niet een vergelijkende nauwkeurigheidsmeting tegen productiedata of andere tools zoals MicroRCA.

Betekenis en Claims

Het papier stelt dat de bottleneck in autonome operaties geheugen is, niet perceptie. Hoewel detectiesystemen talrijk zijn, zijn systemen die "normaal gedrag", afhankelijkheden en historie "begrijpen" dat niet.

OpsCortex claimt significant te zijn als een concreet architecturaal argument voor:

Herformulering van het Doel: Verplaatsen van het afleiden van grondoorzaken vanaf nul bij elke alert naar het onderhouden van een "levend model" waar het antwoord vaak al bekend is.
Taakverdeling: Het toewijzen van deterministische taken (lokalisatie, ordening) aan regelgebaseerde systemen en generatieve taken (verklaring, aanbeveling) aan LLM's, om zo het risico op gehallucineerde grondoorzaken te verminderen.
Kostenreductie: Het systeem "goedkoper" maken over tijd door te leren ruis te onderdrukken en dure LLM-aanroepen voor bekende patronen te omzeilen.

De auteurs blijven bescheiden over de huidige status van het prototype en erkennen beperkingen zoals het gebruik van "first-crossing" als proxy voor causaliteit (wat kan falen in feedback-gekoppelde systemen) en het gebrek aan evaluatie op echte, gelabelde incident-corpora. Toekomstig werk is gericht op het bewegen van temporele heuristieken naar causale inferentie en het valideren van het systeem op echte post-mortem data.