Versionamento de um modelo treinado: o artefato junto com o código, os dados, os parâmetros e o ambiente que o produziram

Objetivo

Responder, para qualquer predição servida em produção, qual modelo a gerou, a partir de que código, dados e configurações ele foi construído, qual foi o seu desempenho e como voltar ao modelo anterior. O versionamento do dataset em si é tratado no artigo sobre proveniência de datasets pequenos; este protocolo cobre o lado do modelo e as ligações com o restante.

Pré-requisitos

Código sob controle de versão, um dataset com identificador estável (checksum, ponteiro do DVC ou nome de snapshot), um split de teste fixo e um local para armazenar artefatos com metadados. Pode ser um registry como o Model Registry do MLflow, que a sua documentação descreve como um repositório centralizado com linhagem até a execução (run) que produziu o modelo, além de versionamento e aliases, ou uma estrutura disciplinada em armazenamento de objetos com um arquivo de manifesto.

Passos

1. Treine somente a partir de um estado commitado; recuse registrar um modelo construído a partir de uma árvore de trabalho com alterações não commitadas. Registre o hash do commit.
2. Registre o identificador do dataset, o identificador do split e o conjunto completo de hiperparâmetros como parâmetros da execução.
3. Registre as versões exatas das dependências do ambiente de treino. O guia de persistência do scikit-learn observa que carregar um estimador com outra versão do scikit-learn gera um InconsistentVersionWarning e que um modelo treinado com versões mais antigas da biblioteca e de suas dependências pode precisar ser retreinado em um ambiente atualizado; por isso, o ambiente faz parte da versão.
4. Avalie no split de teste fixo e armazene as métricas junto com a execução; armazene também o esquema de entrada e saída (uma signature), para que o código de serving possa validar as requisições.
5. Serialize o modelo em um formato escolhido de acordo com o contexto de serving; a comparação do guia indica que formatos baseados em pickle executam código arbitrário ao serem carregados e que ONNX ou skops são alternativas mais seguras. Armazene o artefato sob um número de versão imutável.
6. Promova por alias (champion, challenger), nunca sobrescrevendo o arquivo por trás de uma versão existente; o serving lê o alias, e o rollback é uma troca de alias.
7. Registre a versão do modelo em cada predição, para que o comportamento em produção possa ser relacionado de volta ao registry.

Resultado esperado

Toda predição servida remete a uma versão, e toda versão remete a um commit, um dataset, parâmetros, métricas e um ambiente; o rollback exige apenas uma troca de alias.

Limites e base de verificação

O protocolo acrescenta trabalho de registro a cada execução de treino e exige espaço de armazenamento para os artefatos. Ele não torna o treinamento determinístico (veja reprodutibilidade de um experimento de ML). Não se afirma nenhum prazo nem resultado decorrente de segui-lo.