
MLOps: Apenas DevOps para aprendizado de máquina?
O artigo a seguir tenta resumir o que é exatamente ML Ops e fornece algumas diretrizes para quem está tentando se aprofundar nele (ou avaliar se precisa se aprofundar nele). Deixe-me começar dizendo que o MLOps é apenas o novo hype em IA. Isso começou como um conjunto de melhores práticas no campo, que, dada a enorme demanda e as oportunidades, agora estão se transformando em uma nova disciplina. Se você precisar resumir isso para alguém que não está muito familiarizado com ML, você pode dizer que MLOps é apenas ML + DevOps, mas é muito mais do que isso e tentarei explicar o porquê a seguir. Por que estou falando sobre isso? Provavelmente é bom dar um pouco de informação sobre mim. Eu trabalho ajudando várias empresas a colocar o aprendizado de máquina em produção. Meu trabalho geralmente envolve ajudá-los a definir a definição do problema, reunir e rotular os dados, projetar e treinar os modelos, implantá-los na produção e posterior manutenção. Uma das coisas boas do meu trabalho é que eu trabalho com empresas de todos os tamanhos, desde empresas da Fortune 50 até startups e em uma ampla variedade de setores (saúde, varejo, indústria pesada etc.) nos diferentes campos de aprendizado de máquina: visão computacional, processamento de linguagem natural e análise preditiva. Isso me permitiu aprender sobre seus processos e melhores práticas, usando um amplo espectro de ferramentas durante todo esse processo. Enfrentando esses diversos problemas, eu tenho:
- Criei minhas próprias ferramentas para diferentes partes do processo e até entrei em um programa de 500 startups para isso (www.oktopus.ai)
- Ajudou outras empresas a projetar e implementar suas ferramentas para isso
- Avaliou e usou muitas das diferentes ferramentas existentes, adicionando-as do zero a novos pipelines, bem como melhorando os existentes
O que é exatamente o MLOps? O MLOps é o processo de implantação de um modelo de aprendizado de máquina na produção. Algumas pessoas incluem a fase de design nela. Pessoalmente, gosto de ver isso como o gerenciamento do ciclo de vida do ML. É um conjunto de melhores práticas que visa reduzir o atrito, os pontos de falha e o trabalho manual envolvidos na implantação de um primeiro modelo na produção e, em seguida, em todos os modelos subsequentes retreinados. Um ciclo de vida de ML geralmente inclui as seguintes etapas:
- Coleta de dados, limpeza e rotulagem
- Exploração, pré-processamento e aumento de dados
- Engenharia de recursos (inclui seleção de recursos, classificação e poda)
- Modelagem e acompanhamento de experimentos
- Design do modelo
- Treinamento
- Avaliação
- Ajuste fino
- Implantação
- Servindo
- Monitoramento
- Coleta de dados de produção
- Retreinamento (a iteração começa aqui)
Idealmente, essas etapas são o mais automatizadas possível, reduzindo a possibilidade de erro humano e minimizando o trabalho manual (como rastrear experimentos em uma planilha...). Essas etapas também devem levar em conta os requisitos regulatórios (como privacidade de dados).

O diagrama mais simples que representa o que é MLOps é o seguinte:

O que é tão diferente do DevOps? As principais diferenças derivam do papel fundamental que os dados desempenham nos algoritmos. Diferentemente do software tradicional, em que você programava regras com base nas observações do desenvolvedor a partir dos dados, agora o algoritmo de inferência é definido pelo uso de dados do algoritmo de treinamento, e quanto mais dados você tiver, melhor. As consequências disso incluem:
- Sempre que quiser melhorar um algoritmo, você provavelmente desejará incluir novos dados, se disponíveis.
- Os dados precisam ser rotulados e validados, caso contrário, você pode prejudicar o desempenho do seu algoritmo
- Os dados reais mudam, então você precisa atualizar seu algoritmo de vez em quando
- Os dados estão sujeitos a muitas regulamentações e medidas adicionais de segurança devem ser tomadas
- Os dados exigem grandes armazenamentos e a transferência pode ser cara. Nunca subestime isso.
Além disso, uma das principais vantagens do aprendizado de máquina é que ele pode aprender relações complexas com recursos não triviais e usar isso para prever o comportamento variável de um alvo ou fazer algum tipo de classificação. A desvantagem é que isso geralmente exige muita computação, já que “aprender relacionamentos complexos” é basicamente fazer muitas operações matriciais. As GPUs, que tendem a ser muito boas e rápidas na execução de operações matriciais, também tendem a ser significativamente mais caras do que as CPUs. Isso nos obriga a ser extremamente cuidadosos com os recursos de hardware, tanto para treinamento quanto para inferência. As boas práticas tradicionais de software em muitas empresas estão fora de questão devido às fortes limitações dos recursos disponíveis. Isso pode incluir escalabilidade automática e implantações sem tempo de inatividade (já que esses modelos podem levar até alguns minutos para serem carregados na memória e uma única instância pode não conseguir carregar dois modelos ao mesmo tempo porque simplesmente não tem memória suficiente). Qual é o valor agregado pelos MLOps? Se feito corretamente, ele pode permitir que sua organização melhore o desempenho do seu modelo a um custo muito baixo. Você pode melhorar significativamente sua velocidade de desenvolvimento se:
- você implementa com sucesso um pipeline que permite usar dados de produção para treinar novamente seu modelo
- reproduzir experimentos é fácil de fazer. Isso envolve:
- ativando o hardware necessário (já que você provavelmente desativou sua instância de treinamento para economizar alguns dólares)
- obtendo a versão exata do conjunto de dados que você treinou originalmente
- você sabe exatamente quais parâmetros você usou no treinamento original
- experimentar não é uma tarefa demorada porque você conseguiu automatizar a pesquisa de hiperparâmetros, reverter para experimentos anteriores, etc.
Além disso, você pode evitar problemas como o desvio de dados: os dados mudam lentamente na produção a partir do que seu modelo foi treinado. Quais habilidades sua equipe precisa para fazer MLOPs? Não é muito estranho encontrar uma empresa que tenha uma equipe de ciência de dados ou aprendizado de máquina e uma equipe de DevOps. Então, como você vai de lá para o MLOps? O MLOps exige a apropriação de todo o pipeline de dados, desde o primeiro conjunto de dados usado para treinar o primeiro modelo até os dados de produção para os quais o modelo está fazendo as previsões. Há muitos pequenos detalhes que fazem toda a diferença envolvidos na modelagem e no treinamento, então é melhor que quem esteja encarregado dos MLOps em sua organização esteja bem informado sobre isso. Além disso, lidar com grandes volumes de dados e dimensionar corretamente o hardware não é uma tarefa fácil, então você precisa de alguém que realmente conheça infraestrutura e possa aproveitar serviços de computação em nuvem como Databricks, SageMaker etc. Caso contrário, você pode acabar pagando grandes contas de nuvem causadas por transferências ou armazenamento de dados desnecessários, instâncias ociosas etc. O Docker também não funciona muito bem com GPUs (por exemplo, as GPUs não são suportadas pelo docker-compose no momento).) e você precisa de alguém que seja capaz de resolver problemas de compatibilidade de bibliotecas de baixo nível (cuDNN, CUDA, etc.). Ter a pessoa ou a equipe certa no comando dos MLOPs pode ter um grande impacto nas métricas de negócios. Ele permite que você se concentre no que realmente importa ao tentar melhorar o desempenho. Nesta linha, eu recomendo isso Palestra de Andrew Ng, na qual ele basicamente recomenda dar uma olhada na melhoria dos dados em vez da arquitetura ou dos parâmetros de um modelo ao tentar melhorar o desempenho. Vamos começar a trabalhar A boa notícia sobre os MLOps é que existem muitas ferramentas surgindo neste momento que cuidam de tarefas realmente específicas, bem como de todo o pipeline. A desvantagem é que o mercado ainda não está maduro e não há líderes de mercado claros para a maioria dos problemas. Lembre-se de que isso torna difícil fazer uma recomendação, pois eu entendo que não há receita ou solução perfeita. Isso também deve ser revisitado com frequência, dada a alta velocidade de mudança dessas (e novas) ferramentas. Eu recomendo, para casos de uso específicos, ferramentas como dvc para controle de versão do conjunto de dados, Fluxo de ar para orquestração do fluxo de trabalho, Kubernetes e Kubeflow para orquestração de implantação, Fluxo de ml para rastreamento de experimentos (embora seja destinado a mais do que apenas isso), Pesos e preconceitos também para rastreamento de experimentos e Faísca (e Pyspark) para processamento de dados. Neste vincular você pode encontrar uma lista mais exaustiva das diferentes ferramentas disponíveis.
