Base de LLM de IA para documentacion y topologia de infraestructura IT/OT

La mayor parte de los datos de infraestructura que acaba en pipelines de IA nunca se diseno para estar ahi.

Las exportaciones brutas de vendors, los blobs JSON ad hoc y los dumps de logs arrastran suficiente ruido como para que entrenar sobre ellos ensene a un modelo sobre todo a reproducir el dialecto del vendor, no a razonar sobre infraestructura, incluyendo un riesgo potencial de arrastrar datos sensibles como secretos. OSIRIS JSON se diseno para un objetivo distinto, para ser:

1. portable
2. neutral respecto al vendor
3. normalizar los datos de salida
4. snapshots de topologia estandarizados y validados por schema

pero ese diseno resulta ser exactamente lo que lo hace util como base de entrenamiento para LLM de IA. Las dos etapas del pipeline de LLM donde OSIRIS JSON encaja de forma mas natural son fine-tuning e instruccion.

Lo que necesita el fine-tuning de los datos

El fine-tuning adapta un modelo preentrenado a un dominio especifico. La senal viene del corpus de entrenamiento: cada documento ensena al modelo que vocabulario es normal, que estructuras aparecen juntas, que relaciones son validas y que patrones se repiten.

Para que esa senal sea util, los datos tienen que ser consistentes. Un corpus de entrenamiento hecho de exportaciones brutas de Cisco NX-OS, templates Azure ARM y dumps de VMware vCenter no ensena razonamiento sobre infraestructura. Ensena tres dialectos de vendor distintos. Un modelo entrenado con esa mezcla reflejara esas inconsistencias cuando se le pida razonar a traves de fronteras.

OSIRIS JSON intenta eliminar ese problema a nivel de schema.

Cada documento OSIRIS JSON, tanto si se produce desde un hyperscaler como una cuenta de AWS, como desde un fabric Arista on-premise o una serie de switches Cisco Nexus, o desde un fabric Nokia, comparte la misma estructura externa: version, metadata y topology. Los recursos siempre tienen id, type y provider. Los tipos de conexion siguen las mismas convenciones de notacion por puntos. La semantica de grupos es consistente.

Un corpus de fine-tuning construido a partir de documentos OSIRIS puede entrenar mejor a un modelo LLM en conceptos de infraestructura, no en los formatos de cada vendor, que podrian cambiar con el tiempo a medida que el vendor actualiza funcionalidades. El modelo aprende que un network.firewall se situa entre recursos network.switch y tiene conexiones connectivity hacia los segmentos que protege. Aprende que una topologia de aplicacion de tres capas implica de forma consistente un load balancer, recursos de computacion y una base de datos de capa de aplicacion. Aprende como es una relacion containment valida frente a una dependency.

Ese es el tipo correcto de conocimiento de dominio para especializar un modelo.

La estructura de grafo es una senal natural de entrenamiento

OSIRIS JSON modela la infraestructura como un grafo explicito: los recursos son nodos, las conexiones son aristas y los grupos agrupan ambos en fronteras logicas o fisicas.

La estructura de grafo es especialmente valiosa en los datos de entrenamiento porque codifica relaciones explicitamente. En texto no estructurado, el modelo tiene que inferir que un firewall esta aguas arriba de los servidores que protege. En un documento OSIRIS JSON, esa relacion es una conexion tipada y direccional con source, target y type. El modelo no tiene que adivinarlo, lee una estructura que se construyo deliberadamente para expresar exactamente esa topologia.

La taxonomia de tipos de conexion aporta una senal adicional. La diferencia entre una conexion dependency y una conexion containment es semantica, no sintactica. Entrenar sobre documentos que usan correctamente esos tipos ensena a un modelo a distinguir relaciones funcionales de relaciones estructurales. Esa distincion importa cuando se le pide al modelo responder preguntas como:

• que se rompe si este recurso cae?
• que hay logicamente dentro de esta amazon aws vpc?
• puedes mostrar el flujo de trafico de todos los recursos dentro de esta suscripcion de microsoft azure?

La taxonomia de tipos de recursos anade otra capa. La jerarquia de notacion por puntos (compute.vm, compute.vm.template, network.switch, storage.volume) proporciona una clasificacion natural que un modelo ajustado con fine-tuning puede interiorizar, generalizar y aplicar a recursos que nunca ha visto antes.

Por que la normalizacion importa para la calidad del entrenamiento

La normalizacion de producers es una de las partes menos comentadas de OSIRIS JSON, pero tiene un impacto directo en la calidad de los datos de entrenamiento.

Antes de que un documento OSIRIS JSON llegue al corpus de fine-tuning, un producer ya:

• ha mapeado tipos de recursos especificos del vendor a entradas estandar de la taxonomia de OSIRIS JSON
• ha eliminado credenciales, tokens y secretos mediante redaction
• ha resuelto identificadores duplicados o conflictivos en ID estables y deterministas
• ha serializado la topologia en una salida consistente y ordenada

El resultado es que cada documento del corpus de entrenamiento esta estructuralmente limpio y con guardrails en su sitio. No hay contrasenas ni secretos incrustados que ensenen al modelo a asociar credenciales con campos de topologia. No hay inestabilidad de identificadores que introduzca ruido entre ejecuciones del mismo entorno. No hay propiedades especificas de un vendor que entren en conflicto con la misma propiedad nombrada de forma distinta por otro vendor.

Un corpus de fine-tuning construido a partir de documentos OSIRIS JSON validados por producer tiene un suelo de ruido inusualmente bajo para un dominio tan heterogeneo como la infraestructura.

Lo que necesita la alineacion por instruccion de los datos

El fine-tuning por instruccion trata de algo distinto. El objetivo no es ensenar conocimiento de dominio, sino ensenar al modelo a usar ese conocimiento en respuesta a peticiones humanas. Esta es la etapa que mejora dramaticamente la usabilidad al alinear el comportamiento del modelo con las expectativas humanas, haciendolo mas util, fiable y controlable.

Los documentos OSIRIS JSON son artefactos fundamentados. Describen una infraestructura especifica en un punto concreto del tiempo, validada frente a un schema conocido. Ese anclaje es lo que los hace utiles para construir pares de instrucciones.

Un ejemplo bien formado de instruccion empareja una pregunta en lenguaje natural, un documento OSIRIS JSON como contexto y una respuesta correcta derivada de la topologia. Por ejemplo:

• Tiene esta topologia un punto unico de fallo? El modelo lee las conexiones, identifica recursos sin camino redundante y responde con ID de recursos especificos y razonamiento
• Que se veria afectado si el firewall perdiera su uplink? El modelo recorre hacia fuera el grafo de conexiones desde el recurso relevante y enumera los recursos dependientes
• Resume esta infraestructura para una revision de arquitectura El modelo lee tipos de recursos, cantidades y estructura de grupos para producir un resumen legible por humanos
• Genera un documento OSIRIS actualizado que anada una replica en standby para la base de datos primaria El modelo extiende la topologia de una forma valida respecto al schema
• Genera una topologia precisa de mi infraestructura de Microsoft Azure y documentala en formato markdown Al leer un documento OSIRIS JSON, el modelo es capaz de crear una topologia en formato draw.io o mermaid (para visibilidad de alto nivel) junto con un documento markdown que resume la configuracion de la infraestructura en un punto del tiempo.

La propiedad clave es la verificabilidad. Como el documento fuente esta validado por schema y la topologia es explicita, un revisor humano puede comprobar que la respuesta del modelo es correcta. Ese bucle de feedback, en el que evaluadores humanos pueden realmente contrastar respuestas del modelo con una verdad de referencia, es lo que hace utiles los datos de instruccion. Es mucho mas dificil construir pares de instrucciones de calidad para infraestructura cuando los datos fuente son ambiguos o tienen formatos inconsistentes.

La atribucion del provider preserva la trazabilidad sin bloquearse en un sesgo de vendor

Una decision de diseno en OSIRIS JSON que importa para casos de uso de IA es la atribucion del provider.

Los recursos llevan la informacion de su provider de origen, AWS, Azure, Arista, Cisco, Nokia, HPE, pero la estructura core sigue siendo siempre neutral respecto al vendor. Un modelo entrenado con documentos OSIRIS JSON aprende a asociar el contexto del provider con el comportamiento del recurso sin aprender que el lenguaje de topologia core es especifico de un provider.

Esto importa especialmente para la alineacion por instruccion. Si un usuario pregunta que tipo de infraestructura es esta? el modelo deberia responder basandose en la topologia, no en reconocer un formato de exportacion especifico de un vendor. La atribucion del provider en OSIRIS JSON hace explicita esa distincion en los datos de entrenamiento en lugar de dejar que el modelo la infiera a partir de patrones lexicos.

Una base estructurada para modelos LLM de IA conscientes de la infraestructura

La direccion a la que apunta esto es la de LLM de IA conscientes de la infraestructura, capaces de razonar sobre topologia, aflorar riesgos, responder preguntas de arquitectura, asistir con documentacion y proponer cambios fundamentados en tus datos reales y actualizados de inventario, no en conocimiento y documentacion vagos y generales o especificos del vendor sobre como “suele” ser una infraestructura.

OSIRIS JSON no es el unico ingrediente para eso. Pero, como formato de intercambio normalizado, validado por schema y determinista, al que pueden dirigirse producers de distintos vendors y plataformas, proporciona algo que el pipeline de IA tendria que construir desde cero de otra manera: un lenguaje estructural consistente para infraestructura.

Esta es la base de OSIRIS JSON.

Lecturas relacionadas

• Leer la especificacion de OSIRIS JSON v1.0
• Leer los conceptos core
• Leer la taxonomia de tipos de recurso
• Leer las directrices para producers
• Leer sobre los niveles de validacion

Autor del icono del banner Esri