Afleidingsregel
Een afleidingsregel legt uit hoe een nieuwe waarde wordt berekend of bepaald uit bestaande data. Ze maakt businesslogica achter velden, metr...
Lees meerFeature engineering is ruwe data omvormen tot de invoervariabelen (features) waar een machine learning-model echt iets mee kan. Uit besteldata maak je bijvoorbeeld 'dagen sinds laatste bestelling': één feature die vaak meer zegt dan alle ruwe rijen samen. Domeinkennis weegt hier zwaarder dan rekenkracht.
Feature engineering is ruwe data omvormen tot de invoervariabelen waar een machine learning-model iets mee kan. Die variabelen heten features: de kolommen die het model ziet tijdens het trainen en bij elke voorspelling.
Een voorbeeld maakt dat concreet. Je wil voorspellen welke klanten dreigen af te haken. Je ruwe data is een tabel met bestellingen: klantnummer, datum, bedrag, plus een lijst klachtentickets. Daar kan een model weinig mee, want het signaal "deze klant is aan het afhaken" staat in geen enkele rij. Dus bouw je features: dagen sinds de laatste bestelling, gemiddeld orderbedrag in het laatste kwartaal, aantal klachten in het voorbije halfjaar. Elke feature vat honderden ruwe rijen samen in één getal dat wel iets zegt.
Dat is meteen de kern: een goede feature zegt meer dan de ruwe kolom waaruit ze komt. Een model dat "dagen sinds laatste bestelling" ziet, hoeft niet zelf uit duizenden orderregels af te leiden dat stilte een alarmsignaal is. Jij hebt dat inzicht al in de data gestopt.
De technieken klinken technischer dan ze zijn. Vier ervan kom je in bijna elk project tegen.
Aggregaties per klant
Je vat veel rijen samen tot één rij per klant: aantal bestellingen, gemiddeld bedrag, datum van de laatste aankoop. De meeste modellen verwachten één rij per ding dat ze moeten beoordelen, dus dit is bijna altijd de eerste stap.
Afgeleide waarden en verhoudingen
Nieuwe getallen berekend uit bestaande kolommen. "Omzet dit kwartaal gedeeld door omzet vorig kwartaal" toont een dalende trend die in geen enkele ruwe kolom staat. Hetzelfde geldt voor de verhouding tussen retours en bestellingen, of de marge per order.
Datumkenmerken
Uit één datumkolom haal je de weekdag, de maand, het kwartaal en of het een feestdag was. Voor alles met een seizoenspatroon, van verkoop tot personeelsplanning, doen die kenmerken veel werk. AutoML-tools kunnen datumkolommen omzetten naar kalenderfeatures, zoals weekdag, maand of feestdagindicatoren, vooral bij forecasting.
Categorieën omzetten naar getallen
Een model rekent met getallen, niet met woorden. Een kolom zoals "sector" met waarden als bouw, retail en horeca zet je om naar aparte ja/nee-kolommen, één per sector. Die techniek heet one-hot encoding.
Welke features werken, kan een algoritme niet volledig voor je bedenken. Wie het proces kent, weet welke signalen tellen. Microsoft omschrijft feature engineering in zijn Azure-documentatie dan ook als domeinkennis over je data gebruiken om features te maken waar algoritmes beter van leren.
Concreet: je accountmanager weet dat klanten die vertrekken eerst kleiner beginnen te bestellen. Dat inzicht vertaal je naar een feature "trend in orderbedrag over de laatste zes maanden". Extra rekenkracht vindt dat signaal niet altijd betrouwbaar als de feature er niet is. Een gesprek van een halfuur met de juiste collega kan dan meer opleveren.
Het verklaart waarom wie professioneel met machine learning bezig is meer tijd steekt in data beoordelen en omvormen dan in modellen bouwen. Het model is vaak een standaardalgoritme. De features zijn het echte werk.
Deep learning leert zijn kenmerken zelf. Geef een diep netwerk ruwe pixels, audio of tekst, en het ontdekt in zijn lagen welke patronen ertoe doen. Voor veel beeld- en taalproblemen heeft dat handmatige feature engineering grotendeels vervangen: je bouwt meestal geen losse rand-, kleur- of woordtellingfeatures meer.
Voor tabellen met bedrijfsdata ligt dat anders. Op omzetcijfers, klantgegevens en voorraadstanden winnen eenvoudigere modellen met goed gekozen features geregeld van diepe netwerken, zeker op de dataschaal waar de meeste KMO's mee werken.
Feature engineering is het werk, de feature store is de kast waarin je het resultaat bewaart. Zodra meerdere modellen en teams dezelfde features gebruiken, wil je één plek waar "gemiddeld orderbedrag" maar één definitie en één berekening heeft. Voor één model dat maandelijks draait, is die kast overbodig: een goed gedocumenteerde berekening in je datapijplijn volstaat.
De gevaarlijkste fout bij feature engineering is een feature bouwen die het antwoord al bevat. Dat heet data leakage.
Stel dat je wanbetaling wil voorspellen en "aantal aanmaningen" als feature meeneemt. Aanmaningen verstuur je pas nadat een factuur te laat is. In je historische data voorspelt die feature wanbetaling dus heel sterk, en je model haalt hoge testscores. Alleen: op het moment dat je echt wil voorspellen, bij het versturen van een nieuwe factuur, zijn er nog geen aanmaningen. Het model leunt volledig op informatie die er op het voorspelmoment niet is, en valt in productie door de mand.
De vuistregel: bouw elke feature alsof je op het voorspelmoment staat. Alles wat pas later bekend wordt, van aanmaningen tot annulaties, hoort niet in je trainingsdata. Dezelfde toets geldt voor praktische beschikbaarheid: een feature uit een systeem dat maar één keer per maand synchroniseert, is onbruikbaar voor een model dat elke dag voorspelt.
Dezelfde berekening in training en productie
Als een feature in je trainingscode net iets anders berekend wordt dan in het systeem dat live voorspelt, scoort je model in productie slechter dan in elke test, en niemand ziet waarom. Definieer elke feature op één plek en hergebruik die code aan beide kanten.
Elke feature is onderhoud
Een feature is code die blijft draaien, ook wanneer de brondata verandert. Verhuist een kolom of wijzigt een definitie in je ERP, dan rekent je feature stil verder met verkeerde waarden. Neem features daarom mee in je checks op datakwaliteit.
Schrijf de definities op
"Actieve klant" kan betekenen: bestelde dit jaar, bestelde dit kwartaal, of heeft een lopend contract. Zonder vastgelegde definitie bouwt elk teamlid zijn eigen variant en spreken je modellen elkaar tegen. Eén zin per feature in een gedeeld document voorkomt dat.
1. Kan een tool dit niet gewoon automatisch?
Deels. AutoML-tools genereren standaardkenmerken zoals datumfeatures en encoding vanzelf, en dat spaart tijd. De features die je bedrijfsproces kennen, zoals "klant bestelt kleiner dan vorig kwartaal", bedenkt geen tool voor je.
2. Hoeveel features heeft een model nodig?
Daar bestaat geen vast getal voor. Tien features die elk een echt signaal dragen, werken beter dan honderd kolommen ruwe data. Meer features betekent ook meer kans op toevallige verbanden en meer onderhoud.
3. Heb ik er een data scientist voor nodig?
Niet per se. Veel features zijn gewone berekeningen in SQL of Power Query op data die je al hebt. De combinatie die telt: iemand die de data kan bewerken en iemand die het bedrijfsproces kent. Dat mag dezelfde persoon zijn.
Een afleidingsregel legt uit hoe een nieuwe waarde wordt berekend of bepaald uit bestaande data. Ze maakt businesslogica achter velden, metr...
Lees meerAfwijkingsanalyse onderzoekt waar procesuitvoeringen verschillen van een norm, verwacht patroon of vergelijkingsgroep. Ze maakt zichtbaar we...
Lees meerDe AI Act is de Europese verordening die artificiële intelligentie reguleert. Ze deelt AI-systemen op volgens risico en legt verplichtingen ...
Lees meerAI Builder brengt AI-modellen en prompts naar Power Apps en Power Automate. Makers kunnen er onder meer documenten uitlezen, tekst classific...
Lees meerEen AI-agent is een AI-systeem dat zelfstandig meerdere stappen plant en uitvoert om een doel te bereiken. Hij gebruikt een taalmodel als br...
Lees meer
Zeven nieuwe Data Panda-connectors uit juni 2026, met concrete toepassingen voor rapportering, voorraad, finance, ticketing, planning en ope...
Nieuw in Microsoft Fabric? Zo verschillen een lakehouse en een warehouse, in mensentaal: wat ze doen, wanneer je wat kiest en wanneer je bei...