MLOps na Prática: Do Notebook ao Modelo em Produção (o Ciclo que Ninguém Mostra)

Existe uma distância enorme entre um modelo que atinge 92% de acurácia num notebook e um modelo que entrega valor em produção por seis meses sem ninguém perceber que ele existe. Essa distância tem nome: MLOps.

A maioria dos tutoriais para no model.fit(). Este texto é sobre tudo que vem depois — a parte que ninguém mostra porque não rende screenshot bonito, mas é onde o modelo vive ou morre.

MLOps não é DevOps com nome bonito

A tentação é tratar modelo como código: versiona no git, builda, faz deploy. Mas modelo tem três fontes de variação que código não tem:

1. Dados mudam — e o modelo treinado neles fica obsoleto sozinho, sem ninguém mexer numa linha.
2. O treino não é determinístico por padrão (seeds, ordem de batches, hardware).
3. A performance degrada em silêncio — o sistema continua respondendo 200 OK enquanto acerta cada vez menos.

Por isso MLOps acrescenta ao DevOps clássico três preocupações que não existem em software tradicional: versionar dados, reproduzir treino e monitorar qualidade de predição (não só uptime).

O ciclo real

dados versionados
   -> treino reprodutível
      -> avaliação + validação
         -> registry (modelo versionado)
            -> deploy (batch ou online)
               -> monitoramento (drift + qualidade)
                  -> gatilho de retraining
                     -> (volta ao topo)

Cada seta é um ponto onde projetos reais quebram. Vamos por partes.

1. Versionamento de dados

Se você não consegue responder “com quais dados exatos este modelo foi treinado?”, você não tem MLOps — tem sorte. Código versiona no git, mas datasets de gigabytes não. A solução prática é guardar os dados num storage de objetos (S3, Spaces) e versionar ponteiros + hash no git, com ferramentas como DVC, ou simplesmente um manifesto com o hash de cada arquivo e a query que o gerou.

A regra mínima: todo modelo em produção tem que apontar para o snapshot imutável de dados que o gerou.

2. Treino reprodutível

Reprodutibilidade não é luxo acadêmico — é o que permite você debugar uma regressão de qualidade. Na prática:

• Fixe seeds (random, numpy, framework).
• Pinne versões de bibliotecas (um requirements.txt travado, não >=).
• Registre os hiperparâmetros junto com o resultado (um params.json por run).
• Containerize o ambiente de treino.

Se rodar duas vezes dá dois números muito diferentes, qualquer melhoria que você medir depois é ruído.

3. Model registry

O modelo treinado é um artefato, e artefato precisa de versão, metadados e estágio (staging, produção, arquivado). Um registry — seja o MLflow, seja uma convenção sua de nomes + metadados num banco — responde: qual versão está em produção, quais métricas ela teve, em que dados treinou, quem promoveu.

Sem isso, “fazer rollback do modelo” vira arqueologia.

4. Serving: batch vs online

Duas formas de servir, e a escolha define a arquitetura inteira:

	Batch	Online (tempo real)
Quando	predição não precisa ser instantânea	resposta por requisição
Exemplo	score de churn diário	recomendação na hora do clique
Complexidade	baixa (um cron + tabela)	alta (latência, escala, cache)
Latência	irrelevante	é o produto

A pergunta certa não é “qual é melhor”, é “o negócio precisa da predição agora ou pode ser de madrugada?”. Muita gente monta infra de serving online cara para um problema que um job batch resolveria.

5. Monitoramento — o pulo do gato

Software tradicional você monitora com uptime e erro 500. Modelo você monitora com dois sinais que não aparecem em log de servidor:

• Data drift: a distribuição dos dados de entrada mudou em relação ao treino. Ex.: você treinou com clientes de SP e agora 40% vêm do Nordeste. O modelo não “erra” tecnicamente — ele opera fora do que conhece.
• Concept drift: a relação entre entrada e saída mudou. Ex.: pré-pandemia, “viagem internacional” previa inadimplência de um jeito; pós-pandemia, de outro.

Você detecta drift comparando estatísticas da janela atual com a baseline do treino (médias, distribuições, PSI). E, quando der, monitore a métrica de negócio real (taxa de conversão, acerto confirmado) — é o sinal mais honesto.

6. Retraining

Retraining pode ser agendado (todo mês), por gatilho (drift passou de um limiar) ou contínuo. O erro comum é retreinar cedo demais e injetar ruído, ou tarde demais e perder dinheiro com modelo velho. A decisão depende de quão rápido seus dados mudam — e isso só o monitoramento te diz.

Stack mínima viável (sem overengineering)

Você não precisa de Kubeflow para começar. Uma stack honesta de MLOps inicial:

• Dados: storage de objetos + manifesto com hash.
• Treino: script (não notebook) + container + seeds fixas.
• Tracking: MLflow ou um CSV/banco com params + métricas por run.
• Registry: convenção de versão + metadados.
• Serving: FastAPI (online) ou cron + tabela (batch).
• Monitoramento: job que calcula drift e métrica de negócio, com alerta.

Comece simples. A complexidade entra quando o volume justifica, não antes.

Os erros que mais vejo

1. Notebook em produção. Notebook é para explorar, não para operar. Vire script versionado.
2. Sem baseline de monitoramento. Se você não salvou as estatísticas do treino, não tem como detectar drift depois.
3. Otimizar acurácia, ignorar latência e custo. Um modelo 1% melhor que custa 5x e responde 3x mais devagar perdeu.
4. Não medir métrica de negócio. Acurácia offline alta com conversão real caindo é o pesadelo silencioso.

Conclusão

MLOps é o que transforma “treinei um modelo” em “opero um sistema de IA”. O modelo é talvez 10% do trabalho; os outros 90% são dados versionados, treino reprodutível, serving adequado, e monitoramento que enxerga degradação antes do cliente. Quem domina esse ciclo não é quem tem o modelo mais sofisticado — é quem tem o modelo que ainda funciona daqui a seis meses.