5 aprendizados de um engenheiro de machine learning mid-level

Neste artigo você vai ver:

Acima de tudo, o que me inspirou a escrever este artigo é a minha situação de carreira neste momento, trabalho na área de machine learning entre 4 e 5 anos e estou em um dos projetos mais importantes que já trabalhei. Por isso, gostaria de compartilhar minhas experiências e minhas reflexões sobre o papel do engenheiro de machine learning.

Este post é focado em pessoas que têm um conhecimento mínimo sobre machine learning e estão pensando em migrar para a área. Portanto, eu criei uma lista com os 5 principais aprendizados que tive como um engenheiro de machine learning até este momento da minha carreira. 

Esses aprendizados que compartilharei também podem ser úteis para outras carreiras em tecnologia, não se limitando apenas a machine learning, mas também para a carreira em engenharia de software.

Ah, se estiver em um momento anterior buscando informações sobre como começar na carreira de dados, temos o artigo certo para você! ?

1. Não tenha medo de arriscar

Em MLOps (Machine Learning Operations), temos uma carência de ferramentas para garantir o melhor para um sistema de aprendizado de máquina de ponta a ponta. Por exemplo, aspectos como versionamento de dados; CI/CD focado em machine learning; implantar grandes modelos que possuem um volume de dados muito alto; monitoramento; e assim por diante. 

No início, como um engenheiro de ML júnior, eu evitava tomar riscos em algumas implementações, em grande parte porque eu não tinha conhecimento suficiente para fazer. Porém, com o tempo e experiência, ficou nítido para mim que para subir de nível e se tornar um engenheiro melhor era inevitável que deveria realizar tarefas mais difíceis e complexas.

Um ótimo exemplo foi quando recebi uma tarefa para criar um recurso de observabilidade para o sistema usando Terraform na AWS (nunca tinha feito isso antes) focado em ML.

Pensei: “Ah, como posso desenvolver isso da melhor forma e adaptar para ML?”. Ainda não tínhamos uma ferramenta específica para fazer esse trabalho, fui desafiado a ultrapassar os limites das soluções e fazer novas coisas para resolver esse problema. O que me faltava era “pensar fora da caixa”.

Não conseguia entender que um júnior também era um engenheiro, não importando se está em software, DevOps, etc., era preciso fomentar soluções e assumir seus riscos.

Eu estava com medo, porque ainda não tinha feito nada parecido e sem nenhuma referência com o foco em machine learning em torno da observability.

Inclusive, observability foi um exemplo, mesmo com uma grande falta de ferramentas para resolver problemas de engenharia de ML, você tem que assumir riscos, o caminho é feito do zero, o aprendizado vem com tropeços, não tenha medo e vá em frente, você vai atingir o seu objetivo!

2. Simplifique

Seguindo o primeiro aprendizado, para tornar o trabalho o mais simples possível, como um engenheiro de ML temos muitas possibilidades de criar inúmeras soluções para um sistema de machine learning. Por exemplo:

  • Qual provedor de nuvem podemos usar? 
  • Qual é o melhor repositório de dados para usar? 
  • Qual será a feature store que vamos utilizar? 

Você concorda que temos muitas maneiras de resolver o mesmo problema? Profissionais de engenharia de machine learning precisam pensar em todo o pipeline e nas pequenas peças do quebra-cabeças.

Precisamos lembrar que existe uma linha de tênue do que é necessário e over-engineering. Em engenharia de software, o termo refere-se, em poucas palavras, como “design excessivo para resolver uma tarefa simples”.

Para engenharia de machine learning o mesmo é válido, “usar Kubernetes para implantar apenas um modelo”, mas faz sentido usar o Kubernetes apenas para manter um único modelo? “Que tal criar um cluster distribuído de GPUs para treinar um modelo de Deep Learning”, você realmente precisa de um modelo de Deep Learning ou um algoritmo mais simples já resolve o problema? 

Você precisa ter clareza em sua mente ao diferenciar uma solução que não é necessária para resolver determinada tarefa, quanto maior for a complexidade em sua solução mais difícil será mantê-la no ar.

Comece simples e escale a partir daí, você não precisa escalar desde o primeiro dia do projeto, as melhores soluções são aquelas que resolvem o problema e são simples, aprenda a reduzir uma solução de alta complexidade para uma solução mais simplificada. 

O que você ganha com isso? 

Os benefícios são muitos: menos tempo para corrigir erros de produção; deixar o time de engenharia a par da solução; facilidade de aplicar um novo recurso; e muitos outros. Minha dica é começar simples, manter simples e tentar escaloná-lo de forma simples, o seu trabalho será infinitamente mais produtivo, simplicidade é a chave.

3. O negócio está envolvido

Por que esse título? Antes de passar para engenharia de ML, eu era cientista de dados e fiz vários modelos para resolver uma ampla gama de problemas de negócios, sistemas de recomendação, detecção de fraudes, resumir textos, etc. 

Na função de engenheiro, no primeiro trabalho, eu fiz tudo dito antes, mas esse ponto chave foi que eu não era uma pessoa comunicativa. Como cientista de dados, precisava ter a habilidade de ser comunicativo e mostrar os resultados para as partes interessadas.

Na minha visão, Product Managers (PM) eram as pessoas responsáveis por entender do negócio e fazer a gestão do time durante o projeto, entregando os requisitos de negócio para o time de dados desenvolver. Assim como muitas pessoas, eu tinha preferência em não sair da frente do código e não precisar me expor em reuniões de negócio.

Bem, com uma breve introdução sobre minha antiga função como cientista de dados, tenho a chance de passar para a função de engenheiro de ML. Não mudei porque precisava falar com as partes interessadas, mas a engenharia de ML faz sentido para mim, eu sempre amei engenharia e aprendizado de máquina, era uma combinação perfeita um do outro.

Mas ouvi falar que profissionais de engenharia de ML não precisam falar com stakeholders, porque se preocupam com arquitetura e deploy, assim não necessitam explicar resultados de modelos, métricas, impacto no negócio, etc. Isso é um erro completo.

Como pessoa engenheira de machine learning, seu relacionamento com stakeholders não se extinguiu. Sua preocupação é garantir uma boa plataforma ou arquitetura de ML para cientistas de dados e os stakeholders estão envolvidos nesse assunto.

Quando ouvi alguém dizer que profissionais de engenharia de ML precisavam apenas de código e pensamento técnico, estavam todos errados e aprendi qual é o impacto para PMs com envolvimento com a engenharia.

Faz parte da função de engenharia se manter por dentro das decisões de negócios. Você nem sempre está no comando dos desafios técnicos, é praticamente impossível ficar longe do negócio e desenvolver sem esse contexto.

4. Os padrões de design de ML são fundamentais

Quanto aos padrões de projeto voltados para aprendizado de máquina, há algum tempo um time de especialistas em aprendizado de máquina lançou um livro chamado Padrões de projeto de aprendizado de máquina”.

O material inclui 30 padrões para representação de dados e problemas, operacionalização, repetibilidade, reprodutibilidade, etc. Em engenharia de software, esse conceito de “design patterns” é bem estabelecido, em engenharia de ML ainda não. Isso tem impacto direto no desenvolvimento do produto/serviço.

Capa do livro “Machine Learning Design Patterns: Solutions to Common Challenges in Data Preparation, Model Building, and Mlops” onde temos o seu título e a ilustração de uma ave, seguida pelo nome dos autores Valliappa Lakshmanan, Sara Robinson e Michael Munn.

Certamente poucas pessoas conhecem alguns dos padrões de design de ML que são mais usados em aprendizado de máquina. Na minha experiência, quando conheço alguns deles e os coloco em prática, tenho uma visão bem definida de cada parte do projeto e sei qual é a parte mais arriscada do código. Definitivamente, eu era outro engenheiro antes de conhecer e praticar padrões de design de ML.

No entanto, assim como as práticas de MLOps, os padrões de design de ML são iguais, dependendo da cultura da equipe adotar uma prática de usar padrões de design ou não. Quer dizer, não é uma decisão unilateral e sim de toda a equipe.

Para finalizar este tópico, vou compartilhar três padrões de design de ML que mais impactam meu trabalho:

  • Embeddings (estrutura, tamanho do vetor de recursos): especificamente, a maioria dos algoritmos de aprendizado de máquina só pode receber dados numéricos de baixa dimensão como entradas, embeddings é reduzir esses dados a um espaço dimensional;
  • Stateless Serving Function: permite ter um sistema de ML em produção lidando de forma síncrona com milhões de solicitações de previsão por segundo;
  • Feature Store: repositório central de features, permite produzir novas features sem a necessidade de um grande esforço de engenharia.

Aproveite e acompanhe uma live com zuppers para discutir sobre MLops e produtos financeiros. Está imperdível e disponível na íntegra no nosso canal!

5. Mindset de Engenharia

Eu era Cientista de Dados antes de passar para o cargo de engenheiro de ML e sou formado em ciência da computação (background em sistemas de banco de dados). Quando consegui meu primeiro emprego na área de aprendizado de máquina, passei muito tempo estudando estatística, probabilidade, álgebra linear, tudo isso para conseguir um papel como cientista de dados.

Em geral, mudei meu foco para matemática e esquecendo da engenharia, para mim estava tudo bem, mas algumas coisas mudaram na minha mente, outras experiências me convenceram sobre engenharia e matemática aplicada ao aprendizado de máquina.

A primeira é que engenharia é mais valiosa para pessoas engenheiras de ML do que matemática. Pode-se dizer, obviamente, mas não vi isso muito claro no começo, mesmo que no aprendizado de máquina a maioria das pessoas se concentram em ML como o tópico principal para estudar para conseguir esse papel.

Estou aqui para discordar disso, agora percebi o quanto é importante ter habilidades de engenharia. O papel de profissionais de engenharia é focar em construir coisas e não criar um algoritmo de aprendizado de máquina. 

Por isso, é essencial saber o que é um teste de unidade, implantação, arquitetura em nuvem, bash e práticas mais específicas, quando soube disso, pude fazer um trabalho mais produtivo.

Conclusão

Esses foram os meus principais aprendizados durante alguns anos trabalhando como engenheiro de machine learning, espero que este post tenha sido útil para quem pensa em seguir uma carreira na área.

Me inspirei em fazer este post para compartilhar com a comunidade meus sentimentos e pensamentos sobre a área. Afinal, neste momento, a engenharia de ML está começando e ainda tem muito a fazer!

Por isso, a área nasceu com novas ferramentas e conceitos, e está ganhando maturidade e mais clareza. Quer participar dessa conversa? Conte sua opinião nos comentários!

Obrigado por ler até o final, até o próximo post!

A imagem corresponde ao conteúdo sobre "5 aprendizados de um engenheiro de machine learning mid-level", onde traz o conceito de Conceito de tecnologia de TI moderna com machine learning.
felipe-silva
Machine Learning Engineer (Pleno)
Engenheiro de Machine learning com o objetivo de colocar modelos em produção em larga escala. Apaixonado em pesquisas acadêmicas na área de Deep learning, sempre motivado a testar coisas novas e colaborar com o próximo estágio da Inteligência Artificial.

Este site utiliza cookies para proporcionar uma experiência de navegação melhor. Consulte nossa Política de Privacidade.