Data engineering voor AI: van rommelige data naar betrouwbare pipelines

Data engineering voor AI is het werk van het verzamelen, opschonen, ordenen en verplaatsen van data, zodat machine-learningmodellen een gestage stroom van accurate, goed gevormde informatie ontvangen. Als een model de motor is, dan is data engineering tegelijk de brandstofleiding, het filter en de raffinaderij. Het is het verschil tussen een AI die stilletjes verkeerde antwoorden produceert op verouderde data, en een AI die vertrouwen verdient omdat de cijfers erachter correct, vers en consistent zijn. De meeste AI-projecten mislukken niet omdat het model zwak is. Ze mislukken omdat de data die het voedt rommelig, te laat of ongemerkt kapot is.

Dat is een weinig glamoureuze waarheid, en het is de moeite waard om het ronduit te zeggen. Het slimme deel van een AI-project haalt de krantenkoppen, maar het is de data engineering die ervoor zorgt dat het daadwerkelijk werkt op een dinsdagmiddag, wanneer echte klanten het gebruiken.

Wat doet een data engineer eigenlijk?

Haal de jargon weg en een data engineer bouwt de systemen die de juiste data in de juiste vorm op de juiste plek krijgen. In de praktijk betekent dat een handvol terugkerende taken.

• Verzamelen van data waar die ook maar leeft: je CRM, je boekhoudsysteem, spreadsheets, de API van een SaaS-tool, sensorlogs, pdf's, soms een database die niemand meer heeft aangeraakt sinds 2019.
• Opschonen ervan: datums repareren die op vijf verschillende manieren zijn opgeslagen, duplicaten verwijderen, ontbrekende waarden afhandelen, en verzoenen dat "NL", "Nederland" en "The Netherlands" allemaal hetzelfde land bedoelen.
• Transformeren naar een vorm die een model of een rapport kan gebruiken: gejoind, geaggregeerd, ontdubbeld, gestandaardiseerd.
• Verplaatsen en opslaan op een betrouwbare manier, zodat de data op tijd aankomt en een uitval van een systeem overleeft.
• Monitoren van de hele keten, zodat je het merkt voordat je klanten dat doen wanneer er iets stukgaat.

Niets hiervan is glamoureus. Alles ervan is dragend. Een model dat is getraind op een schone, goed ge-engineerde dataset wint meestal van een chiquer model dat is getraind op een rommeltje. Dit hangt nauw samen met de vraag of je data überhaupt klaar is, iets wat we behandelen in is je data AI-ready.

Wat is een data pipeline, in gewone taal?

Een data pipeline is een geautomatiseerde reeks stappen die data uit een bron haalt, verwerkt en aflevert bij een bestemming, op een schema of in realtime, zonder dat iemand iets kopieert en plakt.

Stel je een lopende band voor in een fabriek. Aan de ene kant gaan grondstoffen erin. Langs de band worden dingen gesorteerd, gewassen, geassembleerd en gekeurd. Aan de andere kant komt een afgewerkt product naar buiten, klaar voor gebruik. Een data pipeline is die band voor informatie. Ruwe data komt erin, elke fase doet één taak, en schone, modelklare data komt eruit.

De reden dat pipelines ertoe doen voor AI is herhaalbaarheid. Je wilt geen eenmalige heldhaftige inspanning waarbij iemand handmatig een spreadsheet in elkaar knutselt voor de demo. Je wilt dat hetzelfde proces vanavond draait, morgenavond, en elke avond daarna, met steeds hetzelfde betrouwbare resultaat. Een model dat van data leert, is slechts zo goed als de pipeline die die data actueel houdt. (Voor waarom modellen verouderen als je stopt met ze voeden, zie waarom ML-modellen stoppen na training.)

ETL vs ELT: wat is het verschil en maakt het uit?

Je hoort twee afkortingen rondvliegen: ETL en ELT. Ze beschrijven de volgorde van de bewerkingen in een pipeline, en het onderscheid is simpeler dan het klinkt.

ETL staat voor Extract, Transform, Load. Je haalt de data eruit, schoont en hervormt die, en laadt daarna het afgewerkte resultaat in je warehouse. Dit was decennialang de klassieke aanpak, vooral toen opslag duur was en je alleen de opgeruimde versie wilde bewaren.

ELT staat voor Extract, Load, Transform. Je haalt de data eruit, laadt de ruwe versie eerst in een modern cloud warehouse, en transformeert die daar naar behoefte. Opslag is nu goedkoop, dus de ruwe data bewaren en die on demand vormgeven is de populaire standaard geworden. Het is flexibel: als je de data later in een andere vorm nodig hebt, staat de ruwe bron er nog.

Voor het meeste AI-werk vandaag de dag is ELT het verstandige startpunt. Maar het eerlijke antwoord is dat de afkorting minder uitmaakt dan de discipline. Waar je echt om geeft, is: klopt de data, is die vers, en kun je traceren waar elk cijfer vandaan komt? Een team dat zich vastbijt in de letters en die drie vragen negeert, mist de kern.

Wat is een feature pipeline, en waarom heeft AI er een nodig?

Hier verschillen AI-pipelines van gewone rapportagepipelines. Modellen leren niet van ruwe records. Ze leren van features: de specifieke, berekende signalen die je het model voert.

"Aantal bestellingen in de laatste 90 dagen." "Gemiddelde reactietijd per klant." "Dagen sinds laatste login." Elk hiervan is een feature, berekend uit je ruwe data. Een feature pipeline is het deel van je data engineering dat ruwe gebeurtenissen omzet in deze modelklare signalen, betrouwbaar en consistent.

Dat betrouwbaarheidsaspect is cruciaal, en het laat veel teams struikelen. De features die je berekent tijdens het trainen van het model moeten op precies dezelfde manier worden berekend wanneer het model live draait. Als "laatste 90 dagen" tijdens de training iets anders betekent dan in productie, dan verslechtert de prestatie van je model in de echte wereld stilletjes en kan niemand uitvinden waarom. Deze mismatch, vaak training-serving skew genoemd, is een van de meest voorkomende redenen waarom een model dat er in de test geweldig uitzag, teleurstelt in het wild. Het goed krijgen is een groot deel van wat een demo onderscheidt van machine learning in productie.

Hoe bouw je een pipeline die je echt kunt vertrouwen?

Betrouwbaarheid is geen functie die je er aan het eind aan vastschroeft. Het wordt vanaf de eerste stap ingebouwd. Een pipeline die je kunt vertrouwen deelt meestal een aantal gewoonten.

1. Valideer data bij binnenkomst. Controleer of waarden in de verwachte bereiken vallen, of verplichte velden aanwezig zijn, of het aantal rijen ongeveer is wat je verwacht. Vang de kapotte leveranciersfeed op maandag, niet in het model van het volgende kwartaal.
2. Maak elke run reproduceerbaar. Dezelfde input hoort dezelfde output te geven. Geen verborgen handmatige stappen, geen "je moet het twee keer draaien bij volle maan".
3. Bewaar de ruwe data. Als je alleen de getransformeerde versie opslaat en er zat een bug in je logica, kun je niet terug. Ruwe data is je vangnet.
4. Monitor versheid en volume. Meldingen die zeggen "het bestand van vandaag is half zo groot als normaal" of "vanochtend is er geen data binnengekomen" vangen de meeste praktijkstoringen op voordat ze een model bereiken.
5. Documenteer lineage. Wees in staat om voor elk cijfer waarop de AI leunt de vraag "waar komt dit getal vandaan?" te beantwoorden. Onder de AVG en de EU AI Act is dit niet alleen goede praktijk, het wordt steeds vaker verwacht.
6. Ga elegant om met falen. Netwerken vallen uit, API's rate-limiten, bestanden komen te laat. Een goede pipeline probeert opnieuw, slaat netjes over en waarschuwt iemand, in plaats van stilletjes half-lege data te produceren.

Een model dat wordt gevoed door een pipeline met deze gewoonten zal minder hallucineren, minder driften en veel makkelijker te debuggen zijn. (Over waarom modellen dingen verzinnen wanneer de input mager is, zie wat is AI-hallucinatie.)

Waar past dit in de grotere AI-stack?

Data engineering is de fundamentlaag. Daarbovenop zitten training, serving, retrieval en het model zelf. Als je een systeem bouwt dat dingen opzoekt in je eigen documenten, dan bepaalt de kwaliteit van de onderliggende pipeline de kwaliteit van de antwoorden. Dat geldt ook voor retrieval-augmented systemen, waar schone, goed-gechunkte brondata alles is. Als die termen nieuw zijn, dan zijn wat is RAG en RAG vs fine-tuning goede metgezellen, en de production AI-stack laat zien hoe de lagen samenhangen.

Het nuttige mentale model: data engineering is de onderkant van de piramide. Alles erboven erft de kwaliteit ervan, goed of slecht. Je kunt een slim model bouwen op een wankel fundament, maar het zal wiebelen. Een bescheiden model op solide data engineering zal er stilletjes beter presteren.

Kun je de data gebruiken die je al hebt?

Meestal wel, en meer ervan dan je denkt. De meeste organisaties zitten op jaren aan operationele data in hun bestaande systemen. Het werk gaat zelden over het kopen van nieuwe data; het gaat over het verbinden, opschonen en vormgeven van wat je al bezit. We graven hier dieper in bij bestaande data gebruiken om AI te trainen, en de AVG-veilige aanpak om dat op bedrijfsdata te doen in AI trainen op bedrijfsdata en de AVG.

Het is de moeite waard om hier nuchter te zijn over de inspanning. Jaren aan inconsistente records opruimen kost echt tijd, en elke eerlijke partner zal je dat vooraf vertellen in plaats van een magische importknop te beloven. Goede data engineering is geduldig werk. Het is ook het werk dat zich jarenlang terugbetaalt, want elk toekomstig AI-project put uit datzelfde schone fundament.

Hoeveel pipeline heb je echt nodig?

Hier wordt veel geld verspild. Het instinct is om een groots, toekomstbestendig dataplatform te bouwen voordat je hebt bewezen dat de AI iets nuttigs doet. Dat is meestal andersom.

Een verstandiger pad is om de kleinste betrouwbare pipeline te bouwen die de waarde bewijst, en die daarna uit te breiden. Voor een eerste project heb je vaak veel minder infrastructuur nodig dan een leverancier je probeert te verkopen. Begin met één goed ge-engineerde dataset die één model voedt dat één echt probleem oplost. Als het werkt, schaal je het leidingwerk op. Als het niet werkt, heb je een paar duizend euro besteed om dat te bewijzen in plaats van een paar honderdduizend om een platform te bouwen voor een model dat het toch nooit ging halen. Wij scopen projecten precies op deze manier, wat de logica is achter hoe je een AI-proof-of-concept scopet en wat AI-implementatie echt kost.

Er is een verwante disciplinevraag die het waard is om te stellen: data engineering is niet hetzelfde als business-intelligence-dashboards, en het is niet hetzelfde als data science. Rapportagetools laten je het verleden zien. Data engineering bouwt de toevoerlijnen. Weten wat je daadwerkelijk nodig hebt, bespaart echt geld, en het is een deel van waarom machine learning vs AI en machine learning voor bedrijven het lezen waard zijn voordat je een budget vastlegt.

Waar Crux Digits past

Wij zijn een klein AI-adviesbureau in de regio Utrecht in Nederland, en een flink deel van ons werk is precies dit: de rommelige, verspreide data van een klant omzetten in pipelines die modellen betrouwbaar voeden, met de AVG en de EU AI Act ingebouwd in plaats van er achteraf op vastgeschroefd. We doen projecten met een vaste scope, geen mensen-voor-de-huur en geen dashboards. Een korte AI-audit en strategie vertelt je eerlijk of je data klaar is en wat er nodig zou zijn om dat zo te maken, voordat iemand een regel pipelinecode schrijft.

Als je afweegt of je data de AI kan ondersteunen die je in gedachten hebt, dan is dat een goed gesprek om vroeg te voeren. Je bent welkom om contact op te nemen of meer te lezen over hoe wij AI-consulting in Nederland aanpakken. Geen harde verkoop, en als het eerlijke antwoord is "je bent er nog niet klaar voor", dan zeggen we dat.

Rommelige data is normaal. Elke organisatie heeft het. Het doel van data engineering is niet perfectie. Het is het bouwen van pipelines die betrouwbaar genoeg zijn zodat je AI vertrouwd kan worden, en geduldig genoeg om dat vertrouwen te blijven verdienen terwijl je data blijft veranderen.

Veelgestelde vragen