MLOps: treinar não é implantar

O notebook termina com uma célula feliz. A métrica subiu. O time comemora. Na semana seguinte, o modelo entra em um endpoint e começa a decidir sobre pessoas, filas ou dinheiro. Aí o ofício muda.

Treinar é um experimento. Implantar é operar um sistema que erra em público, envelhece em silêncio e depende de dados que ninguém congela. MLOps é o nome curto para essa diferença. Não é uma ferramenta. É recusar a ideia de que o arquivo modelo.pkl é o produto.

Quem já viu machine learning como programa cujos parâmetros vêm dos dados reconhece o corte: se os parâmetros vêm dos dados, o sistema morre quando os dados mudam e ninguém percebe.

O laboratório não é a fábrica

No notebook, o conjunto cabe na memória. O recorte é estático. O autor lembra que a coluna idade foi imputada com a mediana do treino. A aleatoriedade tem uma semente. O gráfico é bonito porque o eixo foi escolhido depois.

Em produção, a entrada chega suja, atrasada, incompleta. A mediana do treino precisa estar materializada, não na cabeça de quem saiu de férias. O horário em que o feature é calculado precisa ser o mesmo horário em que era calculado no treino. Se no treino você usou o total do mês já fechado para prever o mês, e na hora de servir você só tem o mês em andamento, o modelo não está “um pouco pior”. Está respondendo a outra pergunta.

Essa falha tem um nome feio e merecido: vazamento, ou treino-servir inconsistente. É a causa silenciosa de muitos “no notebook estava 94%”.

flowchart TD
  A[Notebook] --> B[Pipeline de features]
  B --> C[Modelo versionado]
  C --> D[Serviço]
  D --> E[Monitoramento]
  E --> F{Deriva ou falha?}
  F -->|Sim| G[Rollback]
  F -->|Não| D
  G --> C
  classDef ouro fill:#FBF5E4,stroke:#C9A227,color:#0B1F18,stroke-width:1.4px
  classDef verde fill:#F3FAF7,stroke:#1E7A57,color:#0B1F18,stroke-width:1.4px
  classDef fim fill:#14513B,stroke:#0F3328,color:#FBFAF6,stroke-width:1.4px
  class A ouro
  class B,C,D,E,F verde
  class G fim

Deriva: o mundo não assina o dataset

Há pelo menos duas mudanças que matam um modelo parado.

Deriva de dados. A entrada muda. A fábrica troca a lâmpada e as imagens ficam mais amarelas. O microfone do celular novo distorce o áudio. O formulário passa a deixar um campo em branco. O modelo recebe um x que não é o x do treino.

Deriva de conceito. A relação entre entrada e saída muda. O mesmo perfil de compra deixa de ser fraude porque a pandemia alterou o hábito. Casas do mesmo tamanho ficam mais caras. A regra do negócio muda e o rótulo de ontem não vale.

Os dois pedem monitoramento, mas a resposta não é idêntica. Na deriva de dados, às vezes o conserto está na coleta. Na de conceito, o mapa antigo está errado: é preciso novo rótulo, novo treino, às vezes nova tarefa.

Esperar o usuário reclamar é uma estratégia. É a pior. Quando o rótulo de produção atrasa — fraude confirmada semanas depois, diagnóstico só no retorno — a métrica de negócio já se moveu e o dashboard de acurácia ainda sorri com o lote antigo.

O que vale a pena olhar

Três famílias de métrica, não uma.

Software. Latência, erro 5xx, uso de CPU e memória, filas. Um modelo certo que responde em quatro segundos pode ser um produto errado. Um modelo que sobe a memória até o pod morrer não é “IA”. É vazamento.

Entrada. Distribuição das features, taxa de nulos, brilho médio da imagem, duração do áudio, proporção de um país no tráfego. Quando a entrada sai da faixa do treino, o número de acerto futuro já é suspeito, mesmo antes do rótulo chegar.

Saída. Taxa de recusa, de “não reconhecido”, de cliques, de abandono para o canal humano. A saída é o que o produto sente. Se o classificador começa a mandar todo mundo para revisão manual, o sistema não quebrou no sentido de exceção. Quebrou no sentido de operação.

No começo, meça demais. Depois, corte. Defina limiares que disparem gente, não só gráfico. Um dashboard sem dono é um screensaver caro.

Pipeline de features é o contrato

O modelo é a parte pequena. O contrato é: dado este evento, nestas horas, com estas janelas, produzimos este vetor. Treino e serviço precisam obedecer o mesmo contrato.

Isso leva a um desenho menos romântico do que o notebook. Transformações versionadas. Feature store ou, no mínimo, a mesma biblioteca chamada nos dois lados. Registro do que entrou em cada predição, para auditoria e para o próximo treino. Sem log da feature, você não reproduz o erro. Sem reproduzir o erro, você só tem opinião.

Há um detalhe de tempo que programas comuns também conhecem e times de modelo às vezes esquecem. Qualquer atributo que só existe depois do fato não pode entrar na predição do fato. O valor “cliente cancelou na semana seguinte” não estava disponível na sexta-feira da oferta. Se estava na tabela analítica, estava no futuro. Produção não terá essa coluna. O notebook terá, se ninguém vigiar.

Rollback é parte do treino

Código tem revert. Modelo precisa do mesmo reflexo. Uma versão nova com métrica melhor no conjunto de validação pode degradar um recorte que o conjunto não representava: um estado, um dispositivo, um idioma, um fim de semana.

Implantar 100% no primeiro dia é um ato de fé. Canário, sombra — prever sem decidir — e comparação lado a lado existem porque o custo de um modelo ruim não é um gráfico vermelho. É decisão irreversível em cliente.

Rollback não é só restaurar o arquivo. É restaurar o contrato de features daquela versão. Um modelo antigo com pipeline novo é um terceiro modelo, não documentado.

Retreino automático parece maduro e às vezes é um gerador de regressão. Se o rótulo é lento ou enviesado, o retreino aprende o viés mais rápido. Manual com gatilho — deriva detectada, volume mudou, métrica de negócio caiu — costuma ser o primeiro degrau honesto.

Engenharia que o notebook esconde

Onde o modelo roda: nuvem, dispositivo, navegador. Treinar em GPU e servir em CPU muda o que é viável. Quantização, destilação e recusar um modelo grande não são detalhes. São o produto.

Lote ou tempo real muda a arquitetura. Um score noturno de crédito não precisa de 50 milésimos. Um interruptor de voz, sim. Logs de predição são dados de treino futuro e também risco de privacidade. Segurança não é um apêndice moral. É requisito do sistema que agora toca dado pessoal para decidir.

Nada disso aparece na célula que imprime accuracy. Aparece quando alguém pergunta: o que fazemos às 2h da manhã, se a taxa de nulos triplicar?

Uma lista antes de chamar de produção

1. O recorte de features do treino é o mesmo da hora de servir, com o mesmo relógio.
2. O modelo, o código e os dados de treino têm versão recuperável.
3. Há métricas de software, de entrada e de saída, com alarme e dono.
4. Há um modelo anterior para o qual voltar, com o pipeline correspondente.
5. Há um plano de rótulo: de onde vem, com que atraso, com que viés conhecido.
6. Alguém consegue explicar o que acontece quando o modelo se recusa a responder.

Se o item 1 falha, o restante é teatro. Se o item 4 falha, cada deploy é irreversível. Se o item 6 falha, você não tem um produto. Tem um experimento com usuários.

Treinar não é implantar. Implantar não é terminar. O ciclo verdadeiro é treinar, servir, observar, corrigir dados, voltar atrás quando preciso, treinar de novo. MLOps é só o nome que damos à recusa de fingir que a última célula do notebook fecha o assunto.

Treinar é o meio do caminho. O volume 10 da AI One trata o modelo como sistema: monitoramento, custo e a vida depois do deploy.

Leia também: Machine learning para quem já programa.