Uma visão geral sobre MLOps
Em um contexto operacional, onde os modelos de aprendizado de máquina são apresentados como serviços para aplicações com finalidades diversas, etapas de machine learning como seleção de algoritmos, hiperparametrização e definição de modelos de aprendizado de máquina acabam sendo uma parte pequena de um processo completo.
O Cientista de Dados acaba se preocupando não só com códigos de machine learning (ML), mas também com infraestrutura, escalabilidade, disponibilidade e tarefas como integração contínua (CI) e entrega contínua (CD).
Com uma grande e atual demanda por modelos de machine learning, devido a sua capacidade na resolução de problemas complexos do mundo real, surgem diversas ferramentas para automatizar o processo de machine learning e de operacionalização do ML (MLOps).
Ainda assim, o cientista de dados depara-se com uma alta gama de opções, muitas vezes, similares. Nesse cenário, acaba selecionando as ferramentas através de critérios específicos de cada aplicação.
Com isso, a organização acaba enfrentando os seguintes problemas:
- Dificuldade no gerenciamento de projetos de ML;
- Dificuldade com processos e fluxos de dados não estabelecidos;
- Gerenciar dez, cem ou mil modelos distintos com processos distintos.
Surge então a necessidade da definição de um processo único, onde todos os cientistas de dados de um projeto (ou vários projetos) utilizam as mesmas ferramentas e tecnologias.
A seguir, apresentamos um fluxo generalizado de etapas do processo de MLOps.
Aquisição e pré-processamento de dados
A aquisição de dados é um dos processos mais cruciais em um fluxo de MLOps. Muitas vezes, as organizações possuem múltiplas fontes de dados, que podem conter dados estruturados, não-estruturados, em streaming ou não, e com janelas de atualização diferentes.
A complexidade de muitos ecossistemas de dados em corporações pode tornar o trabalho de um cientista de dados muito mais difícil. Também deve-se atentar ao fato de que esse tipo de tarefa, muitas vezes, requer processamento massivo de informações e que, na maioria dos casos, poderiam se beneficiar de recursos como processamento paralelo e distribuído.
Uma alternativa seria criar uma linguagem específica de domínio (DSL) para definir uma sintaxe única para a aquisição e alguns tipos de pré-processamento de dados.
A ferramenta open source Apache Beam é uma das principais alternativas para definir pipelines de processamento paralelo de dados em batch e streaming, através de um modelo unificado que pode ser definido utilizando SDKs para as linguagens Python, Java e Go.
Beam também suporta múltiplos backends para processamento paralelo de dados como: Apache Flink, Apache Spark e Google Cloud Dataflow. Hoje em dia, a ferramenta se mantém como uma das mais utilizadas para esse fim e é inclusive utilizado como backend para aquisição de dados em frameworks MLOps end-to-end como o Tensorflow Extended (TFX).
Seleção de algoritmo, otimização de hiperparâmetros e treinamento de modelos
A otimização de hiperparâmetros é uma tarefa fundamental para o treinamento de modelos de ML. Existem inúmeros métodos para percorrer o espaço de busca e obter os melhores hiperparâmetros para um algoritmo de aprendizado de máquina ou até mesmo combinações (ensemble), alguns paralelizáveis e outros não.
O principal problema do cientista de dados nessa etapa, e durante o treinamento de modelos, é a limitação de hardware em computadores pessoais. Treinamentos de modelos que usam uma quantidade massiva de dados ou dependem do uso de GPUs/TPUs não apresentam condições para serem treinados fora de um ambiente específico.
Uma das soluções para esse problema é o Kubeflow, um projeto que visa facilitar o desenvolvimento de workflows de ML dentro do Kubernetes, para que rodem de maneira escalável. Open source, é oferecido por alguns provedores de serviços na nuvem e também pode rodar on-premisses (em hardware próprio, fora de um serviço gerenciado).
O projeto agrupa uma série de subprojetos em seu ecossistema, que se adequam às especificidades de projetos de ML e que ajudam o cientista de dados a realizar seu fluxo de trabalho distribuído da forma mais abstrata possível.
Um dos projetos é o Katib (secretário, em árabe), um gerenciador de experimentos para a otimização de hiperparâmetros. Cada experimento é definido por um objetivo, um espaço de busca e um algoritmo de busca.
Cada um deles realiza uma série de tentativas (trials) com parâmetros dentro do seu espaço de busca para avaliá-los, se guiando sempre pelo objetivo de obter uma parametrização ótima.
O Katib aplica o processamento distribuído, direcionando cada trial para um worker, ou seja, várias trials podem ser realizadas simultaneamente dentro do Kubernetes, acelerando o processo de otimização.
Outro subprojeto valioso do Kubeflow é o Kubeflow Pipelines (KFP). Ele define uma DSL para a construção de um DAG (Grafo acíclico direcionado) distribuído no Kubernetes, possibilitando a construção e parametrização de contêineres, volumes e bancos de dados, além de possibilitar o agendamento de jobs paralelos e sequenciais.
O workflow criado pode salvar metadados de artefatos gerados pelo DAG, através de outra funcionalidade da plataforma chamada ML Metadata (MLMD), que tipifica os artefatos e os mantém categorizados e disponíveis para download na interface web do Kubeflow.
Uma alternativa famosa ao KFP é o Apache Airflow. Essa ferramenta permite o agendamento de tarefas em batch, utilizando a abstração de DAG’s. Definir um DAG no Kubeflow ou no Airflow tem quase a mesma complexidade.
No entanto, o segundo não oferece suporte nativo a ferramentas específicas de ML como o Katib, já que o Airflow possui propósito geral e pode ser utilizado em quaisquer tarefas em batch que podem ser descritas como DAG’s.
CI/CD, serving e monitoramento
Enquanto no software tradicional desenvolve-se fluxos de integração contínua que rodam testes convencionais de software no código, em MLOps existem diferentes técnicas a serem aplicadas.
Testes precisam ser realizados, não só em relação aos algoritmos utilizados, mas também nos dados e modelos produzidos. Uma prática comum é realizar esse processo de teste e validação dos dados e modelos dentro do workflow de MLOps, validando os dados entre o pré-processamento e o treinamento e validando o modelo após o treinamento.
Quanto aos dados, é interessante realizar uma análise estatística e de consistência, construindo heurísticas de testes para detectar futuros problemas no treinamento de modelos e procurando possíveis vieses, feedback loops ou até mesmo anomalias nas distribuições.
Os testes de integração também deverão comparar o modelo em produção com o recém-produzido, avaliando se vale a pena realizar a troca. Os fatores comumente analisados são as medidas de avaliação e métricas de consumo de hardware.
Geralmente os modelos são consumidos através de API’s REST ou até mesmo por RPCs (Remote Procedure Call). O Google criou uma implementação do protocolo RPC que funciona em cima do HTTP/2, uma revisão melhorada do HTTP original, chamada gRPC que vem sendo muito utilizada hoje em dia pela sua superioridade em relação a outras tecnologias disponíveis.
Um engenheiro de software deve analisar suas necessidades em relação ao serving e as opções disponíveis dentre as open source e serviços de nuvem. Para modelos construídos com o backend Tensorflow existe o Tensorflow Serving, que pode disponibilizar serviços HTTP ou gRPC com uma configuração mínima. A maioria dos frameworks end-to-end também possuem opções de serving.
Quanto ao monitoramento, o único padrão é analisar o consumo de hardware nas predições do modelo. Variações na acurácia podem ser detectadas fazendo testes periódicos com dados atuais anotados por um especialista.
Resultados ruins podem ser um indicativo de um descolamento do modelo em relação ao mundo real, podendo ser necessário o treinamento de uma nova versão com dados mais atuais.
Outras formas de monitoramento podem ser usadas em contextos específicos. Em tarefas de classificação, por exemplo, monitorar a distribuição estatística das predições pode ser interessante para detectar mudança no mundo real e, consequentemente, o esgotamento do modelo.
Frameworks end-to-end
Assim como existem softwares e frameworks para etapas específicas, podemos encontrar soluções end-to-end. Essas plataformas possuem ferramentas para a maioria das etapas do workflow de MLOps e podem ser bastante valiosas como forma de padronizar as etapas e abstrair para os cientistas de dados as minúcias operacionais.
O Tensorflow Extended (TFX) possui um sistema de orquestração, onde cada etapa roda em um componente independente. Algumas etapas são amplamente automatizadas, como a ExampleGen que já faz a separação de dados de treinamento e de teste, e salva os artefatos em um formato específico para o Tensorflow. Essas etapas não requerem muita parametrização por parte do usuário e são bastante automatizadas.
Com essas facilidades, o TFX consegue robotizar o fluxo de MLOps, pois as únicas etapas que necessitam de intervenção ativa do usuário são a Transform e a Trainer.
A primeira encapsula o código, definido pelo usuário, para a transformação dos dados a serem utilizados para o treinamento, após uma limpeza prévia realizada pelas etapas ExampleGen, StatisticsGen (que analisa os dados e gera visualizações para análise exploratória) e SchemaGen (que define um esquema automático para os dados, gerando gramáticas e intervalos para auxiliar o processo de treinamento). Já na etapa Trainer, se define o algoritmo de treinamento que será utilizado.
O TFX foi desenvolvido especificamente para o Tensorflow, exigindo que suas etapas rodem nesse backend específico, porém frameworks como o Keras são permitidos e amplamente utilizados para a definição do componente de treinamento. Após o processo de treinamento, as etapas Evaluator e Pusher são executadas, realizando a análise e integração do modelo no ambiente de produção. O serving é feito através do Tensorflow Serving.
Outro framework end-to-end open source é o Apache Marvin-AI, inicialmente desenvolvido como um projeto interno da B2W Digital e posteriormente incubado pela Apache Software Foundation. O Marvin define um padrão de projeto chamado DASFE (Data Acquisition, Selection, Feedback and Evaluation) onde são definidas algumas etapas independentes.
As primeiras etapas são executadas em batch e geram cada uma um artefato. A etapa Acquisitor and Cleaner faz a aquisição e limpeza inicial dos dados e produz o artefato initial_dataset. A etapa seguinte, Training Preparator, carrega o artefato anterior, faz o pré-processamento de separação dos dados em conjunto de treinamento e teste, e armazena o artefato dataset.
A etapa Trainer faz o treinamento do modelo usando como entrada o artefato anterior, produzindo o artefato model. A última etapa em batch é a Metrics Evaluator que faz a análise de métricas do modelo e salva o artefato metrics.
Após as etapas em batch é possível definir um predictor, responsável por receber a entrada do usuário e responder com uma predição. O predictor é considerado uma etapa online.
Depois da definição das etapas online e em batch, ao comando do usuário, o Marvin pode subir um serviço gRPC para cada etapa e um executor que se conecta a esses serviços e executa uma interface com um endpoint para um deles.
Isso possibilita o controle remoto das etapas de maneira fácil, gerenciando a execução do código, reload de artefatos e healthcheck através dos endpoints. Todas essas execuções ocorrem de maneira assíncrona.
O Apache Marvin-AI possui outras diversas funções e lançará em breve um release que, dentre outras funcionalidades, permitirá o desenvolvimento remoto através do docker e incluirá uma biblioteca de benchmarks. Em um futuro próximo a comunidade estará debatendo e possivelmente implementando integrações do Marvin com o Kubeflow e o TFX, permitindo o uso dessas ferramentas robustas de uma maneira simplificada e padronizada.
O artigo apresenta uma introdução geral e apresentação do conceito de MLOps e algumas ferramentas para sua implementação, vale destacar que não existe framework ou SDK perfeito todos os casos de uso e ambientes. Ao se definir um fluxo de MLOps, deve-se fazer em conjunto com todas as partes envolvidas (cientistas de dados, time de operação, etc.) para que as necessidades de cada uma delas sejam consideradas.
Se você busca uma oportunidade de desenvolvimento, trabalhando com inovação em um negócio de alto impacto, acesse o portal B2W Carreiras! Nele, você consegue acessar todas as vagas disponíveis. Venha fazer parte do nosso time!
