Ir para o conteúdo

Contratar um engenheiro de MLOps

Os especialistas em MLOps da Data Science Lab estabelecem o caminho até à produção na sua própria equipa, como fizeram na equipa Datalab da Waternet.

Como parte da equipa Datalab da Waternet, implementámos e mantemos o fluxo de trabalho de MLOps

A Waternet quer que os projetos da equipa Datalab sejam efetivamente utilizados. Como parte da equipa, implementámos para esse fim o fluxo de trabalho de MLOps, com Azure DevOps, Bicep, um registo de modelos MLflow e templates de CI/CD para colocar código e modelos em produção. Também asseguramos a manutenção desse fluxo de trabalho.

Leia o caso de estudo

Quem acompanha os nossos modelos depois de entrarem em funcionamento?

Três modelos estão em produção, cada um implementado de forma diferente por quem o criou. As novas versões são lançadas manualmente e ninguém deteta se os dados de entrada estão a mudar. Um engenheiro de MLOps estabelece um processo único com um registry, uma pipeline e monitorização.

Agende uma conversa
Drie collega's aan een tafel bespreken grafieken op een laptop, met een tweede scherm erachter.

Um engenheiro de MLOps cria o percurso comum a todos os seus modelos

Fale connosco sobre os seus modelos

Registry e CI/CD

Cada versão de modelo fica num registry e cada alteração passa pelos mesmos testes, como na Waternet, com MLflow e templates de CI/CD no Azure DevOps.

Templates para os próximos modelos

Uma forma de trabalhar que se aplica ao projeto seguinte, como o ciclo de vida de MLOps com templates reutilizáveis que implementámos para a GVB em Databricks.

Monitorização de drift

Uma abordagem única à deteção de drift e outliers em todos os modelos, como o pacote genérico de monitorização que desenvolvemos para a Rijkswaterstaat.

Infraestrutura em servidores próprios

Serving, monitorização e manutenção quando os dados não podem sair das instalações, como no LUMC, numa infraestrutura on-premise e soberana.

Fale com um candidato de MLOps sobre os seus modelos e a sua plataforma

  1. Modelos e processo de implementação

    Analisamos que modelos estão em funcionamento, como são atualmente colocados em produção e monitorizados e quem é responsável por eles.

  2. Conhecer e escolher

    Apresentamos-lhe colegas que conhecem a sua plataforma. Pode falar com eles sem compromisso e escolher quem contratar.

  3. Configurar e documentar

    O engenheiro desenvolve no seu repositório. As pipelines, os templates e as regras de alerta permanecem disponíveis quando o trabalho termina.

Está na altura de integrar um engenheiro de MLOps ou é preciso tratar de outra coisa primeiro?

Avalie a situação numa conversa

É adequado se

Já existem modelos em funcionamento ou estão previstos mais modelos, e cada um chega atualmente a produção de uma forma diferente. A sua equipa quer um processo único que consiga manter por si própria.

Não é adequado se

Ainda não há nenhum modelo que precise de entrar em produção, ou pretende que toda a estrutura de MLOps seja entregue como um projeto. Nesse caso, é preferível começar por um modelo ou um projeto, em vez de reforçar a equipa.

Dedicação e tarifa

O projeto determina quantas horas por semana são necessárias e durante quanto tempo; não estabelecemos uma duração mínima nem máxima. A tarifa depende dos conhecimentos especializados de que precisa, da experiência do engenheiro e da duração do projeto.

Não é uma prestação de serviços independente

O engenheiro de MLOps é funcionário da Data Science Lab e fica destacado na sua organização. A seleção, o onboarding e o acompanhamento são tratados através de um único ponto de contacto da nossa parte.

Um engenheiro de MLOps em regime de cedência, MLOps como projeto ou uma contratação permanente?

Cedência

Escolha esta opção se a sua equipa continuar responsável pelos modelos e quiser aprender a gerir o percurso até à produção. Recomendamos esta opção se já tiver vários modelos em funcionamento.

Como projeto

Escolha esta opção se preferir que concebamos e entreguemos o percurso até à produção, assumindo nós a responsabilidade. Consulte MLOps.

Contratação permanente

Escolha esta opção se MLOps passar a ser uma atividade permanente. Se o nosso engenheiro corresponder às suas expectativas, podemos conversar sobre a sua contratação para os seus quadros.

Os nossos engenheiros de MLOps podem contar com colegas que têm modelos em produção

Esses colegas trabalharam em registry, pipelines e monitorização na Waternet, no GVB, na Rijkswaterstaat e no LUMC. Podem também contar com o nosso laboratório interno e os Techdays. A Data Science Lab existe desde 2016 e é Databricks Partner e Microsoft Partner.

Agende uma reunião de apresentação

O que já está em funcionamento é o ponto de partida para a primeira conversa

Stef Stoelwinder

Stef Stoelwinder

Desenvolvimento de Negócio

Stef é o seu primeiro ponto de contacto. Na primeira conversa, falamos dos seus modelos, da sua plataforma e do perfil de MLOps mais adequado.

Que modelos precisamos de manter a funcionar de forma fiável?

Indique-nos quais são os modelos, a plataforma e a equipa envolvidos. Respondemos por email ou propomos uma primeira conversa.

Introduza um endereço de e-mail válido.

Diga-nos como podemos ajudar.

Perguntas frequentes

Um engenheiro de MLOps prepara o percurso de cada modelo, desde a experimentação até à produção. Coloca o código no Git, regista as execuções e as versões dos modelos num registry, cria CI/CD com ambientes separados para desenvolvimento, teste e produção e configura a monitorização e o novo treino dos modelos.

Na nossa página sobre cedência de profissionais, o engenheiro de MLOps consta das funções de data engineering. Se precisar de um especialista em MLOps para uma plataforma específica, propomos alguém que a conheça.

Um engenheiro de machine learning coloca um modelo em produção: transforma o trabalho feito num notebook em código testado, numa pipeline de treino e num endpoint. Um engenheiro de MLOps cria a infraestrutura partilhada por todos os modelos: um registry, templates de CI/CD, monitorização e regras para voltar a treinar os modelos.

Em equipas pequenas, a mesma pessoa desempenha muitas vezes as duas funções. Se a prioridade for colocar um único modelo em produção, leia sobre contratar um engenheiro de machine learning.

A Google descreve três níveis. No nível 0, tudo é feito manualmente: o profissional de data science entrega um modelo treinado aos engenheiros, raramente surgem novas versões e as previsões não são monitorizadas. No nível 1, a pipeline de treino é automatizada e o modelo volta a ser treinado com novos dados. No nível 2, o CI/CD também testa e implementa a própria pipeline.

Se a sua equipa estiver no nível 0 e tiver mais do que um modelo em funcionamento, passar para o nível 1 é trabalho para um engenheiro de MLOps.

Monitoriza os dados de entrada para detetar data drift, as previsões para detetar prediction drift, a qualidade dos dados (valores em falta, tipos incorretos e valores fora do intervalo) e, quando os resultados reais estiverem disponíveis, o próprio desempenho do modelo. É definido um limiar para cada indicador, que aciona um alerta.

A Microsoft recomenda definir os limiares em conjunto com o profissional de data science que conhece o modelo, para evitar alertas em excesso. No Azure Machine Learning, um alerta pode iniciar uma tarefa de novo treino através do Event Grid.

Na maioria dos casos, a Databricks recomenda promover o código: o código de treino passa pelo ambiente de teste antes de chegar à produção, onde treina o modelo, porque já foi revisto e testado. Promover um modelo treinado faz sentido quando o treino é muito dispendioso ou difícil de repetir.

No Unity Catalog, atribui-se um alias, como champion, à versão em produção. Os processos batch e os endpoints seguem esse alias, e a lineage mostra em que tabelas o modelo foi treinado.

Um freelancer contratado diretamente tem de trabalhar de forma independente também na prática. Desde 1 de janeiro de 2025, a autoridade tributária neerlandesa voltou a fiscalizar plenamente este requisito. Quem trabalha nas tarefas da sua equipa sob a sua direção pode facilmente deixar de cumprir esse critério.

Os nossos engenheiros de MLOps são funcionários da Data Science Lab e são cedidos à sua organização. Peça aos recursos humanos, ao departamento de compras ou a um consultor que avaliem como esta opção se enquadra na sua política de contratação.

Para os sistemas de IA de risco elevado, o Regulamento da IA exige, entre outras coisas, registos que permitam rastrear os resultados, supervisão humana e robustez. Após a entrada em funcionamento, o fornecedor tem de dispor de um sistema de monitorização. Segundo a Comissão Europeia, estas regras aplicam-se à maioria das aplicações de risco elevado a partir de 2 de dezembro de 2027.

Um processo de MLOps que regista execuções e versões e monitoriza os modelos ajuda a reunir essas provas. Um jurista ou o seu departamento de conformidade pode determinar se um modelo está sujeito a essas regras. Saiba mais sobre governação da IA.

Se ainda não houver nenhum modelo em funcionamento, não há nada para implementar ou monitorizar. Comece por data science. Se houver um único modelo para colocar em produção, um engenheiro de machine learning é mais adequado. Se o problema estiver nos próprios dados, trate primeiro da fundação de dados.

Se quiser que todo o processo seja entregue como solução, em vez de apenas reforçar a equipa, MLOps como projeto é mais adequado.