Cuidando dos algoritmos preditivos na firma: uma introdução ao MLOps
O processo de criação de algoritmos estatísticos ou de IA recebe uma boa atenção: afinal, é divertido experimentar coisas novas, não é? É legal testarmos técnicas que sejam novidade, combinarmos diferentes códigos, criarmos visualizações legais, reportarmos erros baixos (ou taxas de acerto altas). É divertido falar coisas como:
Criamos uma Inteligência Artificial que prevê as vendas das próximos meses com 85% de certeza!
Fizemos um algoritmo com Estatística Avançada que comprova que nos próximos meses o valor deste produto abaixará!
Temos um algoritmo preditivo que fornece as recomendações de produtos que poderemos vender aos clientes do nosso e-commerce e que funciona com um erro baixíssimo!
Beleza, mas… E para cuidar disso no dia-a-dia? Isso foi testado fora do seu próprio computador? Como rodar isso automaticamente? E se você sair de férias (ou ganhar um bom dinheiro em criptomoedas) e outra pessoa precisar mexer neste algoritmo? Como acompanhar isso, e garantir que será uma solução robusta do ponto de vista de TI?
É para isto que existe o MLOps, que é uma variação do DevOps. E, para falar de DevOps, precisamos falar sobre como é o dia-a-dia do pessoal de Tecnologia em uma empresa de médio a grande porte.
O dia-a-dia na firma
O pessoal de Tecnologia nessas empresas não é uma equipe de 3 a 5 pessoas, mas sim de algumas dezenas a centenas (ou milhares!), organizadas em uma diretoria ou vice-presidência. Dentro desta estrutura, as pessoas possuem as suas competências (ou seja, o pessoal de back-end, front-end, arquitetura corporativa, gestão de projetos, cientistas de dados, engenheiros de dados, DBAs, segurança da informação, QA, entre outros). Além disso, também podem atuar em dois tipos de trabalho essencialmente: criar coisas novas, ou garantir que o que foi produzido esteja funcionando direito.
A organização das pessoas pode mudar dependendo da empresa: pode ser por squads/tribos/guildas, ou por equipes, ou por qualquer outra forma parecida. Mesmo assim, o desafio permanece: como garantir que novas coisas sejam desenvolvidas direito e como garantir que o que já foi produzido continue funcionando corretamente?
Do ponto de vista das pessoas, isto é relativamente difícil de lidar: quem trabalha com projetos possui como objetivo fazer as entregas das funcionalidades do projeto, mas não exatamente em resolver todos os pequenos bugs ou inconsistências que podem aparecer no dia-a-dia. Já o pessoal que trabalha para dar apoio ao que já foi produzido quer garantir que na sexta-feira, 17h, não apareça nenhum susto que poderá tirar o seu sono no final de semana. O problema é que quem atua com somente um desses mundos dificilmente entenderá as dores de quem está no outro lado.
Para ajudar isso surgiu o DevOps.
DevOps
DevOps é um conjunto de práticas que busca garantir um fluxo contínuo entre desenvolver novas funcionalidades e operacionalizar isto — daí a imagem abaixo [1].
Isto não deve ser entendido como “uma pessoa deve sempre cuidar de tudo — desde o projeto até o dia-a-dia por todos os dias até o final dos tempos”, mas sim uma forma de ajudar que as empresas desenvolvam e melhorem os seus softwares de uma forma mais rápida e eficiente.
Na prática, isto é uma combinação de tecnologias que ajudam a automatizar todo este processo e também uma combinação de pessoas que trabalham de forma integrada no desenvolvimento de novas funcionalidades e na manutenção das mesmas. Assim, a responsabilidade é compartilhada [2].
Olhe só alguns exemplos de ferramentas que poderiam ajudar na automatização/automação deste processo:
Agora, se o DevOps é um conjunto de práticas que garantem uma gestão integrada do ciclo de vida de softwares, como isto funcionaria para o mundo de machine learning (ML)? Afinal de contas, ML vai além daqueles passos da imagem do DevOps, acima. É para isso que veio o MLOps.
MLOps
O ciclo de MLOps é bem parecido com o DevOps. A diferença é que ele é voltado para trabalhos de ML. Cientistas de dados precisam atuar na criação de bons modelos preditivos (ou outros tipos de algoritmos de ML) constantemente. Os modelos podem mudar conforme temos mais dados que possam mudar o comportamento do mercado. Imagine os seguintes exemplos:
- Você trabalha no iFood/Rappi/demais concorrentes, e criou um algoritmo de recomendação de produtos, e ele está funcionando muito bem. Por outro lado, a Copa do Mundo está chegando e, por isso, vários restaurantes estão preparando combos de produtos temáticos. Por isso, precisará retreinar uma nova versão do algoritmo para considerar esta mudança de tendência.
- Você trabalha em um fundo de investimentos e precisa disponibilizar uma nova versão de um algoritmo que projeta tendências de mercado porque, na Europa, aconteceu uma guerra a qual mudou completamente o comportamento do mercado.
- Você trabalha em um e-commerce que comprou uma outra empresa e, por isso, agora oferecem mais produtos para uma nova região do país. Por isso, precisarão readaptar os algoritmos de distribuição logística.
Para todos esses casos, o passo-a-passo de ciência de dados se repete: você faz uma análise exploratória dos dados (EDA); modela esta base de dados; desenvolve e treina novos modelos e, após revisar com o usuário, disponibiliza para que as pessoas possam utilizar [3, 4, 5].
Um processo típico de trabalho com ML é composto por algumas tarefas que se repetem independentemente do tamanho da empresa, da equipe, ou da indústria. Observe a imagem abaixo: após todo o processo de modelagem e obtenção de dados (Data Pipeline), testamos diversos modelos e escolhemos entre eles o melhor em um ambiente com acesso restrito aos demais usuários — afinal, estamos por enquanto somente testando (Dev). Após escolher um bom modelo, testamos e validamos este modelo para ver se faz sentido para as pessoas que o usarão (Preprod). Se estiver tudo certo, disponibilizamos para uso geral (Prod) [4].
O mesmo fluxo acima pode ser também entendido como a imagem abaixo, a qual é bem próxima ao desenho de loop do ciclo de DevOps [3]:
O legal de se trabalhar com DevOps e MLOps é a possibilidade de termos um processo contínuo de desenvolvimento de algoritmos, de integração das atividades de vários desenvolvedores em uma mesma base de código, e de disponibilização desta base (continuous integration/continuous deployment, ou CI/CD). Em MLOps em específico também temos uma possibilidade de treinamento contínuo de modelos (continuous training, ou CT) [3, 5].
Esta parte de treinamento contínuo e das diferentes fases do MLOps podem também ser visualizadas melhor na imagem abaixo: veja que sempre os passos de análise e tratamento de dados vem por primeiro e que há sempre no meio uma etapa de revisão e governança de modelos. Isto é bem importante porque, afinal de contas, os algoritmos de ML podem impactar bastante a vida das pessoas e a saúde financeira das empresas. Logo, a responsabilidade pelos mesmos (e, aqui, trago a palavra accountability) é bem importante.
E, caso tenha interesse, recomendo dar uma olhada no MLflow. É uma ferramenta bem legal para a gestão do ciclo de vida de modelos preditivos que algumas soluções de mercado já utilizam. Logo, se você já atua com isto, testar esta biblioteca pode ser uma boa para você.
Ah, e finalmente: a responsabilidade de um trabalho de DevOps (ou MLOps) não é necessariamente aplicado a uma pessoa, mas a uma equipe: a equipe que desenvolve coisas novas também cuidará das suas operações, ainda que tenhamos dentro desta equipe que entendam um pouco mais de desenvolvimento do que de operações, ou vice-versa.
Observe a figura abaixo, a qual contém quatro organizações diferentes. As organizações A e B estão bem mais afastadas de um trabalho em DevOps de verdade do que o C e D [6]. A mesma lógica se aplica, naturalmente, a equipes trabalhando com MLOps.
Até a próxima!
Referências
[1] DevOps: Where Are We and How Did We Get Here? — VMware Cloud Management
[2] What is DevOps? — Amazon Web Services (AWS)
[3] What is MLOps? — Databricks
[4] O que é MLOps? — Blog Oficial NVIDIA Brasil
[5] MLOps: Continuous delivery and automation pipelines in machine learning | Google Cloud
[6] López-Fernández, D., Diaz, J., Garcia-Martin, J., Pérez, J., & Gonzalez-Prieto, A. (2021). DevOps Team Structures: Characterization and Implications. IEEE Transactions on Software Engineering.
