Nas últimas semanas, minhas discussões se tornaram uma nuvem de buzzwords: MLOps, CICD, pipeline, kubernets, cloud, cloud, cloud.
A verdade é que estamos observando uma mudança de mentalidade importante no que entendemos como machine learning (ML).
Após todo aquele grande buzz em torno de inteligência artifical, ML e automatização de processos, estamos caindo na real que precisamos entregar todas essas promessas.
Mas, não me entenda mal.
Quando falo sobre entregar, quero dizer de forma profissional, eficiente e adequada para os desafios que a disciplina de ciência de dados exige.
Já observamos isso acontecendo nas squads tradicionais de DevOps. O desenvolvimento de software garantido integração e entrega continua (CICD) já é uma cultura, com ferramentas e mais de 10 anos de experiência.
E a pergunta que nos resta é: como pensar um MLOps, combinando os desafios do machine learning com as boas práticas de CICD que já existem?
Eu também não sei!
A boa noticia é que estamos todos tentando descobrir.
Do último ano prá cá, vimos como esse pensamento se estruturou na forma de diversos textos procurando pensar sobre o tema. Entre os meus favoritos estão:
E, foi nesse cenário que junto com @thalsin e @eduardovelludo , decidimos tornar uma competição no @Kaggle um simulacro do que esperariamos num cenário ideal de MLOps.
Os eventos a seguir datam de 1 semana.
Prólogo
Com mais de 1200 times e dois meses para seu deadline, a competição kaggle ASHRAE - Great Energy Predictor III tem como objetivo realizar a previsão do consumo de energia predial hora a hora baseado em medições climáticas, localização etc.
De fato, um problema de regressão com grande potêncial de emsembling de modelos e feature engineering.
Ao ingressarmos na competição, fizemos a escolha de nos separarmos em duas equipes: (1) cientista de dados - com foco no entendimento e modelagem do problema e (2) engenharia de machine learning - com foco em montar a esteira de “deploy” dos modelos criados.
“deploy”
Deploy entre aspas.
Diferente do deploy tradicional - em que realizamos requisições via API para escoragem de uma base ou observação - nosso deploy consiste em submeter o melhores modelos criados (base escorada) de forma automátizada para o Kaggle.
E foi nesse primeiro entendimento da target de nosso problema de engenharia que surgiu a necessidade de alinhar muito bem, as entregas e requisitos de cada um dos times.
Apesar de estarmos buscando o mesmo desafio, as responsabilidades e atividades exigiriam focos completamente diferentes.
A engenharia se preocuparia em testar e implementar diferentes tecnologias para a esteira de CICD com a certeza de que teria os inputs dos cientistas de dados em um formato especifico.
O time dos cientistas se preocuparia em testar diferentes soluções com a certeza de que a engenharia seria capaz de fornecer ferramental e adaptações na esteira de CICD para o deploy desejado.
Tratamos esse processo de forma bem consciente, na forma de um “teatro” que pudesse simular uma interação real entre estes dois times, para que pudessemos visualizar possíveis pontos de atenção e atrito na construção deste MLOps.
Ato 1 - The gathering of clouds
A primeira - e mais honesta - pergunta partiu dos cientistas.
Onde vamos trabalhar?
Apesar de não ser uma questão de CICD, entedemos que a resposabilidade de criar o ambiente para a atuação do cientista caberia a Engenharia de Machine Learning, tanto pelas competências envolvidas, quanto pela facilidade a posteriori de adequar o ambiente de prototipação com o deploy.
Por adotarmos python no projeto, o uso de jupyter notebooks era natural. Mas, a partir dessa decisão outras perguntas vinheram e dessas muito outras:
└── Trabalharemos em máquina local ou na cloud?
└── Cloud
├── Cloud pública ou privada?
│ └── Cloud Pública
│ └── AWS, GCP ou Azure?
│ └── Qual delas oferece free tier mais vantajoso?
│ └── GCP
│
└── Quais serão os requisitos da máquina?
├── Alinhamento com cientistas de dados
├── Como garantir um ambiente sandbox ao cientista?
│ └── Conteinerização das aplicações
└── Como garantir a contínua atualização dos requisitos?
├── Conteinerização das aplicações (dockerfile)
└── Como tornar a atualização automatizada?
└── Ferramentas de IaaC
└── Qual delas é agnostica à cloud?
└── Terraform