Base de LLM d’IA per a documentacio i topologia d’infraestructura IT/OT
La major part de les dades d’infraestructura que acaben en pipelines d’IA mai no es van dissenyar per ser-hi.
Els exports bruts de vendors, els blobs JSON ad hoc i els dumps de logs arrosseguen prou soroll perque entrenar-hi ensenyi a un model sobretot a reproduir el dialecte del vendor, no a raonar sobre infraestructura, incloent-hi un risc potencial d’arrossegar dades sensibles com secrets. OSIRIS JSON es va dissenyar per a un altre proposit, per ser:
- portable
- neutre respecte del vendor
- normalitzar les dades de sortida
- snapshots de topologia estandarditzats i validats per schema
pero aquest disseny resulta ser exactament allo que el fa util com a base d’entrenament per a LLM d’IA. Les dues etapes del pipeline de LLM on OSIRIS JSON encaixa de manera mes natural son fine-tuning i instruccio.
El que necessita el fine-tuning de les dades
El fine-tuning adapta un model preentrenat a un domini especific. El senyal prove del corpus d’entrenament: cada document ensenya al model quin vocabulari es normal, quines estructures apareixen juntes, quines relacions son valides i quins patrons es repeteixen.
Perque aquest senyal sigui util, les dades han de ser consistents. Un corpus d’entrenament format per exports bruts de Cisco NX-OS, templates Azure ARM i dumps de VMware vCenter no ensenya raonament sobre infraestructura. Ensenya tres dialectes de vendor separats. Un model entrenat amb aquesta barreja reflectira aquestes inconsistencies quan se li demani raonar a traves de fronteres.
OSIRIS JSON intenta eliminar aquest problema al nivell del schema.
Cada document OSIRIS JSON, tant si s’ha produit a partir d’un hyperscaler com un compte d’AWS, d’un fabric Arista on-premise o d’una serie de switches Cisco Nexus, o d’un fabric Nokia, comparteix la mateixa estructura externa: version, metadata i topology. Els recursos sempre tenen id, type i provider. Els tipus de connexio segueixen les mateixes convencions de notacio per punts. La semantica de grups es consistent.
Un corpus de fine-tuning construit a partir de documents OSIRIS podria entrenar millor un model LLM en conceptes d’infraestructura, i no en els formats de cada vendor, que eventualment poden canviar amb el temps a mesura que el vendor actualitza funcionalitats. El model apren que un network.firewall se situa entre recursos network.switch i te connexions connectivity cap als segments que protegeix. Apren que una topologia d’aplicacio de tres capes implica de manera consistent un load balancer, recursos de computacio i una base de dades de capa d’aplicacio. Apren com es una relacio containment valida en contrast amb una dependency.
Aquest es el tipus correcte de coneixement de domini per especialitzar un model.
L’estructura de graf es un senyal natural d’entrenament
OSIRIS JSON modela la infraestructura com un graf explicit: els recursos son nodes, les connexions son arestes i els grups agrupen tots dos en fronteres logiques o fisiques.
L’estructura de graf es especialment valuosa en les dades d’entrenament perque codifica relacions explicitament. En text no estructurat, el model ha d’inferir que un firewall es troba aigues amunt dels servidors que protegeix. En un document OSIRIS JSON, aquesta relacio es una connexio tipada i direccional amb source, target i type. El model no ho ha d’endevinar, llegeix una estructura construida deliberadament per expressar exactament aquella topologia.
La taxonomia de tipus de connexio aporta senyal addicional. La diferencia entre una connexio dependency i una connexio containment es semantica, no sintactica. Entrenar amb documents que fan servir correctament aquests tipus ensenya a un model a distingir relacions funcionals de relacions estructurals. Aquesta distincio importa quan se li demana al model que respongui preguntes com:
- que es trenca si aquest recurs cau?
- que hi ha logicament dins d’aquesta amazon aws vpc?
- pots mostrar el flux de trafic de tots els recursos dins d’aquesta subscripcio de microsoft azure?
La taxonomia de tipus de recursos afegeix una altra capa. La jerarquia de notacio per punts (compute.vm, compute.vm.template, network.switch, storage.volume) proporciona una classificacio natural que un model ajustat amb fine-tuning pot interioritzar, generalitzar i aplicar a recursos que no ha vist mai abans.
Per que la normalitzacio importa per a la qualitat de l’entrenament
La normalitzacio de producers es una de les parts menys comentades d’OSIRIS JSON, pero te un impacte directe en la qualitat de les dades d’entrenament.
Abans que un document OSIRIS JSON arribi al corpus de fine-tuning, un producer ja:
- ha mapejat tipus de recursos especifics del vendor a entrades estandard de la taxonomia d’OSIRIS JSON
- ha eliminat credencials, tokens i secrets mitjancant redaction
- ha resolt identificadors duplicats o conflictius en ID estables i deterministes
- ha serialitzat la topologia en una sortida consistent i ordenada
El resultat es que cada document del corpus d’entrenament queda estructuralment net i amb guardrails en vigor. No hi ha contrasenyes ni secrets incrustats que ensenyin el model a associar credencials amb camps de topologia. No hi ha inestabilitat d’identificadors que introdueixi soroll entre execucions del mateix entorn. No hi ha cap propietat especifica d’un vendor que entri en conflicte amb la mateixa propietat anomenada de manera diferent per un altre vendor.
Un corpus de fine-tuning construit a partir de documents OSIRIS JSON validats per producer te un nivell de soroll inusualment baix per a un domini tan heterogeni com la infraestructura.
El que necessita l’alineacio per instruccio de les dades
El fine-tuning per instruccio tracta una cosa diferent. L’objectiu no es ensenyar coneixement de domini, sino ensenyar al model com fer servir aquest coneixement en resposta a peticions humanes. Aquesta es l’etapa que millora dramaticament la usabilitat alineant el comportament del model amb les expectatives humanes, i fent-lo mes util, fiable i controlable.
Els documents OSIRIS JSON son artefactes arrelats. Descriuen una infraestructura especifica en un punt concret del temps, validada contra un schema conegut. Aquest arrelament es el que els fa utils per construir parells d’instruccions.
Un exemple ben format d’instruccio aparella una pregunta en llenguatge natural, un document OSIRIS JSON com a context i una resposta correcta derivada de la topologia. Per exemple:
- Aquesta topologia te un punt unic de fallada? El model llegeix les connexions, identifica recursos sense cami redundant i respon amb ID de recursos specifics i raonament
- Que es veuria afectat si el firewall perdes el seu uplink? El model recorre cap enfora el graf de connexions a partir del recurs rellevant i llista els recursos dependents
- Resumeix aquesta infraestructura per a una revisio d’arquitectura El model llegeix tipus de recursos, quantitats i estructura de grups per produir un resum llegible per humans
- Genera un document OSIRIS actualitzat que afegeixi una replica en standby per a la base de dades primaria El model esten la topologia d’una manera valida respecte del schema
- Genera una topologia precisa de la meva infraestructura de Microsoft Azure i documenta-la en format markdown Llegint un document OSIRIS JSON, el model es capac de crear una topologia en format draw.io o mermaid (per a visibilitat d’alt nivell) juntament amb un document markdown que resumeix la configuracio de la infraestructura en un punt del temps.
La propietat clau es la verificabilitat. Com que el document font esta validat per schema i la topologia es explicita, un revisor huma pot comprovar que la resposta del model es correcta. Aquest bucle de feedback, en que avaluadors humans poden realment contrastar respostes del model amb una veritat de referencia, es el que fa utils les dades d’instruccio. Es molt mes dificil construir parells d’instruccions de qualitat per a infraestructura quan les dades font son ambigues o tenen formats inconsistents.
L’atribucio del provider preserva la tracabilitat sense bloquejar-se en un biaix de vendor
Una decisio de disseny d’OSIRIS JSON que importa per a casos d’us d’IA es l’atribucio del provider.
Els recursos porten la informacio del provider d’origen, AWS, Azure, Arista, Cisco, Nokia, HPE, pero l’estructura core continua sent sempre neutral respecte del vendor. Un model entrenat amb documents OSIRIS JSON apren a associar el context del provider amb el comportament del recurs sense aprendre que el llenguatge de topologia core es especific d’un provider.
Aixo importa especialment per a l’alineacio per instruccio. Si un usuari pregunta quin tipus d’infraestructura es aquesta? el model hauria de respondre basant-se en la topologia, i no en reconeixer un format d’exportacio especific d’un vendor. L’atribucio del provider en OSIRIS JSON fa explicita aquesta distincio en les dades d’entrenament en lloc de deixar que el model la infereixi a partir de patrons lexics.
Una base estructurada per a models LLM d’IA conscients de la infraestructura
La direccio cap a la qual apunta aixo es la de LLM d’IA conscients de la infraestructura, capacos de raonar sobre topologia, aflorar riscos, respondre preguntes d’arquitectura, ajudar amb documentacio i proposar canvis fonamentats en les teves dades reals i actualitzades d’inventari, i no en coneixement i documentacio vags i generals o especifics del vendor sobre com “sol” ser una infraestructura.
OSIRIS JSON no es l’unic ingredient per a aixo. Pero, com a format d’intercanvi normalitzat, validat per schema i determinista, al qual poden apuntar producers de diferents vendors i plataformes, proporciona una cosa que el pipeline d’IA hauria de construir des de zero d’una altra manera: un llenguatge estructural consistent per a infraestructura.
Aquesta es la base d’OSIRIS JSON.
Lectures relacionades
- Llegir l’especificacio d’OSIRIS JSON v1.0
- Llegir els conceptes core
- Llegir la taxonomia de tipus de recurs
- Llegir les directrius per a producers
- Llegir sobre els nivells de validacio
Autor de la icona del banner Esri