Não consegue contratar rápido o suficiente? Como entregar valor de sua IA com uma pequena equipe de dados

As equipes de ciência de dados corporativos estão tendo problemas para contratar cientistas de dados e engenheiros de aprendizado de máquina com rapidez suficiente. Mas não há necessidade de esperar até que sua equipe esteja totalmente equipada para começar a gerar valor a partir de sua IA. É apenas uma questão de reunir automação e ferramentas melhores para que mesmo pequenas equipes de ciência de dados possam ter um impacto desproporcional.

Ao se envolver com diretores de dados e análises, um dos temas mais comuns que ouço é a dificuldade em contratar e reter cientistas de dados e engenheiros de aprendizado de máquina. As principais iniciativas de ciência de dados serão interrompidas quando um cientista de dados principal sair ou os esforços para integrar a IA em toda a empresa se tornarem apenas alguns projetos devido à incapacidade de contratar engenheiros de ML com rapidez suficiente para gerenciar cada modelo em produção.

E esse é um problema generalizado. De acordo com uma pesquisa do Gartner de 2021, quase dois terços (64%) dos executivos de TI identificaram a falta de talentos qualificados como a maior barreira para a adoção de tecnologias emergentes como IA e aprendizado de máquina. A contratação de cientistas de dados leva 20% mais tempo do que os trabalhos de TI como um todo e mais que o dobro do tempo médio de um trabalho corporativo nos EUA. A demanda por engenheiros de ML é ainda mais intensa, com vagas para engenheiros de ML crescendo 30 vezes mais rápido do que os serviços de TI como um todo.

VEJO: Kit de contratação: cientista de dados (TechRepublic )

As empresas investiram bilhões de dólares em IA (investimentos que incluíram a expansão de equipes de dados) com base em promessas de maior automação, personalizando a experiência do cliente em escala ou fornecendo previsões mais precisas para aumentar a receita. Mas até agora tem havido uma enorme lacuna entre o potencial da IA ​​e os resultados, com apenas cerca de 10% dos investimentos em IA gerando um ROI significativo.

Para CDAOs, esta é uma questão chave. Como eles podem agregar valor de IA/ML aplicada em toda a empresa no curto prazo com apenas um pequeno número de cientistas de dados e possivelmente ainda menos engenheiros de ML? Dito de outra forma, as pequenas equipes de ciência de dados podem começar a gerar valor desproporcional sem esperar meses ou anos por uma equipe totalmente treinada e com equipe completa?

Em vez de esperar até que preencham essas funções, as equipes de MLOps precisam encontrar uma maneira de oferecer e a mais modelos de ML e casos de uso sem um aumento linear no número de funcionários de ciência de dados. Então, como eles fazem isso? Algumas dicas incluem:

Reconhecer os pontos fortes dos membros da equipe existentes

Diferentes membros da equipe trazem diferentes pontos fortes e habilidades para a equipe. Os Cientistas de Dados são excelentes em transformar dados em modelos que ajudam a resolver problemas de negócios e tomar decisões de negócios. Mas a experiência e as habilidades necessárias para construir grandes modelos não são as mesmas habilidades necessárias para empurrar esses modelos no mundo real com código pronto para produção e, em seguida, monitorar e atualizar continuamente. Por outro lado, os engenheiros de ML integram ferramentas e estruturas para garantir que os dados, os pipelines de dados e a infraestrutura principal funcionem de forma coesa para produzir modelos de ML em escala.

Mas, embora os cientistas de dados possam ficar felizes em entregar seus modelos à equipe de MLOps para um lançamento em produção, esse processo pode não ser eficiente. Como os cientistas de dados e engenheiros de MLOps não falam a mesma linguagem e não trabalham ou pensam da mesma maneira, pode haver gargalos demorados quando um grupo tenta articular um requisito (por exemplo, pré-processamento de dados necessário) e o outra equipe tenta satisfazê-lo.

Além disso, se um modelo começar a se comportar mal ou se tornar menos preciso na produção, como os engenheiros de ML detectam o problema e alertam os cientistas de dados de que um modelo pode precisar ser treinado novamente? Pode ser um esforço de equipe para diagnosticar o problema – é um erro na pilha de produção ou há algo errado com o modelo? Isso pode levar aos mesmos gargalos de comunicação e coordenação observados durante a implantação, pois os cientistas de dados lutam para obter visibilidade de seus modelos na pilha de produção.

Evite repetir os erros da adoção da nuvem

Dez anos atrás, as equipes de infraestrutura de TI procuravam construir suas próprias nuvens privadas. Eles acabaram demorando mais e custando mais do que o esperado para serem construídos, exigindo mais recursos para manter e tendo menos recursos mais recentes em segurança e dimensionamento do que o fornecido pelas nuvens públicas. E, em vez de investir em recursos de negócios essenciais, essas empresas acabaram investindo tempo e número de funcionários significativos em infraestrutura.

Muitas empresas estão repetindo a mesma abordagem do tipo “faça você mesmo” para a maioria dos MLOps. A abordagem mais comum para colocar o ML em produção geralmente são soluções personalizadas reunidas a partir de várias ferramentas de código aberto, como o Apache Spark.

Eles geralmente são ineficientes (conforme medidos por inferências executadas em computação e tempo necessário) e, especialmente, não possuem a observabilidade necessária para testar e monitorar a precisão contínua dos modelos ao longo do tempo. Além disso, essas abordagens são muito personalizadas para fornecer processos escaláveis ​​e repetíveis para vários casos de uso em diferentes partes da empresa.

Contrate para o que importa e automatize todo o resto

Para isso, os CDAOs precisam desenvolver os recursos em torno da ciência de dados que são essenciais para os negócios, mas investir em tecnologias que automatizem o restante dos MLOps. Por exemplo, uma empresa de serviços financeiros de varejo pode encontrar valor na contratação de cientistas de dados individuais com experiência no setor em cada subvertical, como seguros, cartões de crédito e empréstimos à habitação, para criar perfis de risco de clientes mais granulares por linha de negócios. Mas não há ganho comercial semelhante para a empresa ao contratar engenheiros de ML dedicados para cada linha de negócios: na verdade, isso gera aumento de custos e diminuição da produtividade. Em vez disso, o negócio é melhor quando tem uma plataforma padronizada para implantar e gerenciar modelos de ML em produção que é independente da equipe que o desenvolveu ou das estruturas de construção de modelo usadas.

Sim, esse é o dilema comum “construir versus comprar”, mas desta vez a maneira correta de medir não é apenas os custos de OpEx, mas de forma rápida e eficaz seus investimentos em IA estão permeando toda a empresa – seja gerando novas receitas por meio de produtos melhores e segmentos de clientes, ou corte de custos por meio de maior automação e redução do desperdício.

Embora a contratação em ciência de dados e MLOps continue sendo difícil, os CDAOs podem começar a fornecer valor imediato de sua IA/ML mesmo com uma equipe limitada de cientistas de dados. O principal bloqueador será a crença de que “precisamos construir tudo isso internamente”. Ao entender as diferentes funções necessárias para criar e operacionalizar IA/ML e, em seguida, identificar aquelas que podem ser automatizadas por meio de ferramentas de ponta, a organização CDAO pode superar sua classe de peso (contagem de funcionários) mesmo com uma equipe pequena.