CI/CD para modelos + monitoring drift
⏱ 13 min·⭐ 55 XP
Pré-requisitos (0/1)0%
- ⬜📦 Data versioning: DVC, lakeFS(MLOps — ML em produção)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
CI/CD de modelo é diferente de CI/CD de serviço
CI/CD tradicional testa código. CI/CD de modelo precisa testar também o artifact treinado: métrica em golden set, métricas em slices sensíveis, custo por inferência, latência p99 em hardware-alvo. Só depois disso vai para o deploy progressivo.
GitHub Actions — workflow de ML
# .github/workflows/model-ci.yml
name: model-ci
on:
pull_request:
paths: ["src/**", "dvc.yaml", "params.yaml"]
jobs:
reproduce:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: iterative/setup-dvc@v1
- uses: actions/setup-python@v5
with: { python-version: "3.12" }
- run: pip install -r requirements.txt
- run: dvc pull
- run: dvc repro
- name: Eval em golden set
run: python src/eval_golden.py --report metrics/pr.json
- name: Gate estatistico vs baseline
run: python src/gate.py --pr metrics/pr.json --baseline metrics/main.json
- name: Publicar modelo candidato no MLflow
env:
MLFLOW_TRACKING_URI: ${'$'}{{ secrets.MLFLOW_URI }}
run: python src/register_candidate.py⚠️
O step gate.py deve falhar o PR se a melhora não for estatisticamente significativa ou se houver regressão em qualquer slice monitorado.
Deploy progressivo — shadow, canary, rollout
# argo rollouts — canary strategy
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: churn-serving
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 2h }
- analysis:
templates: [ { templateName: churn-metrics } ]
- setWeight: 25
- pause: { duration: 4h }
- analysis:
templates: [ { templateName: churn-metrics } ]
- setWeight: 50
- pause: { duration: 6h }
- setWeight: 100Origem
Treino
Registroversão, métricas e linhagem
Estágio 1 — sombra
Sombrarecebe o tráfego real e a resposta é DESCARTADA
Comparaçãodivergência contra o modelo atual
Estágio 2 — fatia pequena
Fatia de 5%usuários reais, estrago limitado
Reversão automáticagatilho por métrica, não por opinião
Estágio 3 — completo
100%
Monitor de desvioa entrada muda depois da publicação
- → sem divergência grave
- → reverte
- Conceito de arquitetura
- Gestão e governança
- Rede e entrega
- Compute
A diferença para publicar um serviço comum: aqui não basta responder — é preciso responder BEM, e isso não se mede com verificação de saúde. Os três estágios existem porque cada um responde a uma pergunta que o anterior não responde.
- 1 · Modelo tem duas dimensões de correção. O serviço pode estar de pé e respondendo errado. Verificação de saúde não detecta qualidade — é preciso comparar predições.
- 2 · Sombra é risco zero para o usuário. O modelo novo vê o tráfego real e ninguém consome a resposta dele. É o único estágio que testa com dado de produção sem expor ninguém.
- 3 · Divergir do modelo atual não significa estar errado. A comparação diz ONDE eles discordam. Julgar qual está certo exige rótulo — e é por isso que a sombra informa, mas não aprova sozinha.
- 4 · A fatia pequena responde o que a sombra não responde. Efeito no comportamento do usuário. Um modelo pode divergir pouco e mudar a taxa de conversão — só o tráfego real mostra.
- 5 · A reversão precisa ser automática e por métrica. Depender de alguém perceber significa minutos de degradação. O gatilho por métrica reverte antes de a reclamação chegar.
- 6 · Publicar não encerra — a entrada continua mudando. O conjunto de teste está congelado no passado; o mundo não. Monitor de desvio é o que detecta o modelo envelhecendo depois de publicado.
Quiz rápido
Por que integração contínua de modelo difere da de um serviço comum?
Drift detection com Evidently
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset, TargetDriftPreset
report = Report(metrics=[DataDriftPreset(), TargetDriftPreset()])
report.run(reference_data=df_ref, current_data=df_live)
result = report.as_dict()
drift_share = result["metrics"][0]["result"]["drift_share"]
if drift_share > 0.3:
trigger_retraining_pipeline(reason=f"drift_share={drift_share:.2f}")
alert_slack(channel="#ml-ops", message="Drift detectado em churn-v7")
else:
log_ok(drift_share)Retraining automation
# retraining triggers — documentados e versionados
triggers:
schedule: "0 3 * * 1" # piso: toda segunda 03:00
drift:
metric: evidently.drift_share
threshold: 0.30
online_quality:
metric: f1_weekly
delta_vs_baseline: -0.02
actions:
on_trigger:
- run_pipeline: kubeflow/churn-training
- open_pr_with_mlflow_link: true
- require_human_approval_for_production: true✅
Meta de maturidade Level 2: pipeline inteiro é entregue por CI/CD e promoção para Production exige aprovação humana com evidência anexada.
Perguntas frequentes
❓ Como implantar modelo com segurança?
Em sombra primeiro — recebendo tráfego real sem responder ao usuário — e depois em canário com fração pequena, comparando métrica de qualidade e de custo. Publicar direto significa descobrir o retrocesso pela reclamação, e reverter depois do dano.
❓ O que monitorar depois de publicar?
Desvio na distribuição de entrada, que muda antes do resultado; métrica de qualidade quando o rótulo chega depois; e latência e custo por requisição. O desvio de entrada é o alarme antecipado, e agir nele é o que evita o incidente.
❓ Portão automático de qualidade para modelo funciona?
Funciona com limiar sobre REGRESSÃO em relação à versão em produção, não sobre nota absoluta — métrica de modelo oscila. Portão com número absoluto rígido é desligado na primeira semana apertada, e aí não protege nada.
Fixando
Quiz rápido
O que caracteriza uma implantação em sombra?
Quiz rápido
Qual é o gatilho adequado para retreinar automaticamente?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…