Projectafbakening: het probleem en de succescriteria definiëren

De meest voorkomende reden dat ML-projecten mislukken, is niet een slecht gekozen algoritme — het is een slecht gedefinieerd probleem. Projectafbakening vertaalt een vage zakelijke behoefte ('we willen AI gebruiken') naar een nauwkeurige, meetbare specificatie die elke daaropvolgende technische beslissing stuurt. Een goed afgebakend project definieert het te voorspellen doel, de succescriteria, de gegevensvereisten en de beperkingen voor ingebruikname voordat er ook maar één regel modelleercode wordt geschreven.

De eerste beslissing bij de afbakening is het type ML-taak. Vraag jezelf af: is de uitvoer een getal (regressie), een categorie (classificatie), een rangschikking (leren rangschikken), een cluster (zonder toezicht), of een reeks (NLP/tijdreeks)? Elk type leidt tot andere algoritmen, gegevensvereisten en evaluatiemaatstaven. Zo is ‘voorspel welke klanten vertrekken’ een binair classificatieprobleem en geen regressieprobleem, ook al draait het bedrijf uiteindelijk om omzet.

Het voorspellingsdoel (label of afhankelijke variabele) moet ondubbelzinnig worden gedefinieerd. ‘Zal deze klant vertrekken?’ is niet eenduidig: binnen welke periode? Welke definitie van vertrek gebruik je (opzegging, inactiviteit, terugbetaling)? Een precieze definitie kan zijn: ‘zal de klant in de 90 dagen na zijn laatste aankoop geen enkele aankoop meer doen?’ Elk woord telt, omdat het bepaalt welke rijen in de database trainingsvoorbeelden worden.

Controleer na het definiëren van het doel de beschikbare gegevens. Vraag jezelf af: bestaan er historische gegevens met labels? Hoe ver terug gaan die — zijn dat genoeg trainingsvoorbeelden? Zijn de kenmerken op het moment van voorspellen beschikbaar (en niet pas na de gebeurtenis)? Een kenmerk dat pas na de uitkomst wordt geregistreerd (bijvoorbeeld ‘klacht ingediend’) vormt een risico op gegevenslekken. Breng voor elk kandidaatkenmerk de bron, de verzamelingsfrequentie en de beschikbaarheidsvertraging in kaart voordat je het vastlegt.

Vage succescriteria (‘het model moet nauwkeurig zijn’) maken projecten onmogelijk te evalueren. Succescriteria moeten specifiek, meetbaar, haalbaar, relevant en tijdgebonden (SMART) zijn. Definieer een primaire maatstaf (bijvoorbeeld recall ≥ 0.80 voor fraudedetectie), een secundaire maatstaf (precision ≥ 0.70) en een bedrijfsmaatstaf (verliezen door klantvertrek binnen 6 maanden met 15% verminderen). Deze bepalen wanneer je het model uitrolt en wanneer je het opnieuw traint.

Definieer voordat je een model bouwt een referentieniveau — de eenvoudigste redelijke oplossing waarmee alle modellen worden vergeleken. Bij classificatie is het referentieniveau meestal een DummyClassifier die de grootste klasse voorspelt, of willekeurige voorspellingen doet met gewichten op basis van de klassenfrequentie. Bij regressie voorspel je het gemiddelde. Een model dat dit referentieniveau niet kan overtreffen, levert geen enkele bedrijfswaarde op en mag niet worden geïmplementeerd.

Een model dat voor 95% nauwkeurig is maar 10 seconden per voorspelling nodig heeft, is nutteloos in een realtime-aanbevelingssysteem. Leg implementatiebeperkingen al tijdens de afbakening vast: vertraging (maximale tijd per voorspelling), verwerkingscapaciteit (voorspellingen per seconde), geheugengebruik (mobiel versus cloud) en bijwerkfrequentie (elke dag versus elke maand opnieuw trainen). Deze beperkingen sluiten vaak hele groepen algoritmen uit voordat er code is geschreven.

Beoordeel ethische en juridische risico’s voordat je je aan een project vastlegt. Vraag jezelf af: heeft het model invloed op de toegang van personen tot diensten, werk of krediet? Zijn beschermde kenmerken (ras, gender, leeftijd) direct aanwezig of af te leiden uit plaatsvervangende kenmerken? Zijn er AVG-, CCPA- of sectorspecifieke voorschriften van toepassing (HIPAA voor gezondheidszorg, FCRA voor krediet)? Deze kwesties tijdens de afbakening identificeren kost minuten; ze pas na implementatie ontdekken kan miljoenen kosten en het vertrouwen van gebruikers vernietigen.

Leg alle beslissingen over de afbakening vast in een beknopt projectcharter — een document van één pagina dat belanghebbenden, engineers en datawetenschappers allemaal kunnen lezen en goedkeuren voordat het werk begint. Het charter specificeert: probleemstelling, type ML-taak, definitie van het voorspellingsdoel, gegevensbronnen, succesmaatstaven, referentieniveau, implementatiebeperkingen en ethische overwegingen. Het vormt de bron van waarheid bij discussies over scope creep gedurende het hele project.

Afbakening is geen eenmalige activiteit. Na een eerste verkenning van de gegevens (EDA) ontdek je mogelijk dat het label historisch niet te berekenen is, dat de scheefheid tussen klassen groter is dan verwacht, of dat het meest informatieve kenmerk te veel vertraging heeft voor realtime gebruik. Plan minstens één herziening van de afbakening na EDA en één na het uitvoeren van een referentiemodel. Geef het projectcharter versies met datums, zodat je kunt bijhouden hoe de probleembeschrijving zich heeft ontwikkeld.

Een voltooid charter vormt de basis voor een concreet werkplan. Deel het project op in fasen: Fase 1 — EDA en controle van de gegevenskwaliteit; Fase 2 — kenmerken construeren en referentieniveau; Fase 3 — modelselectie en afstemming; Fase 4 — evaluatie en controle op eerlijkheid; Fase 5 — implementatie, monitoring en A/B-toets. Wijs aan elke fase verantwoordelijken en deadlines toe. Deze structuur is hetzelfde, of je tijdlijn nu twee weken of zes maanden duurt.

In deze les heb je geleerd dat het afbakenen van een project bedrijfsbehoeften vertaalt naar precieze ML-specificaties voordat er code wordt geschreven, dat succescriteria kwantitatief moeten zijn en gekoppeld aan zowel modelmaatstaven als bedrijfsresultaten, en dat implementatiebeperkingen, ethische risico’s en de haalbaarheid van gegevens vooraf moeten worden beoordeeld om dure koerswijzigingen later te voorkomen. Hierna gaan we aan de slag met het bewerken en verkennen van gegevens om de onbewerkte gegevensverzameling te begrijpen en kwaliteitsproblemen te ontdekken.