Lições das trincheiras: colocando sistemas de ML em produção

Na imensa maioria das vezes assistimos palestras de empresas e startups que falam em usar sistemas de ML, geralmente no futuro, ou que estão em experimentações em labs restritos, mas poucas vezes ouvimos elas dizerem de como mantém seus sistemas de ML em produção. Um sistema de ML não utilizado não oferece valor. Um protótipo, se não for colocado em produção, torna-se um brinquedo. E em muitas conversas observo que ainda vemos poucas coisas de ML colocadas em produção e por isso pouco é dito sobre como fazer a transição do desenvolvimento para produção e de como manter e gerenciar estes sistemas no dia a dia.

Um sistema de ML é um sistema de software. Para sair da ideia para a realidade deve seguir a prática de desenvolvimento ágil que já conhecemos, embora os prazos possam ser muito mais incertos que nos sistemas programáticos. Se você não tem experiência com projetos de ML terá alguma dificuldade de mensurar prazos e custos. Por exemplo, negocie claramente com os usuários qual a precisão (níveis de acerto) que os modelos devem atender. Os dados de treinamento estão rotulados e limpos, ou os dados devem ser criados? A falta de dados ou dados não rotulados e sujos pode atrasar em muitos meses o projeto! Quais prazos devem ser cumpridos? Isso pode ser muito mais desafiador do que no desenvolvimento de software tradicional, pois a melhoria de um modelo exige experimentação. Pode levar poucas semanas para se chegar a 50% de precisão, uns meses para 80%, mais alguns para 95% e muitos mais para alcançar o patamar de 98%. Até que nível você realmente precisa chegar? E, acorde também como considerar que a solução está pronta para produção. Como vemos, tem diferenças em relação aos sistemas programáticos determinísticos.

Um projeto de ML pode dar errado por várias razões, como uma má escolha de um algoritmo e/ou ao treinamento com dados ruins.

Vamos ver alguns exemplos aqui:

1. Quantidade insuficiente de dados de treinamento. Os algoritmos de ML precisam de uma grande quantidade de dados para praticar os cálculos estatísticos e funcionar corretamente. Mesmo para problemas simples, os modelos normalmente precisarão de milhares de exemplos. Um problema mais complexo, como classificação de imagens ou reconhecimento de fala, exigirá milhões de exemplos. Provavelmente vale mais a pena investir no desenvolvimento do corpus de dados que no desenvolvimento do algoritmo. Entretanto, devemos ressaltar que ainda são comuns, em muitos problemas, que não tenhamos muitos dados de treinamento. Nesse caso, devemos colocar mais esforço no algoritmo de aprendizagem.

2. Dados de treinamento não representativos. Para que o modelo seja bem generalizado, seus dados de treinamento devem ser representativos do que se espera ver na produção. Se os dados de treinamento não forem representativos dos dados de produção ou forem diferentes, isso é conhecido como “não representatividade” de dados. Essa “não representatividade” de dados ocorre quando você tem grandes dados de treinamento, mas eles não representam o que o modelo verá na produção. Isso pode ocorrer devido ao processo de escolha da amostragem, ou porque a amostra é muito pequena, e, portanto os dados não serão representativos. Ou pode ser o viés de amostragem, que consiste em amostras grandes, mas o método de coleta de dados para a amostragem foi tendencioso.

Como regra geral, os dados de validação e teste devem ser tão representativos quanto possível dos dados que serão vistos na produção. No entanto, é sempre difícil coletar grandes quantidades, por isso não estará disponível em seu conjunto de treinamento. Após treinar o modelo, se o desempenho for decepcionante no conjunto de validação, provavelmente será por overfitting (o modelo está superajustado aos dados de treinamento) ou é devido a uma “não representatividade” entre os dados de treinamento e de validação.

3. Dados de baixa qualidade. Uma vez que os modelos de aprendizagem usarão os dados para aprender o padrão estatístico deles, é fundamental que os dados sejam de boa qualidade. Ter dados de treinamento cheios de valores discrepantes, erros, ruídos e dados ausentes diminuirá a capacidade do modelo de aprender com os dados e, então, o vai funcionar modelo mal em novos dados. É por isso que a limpeza de dados é considerada uma das etapas mais importantes do fluxo de ML, pois garante que os dados para treinar o modelo sejam válidos.

4. Features irrelevantes. lembre-se que se “entra lixo, sai lixo”, o seu modelo de ML só será capaz de aprender se os dados contiverem features relevantes. O processo de criação de features relevantes e remoção de features irrelevantes é conhecido como “feature engineering”.

Este processo envolve: (a) Seleção de features: selecione as features mais relevantes para treinar entre as features existentes. e (b) Extração de features: Combinar features existentes para produzir uma que seja mais útil.

5. Overfitting dos dados de treinamento. Overfitting significa que o modelo está indo bem nos dados de treinamento, mas não generaliza bem nos dados de teste/validação. O overfitting acontece quando o modelo é muito complexo em relação ao tamanho dos dados e sua qualidade, o que resultará no aprendizado mais sobre o padrão no ruído dos dados ou padrões muito específicos nos dados que o modelo não será capaz de generalizar para novas instâncias.

O que fazer? (a) Simplifique o modelo usando um modelo mais simples, diminuindo o número de features ou usando parâmetros de regularização. (b) Colete dados de treinamento mais representativos. © Reduza o ruído nos dados de treinamento usando técnicas de limpeza de dados. (d) Diminua a “não representatividade” de dados usando técnicas de pré-processamento de dados.

6. Underfitting dos dados de treinamento. Underfitting é o oposto de overfitting, ou seja, quando o modelo é muito simples para aprender qualquer um dos padrões nos dados de treinamento. O que fazer? (a) Selecione um modelo mais complexo com mais parâmetros. (b) Reduza o parâmetro de regularização se o estiver usando. © Adicione features melhores ao algoritmo de aprendizagem usando “feature enginnering”.

Após a ideação, realize pesquisas e desenvolva uma PoC (prova de conceito). Para uma pesquisa e desenvolvimento adequado, itere rapidamente e use o hardware apropriado. Dependendo do volume de dados a ser processado e do tipo de algoritmos a ser usado, talvez você precise de hardware especializado. Observe que muitas vezes serão tomadas decisões diferentes se a velocidade for mais importante que a precisão e vice-versa. Como sugestão, comece otimizando a velocidade em detrimento da qualidade. É melhor colocar em produção uma versão inicial do modelo gerado no ambiente de pesquisa e, em seguida, solicitar feedback dos usuários no dia a dia, do que esperar até que o modelo de pesquisa seja perfeito. Melhor passar um mês para obter um modelo fraco e depois iterar para torná-lo ótimo, do que ficar refinando e refinando o modelo, sem iteração com os usuários. Muitos cientistas de dados resistem ao lançamento de modelos que não são “bons o suficiente”. Supere esse obstáculo desenvolvendo uma cultura na qual a dinâmica do desenvolvimento do sistema ​​seja plenamente compreendida e que os resultados precoces e de baixa qualidade fazem parte da técnica adotada. Durante a preparação do modelo e depois, em produção, garanta o backup regular dos dados para impedir que alguma exclusão acidental ou alterações indevidas quebrem seus modelos de ML.

Até chegar à PoC, considere usar prototipagem contínua e iterativa, que envolverá os usuários e permite que outros aplicativos chamem o modelo, servindo como ponto de partida para as melhorias. Durante esta fase, é fundamental solicitar feedback de pessoas de fora da equipe de ML ​​e do pessoal de produção. Use o modelo ágil, pois assim como no desenvolvimento de sistemas que não são de IA, as mudanças frequentes e iterativas oferecem flexibilidade para lidar com as dificuldades à medida que surgem.

Agora que você já tem uma PoC pronta para liberação no ambiente de produção, não esqueça que, embora imperfeito, ele conterá todos os elementos necessários para resolver o problema, como interfaces da web, APIs, controle de armazenamento e de versão.

Ter um modelo em produção não significa que ele precisa ser visível publicamente. Pense em uma fase piloto, onde ele deve ser exposto a dados ativos, para que sua equipe possa fazer refinamentos até atender aos requisitos que serão disponibilizados para uso aberto. Com os dados ativos, você pode realizar testes mais exaustivos de execução e fornecer à sua equipe de IA feedback sobre o que está funcionando bem e o que não está. Nesse estágio, priorize o estabelecimento de um processo de liberação controlada e gradual. Você também deve monitorar o desempenho e a escalabilidade do seu sistema. Planeje ciclos contínuos de melhoria, investigue e implemente refinamentos do modelo e, alterações das interfaces. Novos modelos devem ser comprovadamente superiores aos que substituem. Teste todas as alterações antes que as atualizações sejam lançadas no ambiente de produção. Esses ciclos continuarão por toda a vida útil do sistema.

Ao planejar o projeto de implementação, valide onde seu sistema será executado: no seu data center ou na nuvem? A opção pelo seu data center, on premise, geralmente é tomada quando seus dados são altamente sensíveis e você precisa mantê-los sob seu controle direto. Normalmente, isso é possível apenas para empresas que já possuem sua própria infraestrutura de hardware. Essa pode ser uma opção válida se o volume de solicitações de gerenciamento for conhecido e relativamente estável. No entanto, todo o novo hardware adicional deve ser adquirido e provisionado, o que limita a escalabilidade. A opção de usar nuvem pode ser vantajoso para a maioria das empresas. Não esqueça que você pagará para transferir e receber dados, mas vai evitar o custo da aquisição de hardware e de uma equipe para gerenciar o ambiente. Como transferir grandes volumes de dados é custoso, se você já estiver usando ambientes de nuvem como os da Amazon, Google, IBM ou Microsoft, para suas aplicações tradicionais, é mais atrativo continuar com ele para seus projetos de IA.

Para comprovação de que as novas versões do sistema de ML são eficazes e melhores que as versões anteriores, teste seu sistema atual em vários estágios. Durante o treinamento: enquanto seu modelo está sendo treinado, teste-o constantemente com um subconjunto de dados de treinamento para validar sua precisão. Os resultados não representam totalmente o desempenho do modelo, porque os dados do teste randomizados irão influenciar o modelo. Como resultado, esse teste provavelmente exagerará a precisão do modelo. Não considere este número quando for vender a ideia para seu board!

Na validação, reserve uma parte dos seus dados de treinamento para isso. Este conjunto de testes, conhecido como conjunto de validação, não deve ser usado para treinamento. Por conseguinte, as previsões que o seu sistema de ML faz a partir do conjunto de validação representam melhor as previsões que ele fará no mundo real. A precisão no estágio da validação geralmente é menor que a precisão obtida durante o treinamento. Atente para que o seu conjunto de dados represente bem os dados do mundo real, pois, caso contrário, pode gerar uma precisão superestimada. Muita atenção com os dados que podem embutir viés nos algoritmos.

Após a criação do seu modelo, teste-o com dados ativos para obter uma medida de precisão mais apropriada. De maneira geral essa precisão é menor que a obtida no teste e deve ser refinada continuamente.

Existem três medidas de “precisão” comumente usadas na IA: recall, precisão e exatidão. Como exemplo, vamos pensar um sistema de ML que determine se uma determinada fruta é ‘boa’ ou ‘ruim’ com base em análises de imagens desta fruta. Existem quatro resultados possíveis:

1. Verdadeiro positivo: a fruta é boa — e a IA prediz ‘boa’.

2. Verdadeiro negativo: a fruta é ruim — e a IA prediz ‘ruim’.

3. Falso positivo: a fruta é ruim — mas a IA prediz ‘bom’.

4. Falso negativo: a fruta é boa — mas a IA prediz ‘ruim’.

Para medir quão preciso é o sistema, use simultaneamente as três medidas, recall, precisão e exatidão.

Recall: Que proporção de frutas encontrei corretamente? É o número de frutas boas identificadas corretamente, dividido pelo número total de frutas boas identificadas, corretamente ou não.

Precisão: que proporção de frutas que eu disse são boas, eu acertei? É o número de frutas boas identificadas corretamente dividido pelo número total de frutas rotuladas como boas (identificadas corretamente ou não).

Acurácia: que proporção de frutas rotulei corretamente? É o número de frutas corretamente identificadas como boas ou ruins, dividido pelo número total de frutas.

Equilibrar precisão e recall pode ser difícil. À medida que você ajusta seu sistema para um recall mais alto, ou seja, menos falsos negativos-, você aumenta os falsos positivos e vice-versa. A opção por minimizar falsos negativos ou falsos positivos, dependerá do problema que você está resolvendo e do seu domínio. Se estiver desenvolvendo uma solução de marketing, convém minimizar os falsos positivos. Para evitar o constrangimento de mostrar um logotipo incorreto, é menos mal perder algumas oportunidades de marketing. Mas, se estiver executando diagnósticos médicos, convém minimizar os falsos negativos para evitar o erro de um diagnóstico.

E finalmente, lembre-se que um sistema de ML não cessa de evoluir nunca. Infelizmente na hora que você coloca seu sistema de ML em produção ele começa a degradar! Para manter a assertividade do sistema de ML, teste regularmente os resultados com dados ativos, para garantir que os resultados continuem atendendo seus critérios de aceitação. Separe budget para futuras atualizações e reciclagem, e monitore sistematicamente a degradação do desempenho. À medida que sua empresa cresce ou muda o foco, os dados (incluindo dados de séries temporais e características do produto) evoluirão e se expandirão. A reciclagem sistemática de seus sistemas deve ser um componente de sua estratégia de IA. Surgem novos algoritmos e as técnicas de ML que usamos hoje podem se tornar obsoletas em poucos anos.