Base des LLM d’IA pour la documentation et la topologie d’infrastructure IT/OT

La plupart des donnees d’infrastructure qui finissent dans des pipelines d’IA n’ont jamais ete concues pour y entrer.

Les exports bruts de vendors, les blobs JSON ad hoc et les dumps de logs transportent assez de bruit pour qu’un entrainement sur ces donnees apprenne surtout a un modele a reproduire le dialecte du vendor, pas a raisonner sur l’infrastructure, y compris avec un risque potentiel de transporter des donnees sensibles comme des secrets. OSIRIS JSON a ete concu pour un autre objectif, a savoir etre:

1. portable
2. neutre vis-a-vis des vendors
3. normaliser les donnees de sortie
4. des snapshots de topologie standardises et valides par schema

mais cette conception s’avere etre exactement ce qui le rend utile comme base d’entrainement pour les LLM d’IA. Les deux etapes du pipeline LLM ou OSIRIS JSON s’integre le plus naturellement sont le fine-tuning et l’instruction.

Ce que le fine-tuning attend des donnees

Le fine-tuning adapte un modele pre-entraine a un domaine specifique. Le signal provient du corpus d’entrainement: chaque document apprend au modele quel vocabulaire est normal, quelles structures apparaissent ensemble, quelles relations sont valides et quels motifs se repetent.

Pour que ce signal soit utile, les donnees doivent etre coherentes. Un corpus d’entrainement compose d’exports bruts Cisco NX-OS, de templates Azure ARM et de dumps VMware vCenter n’enseigne pas le raisonnement sur l’infrastructure. Il enseigne trois dialectes vendors separes. Un modele entraine sur ce melange reflechira ensuite ces incoherences lorsqu’on lui demandera de raisonner au-dela des frontieres.

OSIRIS JSON essaie d’eliminer ce probleme au niveau du schema.

Chaque document OSIRIS JSON, qu’il soit produit a partir d’un hyperscaler comme un compte AWS, d’une fabric Arista on-premise ou d’une serie de switches Cisco Nexus, ou encore d’une fabric Nokia, partage la meme structure externe: version, metadata et topology. Les ressources ont toujours id, type et provider. Les types de connexion suivent les memes conventions en notation a points. La semantique des groupes est coherente.

Un corpus de fine-tuning construit a partir de documents OSIRIS peut mieux entrainer un modele LLM sur des concepts d’infrastructure, plutot que sur les formats propres a chaque vendor, qui peuvent eux-memes evoluer au fil du temps a mesure que le vendor met a jour ses fonctionnalites. Le modele apprend qu’un network.firewall se place entre des ressources network.switch et possede des connexions connectivity vers les segments qu’il protege. Il apprend qu’une topologie d’application a trois niveaux implique de maniere coherente un load balancer, des ressources de calcul et une base de donnees de couche applicative. Il apprend a quoi ressemble une relation containment valide par opposition a une dependency.

C’est le bon type de connaissance de domaine pour specialiser un modele.

La structure de graphe est un signal d’entrainement naturel

OSIRIS JSON modelise l’infrastructure comme un graphe explicite: les ressources sont des noeuds, les connexions sont des aretes et les groupes regroupent le tout dans des frontieres logiques ou physiques.

La structure de graphe est particulierement precieuse dans les donnees d’entrainement parce qu’elle encode explicitement les relations. Dans du texte non structure, le modele doit inferer qu’un firewall se situe en amont des serveurs qu’il protege. Dans un document OSIRIS JSON, cette relation est une connexion typee et orientee avec une source, une target et un type. Le modele n’a pas a deviner, il lit une structure construite deliberement pour exprimer exactement cette topologie.

La taxonomie des types de connexion apporte un signal supplementaire. La difference entre une connexion dependency et une connexion containment est semantique, pas syntaxique. S’entrainer sur des documents qui utilisent correctement ces types apprend au modele a distinguer les relations fonctionnelles des relations structurelles. Cette distinction compte lorsqu’on demande au modele de repondre a des questions comme:

• qu’est-ce qui tombe si cette ressource devient indisponible?
• qu’est-ce qui se trouve logiquement a l’interieur de cette amazon aws vpc?
• peux-tu montrer le flux de trafic de toutes les ressources a l’interieur de cet abonnement microsoft azure?

La taxonomie des types de ressources ajoute une autre couche. La hierarchie en notation a points (compute.vm, compute.vm.template, network.switch, storage.volume) fournit une classification naturelle qu’un modele fine-tune peut internaliser, generaliser et appliquer a des ressources qu’il n’a encore jamais vues.

Pourquoi la normalisation compte pour la qualite de l’entrainement

La normalisation des producers est l’une des parties les moins discutees d’OSIRIS JSON, mais elle a un impact direct sur la qualite des donnees d’entrainement.

Avant qu’un document OSIRIS JSON n’atteigne le corpus de fine-tuning, un producer a deja:

• mappe les types de ressources specifiques au vendor vers des entrees standard de la taxonomie OSIRIS JSON
• supprime les identifiants, les tokens et les secrets via la redaction
• resolu les identifiants dupliques ou conflictuels en IDs deterministes et stables
• serialise la topologie dans une sortie coherente et triee

Le resultat est que chaque document du corpus d’entrainement est structurellement propre, avec des garde-fous en place. Il n’y a pas de mots de passe ou de secrets embarques qui enseigneraient au modele a associer des identifiants aux champs de topologie. Il n’y a pas d’instabilite des identifiants qui introduise du bruit entre plusieurs executions du meme environnement. Il n’y a pas de propriete specifique a un vendor qui entre en conflit avec la meme propriete nommee differemment par un autre vendor.

Un corpus de fine-tuning construit a partir de documents OSIRIS JSON valides par producer possede un niveau de bruit exceptionnellement bas pour un domaine aussi heterogene que l’infrastructure.

Ce que l’alignement par instruction attend des donnees

Le fine-tuning par instruction porte sur autre chose. Le but n’est pas d’enseigner une connaissance de domaine, mais d’apprendre au modele comment utiliser cette connaissance en reponse a des demandes humaines. C’est l’etape qui ameliore fortement l’utilisabilite en alignant le comportement du modele avec les attentes humaines, ce qui le rend plus utile, plus fiable et plus controlable.

Les documents OSIRIS JSON sont des artefacts ancres. Ils decrivent une infrastructure specifique a un moment donne, validee par rapport a un schema connu. C’est cet ancrage qui les rend utiles pour construire des paires d’instructions.

Un exemple d’instruction bien forme associe une question en langage naturel, un document OSIRIS JSON comme contexte, et une reponse correcte derivee de la topologie. Par exemple:

• Cette topologie a-t-elle un point unique de defaillance? Le modele lit les connexions, identifie les ressources sans chemin redondant et repond avec des IDs de ressources precis et un raisonnement explicite
• Qu’est-ce qui serait affecte si le firewall perdait son uplink? Le modele parcourt le graphe de connexions vers l’exterieur a partir de la ressource concernee et liste les ressources dependantes
• Resume cette infrastructure pour une revue d’architecture Le modele lit les types de ressources, les quantites et la structure des groupes pour produire un resume lisible par un humain
• Genere un document OSIRIS mis a jour qui ajoute une replique de secours pour la base de donnees primaire Le modele etend la topologie de maniere valide vis-a-vis du schema
• Genere une topologie exacte de mon infrastructure Microsoft Azure et documente-la au format markdown En lisant un document OSIRIS JSON, le modele est capable de creer une topologie au format draw.io ou mermaid (pour une visibilite de haut niveau) avec un document markdown qui resume la configuration de l’infrastructure a un moment donne.

La propriete cle est la verifiabilite. Parce que le document source est valide par schema et que la topologie est explicite, un relecteur humain peut verifier que la reponse du modele est correcte. Cette boucle de retour, dans laquelle des evaluateurs humains peuvent effectivement juger les reponses du modele par rapport a une verite de reference, est ce qui rend les donnees d’instruction utiles. Il est bien plus difficile de construire des paires d’instructions de qualite pour l’infrastructure lorsque les donnees source sont ambigues ou formatees de maniere incoherente.

L’attribution du provider preserve la tracabilite sans enfermer dans un biais vendor

Un choix de conception dans OSIRIS JSON qui compte pour les cas d’usage IA est l’attribution du provider.

Les ressources portent l’information sur leur provider d’origine, AWS, Azure, Arista, Cisco, Nokia, HPE, mais la structure core reste toujours neutre vis-a-vis des vendors. Un modele entraine sur des documents OSIRIS JSON apprend a associer le contexte du provider au comportement de la ressource sans apprendre que le langage de topologie core est specifique a un provider.

Cela compte en particulier pour l’alignement par instruction. Si un utilisateur demande de quel type d’infrastructure s’agit-il? le modele doit repondre d’apres la topologie, pas d’apres la reconnaissance d’un format d’export specifique a un vendor. L’attribution du provider dans OSIRIS JSON rend cette distinction explicite dans les donnees d’entrainement au lieu de laisser le modele l’inferer a partir de motifs lexicaux.

Une base structuree pour des modeles LLM d’IA conscients de l’infrastructure

La direction vers laquelle cela pointe est celle de LLM d’IA conscients de l’infrastructure, capables de raisonner sur la topologie, de faire remonter les risques, de repondre a des questions d’architecture, d’aider a la documentation et de proposer des changements fondes sur vos donnees d’inventaire reelles et a jour, et non sur un savoir et une documentation vagues, generaux ou specifiques a un vendor sur ce a quoi l’infrastructure “ressemble generalement”.

OSIRIS JSON n’est pas le seul ingredient necessaire pour cela. Mais en tant que format d’echange normalise, valide par schema et deterministe, que des producers de vendors et de plateformes differents peuvent cibler, il fournit quelque chose que le pipeline IA devrait sinon construire a partir de zero: un langage structurel coherent pour l’infrastructure.

Telle est la base OSIRIS JSON.

Lectures associees

• Lire la specification OSIRIS JSON v1.0
• Lire les concepts core
• Lire la taxonomie des types de ressources
• Lire les directives pour producers
• Lire a propos des niveaux de validation

Auteur de l’icone de la banniere Esri