Engenharia de Machine Learning
Plataformas de Machine Learning — Parte I — Modelos do Ponto de Vista da Engenharia.
Na primeira parte da série vamos falar sobre o ponto de vista dos nossos engenheiros e engenheiras sobre modelos de machine learning.
Atenção: O papel e as responsabilidades da engenharia de machine learning divergem (e muito) entre empresas e até entre áreas de uma mesma empresa. Neste artigo, apresentamos a visão do time de dados de crédito da Stone sobre o assunto.
1. Introdução
Em geral, nosso primeiro contato com modelos de machine learning ocorre na perspectiva da ciência de dados. Na área, é comum encontrar todo o ciclo de vida de modelos (feature engineering, modelling, monitoring, serving, etc.) em soluções de notebooks como Jupyter, AWS SageMaker e GCP Colab. Os beneficios são evidentes: infraestrutura autogerênciada, velocidade de prototipagem, autonomia do código ponta a ponta, etc. Contudo, a prática também reforça o estereótipo de que um cientista de dados “gasta mais tempo preparando do que modelando dados”. Indo além, em times de ciência de dados, a prática impacta negativamente outras atividades como reuso de features e a atualização e manutenção de modelos.
De fato, o ciclo de vida de um modelo exige múltiplas habilidades: engenharia de dados para construção de features, ciência de dados para a seleção e treinamento de modelos, engenharia de software para servir as predições, etc. Para separar as responsabilidades e escalar todo o processo, existem as plataforma de machine learning. Uma plataforma é uma arquitetura de dados que busca industrializar a criação, implantação, disponibilização e monitoramento de modelos.
Esta série é sobre os elementos de uma plataforma de machine learning: model registry, feature store, modelling sandbox, prediction service e monitoring service. Contudo, antes de falar de arquitetura, precisamos aprender a olhar para os modelos do ponto de vista da engenharia. Em especial, entender o que significa o versionamento de um modelo de machine learning.
2. Modelos do ponto de vista da engenharia
Um modelo de machine learning pode ser encarado como um tradicional objeto do paradigma de orientação a objetos, com seu estado (stateful object) e seus métodos.
O estado de um modelo é composto pelos seus hiperparâmetros e parâmetros. O método de treino atualiza seu estado e o método de predição consome-o para gerar predições.
De maneira geral, o estado de um modelo é composto por seus hiperparâmetros (kernel de uma máquina de vetores de suporte, topologia de uma rede neural, etc.) e parâmetros (pesos de uma regressão logística, entropia de um nó de uma árvore de decisão, etc.), respectivamente definidos antes e depois da execução do método de treino. Este, por sua vez, é uma função dos atributos independentes (features), da variável resposta (target) e dos próprios hiperparâmetros e tem como objetivo atualizar o estado do objeto. Já o método de predição consome o estado para gerar predições. A possível definição de uma classe para representar um modelo de machine learning genérico está presente no algoritmo I.
Como exemplo, podemos estender a classe genérica e alterar o método de treino e predição (algoritmo II) para criar um modelo de machine learning de regressão linear.
Com os métodos definidos, basta instanciar a classe e atualizar o seu estado com método de treino, et voilá, o modelo está pronto para fazer predições. No algoritmo III vamos além, utilizamos o módulo pickle, nativo da linguagem Python, para serializar o objeto recém criado em um arquivo chamado ml-model-v1–0.pickle, permitindo assim que o modelo possa ser persistido em disco (local, cloud, etc.). Note que estamos definindo como a versão 1.0 (major.minor) do modelo de machine learning como conjunto atual do seu estado e da definição do seus métodos.
A versão do objeto de um modelo de machine learning é definida pelo seu estado atual (parâmetros e hiperparâmetros) e a definição de seus métodos (treino e predição).
Para utilizar o modelo para gerar predições, basta utilizar novamente o módulo pickle, mas agora para deserializar o objeto em memória, como no algoritmo IV. A única restrição é que a definição da classe do modelo deve estar presente.
3. Versionamento de modelos
Partindo da relação entre a versão de um modelo com seu estado e seus métodos, a nossa proposta é a seguinte: toda vez que o estado do modelo for alterado (novos hiperparâmetros, novos dados de treino, etc.), incrementa-se o minor da versão. Logo, toda vez que os métodos forem alterados (novo modelo), incrementa-se o major. A proposta é complacente com o versionamento semântico e sua definição de compatibilidade reversa, pelo menos durante a etapa de modelagem. Nós a chamamos de ML Versioning ou MLV. Confira alguns exemplos:
MLV (ml versioning) é um padrão para versionamento de modelos de machine learning. Mudanças nos hiperparâmetros ou nos dados de treinamento (estado) alteram o valor minor da versão. Por sua vez, alterações no algoritmo do modelo (métodos) alteram o valor da major.
3.1. Versionamento do estado
No exemplo do algoritmo V, utilizamos o modelo de regressão linear e alteramos seus hiperparâmetros. Como a modificação foi no estado do modelo, alteramos o valor minor da versão, 1.0 para 1.1. Após a execução do método de treino, serializamos o modelo no arquivo ml-model-v1–1.pickle.
3.2. Versionamento dos métodos
Já no exemplo do algoritmo VI, alteramos o modelo de regressão linear para um modelo de regressão logística.
Como a modificação foi (majoritariamente) nos métodos do modelo, alteramos o valor major da versão, de 1.0 para 2.0. Após a execução do método de treino, serializamos novamente o modelo no arquivo ml-model-v2–0.pickle, conforme o algoritmo VII.
3.3. Modelos como artefatos
Por fim, teremos três versões diferentes de um modelo de machine learning serializadas, mas que produzem predições para a solução de um mesmo problema.
Com esse novo ponto de vista, estamos prontos para falar sobre o primeiro elemento de uma plataforma de machine learning, o model registry, que busca armazenar modelos como artefatos de forma semelhante ao que o PyPI, Maven e NPM fazem com módulos Python, Java e JavaScript respectivamente, ou ainda ao que o Docker Hub, AWS Elastic Container Registry (ECR) e GPC Container Registry fazem com imagens Docker. Mas isso é um papo para o próximo artigo da nossa série.
Não percam os próximos artigos. 😉
Pra fechar com chave de ouro, é com muito orgulho que trago aqui a primeira vaga de engenheiro de machine learning do time de dados de crédito da Stone 💚. Se você curtiu a nossa visão sobre a área, inscreva-se e vem pintar o mundo de verde com a gente.
