Conceito e mecanismo
Uma experiência MLflow agrupa runs relacionados. Cada run pode registar parâmetros, métricas e artefactos: por exemplo, profundidade de uma árvore, erro de validação e relatório de análise. Autologging ajuda com integrações suportadas, mas uma métrica operacional personalizada pode exigir registo explícito. Compara runs avaliados sobre uma base compatível; ordenar números de populações diferentes não demonstra melhoria. Guarda também a identificação dos dados e do código. No MLflow 3, o registry predefinido é databricks-uc; confirma o registry URI e usa nomes de três partes quando trabalhas com Unity Catalog. A assinatura de um modelo descreve entradas e saídas e é necessária para registar novas versões em UC.
Aplicação guiada
Um alias como champion aponta para uma versão e pode ser alterado. Um consumidor batch que resolve o alias ao carregar o modelo pode passar a usar outra versão na execução seguinte. Um endpoint já configurado com uma versão não muda automaticamente só porque o alias mudou. Trata a promoção como uma decisão com evidência, identidade, versão efetiva, aceitação e recuperação. Tags ajudam a descrever validações, mas não substituem controlo de acesso nem uma alteração de tráfego. Decide se promoves código para treinar no ambiente de produção ou um artefacto já treinado; documenta dados, custo e condições de reprodução.
Champion aponta para v8, mas o endpoint continua configurado para v7 até ser atualizado.
Armadilhas comuns
Tag como aprovação executável; alias como atualização automática de serving.
Tópicos relacionados: Ambiente, AutoML e reprodutibilidade · Features temporais e consistência · Dados, preparação e validação
Regista evidência e confirma a versão que realmente responde ao consumidor.
Referência: Model lifecycle in Unity Catalog · 2025-03-01