Aprendizado Automático de Modelos

Lucas Lascasas
9 min readNov 23, 2023

--

Autores

Introdução

Nas últimas décadas, houve um avanço significativo da área de Aprendizado de Máquina (Machine Learning, ML), trazendo cada vez mais modelos sofisticados e poderosos. Buscando prover uma suíte completa de ferramentas de ML na nuvem, a AWS criou o Sagemaker como um ambiente completo de ML para modelos personalizados. Entretanto, uma dor comum de clientes é que o modelo tenha um foco maior no “Aprendizado” do seu nome, sendo capaz de incorporar novos dados continuamente e gerar versões mais avançadas do sistema. Existem diversas formas de se atingir esse aspecto dentro de um ambiente, utilizando-se de técnicas de MLOps (Machine Learning Operations), mas essas técnicas tendem a ser custosas em esforço dos profissionais e tempo de desenvolvimento. Nesse artigo, vamos abordar uma estratégia mais simples e rápida de implantar para trazer esse benefício em uma curta janela de tempo sem a necessidade da criação de toda uma esteira de MLOps. Vale destacar que para ambientes produtivos em larga escala, ainda é altamente recomendado o emprego correto de MLOps no sistema, a versão apresentada nesse artigo é mais apropriada para ambientes piloto ou em beta test.

Desafio

O objetivo principal desse artigo e a motivação do desenvolvimento dessa arquitetura é a criação de um sistema capaz de treinar sobre dados novos automaticamente. Além disso, o sistema deve ser capaz de armazenar informações de assertividade dos modelos treinados para fins comparativos. Finalmente, o endpoint de inferência do modelo deve ser passível de ser facilmente substituído quando uma nova versão supera os níveis de assertividade do modelo em produção. O intuito por trás disso é ter um sistema capaz de aprender com dados novos, mas que um analista possa ter a tomada de decisão quanto a qual modelo utilizar.

Solução

Para solucionar esse desafio de forma simples e ágil, algumas funcionalidades do Sagemaker foram utilizadas em conjunto com demais serviços gerenciados da AWS.

Hiperparameter Optimization (HPO)

O HPO é uma ferramenta do Sagemaker que consiste em um modelo de otimização com base em diferentes algoritmos (Random Search, Grid Search, Baysian, etc) à escolha do cientista de dados. Assim, o HPO instancia diferentes versões de um modelo, variando seus hiperparâmetros (parâmetros de configuração do modelo de ML sendo utilizado), a fim de encontrar o conjunto de valores que maximizem a eficiência do modelo com base em alguma métrica definida pelo cientista de dados. Na solução do desafio, essa ferramenta é utilizada para o treinamento de modelos sobre os dados novos, tendo em mente que os hiperparâmetros utilizados em uma solução não necessariamente são os melhores para conjuntos distintos de dados.

Batch Transform

Existem diversas formas de utilizar um modelo de ML para gerar inferências sobre dados novos, uma delas é o processamento em batch (grupos de dados). O Batch Transform é uma ferramenta do Sagemaker que provê uma máquina para gerar inferências sobre um conjunto de entradas para o modelo de ML. Essa ferramenta é ideal para workloads não sensíveis a tempo, que podem ser processadas uma vez que agrupadas. Na solução proposta aqui, o Batch Transform é utilizado para realização de testes sobre o modelo mais performático do HPO, gerando assim uma métrica comparável com modelos em produção. Vale ressaltar que o HPO realiza testes sobre seus modelos com base nos dados enviados, mas o Batch Transform pode ser utilizado sobre conjuntos específicos de testes para gerar métricas mais compatíveis com modelos em produção.

Model Registry

Durante o processo de treinamento de um modelo, diversas métricas são geradas e ter um sistema capaz de registrar essas métricas para uso posterior é fundamental. O Sagemaker encapsula uma ferramenta chamada Model Registry, capaz de armazenar essas informações automaticamente e ainda ser capaz de generalizá-las para adição de valores customizados. Além da funcionalidade de gestão de métricas dos modelos, o Model Registry é capaz de realizar o versionamento dos mesmos. Dentro da solução proposta, o Model Registry é utilizado para o armazenamento de informações importantes para o deploy dos modelos treinados pelo HPO, sendo uma delas as métricas geradas pelo Batch Transform.

Model Endpoint

Finalmente, após todo o trabalho de treinamento dos modelos, existe a demanda de gerar inferências sobre os dados sob demanda. Para isso, o Sagemaker provê o Model Endpoint como uma ferramenta capaz de instanciar um servidor para gerar as inferências em tempo real na nuvem. Nessa solução, o Model Endpoint é utilizado para criar a máquina responsável pelas inferências ao modelo de ML.

Outros Serviços

Além do Sagemaker, a AWS provê uma suíte completa de serviços para diversos casos de uso. O Simple Storage Service (S3) é o serviço de armazenamento de arquivos da AWS, capaz de armazenar informações do sistema de forma criptografada. Funções Lambda são utilizadas para o processamento ágil de códigos pontuais (aqueles que possam ser executados em menos de 15 minutos e com um consumo de RAM inferior a 10 GB), como a modelagem de dados, processamento de requisições e extração de informações de resultados dos processamentos de ML. O API Gateway provê uma API REST para a conexão do sistema com o mundo externo. A Virtual Private Cloud (VPC) encapsula recursos dentro de uma rede privada na AWS para evitar falhas de segurança e acessos indevidos das aplicações, provendo endpoints de conexão privados e seguros para a nuvem AWS. O Step Functions é um serviço gerenciado para a orquestração dos demais serviços AWS mencionados até aqui. Finalmente, o EventBridge é o serviço responsável pelo disparo de ações dentro do sistema de forma automática com base em regras temporais.

Arquitetura

Toda a arquitetura desenvolvida é entregue por um pipeline de CI/CD utilizando de Infraestructure as Code (IaC) pelo Cloudformation para simplificar a gestão da infraestrutura e até mesmo padronizar processos de atualização da arquitetura proposta.

Pipeline de CI/CD

Arquitetura do Pipeline de CI/CD

O pipeline de CI/CD dessa arquitetura é composto pela suíte de serviços AWS mostrada acima. Um template CloudFormation (ferramenta de IaC da AWS) é utilizado para criar os pipelines de CI/CD (um para cada ambiente de desenvolvimento, homologação e produção), além do bucket de artefatos de deploy e as Roles IAM, que gerem os acessos dos recursos da arquitetura. Esse primeiro template deve ser executado manualmente por um usuário com permissões apropriadas, essa necessidade do processo manual vem de um “loophole” de segurança onde um pipeline com poder de criação de acesso na AWS pode ser usado de forma maliciosa por uma pessoa que não possua tal acesso, mas que tenha permissão de acessar o repositório do projeto. Assim, se a criação de Roles for feita dentro do pipeline de CI/CD, uma pessoa pode criar credenciais para si mesma, garantindo acessos a recursos que ela não deveria ter. Uma vez que o pipeline é provido, o CodeCommit é utilizado como repositório do projeto, onde os códigos e o template IaC SAM (Serverless Application Model) são versionados. A cada push dentro do CodeCommit, o CodePipeline é acionado para coordenar o deploy das alterações. A primeira etapa do pipeline é o acionamento do CodeBuild que recupera o código do repositório e gera os artefatos de deploy. Em seguida o CloudFormation realiza a construção das estruturas no ambiente AWS com os artefatos gerados.

Arquitetura da Solução

Arquitetura do Sistema AWS

A arquitetura proposta nessa solução na AWS se inicia com o EventBridge, que aciona periodicamente (a ser definido pelo cientista de dados) o orquestrador do sistema por meio de uma Função Lambda, feito no Step Functions. O primeiro passo do orquestrador é acionar a Função Lambda responsável por modelar os dados armazenados no S3, devolvendo ao S3 os dados prontos para o treinamento dos modelos. Em seguida, o HPO é acionado para gerar os modelos com base nos dados do S3. O terceiro passo é o acionamento de uma Função Lambda que detecta e extrai os artefatos do modelo mais performático do HPO. Com esses dados, o orquestrador aciona o Sagemaker para salvar o modelo mais performático no S3. O quinto passo é a realização da bateria de testes no modelo utilizando o Batch Transform e os dados salvos no S3. Finalmente, o orquestrador aciona uma Função Lambda que registra todos os dados no Model Registry.

No lado mais “ativo” da arquitetura, o API Gateway provê uma API REST com 3 endpoints processados por Funções Lambda e encapsulados em uma VPC. O primeiro endpoint recupera as informações dos modelos acionando o Model Registry por um endpoint privado da VPC, retornando informações que são fundamentais nas tomadas de decisão relativos ao segundo endpoint. O próximo endpoint é responsável por realizar o deploy do modelo na AWS, atualizando o endpoint de inferência. Finalmente, o terceiro endpoint aciona o modelo para gerar inferências em tempo real. Vale ressaltar que existem também endpoints auxiliares não mostrados no desenho para não poluir a arquitetura, como endpoint de deleção de modelos de inferência, atualização de status, entre outros.

Orquestração

Orquestrador do Treinamento de ML

O orquestrador do sistema, implementado no Step Functions pode ser visualizado na máquina de estados acima, mostrando o fluxo de acionamentos da arquitetura de maneira linear.

Benefícios

A fim de medir a eficiência da solução, foi utilizado um modelo do XGBoost para a classificação de fraudes com base em um limiar de confiança, sendo assim uma solução relativamente simples. Vale destacar que as informações mostradas aqui podem variar de acordo com a complexidade do workload de ML.

A solução proposta possui diversos benefícios, sendo o principal deles a simplicidade da atualização de modelos que seguem um procedimento de aprendizado contínuo. A latência de inferências em tempo real leva um tempo na casa de 200 milissegundos, com exceção do cold start do Lambda (primeira execução a cada período do serviço serverless), que leva 3 segundos. O processo de deploy de um novo endpoint dura em média 5 minutos para um modelo pré-treinado pelo sistema. A arquitetura é serverless-first, significando que todos os recursos cabíveis de processamento serverless são feitos assim e mesmo aqueles que provisionam máquinas realizam o clean-up das mesmas de forma built-in. Os custos do sistema são diretamente proporcionais ao uso do sistema, com exceção do endpoint de inferência que foi planejado 24/7 na arquitetura proposta. O sistema é altamente escalável naturalmente pelos serviços gerenciados da AWS, sem necessidade de provisionamento e gestão de infraestruturas novas. A arquitetura é multi-AZ (disponível em diferentes Availability Zones) e replicada em ambiente de desenvolvimento, homologação e produção. Finalmente, pelo provisionamento IaC da infraestrutura, as atualizações e customizações de serviços é simples de ser feita.

Customizações

Existem possibilidades de customização dessa arquitetura, como:

  • Serverless Endpoint: o Sagemaker possui uma ferramenta de provisionamento de endpoints serverless, não havendo assim a necessidade de um servidor 24/7 para inferências.
  • Inferências em Batch: caso não exista a necessidade de realizar inferências em tempo real, pode-se substituir o endpoint de inferência por um processamento de Batch Transform.
  • Big Data: em cenários de modelagem de dados que necessitem de mais de 10 GB de RAM, essa etapa pode ser substituída pelo AWS Glue, ferramenta mais robusta de ETL e processamento de dados na AWS.
  • Entre outros: por meio do IaC, as possibilidades de customização dessa arquitetura são infinitas dentro das limitações da própria AWS!

Conclusão

Esse artigo apresenta um sistema de aprendizado contínuo para modelos de ML, sendo simples de operar e rápido de implantar. Os benefícios dessa arquitetura mostram que em uma janela de 5 minutos, um novo modelo gerado pode ser analisado e ter o seu deploy feito para estar disponível para uso. Dentro de um teste dessa arquitetura, alcançamos um aumento do F1 Score (métrica que correlaciona a precisão e o recall de um modelo) de 94.92% para 97.84%, representando um ganho percentual de qualidade de 2.92%, reforçando assim a importância de ter um modelo de ML com aprendizado contínuo sobre novos dados para aumentar as suas métricas de qualidade com o tempo.

--

--

Lucas Lascasas

Master in Computer Science | Manager at BRLink/INGRAM | 4x AWS Certified | AI/ML Black Belt