Modelos que funcionam de forma reproduzível, são monitorizados quanto a drift e voltam a ser treinados quando os dados mudam.
Com a confiança de organizações de referência
MLOps reúne as práticas e técnicas necessárias para colocar modelos de machine learning em produção de forma fiável e mantê-los a funcionar: desde o controlo de versões e os testes automatizados até à monitorização e ao retreino. Destina-se a organizações que desenvolvem modelos, ou que já os têm, e querem que continuem a funcionar quando os dados mudam. A Data Science Lab implementa MLOps em conjunto com a sua equipa.
Uma data scientist criou um modelo que prevê as necessidades de manutenção e, no notebook, os resultados parecem bons. Para o colocar em utilização, envia o ficheiro do modelo à equipa de TI, acompanhado de um documento que descreve as colunas esperadas. A equipa de TI volta a implementar os cálculos dos dados de entrada, mas com ligeiras diferenças face ao notebook. O modelo funciona, mas ninguém se apercebe de que as previsões se vão desviando gradualmente.
Mais tarde, alguém da equipa de conformidade pergunta com que dados foi treinada a versão atual. Ninguém consegue responder: a tabela de treino foi substituída, o código está num portátil e ninguém sabe que configurações foram usadas.
O problema raramente está no próprio modelo. Está no que falta à sua volta: um local definido para o código, os dados e as versões do modelo, um processo automatizado até à produção e uma pessoa responsável pelo modelo assim que entra em funcionamento. É isso que se implementa com MLOps.
O código fica no Git e cada execução de treino regista os parâmetros, as métricas e o ficheiro do modelo, por exemplo no MLflow. Regista-se também a versão dos dados de treino utilizada: as tabelas Delta têm versões, mas as versões antigas desaparecem após a limpeza.
Um model registry, como o Models in Unity Catalog ou o MLflow Model Registry, acompanha as versões existentes de cada modelo e a execução de que provêm. Com aliases como champion e challenger, pode mudar de versão sem alterar o código.
Cada alteração passa pelos mesmos testes e segue o mesmo percurso, do ambiente de desenvolvimento ao de produção, passando pelo de testes. A Databricks recomenda promover o código em vez dos modelos treinados, para que o modelo de produção seja treinado no ambiente de produção com código testado.
Para cada modelo, monitorizamos os dados de entrada e as previsões para detetar drift, verificamos a qualidade dos dados e avaliamos a exatidão assim que os resultados reais estão disponíveis. Os limiares definidos para cada sinal determinam quem recebe um alerta e quando. Se estiverem em execução vários modelos, uma abordagem de monitorização comum escala melhor do que tratar cada modelo manualmente.
Comece por retreinar segundo um calendário fixo e depois passe a retreinar em resposta a um sinal, como drift ou uma quebra de qualidade. É também essa a recomendação da Databricks. Uma nova versão só entra em produção se tiver um desempenho pelo menos tão bom como o da versão atual.
Para cada modelo, fica definido quem é o responsável, quem recebe os alertas e quem decide sobre uma nova versão. Como cada passo é registado, pode demonstrar posteriormente com que dados, código e configurações foi criado um modelo.
Fale com um dos nossos engenheiros de ML sobre como colocá-lo em produção de forma reproduzível e com monitorização.
Analisamos que modelos existem, onde são executados, como são atualmente treinados e colocados em produção e onde há trabalho manual ou riscos.
Escolhemos um modelo relevante e registamos o código, as execuções e os dados de treino no Git, no MLflow e numa versão fixa dos dados.
Criamos uma pipeline CI/CD com testes e ambientes separados de desenvolvimento, teste e produção, por exemplo no Azure DevOps.
Medimos o drift, a qualidade dos dados e, quando há resultados disponíveis, o desempenho. Definimos os limiares e os destinatários dos alertas com o responsável.
Registamos o que funciona em templates reutilizáveis, para que os modelos seguintes sigam o mesmo caminho e cada projeto não tenha de começar do zero.
A sua equipa assume esta forma de trabalhar, com formação técnica quando for útil, ou continuamos envolvidos na gestão e melhoria contínua.
A DSL apresentou uma solução engenhosa que podemos aproveitar bem.
O MLOps exige um ambiente para experiências, um model registry e um processo de implementação. No Databricks, estes elementos estão disponíveis através do MLflow e do Unity Catalog; o Microsoft Fabric inclui experiências com MLflow e um model registry integrado. Também é possível trabalhar on-premise. No LUMC, já criámos a infraestrutura para implementar modelos na prática clínica. Agora estamos a trabalhar em MLOps numa infraestrutura on-premise e soberana, com recurso, entre outras ferramentas, ao MLflow e ao Docker.
Os notebooks e modelos existentes são o ponto de partida. Na GVB, configurámos no Databricks um ciclo de vida de MLOps com templates reutilizáveis para um modelo de segmentação baseado nos padrões de deslocação. Na Waternet, criámos, no âmbito da equipa Datalab, um workflow com um model registry do MLflow e templates de CI/CD, cuja manutenção também asseguramos. Se precisa sobretudo de reforçar a equipa, pode ainda contar com um dos nossos engenheiros de MLOps em regime de destacamento.
A tecnologia não costuma ser a parte mais difícil. Os data scientists passam a trabalhar com Git e pipelines em vez de notebooks isolados, e a equipa de IT aprende a gerir modelos como software dependente de dados. Acompanhamos essa transição e, se pretender, incluímos o pipeline de MLOps nos serviços de gestão e melhoria contínua.
Qualquer organização pode iniciar um projeto-piloto de IA. O desafio vem a seguir: integrar a IA na organização. É aí que a Data Science Lab faz a diferença.
Saiba mais sobre nós
10+
8,7
200+
MLOps, abreviatura de machine learning operations, combina práticas, funções e ferramentas para desenvolver, implementar, monitorizar e melhorar modelos de machine learning. O objetivo não é apenas colocar um modelo em produção uma vez, mas garantir que continua a ter um bom desempenho quando as condições mudam.
O desenvolvimento do próprio modelo fica fora do âmbito de MLOps. Saiba como o fazemos em desenvolvimento de modelos de machine learning.
DevOps trata de software cujo comportamento está definido no código. Um modelo de machine learning aprende o seu comportamento a partir de dados, e esses dados mudam. Por isso, o desempenho de um modelo pode piorar sem que nenhuma linha de código tenha sido alterada. MLOps acrescenta controlo de versões de dados e modelos, monitorização de drift e novo treino ao que DevOps já assegura, como testes e implementação automatizados.
No data drift, os dados de entrada mudam: por exemplo, surgem tipos de clientes ou valores medidos diferentes dos dados de treino. No concept drift, muda a relação entre os dados de entrada e o resultado, por exemplo porque os clientes passam a comportar-se de forma diferente após uma alteração de preço. O concept drift deteta-se sobretudo comparando as previsões com os resultados reais. Para Rijkswaterstaat, desenvolvemos um pacote genérico de monitorização para detetar drift e outliers.
Depende da rapidez com que os seus dados mudam, do custo de um erro e de quando ficam disponíveis os resultados reais. Num modelo que prevê atrasos de pagamento, só mais tarde se sabe se a previsão estava correta; até lá, monitoriza-se o drift nos dados de entrada. Por isso, definimos um calendário de novo treino para cada modelo, em conjunto com o respetivo responsável.
Escolhemos as ferramentas adequadas ao seu ambiente atual. Nos nossos projetos, trabalhamos, entre outras, com MLflow para experiências e o registo de modelos, Databricks, Azure DevOps para CI/CD, Docker e pacotes Python como Alibi Detect para deteção de drift. No Microsoft Fabric, é possível seguir a mesma abordagem com as experiências MLflow integradas. Somos Databricks Partner e Microsoft Partner.
Para a IA de alto risco, o Regulamento da IA estabelece, entre outros, requisitos de governação de dados (artigo 10), registo automático de eventos (artigo 12), exatidão e robustez ao longo do ciclo de vida (artigo 15) e monitorização após a entrada em funcionamento (artigo 72). Na sequência do pacote Omnibus Digital, estes requisitos aplicam-se a partir de 2 de dezembro de 2027 e, para a IA em produtos regulamentados, a partir de 2 de agosto de 2028. MLOps fornece provas para demonstrar o cumprimento destes requisitos, mas não torna automaticamente um sistema conforme. Cabe a um jurista ou ao seu departamento de conformidade avaliar se a sua aplicação é de alto risco; nós ajudamos a fazer o levantamento, a preparar a classificação de risco e a tratar da governação da IA.
E-mail info@datasciencelab.nl
Telefone +31 (0)20 3636 724
Diga-nos que modelos tem e onde surgem as dificuldades. Depois, analisamos em conjunto o caminho do notebook até à produção.
Mensagem enviada
Obrigado pela sua mensagem. Entraremos em contacto consigo o mais rapidamente possível.
