Ga naar de inhoud

MLOps: modellen betrouwbaar in productie

Modellen die reproduceerbaar draaien, op drift worden bewaakt en hertrainen wanneer de data verandert.

Vertrouwd door toonaangevende organisaties

Agrocare
Athlon
DPG Media
Rijkswaterstaat
Brocacef
WUA
Fokker
The Cirqle
Zorginstituut Nederland
AWVN
Independer
Gemeente Hollands Kroon

MLOps is de werkwijze en techniek waarmee je machine learning-modellen betrouwbaar in productie brengt en houdt: van versiebeheer en geautomatiseerd testen tot monitoring en hertrainen. Het is bedoeld voor organisaties die modellen bouwen of al hebben en willen dat die blijven werken als de data verandert. Data Science Lab richt MLOps in, samen met je eigen team.

Waarom modellen in de notebook blijven hangen

Een data scientist heeft een model gebouwd dat de vraag naar onderhoud voorspelt, en in de notebook ziet het er goed uit. Om het in gebruik te nemen, stuurt ze het modelbestand naar IT, met een document over de kolommen die het verwacht. IT bouwt de berekening van de invoer opnieuw na, net iets anders dan in de notebook. Het model draait, maar niemand ziet dat de voorspellingen langzaam afwijken.

Later vraagt iemand van compliance op welke data de huidige versie is getraind. Dat blijkt niet te beantwoorden: de trainingstabel is overschreven, de code staat op een laptop en niemand weet welke instellingen zijn gebruikt.

Dat ligt zelden aan het model zelf, maar aan wat eromheen ontbreekt: een vaste plek voor code, data en modelversies, een geautomatiseerde route naar productie en een eigenaar zodra het model draait. Dat richt je met MLOps in.

Wat een MLOps-werkwijze voor je regelt

Data, code en model versioneren

Code staat in Git en elke trainingsrun legt parameters, metrics en het modelbestand vast, bijvoorbeeld in MLflow. Leg ook vast welke versie van de trainingsdata is gebruikt: Delta-tabellen kennen versies, maar oude versies verdwijnen na opschonen.

Een model registry

Een model registry, zoals Models in Unity Catalog of de MLflow Model Registry, houdt bij welke modelversies er zijn en uit welke run ze komen. Met aliassen als champion en challenger wissel je van versie zonder codewijziging.

CI/CD voor modellen

Elke wijziging doorloopt dezelfde tests en route van ontwikkel- via test- naar productieomgeving. Databricks raadt aan code te promoten in plaats van getrainde modellen, zodat het productiemodel met geteste code in de productieomgeving wordt getraind.

Monitoring op data- en conceptdrift

We bewaken per model invoer en voorspellingen op drift, de datakwaliteit, en de nauwkeurigheid zodra de werkelijke uitkomsten binnen zijn. Drempels per signaal bepalen wie wanneer een alert krijgt. Draaien er meerdere modellen, dan schaalt één generieke monitoringaanpak beter dan handwerk per model.

Hertrainen met een aanleiding

Begin met hertrainen op een vast schema en stap over op hertrainen na een signaal, zoals drift of dalende kwaliteit; dat advies geeft Databricks ook. Een nieuwe versie gaat pas live als hij minstens zo goed presteert als de huidige.

Eigenaar en audit trail

Per model ligt vast wie eigenaar is, wie de alerts krijgt en wie beslist over een nieuwe versie. Omdat elke stap wordt gelogd, kun je achteraf laten zien met welke data, code en instellingen een model is gemaakt.

Staat er een model in een notebook dat naar productie moet?

Bespreek met een van onze ML-engineers hoe je het reproduceerbaar en bewaakt live krijgt.

Abstract datavisualisatie-beeld in de merkstijl van Data Science Lab

Zo richten we MLOps in

  1. Huidige situatie in kaart

    We bekijken welke modellen er zijn, waar ze draaien, hoe ze nu worden getraind en uitgerold en waar handwerk of risico zit.

  2. Eén model reproduceerbaar maken

    We kiezen een model dat ertoe doet en leggen code, runs en trainingsdata vast in Git, MLflow en een vaste dataversie.

  3. Route naar productie bouwen

    We bouwen een CI/CD-pijplijn met tests en aparte omgevingen voor ontwikkeling, test en productie, bijvoorbeeld in Azure DevOps.

  4. Monitoring en alerts inrichten

    We meten drift, datakwaliteit en, waar uitkomsten beschikbaar zijn, prestaties. Drempels en ontvangers van alerts spreken we af met de eigenaar.

  5. Vastleggen in templates

    Wat werkt, leggen we vast in herbruikbare templates, zodat volgende modellen dezelfde route volgen en niet elk project opnieuw begint.

  6. Overdragen of samen beheren

    Je team neemt de werkwijze over, met een technische training waar dat helpt, of we blijven betrokken bij beheer en doorontwikkeling.

DSL is met een inventieve oplossing gekomen die we goed kunnen gebruiken.

Nanine Overgaauw Rijkswaterstaat - SRE Data Science

Wat MLOps vraagt en hoe het aansluit

MLOps vraagt om een plek voor experimenten, een model registry en een uitrolroute. In Databricks zit dat in MLflow en Unity Catalog; Microsoft Fabric heeft MLflow-experimenten en een ingebouwde model registry. Het kan ook on-premise. Bij het LUMC hebben we eerder de infrastructuur opgezet om modellen in de zorgpraktijk te implementeren, en nu werken we daar aan MLOps op een on-premise en soevereine infrastructuur, met onder meer MLflow en Docker.

Bestaande notebooks en modellen zijn het vertrekpunt. Bij GVB richtten we in Databricks een MLOps-lifecycle met herbruikbare templates in voor een segmentatiemodel op basis van reisgedrag. Bij Waternet hebben we binnen het Datalab-team een workflow met een MLflow model registry en CI/CD-templates opgezet, die we ook onderhouden. Zoek je vooral extra handen, dan kun je ook een MLOps engineer bij ons detacheren.

De techniek is meestal niet het lastigste deel. Data scientists gaan werken via Git en pijplijnen in plaats van losse notebooks, en IT leert modellen beheren als software die van data afhangt. Die omschakeling begeleiden we, en als je wilt nemen we de MLOps-straat mee in beheer en doorontwikkeling.

Over Data Science Lab

Iedere organisatie kan een AI-pilot starten. De uitdaging zit in de stap daarna. AI onderdeel maken van de organisatie. Dat is waar Data Science Lab het verschil maakt.

Lees meer over ons
Data Science Lab team
Data Science Lab kantoor
Data Science Lab werkplek

Waarom organisaties voor ons kiezen

10+

jaar ervaring

8,7

klantwaardering

200+

projecten gerealiseerd

Microsoft & Databricks Partner

Veelgestelde vragen

MLOps, kort voor machine learning operations, is de combinatie van werkwijze, rollen en tooling waarmee je machine learning-modellen ontwikkelt, uitrolt, bewaakt en verbetert. Het doel is dat een model niet alleen een keer live gaat, maar ook blijft presteren als de omstandigheden veranderen.

DevOps gaat over software waarvan het gedrag in code vastligt. Een machine learning-model leert zijn gedrag uit data, en die data verandert. Daardoor kan een model slechter worden terwijl er geen regel code is aangepast. MLOps voegt daarom versiebeheer van data en modellen, monitoring op drift en hertrainen toe aan wat DevOps al regelt, zoals automatisch testen en uitrollen.

Bij data drift verschuift de invoer: er komen bijvoorbeeld andere klanttypen of meetwaarden binnen dan in de trainingsdata. Bij conceptdrift verandert het verband tussen invoer en uitkomst, bijvoorbeeld doordat klanten zich na een prijswijziging anders gedragen. Conceptdrift zie je vooral door voorspellingen te vergelijken met de werkelijke uitkomsten. Voor Rijkswaterstaat ontwikkelden we een generieke monitoringpackage voor drift- en outlierdetectie.

Dat hangt af van hoe snel je data verandert, wat een fout kost en wanneer je de werkelijke uitkomsten terugziet. Bij een model dat betalingsachterstand voorspelt, weet je pas later of het klopte; tot die tijd stuur je op drift in de invoer. Het hertrainschema leggen we daarom per model vast, samen met de eigenaar.

We kiezen wat past bij je bestaande omgeving. In onze projecten werken we onder meer met MLflow voor experimenten en de model registry, Databricks, Azure DevOps voor CI/CD, Docker en Python-pakketten zoals Alibi Detect voor driftdetectie. In Microsoft Fabric kan dezelfde werkwijze met de ingebouwde MLflow-experimenten. We zijn Databricks Partner en Microsoft Partner.

Voor hoog-risico-AI stelt de AI-verordening onder meer eisen aan datagovernance (artikel 10), automatische logging (artikel 12), nauwkeurigheid en robuustheid gedurende de levenscyclus (artikel 15) en monitoring na ingebruikname (artikel 72). Na de digitale omnibus gelden ze vanaf 2 december 2027, voor AI in gereguleerde producten vanaf 2 augustus 2028. MLOps levert daarvoor bewijs, maar maakt een systeem niet vanzelf compliant. Of je toepassing hoog-risico is, beoordeelt een jurist of je compliance-afdeling; wij helpen met inventariseren, de risico-indeling voorbereiden en AI-governance.

Heb je één model dat zelden opnieuw wordt getraind en waarvan een fout weinig gevolgen heeft, dan is een volledige MLOps-straat vaak te zwaar. Code in Git, een vastgelegde trainingsrun en een eenvoudige controle op de uitkomsten volstaan dan. Is nog niet bewezen dat het model waarde oplevert, begin dan met data science. Verdere automatisering loont pas als er meer modellen bijkomen of de gevolgen groter worden.

Vragen over MLOps?

Stef Stoelwinder

Stef Stoelwinder

Business Development

Draaien jouw modellen al betrouwbaar in productie?

Vertel ons welke modellen je hebt en waar het wringt. Dan kijken we samen naar de route van notebook naar productie.

Vul een geldig e-mailadres in.

Laat ons weten waar we je mee kunnen helpen.