Você já colocou um modelo em produção e, uma semana depois, a acurácia despencou sem aviso? Esse é o pesadelo de 62% das empresas que escalam machine learning, que ainda não automatizam o retreinamento (MLOps Survey 2026). Enquanto isso, 78% das organizações que usam MLOps reportam entregas mais previsíveis e menos incidentes.

O problema não é falta de ferramentas — é a ausência de um pipeline integrado. Neste tutorial, você vai montar, do zero, um fluxo completo de MLOps usando só ferramentas open-source: MLflow para rastrear experimentos, DVC para versionar datasets, GitHub Actions para CI/CD e Evidently AI para monitorar drift. O foco é prático: cada etapa tem código executável e configuração YAML.

O verdadeiro gargalo do ML não é construir modelos, é mantê-los vivos em produção. Um pipeline de MLOps bem desenhado transforma o deploy de um evento estressante em um processo previsível e reversível.

1. Versionamento de Dados com DVC: O Pilar que Todo Mundo Ignora

Sem versionamento de dados, seu pipeline de ML é uma caixa-preta. Você treina o modelo hoje, ele funciona. Três meses depois, alguém atualiza o dataset sem avisar — e o modelo quebra. DVC (Data Version Control) resolve isso ao tratar datasets como objetos versionáveis, linkados ao Git.

Passo 1: Inicialize o DVC no seu repositório

pip install dvc
git init
dvc init

Isso cria um diretório .dvc/ e um arquivo de configuração. Nada muda no Git ainda.

Passo 2: Adicione um dataset ao controle

dvc add data/train.csv
git add data/train.csv.dvc .gitignore
git commit -m "Adiciona dataset de treino v1.0"

O DVC não armazena o arquivo grande no Git. Ele cria um arquivo .dvc leve que aponta para o hash do arquivo. O dado real vai para um cache local ou remoto (S3, GCS, servidor SFTP).

Passo 3: Configure um remote (exemplo: bucket S3)

dvc remote add -d myremote s3://meu-bucket-ml/dvc-cache
dvc push

Agora qualquer pessoa no time pode baixar exatamente a mesma versão do dataset com dvc pull. Isso é essencial para reprodutibilidade. Se o dataset mudar, o DVC detecta a diferença pelo hash — e você pode comparar versões.

Tabela 1: Comparação rápida de ferramentas de versionamento

Dica prática: Sempre execute dvc checkout após um git checkout para garantir que os dados locais correspondam ao commit. Automatize isso com um hook do Git.

2. CI/CD para ML: GitHub Actions + MLflow + Testes de Modelo

CI/CD para ML não é igual ao de software comum. Além de testar código, você precisa validar dados, métricas de modelo e detectar vazamento de informação. O MLflow entra aqui como o cérebro dos experimentos, armazenando parâmetros, métricas e artefatos.

Estrutura do repositório:

meu-projeto-ml/
├── .github/workflows/ci-ml.yml
├── data/
├── notebooks/
├── src/
│   ├── train.py
│   ├── evaluate.py
│   └── data_validation.py
├── models/
├── requirements.txt
├── DVC
└── README.md

Arquivo ci-ml.yml (GitHub Actions):

name: ML Pipeline CI/CD

on: push: branches: [main] pull_request: branches: [main]

jobs: train-and-evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: '3.11' - name: Instalar dependências run: pip install -r requirements.txt - name: Baixar dados versionados run: | dvc pull dvc checkout - name: Executar validação de dados run: python src/data_validation.py - name: Treinar modelo run: | python src/train.py --experiment-name "ci-$(date +%Y%m%d-%H%M%S)" - name: Avaliar modelo run: python src/evaluate.py --threshold 0.75 - name: Registrar modelo no MLflow run: | mlflow models register -m runs:/<run-id>/model -n meu_modelo_producao

Destaque para data_validation.py: ele verifica se o dataset não tem valores nulos em colunas críticas, se a distribuição das features está dentro de limites esperados e se o número de linhas é coerente. Sem essa validação, um dataset corrompido pode passar reto e gerar um modelo inútil.

Blockquote editorial (sem atribuição):

Treinar um modelo com dados sujos é como cozinhar com ingredientes estragados: você só descobre o erro depois que a comida está na mesa — e o cliente já reclamou.

Exemplo de train.py com MLflow:

import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split

mlflow.set_tracking_uri("http://localhost:5000")

with mlflow.start_run(): # Parâmetros n_estimators = 100 max_depth = 10 mlflow.log_param("n_estimators", n_estimators) mlflow.log_param("max_depth", max_depth)

# Treinamento
model = RandomForestClassifier(n_estimators=n_estimators, max_depth=max_depth)
model.fit(X_train, y_train)

# Métricas
acc = model.score(X_test, y_test)
mlflow.log_metric("accuracy", acc)

# Log do modelo
mlflow.sklearn.log_model(model, "model")

O CI/CD vai executar esse script a cada push no main. Se a acurácia cair abaixo de 0.75, o pipeline falha — e o modelo não vai para produção. Isso é o que separa um deploy responsável de um "chute e reza".

3. Monitoramento de Drift com Evidently AI: Quando o Modelo Começa a Falhar

Modelos em produção são vítimas do tempo. Dados mudam, conceitos evoluem, e o que funcionava em janeiro pode ser desastroso em junho. O Evidently AI é a ferramenta open-source padrão para detectar drift de dados e de conceito (concept drift).

Passo 1: Instale o Evidently

pip install evidently

Passo 2: Crie um dashboard de monitoramento

import pandas as pd
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset, RegressionPreset

Dados de referência (treino original)

reference = pd.read_csv("data/train.csv")

Dados atuais (última semana de produção)

current = pd.read_csv("data/production_latest.csv")

report = Report(metrics=[ DataDriftPreset(), RegressionPreset() ]) report.run(reference_data=reference, current_data=current) report.save_html("monitoring_report.html")

Esse relatório mostra, para cada feature, se houve drift estatístico (teste de Kolmogorov-Smirnov ou chi-quadrado) e qual a magnitude. Se mais de 20% das features apresentarem drift, o alarme deve disparar.

Passo 3: Automatize o alerta com GitHub Actions (agendado)

Você pode rodar o monitoramento como um job semanal no GitHub Actions:

name: Monitoramento de Drift Semanal

on: schedule: - cron: '0 6 * * 1' # toda segunda 6h UTC

jobs: check-drift: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Instalar dependências run: pip install -r requirements.txt - name: Executar monitoramento run: python src/monitor_drift.py - name: Enviar alerta se drift alto run: | if grep -q "drift_detected: true" drift_report.json; then curl -X POST -H "Content-Type: application/json"
-d '{"text":"Drift detectado! Iniciar retreinamento."}'
$SLACK_WEBHOOK_URL fi

Integração com retreinamento automático: Quando o drift ultrapassa o limiar, o pipeline pode disparar um novo treinamento via CI/CD. O MLflow versiona o novo modelo, e o DVC garante que o dataset usado é o correto. Tudo orquestrado.

Kubeflow para orquestração pesada: Se sua empresa opera múltiplos modelos em escala, o Kubeflow oferece pipelines nativos do Kubernetes. Ele gerencia dependências, paralelismo e recursos computacionais. A CNCF relata que ferramentas como MLflow, DVC e Kubeflow reduzem em 40% o tempo de deploy de modelos (CNCF 2026). Isso significa que um processo que levava duas semanas passa a levar seis dias úteis.

Checklist final para seu pipeline de MLOps em 2026:

• Versionamento de dados com DVC (commits atômicos, cache remoto)
• Rastreamento de experimentos com MLflow (parâmetros, métricas, artefatos)
• CI/CD com GitHub Actions (validação de dados + treino + avaliação)
• Testes de modelo (threshold mínimo de performance)
• Registro automático de modelo aprovado (MLflow Model Registry)
• Monitoramento de drift com Evidently AI (relatório semanal + alerta)
• Gatilho de retreinamento automático (quando drift > 20% ou performance cai)

Conclusão

MLOps não é um luxo para empresas de tecnologia — é a barreira mínima para qualquer time que queira manter modelos em produção sem sustos. Este tutorial mostrou o esqueleto de um pipeline funcional com DVC, MLflow, GitHub Actions e Evidently AI. O próximo passo é adaptá-lo à sua realidade: escolha o remote de dados, defina os thresholds de drift que fazem sentido para seu domínio e automatize o retreinamento. O custo de ignorar MLOps é previsível: modelos que morrem em silêncio, decisões erradas e retrabalho. O custo de implementar é um fim de semana de configuração e uma cultura de disciplina técnica. A escolha é sua.

Artigos Relacionados

• A Grande Reforma do Transformer: Maio de 2026 Está Reescrevendo as Regras do ML
• O Fim dos Pilotos de ML: Como as 'AI Factories' Estão Industrializando o Machine Learning nas Empresas em 2026
• AlphaEvolve: 11 Recordes que Provam que o ML Já Está se Redesenhando