Base degli AI LLM per documentazione e topologia dell’infrastruttura IT/OT

La maggior parte dei dati infrastrutturali che finisce nelle pipeline AI non è mai stata progettata per esserci.

Export grezzi dei vendor, blob JSON ad hoc e dump di log portano con sé abbastanza rumore da insegnare a un modello soprattutto a riprodurre il dialetto del vendor, non a ragionare sull’infrastruttura, incluso un potenziale rischio di trascinare dati sensibili come i secrets.

OSIRIS JSON è stato progettato per uno scopo diverso, cioè per essere:

1. portabile
2. vendor-neutral
3. in grado di normalizzare i dati di output
4. uno snapshot topologico standardizzato e validato da schema

ma proprio questo design finisce per renderlo una base utile per l’addestramento degli AI LLM. Le due fasi della pipeline LLM in cui OSIRIS JSON si inserisce in modo più naturale sono il fine-tuning e la instruction.

Cosa serve al fine-tuning dai dati

Il fine-tuning adatta un modello preaddestrato a un dominio specifico. Il segnale arriva dal corpus di training: ogni documento insegna al modello quale vocabolario è normale, quali strutture compaiono insieme, quali relazioni sono valide e quali pattern si ripetono.

Perché questo segnale sia utile, i dati devono essere coerenti. Un corpus di training formato da export grezzi Cisco NX-OS, template Azure ARM e dump VMware vCenter non insegna il ragionamento infrastrutturale. Insegna tre dialetti vendor separati. Un modello addestrato su quel mix rifletterà poi quelle incoerenze quando gli verrà chiesto di ragionare attraverso confini diversi.

OSIRIS JSON prova a rimuovere questo problema a livello di schema.

Ogni documento OSIRIS JSON, indipendentemente dal fatto che sia stato prodotto da un hyperscaler come un account AWS, da una fabric Arista on-premise o da una serie di switch Cisco Nexus, oppure da una fabric Nokia, condivide la stessa struttura esterna: version, metadata e topology. Le risorse hanno sempre id, type e provider. I tipi di connessione seguono le stesse convenzioni in dot-notation. La semantica dei gruppi è coerente.

Un corpus di fine-tuning costruito a partire da documenti OSIRIS può addestrare meglio un modello LLM sui concetti infrastrutturali, invece che sui singoli formati dei vendor che possono cambiare nel tempo man mano che il vendor aggiorna le funzionalità. Il modello impara che una network.firewall si trova tra risorse network.switch e possiede connessioni connectivity verso i segmenti che protegge. Impara che una topologia applicativa a tre livelli coinvolge in modo coerente un load balancer, risorse di compute e un database a livello applicativo. Impara com’è fatta una relazione containment valida rispetto a una dependency.

Questo è il tipo giusto di conoscenza di dominio su cui specializzare un modello.

La struttura a grafo è un segnale di training naturale

OSIRIS JSON modella l’infrastruttura come un grafo esplicito: le risorse sono nodi, le connessioni sono archi e i gruppi raggruppano entrambi entro confini logici o fisici.

La struttura a grafo è insolitamente preziosa nei dati di training perché codifica le relazioni in modo esplicito. In un testo non strutturato, il modello deve inferire che un firewall si trovi a monte dei server che protegge. In un documento OSIRIS JSON, quella relazione è una connessione tipizzata e direzionale con source, target e type. Il modello non deve indovinare: legge una struttura costruita deliberatamente per esprimere esattamente quella topologia.

La tassonomia dei tipi di connessione aggiunge ulteriore segnale. La differenza tra una connessione dependency e una connessione containment è semantica, non sintattica. Addestrare su documenti che usano correttamente questi tipi insegna al modello a distinguere le relazioni funzionali da quelle strutturali. Questa distinzione conta quando a un modello vengono poste domande come:

• cosa si rompe se questa risorsa va giù?
• cosa si trova logicamente dentro questa VPC Amazon AWS?
• puoi mostrare il flusso di traffico di tutte le risorse all’interno di questa subscription Microsoft Azure?

La tassonomia dei tipi di risorsa aggiunge un ulteriore livello. La gerarchia in dot-notation (compute.vm, compute.vm.template, network.switch, storage.volume) fornisce una classificazione naturale che un modello fine-tuned può interiorizzare, generalizzare e applicare a risorse che non ha mai visto prima.

Perché la normalizzazione conta per la qualità del training

La normalizzazione del producer è una delle parti meno discusse di OSIRIS JSON, ma ha un impatto diretto sulla qualità dei dati di training.

Prima che un documento OSIRIS JSON arrivi nel corpus di fine-tuning, un producer ha già:

• mappato i tipi di risorsa vendor-specific agli elementi standard della tassonomia OSIRIS JSON
• rimosso credenziali, token e secrets tramite redaction
• risolto identificatori duplicati o in conflitto in ID stabili e deterministici
• serializzato la topologia in un output coerente e ordinato

Il risultato è che ogni documento nel corpus di training è strutturalmente pulito e dispone di guardrail. Non ci sono password incorporate o secrets che insegnino al modello ad associare credenziali ai campi topologici. Non c’è instabilità negli identificatori che introduca rumore tra esecuzioni diverse dello stesso ambiente. Non c’è una proprietà vendor-specific che vada in conflitto con la stessa proprietà nominata in modo diverso da un altro vendor.

Un corpus di fine-tuning costruito a partire da documenti OSIRIS JSON validati dal producer presenta un livello di rumore insolitamente basso per un dominio eterogeneo come l’infrastruttura.

Cosa serve all’instruction alignment dai dati

L’instruction fine-tuning riguarda qualcosa di diverso. L’obiettivo non è insegnare la conoscenza di dominio, ma insegnare al modello come usare quella conoscenza in risposta a richieste umane. Questa è la fase che migliora drasticamente l’usabilità allineando il comportamento del modello alle aspettative umane, rendendolo più utile, affidabile e controllabile.

I documenti OSIRIS JSON sono artefatti fondati. Descrivono un’infrastruttura specifica in uno specifico momento, validata rispetto a uno schema noto. È proprio questa aderenza al dato reale a renderli utili per costruire coppie di instruction.

Un esempio di instruction ben formato abbina una domanda in linguaggio naturale, un documento OSIRIS JSON come contesto e una risposta corretta derivata dalla topologia. Per esempio:

• Questa topologia ha un single point of failure? Il modello legge le connessioni, identifica le risorse prive di percorso ridondante e risponde con ID di risorsa specifici e relativo ragionamento
• Cosa verrebbe impattato se il firewall perdesse il suo uplink? Il modello attraversa la topologia delle connessioni a partire dalla risorsa rilevante ed elenca le risorse dipendenti
• Riassumi questa infrastruttura per una architecture review Il modello legge tipi di risorsa, conteggi e struttura dei gruppi per produrre un riepilogo leggibile da esseri umani
• Genera un documento OSIRIS aggiornato che aggiunga una replica standby per il database primario Il modello estende la topologia in modo valido rispetto allo schema
• Genera una topologia accurata della mia infrastruttura Microsoft Azure e documentala in formato markdown Il modello, leggendo un documento OSIRIS JSON, è in grado di creare una topologia in formato draw.io o mermaid, per visibilità di alto livello, insieme a un documento markdown che riassuma la configurazione dell’infrastruttura in un dato momento

La proprietà chiave è la verificabilità. Poiché il documento sorgente è validato da schema e la topologia è esplicita, un revisore umano può controllare che la risposta del modello sia corretta. Questo ciclo di feedback, in cui valutatori umani possono davvero confrontare le risposte del modello con una ground truth, è ciò che rende utili i dati di instruction. È molto più difficile costruire coppie di instruction di qualità per l’infrastruttura quando i dati sorgente sono ambigui o formattati in modo incoerente.

L’attribuzione del provider preserva la tracciabilita senza fissare un vendor bias

Una scelta progettuale in OSIRIS JSON che conta per i casi d’uso AI è l’attribuzione del provider.

Le risorse portano con se le informazioni sul provider di origine, AWS, Azure, Arista, Cisco, Nokia, HPE, ma la struttura core resta sempre vendor-neutral. Un modello addestrato su documenti OSIRIS JSON impara ad associare il contesto del provider al comportamento della risorsa senza imparare che il linguaggio topologico di base sia provider-specific.

Questo conta in particolare per l’instruction alignment. Se un utente chiede che tipo di infrastruttura è questa?, il modello dovrebbe rispondere in base alla topologia, non in base al riconoscimento del formato di export di uno specifico vendor. L’attribuzione del provider in OSIRIS JSON rende esplicita questa distinzione nei dati di training invece di lasciare al modello il compito di inferirla da pattern lessicali.

Una base strutturata per modelli AI LLM consapevoli dell’infrastruttura

La direzione verso cui tutto questo punta è quella di AI LLM consapevoli dell’infrastruttura, capaci di ragionare sulla topologia, far emergere rischi, rispondere a domande architetturali, assistere nella documentazione e proporre modifiche basate sui tuoi dati di inventario reali e aggiornati, non su conoscenza e documentazione vaga, generale o vendor-specific di come l’infrastruttura “di solito” appare.

OSIRIS JSON non è l’unico ingrediente necessario. Ma, come formato di interscambio normalizzato, validato da schema e deterministico che producer di vendor e piattaforme diverse possono prendere come target, fornisce qualcosa che la pipeline AI altrimenti dovrebbe costruire da zero: un linguaggio strutturale coerente per l’infrastruttura.

Questa è la base di OSIRIS JSON.

Letture correlate

• Leggi la specifica OSIRIS JSON v1.0
• Leggi i concetti core
• Leggi la tassonomia dei tipi di risorsa
• Leggi le linee guida per i producer
• Leggi i livelli di validazione

Autore dell’icona del banner Esri