Modelos que funcionam de forma reproduzível, são monitorizados para detetar drift e são treinados novamente quando os dados mudam.
Com a confiança de organizações de referência
MLOps reúne as práticas e a tecnologia 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 novo treino dos modelos. Destina-se a organizações que desenvolvem modelos ou que já os têm e querem garantir que continuam a funcionar quando os dados mudam. A Data Science Lab implementa MLOps em conjunto com a sua equipa.
Uma especialista em data science criou um modelo que prevê a procura de manutenção, e no notebook parece funcionar bem. Para o colocar em utilização, envia o ficheiro do modelo à equipa de TI, juntamente com um documento que descreve as colunas esperadas. A equipa de TI recria o cálculo dos dados de entrada, mas com pequenas diferenças em relação 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. Não é possível responder: a tabela de treino foi sobrescrita, o código está num portátil e ninguém sabe que configurações foram utilizadas.
O problema raramente está no próprio modelo, mas no que falta à sua volta: um local definido para o código, os dados e as versões do modelo, um processo automatizado de passagem à produção e alguém responsável quando o modelo está em funcionamento. Com MLOps, pode criar essa estrutura.
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. Registe 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, regista as versões dos modelos e a execução de que resultaram. 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 do ambiente de desenvolvimento, através do ambiente de teste, até ao de produção. 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 as entradas e as previsões quanto a drift, a qualidade dos dados e a precisã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 funcionamento vários modelos, uma única abordagem genérica de monitorização escala melhor do que gerir cada modelo manualmente.
Comece por retreinar segundo um calendário fixo e passe depois a retreinar em resposta a um sinal, como drift ou uma quebra de qualidade. Esta é também a recomendação da Databricks. Uma nova versão só entra em produção se tiver um desempenho pelo menos tão bom como a 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 mais tarde com que dados, código e configurações foi criado um modelo.
Fale com um dos nossos engenheiros de machine learning sobre como o colocar 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 e as execuções no Git e no MLflow, utilizando uma versão fixa dos dados de treino.
Criamos uma pipeline CI/CD com testes e ambientes separados para desenvolvimento, testes 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 em conjunto 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 adota esta forma de trabalhar, com formação técnica quando for útil, ou continuamos envolvidos na gestão e melhoria contínua.
A DSL encontrou uma solução engenhosa que podemos aproveitar bem.
O MLOps exige um espaço para experiências, um registo de modelos e um processo de implementação. O Databricks disponibiliza estes elementos através do MLflow e do Unity Catalog; o Microsoft Fabric suporta experiências MLflow e inclui um registo de modelos integrado. Também é possível trabalhar numa infraestrutura local. No LUMC, já criámos a infraestrutura para implementar modelos na prática clínica. Agora, estamos a trabalhar em MLOps numa infraestrutura local e soberana, recorrendo, entre outras ferramentas, ao MLflow e ao Docker.
Os notebooks e modelos existentes são o ponto de partida. No GVB, criámos no Databricks um ciclo de vida de MLOps com templates reutilizáveis para um modelo de segmentação baseado nos padrões de viagem. Na Waternet, desenvolvemos, com a equipa Datalab, um workflow com um registo de modelos MLflow e templates de CI/CD, cuja manutenção também asseguramos. Se precisa sobretudo de reforçar a equipa, também pode recorrer a um dos nossos engenheiros de MLOps em regime de destacamento.
A tecnologia não costuma ser a parte mais difícil. Os profissionais de data science passam a trabalhar com Git e pipelines em vez de notebooks isolados, e a equipa de TI aprende a gerir os modelos como software que depende de dados. Acompanhamos essa mudança e, se pretender, incluímos a pipeline de MLOps nos nossos serviços de gestão e melhoria contínua.
Qualquer organização pode iniciar um projeto-piloto de IA. O desafio está no passo seguinte: 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.
DevOps trata de software cujo comportamento está definido no código. Um modelo de machine learning aprende o seu comportamento a partir dos 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 dos dados e dos modelos, monitorização de drift e novo treino ao que DevOps já abrange, como testes e implementação automatizados.
No data drift, os dados de entrada mudam: por exemplo, o modelo recebe tipos de clientes ou medições diferentes dos presentes nos dados de treino. No concept drift, muda a relação entre os dados de entrada e o resultado, por exemplo porque os clientes se comportam de forma diferente após uma alteração de preços. O concept drift é detetado sobretudo ao comparar as previsões com os resultados reais. Para a Rijkswaterstaat, desenvolvemos um pacote de monitorização genérico 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 nos pagamentos, só mais tarde se sabe se as previsões estavam corretas; 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 existente. Nos nossos projetos, utilizamos, entre outras, MLflow para experiências e para o model registry, Databricks, Azure DevOps para CI/CD, Docker e pacotes Python como Alibi Detect para detetar drift. No Microsoft Fabric, é possível seguir a mesma abordagem com as experiências MLflow integradas. Somos Databricks Partner e Microsoft Partner.
Para sistemas de IA de risco elevado, 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.º). Após o omnibus digital, estes requisitos aplicam-se a partir de 2 de dezembro de 2027, ou de 2 de agosto de 2028 no caso da IA em produtos regulamentados. MLOps fornece elementos para demonstrar o cumprimento destes requisitos, mas não torna automaticamente um sistema conforme. A avaliação de uma aplicação como sendo de risco elevado cabe a um jurista ou ao seu departamento de conformidade; ajudamos a fazer o levantamento, a preparar a classificação de risco e a estabelecer a governação da IA.
Se tiver um único modelo que raramente volta a ser treinado e cujos erros têm poucas consequências, uma pipeline de MLOps completa é muitas vezes excessiva. Código em Git, um processo de treino documentado e uma verificação simples dos resultados podem ser suficientes. Se o modelo ainda não demonstrou criar valor, comece por data science. A automatização adicional só compensa quando surgem mais modelos ou as consequências dos erros se tornam maiores.
E-mail info@datasciencelab.nl
Telefone +31 (0)20 3636 724
Diga-nos que modelos tem e onde surgem dificuldades. Depois, analisamos em conjunto o percurso do notebook até à produção.
Mensagem enviada
Obrigado pela sua mensagem. Entraremos em contacto consigo o mais rapidamente possível.
