O tempo matou o meu modelo de ML!

Todos nós já ouvimos a estatística de que 90%, 88%, 87%, 85% ou alguma percentagem absurda de modelos de ML nunca chegam à produção. Para ser bem sincero, não faço ideia de como alguém calculou isso e estou tão perplexo quanto esta pessoa. Mas isso não vem ao caso. Idealmente, esse número importa muito menos do que o porquê muitas empresas lutam para obter valor de negócio a partir de Machine Learning- ainda!

Para entender isso, tivemos conversas de 1 hora com mais de 200 pessoas em sessões individuais para entender o fluxo de trabalho de construção de modelos de ML, que inclui – desde a definição de requisitos de negócio, a sua tradução em sprints, recolha de dados, construção de modelos, preparação para produção, implementação, retreinamento, testes A/B, depuração, monitorização, observabilidade etc., e fechar o ciclo de qualquer etapa para qualquer outra etapa nesta sequência. Isso inclui diversas perspetivas de líderes de negócio, líderes de engenharia, gestores de produto, cientistas de dados, Devops, engenheiros de dados e engenheiros de ML! Após estas conversas qualitativas, também realizámos um inquérito objetivo para ter uma noção mais ampla dos problemas predominantes, cujos resultados podem ser encontrados aqui.

Embora a Machine Learning aplicada seja um campo relativamente novo e existam problemas em praticamente todas as partes do pipeline, houve um tema unânime e proeminente que surgiu das nossas conversas-

O atraso de tempo em e entre cada etapa da construção e lançamento de modelos de ML, reduz a confiança e o moral das equipas de engenharia e liderança, matando os Modelos de ML!

No mundo do software, estamos acostumados a tomar decisões orientadas por dados. Queremos ver resultados rapidamente, executar testes A/B, justificar os custos e, se um projeto não gerar um ROI suficiente em um razoável tempo — somos ensinados a eliminá-lo. E tempo é algo que o ML consome muito! Isso é verdade para empresas em todo o espectro, embora por razões diferentes —

1. Startups em estágio inicial (da fase seed à Série C)
2. Gigantes tradicionais como Walgreens, Target, Siemens
3. Gigantes da tecnologia como Uber, Amazon, Netflix etc.

Vamos estudar isso em detalhes.

Startups em estágio inicial

Frequentemente, construir e implantar pipelines de Machine Learning exige um conjunto de habilidades variado —

1. Compreensão do caso de uso de negócio — tipicamente Gerentes de Produto
2. Pipelines de registro e processamento de dados — tipicamente Engenheiros de Dados
3. Experimentação e construção de modelos — tipicamente Cientistas de Dados
4. Criação de APIs de Inferência e implantação — tipicamente Engenheiros de ML
5. Escalonamento de modelos, staging, pipelines de produção — tipicamente equipe de DevOps
6. Frameworks de teste A/B, Monitoramento e Observabilidade, Pipelines de Retreinamento

Com muita frequência, as startups não têm recursos para contratar pessoas diferentes para preencher todo o espectro de habilidades. As startups ingenuamente acreditam que podem contratar 1-2 pessoas realmente inteligentes que já teriam passado por isso e podem resolver todos os problemas acima — mas não percebem que tais criaturas míticas não existem de fato fora dos sonhos do fundador!

No final, o cientista de dados ou engenheiro de ML contratado tenta seguir o ditado comum — “numa startup, faz-se o que for preciso para que as coisas aconteçam”. Mas a curva de aprendizado das tecnologias nesta área (que está mudando rapidamente) é muito acentuada e acaba levando muito tempo para aprender e implementar cada uma dessas diferentes partes. Naturalmente, os pipelines construídos por este novato muitas vezes não são à prova de falhas e começam a falhar em diferentes pontos, o que inicia uma sequência de projetos de remendo — uma razão clássica para o esgotamento dos recursos de engenharia! Neste ponto, o fundador frustrado toma uma decisão difícil — “Certo, ainda não estamos prontos para Machine Learning — vamos construir um sistema simples, fácil de manter, baseado em regras, que simplesmente funcione — de volta ao básico!”

Gigantes tradicionais como Walgreens e Target

Em grandes empresas, a razão pela qual os Modelos de ML acabam levando muito tempo é tanto organizacional (ou até mais) quanto técnica. Tipicamente, algum usuário de negócios — talvez de uma equipe de Sucesso do Cliente ou de Vendas — terminará uma chamada com um cliente e surgirá com uma ideia para um projeto de Machine Learning. Isso passa por traduções feitas por Gerentes de Produto, alocação de recursos e reuniões de planejamento de sprint antes de finalmente chegar às mãos de um Cientista de Dados. Vamos supor que essa ideia fosse uma das mais simples, onde a organização já tinha os dados para alimentar o modelo (por exemplo, fluxo de cliques do usuário).

O cientista de dados então constrói o modelo, mas não tem como obter feedback rápido do usuário de negócios porque—

1. O notebook é muito técnico para pessoas de negócios
2. Resultados armazenados em planilhas Excel não são interativos
3. Cientistas de dados tipicamente não possuem as habilidades para hospedar rapidamente o modelo e expor uma API.

Sem o feedback do usuário de negócios, como o CD sabe—

• O modelo deles resolve o problema que o usuário de negócios pediu ou a intenção se perdeu na tradução?
• Eles estão perdendo algumas condições de contorno críticas que, se perdidas, deixariam o cliente furioso?
• Eles estão usando alguma fonte de dados que possa introduzir vieses no modelo ou prejudicar adversamente algum segmento de usuário?

Mesmo que tudo o que foi dito acima se encaixe — quem sabe ao certo se a intuição inicial do usuário de negócios estava correta? O feedback final viria apenas do usuário final. Mas como você coloca o modelo nas mãos do usuário final?

Sim, você adivinhou corretamente — você precisa envolver a equipe de engenharia e produto. Haverá novamente reuniões de alocação de recursos, planejamento de sprint e, eventualmente, o modelo será integrado ao produto. Isso pode levar meses e, a essa altura, o usuário de negócios pode perceber que a prioridade do produto mudou! E então vem a terrível declaração — “Não adianta investir mais recursos neste projeto — não vamos jogar dinheiro bom fora com dinheiro ruim!”

Gigantes da tecnologia como Uber e Amazon

Desnecessário dizer, essas empresas estão na vanguarda e com muita frequência não levam meses para lançar Modelos de ML em produção. Mas isso não é inédito mesmo com essas empresas de ponta. E elas têm um problema muito peculiar neste contexto.

Com muita frequência, grandes gigantes da tecnologia constroem as suas próprias plataformas MLOps que fazem de tudo, desde a construção de feature stores, à implementação de algoritmos, à gestão de dependências, à implantação, à inferência de modelos e muito mais. Construir plataformas tão genéricas que funcionem para todos os casos de uso é um problema de engenharia difícil e esses sistemas acabam por fazer suposições do tipo-

1. Estas são as bibliotecas mais comuns que esperamos que os cientistas de dados usem
2. Enquanto o Cientista de Dados usar algoritmos “prontos para uso”, tudo funciona perfeitamente, mas se quiserem desenvolver o seu próprio modelo, terão de seguir os passos X, Y e Z.

Vamos examinar estas suposições e argumentar que não são práticas — os algoritmos de ML e o conjunto de ferramentas estão em constante melhoria e soluções de ponta são o que é necessário para os problemas de ponta em que estas empresas estão a trabalhar. Isto significa que quanto mais a empresa tentar ser intensiva em ML, mais precisará de soluções personalizadas e maior será a necessidade de alocar recursos de engenharia dedicados!

Por esta mesma razão, com muita frequência, as equipas de ciência de dados contentam-se com soluções prontas para uso, o que acarreta um enorme custo de oportunidade. Se o Cientista de Dados ou a empresa decidir seguir o caminho mais difícil, ou seja, avançar a sua plataforma e permitir a construção de soluções avançadas personalizadas — adivinhe, é preciso justificar o investimento, obter os recursos certos, falar com pessoas de muitas organizações. Quer resulte numa plataforma melhorada ou não, certamente adiciona atrasos!

E se, depois de muitos destes investimentos, as coisas não correrem como planeado, quando lançado para o utilizador — há um reforço para seguir o caminho mais fácil das soluções prontas para uso no próximo projeto.

Conclusão e Próximos Passos

Este tema dos modelos de ML a demorar “demasiado tempo” por várias razões, surgiu de forma evidente em todas as nossas conversas com utilizadores.

1. Uma startup que não tem todos os recursos humanos e ferramentas e não tem muito tempo para iterar e descobrir a solução ideal — contenta-se com sistemas baseados em regras ao abandonar projetos de ML!
2. Grandes empresas tradicionais com desafios organizacionais abandonam projetos de ML porque demorou demasiado tempo a concretizar-se e frequentemente não conseguem criar um impacto comercial justificável.
3. Empresas de tecnologia modernas com plataformas MLOps otimizadas para produção, mas não tanto para experimentação aberta, acabam por se contentar com algoritmos e bibliotecas "prontos para uso". Utilizar todo o potencial da Aprendizagem Automática demoraria demasiado tempo de outra forma.

Ficámos espantados ao ver este tema comum num espectro tão vasto de empresas-

Modelos de ML a demorar demasiado tempo e o impacto comercial e ciclos de feedback atrasados são uma das principais razões pelas quais muitos modelos de ML não veem a luz do dia.

Acreditamos que se pudermos viabilizar uma solução que permita uma comunicação fluida entre utilizadores de negócio e cientistas de dados, feedback rápido dos consumidores para verificar o impacto comercial antes de gastar muitos recursos organizacionais em soluções de ML, isso aumentará a confiança e o investimento em Machine Learning — e também tornará esses investimentos muito mais frutíferos.

Não afirmamos ter uma solução completa para o problema ainda, mas estamos a trabalhar nisso. Estamos a falar com pessoas inteligentes e a descobrir como podemos atenuar, se não resolver completamente, este problema.

Acreditamos firmemente que um problema tão grande exige que diversas perspetivas se unam. Se se identifica com este problema, ou tem ideias para partilhar, ou tem ideias sobre como resolver o problema ou quer ouvir as nossas ideias, convidamo-lo a comentar ou a vir falar connosco.

Pode contactar-me pessoalmente em- nikunjbjj@gmail.com. E aqui estão os perfis do LinkedIn meus e dos meus cofundadores-

• Nikunj Bajaj
• Abhishek Choudhary
• Anuraag Gutgutia

Este artigo foi publicado originalmente no Medium em https://medium.com/@nikunjbajaj/time-killed-my-ml-model-48521fad6c4 em 30 de agosto de 2021