Grundlage fur KI-LLMs in der IT/OT-Infrastrukturdokumentation und Topologie

Die meisten Infrastrukturdaten, die in KI-Pipelines landen, wurden nie dafur entworfen.

Rohe Vendor-Exporte, ad-hoc-JSON-Blobs und Log-Dumps tragen genug Rauschen in sich, sodass ein darauf trainiertes Modell meist vor allem den Dialekt des Vendors reproduziert, statt uber Infrastruktur zu schlussfolgern, einschliesslich eines potenziellen Risikos, sensible Daten wie Secrets mitzutragen. OSIRIS JSON wurde fur einen anderen Zweck entworfen, namlich:

1. portabel zu sein
2. vendor-neutral zu sein
3. Ausgabedaten zu normalisieren
4. schema-validierte und standardisierte Topologie-Snapshots zu liefern

genau dieses Design macht es aber zu einer nutzlichen Grundlage fur das Training von KI-LLMs. Die zwei Phasen der LLM-Pipeline, in die OSIRIS JSON am naturlichsten passt, sind Fine-Tuning und Instruction.

Was Fine-Tuning von Daten braucht

Fine-Tuning passt ein vortrainiertes Modell an eine bestimmte Domain an. Das Signal kommt aus dem Trainingskorpus: Jedes Dokument lehrt das Modell, welches Vokabular normal ist, welche Strukturen gemeinsam auftreten, welche Beziehungen gultig sind und welche Muster sich wiederholen.

Damit dieses Signal nutzlich ist, mussen die Daten konsistent sein. Ein Trainingskorpus aus rohen Cisco-NX-OS-Exporten, Azure-ARM-Templates und VMware-vCenter-Dumps lehrt keine Infrastruktur-Logik. Er lehrt drei voneinander getrennte Vendor-Dialekte. Ein Modell, das auf diesem Mix trainiert wurde, spiegelt diese Inkonsistenzen zuruck, sobald es uber Grenzen hinweg schlussfolgern soll.

OSIRIS JSON versucht, dieses Problem auf Schema-Ebene zu beseitigen.

Jedes OSIRIS-JSON-Dokument teilt unabhangig davon, ob es aus einem Hyperscaler wie einem AWS-Account, aus einer On-Premise-Arista-Fabric oder einer Serie von Cisco-Nexus-Switches oder aus einer Nokia-Fabric erzeugt wurde, dieselbe Aussenstruktur: version, metadata und topology. Ressourcen haben immer id, type und provider. Verbindungstypen folgen denselben Punktnotation-Konventionen. Gruppen-Semantik ist konsistent.

Ein Fine-Tuning-Korpus, der aus OSIRIS-Dokumenten aufgebaut wird, kann ein LLM besser auf Infrastrukturkonzepte trainieren als auf die einzelnen Vendor-Formate, die sich im Lauf der Zeit andern konnen, wenn Vendors Features aktualisieren. Das Modell lernt, dass eine network.firewall zwischen network.switch-Ressourcen sitzt und connectivity-Verbindungen zu den Segmenten hat, die sie schutzt. Es lernt, dass eine dreistufige Anwendungstopologie konsistent aus einem Load Balancer, Compute-Ressourcen und einer Datenbank auf Anwendungsebene besteht. Es lernt, wie eine gultige containment-Beziehung im Unterschied zu einer dependency aussieht.

Das ist genau die Art von Domain-Wissen, auf die ein Modell spezialisiert werden sollte.

Die Graphstruktur ist ein naturliches Trainingssignal

OSIRIS JSON modelliert Infrastruktur als expliziten Graphen: Ressourcen sind Knoten, Verbindungen sind Kanten, und Gruppen clustern beides in logische oder physische Grenzen.

Graphstruktur ist in Trainingsdaten ungewohnlich wertvoll, weil sie Beziehungen explizit kodiert. In unstrukturiertem Text muss das Modell schliessen, dass eine Firewall vor den Servern liegt, die sie schutzt. In einem OSIRIS-JSON-Dokument ist diese Beziehung eine typisierte, gerichtete Verbindung mit source, target und type. Das Modell muss nicht raten, es liest eine Struktur, die absichtlich genau diese Topologie ausdrucken soll.

Die Taxonomie der Verbindungstypen tragt weiteres Signal. Der Unterschied zwischen einer dependency-Verbindung und einer containment-Verbindung ist semantisch, nicht syntaktisch. Training auf Dokumenten, die diese Typen korrekt verwenden, lehrt ein Modell, funktionale Beziehungen von strukturellen zu unterscheiden. Diese Unterscheidung ist wichtig, wenn ein Modell Fragen beantworten soll wie:

• was bricht, wenn diese Ressource ausfallt?
• was befindet sich logisch innerhalb dieser Amazon AWS VPC?
• kannst du den Traffic-Flow aller Ressourcen innerhalb dieser Microsoft Azure Subscription darstellen?

Die Taxonomie der Ressourcentypen fugt eine weitere Ebene hinzu. Die Hierarchie in Punktnotation (compute.vm, compute.vm.template, network.switch, storage.volume) liefert eine naturliche Klassifikation, die ein feinabgestimmtes Modell internalisieren, verallgemeinern und auf Ressourcen anwenden kann, die es vorher nie gesehen hat.

Warum Normalisierung fur die Trainingsqualitat wichtig ist

Die Producer-Normalisierung ist einer der am wenigsten diskutierten Teile von OSIRIS JSON, hat aber direkte Auswirkungen auf die Qualitat der Trainingsdaten.

Bevor ein OSIRIS-JSON-Dokument den Fine-Tuning-Korpus erreicht, hat ein Producer bereits:

• vendorspezifische Ressourcentypen auf standardisierte Eintrage der OSIRIS-JSON-Taxonomie abgebildet
• Zugangsdaten, Tokens und Secrets per Redaction entfernt
• doppelte oder widerspruchliche Bezeichner in deterministische stabile IDs aufgelost
• die Topologie in einer konsistenten, sortierten Ausgabe serialisiert

Das Ergebnis ist, dass jedes Dokument im Trainingskorpus strukturell sauber ist und Schutzmechanismen besitzt. Es gibt keine eingebetteten Passwoerter oder Secrets, die dem Modell beibringen, Zugangsdaten mit Topologiefeldern zu verknupfen. Es gibt keine Instabilitat bei Bezeichnern, die zwischen mehreren Laeufen derselben Umgebung Rauschen einfugt. Es gibt keine vendorspezifische Eigenschaft, die mit derselben Eigenschaft eines anderen Vendors kollidiert, nur anders benannt.

Ein Fine-Tuning-Korpus, der aus producer-validierten OSIRIS-JSON-Dokumenten aufgebaut ist, hat fur eine so heterogene Domain wie Infrastruktur einen ungewohnlich niedrigen Rauschboden.

Was Instruction Alignment von Daten braucht

Instruction Fine-Tuning zielt auf etwas anderes. Das Ziel ist nicht, Domain-Wissen zu lehren, sondern dem Modell beizubringen, wie es dieses Wissen als Antwort auf menschliche Anfragen einsetzt. Das ist die Phase, die die Nutzbarkeit drastisch verbessert, indem sie das Verhalten des Modells an menschliche Erwartungen angleicht und es hilfreicher, zuverlassiger und besser steuerbar macht.

OSIRIS-JSON-Dokumente sind geerdete Artefakte. Sie beschreiben eine konkrete Infrastruktur zu einem konkreten Zeitpunkt, validiert gegen ein bekanntes Schema. Genau diese Geerdetheit macht sie fur den Aufbau von Instruction-Paaren nutzlich.

Ein gut geformtes Instruction-Beispiel kombiniert eine naturliche Sprachfrage, ein OSIRIS-JSON-Dokument als Kontext und eine korrekte Antwort, die aus der Topologie abgeleitet ist. Zum Beispiel:

• Hat diese Topologie einen Single Point of Failure? Das Modell liest die Verbindungen, identifiziert Ressourcen ohne redundanten Pfad und antwortet mit konkreten Ressourcen-IDs und Begruendung
• Was ware betroffen, wenn die Firewall ihren Uplink verliert? Das Modell traversiert den Verbindungsgraphen ausgehend von der relevanten Ressource und listet abhangige Ressourcen auf
• Fasse diese Infrastruktur fur ein Architektur-Review zusammen Das Modell liest Ressourcentypen, Anzahlen und Gruppenstruktur, um eine menschenlesbare Zusammenfassung zu erzeugen
• Erzeuge ein aktualisiertes OSIRIS-Dokument, das eine Standby-Replik fur die primare Datenbank hinzufugt Das Modell erweitert die Topologie schema-gultig
• Erzeuge eine genaue Topologie meiner Microsoft-Azure-Infrastruktur und dokumentiere sie im Markdown-Format Das Modell kann beim Lesen eines OSIRIS-JSON-Dokuments eine Topologie im draw.io- oder Mermaid-Format erzeugen und ein Markdown-Dokument erstellen, das die Infrastrukturkonfiguration zu einem Zeitpunkt zusammenfasst

Die Schlusseleigenschaft ist Verifizierbarkeit. Weil das Quelldokument schema-validiert ist und die Topologie explizit vorliegt, kann ein menschlicher Reviewer prufen, ob die Antwort des Modells korrekt ist. Diese Feedback-Schleife, in der menschliche Evaluatoren die Modellantworten tatsachlich gegen eine Ground Truth bewerten konnen, macht Instruction-Daten nutzlich. Qualitativ gute Instruction-Paare fur Infrastruktur zu erstellen ist deutlich schwerer, wenn die Quelldaten mehrdeutig oder inkonsistent formatiert sind.

Provider-Zuordnung erhalt Nachvollziehbarkeit ohne Vendor-Bias festzuschreiben

Eine Designentscheidung in OSIRIS JSON, die fur KI-Anwendungsfalle wichtig ist, ist die Provider-Zuordnung.

Ressourcen tragen Informationen uber ihren ursprunglichen Provider, also AWS, Azure, Arista, Cisco, Nokia oder HPE, aber die Kernstruktur bleibt immer vendor-neutral. Ein Modell, das auf OSIRIS-JSON-Dokumenten trainiert wird, lernt, Provider-Kontext mit dem Verhalten von Ressourcen zu verknupfen, ohne zu lernen, dass die zugrunde liegende Topologiesprache providerspezifisch ist.

Das ist insbesondere fur Instruction Alignment wichtig. Wenn ein Benutzer fragt um welche Art von Infrastruktur handelt es sich hier?, sollte das Modell anhand der Topologie antworten und nicht daran, dass es das Exportformat eines bestimmten Vendors wiedererkennt. Die Provider-Zuordnung in OSIRIS JSON macht diese Unterscheidung in den Trainingsdaten explizit, statt sie dem Modell nur uber lexikalische Muster uberlassen zu mussen.

Eine strukturierte Grundlage fur infrastruktur-bewusste KI-LLM-Modelle

Die Richtung, auf die das hinauslauft, sind infrastruktur-bewusste KI-LLMs, die uber Topologie schlussfolgern, Risiken sichtbar machen, Architekturfragen beantworten, bei Dokumentation helfen und Anderungen vorschlagen konnen, die auf deinen realen aktuellen Inventardaten beruhen und nicht auf vagem allgemeinem oder vendorspezifischem Wissen und Dokumentation daruber, wie Infrastruktur “ublicherweise” aussieht.

OSIRIS JSON ist dafur nicht der einzige Baustein. Aber als normalisiertes, schema-validiertes und deterministisches Austauschformat, auf das Producer uber verschiedene Vendors und Plattformen hinweg zielen konnen, liefert es etwas, das die KI-Pipeline sonst von Grund auf selbst konstruieren musste: eine konsistente strukturelle Sprache fur Infrastruktur.

Das ist die OSIRIS-JSON-Grundlage.

Zugehorige Dokumente lesen

• Die OSIRIS-JSON-v1.0-Spezifikation lesen
• Die Core-Konzepte lesen
• Die Taxonomie der Ressourcentypen lesen
• Die Producer-Leitlinien lesen
• Mehr uber Validierungsstufen lesen

Autor des Banner-Icons Esri