Gegevens normaliseren: een complete gids met voorbeelden

Een neuraal netwerk dat weigert te convergeren, met verlies dat vlak blijft en gradiënten die ofwel verdwijnen of exploderen, blijkt vaak helemaal geen probleem in de architectuur te hebben. Het probleem is vaak veel eenvoudiger: invoerkenmerken op totaal verschillende schalen, waarbij de ene kolom loopt van 0 tot 1 en een andere in de tienduizenden loopt. 

In mijn ervaring komt dit patroon constant voor in de praktijk. Vijf minuten preprocessing kan oplossen wat dagen hyperparametertuning niet lukte.

In deze tutorial laat ik je zien hoe je gegevens normaliseert. Ik neem je mee langs verschillende normalisatietechnieken, wanneer je welke toepast, inclusief Python-implementaties. Daarnaast leer je over veelvoorkomende fouten en misvattingen en hoe je die vermijdt.

Wil je meer leren over het voorbereiden van data voor machinelearningalgoritmen? Volg dan onze cursus Preprocessing for Machine Learning in Python.

Wat is datanormalisatie?

Datanormalisatie verwijst naar het transformeren van numerieke kenmerken zodat ze vergelijkbare bereiken innemen of een consistente schaal volgen. 

De term krijgt verschillende betekenissen afhankelijk van de context: in machine learning betekent het doorgaans het herschalen van kenmerkwaarden om te voorkomen dat grootte de belangrijkheid dicteert, terwijl het in databasemodellering verwijst naar het organiseren van tabellen om redundantie te elimineren.

Ik focus me vooral op de betekenis binnen machine learning, al behandelen we later kort database-normalisatie om de overlap in terminologie te verduidelijken.

Waarom datanormalisatie belangrijk is

Wanneer kenmerken op verschillende schalen bestaan, geven bepaalde algoritmen onevenredig veel gewicht aan waarden die toevallig numeriek groter zijn. 

Een kenmerk dat inkomen in duizenden meet, zal domineren over een kenmerk dat leeftijd in decennia meet, niet omdat inkomen belangrijker is voor de voorspellingstaak, maar simpelweg omdat de getallen groter zijn. Normalisatie zet kenmerken op gelijke voet, zodat het model kan leren welke echt belangrijk zijn.

Naast modeltraining helpt normalisatie ook bij:

• het combineren van metingen die verschillende eenheden gebruiken
• het integreren van data uit meerdere bronnen met inconsistente conventies
• het ontwerpen van databaseschema’s die in de tijd consistent moeten blijven.

Datanormalisatie vs. schalen vs. standaardiseren

Dus, wat is het verschil tussen normalisatie, schalen en standaardiseren? Deze drie termen komen vaak voor in documentatie en worden vaak door elkaar gebruikt, ondanks dat ze verschillende betekenissen hebben.

Het praktische onderscheid komt neer op de vraag of je model waarden binnen specifieke grenzen nodig heeft. Min-max-normalisatie garandeert grenzen, standaardiseren niet. De volgende tabel vat de verschillen samen:

Voor een diepere vergelijking van wanneer elke aanpak averechts werkt, behandelt onze blog Normalization vs. Standardization Explained de randgevallen goed.

Gebruiksscenario’s voor datanormalisatie

Nu we de termen hebben vastgesteld, kijken we naar enkele klassieke use-cases. Normalisatie dient verschillende doelen afhankelijk van je use-case, van het verbeteren van de trainingsdynamiek van modellen tot het mogelijk maken van zinvolle vergelijkingen over heterogene databronnen heen.

Verbeter de prestaties van machinelearningmodellen

Neurale netwerken en logistische regressie updaten gewichten via gradient descent, waarbij de bijdrage van elk kenmerk aan de voorspellingsfout bepaalt hoeveel het bijbehorende gewicht wordt aangepast. 

Wanneer kenmerkengroottes sterk verschillen, doen de resulterende gradiënten dat ook: grote kenmerken leveren grote gradiënten op, kleine kenmerken kleine. Deze onbalans zorgt ervoor dat de optimizer enorme stappen in sommige richtingen zet en nauwelijks in andere, wat leidt tot instabiele training of helemaal niet convergeren.

Afstand-gebaseerde algoritmen zoals kNN en k-means hebben een gerelateerd probleem. Ze berekenen overeenkomsten met afstandsmaatstaven, meestal Euclidische afstand, waarbij grotere numerieke waarden meer bijdragen aan de berekening simpelweg omdat ze groter zijn. Een kenmerk dat loopt van 0 tot 10.000 zal domineren over een kenmerk dat loopt van 0 tot 1, ongeacht welk kenmerk daadwerkelijk belangrijk is voor de taak. 

Schalen zorgt ervoor dat alle kenmerken proportioneel bijdragen op basis van hun werkelijke voorspellende waarde in plaats van hun willekeurige numerieke bereik.

Eerlijke vergelijking tussen kenmerken mogelijk maken

Bij het bouwen van samengestelde scores of het combineren van metingen met verschillende eenheden kunnen ruwe waarden tot misleidende vergelijkingen leiden. 

Een klantgezondheidsmetric die maandelijkse uitgaven in dollars, inlogfrequentie als telling en accountleeftijd in dagen combineert, zal bedragen in dollars het zwaarst wegen, simpelweg omdat die getallen groter zijn. 

Normalisatie stelt je in staat om deze metingen te combineren op een manier die hun werkelijke belang weerspiegelt in plaats van hun toevallige grootteorde.

Dit geldt ook voor verkennende analyse en visualisatie. Kenmerken met verschillende schalen plotten maakt het moeilijker om patronen te zien of verdelingen te vergelijken. Genormaliseerde data geeft een helderder beeld van hoe kenmerken zich tot elkaar verhouden.

Verbeter de datakwaliteit en -integriteit

Productiepijplijnen halen vaak data uit meerdere bronnen met inconsistente conventies. Omzet kan in dollars uit het ene systeem komen en in duizenden uit het andere. Datums verschijnen als Unix-timestamps in de ene API en als geformatteerde strings in een andere. 

Een consistente schaal en formaat vastleggen vóór downstreamverwerking voorkomt subtiele bugs die later lastig te achterhalen zijn.

In databasecontexten krijgt normalisatie een andere maar gerelateerde betekenis: tabellen zo organiseren dat elk stukje informatie precies één plek heeft. 

Dit voorkomt update-anomalieën waarbij een waarde op de ene plek wijzigen tegenstrijdige waarden elders achterlaat. Hoewel de technieken verschillen van kenmerkenschaling, is de onderliggende motivatie vergelijkbaar: data consistent en voorspelbaar houden.

Veelvoorkomende technieken voor datanormalisatie

Elke normalisatieaanpak maakt verschillende aannames over je data en levert andere uitvoerkenmerken op. De juiste keuze hangt af van de verdeling van je data, de aanwezigheid van uitschieters en wat je downstreammodel verwacht.

Min-max-normalisatie

Min-max-normalisatie comprimeert waarden in een vast bereik, meestal 0 tot 1, door het minimum af te trekken en te delen door het bereik. Deze aanpak behoudt de oorspronkelijke verdelingsvorm terwijl wordt gegarandeerd dat alle waarden binnen bekende grenzen vallen.

Zo werkt het: Trek het minimum af, deel door het bereik. Dat is alles.

Wat het doet:

• Garandeert dat de uitvoer binnen gedefinieerde grenzen blijft
• Behoudt de oorspronkelijke verdelingsvorm—alleen herschaald
• Nul wordt je vloer, één wordt je plafond

Het best te gebruiken voor:

• Pixelintensiteiten (altijd 0-255 per definitie)
• Kansen en percentages
• Examencijfers, beoordelingen, alles met een natuurlijk minimum en maximum
• Neurale netwerken die begrensde input verwachten, zoals beeldclassificaties

Waarop te letten:

Uitschieters kunnen min-max-normalisatie volledig onderuithalen. Stel je data voor die grotendeels tussen 10 en 100 zit, maar één waarde op 99.999? Dat ene punt rekt je bereik zo ver op dat alles wat normaal is in een klein strookje dicht bij nul wordt geperst. Eén slechte observatie, hele kenmerk verpest.

Denk ook na over wat er gebeurt wanneer nieuwe data buiten het trainingsbereik valt. Testwaarden boven het trainingsmaximum leveren uitvoer boven 1 op. Of dat iets breekt, hangt van je model af.

Z-score-standaardisering

Z-score-standaardisering transformeert data zodat het gemiddelde nul is en de standaarddeviatie één, zonder vaste grenzen op te leggen aan de uitvoer. Deze aanpak werkt goed voor data zonder duidelijke natuurlijke grenzen en wordt door veel algoritme-implementaties verondersteld of aanbevolen.

Zo werkt het: Trek het gemiddelde af, deel door de standaarddeviatie.

Wat het doet:

• Centreert alles zodat het gemiddelde nul wordt
• Schaalt zodat één standaarddeviatie gelijk is aan één eenheid
• Uitvoer kan negatief zijn en elke grens overschrijden

Het best te gebruiken voor:

• Data zonder duidelijke natuurlijke grenzen
• Ruwweg klokvormige verdelingen
• Algoritmen die standaardiseren veronderstellen of aanbevelen (de meeste neurale-netwerktutorials, implementaties van logistische regressie)
• Wanneer je niet zeker weet wat anders te gebruiken (een redelijke standaard)

Afweging:

De interpretatie wordt lastiger. "Deze observatie is 1,7 standaarddeviaties boven gemiddeld" vergt meer denkwerk dan "dit zit op 80% van het bereik." Als stakeholders geschaalde waarden direct moeten begrijpen, kan min-max beter communiceren.

Uitschieters blazen nog steeds het gemiddelde en de standaarddeviatie op en vertekenen zo de schaling voor de bulk van de data, maar het is minder problematisch dan bij min-max-normalisatie.

Robuust schalen

Robuust schalen pakt de gevoeligheid voor uitschieters aan van zowel min-max als z-score door gebruik te maken van mediaan en interkwartielafstand (IQR) in plaats van gemiddelde en standaarddeviatie. Deze statistieken blijven stabiel ongeacht extreme waarden in de staarten van je verdeling.

Zo werkt het: Trek de mediaan af, deel door de IQR (verschil tussen 25e en 75e percentiel).

Wat het doet:

• Schaalt op basis van het middendeel van je data en negeert extremen
• Staarten kunnen hun gang gaan zonder de transformatie voor typische waarden te vervormen
• Stabieler wanneer je data legitieme uitschieters bevat die je niet kunt verwijderen

Het best te gebruiken voor:

• Financiële transacties, waar de meeste aankopen klein zijn maar af en toe legitieme hoge bedragen voorkomen
• Inkomensdata, die vaak lange rechterstaarten heeft
• Sensoraflezingen waarbij pieken echte gebeurtenissen vertegenwoordigen
• Elke sterk scheve verdeling en situatie waarin gemiddelde-gebaseerde aanpakken worden meegetrokken door extreme waarden

Waarom het helpt bij scheve data:

Inkomensverdelingen zijn een goed voorbeeld. De meeste mensen verdienen gematigde bedragen en sommigen enorme bedragen: een klassiek rechts-scheve verdeling. De standaarddeviatie wordt opgeblazen door de grootverdieners, waardoor standaardiseren minder nuttig wordt voor de meerderheid van de observaties. Mediaan en IQR blijven verankerd in het midden van de verdeling, ongeacht wat er in de extremen gebeurt.

Unit-norm vectornormalisatie

Unit-norm (L1/L2) normalisatie werkt anders dan de bovenstaande technieken: in plaats van kenmerken (kolommen) te schalen, schaalt het vaak individuele samples (rijen). Elke samplevector wordt herschaald zodat de lengte 1 is onder een gekozen norm (vaak L2), wat de algehele grootte verwijdert en alleen richting/proporties behoudt.

Verwar dit niet met L1/L2 regularisatie (Lasso/Ridge): regularisatie wijzigt de trainingsdoelstelling door een straf op modelgewichten toe te voegen om overfitting te verminderen, niet door invoervectoren te herschalen.

Zo werkt het: Bij L2-normalisatie wordt elke rij gedeeld door zijn Euclidische norm, zodat de kwadraten optellen tot één. L1 gebruikt de som van absolute waarden.

Wat het doet:

• Haalt grootte uit de vergelijking
• Maakt rijen vergelijkbaar op basis van verhouding in plaats van ruwe omvang
• De hoek tussen vectoren wordt het signaal; hoe lang de vector is wordt irrelevant

Het best te gebruiken voor:

• Tekstdata weergegeven als woordtelvectoren: een rapport van 50.000 woorden heeft van nature grotere tellen dan een e-mail van 500 woorden, maar met L2 kun je inhoudsverhoudingen vergelijken
• Alles waarbij cosinusgelijkenis betrokken is
• Documentclassificatie, information retrieval en aanbevelingssystemen op basis van content

Niet nuttig voor:

Situaties waarin grootte wél belangrijk is. Als het totaal aantal woorden betekenisvol is voor je taak, verlies je informatie door het weg te normaliseren.

Database-normalisatie

Database-normalisatie verwijst naar het herstructureren van relationele tabellen om redundantie te elimineren en de dataintegriteit te verbeteren—bijvoorbeeld ervoor zorgen dat het e-mailadres van een klant precies op één plek wordt opgeslagen in plaats van herhaald in elk orderrecord.

Het heeft geen verband met kenmerkenschaling.

De term overlapt simpelweg. In machine learning verwijst "normalisatie" bijna altijd naar het schalen van numerieke waarden. In data engineering of SQL verwijst het naar het organiseren van tabelstructuren (vaak besproken als 1NF, 2NF of 3NF).

Belangrijk onderscheid:

• Kenmerk-normalisatie (ML): Getallen transformeren (bijv. 0–1-schaling) om modellen te helpen leren.
• Database-normalisatie (SQL): Schema organiseren om dataduplicatie te voorkomen.

Als een data-engineer je vraagt om "de database te normaliseren", willen ze dat je de tabelstructuur fixt, niet dat je MinMaxScaler draait.

Voor een verdiepende uitleg, bekijk deze gids over database-normalisatie in SQL.

Data normaliseren in de praktijk

Normalisatie correct implementeren vereist aandacht voor de volgorde van bewerkingen, met name rond train/test-splits. De code zelf is eenvoudig, maar subtiele volgordefouten kunnen je hele evaluatie ongeldig maken.

Gegevens normaliseren in Python

Scikit-learn geeft je de scalers, maar de hoofdregel is procedureel, niet wiskundig: eerst splitsen, fitten op alleen train, en die gefitte transformer vervolgens overal hergebruiken.

Waarom die moeite? Omdat schalen getallen leert uit data: min/max, gemiddelde/std, mediaan/IQR. Als die getallen met de testset worden berekend, heb je stiekem toekomstige informatie in training laten lekken. Niets crasht, maar je metrics betekenen simpelweg niet meer wat je denkt dat ze betekenen.

Een minimaal voorbeeld:

import pandas as pd
from sklearn.preprocessing import MinMaxScaler, StandardScaler, RobustScaler
from sklearn.model_selection import train_test_split

# Example data
data = pd.DataFrame({
    'age': [25, 32, 47, 51, 62, 28, 35, 44],
    'income': [30000, 45000, 72000, 85000, 120000, 38000, 55000, 67000],
    'score': [0.2, 0.5, 0.7, 0.4, 0.9, 0.3, 0.6, 0.8]
})

# Split happens before any scaling
train_data, test_data = train_test_split(data, test_size=0.25, random_state=42)Mogelijk gemaakt door

Vanaf dit punt behandel je de trainingssplit als "hoe de wereld eruitzag toen ik het model bouwde." De testsplit is "nieuwe, ongeziene data." Je scaler moet de wereld alleen van de eerste leren.

MinMaxScaler

Min-max-standaardisering is eenvoudig: het slaat het trainingsminimum en -maximum per kolom op en past diezelfde mapping later toe.

scaler = MinMaxScaler()
scaler.fit(train_data)  # training only

train_scaled = scaler.transform(train_data)
test_scaled = scaler.transform(test_data)Mogelijk gemaakt door

Als je jezelf ooit fit() ziet aanroepen op de testset: stop. Dat ondermijnt het hele doel van een testset apart houden.

StandardScaler

StandardScaler slaat gemiddelde en standaarddeviatie uit de trainingssplit op en gebruikt diezelfde waarden om zowel train als test te transformeren.

scaler = StandardScaler()
scaler.fit(train_data)

train_standardized = scaler.transform(train_data)
test_standardized = scaler.transform(test_data)Mogelijk gemaakt door

Dit is degene die stilletjes breekt wanneer lekkage plaatsvindt, omdat gemiddelde/std gemakkelijk te "stabiliseren" zijn door per ongeluk meer data te gebruiken dan zou moeten.

RobustScaler

RobustScaler doet dezelfde routine van “één keer fitten, voor altijd hergebruiken”, maar gebruikt mediaan en IQR, zodat een paar extreme punten de schaal niet bepalen.

scaler = RobustScaler()
scaler.fit(train_data)

train_robust = scaler.transform(train_data)
test_robust = scaler.transform(test_data)Mogelijk gemaakt door

Een praktisch teken dat robuust schalen de moeite waard is: je hebt een lange staart die je juist wilt behouden (betalingen, claims, sensorpieken) en je wilt niet dat één rare dag de rest van het kenmerk tot bijna nul samenperst.

Snelle pandas-berekeningen

Voor snelle verkennende analyses is de wiskunde direct in pandas doen prima, zolang je eerlijk bent over wat je doet: dit is om verdelingen te verkennen, niet voor modelevaluatie.

# Min-max
df_minmax = (data - data.min()) / (data.max() - data.min())

# Z-score
df_zscore = (data - data.mean()) / data.std()Mogelijk gemaakt door

Datalekken voorkomen

Gevaar hier: statistieken zijn gebaseerd op de gehele dataset. Doe dit vóór het splitsen, en testwaarden beïnvloeden de transformatie. Je evaluatie verliest betekenis omdat preprocessing al naar antwoorden heeft gegluurd die het niet had mogen zien.

Het lekkagepatroon ziet er meestal zo uit:

De verkeerde manier:

scaler = MinMaxScaler()
scaled_all = scaler.fit_transform(full_data)  # problem
train, test = split(scaled_all)Mogelijk gemaakt door

Deze aanpak normaliseert de data vóór het splitsen, waardoor de testdata de transformatie al heeft beïnvloed.

De juiste manier:

Door de data eerst te splitsen, zorgen we ervoor dat de scaler statistieken uitsluitend van de trainingsset leert, en blijft de testdata echt ongezien.

scaler = MinMaxScaler()
scaler.fit(train_data)
train_scaled = scaler.transform(train_data)
test_scaled = scaler.transform(test_data)Mogelijk gemaakt door

Dezelfde bewerkingen, andere volgorde. En die volgorde is precies het punt.

Wil je preprocessing end-to-end oefenen (inclusief correct standaardiseren en lekkage vermijden)? Dan is deze cursus precies daarvoor: Preprocessing for Machine Learning in Python.

Normalisatie in SQL

Zoals we eerder noemden, hebben we verschillende betekenissen van hetzelfde woord. Hier is “normalisatie” geen numerieke transformatie. Het is een structurele beslissing om te stoppen met het dupliceren van feiten.

Als je ordertabel customer_email in elke rij opslaat, laat de database dat toe. De database accepteert later ook vrolijk tegenstrijdigheden: één e-mail in de ene rij, een andere in een andere, en geen duidelijke manier om te weten welke “echt” is.

Vóór normalisatie:

CREATE TABLE orders_denormalized (
    order_id INT,
    customer_name VARCHAR(100),
    customer_email VARCHAR(100),
    product_name VARCHAR(100),
    product_price DECIMAL(10,2),
    quantity INT
);Mogelijk gemaakt door

Klantgegevens worden in elke rij herhaald. Een e-mailadres updaten betekent al hun orders vinden en aanpassen.

Na normalisatie:

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    name VARCHAR(100),
    price DECIMAL(10,2)
);

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT REFERENCES customers(customer_id),
    product_id INT REFERENCES products(product_id),
    quantity INT
);Mogelijk gemaakt door

Klantinfo bestaat één keer. Queries hebben joins nodig, maar updates gebeuren op één plek.

Hoe kies je de juiste normalisatietechniek

Tot slot geef ik je een besliskader voor de volgende keer dat je je afvraagt welke normalisatietechniek je moet gebruiken.

Min-max wanneer grenzen bestaan

Min-max-schaling werkt het best wanneer je data bekende, stabiele grenzen heeft die niet veranderen tussen training en uitrol. Pixelwaarden liggen altijd tussen 0 en 255. Kansscores kunnen niet boven 1 uitkomen. Examencijfers hebben gedefinieerde minima en maxima.

Deze aanpak past ook wanneer je model specifiek begrensde input verwacht, zoals sommige neurale netwerkarchitecturen. Vermijd echter min-max-schaling wanneer er uitschieters aanwezig zijn, aangezien één extreme waarde alle normale observaties kan samendrukken tot een smalle band nabij nul.

Standaardiseren als vangnet

Standaardiseren is een redelijk uitgangspunt wanneer je geen sterke aannames hebt over de grenzen of verdeling van je data. Het werkt goed voor kenmerken met variërende bereiken, onbekende limieten of ruwweg klokvormige verdelingen.

Veel algoritme-implementaties veronderstellen of bevelen gestandaardiseerde input aan, waaronder de meeste neurale netwerkframeworks en libraries voor logistische regressie. Als je niet zeker weet welke aanpak je moet gebruiken en je data geen duidelijke natuurlijke grenzen heeft, is standaardiseren meestal een veilige keuze.

Robuust voor echte wereld-rommeligheid

Robuust schalen wordt de juiste keuze wanneer je data significante uitschieters bevat die legitieme waarden vertegenwoordigen in plaats van fouten. Financiële transactiegegevens hebben dit kenmerk vaak: de meeste aankopen zijn klein, maar af en toe grote bedragen zijn echt en moeten in de dataset blijven.

Inkomensverdelingen, sensoraflezingen met af en toe pieken en elke data met zware scheefheid of lange staarten profiteren van robuust schalen. De mediaan en interkwartielafstand blijven verankerd in de bulk van je verdeling ongeacht wat er in de extremen gebeurt.

Wanneer niet normaliseren

Boomgebaseerde modellen zoals random forests, XGBoost en gradient boosted trees splitsen op drempelwaarden en berekenen nooit afstanden of gradiënten over kenmerken. Schaal is voor hen onzichtbaar, dus normaliseren voegt complexiteit toe zonder voordeel.

One-hot-encoded kenmerken zijn al binair (0 en 1), dus schalen doet daar niets nuttigs. Datasets die alleen categorisch zijn, vallen in dezelfde categorie.

Soms werken domeinspecifieke transformaties beter dan generieke normalisatie:

• Logschaling comprimeert lange rechterstaarten en spreidt samengeklonterde lage waarden, wat vaak beter werkt voor inkomens- of prijsdata dan standaardaanpakken. 
• Binnen is logisch wanneer categorielidmaatschap belangrijker is dan precieze numerieke waarden. 
• Machtstransformaties helpen de variantie in specifieke situaties te stabiliseren.

Samenvattende vergelijktabel

Hier is een overzicht van de technieken en hun use-cases:

Conclusie

Schaalverschillen veroorzaken echte problemen voor modellen die daar gevoelig voor zijn. Afstandsmaatstaven bevoordelen kenmerken met grote grootte. Gradient descent worstelt wanneer gradiënten ordegroottes verschillen. Training stokt of explodeert om redenen die niet duidelijk zijn door naar de code of architectuur te kijken.

Normalisatie pakt dit aan. Gebruik min-max-normalisatie voor begrensde data, robuust schalen wanneer uitschieters echt zijn en niet verwijderd kunnen worden, en standaardiseren als redelijke standaard. De mechaniek is eenvoudig: fit in training, pas overal consistent toe. 

Uit mijn ervaring kost het tijd om niet te herkennen wanneer schalen ertoe doet en vervolgens dagenlang modelgedrag te debuggen terwijl preprocessing het antwoord was. Of de omgekeerde fout: schalen reflexmatig toepassen op modellen die er niet om geven, wat complexiteit toevoegt zonder voordeel.

Klaar om een stap verder te gaan? Onze uitgebreide Machine Learning Engineer track leert je alles wat je moet weten over de machinelearningworkflow.