Nossos primeiros passos para escalar a produção de modelos de Data Science

Quando o time de Data Science finaliza um modelo de machine learning, sempre existe uma grande expectativa para disponibilizar este modelo rapidamente em produção, na maioria das vezes são modelos com grande potencial para alavancar o negócio. Mas o time de Data Engineering da Creditas tinha dificuldade em atender essas demandas com a agilidade esperada, principalmente devido à alta demanda do time e a dificuldade das pessoas do time alternarem entre os diferentes contextos de Data Science, Analytics e plataforma de dados.

No artigo intitulado “Precisamos especializar o time de engenharia de dados”, o André Casimiro, gerente do time de Data Engineering da Creditas, fala sobre a necessidade de equipes especializadas. No artigo mencionado, ele explicou a necessidade de quebrar a Engenharia de Dados em uma estrutura mais flexível para trabalhar com o ciclo de vida dos dados usados na Creditas, amplificar a inovação e suportar as melhores tomadas de decisão no desenvolvimento de produtos.

Em meio a essa reestruturação surgiu o time Machine Learning Engineering na Creditas. Assim, neste artigo vou falar um pouco sobre o escopo desta nova equipe e a sua respectiva estratégia para acelerar o ciclo de desenvolvimento dos modelos de Data Science.

Figura 1 — Especialização da Engenharia de Dados para trabalhar o ciclo de vida dos Dados

Motivação do Time de Machine Learning Engineering

O time de MLE (Machine Learning Engineering) nasceu com o propósito de acelerar o ciclo de vida do time de Data Science, tornando-o 100% autônomo e livre para inovar cada vez mais. Na prática, isso significa invadir o ciclo de desenvolvimento de Data Science para operacionalizar — de preferência automatizar — todas as tarefas maçantes de dados e DevOps, desde a captura e transformação de dados até a disponibilização da infraestrutura requerida para a implantação de modelos em produção.

Inspirados pela plataforma de Machine Learning da Uber, denominada Michelangelo, iniciamos a missão de materializar uma experiência de self-service na produção de modelos para os cientistas de dados através da construção de uma plataforma que chamamos de Brain.

BRAIN — Machine Learning Engineering Platform

A proposta do Brain é criar uma plataforma que acompanhe todo o ciclo de vida de um modelo concebido pelo time de Data Science. A Figura 2 mostra algumas das funcionalidades da plataforma e como ela deve impactar o ciclo de desenvolvimento dos modelos de Data Science.

Figura 2 — Presença da plataforma Brain no ciclo de desenvolvimento de Data Science

Uma das funcionalidades é o Feature Store, que permite à equipe de ciência de dados ingerir, catalogar e compartilhar features de forma centralizada para serem usadas de acordo com o tempo e necessidade de cada um. Uma vantagem óbvia desta prática é que ela permite diminuir o atrito nas etapas de captura e transformação de dados, dando grande velocidade à equipe de ciência de dados na etapa de pesquisa exploratória.

Após a aquisição do dataset a equipe de ciência de dados precisa ter um ambiente de desenvolvimento adequado para escalar o processamento horizontal ou verticalmente, por exemplo, utilizar GPU para algum treinamento mais intensivo, e uma forma de disponibilizar rapidamente os modelos nos ambientes produtivos.

A Figura 3 mostra o processo entre adquirir o dataset de treino e colocar o modelo em produção:

Figura 3 — Ciclo de vida de modelos de machine learning

Mas o que fizemos até agora?

A principal dor que precisávamos resolver era a implantação dos modelos que durava cerca 2 semanas para entendimento do contexto por parte do time de engenharia de dados, criação da API para servir o modelo, implantação e monitoração do modelo.

Para resolver esse problema começamos a desenvolver uma das capacidades da plataforma Brain que é a implantação dos modelos. Os modelos criados na plataforma são apelidados de “neurons” e seguem a “receita” mostrada na Figura 4.

Figura 4 — Template de aplicação neuron

Para integrar os neurons com as aplicações da Creditas, desenvolvemos uma aplicação chamada Dendrito, que serve como orquestrador das requisições e faz coletas de dados internos e externos para alimentar os neurons, como mostra a Figura 5.

Figura 5 — Dendrito

Quando a equipe de ciência de dados termina a pesquisa e alcança as métricas desejadas, temos como etapas seguintes a criação de um repositório no GitHub (baseado no template do neuron) e a edição de alguns campos de configuração do neuron, tais como:

• Arquivo de configuração do neuron que contém algumas informações importantes sobre as features de entrada e saída do modelo.
• Path do modelo treinado e serializado em um formato de arquivo pickle.
• Path do Pipeline do scikit learn para execução da etapa de feature engineering.

A Figura 6 mostra o processo de criar e implantar um neuron.

Figura 6 — Criação e deploy de um neuron.

Antes de implantar o neuron criamos a infraestrutura para ele, como mostra a Figura 7.

Figura 7 — Criação da infraestrutura de um neuron.

Assim, seguindo os passos mostrados nas Figuras 6 e 7 conseguimos entregar modelos em produção com pouca ou nenhuma programação e resolvemos alguns dos problemas mencionamos no começo deste artigo.

Resultados e Lições aprendidas

Até o momento em que este texto foi publicado já tínhamos 7 neurons em produção, incluindo os modelos legados.

A partir de um conjunto de arquivos válidos, conseguimos fazer a implantação da aplicação nos ambientes produtivos em alguns minutos. A implantação do primeiro neuron levou cerca de 1 semana — metade do tempo necessário antes — , principalmente devido ao custo de “traduzir” o Jupyter notebook em um neuron “produtizável”.

Os neurons seguintes foram implantados em média em 3 dias, a melhoria observada ocorreu principalmente por que após o primeiro neuron os times de MLE e Data Science já estavam mais “entrosados” e cientes dos processos necessários para realizar a “passagem de bastão”, além das melhorias implementadas no Brain.

Já nas primeiras entregas notamos uma série de ganhos e oportunidades de melhorias.
O fato de de termos iniciado a construção da plataforma antes de conhecer os detalhes de todos os modelos de Data Science em casa refletiu em ajustes adicionais para comportar os modelos que não se enquadraram na nossa “receita”.
Além disso, gerar um repositório GitHub para cada novo modelo de Data Science atende bem por enquanto, mas, a medida que muitos modelos são criados, começaremos a ter muita duplicação de código e dificuldade em gerenciar os neurons pois a base de código é a mesma com algumas pequenas diferenças entre cada modelo.

Próximos Passos

Temos uma lista grande das funcionalidades que queremos implementar, algumas delas são:

• Integrar o ambiente de pesquisa à plataforma para diminuir o atrito entre terminar um modelo e colocá-lo em produção.
• Construir um Feature Store, um lugar onde a equipe de ciência de dados pode ter acesso às features, de forma normalizada e documentada, dessa forma conseguiremos uniformizar a utilização dos dados entre diferentes modelos.
• Habilitar a capacidade de subir duas versões do mesmo modelo para executar testes A/B.
• Retreino automático dos modelos em produção.

Neste artigo apresentei um pouco da arquitetura que estamos desenvolvendo, mas foquei nas partes que já desenvolvemos e os resultados obtidos. Em breve o Felipe Cordeiro, Tech Lead de Machine Learning Engineering da Creditas, deve apresentar com mais detalhes a nossa arquitetura e o que pretendemos construir. Fique de Olho!

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.