Agora, vamos ver com detalhes as fases de desenvolvimento e publicação de um modelo de machine learning. Pense nos MLOps como uma disciplina de gestão de ciclo de vida para ML. O objetivo dela é ter uma abordagem equilibrada de processamento completo voltada ao gerenciamento de recursos, dados, código, tempo e qualidade para atingir as metas empresariais e cumprir os requisitos regulamentares. Alguns dos conceitos de DevOps refletem diretamente em MLOps. Quando desenvolvedores de software trabalham em um projeto, essas pessoas não trabalham no mesmo código ao mesmo tempo. Em vez disso, elas verificam o código no qual pretendem trabalhar em um repositório seguro de códigos e depois o mesclam de novo quando a tarefa é concluída. Antes que o código seja devolvido a um repositório seguro, o desenvolvedor verifica se nada mudou na versão principal e se a nova unidade tem as atualizações antes de mesclar o código novamente. Quanto mais frequentemente essas mudanças forem mescladas com o código principal, menor será a chance de divergência. Esse processo é chamado de CI, ou integração contínua. Em uma equipe de desenvolvimento ocupada, isso acontece dezenas de vezes por dia. Outro processo preferido dos desenvolvedores é a entrega contínua, chamada de CD. Este é um método para desenvolver, testar e lançar software em ciclos curtos. Feito dessa forma, o código principal de desenvolvimento está quase sempre pronto para produção e, a qualquer momento, pode ser lançado no ambiente ao vivo. Caso isso não seja feito dessa maneira, o código principal é como um carro de corrida sem rodas e sem motor: ele pode ser rápido, mas só quando está completo. A entrega contínua pode ser feita manual ou automaticamente. A integração contínua de código-fonte, teste de unidade, teste de integração e entrega contínua do software para produção também são processos importantes nas operações de machine learning. Mas há outro aspecto importante relacionado a MLOps. É isso mesmo: os dados. Ao contrário do software convencional, que podemos confiar para fazer sempre a mesma coisa, um modelo de ML pode deixar de funcionar. Com isso, queremos dizer que seu poder preditivo diminui à medida que os perfis de dados mudam, o que inevitavelmente acontece. Assim, podemos basear os processos em integração e entrega contínuas e introduzir um novo termo: treinamento contínuo, ou CT. O treinamento contínuo é o processo de medir, monitorar, treinar outra vez e exibir os modelos. O MLOps se diferencia do DevOps de maneiras importantes também. A integração contínua já não é mais só sobre testar e validar códigos e componentes, mas também sobre testar e validar dados, esquemas de dados e modelos. Não se trata mais de apenas um único pacote de software ou serviço, mas de um sistema, o pipeline de treinamento de ML, que, de maneira automática, precisa implantar outro serviço: o serviço de previsão de modelos. De maneira singular, o ML também se preocupa em monitorar, treinar outra vez e exibir os modelos de maneira automática. A dívida técnica é outro conceito que é visto tanto em desenvolvimento de software como em aprendizado de máquina. Os desenvolvedores de software estão familiarizados com as escolhas entre tempo, recursos e qualidade. Essas pessoas falam sobre dívida técnica, que é o o acúmulo de retrabalho gerado, porque às vezes é preciso comprometer a qualidade para desenvolver o código rapidamente. Há o entendimento de que, embora possa haver boas razões para isso, será preciso voltar mais tarde para corrigir o que for necessário. Na área de engenharia, isso é a reformulação de um ditado popular: "Deixe para amanhã o que é melhor fazer hoje". Há um preço a ser pago. O aprendizado de máquina pode ser considerado o cartão de crédito com juros altos da dívida técnica. Isso significa que desenvolver e implantar um sistema de ML pode ser relativamente rápido e barato, mas mantê-lo ao longo do tempo pode ser difícil e caro. O verdadeiro desafio não é criar um modelo de ML, e sim criar um sistema de ML integrado e operá-lo continuamente na produção. Como um cartão de crédito com juros altos, a dívida técnica com ML vai se agravando e pode ficar cara e difícil de pagar. Podemos considerar sistemas de ML como um tipo especial de sistema de software. Operacionalmente, eles têm todos os desafios do desenvolvimento de software, além de alguns próprios. Alguns deles incluem equipes multifuncionais, porque os projetos de ML provavelmente terão desenvolvedores e cientistas de dados trabalhando em análise de dados, desenvolvimento de modelos e experimentação. Equipes multifuncionais podem criar os próprios desafios de gerenciamento. Machine learning é experimental por natureza. É preciso testar constantemente novas abordagens em relação aos dados, aos modelos e à configuração de parâmetros. O desafio é acompanhar o que funcionou e o que não funcionou, além de manter a reprodutibilidade enquanto maximiza a reutilização do código. Outra consideração é: testar um sistema de ML é mais complicado do que testar outros sistemas de software, porque você está validando dados, parâmetros e códigos juntos em um sistema, em vez de métodos e funções de teste de unidade. Em sistemas de ML, a implantação não é tão simples quanto implantar um modelo de ML treinado off-line como um serviço de produção. Os sistemas de ML podem exigir a implantação de um pipeline de vários passos para treinar e implantar os modelos de maneira automática. E, finalmente, é preciso abordar as preocupações com o desvio de conceito e o consequente declínio do modelo. Os perfis de dados mudam constantemente: se algo mudar na entrada de dados, a capacidade preditiva do modelo em produção provavelmente vai mudar também. Portanto, é preciso acompanhar o resumo das estatísticas dos dados e monitorar o desempenho on-line do modelo para enviar notificações ou fazer reversões quando os valores forem diferentes daquilo que você espera. Há vários motivos para o acúmulo da divida técnica em um sistema de ML. Ao longo deste curso, vamos buscar maneiras de amenizar isso.
