Venho observando algo preocupante. Percebo que a maioria das provas de conceito (PoCs) de machine learning (ML) que saem bombasticamente na mídia e em eventos não chegam a entrar realmente no estágio de produção.
Com base na minha experiência, acredito que menos de 20% dos projetos de ML chegam à produção. O resultado é que apesar de resultados impressionantes nos laboratórios, apenas algumas empresas desenvolveram os recursos de ML em escala para trazer um valor agregado real para os seus negócios.
O que vejo são chatbots, a maioria dos quais nem é minimamente “inteligente”. Não que o chatbot não seja interessante para o negócio, mas me parece apenas um arranhão na potencialidade de exploração da IA.
As PoCs são geralmente realizadas com algoritmos relativamente simples, usando os dados de treinamento que estejam disponíveis ou rotulados internamente. O objetivo principal é mostrar que o algoritmo pode ser treinado para lidar com um caso de uso específico, com uma quantidade pequena de dados de treinamento. Caso tenha sucesso, o projeto segue para a fase de produção. Uma PoC bem-sucedida não é garantia de que a solução será escalonada, mas é um bom começo.
(Uma sugestão: na minha opinião, as organizações devem investir em várias PoCs antes de irem para produção, porque precisam aprender sobre potencial de ML, melhorar sua cultura de dados e se educar em projetos de ML e suas características. Sair do primeiro PoC e entrar direto em um problema complexo para resolver por meio de ML é uma excelente maneira de falhar. Não subestime a curva de aprendizado em ML.)
O estágio de produção representa um nível muito mais alto de complexidade para os projetos de IA. Agora, você não está mais tentando provar que a solução funciona, mas que ela pode se integrar à infraestrutura de tecnologia e processos da empresa e ter um bom desempenho em condições reais.
Vamos imaginar, por exemplo, que seu PoC está usando dados pré-rotulados e obteve uma precisão de 70%. Mas você pode considerar colocar um sistema de ML em produção e expor sua marca com uma solução com apenas 70% de precisão?
Na maioria das vezes, os gestores se recusam por motivos óbvios. O risco de 30% de respostas erradas é muto alto. Portanto, para sair da PoC e ir para produção, você precisa apresentar um plano sobre como alcançar um nível mais alto de precisão. Ou sejam, mais dados de treinamento. Os gestores tendem a acreditar que, se atingirmos uma precisão de 70% em dois meses, precisaremos de apenas mais algumas semanas para alcançar algo aceitável (cerca de 90%-95%).
Isso é um erro porque na verdade os modelos têm um apetite insaciável por dados de treinamento e evoluir de 70% para 90% de precisão vai exigir muitos mais tempo e dados de treinamento do que os 70% originais. As necessidades tornam-se exponenciais e, obviamente, mais tempo significa mais dinheiro para financiar o projeto.
Muitas vezes, a etapa de produção tende a ser subestimada no início de um projeto de machine learning
Muitas vezes, a etapa de produção tende a ser subestimada no início de um projeto de ML. Mas, para ter sucesso, os projetos de ML precisam pensar grande desde o início, ainda na PoC, levando em consideração a estrutura tecnológica da empresa, o maior volume de dados, as demandas de integração com outros sistemas e os fluxos de trabalho internos.
Mover-se para o estágio final de integração, em que os sistemas ML serão integrados às várias linhas de negócios e talvez disponibilizada para o usuário/cliente, exige infraestrutura em escala corporativa, segurança, privacidade, aderência aos princípios éticos da corporação, e suporte técnico.
É necessário também presumir que novos e inesperados problemas surgirão conforme nos aproximamos da versão final da solução. Por exemplo, se durante a PoC, o algoritmo demonstrou boa capacidade de reconhecer rostos fotografados na mesma luz, na mesma distância e ângulo, ou seja, um ambiente de teste controlado.
No estágio de produção, o algoritmo vai ser exposto a muitas variações de iluminação, distância, ângulo, tom de pele, gênero e muito mais. Isso significa que o volume de dados a serem usados no processo de desenvolvimento e treinamento será muito maior que na PoC. E vem a pergunta: esses dados estão disponíveis?
Um fato muito comum é subestimar o custo de construção do sistema de ML em escala real. Há muito mais investimento e demanda de recursos para colocar um protótipo em produção. É necessário ter budget para isso. Colocar em produção implica em saber com que frequência as previsões devem ser geradas, se as previsões devem ser geradas para uma amostra de dados de cada vez ou para um lote de amostras, o número de aplicativos e sistemas que acessarão o modelo e os requisitos de latência desses aplicativos.
Se estas demandas não forem definidas no início do projeto, podemos descobrir depois de um grande esforço que o modelo funciona muito bem quando na PoC, mas a sua latência não atende à demanda dos usuários. É um modelo inútil.
As questões de desempenho estão relacionadas com a complexidade do modelo e com a sua demanda. O modelo será usado em processamentos batch ou o acesso será online, quase tempo real? A demanda por capacidade computacional e os recursos tecnológicos envolvidos devem ser cuidadosamente analisados e validados para garantir que os requisitos de latência dos usuários sejam atendidos.
Um acesso via um app que demore minutos é totalmente inviável. A reposta deve ser instantânea. Os usuários hoje não aceitam demoras nas suas solicitações aos apps.
À medida que você for obtendo experiência com projetos de ML vai aprendendo que os prazos são muito mais incertos do que os que você está acostumado, como no desenvolvimento de software tradicional. Os sistemas de ML não são desenvolvidos de forma linear, codificados de uma vez, testados e implantados.
Normalmente, são necessários vários ciclos de treinamento para identificar uma combinação adequada de dados, arquitetura de rede e 'hiperparâmetros' (as variáveis que definem como um sistema aprende). Essa dinâmica varia de acordo com o domínio e a natureza do problema e os dados disponíveis.
Pode ser, portanto, um desafio prever ou automatizar iniciativas de IA, a menos que sejam muito similares aos projetos que você já realizou anteriormente. Além disso, precisamos ter confiança que não teremos anomalias.
Diferentemente da computação programática em que o software responde diretamente ao desenvolvedor que coloca todas as instruções em linhas de código e caso a resposta não seja correta, você depura e conserta o código, o sistema de ML interpreta dados com seus algoritmos e daí toma suas decisões.
Nos algoritmos não supervisionados, não sabemos se a resposta está certa ou errada, pois a resposta pode ser algo que nós humanos não havíamos percebido e a máquina identificou como um padrão e gerou sua decisão a partir desta constatação. A máquina pode gerar resultados surpreendentes, que nós jamais imaginaríamos.
O treinamento dos algoritmos pode demandar muito tempo e a implementação do sistema pode demandar grandes recursos computacionais
Um sistema de ML colocado em produção é diferente de um ERP tradicional. Neste último, assim que ele se torna operacional, você o deixa quieto, sem tocar mais nele. “Não mexa, se mexer estraga”! Já em ML, depois que um modelo é implantado, seu comportamento deve ser monitorado. Espera-se naturalmente que o desempenho preditivo de um modelo diminua com o tempo à medida que o ambiente muda.
Esse fenômeno, conhecido como “efeito deriva”, ocorre quando as distribuições dos recursos de entrada se afastam da distribuição na qual o modelo foi originalmente treinado. Ou sejam, os dados que foram usados para treinar o modelo são agora diferentes do contexto real dos dados que entram para o modelo operar.
Uma vez detectado este desvio, ele pode ser reajustado treinando novamente os modelos. Mas detectar a deriva através do monitoramento é difícil, às vezes só sendo observado após dias, semanas ou meses de sua entrada em operação.
Uma estratégia para esse monitoramento é usar uma métrica de um modelo implantado que possa ser medido ao longo do tempo. Por exemplo, medir a distribuição de saída pode ser útil para detectar desvios, mesmo quando a saída real não está disponível em tempo hábil. A distribuição observada pode ser comparada à distribuição de saída do treinamento, e os alertas podem notificar os responsáveis pelo modelo quando esses valores divergirem.
Os projetos de ML precisam ser apoiados pela administração e sem apetite por investimentos de longo prazo, os sistemas de ML nunca alcançarão qualquer nível significativo de escala ou utilidade. É preciso tempo e paciência para desenvolver e gerar valor com esses projetos.
Em resumo, antes de investir tempo e dinheiro em sistemas de ML, você precisa de uma estratégia para orientar sua utilização. Sem uma estratégia de IA, os sistemas de ML se tornarão um custo adicional que não fornecerá um adequado retorno do investimento.
As iniciativas de ML não devem ser feitas pelo modismo, impulsionado pelo “efeito manada” (“todos estão fazendo”) mas com objetivos bem claros para resolução de problemas de negócio. Esteja atento às suas limitações e separe os mitos da realidade.
Não existem soluções “plug-and-play” que magicamente funcionam do nada, sem uma, às vezes, longa e exaustiva fase de treinamento do algoritmo; não esqueça que nem tudo pode e deve ser resolvido através de sistemas de ML; estude e se aprofunde nos conceitos, potencialidades e limitações dos algoritmos de ML; priorize seus projetos de ML baseados no valor a ser gerado e na sua viabilidade (existem dados para possibilitar treinamento do algoritmo?); assegure-se que você tem equipe preparada (“ML engineers” não são colhidos em árvores); e reserve budget adequado para seu desenvolvimento e contínuo refinamento.
O treinamento dos algoritmos pode demandar muito tempo e a implementação do sistema pode demandar grandes recursos computacionais. Recomendo, para maior aprofundamento no assunto, a leitura do paper “Challenges in Deploying Machine Learning: a Survey of Case Studies”. No mais, boa sorte e colha bons resultados.
Cezar Taurion é VP de Inovação da CiaTécnica Consulting, e Partner/Head de Digital Transformation da Kick Corporate Ventures. Membro do conselho de inovação de diversas empresas e mentor e investidor em startups de IA. É autor de nove livros que abordam assuntos como Transformação Digital, Inovação, Big Data e Tecnologias Emergentes. Professor convidado da Fundação Dom Cabral, PUC-RJ e PUC-RS