O maior problema enfrentado pelo Aprendizado de Máquina (ML – Machine Learning) não é se vamos descobrir melhores algoritmos (provavelmente iremos), se criaremos uma IA genérica (provavelmente não iremos) ou se conseguiremos lidar com eles. O maior problema é como colocaremos os sistemas de ML em produção. Conseguir que um experimento funcione em um laptop é uma coisa. Colocar esse experimento em produção é outra questão. A produção tem que lidar com a realidade, e a realidade não está presente em nossos laptops.
A maior parte do nosso entendimento de “produção” veio do mundo da web e aprendeu a executar aplicativos de comércio eletrônico e mídias sociais em grande escala. Os últimos avanços nas operações de sistemas Web – contêiner e orquestração de contêineres – facilitam o empacotamento de aplicativos que podem ser implantados de maneira confiável e mantida de forma consistente. Ainda não é fácil, mas as ferramentas estão lá. Esse é um bom começo.
Os aplicativos de Machine Learning diferem do software tradicional de duas maneiras importantes. Primeiro, eles não são determinísticos. Segundo, o comportamento do aplicativo não é determinado pelo código, mas pelos dados usados no treinamento. Essas duas diferenças estão intimamente relacionadas.
Um aplicativo tradicional implementa uma especificação que descreve o que o programa deve fazer. Se alguém clicar em “comprar”, um item será adicionado ao carrinho de compras. Se alguém depositar um cheque, uma transação será gerada e as contas serão debitadas e creditadas. Embora as especificações possam ser ambíguas, em um nível fundamental, o comportamento do programa não é. Se você compra um item e esse item não acaba no seu carrinho de compras, isso é um bug.
O aprendizado de máquina é fundamentalmente diferente porque nunca é 100% preciso. Não importa se está identificando rostos, decodificando a caligrafia ou entendendo a fala; erros sempre ocorrerão, e a única questão real é se a taxa de erro é aceitável. Portanto, o desempenho de um sistema de ML não pode ser avaliado com base em uma especificação estrita. É sempre avaliado com base em métricas: métricas de baixo nível, como falsos negativos ou positivos, e métricas em nível de negócios, como vendas ou retenção de usuários. As métricas são sempre específicas do aplicativo; em uma entrevista em podcast, Pete Skomoroch discutiu as métricas usadas pelo LinkedIn para aumentar a retenção. As taxas de erro também são específicas do aplicativo: você pode tolerar uma taxa de erro muito maior em um sistema de recomendação do que em um veículo autônomo. Se você não pode tolerar erros, se é inaceitável que um cliente deposite dinheiro e que este não apareça depositado em sua conta bancária, você não deve usar IA.
O comportamento de um aplicativo tradicional é completamente determinado pelo código. O código certamente inclui bibliotecas de programação. Independentemente de onde você desenha a linha, há uma base de código que determina tudo o que o aplicativo pode fazer.
Nos sistemas ML o código é menos importante. O comportamento do sistema é determinado por um modelo treinado e testado em um conjunto de dados coletados pelos Cientistas de Dados. O modelo levanta uma série de problemas. Os resultados de uma pesquisa recente da O’Reilly mostraram que “a falta de dados ou problemas de qualidade dos dados” está retardando a evolução das tecnologias de IA. Os dados de treinamento podem ser imprecisos e frequentemente refletem preconceitos que levam a aplicativos injustos. Mesmo que os dados sejam precisos quando o modelo é criado, os modelos ficam obsoletos ao longo do tempo e precisam ser treinados novamente. As pessoas mudam seu comportamento, talvez em resposta ao próprio sistema. E o uso de dados de treinamento (e a proteção de informações pessoais) está cada vez mais sujeito a regulamentação, como o GDPR. Coletar dados, limpar os dados, manter os pipelines que coletam os dados, treinar novamente o modelo e implantar o novo modelo são tarefas que nunca desaparecem. Por isso há cada vez mais oportunidades para Cientistas de Dados, Engenheiros de Dados e Engenheiros de Machine Learning.
E como implantamos e gerenciamos esses sistemas? Precisamos voltar ao básico, começando com as ideias mais fundamentais do desenvolvimento de software:
- Controle de versão para tudo
- Automatização todos os processos que podem ser automatizados
- Teste de tudo o que pode ser testado
Os desenvolvedores de software usam sistemas de controle de versão para gerenciar alterações no código fonte há anos. Esse é um começo importante – mas precisamos entender que o aprendizado de máquina apresenta um problema muito maior. Você não pode simplesmente gerenciar o código fonte. Você precisa gerenciar os modelos, os dados usados para treinar e testar os modelos e os metadados que descrevem os dados (suas origens, os termos sob os quais eles podem ser usados etc.). Isso está além do escopo dos sistemas tradicionais de controle de versão, como o git, mas estamos começando a ver ferramentas como o MLflow, projetadas para gerenciar o processo de desenvolvimento, incluindo tarefas como versionar dados de treinamento e rastrear linhagem e proveniência de dados.
As ferramentas atualmente disponíveis, como Docker e Kubernetes, podem automatizar implantações de sistemas de Machine Learning. O problema não é a falta de ferramentas, mas também a atitude e as expectativas. Um aplicativo de ML não está completo quando funciona no laptop do desenvolvedor e é enviado para a nuvem. Esse processo manual deixa você com soluções artesanais de implantação diferentes para cada aplicativo. Se todo contêiner do Docker for uma obra de arte exclusiva, nem os contêineres nem a orquestração de contêineres lhe custarão muito. Essas soluções falharão assim que o desenvolvedor original deixar a empresa ou simplesmente não estiver disponível. Lembre-se também de que um sistema de ML não é apenas o aplicativo: ele deve incluir os pipelines para aquisição de dados, limpeza de dados, modelos de treinamento e testes. A implantação confiável de software complexo é uma disciplina que depende de padronização e automação. A engenharia de aprendizado de máquina agora é uma especialidade distinta, e os Engenheiros de Machine Learning estão desenvolvendo ferramentas e práticas mais adequadas para a implantação de sistemas de ML.
Teste, monitoramento e extensão do monitoramento são práticas fundamentais para operações modernas e engenharia de confiabilidade. Eles são igualmente importantes para o aprendizado de máquina, mas Machine Learning muda o jogo. Os sistemas de ML precisam ser monitorados em relação às métricas de desempenho, não às especificações; precisamos de ferramentas que possam detectar se os modelos ficaram obsoletos e precisam ser re-treinados; essas ferramentas podem até iniciar um novo treinamento automático. Nossas necessidades vão muito além das estruturas de teste de unidade e monitoramento de rede; precisamos de uma imagem precisa se o sistema está produzindo resultados precisos, justos e atendendo às nossas métricas de desempenho.
Na última década vimos a evolução dos procedimentos de implantação de grandes aplicações web. Agora estamos vendo a evolução dos procedimentos de implantação de sistemas de Machine Learning. O refrão constante é “Espere! As ferramentas de que precisamos estão chegando!”. Ainda não temos as ferramentas necessárias para levar o aprendizado de máquina do laptop à produção de maneira eficiente e correta, mas sabemos o que construir. As ferramentas existentes das comunidades DevOps mostram o que precisamos; são provas de conceitos que demonstram que os problemas de implantação e manutenção em escala são solucionáveis.
Traduzido do original: Machine learning requires a fundamentally different deployment approach
David Matos
Não acredito que emular o ciclo de desenvolvimento tradicional para ML seja a solução. Não funciona muito bem nem mesmo para fábricas de software, haja vista a insatisfação constante dos usuários.
A solução na minha opinião seria o modelo treinado no laptop poder ser lançado na nuvem (como pode) e ser “emendado” com dados novos, que fariam um “tuning” dos parâmetros do modelo treinado, atualizando-o sem apagar a “memória” do que se aprendeu no passado. Estes dados novos poderiam até mesmo dispensar os scripts usados nos dados de treinamento da 1a versão, como se fosse a criação de um novo modelo, sofrendo outro tipo de feature enginering, o que poderia enriquecer o modelo já treinado com novos insights, balanceados com os insights já existentes no modelo treinado.