Base de LLMs de IA para documentacao e topologia de infraestrutura IT/OT

A maior parte dos dados de infraestrutura que acaba em pipelines de IA nunca foi pensada para estar ali.

Exports brutos de vendors, blobs JSON ad hoc e dumps de logs carregam ruido suficiente para que o treinamento nesses dados ensine um modelo principalmente a reproduzir o dialeto do vendor, e nao a raciocinar sobre infraestrutura, incluindo um risco potencial de carregar dados sensiveis como segredos. O OSIRIS JSON foi projetado para um proposito diferente, para ser:

1. portavel
2. neutro em relacao a vendors
3. normalizar dados de saida
4. snapshots de topologia padronizados e validados por schema

mas esse desenho acaba sendo exatamente o que o torna util como base de treinamento para LLMs de IA. As duas etapas do pipeline de LLM em que o OSIRIS JSON se encaixa de forma mais natural sao fine-tuning e instrucao.

O que o fine-tuning precisa dos dados

O fine-tuning adapta um modelo pretreinado a um dominio especifico. O sinal vem do corpus de treinamento: cada documento ensina ao modelo qual vocabulario e normal, quais estruturas aparecem juntas, quais relacoes sao validas e quais padroes se repetem.

Para que esse sinal seja util, os dados precisam ser consistentes. Um corpus de treinamento feito de exports brutos de Cisco NX-OS, templates Azure ARM e dumps de VMware vCenter nao ensina raciocinio sobre infraestrutura. Ele ensina tres dialetos de vendor separados. Um modelo treinado nessa mistura refletira essas inconsistencias de volta quando for solicitado a raciocinar atraves de fronteiras.

O OSIRIS JSON tenta remover esse problema no nivel do schema.

Todo documento OSIRIS JSON, independentemente de ter sido produzido a partir de um hyperscaler como uma conta AWS, de um fabric Arista on-premise ou de uma serie de switches Cisco Nexus, ou ainda de um fabric Nokia, compartilha a mesma estrutura externa: version, metadata e topology. Recursos sempre tem id, type e provider. Tipos de conexao seguem as mesmas convencoes de notacao por pontos. A semantica de grupos e consistente.

Um corpus de fine-tuning construido a partir de documentos OSIRIS pode treinar melhor um modelo LLM em conceitos de infraestrutura, e nao nos formatos de cada vendor, que podem eventualmente mudar ao longo do tempo conforme o vendor atualiza recursos. O modelo aprende que um network.firewall fica entre recursos network.switch e possui conexoes connectivity com os segmentos que protege. Aprende que uma topologia de aplicacao em tres camadas envolve de forma consistente um load balancer, recursos de computacao e um banco de dados da camada de aplicacao. Aprende como e uma relacao containment valida em contraste com uma dependency.

Esse e o tipo certo de conhecimento de dominio para especializar um modelo.

A estrutura de grafo e um sinal natural de treinamento

O OSIRIS JSON modela infraestrutura como um grafo explicito: recursos sao nos, conexoes sao arestas e grupos agrupam ambos em fronteiras logicas ou fisicas.

A estrutura de grafo e incomumente valiosa em dados de treinamento porque codifica relacionamentos explicitamente. Em texto nao estruturado, o modelo precisa inferir que um firewall esta a montante dos servidores que protege. Em um documento OSIRIS JSON, esse relacionamento e uma conexao tipada e direcional com source, target e type. O modelo nao precisa adivinhar, ele le uma estrutura que foi construida deliberadamente para expressar exatamente aquela topologia.

A taxonomia de tipos de conexao carrega sinal adicional. A diferenca entre uma conexao dependency e uma conexao containment e semantica, nao sintatica. Treinar em documentos que usam corretamente esses tipos ensina um modelo a distinguir relacionamentos funcionais de estruturais. Essa distincao importa quando se pede ao modelo para responder perguntas como:

• o que quebra se este recurso sair do ar?
• o que esta logicamente dentro desta amazon aws vpc?
• voce pode mostrar o fluxo de trafego de todos os recursos dentro desta assinatura microsoft azure?

A taxonomia de tipos de recursos adiciona outra camada. A hierarquia por notacao de pontos (compute.vm, compute.vm.template, network.switch, storage.volume) fornece uma classificacao natural que um modelo ajustado por fine-tuning pode internalizar, generalizar e aplicar a recursos que nunca viu antes.

Por que a normalizacao importa para a qualidade do treinamento

A normalizacao de producers e uma das partes menos discutidas do OSIRIS JSON, mas tem impacto direto na qualidade dos dados de treinamento.

Antes que um documento OSIRIS JSON chegue ao corpus de fine-tuning, um producer ja:

• mapeou tipos de recursos especificos de vendor para entradas padrao da taxonomia OSIRIS JSON
• removeu credenciais, tokens e segredos por meio de redaction
• resolveu identificadores duplicados ou conflitantes em IDs estaveis e deterministicas
• serializou a topologia em uma saida consistente e ordenada

O resultado e que todo documento no corpus de treinamento fica estruturalmente limpo, com guardrails em vigor. Nao existem senhas ou segredos embutidos ensinando o modelo a associar credenciais a campos de topologia. Nao ha instabilidade de identificadores introduzindo ruido entre execucoes do mesmo ambiente. Nao ha propriedade especifica de vendor em conflito com a mesma propriedade nomeada de forma diferente por outro vendor.

Um corpus de fine-tuning construido a partir de documentos OSIRIS JSON validados por producer tem um piso de ruido incomumente baixo para um dominio tao heterogeneo quanto infraestrutura.

O que o alinhamento por instrucao precisa dos dados

O fine-tuning por instrucao trata de algo diferente. O objetivo nao e ensinar conhecimento de dominio, e ensinar o modelo a usar esse conhecimento em resposta a pedidos humanos. Esta e a etapa que melhora dramaticamente a usabilidade ao alinhar o comportamento do modelo com expectativas humanas, tornando-o mais util, confiavel e controlavel.

Documentos OSIRIS JSON sao artefatos ancorados. Eles descrevem uma infraestrutura especifica em um ponto especifico no tempo, validada contra um schema conhecido. Esse enraizamento e o que os torna uteis para construir pares de instrucao.

Um exemplo bem formado de instrucao combina uma pergunta em linguagem natural, um documento OSIRIS JSON como contexto e uma resposta correta derivada da topologia. Por exemplo:

• Esta topologia tem um ponto unico de falha? O modelo le as conexoes, identifica recursos sem caminho redundante e responde com IDs de recursos especificos e raciocinio
• O que seria afetado se o firewall perdesse seu uplink? O modelo percorre o grafo de conexoes para fora a partir do recurso relevante e lista os recursos dependentes
• Resuma esta infraestrutura para uma revisao de arquitetura O modelo le tipos de recurso, contagens e a estrutura de grupos para produzir um resumo legivel por humanos
• Gere um documento OSIRIS atualizado que adicione uma replica em standby ao banco de dados primario O modelo estende a topologia de forma valida em relacao ao schema
• Gere uma topologia precisa da minha infraestrutura Microsoft Azure e documente-a em formato markdown Lendo um documento OSIRIS JSON, o modelo e capaz de criar uma topologia em formato draw.io ou mermaid (para visibilidade de alto nivel) junto com um documento markdown que resume a configuracao da infraestrutura em um ponto no tempo.

A propriedade chave aqui e a verificabilidade. Como o documento-fonte e validado por schema e a topologia e explicita, um revisor humano pode verificar se a resposta do modelo esta correta. Esse ciclo de feedback, em que avaliadores humanos podem de fato avaliar respostas do modelo contra uma verdade de referencia, e o que torna dados de instrucao uteis. E muito mais dificil construir pares de instrucao de qualidade para infraestrutura quando os dados-fonte sao ambiguos ou formatados de forma inconsistente.

A atribuicao de provider preserva rastreabilidade sem prender o modelo a vies de vendor

Uma decisao de projeto no OSIRIS JSON que importa para casos de uso de IA e a atribuicao de provider.

Os recursos carregam a informacao do provider de origem, AWS, Azure, Arista, Cisco, Nokia, HPE, mas a estrutura core permanece sempre neutra em relacao a vendors. Um modelo treinado em documentos OSIRIS JSON aprende a associar contexto de provider ao comportamento do recurso sem aprender que a linguagem de topologia core e especifica de provider.

Isso importa em especial para alinhamento por instrucao. Se um usuario pergunta que tipo de infraestrutura e esta? o modelo deve responder com base na topologia, e nao por reconhecer um formato de export especifico de vendor. A atribuicao de provider no OSIRIS JSON torna essa distincao explicita nos dados de treinamento em vez de deixar que o modelo a infira a partir de padroes lexicais.

Uma base estruturada para modelos LLM de IA conscientes de infraestrutura

A direcao para a qual isso aponta e a de LLMs de IA conscientes de infraestrutura, capazes de raciocinar sobre topologia, expor riscos, responder perguntas de arquitetura, ajudar na documentacao e propor mudancas fundamentadas em seus dados reais de inventario atualizados, e nao em conhecimento e documentacao vagos e genericos ou especificos de vendor sobre como a infraestrutura “normalmente” se parece.

O OSIRIS JSON nao e o unico ingrediente para isso. Mas, como formato de intercambio normalizado, validado por schema e deterministico, que producers em diferentes vendors e plataformas podem adotar, ele fornece algo que o pipeline de IA teria de construir do zero: uma linguagem estrutural consistente para infraestrutura.

Essa e a base OSIRIS JSON.

Leituras relacionadas

• Ler a especificacao do OSIRIS JSON v1.0
• Ler os conceitos core
• Ler a taxonomia de tipos de recursos
• Ler as diretrizes para producers
• Ler sobre niveis de validacao

Autor do icone do banner Esri