CD4ML: Entrega Contínua para Machine Learning

Problema e solução - Apresentação

Boas-vindas ao curso de Entrega Contínua para Machine Learning.

Eu sou o Igor do Nascimento Alves, vou ser seu instrutor neste curso de CD4ML: Entrega Contínua para Machine Learning. Eu sou um homem branco, de cabelos pretos, curtos, uso óculos de armação redonda. Também possuo um fone de ouvido sem fio, e no meu cenário só temos uma parede com um fundo iluminado pela cor verde, que é a cor da escola de dados.

Neste curso, vamos conhecer o pipeline de um sistema de Machine learning de uma empresa, esse pipeline não está funcionando como eles gostariam, e para conseguirmos aprimorar esse pipeline, vamos aplicar conceitos de Entrega Contínua para Machine Learning, em inglês Continuous Delivery For Machine Learning, que daí vem a sigla CD4ML, que este conceito é mais conhecido.

Este conceito envolve aplicarmos algumas características nesse pipeline de Machine learning, como, por exemplo, automatização dos processos. Então, todo o processo de build do Machine learning vai ser automatizado. A etapa de testes, temos os testes unitários, ou de unidade, os testes de integração, os testes end-to-end e os testes de aceitação. Todos eles vão estar sendo automatizados.

Outra etapa que também vamos trabalhar é o versionamento dos dados, das pipelines, o rastreio dos experimentos, quando estivemos construindo esses modelos de Machine learning. E também, por fim, o registro de logs desse sistema, tornando possível a melhora contínua desse modelo de Machine learning em produção.

Para você conseguir acompanhar todos esses conceitos e entender o que estamos fazendo, você precisa apenas conhecer como funcionam os modelos de Machine learning. Tendo dito tudo isso, estamos prontos para nos aprofundar nesse assunto. Vamos lá?

Problema e solução - Processo atual da empresa

Nós fazemos parte de um time de consultoria que foi contratado por uma grande rede de mercado. Essa rede de mercado estava enfrentando um problema. O problema deles era montar estoques com precisão.

Por que montar um estoque com precisão é tão importante? Por exemplo, caso eles comprassem poucos biscoitos, porque eles acreditavam que esse produto não venderia muito, então eles armazenaram pouco desse produto em estoque. Caso essas vendas acontecessem mais do que eles tivessem em estoque, eles teriam que rapidamente acionar o fornecedor para reabastecer os estoques.

Provavelmente, com essa urgência, esse tempo curto, eles não conseguiriam negociar bem o valor desse produto, então eles pagariam mais pelo produto e teríamos também a questão do tempo, desde o fornecedor trazer esse produto para nós, colocar em estoque e depois esse estoque ser fornecido para os clientes. Então, teríamos uma demora, perderíamos algumas vendas nesse processo.

O segundo erro que pode acontecer é se comprássemos muitos biscoitos, então acreditaríamos ter uma grande venda de biscoitos, faria um grande estoque disso e essas vendas não aconteceriam, não se concretizariam.

Isso é um problema, porque teríamos muitos produtos em estoque que podem vencer, o produto tem a data de vencimento, poderia estragar e perderíamos, teríamos esse prejuízo. E esse produto também tem um problema, porque ele está ocupando um espaço no nosso estoque.

O nosso estoque custa dinheiro para mantê-lo lá, e ele pode ocupar o espaço de um produto que a venda esteja funcionando melhor. Então, acertar quantas vendas vão acontecer para montar um estoque com precisão é muito importante para eles.

Com isso, eles criaram a solução de construir um modelo de Machine learning que conseguisse prever o número de vendas daquele produto. Para isso, o primeiro passo que eles deram foi acionar o time de engenharia de dados, esse time de engenharia de dados ficaria responsável por fornecer os dados históricos de venda.

Para esse time, isso não seria um problema, porque atualmente ele já fornece essas informações para o time de análise de dados, que gera relatórios e dashboards para as lideranças da empresa.

Então, eles rapidamente conseguiriam agregar todas as informações da empresa sobre vendas e concretizar tudo isso em um arquivo bruto de dados históricos. Esse arquivo bruto é muito importante para construir modelos de Machine learning.

Eu abri uma planilha que demonstra como esse arquivo pode parecer. Então, temos sete colunas, a primeira é o ID, que identifica qual produto é o número único de identificação dos produtos.

Temos o nome e a categoria a qual esse produto pertence, então temos um nome, por exemplo, “Arroz”, “Livros”, “Notebooks”, que são informações relacionadas àquele ID. A categoria para qual esse produto pertence, temos o preço e o custo daquele produto, quanto ele nos custou e por quanto ele foi vendido.

Temos três datas nesse arquivo também, que é a data de compra, a data de venda e a data de vencimento. Você, pessoa cientista de dados, que já trabalhou com dados brutos, sabe como pode ser difícil às vezes, temos essas informações agregadas de diversas bases, que tinham padrões diferentes e produtos que não se relacionam bem na mesma tabela, todos agregados nela, isso gera alguns problemas, alguns ruídos de informação.

Então, por exemplo, tem alguns outliers, alguns números de custos que parecem estar incorretos e precisamos resolver, tratar esses dados, antes de colocá-lo no modelo de Machine learning.

Outra situação que pode acontecer é termos dados nulos. Por exemplo, nesse caso temos duas bases agregadas, em que temos produtos com data de vencimento e produtos que não têm data de vencimento. E quando essas informações foram agregadas, os produtos que não tinham essa data ficaram com valor nulo, e isso não funciona para os modelos de Machine learning.

Mas os dados brutos são muito importantes, porque eles estão com o máximo de informação possível para a pessoa cientista de dados trabalhar e identificar quais dados fazem sentido para o modelo de Machine learning e quais não fazem.

Agora que já conhecemos um pouco sobre esses dados, podemos voltar para o nosso pipeline e ver que agora que o time de engenharia de dados terminou o papel dele, que era fornecer esse arquivo de dados brutos.

Agora, o segundo time entra em ação para construir esse sistema de Machine Learning, que é o time de pessoas cientistas de dados. Esse time de pessoas cientistas de dados fica responsável por pegar esse arquivo bruto e começar a construir alguns modelos de Machine Learning.

Então, eles vão entrar em uma etapa de experimentação, eles vão criar diversos modelos, para tentar encontrar o que vai ter a melhor performance, vai acertar mais, e também vão otimizar esse modelo.

Quando eles encontrarem o modelo, eles vão encontrar os melhores hiperparâmetros desse modelo. Hiperparâmetros são as características que regem como o modelo vai funcionar, como ele vai aprender com aqueles dados.

Por exemplo, um modelo de árvore de decisão vai ter a profundidade, então é um parâmetro dele que precisa ser otimizado e entender qual funciona melhor para esses dados e para o programa que está sendo resolvido.

Depois de toda essa experimentação, o time de cientista de dados vai criar um modelo final, que vamos chamar de “artefato”. Esse artefato representa o modelo final, ele está ajustado aos dados e é capaz de fazer previsão de venda a partir de determinadas características do produto.

Então, o nome do produto, por quanto ele está sendo vendido, quanto ele custou, a data que ele foi comprado, e prever quantas unidades daquele produto serão vendidas.

Porém, esse modelo ainda é um arquivo, que não vai ser útil para a pessoa que cuida do estoque. Ela tem um sistema atualmente, em que ela consulta o produto que ela quer comprar, quantos ela vai comprar, e esse arquivo não está conversando com esse sistema deles. Por isso, foi necessário acionar mais um time nesse nosso fluxo.

E esse time precisaria juntar duas skills muito importantes, que é desenvolvimento de software, então, criar uma integração entre esse modelo final, esse arquivo que recebe parâmetros e responde com a previsão de venda, com o sistema atual que já existe na empresa, o sistema de estoque a pessoa responsável por isso já sabe mexer.

Então, criar essa integração precisa dessa pessoa desenvolvedora, que vai criar isso. Outro conhecimento necessário desse time seria a operação, então, colocamos essa nova integração para funcionar. Uma infraestrutura que pode ser na nuvem, pode ser local, mas esse conhecimento precisa estar lá para esse sistema funcionar.

Por isso foi criado o time de operação. O time de operação vai ficar com a responsabilidade de pegar o modelo final e colocá-lo em produção. Com ele fazendo todo esse trabalho de fazer esse modelo, integrá-lo com o sistema, vamos ter finalmente o nosso sistema de Machine learning.

Então, esse sistema de Machine learning está integrado com a pessoa do estoque, ela pode agora prever a bolacha, ela pode querer saber quantas unidades de determinada marca de bolacha, com características específicas, que o modelo determinado vai prever que serão vendidos dois mil no mês de fevereiro.

Então, agora a pessoa do estoque pode utilizar essa informação para montar o estoque dela, para fazer um estoque mais preciso. Esse sistema funcionou, mas eles encontraram alguns gargalos, alguns problemas em todo esse fluxo.

Por exemplo, o sistema de Machine learning não está registrando suas previsões, então não sabemos como esse modelo está saindo em produção, como ele está saindo no mundo real, porque nos testes, na experimentação, ele funcionava muito bem, mas como ele está performando lá?

Outra informação que não temos é se essa decisão está sendo utilizada. Então, a pessoa do estoque está levando essa informação em consideração? E se ela não está levando, por que ela não está levando? Todo esse log, esse registro de como o nosso sistema está sendo utilizado, não está sendo salvo, então estamos colocando o sistema de produto, e não temos mais informações, não temos um cuidado com ele.

Outro cuidado que não está acontecendo é melhorar esse sistema. Então, podemos adicionar novas características a esse problema, melhorar cada vez mais esse modelo. Mas no nosso fluxo atual, essa melhora está toda travada.

Porque, por exemplo, se o time de cientista de dados recebesse a demanda de melhorar um modelo, ele precisa performar melhor em produção, eles teriam que acionar o time de engenharia de dados novamente, para fazer a extração de novos dados históricos para o time de cientista de dados, então o time de cientista de dados poderia trabalhar, criar novos modelos, que poderiam mudar as características do modelo.

Por exemplo, agora ele não vai mais receber data de vencimento, porque isso torna a precisão dele melhor. Com essa mudança, teríamos que novamente acionar o time de operação, o time de operação teria que fazer mudanças no sistema para aceitar esse novo modelo, que agora ele trabalha com outros parâmetros de entrada.

Esse time também teria que estar sempre disponível, já que o time de cientista de dados não consegue ter essa autonomia de pegar o modelo final que eles construírem, fizeram a experimentação e já colocá-lo em produção.

Então, esse time de operação que guarda o conhecimento de rodar um script específico, que vai pegar este artefato e vai fazê-lo funcionar. Então, os conhecimentos estão todos fechados dentro de cada time.

Só o time de engenharia de dados sabe o histórico dos dados, só o time de cientistas de dados sabe como construir os modelos, e o time de operação, de como eu vou colocar esse modelo em produção. Então, todo esse nosso sistema está frágil, e não está se comunicando muito bem.

Esse problema que precisamos resolver com o time de consultoria já aconteceu em outra situação, essa situação foi o desenvolvimento de sistemas de software, lá eles também enfrentaram esse problema de conseguir melhorar cada vez mais rápido o sistema, acionando novas features, novas características.

Lá, eles resolveram isso com o conceito de Entrega Contínua e Melhoria Contínua, ou CICD. Esse conceito tem o objetivo de tornar esse processo mais rápido, tornar esse processo mais otimizado.

Precisamos conhecer um pouco mais profundamente o CICD e ver como podemos aplicar essas características para o nosso problema de sistema de Machine learning. Então, vamos lá entender melhor isso?

Problema e solução - Integração e Entrega Contínua

Com a evolução do desenvolvimento de sistema de softwares, as melhorias precisavam acontecer cada vez mais rápido, de maneira contínua. Por isso, eles começaram a identificar alguns problemas nos processos atuais deles. Vamos conhecer um pouco esses processos.

Um time era responsável por construir uma nova funcionalidade e com isso gerava um novo código com essa funcionalidade. Já um segundo time estava em paralelo trabalhando em uma segunda funcionalidade do sistema.

[00:29] Então, por exemplo, em um sistema de vendas, um time estava responsável por melhorar o botão de compra de produtos, e o segundo time estava responsável por melhorar a recomendação de produtos. Esses dois times estavam trabalhando em paralelo com o mesmo código principal, uma cópia do código que estava funcionando no sistema de vendas em produção, e eles começaram a desenvolver essa feature.

Quando eles terminaram de desenvolver essa feature, eles precisariam fazer um merge, que é unir o código que eles trabalharam localmente na máquina deles, com o código que estava funcionando em produção.

Por eles desenvolverem essa funcionalidade ao longo de um grande tempo, por exemplo, em uma sprint, um mês, 15 dias, esse código poderia variar muito do código que eles estavam trabalhando localmente, com o código que estava em produção.

Então, toda essa etapa de merge, por ela ter levado muito tempo para acontecer, gerava um processo mais lento ainda, para fazer esse código se encaixar com o código que estava em produção agora.

Mas depois que eles conseguiam juntar esses dois códigos, eles podiam colocar esse novo código em um main, que é o código principal, o código que vai funcionar em produção. Com isso, começava o papel de uma terceira pessoa, que é o tech lead, o líder técnico das equipes, que era responsável por pegar esse código que unia, agora com novas funcionalidades, e fazer testes nele.

Então, esse código precisaria funcionar da maneira que era esperado, tanto as novas funcionalidades quanto as funcionalidades que já existiam na empresa. Por esse processo ser muito manual, tínhamos um número limitado de testes que eram possíveis fazer.

Caso o sistema não funcionasse e esses testes falhassem, não passou, voltaríamos para o código da versão anterior, então a pessoa tech lead ficaria responsável por retornar o código para a versão que funcionava, e as funcionalidades precisariam ser retrabalhadas. Mas, caso esse teste passasse, poderíamos seguir para uma próxima etapa.

Essa próxima etapa é fazer o build, então pegaríamos aquele código, passou, está funcionando agora, e fazer o pacote dele, com todos os pré-requisitos dele, se ele utiliza algumas bibliotecas novas, esse pacote seria criado, esse código seria compilado e pronto para colocar em produção. Então, essa etapa de build também seria feita pela pessoa técnica.

Com o novo pacote pronto, podemos colocar o nosso código em produção. Então, o nosso sistema teria sido atualizado.

Todas essas etapas estavam muito manuais, e geravam um gargalo, então tínhamos esse momento no final de uma sprint, por exemplo, que todo mundo ficava estressado, porque tínhamos toda a etapa de merge para fazer o código novo funcionar, teríamos que fazer esse código passar nos testes e construir esse build manual e colocar o código em produção.

Toda essa etapa era muito cansativa e não era ágil. Então, ele não refletia o que o sistema precisava, ele precisava de uma melhora rápida. Nosso botão de recomendação, que era a funcionalidade 2, precisava ir logo para a produção, para vermos se ia funcionar, ver se fazia sentido aquele botão. Então, esse processo precisava ganhar agilidade.

Você, se fosse, por exemplo, a pessoa responsável por pedir novas funcionalidades, você ficaria com receio, porque todo esse processo muito manual, você poderia ficar com medo de pedir uma nova funcionalidade e isso quebrar o sistema que já funcionava. Então, precisaríamos de testes que englobassem mais todo o processo do nosso sistema.

E se você fosse a pessoa desenvolvedora do sistema, você também teria medo de criar novas funcionalidades, falar que vai ter a etapa de merge e está com medo de quebrar um código que já está funcionando. Dizer que queria poder colocar logo esse código em promoção, mas saberia que todas as etapas que envolvem colocar sua nova funcionalidade em produção levam muito tempo.

Então, todo esse problema precisava ser resolvido, então, foi aí que apareceu a Entrega Contínua, Melhoria Contínua, que é o CICD. Ele tem a proposta de melhorar esse sistema e permitir, que vem até do nome dele, essa melhoria contínua.

Então, continuamente sempre vamos colocar pequenas atualizações no sistema, não teríamos mais aquele grande momento, em que todas as funcionalidades da sprint seriam colocadas no sistema.

Não, colocaríamos aos poucos, então, não seria mais uma grande coisa, um grande momento colocar o código em produção. Não, isso acontece diariamente, por exemplo. Então, diariamente, a pessoa está desenvolvendo uma funcionalidade que ela já é capaz de colocar o código dela em produção.

E conseguimos isso, através, por exemplo, da automatização. Então, tiramos aquela pessoa responsável por pegar o código, fazer os testes, fazer o build e colocar em produção. Conseguimos automatizar esse processo, tornando ele muito mais rápido e menos custoso.

Com isso, conseguimos fazer merges mais frequentes, então agora, não precisamos esperar um grande momento para colocar o código em produção. Com a automatização, a pessoa desenvolvedora tem a autonomia de ela desenvolver o código e já fazer o commit dessa atualização, então colocar o código no main.

E já que isso vai acontecer com mais frequência, o código dela vai refletir muito o código que já estava em produção, não vai ter muitas modificações que aconteceram. Então, esse merge vai ficar fácil de fazer, não vai ter muitas diferenças com o código que ela trabalha localmente, com o código que está funcionado.

Outra possibilidade é ter mais testes, então, agora com essa frequência maior de fazer o seu código local ir para a produção, você pode também desenvolver testes. Dizer que tem um teste para a nova funcionalidade, e sobe ele com o seu código novo e ele é agregado nesses testes automatizados.

Então, além da minha funcionalidade estar sendo testada, todo o sistema, todas as partes core do nosso sistema, por exemplo, se é um sistema de vendas, então, o nosso botão de venda está funcionando, nós rodamos um teste.

Com essa nova funcionalidade, o recurso anterior não quebrou, então temos mais testes, conseguimos colocar esse processo com mais frequência em produção. Essa foi a vantagem que tivemos em aplicar o CICD em desenvolvimento de software.

E todo esse conhecimento faz muito sentido também para o nosso processo que estamos tentando melhorar. Então, no nosso processo de criar um sistema de Machine Learning, toda essa automatização, esse versionamento, no desenvolvimento de software tinha código, nesse caso podemos mencionar artefatos.

Então, todo esse conhecimento que temos no CICD, podemos trazer para o nosso sistema de Machine Learning. E esse conceito de trazer o CICD para sistema de Machine Learning, é o nosso CD4ML, que é o Continuous Delivery For Machine Learning, é a entrega contínua para sistema de Machine learning.

Aplicando esses conceitos, vamos ajudar o nosso cliente que precisa de um processo mais eficiente, com maior qualidade.

O primeiro passo que vamos fazer para aprimorar o nosso sistema, vai ser automatização. Vimos como automatização é muito importante no sistema de software, e vamos ver como podemos automatizar alguns processos no nosso sistema de machine learning. Vamos lá?

Sobre o curso CD4ML: Entrega Contínua para Machine Learning

O curso CD4ML: Entrega Contínua para Machine Learning possui 109 minutos de vídeos, em um total de 43 atividades. Gostou? Conheça nossos outros cursos de Machine Learning em Data Science, ou leia nossos artigos de Data Science.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Problema e solução
• Automatizando o processo
• Rastreamento de artefatos
• Melhoria contínua