O guia mais detalhado sobre MLOps: Parte 1

Olá Hackernoon! Neste artigo, discutirei detalhadamente o conceito de MLOps. Além disso, farei isso de três maneiras. Primeiro, teoricamente - através do esquema MLOps mais sensato. Depois, conceitualmente, por meio dos artefatos que estão incorporados na abordagem. E, por fim, entendendo o MLOps como um sistema de informação.

Então vamos começar.

O que é MLOps?

Esta questão há muito ocupa as mentes de muitas equipes de desenvolvimento de sistemas de ML. Por tal sistema neste artigo, entenderei um sistema de informação, um ou mais componentes dos quais contêm um modelo treinado que executa alguma parte da lógica geral de negócios.

Como qualquer outro componente do sistema, esta parte da lógica de negócios precisa ser atualizada para atender às mudanças nas expectativas dos negócios e dos clientes. MLOps tem tudo a ver com esta atualização regular.

Definição e explicação de MLOps

Ainda não existe uma definição única e acordada de MLOps. Muitos autores tentaram fornecê-lo, mas foi um desafio encontrar uma descrição clara e sistemática ao mesmo tempo.

Existe um que pode ser considerado assim:

MLOps é uma disciplina de engenharia que visa unificar o desenvolvimento de sistemas de ML (dev) e a implantação de sistemas de ML (ops) para padronizar e agilizar a entrega contínua de modelos de alto desempenho em produção.

Vamos destacar as partes críticas da definição de MLOps:

• Disciplina de engenharia
• Visa unificar os processos de desenvolvimento e implantação de sistemas de ML
• Padroniza e otimiza a entrega contínua de novas versões
• Modelos de alto desempenho

Portanto, MLOps é uma espécie de DevOps para modelos de ML.

História do surgimento do MLOps

É fácil acreditar que tal disciplina de engenharia tenha se originado em uma grande empresa de TI. Portanto, podemos confiar na teoria de que MLOps, como uma abordagem significativa, se originou no Google, onde D. Sculley estava tentando poupar seus nervos e tempo das tarefas mundanas de gerar modelos de ML para extensões. D. Sculley é agora amplamente conhecido como “O Poderoso Chefão do MLOps” – o podcast de mesmo nome é fácil de encontrar online.

D. Sculley passou a considerar o trabalho com modelos do ponto de vista do débito técnico da equipe. Sim, é possível lançar novas versões de modelos rapidamente, mas o custo de suporte do sistema resultante terá um impacto significativo no orçamento da empresa.

Seu trabalho resultou no artigo "Dívida técnica oculta em sistemas de aprendizado de máquina " publicado em 2015 na conferência NeurIPS. A data de publicação deste artigo pode ser considerada o ponto de partida para a existência de MLOps.

Níveis de maturidade MLOps: os modelos mais conhecidos

Como a maioria dos processos de TI, os MLOps possuem níveis de maturidade. Eles ajudam as empresas a entender onde estão agora e como podem passar para o próximo nível (se tal objetivo existir). Além disso, os métodos geralmente aceitos para determinar a maturidade permitem determinar sua posição entre os concorrentes.

Modelo de maturidade GigaOm MLOps

O modelo mais detalhadamente descrito e amplamente compreensível é o da empresa de análise GigaOm . É o mais próximo da Integração do Modelo de Maturidade de Capacidade (CMMI) de todos os modelos. Trata-se de um conjunto de metodologias para melhoria de processos organizacionais, que também é composto por 5 níveis - de 0 a 4.

O modelo da GigaOm descompacta cada nível de maturidade em 5 categorias: estratégia, arquitetura, modelagem, processos e governança.

Guiado por esse modelo nos estágios iniciais de construção de um sistema de ML, você pode pensar no futuro sobre aspectos essenciais e reduzir as chances de fracasso. Passar de um nível de maturidade para outro superior apresenta à equipe novos desafios que ela talvez não percebesse que existiam antes.

Modelo de maturidade do Google MLOps

Vale ressaltar que o Google também possui seu modelo de níveis de maturidade MLOps . Foi um dos primeiros a aparecer. É conciso e consiste em 3 níveis:

• Nível 0: Processo manual
• Nível 1: automação de pipeline de ML
• Nível 2: automação de pipeline de CI/CD

É difícil escapar da ideia de que este modelo lembra um manual de instruções para pintar uma coruja. Primeiro, faça tudo manualmente, monte os pipelines de ML e finalize os MLOps. Dito isto, está bem descrito.

Modelo de maturidade do Azure MLOps

Hoje, muitas grandes empresas que usam ML compilaram seus modelos de maturidade. Azul , que utiliza uma abordagem semelhante para distinguir níveis, está incluído. No entanto, existem mais deles do que os do Google:

• Nível 0: Sem MLOps
• Nível 1: DevOps, mas sem MLOps
• Nível 2: Treinamento Automatizado
• Nível 3: implantação automatizada de modelo
• Nível 4: Operações automatizadas completas de MLOps

Todos os modelos destacados convergem aproximadamente em uma coisa. No nível zero, eles apresentam ausência de quaisquer práticas de BC. No último nível, contam com a automatização dos processos MLOps. Sempre há algo diferente no meio relacionado à automação incremental de processos. O Azure tem essa automação do processo de treinamento e depois da implantação do modelo.

Estrutura Conceitual MLOps

Como você descreve todos os processos associados ao conceito de MLOps? Surpreendentemente, três alemães - os autores do artigo " Operações de aprendizado de máquina (MLOps): visão geral, definição e arquitetura " - até conseguiu encapsulá-los em um diagrama. Eles conduziram um estudo real e descreveram o conceito de MLOps em detalhes.

Pode ser intimidante porque tem muitos elementos interagindo entre si. Porém, muitas das características dos níveis de maturidade mencionados acima podem ser encontradas nele. Pelo menos pipelines automatizados, CI/CD, monitoramento, registro de modelo, orquestração de fluxo de trabalho e componente de serviço.

Vamos discutir este diagrama e falar sobre cada um com mais detalhes.

Processos principais do MLOps

As partes principais do esquema são blocos horizontais, dentro dos quais são descritos os aspectos processuais dos MLOps (são atribuídas as letras A, B, C e D). Cada um deles foi concebido para resolver tarefas específicas no âmbito de garantir o bom funcionamento dos serviços de ML da empresa. Para facilitar a compreensão do esquema, é melhor começar fora de serviço.

Experimentação

Se uma empresa possui serviços de ML, os funcionários trabalham no Jupyter. Em muitas empresas, esta é a ferramenta onde todos os processos de desenvolvimento de ML estão centrados. É aqui que começa a maioria das tarefas que exigem a implementação de práticas de MLOps.

Vamos considerar um exemplo. A empresa A precisa automatizar parte de alguns processos utilizando aprendizado de máquina (suponhamos que exista um departamento e especialistas correspondentes). É improvável que a forma de resolver o problema seja conhecida com antecedência. Portanto, os executores precisam estudar o enunciado do problema e testar possíveis formas de sua realização.

Para fazer isso, um engenheiro/desenvolvedor de ML escreve código para várias implementações de tarefas e avalia os resultados obtidos pelas métricas alvo. Tudo isso quase sempre é feito no Jupyter Lab. Dessa forma, é necessário capturar manualmente muitas informações importantes e depois comparar as implementações entre si.

Essa atividade é chamada de experimentação. Significa obter um modelo de ML funcional, que pode ser usado posteriormente para resolver problemas relevantes.

O bloco C mostrado no diagrama descreve o processo de condução de experimentos de ML.

Analisando os dados disponíveis no escopo da tarefa

Muitas decisões no desenvolvimento de ML são tomadas com base na análise dos dados disponíveis na empresa. Não é possível treinar um modelo com métricas de qualidade alvo em dados de baixa qualidade ou dados que não existem.

Portanto, é importante descobrir quais dados obtivemos e o que podemos fazer com eles. Para fazer isso, por exemplo, podemos:

• Conduza um estudo ADHoc usando Jupyter ou Superset
• EDA Padrão (Análise Exploratória de Dados)

Uma melhor compreensão dos dados só pode ser obtida quando aliada à análise semântica e estrutural.

Porém, apenas algumas vezes a preparação dos dados está sob o controle da equipe do projeto. Neste caso, estão garantidas dificuldades adicionais. Às vezes, nesta fase, fica claro que não faz sentido continuar a desenvolver o projeto porque os dados não são adequados para o trabalho.

Formação de um conjunto de dados de qualidade

Quando há confiança nos dados disponíveis, é necessário pensar nas regras de pré-processamento. Mesmo que haja um grande conjunto de dados adequados, não há garantia de que não contenha omissões, valores distorcidos, etc. O termo "qualidade dos dados de entrada" e a conhecida frase "Entra lixo - sai lixo" devem ser mencionados aqui.

Não importa quão bom seja um modelo usado, ele produzirá resultados ruins em dados de baixa qualidade. Na prática, muitos recursos do projeto são gastos na criação de um conjunto de dados de alta qualidade.

Treinamento e validação de modelo de ML

Após a etapa anterior, faz sentido considerar as métricas do modelo treinado na condução dos experimentos. No âmbito do bloco em consideração, a experiência consiste em ligar o treino e a validação do modelo ML.

O experimento consiste no esquema clássico de treinamento da versão desejada do modelo com o conjunto selecionado de hiperparâmetros no conjunto de dados preparado. Para isso, o próprio conjunto de dados é dividido em amostras de treinamento, teste e validação:

• Os dois primeiros são usados para selecionar o conjunto ideal de hiperparâmetros
• A terceira é a verificação e confirmação final de que o modelo treinado no conjunto selecionado de hiperparâmetros se comporta adequadamente em dados desconhecidos que não participaram do processo de seleção e treinamento de hiperparâmetros

Você pode ler mais sobre amostras de validação em Este artigo .

Salvando código e hiperparâmetros em um repositório

Se as métricas de aprendizagem do modelo forem boas, o código do modelo e os parâmetros selecionados serão armazenados em um repositório corporativo.

O objetivo fundamental do processo de experimentação é a engenharia de modelos, o que implica a seleção da melhor seleção de algoritmo e a seleção do melhor ajuste de hiperparâmetros.

A dificuldade de conduzir experimentos é que o desenvolvedor precisa verificar muitas combinações de parâmetros de operação do modelo ML. E não estamos falando de diferentes variantes do aparato matemático utilizado.

Em geral, dá trabalho. E o que fazer se as métricas desejadas não forem alcançadas no âmbito das combinações de parâmetros do modelo?

Engenharia de recursos

Se as métricas desejadas de operação do modelo de ML não puderem ser alcançadas, você pode tentar estender a descrição dos recursos dos objetos do conjunto de dados com novos recursos. Com eles, o contexto do modelo será ampliado e, portanto, as métricas desejadas poderão melhorar.

Novos recursos podem incluir:

• Para dados tabulares: transformações arbitrárias de atributos de objetos já existentes - por exemplo, X^2, SQRT(X), Log(x), X1*X2, etc.
• Com base na área temática: índice de massa corporal, número de pagamentos de empréstimos vencidos durante um ano, etc.

Vejamos a parte do diagrama relacionada à Engenharia de Recursos.

O Bloco B1 visa formar um conjunto de requisitos para transformar os dados de origem disponíveis e obter recursos deles. O cálculo dos componentes em si é realizado a partir desses dados pré-processados e limpos de acordo com as “fórmulas” inseridas pelo desenvolvedor do ML.

É fundamental dizer que trabalhar com funcionalidades é iterativo. Aplicando um conjunto de características, uma nova ideia pode vir à mente, concretizada em outro conjunto de características, e assim por diante, ad infinitum. Isso é mostrado explicitamente no diagrama como um Ciclo de Feedback.

O bloco B2 descreve o processo imediato de adição de novos recursos aos dados.

Conectar-se e recuperar fontes de dados são operações técnicas que podem ser bastante complicadas. Para simplificar a explicação, assumirei que existem diversas fontes às quais a equipe tem acesso e ferramentas para descarregar dados dessas fontes (pelo menos scripts Python).

Limpeza e transformação de dados. Esta etapa quase equivale à etapa semelhante do bloco de experimentos (C) - preparação dos dados. Já no conjunto dos primeiros experimentos, há um entendimento de quais dados e em que formato são necessários para treinar modelos de ML. Resta gerar e testar novas funcionalidades corretamente, mas o processo de preparação de dados para esse fim deve ser automatizado tanto quanto possível.

Cálculo de novos recursos. Conforme observado acima, essas ações podem consistir na simples transformação de alguns elementos de uma tupla de dados. Outra opção é executar um grande pipeline de processamento separado para adicionar um único recurso à mesma tupla de dados. De qualquer forma, existe um conjunto de ações que são executadas sequencialmente.

Adicionando o resultado. O resultado das ações anteriores é adicionado ao conjunto de dados. Na maioria das vezes, os recursos são adicionados ao conjunto de dados em lote para reduzir a carga do banco de dados. Mas às vezes é necessário fazer isso em tempo real (streaming) para acelerar a execução das tarefas de negócios.

É fundamental utilizar os recursos obtidos da forma mais eficiente possível: salvá-los e reutilizá-los em tarefas de outros desenvolvedores de ML da empresa. O esquema possui um Feature Store para essa finalidade. Deve estar disponível dentro da empresa, administrado separadamente e com controle de versão de todos os recursos incluídos nele. O Feature Store tem 2 partes: online (para scripts de streaming) e offline (para scripts em lote).

Fluxo de trabalho automatizado de ML

No início do artigo, indiquei que por sistema de ML quero dizer um sistema de informação, um ou mais componentes dos quais contêm um modelo treinado que executa alguma parte da lógica geral de negócios. Quanto melhor for o modelo de ML obtido com o desenvolvimento, maior será o efeito do seu funcionamento. Um modelo treinado processa o fluxo de solicitações recebidas e fornece algumas previsões em resposta, automatizando assim algumas partes da análise ou do processo de tomada de decisão.

O processo de usar um modelo para gerar previsões é chamado de inferência, e o treinamento de um modelo é chamado de treinamento. Uma explicação clara da diferença entre os dois pode ser emprestada do Gartner. Aqui, vou praticar em gatos.

Para a operação eficiente de um sistema de ML de produção, é vital ficar de olho nas métricas de inferência do modelo. Assim que começarem a cair, o modelo deverá ser retreinado ou substituído por um novo. Na maioria das vezes, isso acontece devido a alterações nos dados de entrada (desvio de dados). Por exemplo, há um problema de negócios em que o modelo consegue reconhecer cupcakes em fotos e recebe isso como entrada. Os cães Chihuahua do exemplo são para equilíbrio:

O modelo no conjunto de dados original não sabe nada sobre os cães Chihuahua, por isso faz previsões incorretas. Portanto, é necessário alterar o conjunto de dados e realizar novos experimentos. O novo modelo deverá entrar em produção o mais rápido possível. Ninguém proíbe os usuários de fazer upload de imagens de cachorros Chihuahua, mas eles obterão resultados errados.

Agora, para mais exemplos do mundo real. Vamos considerar o desenvolvimento de um sistema de recomendação para um mercado.

Com base no histórico de compras do usuário, compras de usuários semelhantes e outros parâmetros, um modelo ou conjunto de modelos gera um bloco com recomendações. Ele contém produtos cuja receita de compra é contada e rastreada regularmente.

Algo acontece e as necessidades dos clientes mudam. Consequentemente, as suas recomendações já não são relevantes. A demanda pelos produtos recomendados cai. Tudo isso leva a uma diminuição da receita.

Os próximos gestores gritam e exigem que tudo seja restaurado até amanhã, o que não leva a nada. Por que? Não há dados suficientes sobre as preferências dos novos clientes, então você não pode nem criar um novo modelo. Você pode pegar alguns algoritmos básicos de geração de recomendações (filtragem colaborativa baseada em itens) e adicioná-los à produção. Dessa forma, as recomendações funcionarão de alguma forma, mas esta é apenas uma solução temporária.

Idealmente, o processo deve ser configurado de tal forma que o processo de reciclagem ou experimentação de diferentes modelos seja iniciado com base em métricas, sem que os gestores lhes digam para fazê-lo. E o melhor acabaria por substituir o atual em produção. No diagrama, este é o Automated ML Workflow Pipeline (bloco D), que é iniciado por gatilhos em alguma ferramenta de orquestração.

Esta é a seção mais carregada do esquema. Vários componentes importantes de terceiros estão envolvidos na operação do bloco D:

• O componente orquestrador de fluxo de trabalho, responsável por iniciar o pipeline em uma programação ou evento especificado
• Feature Store, de onde são obtidos os dados sobre os recursos necessários para o modelo
• Registro de Modelo e armazenamento de metadados de ML, onde são colocados os modelos e suas métricas, obtidos após o trabalho do Pipeline lançado

A própria estrutura do bloco combina as etapas dos blocos de experimentação e desenvolvimento de recursos (B2). Não é surpreendente, considerando que estes são os processos que precisam ser automatizados. As principais diferenças estão nas últimas 2 etapas:

• Modelo de exportação
• Envie para o registro do modelo

As etapas restantes são idênticas às descritas acima.

Separadamente, quero mencionar os artefatos de serviço que são exigidos pelo orquestrador para executar pipelines de retreinamento de modelo. Este é o código que é armazenado no repositório e executado em servidores selecionados. É versionado e atualizado seguindo todas as regras de desenvolvimento de software. Este código implementa os pipelines de retreinamento do modelo e o resultado depende de sua correção.

Na maioria das vezes, várias ferramentas de ML são executadas dentro do código, dentro das quais ocorre a execução das etapas dos pipelines, por exemplo:

• O orquestrador de fluxo de ar executa o código para executar os estágios dos pipelines
• O Feast descarrega dados sobre os recursos do conjunto de dados sob comando
• Em seguida, o ClearML cria um novo conjunto de dados e executa um experimento com o conjunto necessário de métricas de desempenho do modelo, obtido de seu próprio repositório.
• Após a conclusão da investigação, o ClearML salva o modelo e suas métricas de desempenho no armazenamento

É importante notar aqui que geralmente é impossível automatizar experimentos. É possível, claro, adicionar o conceito AutoML ao processo. No entanto, atualmente não existe uma solução reconhecida que possa ser usada com os mesmos resultados para qualquer sujeito do experimento.

No caso geral, o AutoML funciona assim:

1. De alguma forma, gera um conjunto de muitas combinações de parâmetros de operação do modelo
2. Executa um experimento para cada combinação resultante. Corrige métricas para cada experimento com base na seleção do melhor modelo
3. O AutoML faz todas as manipulações que um cientista de dados júnior/médio faria em um círculo de tarefas mais ou menos padrão

A automação foi tratada um pouco. Em seguida, precisamos organizar a entrega de uma nova versão do modelo para produção.

Modelos de atendimento e monitoramento

O modelo de ML é necessário para gerar previsões. Mas o modelo de ML em si é um arquivo que não pode ser gerado tão rapidamente. Muitas vezes você pode encontrar essa solução na Internet: uma equipe pega FastAPI e escreve um wrapper Python em torno do modelo para que você possa “seguir os predicados”.

A partir do momento em que o arquivo do modelo de ML é recebido, as coisas podem acontecer de várias maneiras. A equipe pode ir:

• Escreva todo o código para construir um serviço RESTfull
• Implemente todo o envolvimento em torno dele
• Construa tudo em uma imagem Docker
• E então, em algum lugar dessa imagem, você construirá um contêiner
• Dimensione de alguma forma
• Organize a coleção de métricas
• Configurar alertas
• Configure regras para lançar novas versões do modelo
• Muitas outras coisas

É uma tarefa trabalhosa fazer isso para todos os modelos e manter toda a base de código no futuro. Para facilitar, surgiram ferramentas especiais de atendimento, que introduziram 3 novas entidades:

• Instância/serviço de inferência
• Servidor de inferência
• Motor de serviço

Uma Instância de Inferência, ou Serviço de Inferência , é um modelo específico de ML preparado para receber consultas e gerar previsões de respostas. Tal entidade pode representar um subem um cluster Kubernetes com um contêiner com o modelo de ML necessário e as ferramentas técnicas para executá-lo.

O Servidor de Inferência é o criador das Instâncias/Serviços de Inferência. Existem muitas implementações de Servidor de Inferência. Cada um pode trabalhar com estruturas de ML específicas, convertendo os modelos treinados neles em modelos prontos para uso para processar consultas de entrada e gerar previsões.

O Serving Engine executa as principais funções de gerenciamento. Ele determina qual Servidor de Inferência será usado, quantas cópias da Instância de Inferência resultante devem ser iniciadas e como escalá-las.

No esquema em consideração, não existe tal detalhamento dos componentes que servem o modelo, mas aspectos semelhantes são delineados:

• Componente CI/CD, que implanta modelos prontos para rodar em produção (pode ser considerado como uma das versões do Serving Engine)
• O Model Serving, dentro da infraestrutura de que dispõe, organiza o esquema de geração de predição para modelos de ML, tanto para cenários de streaming quanto para cenários em lote (pode ser considerado como uma das versões do Inference Server)

Para obter um exemplo de pilha completa para Servir, podemos consultar a pilha de Seldon:

• Seldon Core é o motor de serviço
• Seldon ML Server é o Servidor de Inferência, que prepara o acesso ao modelo via REST ou gRPC
• Seldon MLServer Custom Runtime é a instância de inferência, uma instância de shell para qualquer modelo de ML cujo exemplo precisa ser executado para gerar previsões.

Existe ainda um protocolo padronizado para implementação do Serving, cujo suporte é de fato obrigatório em todas essas ferramentas. É chamado de Protocolo de Inferência V2 e foi desenvolvido por vários participantes proeminentes do mercado - KServe, Seldon e Nvidia Triton.

Servindo vs. Implantando

Em vários artigos, você pode encontrar referências às ferramentas para veiculação e implantação como uma entidade única. Porém, é essencial entender a diferença na finalidade de ambos. Esta é uma questão discutível, mas este artigo irá colocá-la desta forma:

• Servindo - a criação de um modelo de API e a possibilidade de obter previsões a partir dele. No final, você obtém uma única instância de serviço com um modelo interno.
• Implantar - distribuir a instância de serviço na quantidade necessária para processar solicitações recebidas (pode ser representado como um conjunto de réplicas na implantação do Kubernetes).

Muitas estratégias podem ser usadas para implantar modelos , mas não são específicas de ML. A propósito, a versão paga do Seldon suporta várias estratégias, então você pode apenas selecionar esta pilha e aproveitar como tudo funciona.

Lembre-se de que as métricas de desempenho do modelo devem ser rastreadas. Caso contrário, você não conseguirá resolver os problemas a tempo. Como exatamente rastrear as métricas é a grande questão. Arize AI construiu todo um negócio sobre isso, mas ninguém cancelou Grafana e VictoriaMetrics.

Iniciação do projeto

Considerando tudo o que foi escrito acima, verifica-se que o comando ML:

• Gera conjuntos de dados
• Realiza experimentos com eles em modelos de ML
• Desenvolve novos recursos para estender conjuntos de dados e melhorar a qualidade dos modelos
• Salva os melhores modelos no Registro de Modelos para reutilização futura
• Personaliza o serviço e a implantação de modelos
• Personaliza o monitoramento de modelos em produção e reciclagem automática de modelos atuais ou criação de novos modelos

Parece caro e só às vezes justificado. Portanto, há um bloco separado de Iniciação do Projeto MLOps (A) no diagrama responsável pelo estabelecimento racional de metas.

Um exemplo do raciocínio do diretor de TI pode demonstrar a forma de pensar aqui. Um inspirado gerente de projeto chega até ele e pede a instalação de uma nova plataforma para construir um sistema de ML. Se ambos estiverem agindo no melhor interesse da empresa, serão feitas perguntas esclarecedoras por parte do diretor de TI:

• Que problema de negócios você resolverá com o novo sistema de ML?
• Por que você decidiu que o novo sistema de ML deveria resolver esse problema?
• Seria mais fácil e barato mudar processos ou contratar mais pessoas para suporte técnico?
• Onde você pode ver uma análise comparativa dos componentes do sistema de ML que formaram a base de sua seleção atual?
• Como a arquitetura do sistema de ML escolhida ajudará a resolver um problema de negócios?
• Tem certeza de que o ML possui o aparato matemático necessário para resolver o problema identificado?
• Qual é a declaração do problema para a solução?
• Onde você obterá os dados para treinar os modelos? Você sabe quais dados são necessários para preparar os modelos?
• Você já examinou os dados disponíveis?
• A qualidade dos dados é suficiente para resolver o modelo?

O diretor de TI será destituído do cargo de professor em uma universidade, mas economizará o dinheiro da empresa. Se todas as perguntas foram respondidas, existe uma necessidade real de um sistema de ML.

Próxima pergunta: Preciso fazer MLOps nele?

Depende do problema. Se você precisar encontrar uma solução única, por exemplo, PoC (Prova de Conceito), não precisará de MLOps. Se for essencial processar muitas solicitações recebidas, então o MLOps será necessário. Em essência, a abordagem é semelhante à otimização de qualquer processo corporativo.

Para justificar a necessidade de MLOps para o gerenciamento, é necessário preparar respostas para as perguntas:

• O que vai melhorar?
• Quanto dinheiro economizaremos?
• Se precisamos expandir nossa equipe?
• O que precisamos comprar?
• Onde obter experiência?

A próxima coisa a fazer é refazer o exame de diretor de TI.

Os desafios continuam porque a equipa também deve estar convencida da necessidade de mudar os seus processos de trabalho e a sua pilha de tecnologia. Às vezes, isso é mais difícil do que pedir um orçamento à administração.

Para convencer a equipe, vale preparar respostas para as perguntas:

• Por que a antiga forma de trabalhar não é mais possível?
• Qual é o propósito da mudança?
• Qual será a pilha de tecnologia?
• O que e com quem aprender?
• Como a empresa ajudará na implementação das mudanças?
• Quanto tempo leva para fazer a mudança?
• O que acontece com aqueles que não conseguem?

Como você pode ver, esse processo não é simples.

Pequena conclusão

Concluí aqui um estudo detalhado do esquema MLOps. No entanto, estes são apenas aspectos teóricos. A implementação prática sempre revela detalhes adicionais que podem mudar muitas coisas.

No próximo artigo, discutirei:

• Artefatos MLOps
• MLOps como sistema de informação
• Código aberto para MLOps: Kubeflow x MLflow x Pachyderm

Obrigado pela sua atenção!