Model Registry

Um registro de modelos é um sistema centralizado para organizar, versionar, governar e recuperar modelos de machine learning ao longo de todo o seu ciclo de vida. Ele conecta arquivos de modelos, como model weights aprendidos, com metadados que descrevem como cada modelo foi treinado, avaliado, aprovado e implantado. Como um componente central das machine learning operations, um registro oferece às equipes uma fonte confiável para decidir qual versão de modelo deve atender ao tráfego de produção.

Como Funciona um Registro de Modelos#

O registro de modelos começa após uma execução de treinamento gerar um modelo candidato. O registro cria uma entrada nomeada, atribui uma versão e grava as informações necessárias para entender e reproduzir o artefato. Uma entrada típica inclui:

• Artefato do modelo: Os pesos serializados, a lógica de pré-processamento, os arquivos de configuração ou uma referência à sua localização de armazenamento.
• Versão: Um identificador imutável que diferencia um candidato do outro.
• Métricas e parâmetros: Acurácia de validação, precisão, revocação (recall), latência, detalhes do conjunto de dados, hiperparâmetros e outras medições.
• Linhagem: Conexões entre o modelo, seu código-fonte, a execução de treinamento e os dados.
• Status: Rótulos como candidato, aprovado, rejeitado, campeão (champion) ou arquivado.
• Informações de implantação: Ambientes e endpoints que utilizam a versão atualmente.

As plataformas implementam essas ideias de maneiras diferentes. O MLflow Model Registry workflow utiliza modelos registrados, versões, aliases e tags, enquanto o Amazon SageMaker Model Registry oferece suporte a grupos de modelos, estados de aprovação, linhagem e automação de implantação. Alguns sistemas também registram uma assinatura de modelo: o esquema de entrada e saída esperado descrito na Snowflake model signature documentation.

Aliases como champion ou production fornecem nomes estáveis que podem alternar entre versões imutáveis. Conforme explicado no Vertex AI model alias guide, uma aplicação pode solicitar um alias sem precisar fixar um número de versão no código.

Registro de Modelos vs. Conceitos Relacionados#

Um registro de modelos se sobrepõe a várias ferramentas de ML, mas possui um propósito distinto:

• O Experiment tracking registra execuções de treinamento, incluindo parâmetros, métricas e artefatos intermediários. Um registro recebe saídas selecionadas desses experimentos e as gerencia como candidatos a lançamento.
• O armazenamento de artefatos mantém arquivos grandes. Um registro pode armazenar esses arquivos diretamente, mas também pode funcionar como um índice de metadados que aponta para um armazenamento de objetos externo. A Kubeflow Model Registry architecture ilustra esse design centrado em metadados.
• O controle de versão versiona o código, enquanto um registro de modelos versiona os artefatos treinados e seus metadados específicos de ML. O GitLab model registry pode conectar versões de modelos a jobs de CI/CD, logs, métricas e parâmetros.
• A Model deployment disponibiliza um modelo selecionado para inferência. O registro identifica o artefato aprovado; o sistema de implantação o executa.
• A Model monitoring observa o comportamento em produção após o lançamento. Os resultados do monitoramento podem acionar a avaliação, o retreinamento, o registro e a promoção de uma versão substituta.

Portanto, um registro atua como o ponto de controle entre a experimentação e a produção, em vez de substituir todos os componentes ao seu redor.

Aplicações no Mundo Real#

Em um sistema de inspeção industrial, os engenheiros podem retreinar um detector de defeitos sempre que as câmeras, os materiais ou os designs dos produtos mudarem. O registro pode reter a referência do conjunto de dados de cada modelo, a precisão média (mAP), a latência de inferência e o formato de hardware compatível. Após os testes confirmarem que a versão 12 melhora a detecção de arranhões sem aumentar os falsos alarmes, um aprovador pode promovê-la e reter a versão 11 para um rollback imediato.

Em análises de imagens médicas, várias equipes podem avaliar candidatos de detecção de tumores. O registro preserva os resultados de validação, a configuração de treinamento, o responsável e o histórico de aprovação de cada versão. Aplicações de produção podem ser restritas a modelos revisados, enquanto versões mais antigas permanecem disponíveis para auditorias e reprodutibilidade. Controles baseados em funções, como aqueles descritos para a Snowflake Model Registry governance, ajudam a evitar a substituição não autorizada ou a inspeção de artefatos sensíveis.

Registro de Modelos em Fluxos de Trabalho da Ultralytics#

A Ultralytics Platform fornece gerenciamento centralizado de modelos para anotar conjuntos de dados, treinar, comparar resultados, exportar, implantar e monitorar modelos de visão computacional. O seu Platform model management workflow documentado oferece suporte a pesos .pt carregados e a modelos produzidos por meio de treinamento em nuvem ou remoto.

O fluxo de trabalho documentado a seguir treina o Ultralytics YOLO26 localmente enquanto envia o modelo resultante, a configuração, as métricas e os logs para um projeto nomeado na Platform:

import os

from ultralytics import YOLO

# Authenticate remote training with Ultralytics Platform
os.environ["ULTRALYTICS_API_KEY"] = "YOUR_API_KEY"

model = YOLO("yolo26n.pt")

model.train(
    data="coco8.yaml",
    epochs=3,
    project="username/model-registry-demo",
    name="candidate-001",
)

O nome do projeto e da execução torna o candidato descoberto juntamente com modelos relacionados. As equipes podem avaliá-lo, usar a Ultralytics MLflow integration para registro adicional de experimentos ou aplicar a YOLO model export quando um modelo registrado precisar ser executado em hardware específico de nuvem ou de borda (edge).

Orientações Práticas para o Registro#

Trate cada versão registrada como imutável. Use aliases compreensíveis por humanos para a implantação, retenha evidências de validação e defina requisitos claros de promoção. Uma política de nomenclatura baseada no Semantic Versioning pode comunicar alterações de compatibilidade, embora versões incrementadas automaticamente também sejam eficazes.

Mais importante ainda, registre pacotes de modelos completos em vez de arquivos de pesos sem explicação. Regras de pré-processamento ausentes, nomes de classes, esquemas de entrada, dependências ou referências a conjuntos de dados podem tornar um modelo aparentemente válido impossível de ser reproduzido ou inseguro para implantação. Controles de acesso, testes automatizados, portões de aprovação, logs de auditoria e procedimentos de reversão transformam um registro de modelos de um mero catálogo de arquivos em uma salvaguarda confiável para produção.