TopoEdge: Topology-Grounded Agentic Framework for Edge Networking Code Generation and Repair

TopoEdge ist ein agentenbasiertes Framework, das mittels graphenbasierter Topologie-Einbettung und eines generativen, verifizierenden Reparaturzyklus zuverlässige Software-Defined-Networking-Konfigurationen für Edge-Netzwerke direkt vor Ort generiert und repariert.

Das Wesentliche

Stell dir vor, du bist ein Netzwerk-Architekt, der für ein riesiges, sich ständig veränderndes Straßennetz zuständig ist. Deine Aufgabe ist es, für jede neue Stadt (das Netzwerk) die perfekten Verkehrsregeln (die Konfiguration) zu schreiben, damit keine Staus entstehen und alle Autos (die Daten) sicher ans Ziel kommen.

Das Problem? Wenn sich die Straßenkarte nur ein wenig ändert (ein neuer Kreisverkehr, eine gesperrte Brücke), funktionieren die alten Regeln plötzlich nicht mehr. Manuelle Fehler sind teuer, und die großen, genialen Computer, die diese Regeln normalerweise schreiben, sind oft zu weit weg oder zu teuer, um direkt vor Ort zu arbeiten.

Hier kommt TopoEdge ins Spiel. Es ist wie ein intelligenter, lokaler Handwerker, der direkt in der Stadt arbeitet und dir hilft, diese Regeln automatisch zu schreiben und zu reparieren.

Hier ist die Erklärung, wie das funktioniert, ganz einfach und mit ein paar bildhaften Vergleichen:

1. Der "Gedächtnis-Trick" (TopoRAG)

Stell dir vor, du musst ein neues Haus bauen, hast aber keine Baupläne.

• Das alte Problem: Du versuchst, alles aus dem Kopf zu erfinden. Das dauert lange und führt zu Fehlern.
• Die TopoEdge-Lösung: Das System schaut sich die neue Stadt an und fragt: "Welche andere Stadt sieht dieser Struktur am ähnlichsten?"
  Es nutzt eine spezielle Art von "Gehirn" (ein Graph-Neuronales Netz), das nicht auf Wörter, sondern auf Strukturen achtet. Es findet im Archiv eine fast identische Stadt, für die es bereits einen geprüften, funktionierenden Bauplan gibt.
  • Die Analogie: Es ist wie ein Handwerker, der sagt: "Ah, diese Stadt sieht aus wie die, die wir letztes Jahr gebaut haben. Wir nehmen den Plan von damals, passen nur ein paar Details an, und schon haben wir einen soliden Start."

2. Das "Dreier-Team" (Die Agenten)

Sobald der passende Plan gefunden ist, startet ein kleines Team aus drei KI-Assistenten, die zusammenarbeiten, aber unterschiedliche Aufgaben haben:

• Der Planer (Planning Agent):
  Er ist der Architekt. Er schaut sich den alten Plan und die neue Stadt an und sagt: "Okay, wir brauchen hier eine Ampel, dort eine Einbahnstraße. Hier ist das Grundgerüst." Er erstellt einen groben Fahrplan, damit niemand wild herumrätselt.
• Der Baumeister (Generation Agent):
  Er ist der Handwerker. Er nimmt den Fahrplan und schreibt die eigentlichen Baupläne (den Code). Aber er ist nicht wild: Er trägt einen Schutzanzug (Constrained Decoding). Das bedeutet, er darf nur Wörter und Befehle verwenden, die technisch erlaubt sind. Er kann keine unsinnigen Dinge wie "Baue eine Brücke aus Wackelpudding" schreiben. Das spart Zeit und verhindert dumme Fehler.
• Der Prüfer (Verify Agent):
  Er ist der Polizist und Testfahrer. Er nimmt den fertigen Plan und fährt damit durch eine simulierte Stadt (ein Testlabor).
  • Wenn alles läuft: "Super, fertig!"
  • Wenn ein Unfall passiert: "Hoppla, hier ist die Ampel falsch." Er schreibt nicht einen riesigen Bericht, sondern einen kleinen Zettel mit genau dem Fehler ("Ampel an Kreuzung X auf Grün stellen") und gibt ihn zurück an den Baumeister.

3. Der "Korrektur-Loop" (Generieren – Prüfen – Reparieren)

Dieses Team arbeitet in einer Schleife:

1. Planer macht einen Entwurf.
2. Baumeister schreibt den Code.
3. Prüfer testet ihn.
4. Wenn es klappt: Abhaken.
5. Wenn es klappt: Prüfer gibt den kleinen Zettel mit dem Fehler zurück, Baumeister repariert nur diesen einen Teil, und der Zyklus beginnt von vorne.

Das Tolle ist: Das System weiß genau, wann es aufhören soll. Es hat ein Budget (wie viel Zeit und Energie es hat). Wenn eine Aufgabe einfach ist, ist sie schnell erledigt. Wenn sie schwer ist, bekommt das Team mehr Zeit, aber nicht unendlich viel.

4. Warum ist das so besonders? (Der "Rand"-Effekt)

Normalerweise brauchen solche KI-Systeme riesige, teure Supercomputer in der Cloud. TopoEdge läuft aber auf kleinen, günstigen Computern direkt vor Ort (am "Rand" des Netzwerks, z. B. auf einem Raspberry Pi).

• Warum funktioniert das? Weil es nicht alles neu erfinden muss. Durch den "Gedächtnis-Trick" (TopoRAG) hat es immer einen guten Startpunkt. Und weil es in einem Team arbeitet, das sich gegenseitig korrigiert, muss es nicht perfekt sein, um anzufangen – es wird durch das Testen perfekt.

Das Ergebnis

In Tests hat TopoEdge gezeigt, dass es fast genauso gut ist wie die großen, zentralen Super-KIs (die 93% der Aufgaben lösen), aber auf kleinen Geräten vor Ort (89% Erfolg). Ohne den "Gedächtnis-Trick" (also wenn es nur raten müsste) würde es nur bei 55% der Fälle Erfolg haben.

Zusammenfassend:
TopoEdge ist wie ein kluger, lokaler Handwerker, der nicht aus dem Nichts erfindet, sondern auf bewährte Pläne zurückgreift, ein Team aus Planer, Bauherr und Prüfer hat und durch ständiges Testen und Reparieren sicherstellt, dass das Netzwerk funktioniert – und das alles direkt vor deiner Haustür, ohne teure Cloud-Server.

Technische Zusammenfassung

1. Problemstellung

Die Konfiguration von Software-Defined Networks (SDN) ist anfällig für Fehler, insbesondere wenn sich die Netzwerktopologie ändert. Bestehende Automatisierungstools konzentrieren sich oft nur auf Syntax und Vorlagen, fehlt jedoch das explizite Verständnis der Netzwerktopologie. Kleine Fehler können zu schwer diagnostizierbaren semantischen Ausfällen führen. Zudem bestehen in vielen Szenarien strenge Anforderungen an Latenz, Datenschutz und Sicherheit, die eine Ausführung von Inferenzmodellen direkt am „Edge" (lokal auf ressourcenbeschränkter Hardware) statt in zentralisierten Cloud-Clustern erfordern. Herkömmliche Large Language Models (LLMs) sind oft zu groß für den Edge-Einsatz oder benötigen zentrale APIs, was Datenschutzbedenken aufwirft.

2. Methodik: Das TopoEdge-Framework

TopoEdge ist ein agentic Framework, das speziell für die Generierung und Reparatur von SDN-Konfigurationen am Edge entwickelt wurde. Es basiert auf einem geschlossenen Regelkreis aus Generierung, Verifikation und Reparatur, der durch eine topologiebasierte Wissensabrufschicht (TopoRAG) gestützt wird.

A. TopoRAG (Topology-Grounded Retrieval-Augmented Generation)

• Topologie-Embedding: Jede Zieltopologie wird als Graph auf Router-Ebene dargestellt (Knoten = Router/Switches, Kanten = Links). Ein kontrastiv trainierter Graph Neural Network (GNN), spezifisch ein dreischichtiger Graph Convolutional Network (GCN), erzeugt Embeddings für diese Graphen.
• Retrieval: Das System nutzt einen kontrastiven Lernansatz (InfoNCE-Loss), um einen Embedding-Raum zu lernen, in dem ähnliche Topologien nahe beieinander liegen. Bei einer neuen Anfrage wird die ähnlichste verifizierte Referenztopologie aus einer Datenbank von 386 validierten Fällen (mit ausführbaren Python-Treibern/Topotest-Skripten) abgerufen.
• Kontextbildung: Der abgerufene Referenzfall (Topologie + verifizierter Treiber) wird zusammen mit der Zieltopologie und SDN-Hintergrundwissen zu einem „TopoRAG"-Kontext zusammengeführt. Dies dient als Grounding für die nachfolgenden Agenten.

B. Verteilte Agenten-Architektur

Das System läuft auf einem Edge-Cluster (hier: Raspberry Pi Nodes mit quantisiertem Llama-3.1-8B-Modell) und koordiniert drei spezialisierte Agenten:

1. Planning Agent: Erzeugt einen topologiekonsistenten Konfigurationsplan und ein Skelett für jedes Gerät. Dies definiert die Protokollabsichten und strukturellen Invarianten, bevor Code generiert wird.
2. Generation Agent: Materialisiert ausführbare Konfigurationsartefakte (Gerätekonfigurationen und den Python-Treiber) basierend auf dem Plan und dem TopoRAG-Kontext.
3. Verification Agent: Führt den FRRouting Topotest/pytest-Harness aus. Bei Fehlern komprimiert er die Logs in eine kompakte Fehlertrace und leitet lokalisierte Reparaturanweisungen (Patches) an den Generator weiter.

C. Steuerungsmechanismen für den Edge-Einsatz

Um die Effizienz auf ressourcenbeschränkter Hardware zu gewährleisten, implementiert TopoEdge zwei Controller:

• Adaptiver Inferenz-Budget-Controller: Schätzt die Schwierigkeit eines Falls basierend auf der Ähnlichkeit des Topologie-Embeddings und strukturellen Metriken (Knotenzahl, Grad). Er weist dynamisch Token-Limits und maximale Iterationszahlen zu.
• Eingeschränktes Decoding (Constrained Decoding): Während der Generierung wird der Suchraum des LLM durch ein Schema und eine kuratierte Befehlslexikon eingeschränkt. Dies verhindert syntaktisch ungültige Ausgaben und konzentriert die Modellkapazität auf semantische Korrekturen.

3. Schlüsselbeiträge

1. TopoRAG: Ein topologiebewusster Retrieval-Modul, das die Ähnlichkeit von Topologien mit verifizierten SDN-Treibern verknüpft. Dies ermöglicht die Übertragung von Struktur und Protokollabsicht auf neue Fälle.
2. Edge-deployables Agentic Framework: Ein vollständig am Edge lauffähiges System, das den „Generate-Verify-Repair"-Loop nutzt, um Konfigurationen unter Ressourcenbeschränkungen zu erstellen und zu reparieren.
3. Kosteneffiziente Steuerung: Die Kombination aus adaptiven Budgets und eingeschränktem Decoding ermöglicht eine stabile und effiziente Inferenz auf kleinen quantisierten Modellen ohne zentrale Cloud-Abhängigkeit.

4. Ergebnisse

Die Evaluation erfolgte an 200 zurückgehaltenen Testfällen (Topotest) unter Verwendung eines Edge-Clusters mit vier Raspberry Pi Nodes.

• Erfolgsrate (Pass@20): TopoEdge erreichte eine Pass@20-Rate von 0,890 (178 von 200 Fällen erfolgreich).
  • Zum Vergleich: Die Variante ohne TopoRAG („No-TopoRAG") erreichte nur 0,550.
  • Eine zentrale, leistungsstarke LLM-Baseline (Claude Code) erreichte 0,930.
• Konvergenzgeschwindigkeit: TopoEdge konvergiert deutlich schneller als No-TopoRAG. Die mediane Anzahl der Iterationen bis zum Erfolg lag bei 5 (TopoEdge) gegenüber 9 (No-TopoRAG).
• Effizienz: TopoEdge benötigte durchschnittlich 220 Sekunden und 4.000 Tokens pro Fall, während No-TopoRAG aufgrund von mehr Reparaturversuchen 360 Sekunden und 6.900 Tokens benötigte.
• Ablationsstudie: Das Entfernen der adaptiven Budgets oder des eingeschränkten Decodings führte zu einer signifikanten Verschlechterung der Erfolgsrate und einer Erhöhung der Anzahl ungültiger Artefakte.

5. Bedeutung und Fazit

TopoEdge demonstriert, dass die Kombination aus topologiebasiertem Retrieval (TopoRAG) und einem ausführungsorientierten Reparatur-Loop die Lücke zwischen ressourcenbeschränkten Edge-Modellen und zentralisierten großen Modellen schließen kann.

• Robustheit: Der Zugriff auf verifizierte Referenzfälle ist der Haupttreiber für die Robustheit des Systems.
• Praktikabilität: Das Framework beweist, dass komplexe SDN-Konfigurationsaufgaben auch auf kostengünstiger Edge-Hardware mit kleinen, quantisierten Modellen zuverlässig gelöst werden können, ohne auf zentrale Cloud-Dienste angewiesen zu sein.
• Zukunftsperspektive: Die Autoren planen, das System auf heterogenere Topologien zu erweitern und fortschrittlichere topologische neuronale Netzwerke zu erforschen, um noch komplexere Netzwerkmuster zu erfassen.

Zusammenfassend bietet TopoEdge einen konkreten, ressourcenbewussten Ansatz für die automatisierte, sichere und datenschutzkonforme Verwaltung von SDN-Netzwerken am Edge.