Richtlijnen voor een succesvol data science project
De afgelopen jaren is de vraag naar data-science diensten enorm gegroeid. Vrijwel iedereen die ik tegenkom is enthousiast over wat data voor hun onderneming kan betekenen, maar vaak ontbreekt binnen hun organisatie de benodigde kennis en ervaring om hun ideeën van de grond te krijgen. Naast het enthousiasme bestaat er ook een zekere voorzichtigheid; data-science heeft zijn nut voor hun organisatie immers nog niet bewezen. Een eerdere blog refereert precies aan dit onderwerp.
In veel gevallen wordt er een budget beschikbaar gemaakt om door een externe partij een data-science pilot te laten ontwikkelen. De afgelopen jaren hebben wij bij VORtech veel verschillende data-science projecten mogen doen voor onze klanten. Vaak heb ik bij aanvang van het project al ideeën over welke klasse van machine-learning technieken goed toepasbaar zullen zijn. Maar de praktijk wijst uit dat de belangrijkste succesfactor van zo’n pilotproject hem niet zit in het gebruiken van het meest geavanceerde algoritme, maar meer in hoe het project is vormgegeven.
In dit blog bespreek ik daarom (in willekeurige volgorde) een aantal richtlijnen die wij bij VORtech altijd hanteren bij het uitvoeren van een data-science project, om de kans op een succesvol project zo groot mogelijk te maken.
Werk samen met de klant en bij de klant
Bij VORtech werken we aan data-science projecten voor een heel diverse groep klanten uit verschillende branches. Dit maakt mijn werk als data-scientist erg leuk, want ik werk continu met mensen met heel verschillende achtergronden en expertises, die allemaal een eigen taal spreken en op hun eigen manier naar hun data kijken. Het werken aan zo’n grote verscheidenheid aan projecten is erg leerzaam, zo weet ik inmiddels een stuk meer over hoogspanningskabels, schepen, steigers, waterleidingen en brandweerauto’s.
Wanneer ik aan een data-science project begin, werk ik het liefst bij de klant op kantoor. In veel data-science projecten is het verzamelen, opschonen en verkennen van de data een belangrijk gedeelte van het initiële werk. Zelf kent de klant hun data veel beter dan ik en daar maak ik graag gebruik van. De klant kan bijvoorbeeld helpen met vaststellen of bepaalde waarden zeker foutief zijn, denk aan: bepaalde getallen mogen nooit negatief zijn, bepaalde waarden zijn gereserveerd als errorcodes, of een bepaald event kan nooit plaatsgevonden hebben vóór een bepaald ander event.
Zodra de data op orde is en de klantvraag helder is, kan ik beginnen met het modelleren van de data, met een statistisch of een machine-learning model. Vanaf dat moment is het in principe minder van belang om bij de klant op kantoor te werken. Toch heeft het ook op dat moment nog mijn voorkeur om dit wel te doen. In veel gevallen is het uiteindelijk niet alleen mijn doel om een rapportage van mijn bevindingen op te leveren, maar wil ik ook graag iets opleveren dat de klant daadwerkelijk operationeel kan gaan gebruiken. Bijvoorbeeld een applicatie of een dashboard dat real-time inzicht geeft in de stand van zaken. Dit werkt het beste als de klant zelf nauw betrokken is geweest bij het ontwikkelproces. Eventueel zelfs door het laten meewerken van een eigen ontwikkelaar aan het project.
Wees voorzichtig met data die mogelijk fouten bevat
Vaak hebben klanten door de jaren heen een behoorlijk volume aan data opgebouwd; er worden bijvoorbeeld al jaren records opgeslagen van alle transacties die zijn gedaan, of er zijn tijdreeksen opgeslagen van hoogfrequente sensormetingen. In principe is dit een goed begin, maar wanneer de data nog nooit is gebruikt om enige vorm van analyse op te doen, dan komt het vaak voor dat de data sterk is vervuild. Hierbij kan gedacht worden aan het ontbreken van gegevens, foutief ingevoerde gegevens, technische problemen met het sensornetwerk, handmatige bewerkingen die zijn uitgevoerd op de data, etc. Deze problemen worden zichtbaar zodra ik de data gaan verkennen, maar het is lang niet altijd duidelijk hoe deze fouten opgelost kunnen worden. Door het maken van bepaalde aannames kan ik meestal toch nog een eind komen met het opschonen van de data, maar de ervaring leert dat dit een tijdrovende klus kan zijn.
Het is belangrijk dat de klant zich bewust is van de gevolgen van foutieve data. Ten eerste zal een machine-learning model dat is getraind op foutieve data geen betrouwbare voorspellingen geven of tot verkeerde inzichten leiden. Tot op zekere hoogte kan men zich daartegen wapenen door zogenaamde ‘robuuste’ methoden te gebruiken, bijvoorbeeld door als centrummaat een mediaan te gebruiken in plaats van een gemiddelde, of door het RANSAC algoritme te gebruiken bij het schatten van modelparameters, maar dit soort maatregelen zijn niet altijd voldoende. Ten tweede verwacht een getraind machine learning model correcte input wanneer het een voorspelling gaat maken. Krijgt het foutieve input, dan zijn de uitkomsten weinig meer waard.
Het is dus essentieel om een gezonde en zoveel mogelijk foutvrije database te krijgen. Om te voorkomen dat er in de toekomst meer foutieve data in de database terecht komt, zal de klant anders met de data om moeten gaan. Er zal meer aandacht moeten komen voor de data. Bijvoorbeeld door controles in te bouwen in de applicaties die naar de database schrijven, of door de database te actief te monitoren.
Vertaal een klantvraag naar een wiskundig goed gedefinieerd probleem
De eerste stap die ik zet na het verkennen van de data, is het vertalen van het datavraagstuk naar een wiskundig optimalisatievraagstuk. Hiermee maak ik concreet wat precies de bedoeling is, en krijg ik een maat voor hoe goed een model presteert. In sommige gevallen gaat deze stap gemakkelijk, maar soms komen er ook lastige vragen naar boven. Stel, een klant wil een model dat bepaalt wanneer een onderdeel in een machine moet worden vervangen, dan is het werkelijke doel om onderhoudskosten te drukken. Te vroeg onderdelen vervangen is kostbaar, maar te laat vervangen is misschien nog wel veel kostbaarder. Er moet dan dus worden nagedacht over de relatieve kosten van te vroeg en te laat vervangen, zodat het juiste optimum kan worden gevonden.
Het is verleidelijk om direct als je de data hebt te beginnen met het trainen van machine learning modellen, maar dit leidt vaak tot onbruikbare modellen, als later blijkt dat de vraag niet goed was was gesteld.
Gebruik een baseline bij het modelleren
Wanneer het probleem goed is gedefinieerd kan het modelleren beginnen. Als eerste wordt de data opgesplitst in een gedeelte om het machine learning model mee te trainen (de trainingsset) en een gedeelte om om te beoordelen hoe goed het model werkt op ongeziene data (de testset). Het modelleren zelf is eigenlijk altijd een iteratief proces. Eerst probeer ik enkele modellen, ik kijk welke het beste werkt, bekijk de residuen (het verschil tussen de meting en de voorspelde waarde), en met de nieuwe inzichten maak ik aanpassingen totdat ik tevreden bent met het resultaat. Het belangrijkste model in dit iteratieve proces (en een model dat ik altijd mee laat draaien) is het simpelste model dat ik kan verzinnen. Voor een regressieprobleem (het modelleren van een kwantitatieve variabele) kan dit bijvoorbeeld het gemiddelde zijn van de relevante grootheid in de trainingsset. Voor een classificatieprobleem maak ik een model dat altijd dezelfde klasse voorspelt, namelijk de klasse die het meest voorkomt in de trainingsset. Voor een tijdreeksprobleem, ten slotte, is de voorspelde waarde gelijk aan de voorgaande waarde.
Vervolgens bereken ik de score van dit haast triviale model. In sommige gevallen is de score verrassend goed, maar in de meeste gevallen valt er nog een hoop te winnen door verklarende factoren mee te nemen en een geavanceerder algoritme te gebruiken. Waarom dan niet direct beginnen met het geavanceerdere algoritme? Er zijn verschillende redenen. Ten eerste is het simpele model een snelle test of we de vraag juist hebben gesteld. Ten tweede kan, als het doel is om een operationele tool te maken, direct worden begonnen met de ontwikkeling van deze tool op basis van het baseline model. Verbeteringen op het simpele model kunnen daarna snel worden uitgerold, parallel aan de ontwikkeling van de tool. Als laatste kan het simpele model gebruikt worden als een baseline om geavanceerdere modellen mee te vergelijken. Als we direct waren begonnen met het geavanceerde algoritme en we behaalden een mooie score, dan is de verwachting dat dit komt doordat het algoritme zo goed werkt. Maar soms kan een bijna even goede score worden bereikt met een veel simpeler model. In zulke gevallen heeft het simpelere model vaak de voorkeur, aangezien het bij simpelere modellen doorgaans beter te inzichtelijk gemaakt kan worden hoe voorspellingen tot stand komen, dit in tegenstelling tot ingewikkeldere modellen, die om deze reden ook wel eens ‘black box modellen’ worden genoemd.
Pas software best practices toe
Dit is misschien een inkoppertje, maar net als bij elk ander wetenschappelijk project kan een data-science project behoorlijk uit de hand lopen wanneer er slordig wordt gewerkt. Zelf werk ik naast mijn data-science projecten ook regelmatig aan software-engineering projecten. De best practices die we gebruiken in de software-engineering projecten zoals testen, een consistente coding style, logisch ontwerp en het gebruiken van versiebeheer, neem ik ook mee in mijn data-science projecten. Het is belangrijk om ervoor te zorgen dat het altijd duidelijk is hoe bepaalde resultaten tot stand zijn gekomen. Bovendien moeten alle resultaten simpel reproduceerbaar zijn. Handmatige manipulaties van de data zijn uit den boze.
Conclusie
De technische kant van data-science hoeft in veel gevallen niet al te ingewikkeld te zijn. Er bestaan een hoop uitstekende boeken, blogs, MOOCs en Meetups die gratis of voor een relatief kleine investering toegankelijk zijn, waardoor de basis van de meest gebruikte technieken snel op te pikken is. Open-source bibliotheken met gebruiksvriendelijke interfaces zoals pandas, scikit-learn en TensorFlow zorgen dat in principe iedereen met een technische achtergrond een goed begin kan maken.
Maar toch gaan data-science projecten lang niet altijd goed. Het falen van een data-science project hangt meestal niet samen met een gebrek aan technische kennis, maar meer met de opzet van het project. Het consequent toepassen van enkele relatief eenvoudige richtlijnen kan gelukkig al een hoop helpen bij het succesvol maken van het project.