MLOps: Waarom is het formuleren van het probleem zo belangrijk?

Onlangs schreef ik over het belang en de noodzaak van het hebben van een gedegen MLOps proces. Daarbij introduceerde ik het onderstaand diagram. Dit is een simplistische weergave van het framework om Machine Learning modellen te operationaliseren – en net zo belangrijk, maar minder evident – operationeel te houden. In deze blogpost wil ik dit proces verdiepen en specifiek in gaan op de eerste stap in het framework, namelijk de ‘Problem Formulation’. Letterlijk gezien gaan we het probleem formuleren en wil ik het breder trekken door de spelers te introduceren die voornamelijk in deze eerste fase actief zijn en daarnaast ook de overige rollen te introduceren binnen het gehele MLOps proces. Aan de hand hiervan adresseer ik ook de requirements voor de rollen in die eerste fase.

High level overview MLOps – bijbehorende fasen en betrokken spelers

Wie zijn betrokkenen en welke eisen stellen zij aan MLOps?

Zoals ik in het diagram hierboven weergeef, werken verschillende rollen in een het MLOps proces samen. Naast de data scientists, wiens voornaamste taak het ontwikkelen van de ML-modellen is, zijn het de data engineers, software engineers, Subject Matter Experts (SME’s), analytics architects en riskmanagers die ervoor zorgen dat ML-modellen in productie hun investering waard zijn en blijven.

Data Scientist

Het adopteren van de MLOps strategie zorgt voor een ingrijpende verandering in het werk van data scientists. Uiteraard in positieve zin! Daar waar zij nu nog vaak moeite hebben om hun ideeën en initiatieven om te zetten naar schaalbare oplossingen, mede veroorzaakt door het feit dat zij vaak met afwijkende tooling en in geïsoleerde (data)omgevingen werken, zal MLOps deze pijnpunten voor hun adresseren en daarmee al hun inspanningen belonen. Om een iets beter beeld te geven van de pijnpunten waarover we het dan hebben, een kleine situatieschets: 

Piet is onderdeel van een klein data science team. Het team staat voor de opdracht om een ML-model te ontwikkelen en deze later in productie te brengen. Initieel hebben ze alleen toegang tot een data dump die vriendelijk voor hen bij elkaar gequeried is “want die data pijplijn, dat komt later wel”. Ze beginnen vol goede moed aan alle facetten van de data science pijplijn: data opschonen, feature engineering, exploratie, modeleren, model-hyperparameters tuning, etc. In een volgende blogpost over ‘de modeleerfase in MLOps’ zal ik specifieker ingaan op al deze facetten. Al tamelijk snel, in een van hun standups, verblijden ze de product owner met het nieuws dat ze aardig wat vooruitgang hebben geboekt en dat ze een eerste model hebben staan. Wel vermelden ze erbij dat er nog wat moet worden getweaked aan het model omdat de performance suboptimaal is en ze ook nog tegen wat andere eigenaardigheden aanlopen. Direct wordt er in diezelfde standup aangeboden dat er wel even een nieuwe query voor ze wordt gerund om hen zo van meer up-to-date data te kunnen voorzien, waarin de recente ontwikkelingen die het bedrijf heeft doorgemaakt zitten verweven. Oja, en als ze dan toch bezig zijn… of ze ook niet zo’n zelfde model kunnen maken voor de vestiging in Frankrijk: “business/data bijna helemaal hetzelfde, maar toch ook net niet helemaal”.

De standup is over, bijna iedereen is enthousiast want er is appetijt voor hun model, ze krijgen weer verse data en er zijn ideeën genoeg om het model te verbeteren. Alleen Piet druipt stilletjes af. De moed zakt hem in de schoenen, want hij weet wat dit betekent. Hij heeft dit vaker meegemaakt, hij weet wat er gaat gebeuren. Hij weet dat de taken zullen worden verdeeld en dat de één gaat werken aan de dataprocessing (op de nieuwe data), er zullen nieuwe features worden gecreëerd. De ander legt zijn hand aan het model en weer een ander begint alvast parallel te werken aan het model voor Frankrijk. Al snel zal er verwarring ontstaan omdat bepaalde functies en modellen alleen maar werken op de ene set data, terwijl andere functies alleen maar van toepassing zijn op ‘het Frankrijk-model’. Er zullen verschillende pijplijnen door elkaar gaan lopen en het voelt of alle performance-metingen appels met peren vergelijken is geworden. Piet is ongerust en voorziet chaos. Ook weet hij in zijn achterhoofd dat er een moment gaat komen dat hij en zijn team de boel moeten overdragen/beschikbaar maken omdat ze uit of uit dienst gaan of omdat nu ook team Duitsland oren heeft gekregen naar het model. 

Het is duidelijk, Piet snakt naar een MLOps framework waarbij ze zoveel mogelijk structureren en aan versiebeheer kunnen doen. Ze willen bijvoorbeeld bijhouden wanneer en met welk resultaat, welk model, met welke hyperparameters er op welke data heeft gerund, en welke versie van de code daarbij hoort. Daarnaast willen ze mogelijkheid hebben om hun modellen snel en veilig naar productie te brengen. Dit houdt in dat er een pijplijn klaar staat die hun modellen ‘packaged’, automatisch test en een plekje geeft in het IT-landschap zodat andere applicaties gebruik kunnen maken van het model.

Denk hierbij ook weer aan het management van model versies (het model voor Frankrijk, het model voor productlijn X, het model dat alleen werkt op de data van het eerste half jaar, etc.). Als laatste willen ze demogelijkheid hebben om tests te ontwikkelen en uit te voeren die regelmatig de kwaliteit van hun geproductionaliseerde modellen bepaalt. Dit moet gemonitord worden en op een centrale locatie toegankelijk zijn. Wanneer dit nodig blijkt te zijn willen zij dat er een mechanisme/pijplijn aanwezig is die automatisch het model kan bijschaven om zo de kwaliteit weer te verbeteren. Omdat het model afhankelijk is van de data die er binnenkomt en zo dus ook op een bepaalde manier getraind is, willen zij ook gealarmeerd worden wanneer het dataformaat veranderd of de ‘inhoud’ van de data over de tijd langzaam is gewijzigd.

Subject Matter Expert (SME)

Daar waar de meeste andere teamleden alle technische kennis in huis hebben om de MLOps succesvol te maken, ontbreekt het die teamleden vaak aan het hebben van echte businesskennis. Juist hiervoor maakt de SME onderdeel uit van het team. Hij/zij zal de rest van het team voorzien van de juiste business context.  Gedurende het proces zal de SME uitdrukkelijk in de gaten houden of het ML model het oorspronkelijke probleem gaat oplossen en zal het team bijsturen wanneer nodig. Voor de SME is het dus belangrijk om in het MLOps proces, in business taal, de model performance te kunnen begrijpen en te volgen. Daarnaast eist de SME om het model van ‘commentaar’ te voorzien. Dat wil zeggen dat als de SME ziet dat het model iets verkeerds voorspelt, hij/zij daar een feedback mechanisme voor heeft en zo het model van zijn kennis kan voorzien om zo de performance te verbeteren. Omdat juist in deze eerste fase, het formuleren van het probleem, een belangrijke rol is weggelegd voor de SME zal er na de verschillende rolbeschrijvingen uitvoeriger op de rol van de SME worden ingegaan.

Analytics Architect

De (data) analytics architect is een rol die andere/additionele skills vereist in vergelijking tot een traditionele data architect. Naast de kennis op het gebied van dataopslag, data pijplijnen dient de analytics architect kennis te hebben hoe deze machine learning modellen deze data consumeren. Zij kunnen geschikte technologieën selecteren uit de vele beschikbare open source en commerciële offers die de hedendaagse markt te bieden heeft. Dit is een verantwoordelijke taak want de performance van modellen in productie valt of staat vaak met de technologieën die hierachter zitten. Daarnaast evalueert de analytics architect de niet-functionele attributen zoals security, gebruik en stabiliteit. De voorwaarden die een analytics architect hiermee dus stelt aan het MLOps proces zijn onder andere dat zij een overzicht willen hebben van de modellen hun bijbehorende resources. Ook moet de pijplijn zo flexibel en toegankelijk zijn dat zij kleine architectonische veranderingen makkelijk kunnen doorvoeren wanneer dit nodig blijkt te zijn. 

Riskmanager

De riskmanager heeft zowel aan het begin van het MLOps proces als aan het eind de belangrijke taak om te beoordelen of het ML-model een risico is voor het bedrijf.  Veel handmatig audit werk wordt uit handen worden genomen wanneer zij een toegankelijk overzicht van alle modelversies, dataversies en performance metingen hebben.

Data Engineer

Elk ML-model staat of valt met de data waarop het model getraind en getest wordt. De data engineer is verantwoordelijk voor het creëren van de data pijplijnen die het model hierin voorzien. Aan het begin van een MLOps cyclus staat de data engineer in direct contact met de SME om de juiste data(bronnen) te identificeren voor het traject, om zo naderhand met die opgedane business kennis de data te preparen voor gebruik. In de fase van realisatie van de modellen werkt de data engineer nauw samen met de data scientist om zo nog specifiekere data pijplijnen te realiseren die aansluiten op de inputvereisten van de modellen. Een belangrijke voorwaarde van de data engineer is dat MLOps moet voorziet in het inzoomen op elke individuele detailstap in de datapijplijn.

Software engineer

Aan sec een ML-model alleen heb je niet veel als organisatie. Het ML-model moet bestaansrecht krijgen en als asset zijn werk gaan doen. De software engineer zorgt er dan ook voor dat het ML-model een plaats krijgt in het applicatielandschap van de organisatie. Hiervoor werkt hij/zij vanaf de modelontwikkelfase al nauw samen met de data scientist om ervoor te zorgen dat, zodra het model klaar is dit model soepel integreert in de applicatie CI/CD pijplijn en zo geautomatiseerd op zijn landingsplaats terecht komt.

Fase 1 MLOps – bijbehorende stappen en betrokken spelers

Business Opportunity

Nu dat we kennis hebben gemaakt met de hoofdrolspelers van MLOps wil ik de eerste fase, namelijk de ‘formulering van het probleem’-fase, verdiepen. Dit is met name een niet-technische fase, waarin het begrijpen van de business de eerste en tegelijk erg bepalende stap is in het proces. Zoals het diagram aangeeft start het MLOps proces met de ‘Business opportunity” en dit impliceert dat we dus ook helemaal niet aan MLOps moeten denken wanneer er geen probleem bestaat. Mocht er zich nu wel een business probleem of verbeter mogelijkheid voordoen dan, ongeacht de aard van het probleem, is het zaak deze zo nauwkeurig te identificeren/analyseren zonder direct in oplossingsmogelijkheden te duiken. Hier is dus een grote rol weggelegd voor de SME. Daarnaast is het van belang om goed te communiceren met de verschillende stakeholders om zo alle relevante informatie & achtergronden voor de volgende stappen boven tafel te krijgen.

Requirements

Hierboven werden de functionele requirements van de spelers van MLOps al benoemend en deze dienen vooraf als zodanig te worden beschouwd en kunnen eventueel worden meegemomen in een checklist. De checklist kan er toen dienen om te bepalen of de volgende fase van MLOps ingezet kan worden. Echter, de voorwaarden die we specifiek in deze fase voor ogen hebben hebben te maken met het opstellen van ‘Objective Key Results’ (OKR’s).  Hoe meer aandacht er nu aan de requirements worden besteed, hoe makkelijker het later wordt om onder de (MLOps) streep te evalueren of model succesvol is of niet.

Omdat niet elke probleem met Machine Learning kan worden opgelost is dit het moment waarop een Data Scientist betrokken dient te worden. Anders dan vaak wordt gedacht, dient het niet zo te zijn dat een DS puur en alleen zijn rol heeft binnen de model ontwikkel fase. Hij/zij moet betrokken worden in het formuleren van het business probleem en bediscussieert de OKR’s met een business expert om te bepalen of ML daadwerkelijk kan bijdragen om de opgestelde OKR’s te behalen. Dit proces kan flink wat tijd kosten maar is noodzakelijk. Het is namelijk gelijk een beslismoment of er moet worden ingezet op het ontwikkelen van een ML model, dan wel het beëindigen van het MLOps traject en de oplossing ergens anders te zoeken.

Na dit ‘go/no-go’ moment en nadat we hebben bepaald dat het probleem vertaald kan worden naar een bijbehorend ML probleem, hebben we aan de hand van het concrete probleem en de gekwantificeerde OKR’s genoeg context en is het inzichtelijk welke data precies nodig is. Deze informatie maakt onderdeel uit van de requirementslijst.

Nogmaals, deze fase helpt om op een eenduidige manier transparantie te verkrijgen in welke probleem er is, wat de oplossing moet zijn en welke waarde die oplossing vertegenwoordigt voor de organisatie.

Explore

Om dit onderdeel duidelijk te maken, ga ik er nu even voor het gemak van uit dat we toegang hebben tot de benodigde data en dat het DataOps onderdeel van MLOps staat. Wat er voornamelijk in deze stap gebeurd is het exploreren van de data om daarmee de vraag te beantwoorden of de data toereikend is om aan alle requirements te voldoen. Tijdens de exploratie is er veel interactie tussen de SME, de stakeholders en de data scientist om de relatie in de data te ontdekken en te begrijpen. Ook hier geldt weer, pas als de data voldoet aan de requirements dan kunnen we gaan starten met brainstormen over de te realiseren typen ML modellen. Verder kunnen we nu ook meer specifieke ML metrieken en KPI’s gaan opstellen. Je kunt hierbij denken aan het opstellen van penalty’s (in Euro’s) voor elke mis-classificatie die het model doet. 

Analytical Framework selectie

Nu dat scherp voor ogen hebben welk probleem we gaan oplossen en wat Machine Learning daarin betekent, selecteren we de passende frameworks. Het betekent niet automatisch dat er altijd al direct een specifieke richting gekozen moet worden, maar sommigen frameworks of libraries lenen zich beter voor bepaalde use-cases dan andere. Denk bijvoorbeeld aan ML gedreven services zoals beeld- of spraakherkenning op mobiele of edge devices. Om hierbij in real-time, bij een onbetrouwbare connectiviteit of waarbij ‘latency’ belangrijk is, op een secure en privacygevoelige manier gebruik te kunnen maken van je model is het verstandig om een ML framework te kiezen die juist hiervoor geoptimaliseerd is (bijv. Core ML, TensorFlow Lite, PyTorch Mobile, Firebase’s ML Kit, enz.). Of stel, er is vraag naar ‘een bot’ die antwoordt moet geven op vragen van gebruikers. Je kunt dan kiezen om dit zelf van scratch te bouwen, maar je zou ook gebruik kunnen maken van cognitieve services die bepaalde cloudproviders bieden. Ieder met zijn eigen voor- en nadelen. De analytics architect speelt tijdens deze selecties een grote rol omdat hij/zij altijd op de hoogte is van de nieuwste ontwikkelingen en kan overzien welke gevolgen bepaalde keuzes hebben op de langere termijn (denk bijvoorbeeld aan schaalbaarheid en performance).

*Over veel van de genoemde concepten ga ik in latere blogposts nog dieper in. Voor de volgende keer staat ‘DataOps’ op de planning.

Meer weten?

Geïnteresseerd in een demo of wil je een gesprek over onze visie op een succesvolle implementatie van MLOps? Ga naar onze Data & Business Analytics services of neem direct contact met mij op!

Naar Data & Business Analytics