1.1 O código do modelo é a menor parte do sistema

Um resultado clássico da literatura de engenharia de ML (o paper "Hidden Technical Debt in Machine Learning Systems", do Google): a caixa que contém o algoritmo de ML é minúscula perto de tudo que a cerca — coleta e validação de dados, infraestrutura de features, gestão de configuração, servir, monitorar, orquestrar. É nesse entorno que os projetos morrem.

        ┌──────────────────────────────────────────────────────────┐
        │  coleta   │ validação │ config │ infra de   │ gestão de   │
        │  de dados │ de dados  │        │ serving    │ recursos    │
        ├───────────┼───────────┼────────┴────────────┼─────────────┤
        │ extração  │  ┌─────┐  │   monitoramento     │  ferramentas│
        │ de feat.  │  │ ML  │  │                     │  de análise │
        │           │  └─────┘  │   orquestração / gerenciamento    │
        └───────────┴───────────┴───────────────────────────────────┘
              a caixa "ML" é ~5% do código de um sistema de ML em produção

MLOps é a aplicação de práticas de DevOps + engenharia de dados + governança ao ciclo de vida de ML: automatizar, versionar, testar, monitorar e reproduzir — para que um modelo saia do notebook, entre em produção e permaneça útil.

1.2 Por que ML quebra diferente de software

1.3 O ciclo de vida de ML

   negócio ▶ dados ▶ features ▶ experimentação ▶ avaliação ▶ registro ▶ deploy ▶ monitorar
                ▲                                                                    │
                └──────────── retraining acionado por drift / novos dados / SLA ─────┘

É um loop, não uma linha. E cada etapa precisa ser versionada e automatizável, senão o loop não fecha de forma confiável.

1.4 Níveis de maturidade (modelo do Google)

2.1 Versionamento de dados

"Qual dataset gerou este modelo?" tem que ter resposta exata. Git versiona código; para dados grandes, ferramentas dedicadas:

O mínimo aceitável: cada treino registra um identificador imutável do dataset (hash, versão DVC, snapshot Iceberg) junto com o código e os parâmetros.

2.2 Splits que não mentem

• Split temporal para dados temporais: se o modelo vai prever o futuro, treine no passado e valide no futuro. Split aleatório em série temporal vaza informação do futuro para o treino e infla a métrica.
• Split por grupo: se há múltiplas linhas por entidade (usuário, paciente, loja), o mesmo grupo não pode aparecer em treino e teste — senão o modelo "reconhece" a entidade, não o padrão. Use GroupKFold.
• Estratificação por classe (e por segmentos importantes) para o teste representar a realidade.
• Conjunto de teste "trancado": um holdout que você olha pouco, para não fazer overfitting de decisões nele. O tuning acontece na validação.

2.3 Data leakage o bug nº 1 de modelos que "iam bem"

Vazamento é quando informação que não estará disponível no momento da predição entra no treino. O modelo aprende a "trapacear", a métrica fica linda, e na produção ele desaba.

3.1 Os quatro pilares da reprodutibilidade

Um resultado de ML só é reproduzível se você fixou e registrou os quatro:

1. Código — commit hash exato (e do repositório de pipelines, não só do notebook).
2. Dados — versão/hash do dataset de treino e de validação.
3. Ambiente — versões de bibliotecas (lockfile), versão de CUDA/driver, container image com digest.
4. Configuração — hiperparâmetros, seed aleatória, flags, splits.

3.2 Experiment tracking

# MLflow: um treino instrumentado — tudo que você vai precisar para reproduzir e comparar
import mlflow

mlflow.set_experiment("churn-v3")
with mlflow.start_run(run_name="xgb-baseline"):
    mlflow.log_params({"max_depth": 6, "eta": 0.1, "seed": 42})
    mlflow.log_param("dataset_hash", dataset_sha)        # versão dos dados
    mlflow.set_tag("git_sha", git_sha)

    model = train(X_train, y_train, params)
    metrics = evaluate(model, X_val, y_val)                # por segmento também!

    mlflow.log_metrics(metrics)
    mlflow.log_artifact("feature_importance.png")
    mlflow.xgboost.log_model(model, "model",
        signature=infer_signature(X_val, model.predict(X_val)))   # schema de entrada/saída

3.3 Boas práticas

• Um experimento = uma hipótese. Não mude cinco coisas e registre um run — você não saberá o que causou a diferença.
• Métricas por segmento sempre, não só a agregada. E salve a matriz de confusão / curvas, não só o número.
• Baseline honesto: modelo trivial (média, classe majoritária, regra de negócio atual). Se o ML não bate isso com folga, não vale a complexidade.
• Sweeps de hiperparâmetro registrados (Optuna, W&B Sweeps, Ray Tune) — com orçamento definido, não busca infinita.
• O notebook é rascunho. O que vai para produção é código em módulos, testável e versionado; o experiment tracker é a memória institucional.

4.1 O problema: treino e produção calculam features diferente

No treino, você calcula gasto_medio_30d com um GROUP BY em SQL sobre dados históricos. Em produção, um engenheiro reimplementa o mesmo cálculo em Java, no caminho da requisição. As duas implementações divergem — arredondamento, fuso, tratamento de nulo, janela — e o modelo recebe em produção valores diferentes dos que viu no treino. Isso é training-serving skew, e degrada silenciosamente a performance.

4.2 O que uma feature store faz

Ferramentas: Feast (open source, o mais comum), Tecton, Hopsworks, Featureform, e as feature stores nativas de SageMaker / Vertex / Databricks.

4.3 Point-in-time correctness a razão de existir da feature store

Rótulo: "cliente X deu churn em 2026-03-15"
Feature: gasto_medio_30d

  ERRADO  → gasto_medio_30d calculado com dados até HOJE (inclui período pós-churn) → vazamento
  CERTO   → gasto_medio_30d como era em 2026-03-15 (só dados até ali) → point-in-time join

Fazer esse join corretamente à mão, para dezenas de features e milhões de rótulos com timestamps diferentes, é difícil e propenso a erro. É o principal valor técnico da feature store.

4.4 Você precisa de uma feature store?

5.1 O model registry

Um catálogo central de modelos treinados, cada um com: versão, métricas de avaliação, linhagem (qual run/dados/código o gerou), assinatura de entrada/saída, model card, e um estágio (None → Staging → Production → Archived). Substitui o "qual .pkl está no servidor?" por uma fonte de verdade consultável e auditável.

• Ferramentas: MLflow Model Registry, SageMaker Model Registry, Vertex AI Model Registry, W&B Model Registry.
• Promoção como decisão explícita: mover para "Production" exige aprovação e dispara (ou libera) o deploy. Reverter é mover o ponteiro de volta.
• Linhagem ligada: do modelo em produção você chega ao experimento, aos dados e ao commit que o produziram.

5.2 Assinatura e validação de schema

O modelo deve declarar o schema que espera (nomes, tipos, ordem das features) e o que produz. Assim, o serviço rejeita uma requisição malformada com erro claro em vez de gerar uma predição silenciosamente errada. MLflow infere isso com infer_signature; frameworks de serving validam na borda.

5.3 Empacotamento: formatos e portabilidade

6.1 Os três padrões

6.2 Ferramentas de serving online

6.3 Latência, throughput e custo avançado

• Dynamic batching: agrupar requisições que chegam próximas em um lote para o modelo — aumenta throughput e uso de GPU ao custo de alguns ms de latência. Triton, BentoML e Ray Serve fazem isso.
• Otimização do modelo: quantização (INT8), pruning, distilação, compilação (ONNX Runtime, TensorRT, OpenVINO) — reduzem latência e custo, às vezes com perda pequena de métrica que você mede.
• Autoscaling: por RPS ou por profundidade de fila; scale-to-zero para modelos de uso esporádico; cuidado com cold start (carregar um modelo grande demora).
• CPU vs GPU: muitos modelos clássicos (árvores, regressão, embeddings pequenos) servem melhor e mais barato em CPU. GPU só quando o modelo exige.
• Caching: se a mesma entrada se repete (mesmo usuário, mesmo item), cachear a predição.
• SLOs de serving: p50/p95/p99 de latência, throughput, taxa de erro, saturação — monitorados como qualquer serviço.

7.1 As três siglas

• CI (Continuous Integration): além de lint e testes de código, valida dados e modelo — schema, distribuição, métrica mínima, ausência de regressão.
• CD (Continuous Delivery): entrega o pipeline de treino e/ou o serviço de predição automaticamente até um ambiente, com aprovação para produção.
• CT (Continuous Training): re-treina automaticamente quando disparado — por agenda, por chegada de dados novos, ou por alarme de drift/queda de performance.

7.2 Orquestradores de pipeline de ML

7.3 Testes específicos de ML

# Gate de CI: o modelo novo só passa se não regredir em NENHUM segmento importante
def test_no_regression_by_segment(new_model, prod_model, val):
    for seg in ["br", "latam", "novo_cliente", "alto_valor"]:
        s = val[val.segment == seg]
        auc_new  = roc_auc(s.y, new_model.predict_proba(s.X)[:, 1])
        auc_prod = roc_auc(s.y, prod_model.predict_proba(s.X)[:, 1])
        assert auc_new >= auc_prod - 0.01, f"regressão em {seg}: {auc_new:.3f} < {auc_prod:.3f}"

7.4 Continuous Training

• Gatilhos: agenda (semanal), volume de dados novos, alarme de drift/queda de métrica, evento de negócio (novo produto).
• O pipeline de CT: valida dados → treina → avalia (gates por segmento) → compara com produção → registra → (se passar) promove para staging → canary → produção. Falhou um gate? Para e alerta, não promove.
• Champion/challenger: o modelo em produção (champion) e o recém-treinado (challenger) rodam em paralelo; o challenger só vira champion se ganhar de forma consistente em dados reais.
• Cuidado com loop de feedback: se o modelo influencia os dados que ele mesmo vai usar para re-treinar (recomendação que enviesa cliques), o CT pode amplificar viés. Injete exploração / dados não enviesados.

8.1 Por que modelos apodrecem sozinhos

O modelo aprendeu uma relação entre features e alvo na distribuição de dados de um certo período. O mundo muda: comportamento de cliente, sazonalidade, concorrência, economia, um bug num sistema upstream. A relação que o modelo capturou deixa de valer, e a performance cai — sem ninguém ter mexido em uma linha de código.

8.2 Os tipos de drift

8.3 Monitorar com e sem rótulos

O desafio real: em muitos problemas o rótulo verdadeiro só chega semanas depois (o cliente deu churn? a entrega atrasou? o empréstimo tornou-se inadimplente em 90 dias?). Você não pode esperar para saber que o modelo está ruim.

• PSI (Population Stability Index) e teste KS: medem quanto a distribuição de uma feature (ou do score) mudou vs a referência de treino. Regra de bolso para PSI: < 0,1 estável, 0,1–0,25 atenção, > 0,25 mudança significativa.
• Ferramentas: Evidently (open source, relatórios e testes de drift/qualidade), NannyML (estimativa de performance sem rótulo), whylogs/WhyLabs, Arize, Fiddler, Grafana + métricas próprias.
• Alarme acionável: não alarme em cada micro-variação. Defina limiares por feature, janelas, e ligue o alarme a uma ação (investigar, recalibrar, disparar CT).

8.4 O loop de retraining

monitor detecta drift/queda ▶ investiga (é o mundo? é bug upstream?) ▶
   se mundo mudou ▶ dispara CT (Módulo 7) ▶ novo modelo passa nos gates ▶
   canary / champion-challenger ▶ promove ▶ atualiza a referência de monitoramento

Cadência de retraining: alguns sistemas re-treinam diariamente, outros trimestralmente. Deixe os dados decidirem — meça com que velocidade a performance decai e escolha a cadência que mantém dentro do SLO, sem re-treinar à toa (custo, risco de introduzir regressão).

9.1 Linhagem e auditabilidade

Para qualquer predição em produção, você deve conseguir responder: qual versão do modelo a gerou, quais dados e código o treinaram, quem aprovou a promoção, quais features entraram e com que valores. Isso exige amarrar registry + experiment tracker + versionamento de dados + logs de predição. É requisito de auditoria em setores regulados (finanças, saúde, seguros) e a base de qualquer investigação de incidente.

9.2 Model Risk Management

• Model card / ficha do modelo: propósito, dados de treino e limitações, métricas por segmento, premissas, riscos conhecidos, condições de uso e de não-uso, plano de monitoramento.
• Validação independente: em setores regulados, um time separado do que construiu revisa premissas, dados, métricas e robustez antes do go-live (princípio "SR 11-7" em bancos).
• Inventário de modelos com classificação de risco (impacto × exposição) e cadência de revisão proporcional.
• Aprovações e trilha: quem promoveu, com base em quê, quando.

9.3 Fairness e explicabilidade avançado

• Fairness: medir métricas por grupo protegido (paridade demográfica, igualdade de oportunidade, taxas de erro balanceadas) — não existe uma definição única, e algumas são mutuamente exclusivas; a escolha é do contexto e do jurídico. Ferramentas: Fairlearn, AIF360. Cuidado com proxies (CEP correlaciona com raça).
• Explicabilidade global: importância de features, SHAP summary, PDP/ALE — para entender o modelo e detectar features suspeitas (leakage, proxy).
• Explicabilidade local: SHAP/LIME por predição — para justificar uma decisão individual (exigido, ex.: negativa de crédito) e para depurar.
• Registrar explicações junto das predições de alto impacto, para auditoria e contestação.

9.4 Custo em escala

9.5 Estratégias de deploy (recapitulando com foco em risco)

10.1 Os perfis que contratam

10.2 Roadmap de estudo (10–12 semanas)

Base necessária: Python sólido, SQL, Docker, git, noções de Kubernetes e de uma nuvem (AWS ou GCP). CI (GitHub Actions) e IaC básico (Terraform) ajudam muito.

10.3 Banco de perguntas de entrevista (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. Projeto end-to-end (âncora): um problema real (churn, previsão de demanda, fraude) com dados versionados (DVC), experiment tracking (MLflow), pipeline de treino orquestrado com gates por segmento, modelo no registry, serving (BentoML/KServe) com testes de carga, e monitoramento de drift (Evidently) que dispara retraining simulado. README + artigo explicando cada decisão.
2. Demonstração de leakage: pegue um dataset conhecido, introduza (e depois corrija) três tipos de vazamento, mostrando a métrica inflada e a real. Ótimo para entrevista.
3. Estudo de serving: o mesmo modelo servido de 4 formas (FastAPI, BentoML, ONNX Runtime, Triton) com benchmark de latência/throughput/custo e recomendação.
4. Monitor de drift do zero: implementar PSI/KS e detecção de drift de predição sobre um stream simulado, com dashboard e alarme — mostra que você entende o mecanismo, não só a ferramenta.

10.5 Ferramentas e fontes para continuar

• Tracking / registry: MLflow, Weights & Biases, Neptune, ClearML.
• Dados: DVC, lakeFS, Great Expectations, pandera, TFDV.
• Feature store: Feast, Tecton, Hopsworks.
• Pipelines: Kubeflow, Metaflow, ZenML, Vertex/SageMaker Pipelines, Airflow/Dagster para o lado de dados.
• Serving: BentoML, KServe, NVIDIA Triton, Ray Serve, ONNX Runtime, TensorRT.
• Monitoramento: Evidently, NannyML, whylogs/WhyLabs, Arize, Fiddler.
• Leitura: Designing Machine Learning Systems (Chip Huyen); Machine Learning Design Patterns (Lakshmanan et al.); o paper "Hidden Technical Debt in ML Systems" (Google); o guia "MLOps: Continuous delivery and automation pipelines in ML" (Google Cloud); a checklist "ML Test Score" (Google).