Curso
MLOps, ou Machine Learning Operations, é uma parte essencial do fluxo de trabalho de machine learning e vem se consolidando como uma área própria. Ele combina machine learning com boas práticas de engenharia de software para garantir que os modelos sigam do experimento à produção, além de reduzir a dívida técnica nos times de dados.
Para ter sucesso com machine learning em escala, é fundamental considerar o nível de maturidade em MLOps da sua organização. Muitas vezes há barreiras para colocar modelos em produção, como infraestrutura, cultura organizacional ou a incapacidade de retreinar o modelo quando ocorre drift. Isso pode gerar muito menos valor do que o esperado (ou pior, potencialmente prejudicar stakeholders que interagem com seus modelos). Como resultado, pode surgir desconfiança na capacidade do time de dados de gerar valor com machine learning. Para extrair todo o potencial de machine learning e IA, é preciso uma abordagem bem estruturada de MLOps.
O MLOps também permite que cientistas de dados foquem no que realmente importa: coletar e limpar dados, desenvolver modelos e aplicar as técnicas certas. Isso porque o MLOps aumenta significativamente a automação em todas as etapas do ciclo de vida de machine learning.
Este artigo parte do princípio de que você já tem noções de MLOps e entende sua importância; para saber mais, confira nossos artigos Getting Started with MLOps e MLOps Best Practices.
Por que falar em níveis de maturidade?
MLOps não é só adotar ferramentas ou mudar o modo de trabalhar. A implementação requer uma visão holística de uso de ferramentas e tecnologias para quebrar silos entre times técnicos e aumentar a automação. Isso pode significar reestruturar a organização ou mover pessoas, mas cada empresa terá uma solução diferente e única.
Encarar o MLOps sob a lente da maturidade — isto é, medir o quão avançada sua empresa está no processo de implementação — ajuda a entender onde a organização está, o que pode fazer para evoluir e que benefícios esse avanço trará. Também significa que a maturidade em MLOps pode crescer junto com a organização. Empresas pequenas, com poucos modelos, não precisam estar no mesmo nível de maturidade que organizações grandes e complexas. No entanto, mesmo negócios menores cuja proposta de valor depende de machine learning precisam de uma prática de MLOps relativamente madura.
Vale destacar que avançar no modelo de maturidade não é linear. Sua organização pode ter elementos de MLOps com alta maturidade e outros com baixa. Na seção abaixo, vamos apresentar o modelo de maturidade em MLOps da Microsoft, que traz uma visão holística de como o MLOps evolui dentro de uma organização.
O modelo de maturidade em MLOps da Microsoft
O modelo de maturidade em MLOps da Microsoft define três dimensões amplas para avaliar a maturidade em MLOps:
- Pessoas: Os diferentes papéis dentro do time de dados e como interagem entre si
- Ciclo de vida de ML: Como o ciclo de vida de machine learning é gerenciado, da coleta de dados à criação e liberação do modelo.
- Aplicação: Como os modelos são testados, implementados, colocados em produção e retreinados.
Além disso, o modelo define cinco estágios de maturidade para a prática de MLOps, da seguinte forma:
- Sem MLOps: Sistemas fragmentados e de caixa-preta, com times de dados em silos e treinamento, deploy e testes manuais.
- DevOps sem MLOps: O time de dados treina os modelos enquanto outro time faz o deploy. O feedback sobre desempenho é opaco e a reprodutibilidade é limitada.
- Treinamento automatizado: Os modelos são reprodutíveis e os releases são menos manuais. O treinamento é automático e pipelines são amplamente usados.
- Deploy automatizado: Os deploys são automatizados e rastreáveis até os dados de origem. É possível fazer testes A/B após o deploy e os testes são automatizados.
- MLOps completo: O sistema é totalmente automatizado, da ingestão de dados ao deploy e testes do modelo, com monitoramento e analytics centralizados sobre o desempenho. Esses sistemas costumam ser feitos sob medida.
A seguir, cobrimos cada nível de maturidade, com uma tabela-resumo dos pontos-chave.
Sem MLOps
Neste estágio, há pouquíssima automação e o time de dados está isolado do restante da organização e até internamente. A adoção de ferramentas é baixa e algumas funções, como engenharia de dados, podem nem existir ou ficam a cargo de cientistas de dados. Colocar um único modelo em produção é difícil e demorado, e retreinar modelos exige refazer toda a análise e os jobs de treinamento. Não há acompanhamento do modelo após o deploy, então avaliar seus impactos pode ser inviável.
|
Pessoas |
Cientistas de dados |
Sem comunicação com o time ampliado, trabalhando de forma independente. |
|
Engenheiros de dados |
Podem não existir. |
|
|
Engenheiros de software |
Recebem modelos dos cientistas de dados e estão em silos em relação ao time de dados. |
|
|
Ciclo de vida de ML |
Preparação de dados |
Embora possam existir bancos de dados, a coleta para treino de modelos é feita manualmente. |
|
Treinamento do modelo |
Os experimentos não são rastreados e não há pipelines de dados e de machine learning estabelecidos. |
|
|
Deploy do modelo |
Os modelos geralmente são entregues manualmente com entradas e saídas. Não há controle de versão e o script de scoring é criado manualmente; o deploy costuma ser feito pelos cientistas de dados. |
|
|
Aplicação |
Integração |
Testes e releases totalmente manuais sempre que um modelo fica pronto para deploy, com forte dependência dos cientistas de dados. |
DevOps sem MLOps
Com a adoção de boas práticas de DevOps, o time de dados ainda permanece em silos, embora possa haver engenheiros de dados dedicados. Tecnologias de computação em nuvem podem ser adotadas, mas sem uso de todo o seu potencial. Neste estágio, a coleta a partir de bancos de dados e a preparação para machine learning são automatizadas em pipelines reutilizáveis. Também pode haver testes de integração quando os modelos são colocados em produção. Cientistas de dados acumulam várias funções e participam ativamente dos testes após o deploy.
|
Pessoas |
Cientistas de dados |
Sem comunicação com o time ampliado, trabalhando de forma independente. |
|
Engenheiros de dados |
Sem comunicação com o time ampliado, trabalhando de forma independente. |
|
|
Engenheiros de software |
Recebem modelos dos cientistas de dados e estão em silos em relação ao time de dados. |
|
|
Ciclo de vida de ML |
Preparação de dados |
Pipelines de dados automatizados estão disponíveis e podem rodar em recursos de nuvem gerenciados. |
|
Treinamento do modelo |
Os experimentos não são reproduzíveis e nem sempre são rastreados de forma previsível. |
|
|
Deploy do modelo |
Os modelos ainda são entregues manualmente com entradas e saídas. Há controle de versão, mas o script de scoring continua manual; o deploy costuma ser feito por cientistas de dados ou engenheiros. |
|
|
Aplicação |
Integração |
Releases são automatizados e existem testes básicos de integração, mas ainda dependem muito da expertise dos cientistas de dados. |
Treinamento automatizado
Neste estágio, a colaboração dentro do time de dados aumenta bastante. Cientistas de dados passam a trabalhar com engenheiros para transformar o código de treino em scripts repetíveis que usam pipelines de dados automatizados. Os experimentos passam a ser rastreados e o controle de versão se torna muito mais disseminado. O deploy é mais automatizado, embora os arquivos de modelo ainda sejam repassados para os engenheiros de software.
|
Pessoas |
Cientistas de dados |
Cientistas de dados trabalham com engenheiros de dados para transformar código de experimento em scripts repetíveis. |
|
Engenheiros de dados |
||
|
Engenheiros de software |
Recebem modelos dos cientistas de dados e estão em silos em relação ao time de dados. |
|
|
Ciclo de vida de ML |
Preparação de dados |
Pipelines de dados automatizados que rodam em recursos de nuvem gerenciados. |
|
Treinamento do modelo |
Os experimentos são rastreados e o código de treino e os modelos têm controle de versão. |
|
|
Deploy do modelo |
Os modelos ainda são implantados manualmente; no entanto, o script de scoring tem controle de versão e o release agora é gerenciado por times de engenharia de software. |
|
|
Aplicação |
Integração |
Releases são automatizados e existem testes básicos de integração, mas ainda dependem bastante da expertise dos cientistas de dados. |
Deploy automatizado de modelos
Engenheiros de software agora colaboram muito mais de perto com engenheiros de dados para colocar em produção os modelos e também seus pipelines de treinamento e de coleta de dados. Os experimentos são totalmente rastreados e há testes automatizados de unidade e de integração para cada release de modelo e para a própria aplicação. Pode haver CI/CD em algumas áreas.
|
Pessoas |
Cientistas de dados |
Cientistas de dados trabalham com engenheiros de dados para transformar código de experimento em scripts repetíveis. |
|
Engenheiros de dados |
||
|
Engenheiros de software |
Trabalham com engenheiros de dados para automatizar a integração de modelos nas aplicações. |
|
|
Ciclo de vida de ML |
Preparação de dados |
Pipelines de dados automatizados que rodam em recursos de nuvem gerenciados. |
|
Treinamento do modelo |
Os experimentos são rastreados e o código de treino e os modelos têm controle de versão. |
|
|
Deploy do modelo |
Os modelos passam a ser implantados automaticamente; o script de scoring tem controle de versão e o release é gerenciado por um pipeline de entrega contínua (CI/CD). |
|
|
Aplicação |
Integração |
A integração no código da aplicação depende menos dos cientistas de dados, e há testes de unidade e de integração para cada release de modelo. |
MLOps completo com retreinamento automatizado
No estágio final de maturidade, engenheiros de dados, cientistas de dados e engenheiros de software trabalham lado a lado para garantir o máximo de automação no desenvolvimento e no deploy. Além disso, experimentos, treinamento e retreinamento de modelos são automatizados com base em métricas de produção; os modelos são liberados automaticamente e gerenciados por um pipeline de CI/CD, e os modelos são testados no código da aplicação.
|
Pessoas |
Cientistas de dados |
Cientistas de dados trabalham com engenheiros de dados para converter experimentos em scripts repetíveis e com engenheiros de software para automatizar processos. Engenheiros de dados e de software trabalham juntos para automatizar a integração de modelos na aplicação e coletar métricas de desempenho pós-deploy. |
|
Engenheiros de dados |
||
|
Engenheiros de software |
||
|
Ciclo de vida de ML |
Preparação de dados |
Pipelines de dados automatizados que rodam em recursos de nuvem gerenciados. |
|
Treinamento do modelo |
Os experimentos são rastreados e o código de treino e os modelos têm controle de versão; os modelos são retreinados automaticamente após o deploy com base em métricas de desempenho. |
|
|
Deploy do modelo |
Os modelos passam a ser implantados automaticamente; o script de scoring tem controle de versão e o release é gerenciado por um pipeline de entrega contínua (CI/CD). |
|
|
Aplicação |
Integração |
A integração no código da aplicação depende menos dos cientistas de dados, e há testes de unidade e de integração para cada release de modelo. |
Diferenças entre modelos populares de MLOps
Uma diferença importante entre este modelo de maturidade em MLOps e o da Google é a implementação de conceitos de CI/CD. O Google sugere que eles aparecem tipicamente no nível final de maturidade, enquanto a Microsoft indica que o retreinamento é a última etapa.
Na prática, o retreinamento é um dos principais motivadores para adotar MLOps e pode ser integrado antes do estágio final. Porém, há pré-requisitos para retreinamento de modelos, como forte automação e infraestrutura, além de pipelines de dados e de treinamento de alta qualidade. Os conceitos de CI/CD tendem a evoluir continuamente até os estágios finais de maturidade em MLOps.
Organizações altamente maduras, como Google e Microsoft, normalmente contam com software sob medida que roda em suas soluções próprias de computação em nuvem e utiliza ferramentas específicas ao máximo. Engenheiros de software costumam dizer que a tecnologia nessas empresas “simplesmente funciona”, com deploys sem atrito e acesso eficiente aos dados. Isso é necessário porque elas mantêm centenas de modelos em produção para uma ampla gama de produtos.
Como evoluir a maturidade em MLOps
MLOps continua sendo uma das áreas mais críticas da ciência de dados, já que muitas organizações ainda têm dificuldade de levar modelos para produção. Modelos de maturidade em MLOps oferecem um excelente framework para entender onde os times de dados estão hoje em suas habilidades de machine learning e como podem evoluir daqui para frente.
Para saber mais sobre MLOps, confira estes recursos:
- [DataFramed Podcast] Operationalizing Machine Learning with MLOps
- [Webinar] A Practical Guide to MLOps


