O CI/CD (Continuous Integration / Continuous Deployment) é um padrão no desenvolvimento de software. Mas aplicar os mesmos princípios ao Machine Learning requer adaptações significativas. Um modelo ML não é um microsserviço: ele depende de dados, de hiperparâmetros e de métricas de performance que não existem no desenvolvimento clássico.
Os 3 pipelines do MLOps
Um sistema MLOps maduro se baseia em três pipelines distintos:
Pipeline de dados
Ele coleta, limpa e transforma os dados de treinamento. É o mais frequentemente negligenciado e, no entanto, o mais crítico.
- Versionamento dos datasets com DVC ou LakeFS
- Testes de qualidade automatizados (Great Expectations)
- Feature store para centralizar e reutilizar as features
Pipeline de treinamento
Ele treina o modelo, avalia seu desempenho e decide se a nova versão é elegível para implantação.
- Experiment tracking com MLflow ou Weights & Biases
- Hyperparameter tuning automatizado (Optuna, Ray Tune)
- Model registry para versionar os modelos validados
Pipeline de implantação
Ele implanta o modelo em produção e monitora seu desempenho continuamente.
- Serving via API REST (FastAPI, TensorFlow Serving) ou batch
- A/B testing ou canary deployment para implantações progressivas em produção
- Monitoring do drift (dados e desempenho)
Testes específicos para ML
Além dos testes unitários clássicos, um pipeline ML necessita de testes específicos:
- Testes de dados: as distribuições de entrada estão em conformidade com as expectativas?
- Testes de modelo: a nova versão é melhor do que a anterior?
- Testes de infraestrutura: o modelo carrega corretamente? Os tempos de resposta são aceitáveis?
- Testes de viés: o modelo é justo nas diferentes subpopulações?
O monitoramento em produção
Um modelo ML se degrada naturalmente com o tempo. Os dados de entrada evoluem (data drift), os comportamentos mudam (concept drift). O monitoramento deve cobrir:
- Performance de negócio: os KPIs de negócio ainda estão sendo alcançados?
- Data drift: as distribuições de entrada mudaram?
- Prediction drift: as saídas do modelo mudaram?
- Latência e disponibilidade: o modelo responde dentro do tempo esperado?
Nossa stack recomendada
Para uma PME ou uma primeira implantação MLOps:
| Componente | Ferramenta recomendada |
|---|---|
| Orquestração | Prefect ou Airflow |
| Experiment tracking | MLflow |
| Feature store | Feast |
| Model serving | FastAPI + Docker |
| Monitoring | Evidently AI |
| Infraestrutura | Kubernetes ou serverless |
O objetivo não é implementar tudo desde o início, mas construir progressivamente de acordo com suas necessidades.
