Por Cezar Taurion: projetos de IA e seus desafios

Depois de vários projetos de IA e conversando com muitos executivos, percebi que muitas PoCs não chegam ao estágio de produção. Nos últimos anos muitas empresas começaram a aplicar soluções de IA com resultados positivos, mas apenas algumas poucas conseguiram realmente desenvolver aplicações em escala adequada para trazer valor tangível para a empresa. Acredito que menos de 20% dos projetos de IA (e aqui vou considerar apenas os de Machine Learning – ML) chegam realmente a entrar no processo contínuo de operação, apesar de vermos resultados impressionantes nos protótipos desenvolvidos nos labs.

De maneira geral, as PoCs são construídas com algoritmos relativamente simples, usando os dados de treinamento que estejam disponíveis, de bases internas ou públicas de fácil acesso. O seu 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 a PoC tenha sucesso, o projeto segue para a fase de desenvolvimento, para posteriormente, entrar produção. Entretanto, uma PoC bem-sucedida não é garantia de que a solução será escalonada, é apenas um bom começo!

Na minha opinião, as organizações devem investir em várias PoCs antes de mergulharem a fundo em projetos mais sofisticados, porque precisam aprender sobre potencial de ML, suas limitações, melhorar sua cultura de dados e se educar nas características dos projetos de ML.   Sair do primeiro POC e entrar direto em um problema complexo que será resolvido por uma solução de ML, é uma excelente maneira de falhar. Não subestime a curva de aprendizado em ML!

Projetos de IA: o desenvolvimento é um processo de experimentação

Desenvolver projetos de IA apresenta alguns desafios que o desenvolvimento de software tradicional não enfrenta. Uma diferença fundamental é que o processo de desenvolvimento de uma solução de IA é bem mais próximo do processo da descoberta de moléculas desenvolvido pelo setor farmacêutico do que da engenharia de software. Isso ocorre porque o desenvolvimento de IA é um processo de experimentação, muito parecido com a química ou a física. O trabalho da equipe de desenvolvimento de projetos de IA é ajustar um modelo estatístico a um conjunto de dados, testar o desempenho do modelo em novos dados e repetir o processo.

O desenvolvimento de software, por outro lado, é um processo típico de construção e engenharia. Depois que a especificação e a arquitetura geral de um aplicativo são definidas, novos recursos e funcionalidades podem ser adicionados de forma incremental, como uma linha de código, biblioteca ou chamada de API, até que a visão completa tome forma. Esse processo está em grande parte sob o controle do desenvolvedor, e a complexidade do sistema resultante pode frequentemente ser controlada com o uso de práticas padronizadas da ciência da computação, como modularização, instrumentação e virtualização.

Já nos projetos de IA, ao contrário da engenharia de software, muito pouco está no controle do desenvolvedor. A complexidade do sistema é inerente aos próprios dados de treinamento. E na maioria das vezes, os dados são frequentemente confusos, imprevisíveis e altamente entrópicos. Pior ainda, o código escrito pelo desenvolvedor não muda diretamente o comportamento do programa.

Sistemas de ML

Os sistemas de ML, portanto, 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. Portanto, pode ser 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 onde 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, a situação é mais complicada, pois não sabemos se a resposta está certa ou errada, pois essa 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.

Assim, chegar ao estágio de produção representa um nível muito mais alto de complexidade para os projetos de IA do que para os projetos de software determinísticos as quais a empresa está acostumada. Nessa fase, 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.

Por exemplo, vamos imaginar que sua PoC está usando dados pré-rotulados e obteve uma precisão de 75%. Mas, você pode considerar colocar um sistema de ML em produção e expor sua marca com uma solução com apenas 75% de precisão? Na maioria das vezes, os gestores se recusam por motivos óbvios. O risco de 25% de respostas erradas pode ser considerado muito alto. Portanto, para sair da PoC e ir para produção, você precisa apresentar um planejamento sobre como alcançar um nível mais alto de precisão.

Muitos gestores tendem, simplisticamente, a acreditar que, se conseguimos atingir uma assertividade de 75% 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 75% para 90% de assertividade vai exigir muito mais tempo, volume e variedade de dados de treinamento do que os 75% originais. As necessidades tornam-se exponenciais e, obviamente, mais tempo significa mais dinheiro para financiar o projeto.

Também é muito comum vermos que a etapa de produção tende a ser subestimada no início de um projeto de ML. Para ter chances de sucesso, os projetos de ML precisam pensar grande desde o início, mesmo ainda na PoC, levando em consideração a estrutura tecnológica da empresa, o maior volume de dados, as demandas de desempenho e integração com outros sistemas a e os fluxos de trabalho internos.

Mover-se para o estágio final de integração, onde 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.

Também é necessário 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 de reconhecimento facial demonstrou boa capacidade de reconhecer rostos fotografados na mesma luz, na mesma distância e ângulo, ou seja, em 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 e variedade dos dados que serão usados no processo de desenvolvimento e treinamento será muito maior que na PoC. E vem a pergunta: esses dados existem e estão disponíveis?

Imaginemos que a PoC usou uma base de dados pública, de fonte européia, com maioria de rostos de homens caucasianos. O sistema, a ser exposto a rostos femininos de outras etnias e cor de pele, não terá o mesmo nível de assertividade conseguida na fase de prototipação.

As questões de desempenho do sistema de ML em produção 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 em tempo real, por dezenas de milhares de usuários via smartphones? 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 resposta deve ser instantânea. Os usuários hoje não aceitam demoras nas suas solicitações aos apps.

Um sistema de ML colocado em produção é diferente de um software como um ERP tradicional. Neste último, assim que ele se torna operacional, você o deixa quieto, sem tocar mais nele. Já em um sistema de ML, depois que um modelo é implantado, seu comportamento deve ser monitorado continuamente. Espera-se naturalmente que o desempenho preditivo de um modelo diminua com o tempo à medida que o ambiente muda.

Efeito deriva

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 e refinando novamente os modelos. Mas detectar a deriva através do monitoramento é difícil, às vezes a anomalia só é identificada dias, semanas ou meses após sua entrada em operação. Uma possível 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 se não houver apetite por investimentos de longo prazo, 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 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 que não possam ser resolvidas de outra forma. 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. Estude e se aprofunde nos conceitos, potencialidades e limitações dos algoritmos de ML, priorize seus projetos baseados no valor a ser gerado e na sua viabilidade (existem dados para possibilitar treinamento do algoritmo?) e assegure-se que você tem equipe preparada (“ML engineers” não são colhidos em árvores). No mais, boa sorte e colha bons resultados!

Cezar Taurion é Sócio da Kick Ventures e VP de Estratégia e Inovação na Cia Técnica, mentor e investidor em startups. Conheça sua trajetória e como ele se tornou um dos maiores nomes em Tecnologia da Informação no Brasil. Leia aqui