Model Registry

Um registo de modelos é um sistema centralizado para organizar, versionar, governar e obter modelos de machine learning ao longo do seu ciclo de vida. Liga ficheiros de modelos, como pesos de modelos, a metadados que descrevem como cada modelo foi treinado, avaliado, aprovado e implementado. Enquanto componente essencial das operações de machine learning, um registo fornece às equipas uma fonte fiável para decidir que versão do modelo deve servir o tráfego de produção.

Como funciona um Registo de Modelos#

O registo de modelos começa depois de uma execução de treino produzir um modelo candidato. O registo cria uma entrada com nome, atribui uma versão e regista as informações necessárias para compreender e reproduzir o artefacto. Uma entrada típica inclui:

• Artefacto do modelo: Os pesos serializados, a lógica de pré-processamento, os ficheiros de configuração ou uma referência à respetiva localização de armazenamento.
• Versão: Um identificador imutável que distingue um candidato dos restantes.
• Métricas e parâmetros: Precisão de validação, precisão, revocação, latência, detalhes do conjunto de dados, hiperparâmetros e outras medições.
• Linhagem: Ligações entre o modelo, o respetivo código-fonte, a execução de treino e os dados.
• Estado: Etiquetas como candidato, aprovado, rejeitado, principal ou arquivado.
• Informações de implementação: Ambientes e endpoints que utilizam atualmente a versão.

As plataformas implementam estas ideias de formas diferentes. O fluxo de trabalho do MLflow Model Registry utiliza modelos registados, versões, aliases e etiquetas, enquanto o Amazon SageMaker Model Registry é compatível com grupos de modelos, estados de aprovação, linhagem e automatização da implementação. Alguns sistemas também registam uma assinatura do modelo: o esquema de entrada e saída esperado, descrito na documentação da assinatura de modelos do Snowflake.

Aliases como champion ou production fornecem nomes estáveis que podem mudar entre versões imutáveis. Conforme explicado no guia de aliases de modelos do Vertex AI, uma aplicação pode solicitar um alias sem codificar diretamente um número de versão.

Registo de Modelos vs. Conceitos Relacionados#

Um registo de modelos sobrepõe-se a várias ferramentas de ML, mas tem uma finalidade distinta:

• Acompanhamento de experiências regista execuções de treino, incluindo parâmetros, métricas e artefactos intermédios. Um registo recebe resultados selecionados dessas experiências e gere-os como candidatos a lançamento.
• Armazenamento de artefactos contém ficheiros de grandes dimensões. Um registo pode armazenar esses ficheiros diretamente, mas também pode funcionar como um índice de metadados que aponta para um armazenamento de objetos externo. A arquitetura do Kubeflow Model Registry ilustra este design centrado nos metadados.
• Controlo de versões cria versões do código, enquanto um registo de modelos cria versões dos artefactos treinados e dos respetivos metadados específicos de ML. O GitLab model registry pode ligar versões de modelos a tarefas de CI/CD, registos, métricas e parâmetros.
• Implementação de modelos disponibiliza um modelo selecionado para inferência. O registo identifica o artefacto aprovado; o sistema de implementação executa-o.
• Monitorização de modelos observa o comportamento em produção após o lançamento. Os resultados da monitorização podem desencadear a avaliação, o retreino, o registo e a promoção de uma versão de substituição.

Por conseguinte, um registo funciona como ponto de controlo entre a experimentação e a produção, em vez de substituir todos os componentes que o rodeiam.

Aplicações no mundo real#

Num sistema de inspeção industrial, os engenheiros podem voltar a treinar um detetor de defeitos sempre que as câmaras, os materiais ou os designs dos produtos mudam. O registo pode conservar a referência ao conjunto de dados de cada modelo, a precisão média, a latência de inferência e o formato de hardware compatível. Depois de os testes confirmarem que a versão 12 melhora a deteção de riscos sem aumentar os falsos alarmes, um responsável pela aprovação pode promovê-la e conservar a versão 11 para uma reversão imediata.

Na análise de imagens médicas, várias equipas podem avaliar candidatos à deteção de tumores. O registo preserva os resultados de validação, a configuração de treino, o responsável e o histórico de aprovações de cada versão. As aplicações de produção podem ficar limitadas a modelos revistos, enquanto as versões mais antigas permanecem disponíveis para auditorias e reprodutibilidade. Os controlos baseados em funções, como os descritos na governação do Snowflake Model Registry, ajudam a impedir a substituição ou inspeção não autorizada de artefactos sensíveis.

Registo de Modelos nos Fluxos de Trabalho da Ultralytics#

A Ultralytics Platform fornece gestão centralizada de modelos para anotar conjuntos de dados, treinar, comparar resultados, exportar, implementar e monitorizar modelos de visão computacional. O seu fluxo de trabalho documentado de gestão de modelos da Platform é compatível com pesos .pt carregados e com modelos produzidos através de treino na cloud ou remoto.

O fluxo de trabalho documentado seguinte treina Ultralytics YOLO26 localmente, enviando simultaneamente o modelo resultante, a configuração, as métricas e os registos para um projeto nomeado da 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 tornam o candidato detetável juntamente com modelos relacionados. As equipas podem avaliá-lo, utilizar a integração da Ultralytics com o MLflow para registos adicionais de experiências ou aplicar a exportação de modelos YOLO quando um modelo registado tiver de ser executado em hardware específico na cloud ou na periferia.

Orientações Práticas para Registos#

Trata cada versão registada como imutável. Utiliza aliases legíveis para a implementação, conserva as evidências de validação e define requisitos claros de promoção. Uma política de nomenclatura baseada no Versionamento Semântico pode comunicar alterações de compatibilidade, embora as versões incrementadas automaticamente também sejam eficazes.

Mais importante ainda, regista pacotes completos de modelos em vez de ficheiros de pesos sem explicação. A ausência de regras de pré-processamento, nomes de classes, esquemas de entrada, dependências ou referências a conjuntos de dados pode tornar um modelo aparentemente válido impossível de reproduzir ou inseguro para implementar. Controlos de acesso, testes automatizados, etapas de aprovação, registos de auditoria e procedimentos de reversão transformam um registo de modelos de um catálogo de ficheiros numa salvaguarda fiável para a produção.