Algumas estimativas apontam que em torno de 80% dos projetos de machine learning (ML) não são colocados em produção, não saindo da fase de protótipos e experimentações. E dos que entram em produção, muitos acabam sendo desativados, por várias razões como baixo desempenho operacional ou por não alcançarem um nível adequado de assertividade. Outros não avançam por acabarem não se justificando como vantagem competitiva para a empresa.
Um projeto de ML não é algo que se começa apenas a partir de uma inspiração genial. Ele precisa ter uma clara oportunidade de negócio para a empresa. Afinal serão comprometidos tempo, energia, dinheiro e talentos, daqueles escassos profissionais que conseguem realmente desenvolver soluções adequadas de ML.
Para ter sucesso em projetos dessa natureza, portanto, é necessário comprometimento e engajamento dos executivos e gestores, e a criação de uma equipe de profissionais preparados. Uma equipe para desenvolver projetos de ML não é constituída apenas por cientistas de dados e engenheiros de ML.
Um projeto de ML faz parte de uma solução para um problema de negócio e isso envolve integração com outros sistemas, acesso a dados validados e limpos, interfaces adequados, entendimento do negócio e assim por diante. Uma equipe multidisciplinar. Impossível ter um humano que faça tudo isso bem.
A ideia romântica de um grupo de cientistas de dados passando o dia todo “bolando” algoritmos e modelos matemáticos é uma fantasia. Lembram-se de um artigo publicado pela HBR em 2012, “Data Scientist: The Sexiest Job of the 21st Century”? Pois é, na prática, uns 80% do tempo de um projeto de ML envolve captura e limpeza de dados, que não é necessariamente tão sexy assim.
Para minimizar problemas, a contratação e retenção e talentos deve ser feita com atenção redobrada. Como proliferam cursos rápidos de “seja em cientista de dados em 30 dias”, muita gente faz um ou dois desses cursos e se autointitula “data scientist”. Valide a experiência prática e não acredite apenas no que está escrito no Linkedin.
Para desenvolver uma equipe interna de IA, você não só deve atrair, estruturar, gerenciar e reter talentos de IA, mas também selecionar a infraestrutura tecnológica como frameworks, linguagens de desenvolvimento, estruturas e técnicas que você adotar; aprender a realizar coleta e limpeza de dados; aprender como produzir IA no mundo real e não apenas em laboratórios de demonstração; e garantir conformidade com os padrões regulatórios e éticos.
Pode levar meses para criar uma equipe interna que seja produtiva e, potencialmente, mais tempo para coletar os dados necessários e desenvolver soluções personalizadas que entreguem os resultados nos padrões exigidos. Escassez de talentos é um fato e você vai ter de lidar com esta realidade.
Escassez de talentos é um fato e você vai ter de lidar com esta realidade
Uma vez contratados, não coloque seus cientistas de dados/engenheiros de ML em locais isolados do negócio. Já vi em algumas empresas espaços denominados “AI Labs” e lá dentro alguns profissionais fazendo experimentações desconectados das necessidades da empresa.
É interessante um “AI Lab” quando você é uma Amazon, Facebook ou Google, mas de maneira geral você não quer um grupo de cientistas pesquisadores. Você quer usar ML para resolver uma dor do negócio. Não fazer ciência.
Busque soluções simples. Começar com projetos “moon shot” (aqueles projetos ambiciosos demais) e buscar algoritmos complexos e sofisticados nem sempre é a melhor solução. Modelos simples, mas eficazes, podem resolver muito bem o problema e isso que a empresa está buscando: soluções práticas e rápidas.
Não desenvolva projetos de longa duração sem entregáveis intermediários. Use as técnicas de desenvolvimento ágil, adotando squads e “scrum teams” e não adote o “water fall” para projetos de ML. O sucesso dos projetos de ML deve aparecer nos resultados do negócio.
O uso de ML-as-a-Service e APIs de terceiros aceleram o desenvolvimento. Esses serviços cumprem funções específicas e limitadas, mas dependendo das suas necessidades podem fornecer resultados quase imediatos, claro não esquecendo que algoritmos treinados com as bases de dados dos provedores, precisam aprender com os seus dados e o ciclo de treinamento não pode ser ignorado.
Os serviços de MLaaS resolvem problemas de analítica preditiva e as APIs atuam mais focadas nos domínios da visão e de processamento de linguagem. As APIs de linguagem incluem transcrição, tradução e extração de tópicos. A questão é que algumas não trabalham muito bem com as nuances e regionalismos da língua portuguesa, e seus níveis de acerto estão abaixo dos obtidos com a língua inglesa.
Já as APIs de visão incluem reconhecimento de objetos, detecção de cenas e identificação de logotipos. Como objetos são iguais no mundo inteiro, ou seja, um gato é um gato aqui e na China, essas APIs tendem a funcionar melhor que as de processamento de linguagem.
Além disso, as APIs não permitem ajustar os dados ou modelos de treinamento nos quais os serviços se baseiam. Se você deseja desenvolver serviços com base em dados de treinamento exclusivos ou usar algoritmos complementares para obter melhores resultados, as APIs poderão se mostrar inadequadas.
Essas APIs foram projetadas para adoção em massa e, por isso, tendem a ser genéricas e não têm profundidade e especificidade de domínios. Não esqueça que estas APIs também estão disponíveis para seus concorrentes. Não será possível criar vantagem competitiva duradoura se você depender apenas do uso de APIs de terceiros e o uso delas cria uma dependência sobre a qual você não tem controle.
Os serviços de MLaaS são um passo além das APIs. Permitem fazer upload de seus dados, configurar, treinar e refinar seus próprios modelos de IA usando uma interface simples. Esses serviços abstraem muito das dificuldades do desenvolvimento de IA e permitem que você desenvolva uma solução personalizada mais rapidamente.
Claro, que nem tudo é maravilhoso e você tem que discutir alguns aspectos como os que o uso de serviços de MLaaS implicam em menos controle do que o desenvolvimento interno e o acesso à modelos complementares será limitado, reduzindo a personalização e o refinamento.
Não ignore seus requisitos de privacidade. O uso de serviços de MLaaS envolve passar seus dados a terceiros. Isso está de acordo com suas políticas de governança de dados? Você sabe se este terceiro retém uma cópia dos seus dados e os utiliza para outros fins? Como nas APIs, você cria uma relação de dependência.
Pode ser muito caro migrar para outro provedor de MLaaS, dadas as dependências e os custos de transferência de dados. Analise também questões de propriedade intelectual. Os serviços MLaaS oferecem uma maneira rápida e flexível de desenvolver soluções sob medida, a um custo menor do que a criação de uma equipe interna.
Podem ser alternativas ideais para prototipagem e complementares para muitos projetos. Mas, se você precisar de mais controle, flexibilidade, autonomia e propriedade intelectual, estes serviços não serão a solução.
Tenha prioridades bem definidas e não esqueça que projetos de ML são diferentes dos projetos que a empresa está acostumada a desenvolver. Os desafios iniciais são que se você não tem experiência com projetos de IA terá alguma dificuldade de mensurar prazos e custos. Por exemplo, negocie claramente qual a precisão (níveis de acerto) que os modelos devem atender.
Existem dados de treinamento rotulados e limpos e em caso contrário, qual será o esforço para isso? 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%
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.
Provavelmente para a maioria das empresas, uma abordagem "híbrida" para as iniciativas de ML será a ideal. Use APIs de terceiros para resolver uma versão inicial e mais simples de soluções de IA. Passe para MLaaS para criar soluções mais refinadas, e comece a montar uma equipe interna para projetos mais evoluídos e sofisticados.
Contrate também “ML Product Managers”. Aliás, deve ser uma das primeiras contratações. A função de “ML PM” tem dois lados: é orientada ao negócio de um lado e, do outro, compreende as características como o fluxo e complexidades do desenvolvimento de um projeto de ML.
É alguém que interage com o usuário na linguagem dele e consegue conversar com os cientistas de dados em questões relativas às características técnicas do projeto. É essencial essa função para ter uma relação íntima e produtiva com os usuários, fazendo com as suas expectativas sejam alcançadas e eventuais desvios de rota corrigidos à tempo.
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 ML 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 estão substituindo.
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.Um sistema de ML não pode ser deixado de lado ao entrar produção. Ele precisa ser continuamente ajustado e refinado.
Tomemos, por exemplo, um serviço baseado em algoritmo de ML, que prevê se há um semáforo em uma imagem obtida por um sensor de imagem em um veículo. Esse serviço funcionou bem na fase de testes e foi colocado em produção. Mas, de repente, começou a retornar respostas erradas: prevê semáforos quando eles não estão lá e vice-versa. "O que aconteceu?". Uma possível razão é que começou a chover e o modelo de ML não foi treinado para analisar imagens tiradas sob chuva.
Outra explicação pode ser que um desenvolvedor implantou um novo código para compactar os arquivos de imagem e com isso economizou milhões em custos de armazenamento, mas o modelo de ML não foi treinado para analisar imagens compactadas. Se você não monitorar de perto, a primeira pessoa a notar a falha será o seu cliente, e isso é, no mínimo, bem desagradável.
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 e é uma alternativa cada vez menos adotada. É 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
A opção de usar nuvem pode ser vantajoso para a maioria das empresas. Se você tiver um ambiente híbrido, não esqueça que você pagará para transferir e receber dados, entre seu data center e a nuvem, 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 ML.
Para comprovação de que as novas versões de ML são eficazes e melhores que as versões anteriores, teste seu sistema 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 IA 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. Cuidado 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 esta precisão é menor que a obtida no teste e deve ser refinada continuamente.
Existem três medidas de “precisão” comumente usadas em ML: recall, precisão e exatidão. Como exemplo, vamos pensar um sistema de ML que determina se uma determinada fruta é 'boa' ou 'ruim' com base em análises de imagens desta fruta. Existem quatro resultados possíveis:
- Verdadeiro positivo: a fruta é boa - e o algoritmo prediz 'boa'.
- Verdadeiro negativo: a fruta é ruim - e o algoritmo prediz 'ruim'.
- Falso positivo: a fruta é ruim - mas o algoritmo prediz 'bom'.
- Falso negativo: a fruta é boa - mas o algoritmo 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.
À medida que sua empresa cresce ou muda o foco, os dados evoluirão e se expandirão
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 IA não cessa de evoluir nunca. Infelizmente na hora que você coloca um 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 ML. Surgem novos algoritmos e as técnicas de ML que usamos hoje podem se tornar obsoletas em poucos anos.
