AIToday Live

S03E05 - Professionaliseer Machine Learning met MLOps

AIToday (Info Support & Aigency) Season 3 Episode 5

Ontwikkelde Machine learning-modellen moeten naast ontworpen en gebouwd ook beheerd worden. In de praktijk zien we valkuilen die een succesvolle implementatie van ML-modellen blokkeren. Een ML-model behoudt alleen de maximale waarde als deze professioneel ontwikkeld en beheerd wordt. In deze aflevering duiken we dieper in de valkuilen en hoe je machine learning professionaliseert met de aanpak van MLOps.

Stuur ons een bericht

Info Support
Info Support is de specialist in maatwerk software en leidend in kunstmatige intelligentie (AI).

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Schrijf je in voor onze nieuwsbrief en ontvang exclusieve toegang tot nieuws, blik achter de schermen en meer!

In deze aflevering van de AIToday Live podcast praten Niels Naglé, chapter lead Data & AI Info Support en ik, CTO bij Aigency, over het professionaliseren van machinelearningmodellen met ML-optie. Leuk dat je luistert. We zijn alweer bij de vijfde aflevering. Ja, het vliegt voorbij joh. Laten we er wat meer aan doen dit seizoen, anders zijn we er dadelijk alweer doorheen. Ja zeker, dat lijkt me ook een goed plan. De frequentie is ook een beetje hoger met onze bite-size afleveringen. Ja leuk, ik heb er weer zin in vandaag. We gaan het hebben over het professionaliseren van machinelearningmodellen met MLOps. Dus laten we daar maar meteen induiken toch? Ja, ML-ops. Neem ons mee. Wat versta jij eronder Joop, onder MLOps? Want de term komt natuurlijk veel, veel ervoor en veel artikelen. Nogal wisselend wat mensen eronder verstaan, dus ik ben wel benieuwd. Als we het over MLOps hebben, wat denk jij dan aan? Nou kijk, laat ik eens beginnen met waar je het voor nodig hebt. Dus wat wij veel in de praktijk zien is dat machinelearningmodellen ontworpen, gebouwd worden, die gaan naar productie en dan komt er een soort van zucht van verlichting. Hij staat er, klaar. Maar eigenlijk begint het dan pas. Als zo'n model niet goed beheerd wordt, dan staat een succes van zo'n machinelearningmodel uiteindelijk in de weg. Dus het kan niet heel goed hebben gedaan in de trainingsomgeving en dan ga je zien dat in productie dat je tegen van alles aanloopt. Daar zal ik zo direct even wel wat meer over vertellen. Dus als je maximale waarde uit het machinelearningmodel wil blijven halen, dan is het nodig dat die ook op een goede manier beheerd wordt. En wat ga je dan krijgen is dat je net als bij, misschien kennen mensen die term wel DevOps of DataOps, dat je de development, dus het ontwikkelen, bouwen op een bepaalde manier aanpakt, zodanig dat het beheer ook eenvoudiger wordt. Dat breng je samen en dat heet dan eigenlijk MLOps Machine Learning. Machine Learning, sorry, mijn microfoon die gaat even de verkeerde kant op. Die ga ik even anders zetten, anders hoor ik helemaal niks meer. Niels en ik nemen deze podcast nog steeds online op en hier ging er wat technisch bij mij mis, maar we hebben even geknipt en gaan weer door. Er ging even iets fout met mijn setup. Ik ga gewoon verder waar ik gebleven ben. Net als bij DevOps, DataOps, wat je gaat doen is dat je ontwikkel, bouw en beheer breng je samen in een gezamenlijk proces. Dus ML-ops staat ook voor Machine Learning en Operations samen. Dat zorgt ervoor dat je een aantal valkuilen die je hebt, misschien wat beter tegen kan gaan. Dus je gaat het ook meer zien als een life cycle dan eenmalige opleveringen, als een beleving? Ja, het is zeker een life cycle. Eigenlijk zou je beter kunnen spreken over een MLOps cultuur, waarbij je een aantal processen samen met tooling samenbrengt, waardoor je op een professionele manier ML-modellen kan bouwen en kan gaan beheren. Dus het is niet zeker niet alleen maar technologie, het is heel veel juist cultuur en aanpak en processen en afspraken met elkaar. Zeker, het gaat heel veel over cultuur. Het gaat heel veel over van waar sta je voor, wat wil je gedaan hebben, hoeveel wil je geautomatiseerd hebben, hoe wil je geautomatiseerd zaken getest hebben, hoe wil je monitoring inregelen, hoe wil je zorgen dat je geen discriminatie in je modellen hebt en hoe zorg je dat je dat vooral herhaalbaar hebt. Dus dat je niet eenmalig dat hebt ingeregeld met handmatige procedures, maar zodanig dat het geautomatiseerd is, dat als er iets afwijkt van de waarde die je gesteld hebt, een waarde in de zin van je policies en dat soort zaken, dat je daarop geattendeerd wordt en dat je een model niet in productie krijgt voordat je die voorwaarden voldaan hebt. Ja en dan nog wel een stukje verder, als het in productie is, dat je dat blijft monitoren en dat je daar blijft controleren, want de data verandert, de omgeving verandert, dat je dat meeneemt in jouw proces en ontwikkeling en daar continu ook over nadenkt. Ja, want ik heb een lijstje gemaakt van wat zijn nou eigenlijk valkuilen waar je tegenaan loopt als je dit niet doet. En die eerste is bijvoorbeeld dat je als je in de loop van de tijd je model niet monitoort, de prestaties van je model zul je ook zien dat die verslechterd. Dus je moet je prestaties moeten monitoren en als je je gegevenskwaliteit niet goed bewaakt, dan gaat dat ook mis uiteindelijk in productie. Datadrift hebben we, dan kunnen we misschien zo direct even uitleggen wat dat is. Je afhankelijkheden in productie moet je blijven managen, zowel modellen onderling ten opzichte van afhankelijkheden van data, maar ook van allerlei libraries die je misschien gebruikt weer in development. En je hebt een reproduceerbaar ontwikkelen en implementatieproces nodig. Dus dat zijn eigenlijk de vijf valkuilen en misschien kunnen we die eens wat dieper induiken. Laten we gewoon beginnen bij de eerste, een stukje monitoring. Ja, die monitoring. Kijk, wat je gaat doen uiteindelijk bij die monitoring is dat je, daar heb je natuurlijk allerlei verschillende metrieken kan je gebruiken. Het probleem is dat je model in productie gaat andere data zien dan de data die je hebt gebruikt voor je trainingsset. Dus dat kan betekenen dat je het sowieso in een real life setting slechter doet dan tijdens je training. En dat is bijna altijd wel zo. Dus je hebt een trainingsset, je hebt een testset en je ziet al dat die het vaak tegen de testset al wat slechter doet, omdat die in die testset daar zit data die die niet in de trainingsset gezien heeft. Dus daar zie je al een degradatie van de prestaties. Dat zijn vaak een paar procentpunten. En in productie moet je dat in de gaten houden. Wat je daar waarschijnlijk ook gaat zien is dat je allerlei outliers krijgt die je niet hebt voorzien, die niet in die trainingsset zaten, maar die wel voorbij komen. En als ze vaker voorbij komen, wil je ze misschien ook gaan opnemen in je model. Dus ga je ze ook aanvinken, als zijn er van hier moet je ook optrainen, dit moet je ook leren. Dus leren is geen eenmalige cyclus. Een goed model is uiteindelijk vele malen getraind, omdat je gevallen krijgt die je nog niet gezien hebt. Een stukje context die een peripatie ook verandert. Dus ja, echt een levend organisme wat je moet voeden, bijhouden, af en toe polsen of het goed gaat. Ja, anders blijft hij zeg maar zo slim of dom als dat je hem de eerste keer getraind hebt en gaat er verder niks veranderen. Je noemde net wat metrieken, wat voor metrieken zijn dan de meest voorkomen die je in de praktijk tegenkomt voor het monitoren van die modellen? Nou ja, dat hangt uiteindelijk eigenlijk helemaal af van waar je het model ook op geoptimaliseerd hebt. Dat zijn altijd keuzes. Dus als we even een hele eenvoudige pakken, iets als nauwekeurigheid. Als je hem daar op geoptimaliseerd hebt, dat doe je meestal niet hoor, maar stel een nauwekeurigheid. Dan kan je die ook in de gaten houden in productie. Want hoe nauwkeurig is uiteindelijk dat je nauwkeurigheid ten opzichte van wat je in je trainingsset of in je dataset hebt gezien, of in je trainingset of testset hebt gezien. Maar wat misschien natuurlijk interessanter is, is dat je gaat bijhouden van bijvoorbeeld je false positives of je false negatives. Je kan je voorstellen dat je in de ene context dat het belangrijker is om op false positives te optimaliseren dan op false negatives of juist andersom. Nou ja, dat moet je gaan monitoren. En om dat te monitoren, moet je vaak wel iets gaan inregelen. Dat je ook weet dat er false negatives langs zijn geweest. Die kan je niet automatisch aanvinken. Dus als je een diagnose doet in een ziekenhuis, wanneer weet je dat het een false positive was. Dus die gegevens moeten wel weer terug. Dus dat moet je eigenlijk zien als onderdeel van je product, wat gewoon bij je model hoort. Die metrieken zijn gewoon onderdeel van de oplossing. Vandaar dat je waarschijnlijk ook zegt, het zit veel in de cultuur. Mensen moeten het als een gemeen goed gaan ervaren dat dit er gewoon bij hoort. Ik zit net op datum, ik ben net op een conferentie geweest met datums. Ik zie zoveel raakvlak. Dat je niet weet wat erin gaat komen en wat er vervolgens weer uit moet gaan komen. Dat verandert gewoon continu. En dat goed kunnen monitoren. Klinkt heel makkelijk om zo te zeggen. Maar er komt ook nog heel veel bij kijken. Er komt heel veel bij kijken. Dus dat betekent ook dat je dat echt in je ontwerpproces mee moet nemen. Dat je weet van hier optimaliseren we op. Hoe weten we nou dat daar problemen ontstaan? Dus ook dat deel moet je ontwerpen. Het begint al heel simpel door gewoon de vraag te stellen aan elkaar. Hoe gaan we dit in de toekomst kunnen valideren of die nog goed is of goed genoeg is. Precies. Dus dat is inderdaad makkelijk gezegd, maar wat moeilijker gedaan. Dan krijg ik ook nog een telefoon. Het gaat vandaag goed zo. Ja, volgende keer gaan we gewoon weer aan de keukentaf zitten. Ja toch? Andere die ik genoemd had is natuurlijk even kijken. Ik pak mijn lijstje erbij. O ja, die gegevenskwaliteit die niet goed wordt bewaard. Nou ja, ik denk dat jij daar nog wat beter van kan zeggen dan dat ik dat doe. Wat dat betekent. Ja, daar komt het stukje data op. En dat is denk ik dat gewoon ook gemeengoed moet gaan worden. En daar zie je hetzelfde als bij MLOps. Het is gewoon continu de vraag stellen. Hoe houden we in de gaten? Wat verandert er? Is het goed wat er verandert? Is dit wat we verwachten? En dat geldt niet anders voor de data die richting ML gaat als via reporting of data warehouses of andere data platformen. Het gewoon de mindset hebben om continu de thermometer eigenlijk te hebben waar alle data langs stroomt. Dat wordt gewoon steeds belangrijker, vooral als je het met ketens te maken gaat hebben. Welke keet heeft er aangezeten? Wat is er veranderd? Wat niet? Wat wel? En ook die metrieken inderdaad. Hoe divers is de data? Zie je wel steeds meer dat dat gemeengoed moet gaan worden. Maar ook hier, makkelijk gezegd, moeilijk in de uitvoer. Want ja, het komt overal terug. Het is overal metadata. Dus om dat goed te doen is het kleine stapjes maken. En het in de mindset en de cultuur meenemen. Hoe belangrijk die kwaliteit in die monitoring is. Ja, precies. En waar we het net over hadden van een model wordt niet één keer getraind en daarmee is het klaar. Dus als jij weer traint met historische nieuwe gegevens en daar is die kwaliteit ook niet goed van. Wat je aan het doen bent is dat je die vervuiling ook weer terugkrijgt in die training, waardoor de prestaties van je modellen nog verder zullen verminderen. En je krijgt een loop waarin de problemen zich steeds verder opstapelen. Ja, en wat mij betreft zit daar ook een stukje cultuur bij DataOps. Met elkaar het belang zien van die data kwaliteit. Want in de praktijk komen we nog heel vaak tegen dat die data gewoon fout is aangeleverd. Daar moeten we niet meer genoeg mee nemen, jongens. We moeten gewoon om de tafel gaan van waar zit dan die fout? Kom erbij, wat gaat hier fout? Wat is de impact hiervan? Want heel vaak beseffen mensen niet wat er in de keten erachter zit. Wat het belang is van die controle aan de poort bij invoer van de applicatie of in een systeem. Voor een deel is het echt ook wel automatisierbaar en testbaar. Dus als jij goed in een data catalog vastlegt hoe jouw data eruit ziet, tenminste wat je verwachtingen zijn. Dus je kan heel goed vastleggen van wat voor type verwacht ik? Mag het wel of geen lege velden bevatten? Bandbreedte? Ja, precies, minmax waarde, distributie. Er zijn echt heel veel karakteristieken die je van een dataset kan vastleggen. Waardoor je ook daar gewoon testen op kan schrijven. Dat als je aan de input krijgt, die zegt van hey voldoet dat überhaupt eigenlijk wel aan mijn metadata beschrijving? Zo niet. Dat is een signaal. Wat doen we er dan mee? En wie gaat het oppakken? Want in het begin is het effect misschien klein, maar naarmate je verder de keten in gaat is de impact misschien wel huge, maar weet je het nog niet inderdaad. Precies. En ook daar kan AI juist behelpen om die anomalies juist in die datastromen te ontdekken. Ja toch? Ook hier, dat doe je vaak, wordt het al gedaan in de praktijk, dat alle datasystemen die worden gemonitord en geprofiled, kijken of er data in zit. Maar ook daar zie je vaak dat het een eenmalige acquisitie is. Even kijken wat nu de kwaliteit is. Maar ook dat moet een continue stroom zijn om dat te blijven monitoren. Dus we moeten van periodiek naar continu. En dat is een stap die gewoon gemaakt moet gaan worden. Ja en als je het hebt over professionalisering. We zijn begonnen met professionaliseren van het bouwen van machine learning modellen met MLOps. Dus dit wel echt een hele belangrijke stap wat jij zegt. Het is niet periodiek, maar het is echt continu. Ja en dat vergt een andere mindset. En dat seipelt dan door in de technologie en de processen die je hebt. Maar het is de mindset van we moeten hier continu mee kunnen kijken. Precies. En hier lopen we natuurlijk echt wel heel vaak tegenaan. Ja en er is ook nog geen oplossing. We zien heel veel goede initiatieven. Mensen zien het belang er ook steeds meer van in. Dus dat is het mooie. Maar de oplossing en de automatisering qua tooling om die datastromen die continu zijn goed te kunnen monitoren. Die moeten ook nog verder ontwikkeld worden. Ook daar is gewoon een volwassenheid in de markt daarop voor het automatische testen. Het begint wel steeds meer te komen. Maar het is er nog niet zoals je zou willen. Ja en voor de data engineers die luisteren. In die zin zeg maar helpt de machine learning die er bovenop komt. Want die vergroten dit soort problemen uit. Waardoor de noodzaak om dit aan te pakken ook steeds groter wordt. Ja zeker. Dat is zeker een mooi effect die erbij komt kijken. Omdat AI gaan we mee starten. Dan wordt de datakwaliteit als die nog niet is, wordt die in kaart gebracht. En vice versa als je weet waar de kwaliteit goed is. Dan kan je daar de betere AI casus op loslaten. Dus het versterkt elkaar. En dat is echt een hele goede ontwikkeling. Precies. De volgende die we hebben was dat de data drift niet beheerd wordt. Dat het drift moet misschien even uitgelegd worden. Wat je hebt is dat je je omgeving kan zodanig veranderen. Dat je heel andere type data krijgt. Dat je model daar niet meer op toegespitst is. En ik denk het allerbeste voorbeeld is gewoon de switch dat wij voor corona in corona kwamen. Eén keer veranderde voor heel veel bedrijven hun context. Als je bijvoorbeeld in een webshop veranderde de wereld. Als je in een ziekenhuis veranderde de wereld. Als je misschien in het aanleveren van horeca voorraden veranderde je wereld. Dus wat daarvoor allemaal normale data was. Wat dan door je machine learning modellen gewoon geprocesd kon worden. Dat werd totaal irrelevant. Dit was echt een knik. En zo'n knik die voel je, dus die begrijp je wel. Het probleem met data drift is dat dit heel geleidelijk kan gaan. En als je dat niet in de gaten hebt, nemen dus de prestaties van je model geleidelijk af. En op een gegeven moment zit je op een punt dat je gewoon echt verkeerde uitkomsten krijgt uit je model. Waardoor je ook verkeerde besluiten gaat nemen. En dat zou wel heel erg treurig zijn. Dus hier moet je ook heel goed kijken naar metrieken. Ik weet dat je zich gaat vragen, maar ik ga er even niet op in. Ik denk dat dat gewoon te specifiek is. Er zijn echt allerlei manieren om data drift te detecteren. Het is niet eenvoudig, wel te doen. En daar wil je ook een continu proces van maken. Dus er moet gewoon een achtergrond meelopen. En daar kan je ook denken aan bepaalde distributieverschuivingen. Er zijn allerlei manieren om daar achter te komen. Maar dat is belangrijk vooral dat je dat ook in je ontwerp meeneemt. En ze horen het voornamelijk omdat het geleidelijk is, waardoor het niet opvalt. Dus het ouderwetse piepsysteem van "hé jongens, het is echt wel heel raar wat hier gebeurt", die krijg je niet omdat het een heel kleine afwijking is. En daarom zou je daar wel automatisch op moeten gaan monitoren. Om die kleine changes continu, dat dat toch weer een signaal gaat worden. Dat daar inderdaad weer een verband in zit. Je kan ook nog kijken naar modellen die wat minder last hebben van data drift. Dus dat hangt ook een beetje af van welk algoritme je kiest. Hoe erg die daar last van heeft. Hoe gevoelig die daarvoor is inderdaad. Dus ook dat gaat om weer een proces waar we het net over hadden. Dat je dat meeneemt, by design, goed over nadenkt. Wat moet je ermee? Dat zijn natuurlijk allemaal afwegingen. Hoe goed is het model? Hoe goed moet hij presteren? Waar optimaliseer je op? En past dan een net een ander type die robuuster is op dit gebied, past dat dan ook nog? Moet je gewoon even meenemen. En nu het zo nog een keer herhaalt, komt wel iets bij mij naar boven. Waar ik zeg van, ja, dan moeten we zo continu wel weten wat was ons doel met het model? Waar wilden we naartoe? Zodat je dat ook aan het doel kan blijven toetsen. Volgens mij wordt dat ook nog wel eens onderschat. Het model staat er, het moet nou eenmaal gewoon draaien. Maar waarom hadden we hem? Hoe willen we hem toepassen? Wat is de ethiek en de responsibility gevoel bij dit model? Ook continu kunnen blijven toetsen. Vergeet dat alsjeblieft niet. Ja, en dat is wat anders dan dat je zegt van, hé, mijn accuratesse is heel hoog. Mijn F1 score is super. Weet je, allemaal dat soort fijne metrieken. Die area onder de curve hartstikke goed. En uiteindelijk doet die niet waar je hem voor gemaakt hebt. Ja, wordt die ook goed gebruikt. Dat moet je ook meten. En de afname daarvan gaat dat ook goed. Dus dat zijn ook belangrijke metrieken die je niet moet vergeten. Inderdaad. Precies. Ja. Nee, dat is een hele goede toevoeging. Ja. Dan zitten we op de afhankelijkheden. Wat ik al een beetje aangaf, is van je hebt er twee. Eén is gewoon heel erg technisch is in je code. Ja, de library dependencies. De bibliotheken die je gebruikt. Heb je daar de juiste, heb je daar dezelfde versies. Maar is het ook, het kan zomaar zijn dat je gewoon verschillende versies van één bibliotheek gewoon hebt zitten, zeg maar, in je codebase. Weet je, alleen daar begint het al. Dat je afhankelijk van de versie, dat je dan een iets ander resultaat krijgt. Dat kan natuurlijk nooit waar zijn. En aan de andere kant heb je natuurlijk ook van, jouw model kan weer afhankelijk zijn van de uitkomst van andere modellen. Dus dat moet je goed in de gaten houden. En toch ook weer die traininggegevens. Je bent afhankelijk van je traininggegevens. Dus wat neem je wel op in je traininggegevens, wat niet. Want je hebt daar, dat je het risico loopt op overfitting, underfitting. En als je dat hebt, weet je, dan generaliseert je je model minder goed, waardoor die ook weer minder goed presteert. En dit is best wel een veelvolkomen probleem. Dat bijvoorbeeld de balans van, stel je gaat klassificeren. En je hebt, weet ik veel, tien klasses waar je naar klassificeert. En één klasse die heeft gewoon, bij je eerste ontwikkeling, weet je, ga je het allemaal netjes balanceren. Zeg je nou, allemaal ongeveer evenveel voorbeelden in de trainingsset. Maar als je zonder na te denken, bij de hertraining, gegevens uit productie neemt, kan dat helemaal uit balans raken. Omdat je, stel je gaat e-mailtjes, ga je klassificeren en je krijgt veel meer e-mail binnen over problemen met inloggegevens. Wat niet onwaarschijnlijk is, als je dat soort dingen doet. Als je dat allemaal maar gewoon onbeperkt meeneemt, ja dan gaat die uiteindelijk, worden de prestaties van het model minder, omdat je een niet gebalanceerde trainingsset hebt. Dus dan zal die bijna alles op een gegeven moment als inlogproblemen gaan klassificeren. Omdat je zelf die problemen hebt geïntroduceerd. Ja, en dan bij die eerste technologisch gezien is het inderdaad nog wel redelijk te automatiseren. Ik denk die andere misschien ook nog wel. De lineage of in ieder geval de afhankelijkheden zijn prima natuurlijk in kaart te brengen op codebase niveau. Die je net noemt, die is natuurlijk technisch ook nog wel te voorkomen. Maar dat ze ook wel continu weer het besef hebben en even de tijd pakken om terug te kijken. Wat was er toen ingegaan? Wat moet er nu in? Ja, daar gaan we om. Ja, en dat automatiseer je. Dat je een gebalanceerde set houdt. Dat juist zeg maar zoveel mogelijk automatiseren van dit soort zaken. Zeker weten, want het wordt alleen maar meer. Dus automation is ook een must, maar dan ook wel goed doen. Ja, precies. Laatste, geen reproducerbaar ontwikkeld en implementatie proces. Daar kan je denk ik alles bij voelen. Als dat niet reproducerbaar is, dat je gewoon in de problemen komt. Dat je niet meer terug kan voor probleemoplossingen. Dat je het niet goed herleidbaar hebt waar besluiten uitkomen. Dit lijkt een soort van inkopper. Maar het probleem is dat dit gewoon heel veel gebeurt. Dat er uiteindelijk een besluit ergens is genomen en gewoon niet meer achteraf te achterhalen is van hoe is dit nou tot stand gekomen? Welke data is gebruikt? Welk algoritme is gebruikt? Welke versie is gebruikt? Ja, dat is wel dramatisch. Ja, dat moet echt beter inderdaad. Terwijl, vanuit de softwarehoek is het CI/CD all the way altijd. We zien dat inderdaad op data en op AI gebied dat het nog minder is. Ja, want ook hier moet je even induiken van hoe doe je dat? Hoe krijg je dat goed voor elkaar? Hoe zorg je dat dat vooral geautomatiseerd gaat? Zeker versionering. Als je dat niet geautomatiseerd hebt, dan loopt dat uiteindelijk uit de pas. Handmatige versionering is echt een no-go. En een extra uitdaging bij machine learning is dat je niet alleen maar je code versioneert, zoals wat je bij software development doet, maar dat je je data, je trainingsset, je testset, allemaal dat soort dingen, alles wat je gebruikt, zeg maar je feature set, moet je versioneren samen met het model en de code om dat allemaal aan elkaar te knopen. En als je nog explainable AI gebruikt, wil je ook nog eens een keer dat deel erbij versioneren. En dat alles bij elkaar, dan heb je pas een versie die je in ieder geval terug kan halen. Dan is het reproduceerbaar. Ja, dan kan je het ook addaten. En herhaalbaar is in ieder geval dat je zoveel mogelijk geautomatiseerd hebt, dat zoveel mogelijk ook gelijksoortig behandeld wordt. Ja. En daar moet de tooling ook nog wel in meegroeien natuurlijk. Er moet nog veel handmatig ook wel uitgeprogrammeerd worden, merk ik. Op de data vlak en AI vlak is dat ook nog wel. Dan beginnen er wel steeds meer diensten te komen die dat bij je ondersteunen. Maar dan moet je wel even goed de tijd voor pakken om dat goed in te richten. Als je daarna gaat automatiseren, doe dat gewoon goed de eerste keer en iterateer daarna daarop door en blijf dat ook door ontwikkelen. Het is eigenlijk een subproduct van je product, waar ook gewoon continu aandacht en energie in gestopt moet worden. Iedere kleine verbetering in die automatisering is voor de volgende 20, 50 producten die ook weer geautomatiseerd worden ook waardevol. Ja. En nog makkelijker is als je een manage platform afneemt, bijvoorbeeld bij Info Support, dan zijn dit soort dingen gewoon voor je geregeld. En dan moet je ook denken, je hebt ook nog te maken met security, privacy, schaalbaarheid, allemaal dat soort elementen die we nu nog niet eens benoemd hebben, waar je ook uiteindelijk in je MLOps eigenlijk mee wil nemen. Dat dat allemaal getest wordt. Hoe schaalbaar is je model? Het is misschien leuk dat hij het op je testset een beetje performt, maar wat nou als daar enorme lood op komt? Wat gebeurt er dan? Dus dat maakt het leven nog makkelijker, want dan is het gewoon voor je gedaan. Ja. En valideer dat dus ook als je daar gebruik van gaat maken. Wat is daar al voor ingeregeld? Waar word ik in ontzorgd? En wat is er nog niet geregeld? Maar stel die vragen. Challenge daar de software of de leverancier op om daar met elkaar kritisch naar te kijken. Ik denk dat dat heel belangrijk is. Zeker. En ook niet alles kan voor je ontzorgd worden. Want net wat we erstraks zeiden, het hangt echt van je context af. Wat wil je? Dus daar moet je inderdaad heel goed rekening mee houden. Ja. Organisatiewaarden die doorcijpelen in de modellen en de uitkomsten die je daar wil bereiken met elkaar. Ja, dat kan je niet wegautomatiseren. Dat zit in je organisatie. Dat zit in het hart en ziel van de organisatie. Ja toch? Ja, zeker. Dus ik denk... Oh, sorry. Wat met name dan nog wel een stukje is, er zit heel veel automatisering, heel veel techniek in. Maar laten we ook niet vergeten wat we net ook al gezegd hebben. Het is ook een cultuur. En een cultuurverandering gaat niet zomaar. Dat is echt. Het is een marathon en het is geen sprint. Dat is volhouden, doorzetten, de kernwaarden daarvan, van belangstelling waarom doe je dit. En daar kritisch naar elkaar blijven zijn om daar naartoe te werken. Het gaat niet zonder slag of stoot, is mijn persoonlijke ervaring. Nee, maar als je dit... Kijk, je hoeft het ook niet in één keer te doen. Dus je kan het in stappen doen. Zeg van, nou weet je, dit zijn de grootste risico's. Die willen we als eerste afdekken. En zo kun je wel groeien. En dat is denk ik ook een mooie opstap naar de afsluiter. Het gaat over professionaliseren. Dat is een werkwoord. Het is het professionaliseren van machine learning met MLOps. Dus je werkt daar ook naartoe. Stap voor stap. Zodanig dat je... Nou, als je op een gegeven moment terugkijkt en je denkt van, zo, weet je, die problemen die hebben we toch allemaal mooi opgelost. En het gaat veel soepeler. En we hebben uiteindelijk veel betere modellen in productie. En de reflectie daarop inderdaad. Terugkijken naar waar in het verleden. Wat is de effect daarvan? En daarvan die successen vieren. En ook het verhaalwerk vieren. Want daar kan je op verbeteren. En zo doorgroeien. Dus het lerend vermogen. Niet alleen van de modellen, maar ook van de organisatie, van de teams. Komt hier gewoon mooi naar voren. Ja, nou, cool. Was dat hem alweer voor deze keer, denk ik. Dat was hem zeker. Leuk. We vinden het leuk dat je luistert. Als je geen aflevering wilt missen, volg ons dan in je favoriete podcast app. Wat we ook leuk vinden als je op LinkedIn laat weten wat je van onze podcast vindt. Tot de volgende keer. Tot de volgende keer. Dag. Dag..

People on this episode