AI-engineering deel 2: versiebeheer van gegevens en beheer van afhankelijkheden

In mijn vorige column presenteerde ik onze onderzoeksagenda voor AI-engineering. Deze keer gaan we ons richten op een van de onderwerpen op die agenda, namelijk het beheer van dataversies en afhankelijkheden. Hoewel het big data-tijdperk nu al meer dan tien jaar bezig is, worstelen veel van de bedrijven waar we mee werken nog steeds met hun datapijplijnen, data lakes en datawarehouses.

Aangezien we voornamelijk werken met de embedded systeemindustrie in de B2B-ruimte, is een van de eerste uitdagingen waar veel bedrijven mee worstelen de toegang tot gegevens en eigendomskwesties. Zoals ik in een [eerdere column] (https://bits-chips.nl/artikel/get-your-data-out-of-the-gray-zone/) heb besproken, is het belangrijkste dat in plaats van uw gegevens in een soort grijze zone te laten bestaan waarin het onduidelijk is wie de eigenaar van wat is, het essentieel is om vragen rond toegang, gebruik en eigendom van gegevens tussen uw klanten en uw bedrijf aan te pakken. En natuurlijk moeten we duidelijk en transparant zijn over het gebruik van de gegevens en hoe de gegevens worden geanonimiseerd en samengevoegd voordat ze met anderen worden gedeeld.

De tweede uitdaging op dit gebied hangt samen met het toenemende gebruik van DevOps. Omdat het genereren van gegevens als technologie veel minder volwassen is dan bijvoorbeeld API-beheer in software, hebben teams de neiging om nogal ad-hoc wijzigingen aan te brengen in de manier waarop loggegevens worden gegenereerd, omdat ze denken dat zij de enige gebruikers van de gegevens zijn en dat deze alleen door hen worden gebruikt om het gedrag van de functionaliteit waaraan het team werkt te evalueren. Bijgevolg hebben andere gebruikers van de gegevens de neiging om frequente verstoringen van de gegevensstroom en de inhoud ervan te ervaren.

De frequente veranderingen in gegevensformaten en manieren om gegevens te genereren vormen vooral een uitdaging voor machine learning (ML) toepassingen, omdat de prestaties van de ML-modellen sterk afhankelijk zijn van de kwaliteit van de gegevens. Veranderingen in de data kunnen dus onverwachte verslechteringen van de prestaties veroorzaken. Omdat ML-modellen vaak veel data nodig hebben, willen we meestal grote datasets gebruiken voor training. Daarom combineren we de data van meerdere sprints en DevOps implementaties in een enkele trainings- en validatiedataset. Maar als de gegevens die door elke implementatie worden gegenereerd subtiel (of niet zo subtiel) verschillen, kan dat een uitdaging worden.

De derde uitdaging is dat datapijplijnen vaak impliciete afhankelijkheden hebben die onverwacht naar boven kunnen komen bij het doorvoeren van wijzigingen of verbeteringen. Consumenten van datastromen kunnen plotseling worden uitgeschakeld en aangezien er meestal een aanzienlijke bedrijfskritische waarde is verbonden aan de functionaliteit die door de consument wordt geïmplementeerd, leidt dit gemakkelijk tot blusacties om de consument van de data weer online te krijgen. Maar ook al is dit een leuke endorfine-kick voor de cowboys in de organisatie, feit is dat we dit soort problemen eigenlijk niet hadden moeten ervaren. In plaats daarvan moeten de partijen die gegevens genereren, verwerken en consumeren goed worden aangestuurd en moet de evolutie van de pijplijn en de inhoud ervan worden gecoördineerd tussen de betrokken spelers.

Dit zijn slechts enkele van de uitdagingen op het gebied van gegevensbeheer. In eerder onderzoek hebben we een uitgebreid overzicht gegeven van de uitdagingen op het gebied van gegevensbeheer. In ons huidige onderzoek werken we aan een domeinspecifieke taal om datapijplijnen te modelleren, inclusief de verwerkings- en opslagknooppunten en hun onderlinge connectoren. Het doel op de lange termijn is om operationele pijplijnen te kunnen genereren die monitoringoplossingen bevatten die de afwezigheid van datastromen kunnen detecteren, zelfs in het geval van batch levering van gegevens, evenals een groot aantal andere afwijkingen.

Daarnaast hebben we gewerkt aan een “data linter” oplossing die kan waarschuwen wanneer de inhoud van de gegevens verandert, variërend van eenvoudige veranderingen zoals ontbrekende of buiten het bereik vallende gegevens tot meer gecompliceerde veranderingen zoals verschuivende statistische verdelingen in de tijd. De oplossing kan waarschuwen, gegevens verwerpen en mitigatiestrategieën in gang zetten die de problemen met de gegevens aanpakken zonder de werkzaamheden te onderbreken. Neem contact met me op als je meer wilt weten.

Concluderend, databeheer, inclusief versiebeheer en afhankelijkheden, is een verrassend ingewikkeld onderwerp waar veel bedrijven nog niet uit zijn. Het verschil in volwassenheid tussen de manier waarop we omgaan met software en met gegevens is gewoon onthutsend, vooral bij bedrijven die embedded systemen maken, waar gegevens van oudsher alleen werden gebruikt voor defectbeheer en kwaliteitsborging. In ons onderzoek werken we samen met bedrijven om een stapsgewijze functiewijziging door te voeren in de manier waarop gegevens worden verzameld, verwerkt, opgeslagen, beheerd en geëxploiteerd. Omdat data volgens sommigen de nieuwe olie is, is het van cruciaal belang om deze net zo serieus te nemen als elk ander bedrijfsmiddel.