Capítulo 98 – Machine Learning – Guia Definitivo – Parte 8
Nos 10 capítulos finais (de 91 a 100) deste livro online vamos trazer um grande resumo sobre Machine Learning. O objetivo é fornecer uma visão clara do que é e como Machine Learning está sendo usado no dia a dia, um pouco de matemática, as principais regras e princípios. Queremos ainda que esses capítulos finais possam servir de material de referência para os alunos que estão buscando as certificações oferecidas pela DSA no Bootcamp de Certificação.
Serão 10 partes no total com um guia completo sobre Machine Learning. Aproveite a leitura para compreender de forma definitiva o que é uma das tecnologias mais incríveis do nosso tempo.
Neste capítulo vamos abordar algumas regras que raramente você verá sendo explicadas nos cursos em geral por aí, pelo simples fato que muitos que ensinam Machine Learning nunca colocaram um modelo em produção: Como analisar um modelo existente e melhorá-lo? Isso é mais uma arte do que uma ciência e existem vários padrões e técnicas que ajudam com essa tarefa.
Boa leitura!
O Que é o Deploy de Modelos de Machine Learning?
Antes de trazer as regras para você, vamos compreender claramente o que é colocar um modelo em produção, o que tem vários sinônimos: servir o modelo, implantar o modelo, fazer o deploy do modelo.
Os modelos de Machine Learning (ML) quase sempre são desenvolvidos em uma configuração offline, mas devem ser implantados em um ambiente de produção para fazer previsões ou detectar padrões com novos dados e, então, agregar valor.
O objetivo de construir um aplicativo de aprendizado de máquina é resolver um problema e um modelo de ML só pode fazer isso quando está sendo usado ativamente em produção.
Como tal, a implantação do modelo de ML é tão importante quanto o desenvolvimento do modelo de ML. Cientistas de Dados desenvolvem os modelos e Engenheiros de Machine Learning fazem o deploy.
A implantação é o processo pelo qual um modelo de ML é movido de um ambiente offline e integrado a um ambiente de produção, como um aplicativo ativo. É uma etapa crítica que deve ser concluída para que um modelo atenda ao propósito pretendido e resolva os desafios para os quais foi projetado.
O processo exato de implantação do modelo de ML será diferente dependendo do ambiente do sistema, do tipo de modelo e dos processos de DataOps e MLOps implementados em cada empresa.
Agora vamos às regras com dicas valiosas.
Regra 23: Você Não Deve Fazer os Testes Finais no Modelo
Você (Cientista de Dados, Engenheiro de Machine Learning ou Engenheiro de IA) não é um usuário final do modelo. Você não deve ser o responsável pelos testes finais quando o modelo estiver próximo de ser colocado em produção.
Em última instância um modelo de Machine Learning é uma peça de software e uma regra básica da Engenharia de Software é que os testes devem ser feitos por quem não desenvolveu a solução. Ensinamos isso no primeiro curso da Formação Engenheiro de Machine Learning.
Os testes finais de um modelo de Machine Learning devem ser feitos por usuários, preferencialmente usuários que irão usar o sistema ou que serão responsáveis pelo suporte ao usuário final.
Regra 24: Obtenha Feedback Contínuo
Uma vez que o modelo seja colocado em produção e testado pelos usuários, isso não significa que o trabalho acabou. Muito pelo contrário. O modelo deve ser constantemente monitorado e novas rodadas de validação e testes com os usuários finais devem ser realizadas. Quanto mais feedback você obter sobre o uso do modelo, mais fácil identificar e corrigir problemas.
Para obter feedback contínuo, considere perguntas como essas:
- Como podemos obter o feedback dos modelos de produção?
- Como podemos garantir uma entrega constante?
- Como podemos testar novas iterações do modelo?
- Como podemos iterar nosso modelo sem interromper sua operação?
Crie uma base de conhecimento com o feedback contínuo do modelo em produção e o uso de Machine Learning se torna algo de valor cada vez maior para a empresa.
Regra 25: Calcule o Delta Entre os Modelos
Se você já tiver um modelo de Machine Learning em produção e está preparando uma nova versão do modelo, esse é um bom momento para calcular a diferença de performance entre ambos. Por isso a regra 24 anterior é tão importante. Com a ajuda da validação feita por um usuário final, você pode calcular e medir a diferença de performance entre o modelo atual em produção e o novo modelo com as melhorias.
Além de criar documentação, permite demonstrar a evolução do trabalho e como a empresa está conseguindo construir modelos cada vez melhores. E o contrário também é verdadeiro. Uma mudança que poderia melhorar a performance pode, na verdade, piorá-la e esse é o momento de detectar isso.
Calculando o delta da diferença de performance, podemos facilmente responder perguntas do tipo: Qual o percentual de melhoria de performance do modelo em produção depois das alterações realizadas? Qual foi o custo dessa melhoria? Quanto tempo foi necessário?
Regra 26: Ao Atualizar Modelos, a Solução do Problema é Mais Importante do Que o Poder Preditivo
Seu modelo pode tentar prever a taxa de cliques, por exemplo. No entanto, no final, a questão-chave é o que você faz com essa previsão. Se você estiver usando o modelo para classificar documentos, a qualidade da classificação final importa mais do que o poder de previsão.
Machine Learning não é um fim. É um meio para resolver problemas. Logo, a performance geral do sistema é mais importante do que o poder preditivo do modelo.
Imagine um modelo usado para previsão se uma mensagem é spam ou não. O modelo não precisa ser 100% eficaz. Se conseguir prever que um documento é spam com 55% de probabilidade isso já é suficiente e a performance final do sistema (ter cada mensagem classificada como spam ou não) será ótima.
É comum tentar levar o modelo ao limite da perfeição (como se isso fosse realmente possível), quando na verdade o poder de previsão é menos importante do que o resultado em si.
Regra 27: Procure Padrões nos Erros do Modelo em Produção e Crie Novos Recursos
Suponha que você veja um exemplo de que o modelo em produção errou na previsão. Em uma tarefa de classificação, esse erro pode ser um falso positivo ou um falso negativo. Em uma tarefa de classificação, o erro pode ser um par em que um positivo foi classificado abaixo de um negativo.
O ponto mais importante é que este é um exemplo de que o sistema de aprendizado de máquina sabe o que deu errado e gostaria de corrigir se tivesse a oportunidade. Se você fornecer ao modelo um recurso que permita corrigir o erro, o modelo tentará usá-lo.
Logo, se o modelo em produção foi treinado com 10 recursos (10 variáveis), pode ser que a inclusão de mais um recurso aumente de forma significativa a performance do modelo. Por isso é tão importante monitorar o modelo em produção, pois o padrão que havia nos dados usados no treinamento pode mudar ao longo do tempo e novos recursos podem ser necessários.
Regra 28: Tente Quantificar o Comportamento Indesejável Observado
É natural que um modelo tenha perda de performance ao longo do tempo. Os eventos que geraram os dados mudam, os padrões de comportamento mudam, os dados mudam.
Em determinado momento, um modelo em produção pode começar a apresentar comportamento indesejado, indicando que sua performance está deteriorando. Mas qual o limite aceitável e como quantificar isso?
O ideal nesse caso é criar uma métrica para quantificar o comportamento indesejado. Por exemplo, se é aceitável um modelo classificar mensagens como spam com 55% de probabilidade, se esse valor for reduzido para 52% é hora de tomar alguma ação. Ou seja, não temos que esperar o modelo começar a errar para então otimizá-lo.
A regra geral é “medir primeiro, otimizar depois”. Não caia na tentação de querer otimizar algo que você não mediu antes.
Regra 29: Esteja Ciente de Que Comportamento Idêntico de Curto Prazo Não Implica Comportamento Idêntico de Longo Prazo
A mudança é a regra.
Uma boa estratégia depois que os dados estiverem em produção é continuar coletando novos dados e retreinar o modelo periodicamente. Algumas empresas retreinam seus modelos todos os dias, algumas uma vez por semana e isso vai depender do volume de dados disponível.
Mas o fato é que mudanças de comportamento são esperadas e o modelo não pode ficar muito tempo sem atualização. É possível criar um repositório de versionamento de modelos para garantir que tenhamos sempre a versão mais atual disponível em produção. E mesmo se o modelo parece apresentar boa performance por vários dias seguidos, isso não é garantia que irá permanecer assim por muito tempo.
Regra 30: Reutilize o Código Entre o Pipeline de Treinamento e o Pipeline de Deploy Sempre que Possível
O processamento em lote é diferente do processamento online. No processamento online, você deve lidar com cada solicitação à medida que ela chega (por exemplo, você deve fazer uma pesquisa separada para cada consulta), enquanto no processamento em lote, você pode combinar tarefas (por exemplo, fazer uma junção).
Quando o modelo está em produção, você está fazendo o processamento online, enquanto o treinamento do modelo é uma tarefa de processamento em lote. No entanto, há algumas coisas que você pode fazer para reutilizar o código.
Por exemplo, você pode criar um objeto que seja específico do seu sistema onde o resultado de quaisquer consultas ou junções pode ser armazenado de uma maneira muito legível e os erros podem ser testados facilmente. Então, depois de reunir todas as informações, com o modelo em produção ou em treinamento, você executa um método comum para fazer a ponte entre o objeto legível por humanos específico do seu sistema e qualquer formato que o sistema de aprendizado de máquina espera.
Isso elimina uma fonte de distorção entre o modelo em produção e o treinamento. Tente não usar duas linguagens de programação diferentes entre treinar e servir. Essa decisão tornará quase impossível compartilhar código.
Regra 31: Se Você Produzir um Modelo com Base nos Dados até 5 de Janeiro, Teste o Modelo nos Dados de 6 de Janeiro em Diante
Em geral, meça o desempenho de um modelo nos dados coletados após os dados nos quais você treinou o modelo, pois isso reflete melhor o que seu sistema fará em produção.
Se você produzir um modelo com base nos dados até 5 de janeiro, teste o modelo nos dados a partir de 6 de janeiro, por exemplo. Você esperará que o desempenho não seja tão bom nos novos dados, mas não deve ser radicalmente pior.
Como pode haver efeitos diários, você pode não prever a taxa média de cliques ou a taxa de conversão, mas a área sob a curva, que representa a probabilidade de dar ao exemplo positivo uma pontuação mais alta do que a um exemplo negativo, deve ser razoavelmente próxima.
Regra 32: Na classificação binária para filtragem (como detecção de spam ou determinação de e-mails interessantes), faça pequenos sacrifícios de curto prazo no desempenho para obter dados limpos
Em uma tarefa de filtragem, os exemplos marcados como negativos não são mostrados ao usuário final da aplicação que contém o modelo de Machine Learning.
Suponha que você tenha um filtro que bloqueie 75% dos exemplos negativos em produção. Você pode ficar tentado a extrair dados de treinamento adicionais das instâncias mostradas aos usuários. Por exemplo, se um usuário marca um e-mail como spam que seu filtro deixou passar, você pode querer aprender com isso.
Mas essa abordagem introduz viés de amostragem. Você pode coletar dados mais limpos se, com o modelo em produção, rotular 1% de todo o tráfego como “retido” e enviar todos os exemplos retidos ao usuário. Agora seu filtro está bloqueando pelo menos 74% dos exemplos negativos. Esses exemplos retidos podem se tornar seus dados de treinamento.
Observe que se o seu filtro estiver bloqueando 95% dos exemplos negativos ou mais, essa abordagem se tornará menos viável. Mesmo assim, se você deseja medir o desempenho em produção, pode fazer uma amostra ainda menor (digamos 0,1% ou 0,001%). Dez mil exemplos são suficientes para estimar o desempenho com bastante precisão.
Regra 33: Evite Loops de Feedback com Características Posicionais
A posição do conteúdo afeta drasticamente a probabilidade de o usuário interagir com ele. Se você colocar um botão na primeira posição no topo de uma página, ele será clicado com mais frequência do que um botão no final da página. A posição fará com que um botão seja muito mais clicado do que o outro e isso pode dar a impressão que o primeiro botão é melhor. Não. Ele apenas está posicionado de forma que o cérebro humano o percebe primeiro.
Uma maneira de lidar com isso é adicionar características posicionais, ou seja, características sobre a posição do conteúdo na página. Você treina seu modelo com recursos posicionais e ele aprende a ponderar, por exemplo, o recurso “1stposition” fortemente. Seu modelo, portanto, dá menos peso a outros fatores para exemplos com “1stposition=true”.
Então, ao servir o modelo, você não dá a nenhuma instância o recurso posicional, ou dá a todos o mesmo recurso padrão, porque você está pontuando os candidatos antes de decidir a ordem na qual exibi-los.
Observe que é importante manter quaisquer recursos posicionais um pouco separados do restante do modelo devido a assimetria entre treinamento e teste. Ter o modelo como a soma de uma função dos traços posicionais e uma função do resto dos traços é o ideal. Por exemplo, não cruze os recursos posicionais com nenhum recurso de documento.
Regra 34: Medir a Distorção Entre Treinamento/Produção
Existem várias coisas que podem causar distorção no sentido mais geral. Além disso, você pode dividi-lo em várias partes:
A diferença entre o desempenho nos dados de treinamento e os dados de validação. Em geral, isso sempre existirá, e nem sempre é ruim.
A diferença entre o desempenho nos dados de validação e os dados do “dia seguinte”. Novamente, isso sempre existirá. Você deve ajustar sua regularização para maximizar o desempenho no dia seguinte. No entanto, grandes quedas no desempenho entre os dados de hoje e do dia seguinte podem indicar que alguns recursos são sensíveis ao tempo e possivelmente degradam o desempenho do modelo.
A diferença entre o desempenho nos dados do “dia seguinte” e os dados ao vivo. Se você aplicar um modelo a um exemplo nos dados de treinamento e o mesmo exemplo em produção, ele deverá fornecer exatamente o mesmo resultado. Assim, uma discrepância aqui provavelmente indica um erro na construção do modelo.
Regra 35: Prepara-se Para o Deploy Através de Containers
Hoje a tecnologia de containers (máquinas virtuais super leves) é quase um padrão em Machine Learning e Engenharia de Dados (e por isso o tema é abordado em detalhes nos cursos em nosso portal).
Ao fazer o deploy de um modelo você não estará enviando o modelo em si, mas um container com o modelo, suas dependências, arquivos de configuração, parâmetros e muito mais. Isso simplifica o deploy, mas requer cuidados adicionais, especialmente com o versionamento. Certifique-se que você domina a tecnologia de containers e conhece muito bem o Docker.
Continuaremos no próximo capítulo.
Referências:
Curso Gratuito de Sistema Operacional Linux, Docker e Kubernetes
Machine Learning com Python e R