Como você gerencia versões de modelo para conseguir fazer rollback rápido quando algo dá errado?

Trate modelos como artefatos versionados e imutáveis num registro, nunca como um arquivo sobrescrito no lugar. Cada versão registra o commit do código de treino, o snapshot de dados, suas métricas e um estágio como staging ou produção. O serving lê da configuração qual versão carregar, então o rollback é uma mudança de configuração que leva segundos, e a versão anterior segue carregável em vez de precisar de um rebuild.

Regra um: um artefato de modelo é imutável. Ele ganha uma versão, é escrito uma vez, e nada nunca o sobrescreve, porque o dia em que você precisa de rollback é o dia em que você descobre que o arquivo antigo foi substituído. Cada versão carrega linhagem: o SHA do git do código de treino, o identificador do snapshot de dados, a configuração de hiperparâmetros, as métricas de avaliação e quem promoveu. Isso significa que quando alguém pergunta daqui a três meses por que o modelo começou a se comportar diferente em abril, é uma consulta e não um projeto de arqueologia. O serving não fixa uma versão no código. Ele lê um ponteiro da configuração, então promover é mudar o ponteiro e fazer rollback é mudar de volta, ambos em segundos. Eu mantenho a versão anterior carregada em memória onde o footprint permite, para que um rollback não precise de redeploy nem de cold start num container novo. E eu ensaio, porque um caminho de rollback não testado não é um caminho de rollback. No último time em que eu estive a gente fazia um de propósito numa janela de baixo tráfego de tempos em tempos, e foi assim que descobrimos que a mudança de configuração propagava bem mas um cache lá na frente segurava o limiar antigo por mais dez minutos.