Enorme taalmodellen moeten worden getraind met enorme datasets. Om die te verzamelen wordt op geen bron meer of minder gekeken: The Pile, zowat de grootste dataset van Engelstalige tekst die vandaag bestaat, tikt ongeveer 825 GB aan. De volledige Engelstalige Wikipedia maakt er deel van uit, voor 6.3 GB, oftewel 0.7% van de collectie. Andere databronnen zijn CommonCrawl , OpenWebText , maar er worden ook tekstfragmenten gebruikt afkomstig van Github, ArXiv, PubMed, StackExchange, OpenSubtitles, zelfs het Europees Parlement.

Veel van die datasets zijn met eenvoudige webscraping scripts verzameld. Of dat allemaal wel mag volgens copyright- en privacywetgevingen allerhande, is een ingewikkelde vraag met een nog ingewikkelder antwoord en dus maakt men daar voor het gemak in eerste instantie vaak abstractie van. Kwaliteitschecks en fijnmazige filters zijn tijdrovend als je ze accuraat wil maken, en in de wedloop om het grootste taalmodel sneuvelen die dus helaas ook maar al te vaak.

Gegeven de enorme verscheidenheid aan bronnen, websites, tekstformatteringen en dataverzamelingsmethodes, is het zo haast onvermijdelijk geworden dat in datasets van die grootteorde toch nog persoonsgegevens of auteursrechtelijk beschermde teksten terechtkomen – zelfs als men moeite doet om enigszins correct te handelen. Reden genoeg om zelf eens in zo’n dataset te duiken en te kijken wat we daarin terugvinden.

OSCAR

OSCAR is een meertalige dataset die regelmatig wordt gebruikt voor niet-Engelstalige taalmodellen. De Nederlandstalige subset ervan kan dienen als basis van een Nederlandstalige tekstgenerator. OSCAR is op zijn beurt afgeleid van CommonCrawl, een grootschalige dataset van scraped websites, waarvan de makers wel aangeven dat robots.txt en HTML no-follow specificaties gehonoreerd werden, maar waar verder weinig meer mee gebeurd is dan gegevensopslag. OSCAR groepeert die per taal, voegt wat extra preprocessing toe, en zet de tekstfragmenten in willekeurige volgorde, om zo copyrightproblemen te vermijden. We doen hier geen uitspraak over de vraag of dat wel voldoende is voor dat doel. Een bijkomend effect daarvan is wel dat de inhoudelijke relatie tussen opeenvolgende tekstfragmenten in deze dataset dus verloren is gegaan. (De laatste paper van de auteurs probeert daar alsnog een mouw aan te passen.)

We bekijken de Nederlandstalige gegevens uit de eerste versie van deze dataset uit 2019 (toegang tot versie 2021 of versie 2022 vereisen registratie of aanvraag). Deze is vrij beschikbaar in de dataset repository van Huggingface, dat ook een eerste preview van de inhoud voorziet. Bij Huggingface vermeldt men summier dat de dataset persoonlijke of gevoelige informatie kan bevatten, en dat de training van een AI-model op basis van deze dataset gevoelig kan zijn voor biases, zonder dieper in te gaan op deze problematiek. De verantwoordelijkheid hiervoor wordt bij de gebruiker van de dataset gelegd.

De Nederlandstalige subset van OSCAR bestaat uit 126.064.721 tekstfragmenten van één tot enkele zinnen lang, die we kunnen samengevoegen tot 1 tekstbestand met een grootte van ongeveer 40GB. In wat volgt doorzoeken we deze dataset naar gegevens die als persoonlijk of gevoelig beschouwd zouden kunnen worden. Het valt aan te nemen dat die gegevens grotendeels zijn gescrapet zonder medeweten van de originele auteurs of van de websites waarop ze oorspronkelijk gepubliceerd waren. We tonen telkens een selectie van wat we zoal terugvinden ter illustratie, maar om de mogelijke privacy- en copyrightproblemen niet erger te maken dan ze al zouden kunnen zijn, maskeren we in dit artikel de gevonden gevoelige gegevens alsnog en markeren we ze rood.

Gevoelige gegevens in OSCAR

Door gewoon reguliere expressies toe te passen, die je vaak kan copy-pasten van het internet, kunnen we al veel boven water halen. Om emailadressen te detecteren, gebruiken we een relatief eenvoudig patroon, waarmee we 685.968 potentiële matches terugvinden (let wel dat veel algemene emailadressen, bijvoorbeeld van helpdesks of infolijnen of grote organisaties, herhaaldelijk voorkomen):

grep -a -e "[a-zA-Z0-9._]\+@[a-zA-Z]\+.[a-zA-Z]\+" oscar_nl_full.txt

• Ik gooide enkele nieuwe data online! Wie zin heeft kan zich inschrijven door te mailen naar e*******s@gmail.com
• Ontdek hoe je een WordPress thema vindt dat echt bij jou past! www.speciaalgeselecteerd.nl jouw gids voor WordPress thema s Door: S******* v** N******** Datum: 1-1-2016 E-mail: s********@innonet.nl WordPress
• De hoofdleiding bestaat uit D***** V******, G***** G*******, M**** W****** en F***** V*** B*****, hen kan je contacteren via 0497****** (D*****), 0493****** (G*****), 0477****** (M****) en 0498****** (F*****). Een mailtje naar i***@c*********.be is ook altijd mogelijk. Zij zullen jullie graag helpen met vragen, opmerkingen of klachten.

Veel emailadressen lijken afkomstig van contactpagina’s op websites van bedrijven, organisaties, maar je herkent ook overduidelijk verenigingen, lokale initiatieven, jeugdbewegingen, en forumgebruikers die hun persoonlijke contactgegevens achterlaten, waaronder telefoonnummers. Het volgende patroon zoekt naar cijfercombinaties die eruit zien als een Belgisch telefoonnummer, in de meest voorkomende schrijfwijzen. (Het patroon is iets te algemeen opgesteld, met als nadeel dat we er ook onderdelen van niet-telefoonnummers mee vinden.) Dat leidt alleszins al tot 289.461 potentiële matches:

grep -a -P "(((\+|00)32[ ]?(?:\(0\)[ ]?)?)|0){1}(4(60|[789]\d)\/?(\s?\d{2}\.?){2}(\s?\d{2})|(\d\/?\s?\d{3}|\d{2}\/?\s?\d{2})(\.?\s?\d{2}){2})" oscar_nl_full.txt 

• Tijdens de openingstijden kan je via de Live Chat of via de telefoon 07******** vragen stellen aan één van onze medewerkers.
• […] Heeft u vragen over onze werkwijze, prijzen of materialen dan zijn we bereikbaar op de nummers 03/***.**.** en 03/***.**.**. Ook kunt u een e-mail sturen naar [email protected] of het contactformulier invullen.
• Op 22 september vertrekken we op speel-weekend naar Ronse. Wil je nog mee? Als de bliksem bellen naar R******* 0496/**.**.**
• Propere betonnen palen 8 stuks, geen beton/cement aan de onderkant van de paal- lengte 2.05m. Bieden vanaf €7/stuk. Tel 0478/******

Ook hier vinden we veel contactgegevens van bedrijven, maar een aanzienlijk deel zijn ook persoonlijke telefoonnummers afkomstig van berichten die mensen postten op online marktplaatsen of zoekertjeswebsites. Bankrekeningnummers, BTW-nummers e.d. duiken ook op tussen de gevonden data. Om te blijven focussen op persoonsgerelateerde data, gaan we nog op zoek naar Twitter of Instagram handles. Deze kunnen bijvoorbeeld afkomstig zijn van conversaties op Twitter en Instagram zelf, van internetfora waar mensen erover spreken, of van de footers van webpagina’s met links naar sociale media. Afgezien van enkele bedrijven wiens naam of product met een @ begint, gaan achter de meeste gevonden handles echte, actieve mensen of organisaties schuil. We vinden zo 131.364 potentiële matches:

grep -a -e " @[a-zA-Z0-9]\+" oscar_nl_full.txt

• Vandaag waren we op bezoek bij Leo Timmers, maker van Een huis voor Harry, het Prentenboek van het Jaar 2019! En we gingen Billy ontmoeten, de kat waar Harry op geïnspireerd is. Ik had dus de dag van m’n leven. @v*********** #cat #books #brussels #reading #catsofbrussels #eenhuisvoorharry 
• […] R***** twitterde dit naar mij en @p********, afgelopen zondagmiddag. We hadden het over de blogs die Ruud had willen schrijven die dag: drie stuks maar liefst. De blogs kwamen er inderdaad niet. Nooit meer. R***** overleed maandagavond [datum]. Ik heb een goede vriend verloren.
• Zeg @******** wat willen jullie nou in de omgangsvorm: ‘u’ of ‘je’? Maak een keuze! https://t.co/********
• @******** En niet alleen dat. Het kenteken *-***-** staat mooi op beeld. Kijk dus uit voor deze asociale weggebruiker, mede-weggebruikers. @ [datum]

Er duikt duidelijk een heel palet aan persoonsgebonden informatie in deze dataset op, zoals ook nummerplaten, berichten over ziekte of overlijden, politieke voorkeuren, informatie over wanneer personen waar geweest zijn, en nog heel wat meer. Met hetzelfde gemak vinden we ook beledigingen tegen personen terug, verwensingen allerhande, racistische fragmenten, … we kunnen alleszins heel lang bezig blijven als we hierop enige grip willen krijgen in zo’n dataset.

Een heel ander gevoelig onderwerp is erotische inhoud. Er zijn alvast 2.459.800 matches voor woorden die beginnen met “seks” of “sex” in dit eerste deeltje van de dataset. Voorbeelden daarvan geven we terwille van de goede smaak niet mee, maar u mag de auteur op zijn woord geloven dat de meeste gevonden tekstfragmenten niet van droog-wetenschappelijke papers of schoolse seksuele opvoeding afkomstig zijn. Op een totaal van 126 miljoen zinnen, kunnen we zo schatten dat zulke inhoud ongeveer 2% van het totaal uitmaakt in deze dataset. 

Kom ik er in voor?

Dat kunnen we gemakkelijk achterhalen:

grep -a -e "Joachim Ganseman" oscar_nl_full.txt  

• De 27e Internationale Olympiade Informatica vond plaats in Almaty, Kazachstan. De Belgische ploeg werd gevormd door Damien Galant (5e middelbaar), Robin Jadoul, Mattéo Couplet en Nico Ekkart (allen 6e middelbaar). Zij werden begeleid door Damien Leroy en Joachim Ganseman. […]
• […] De bouwstenen voor artificiële intelligentie (AI) liggen klaar, maar ze staan op los zand. Dhr. Joachim Ganseman van Smals Research bestudeerde de zwaktes van AI. In zijn artikel op de Research-blog bespreekt hij een aantal uitdagingen voor de toekomst.
• Joachim Ganseman wordt onderscheiden voor de ijver waarmee hij als jonge doctoraatsstudent de Belgische informatica-olympiade heeft gesticht, coördineert en communiceert in beide landshelften, met bijzondere inspanningen voor de toegankelijkheid voor alle leerlingen, ongeacht voorkennis.

In 7 tekstfragmenten komt mijn volledige naam voor, voornamelijk in verband met mijn engagement bij de Belgische Informatica-olympiade van 2011 tot 2018. Geen info die iets schandaligs of schaamtelijks bevat, integendeel, maar ik was niet op de hoogte. Als je ooit met naam en toenaam in de krant of op een website van een grotere organisatie hebt gestaan, lijkt de kans alleszins groot dat je naam in dat verband ook in de OSCAR dataset voorkomt. Het blijft dus erg belangrijk om in het achterhoofd te houden dat dat wat eenmaal op het internet staat, er erg moeilijk terug af gaat.

Misschien kan het een goed idee zijn om, naar analogie van Have I Been Pwned die je waarschuwt voor paswoordlekken, een gelijkaardige dienst te hebben bij dataset repositories waarmee gebruikers kunnen checken of hun persoonlijke informatie voorkomt in datasets? Tijd en middelen ontbreken om zoiets zelf verder uit te werken, maar we laten het hier staan als een interessante suggestie.

En dan?

We moeten nog vermelden dat de makers van de CommonCrawl en OSCAR datasets zelf niet Nederlandstalig zijn. Zij hebben dan ook niet onmiddellijk manieren ter beschikking om de verzamelde fragmenten in het Nederlands (en in de meeste van de andere 165 talen in OSCAR) op hun inhoudelijke merites te gaan beoordelen, en presenteren deze datasets “as is”.

Gegeven het feit dat persoonsgebonden gegevens gemakkelijk te vinden zijn op het internet voor wie een beetje zoekt – en zeker op sociale media of op marktplaatsen waar ze gretig uitgewisseld worden – is het niet verwonderlijk dat deze gegevens ook terechtkomen in datasets verzameld via webscraping, als er een breed net wordt uitgegooid en weinig wordt gefilterd.

Smals Research is een technisch team zonder juristen in haar rangen; we laten uitspraken over het wettelijke kader rond webscraping, auteursrechten, en de gebruiksvoorwaarden van websites, in een internationale context, dan ook liever over aan mensen die daar meer van kennen dan wij. Het is in onze sector wel algemeen bekend dat de persoonsgegevens van EU-ingezetenen beschermd worden door de GDPR. Dat houdt onder andere in dat zij de inzage en verwijdering van hun gegevens moeten kunnen vragen, en informatie moet kunnen krijgen over het gebruik ervan. Het wordt natuurlijk moeilijk om dat recht effectief uit te oefenen, als gegevens op elk moment in een externe database kunnen worden overgenomen, zonder medeweten van die persoon of zelfs van de website waarop ze gepubliceerd waren.

Wie van zulke datasets gebruik maakt om AI systemen te trainen, is technisch gesproken de daarin begrepen persoonsgegevens aan het verwerken, en lijkt zo alvast automatisch een verantwoordelijkheid te hebben ten aanzien van die betreffende personen. Het is daarnaast niet ondenkbaar dat een verkeerd of slecht getraind AI-systeem deze gegevens expliciet opneemt in het resulterend model, en ze aanwendt om bepaalde beslissingen te nemen, wat een risico op bias met zich meebrengt. Tot slot weet je nooit of er ergens een slecht beveiligde website gescrapet werd door de dataset-maker, waardoor er misschien login-gegevens of paswoorden voorkomen in de dataset.

Een alternatieve werkwijze

De onderzoeksgroep Computationele Linguïstiek van de Universiteit van Groningen bouwde een eigen variant van een Nederlandstalig GPT-2 model. Zij zijn natuurlijk wél Nederlandstalig, en waren ook selectiever in het kiezen van hun trainingsdata. In hun paper lezen we dat die bestaat uit de Nederlandstalige Wikipedia (2.0GB), een grote hoeveelheid E-books (6.5GB), een dataset van nieuwsartikels die weliswaar nog van 2007 dateert (2.9GB) aangevuld met artikels van andere nieuwswebsites (2.1GB). Na het wegfilteren van duplicaten is dat goed voor een trainingsdataset van 13GB aan Nederlandstalige tekst. Gegeven deze bronnen is het aannemelijk dat hun dataset alvast correcter geschreven Nederlands bevat van een inhoudelijk hogere standaard.

De eigenlijke dataset vonden we na een korte zoektocht niet onmiddellijk terug, dus het is moeilijk de inhoud verder te bekijken – wie weet waar ze ergens beschikbaar zou zijn, mag het steeds laten weten. Het valt alleszins te verwachten dat de inhoud van deze dataset minder problematisch zal zijn op het vlak van persoonlijke gegevens dan OSCAR. Langs de andere kant stelt zich, met een dataset afkomstig van krantenartikels en e-books, misschien wel nog een copyrightprobleem.

Kieskeurig zijn qua trainingsdata heeft weliswaar een keerzijde. Een generatief taalmodel getraind op een selecte dataset is gelimiteerder qua teksten die het kan produceren. Tekstfragmenten die lijken op sociale-media-posts zullen moeilijk gegenereerd kunnen worden door een model dat niet getraind werd op data afkomstig van sociale media, en een hoge aandeel e-books leidt ook tot prozaïscher teksten. Tot slot maakt het groot aandeel van oudere nieuwsartikels ook dat het getrainde model teksten “uit die tijd” zal produceren, en relatief minder woordenschat en zinswendingen kent over recente trends, technologische uitvindingen of politieke ontwikkelingen.

Conclusie

We hebben hier slechts één Nederlandstalige dataset onder de loep genomen, maar het spreekt voor zich dat dezelfde problemen zich stellen in gelijkaardige datasets voor andere talen.

Het valt op dat enkele eenvoudige filters, bijvoorbeeld om emailadressen, rekeningnummers, persoonlijke profielinformatie of andere persoonsgegevens te detecteren, al een heel deel van deze problematische inhoud zouden kunnen wegfilteren. Een sluitende garantie geven dat er niets fouts meer voorkomt is haast onmogelijk in datasets van deze grootteorde, maar hier hebben we toch kunnen illustreren dat er soms wel érg weinig moeite gedaan lijkt te zijn om de datasets een beetje op te schonen. 

Propere datasets maken, deze inhoudelijk onderzoeken en daarbij in de diepte graven, kost natuurlijk tijd en moeite – enkel om problematische stukjes weg te vijlen die in hun geheel maar een klein deeltje uitmaken van de hele dataset, wat dus waarschijnlijk ook maar een kleine impact zou hebben op het daaruit resulterende taalmodel. Het is moeilijk hard te maken dat zulk monnikenwerk zich economisch terugverdient, en garanties dat je effectief alles verwijdert zijn er evenmin.

Toch is het belangrijk dat er voldoende aandacht geschonken wordt aan de kwaliteit van de onderliggende datasets. Als dat niet werkbaar is vanwege hun grootte, moet je je minstens een idee vormen van de impact van mogelijke onregelmatigheden erin. Een data protection impact assessment is net daarvoor bedoeld, en is in sommige gevallen verplicht.

Het blind hergebruiken van een dataset die je zelf niet hebt samengesteld, is een slecht idee. Dat geldt bij uitbreiding eigenlijk ook voor het indirect gebruik ervan via een derde partij of een externe software-library. Dit is overigens een algemeen advies dat geldt voor elke toepassing van machine learning. Wie beter wil doen en ethiek wat hoger in het vaandel wil dragen, vindt goede startpunten in de paper Datasheets for Datasets en bij initiatieven zoals AI Now.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Als het doel is om een functioneel alternatief te voorzien voor gevoelige data, zijn tools voor de creatie van synthetische data bij uitstek geschikt. Ze kunnen immers meer dan enkel de bestaande gegevens door elkaar gooien: ze zijn gemaakt om de structuur van gegevens aan te leren, waarna je willekeurig veel nieuwe gegevens volgens dezelfde structuur kan aanmaken. In combinatie met generatoren voor totaal fictieve gegevens, hebben we daarmee alles voorhanden om niet alleen de originele gegevens te verbergen, maar ook om te zorgen dat wat in de plaats komt, realistisch oogt.

Dat betekent echter niet dat het een kwestie is van een druk op de knop. Eén en ander hangt af van allerlei randvoorwaarden en aannames over de inhoud en structuur van de gegevens. Afhankelijk van de beoogde toepassing of het doel, kan het nodig zijn om extra beperkingen en filters op te leggen, of misschien net om bepaalde delen van de gegevens buiten beschouwing te laten. In dit artikel kijken we vooral naar die praktische bekommernissen: wat kom je zoal tegen als data professional die synthetische data moet aanmaken?

Setup

Wie een dataset wil scramblen, heeft uiteraard toegang nodig tot de originele gegevens. Het spreekt voor zich dat het uploaden van gevoelige data naar een cloud service of zelfs het gebruik van een Docker container voorzien door een derde partij, slechts mogelijk is als er grondig is nagedacht over GDPR-compliance, eventueel een Data Protection Impact Assessments (DPIA) is opgesteld, en best ook met de DPO is overlegd. We doen zelf geen enkele uitspraak over de geschiktheid van eender welke tool vis-à-vis de GDPR-wetgeving. Voor al wat volgt gaan we ervan uit dat we werken met tabulaire, tekstuele of numerieke gegevens, die lokaal beschikbaar zijn – met andere woorden, een grote spreadsheet.

De markt

In een vorig artikel vermeldden we al enkele spelers vanuit de optiek van AI-projecten en software testing. Hier ligt onze focus meer op de privacybescherming en data science. Voor het analyseren en synthetiseren van tabulaire gegevens is er een heel sterk groeiende markt. Enkele interessante spelers zijn de volgende – en er zijn er ongetwijfeld nog veel meer:

• Mostly.ai
• YData
• Tonic
• Gretel
• Synthesized.io

Open source tools zijn er minder en zijn vaak afkomstig van projecten die op universiteiten zijn begonnen. Benerator vermelden we apart omdat deze al langer bestaat en ook een uitgebreid commercieel aanbod heeft. Jongere open source initiatieven zijn onder andere:

• Synthetic Data Vault (SDV)
• Mimesis
• Synthia
• Data Responsibly‘s DataSynthesizer
• MITRE’s Synthea / SyntheticMass (toegespitst op eHealth)

SDV is momenteel de populairste van de open source tools, en we gebruiken deze voor al wat volgt. In onze Quick Review vind je meer uitleg over deze tool.

Het stappenplan

Het plan van aanpak om synthetische data te produceren is bij de meeste tools heel gelijkaardig. We kunnen het onderverdelen in 6 grote stappen:

1. Upload en inlezen van de gegevens. Met name de tekst-encodering kan hier wel eens voor problemen zorgen als de gegevens uit oudere bronnen afkomstig zijn. Problemen hiermee moeten opgelost worden voordat men aan de volgende stappen begint.
2. Analyse en typering van de gegevens. Voor elke kolom: welke zijn de minima, maxima, de waarden die voorkomen, zijn er missende waarden, etc. Omdat de computer niet weet wat de achterliggende betekenis van de gegevens is, is het vaak nodig om in deze stap manueel correcties uit te voeren:
   • Niet alle getalwaarden kan je zomaar beschouwen als “hoeveelheden” die je vrij kan optellen of aftrekken. Sommige zijn categoriën, zoals NACE codes of postcodes, andere zijn misschien onderdeel van een datum.
   • Ontbrekende gegevens zal je in sommige gevallen kunnen gelijkstellen met 0 of met een reeds aanwezige default categorie, maar vaak wil je ze misschien beschouwen als een klasse apart. Een ontbrekende geboortedatum wilt immers niet zeggen dat iemand geboren is in het jaar 0.
3. Transformatie van gegevens. Hierbij worden o.a. ontbrekende gegevens afgesplitst, of categorische variabelen omgezet in een getal-encodering om compacter voorgesteld te worden. Deze stap gebeurt vooral achter de schermen, maar het is vaak mogelijk om manueel configuratie-opties toe te voegen: van sommige kolommen willen we bijvoorbeeld forceren dat de waarden altijd uniek zijn, andere kolommen willen we misschien negeren.
4. Een generatief model trainen. Dit kunnen zowel “klassieke” statistische modellen zijn als deep-learning varianten. Sommige modellen zijn enigszins in staat om diepere verbanden tussen de gegevens te reproduceren, maar dit blijft erg afhankelijk van de hoeveelheid gegevens en hun distributie.
5. Genereren van nieuwe gegevens. Bij gebruik van een generatief model staat er in principe geen limiet op de hoeveelheid gegevens die aangemaakt kan worden.
6. Evalueren en visualiseren van de resultaten. De meeste commerciële tools genereren een mooi eindrapport met daarin een verslag van het hele proces en enkele samenvattende grafieken die toelaten om in een oogopslag te zien of er anomalieën zijn, en of er nog andere correcties toegevoegd dienen te worden. Bij open-source tools is dat vaak beperkt tot enkele metrieken en moet je verdere gegevensanalyse zelf bijprogrammeren.

Gegevens

Wie de tools liefst niet uittest op eigen (gevoelige) data, vindt veel datasets op Kaggle. Zelf maakten we voor onze testen onder andere gebruik van een variant op de Adult Census Income dataset.

Praktische bekommernissen

Telgegevens

Sommige datasets bevatten tellingen. Dat kan het resultaat zijn van een COUNT() functie in de SQL-query voor data-extractie. Om dan een correcte inschatting te kunnen maken van de distributies van de andere variabelen, is het nodig om deze telling ongedaan te maken en de tabel te “unrollen”. Een nieuw gegenereerde tabel moet nadien natuurlijk terug “opgeteld” worden om terug in het originele formaat te staan. Op deze manier kan men desgewenst ook garanderen dat de resulterende tabel ook effectief hetzelfde aantal records voorstelt als in de originele database, zelfs al is er een ander aantal combinaties van variabelen. De kolom met de telvariabele wordt uiteraard niet meegenomen in het generatief model.

Behoud van alle mogelijkheden

Voor sommige toepassingen kan het nodig zijn dat een gesynthetiseerde dataset zeker ook alle mogelijke waarden bevat die voorkomen in de originele dataset – bij wijze van representativiteit voor de originele dataset. Maar met name als bepaalde waarden erg zeldzaam zijn, bestaat er een reëel risico dat ze niet genoeg doorwegen bij de training van het generatief model, waardoor ze achteraf bijna nooit gegenereerd worden. De meeste generatieve modellen laten het conditioneel samplen van gegevens toe: datapunten kunnen gegenereerd worden waarvoor de waarde van een of meerdere variabelen vaststaan. De distributie van de andere waarden volgt dan een conditionele distributie, gegeven deze vaste waarden. Doe dat voor elke waarde die voorkomt in de originele dataset, en men kan garanderen dat elke waarde (alleszins onafhankelijk) voorkomt. Dit vraagt weliswaar wat extra programmeerwerk om gedaan te krijgen, en bovendien impliceert dit ook dat een outputdataset een bepaalde minimumgrootte zal hebben.

Duplicaten en overlap

Het genereren van nieuwe gegevens gebeurt door te samplen uit een generatief model – te vergelijken met het trekken van een lottocombinatie. Zeker als er veel gegevens worden gesynthetiseerd, is het altijd mogelijk dat er twee keer hetzelfde tussenzit. Is dat ongewenst, dan moet een optie toegevoegd worden om duplicaten te verwijderen – en nadien opnieuw gegevens bij te genereren totdat de gewenste grootte opnieuw is bereikt. Eventueel kan men ook forceren dat gesynthetiseerde gegevens zeker niet mogen voorkomen in de originele dataset – dat de twee datasets dus volledig disjunct zijn. Dat laatste voegt echter weinig toe qua privacybescherming: zonder kennis van de originele dataset, kan men steeds bogen op een zekere plausible deniability dat een synthetisch record identiek zou zijn aan een record uit de echte dataset.

Trainingstijd

Zeker bij grote datasets met veel variabelen, en bij gebruik van deep learning tools kan het een lange tijd in beslag nemen om een generatief model te trainen. Dat maakt het moeilijk om iteratief te werk te gaan bij het verfijnen van de opties. Het kan nuttig zijn om tijdens de ontwikkeling, de dataset ten grondslag van de training te beperken tot enkele duizenden willekeurig geselecteerde records. Daarbij mogen we al wat hierboven al werd vermeld natuurlijk niet uit het oog verliezen – bijvoorbeeld, ook hier kan het nuttig zijn om een extra optie te hebben die garandeert dat een selectie uit de trainingset nog steeds minstens 1 datapunt bevat voor elke waarde van elke variabele.

Afhankelijke kolommen

Een kolom die volledig (lineair) afhankelijk is van een of meerdere andere kolommen, moeten we verwijderen en achteraf terug herberekenen. Dat is typisch het geval bij wiskundige afhankelijkheden: een kolom die een som is van twee andere kolommen, of een percentage van een andere kolom voorstelt. We kunnen best niet hopen dat een generatief model dat verband zelf aanleert. Het is veel zekerder om zulke afhankelijke kolommen gewoon te verwijderen uit de dataset, en nadat een nieuwe dataset is gegenereerd, deze kolommen terug te berekenen op basis van de gesynthetiseerde data en dan pas toe te voegen.

Constraints

Iemands geboortedatum valt altijd vroeger dan iemands sterfdatum. Dat is logisch, maar als men voor een fictief persoon een nieuwe geboortedatum en sterfdatum genereert uit het generatief model dat werd getraind op de distributies van alle geboorte- en sterfdata in een dataset, dan kan het voorvallen dat deze logische beperking niet altijd gerespecteerd blijft. Het kunnen opleggen van constraints – de ene variabele is altijd groter of kleiner dan een andere, of altijd positief of negatief, etc. – is een belangrijke feature. Eenvoudige beperkingen, zoals zonet aangehaald, zijn eventueel nog eenvoudig te implementeren door “rejection sampling”: voldoet een gesynthetiseerd record niet aan alle constraints, wordt het gedeleted en wordt een nieuw gegenereerd, totdat alle records voldoen. Worden de constraints ingewikkelder of strikter, dan kan het nodig zijn om zelf de nodige filters te programmeren, of om een post-processing stap te definiëren waarin correcties uitgevoerd kunnen worden.

Kolommen bevriezen

Willen we een dataset scramblen met een kolom geslacht en een kolom woonplaats, dan is het eigenlijk voldoende om enkel de kolom met woonplaatsen door elkaar te husselen om een goed gemengde dataset te bekomen. Het geslacht is daar onafhankelijk van, en kunnen we even goed negeren. Het bevriezen van kolommen, in feite gewoon het verwijderen voor de verwerking en terug eraan plakken na het einde, kan zo een grote tijdswinst opleveren. Het is weeral een kolom minder waarvan de distributie aangeleerd moet worden. 

Kolommen bevriezen, impliceert weliswaar een voorwaarde: ofwel dat de gesynthetiseerde dataset even lang moet zijn als de originele zodat de dimensies overeenkomen, ofwel dat de gegevens in de bevroren kolom(men) helemaal willekeurig verdeeld zijn, dus op geen enkele manier gesorteerd of gegroepeerd, zodat de bevroren kolom(men) zonder effect op de gegevensdistributie kunnen verkort of verlengd worden. Dat laatste kan echter moeilijk te bewijzen zijn.

Maar zeker als het de bedoeling is dat een gesynthetiseerde dataset even groot is als de originele, wat toch vaak voorkomt, is het een enorm grote tijdswinst als van een dataset met 60 kolommen, er slechts 6 moeten gesynthetiseerd worden om een voldoende gescramblede dataset te krijgen. Bovendien zal een generatief model met minder kolommen meestal ook accurater getraind kunnen worden, dus is het resultaat waarschijnlijk zelfs kwalitatief beter. Eventueel kan de synthetische dataset achteraf nog eens geshuffled worden om enige overgebleven structurele gelijkenis met de originele dataset te verbergen. 

Rapportering en grafieken

De gescramblede dataset moet nog vergeleken worden met het origineel, om te verifiëren dat de procedure wel goed verlopen is en of er bepaalde parameters beter aangepast zouden kunnen worden. Het visualiseren van datasets is een uitdaging op zich, waarbij rekening moet worden gehouden met het type van variabele en de waarden die ze kan aannemen. Boxplots zijn vaak een goede keuze voor continue variabelen, en staafdiagrammen voor categorische variabelen. Daarbij moet aandacht worden besteed aan de assen, die overeen moeten komen om in een oogopslag te kunnen vergelijken. Het kan nodig zijn hier en daar extra te groeperen of aggregeren om grafieken van complexe categorische variabelen overzichtelijk te houden. Voor de verbanden tussen twee variabelen kan men verschillende vormen van bivariate plots, heatmaps en correlatiematrices benutten. Werkt men in Python dan zijn matplotlib en seaborn nuttige grafische libraries.

Conclusie

Met synthetische data generatoren hebben we een krachtige tool in handen om data scrambling te kunnen doen. We kunnen er bovendien meer mee dan enkel de gegevens door elkaar haspelen: desgewenst interpoleren ze ook tussen minimum- en maximumwaarden, of tussen datums, en zo kunnen ze ook fictieve gegevens genereren volgens dezelfde structuur als de originele dataset. Het aanmaken van een echt goede synthetische dataset vergt vaak een iteratieve aanpak, om het achterliggend generatief model te finetunen.

We merken in de praktijk dat er heel wat extra checks en balances komen kijken bij het werken met echte datasets. Het is zelden zo dat een generatief model gegenereerd uit een willekeurige dataset met default parameters, vanaf de eerste keer optimaal is. Met name erg ongelijke distributies zorgen voor problemen in het leerproces en voor statistische instabiliteit in het resulterende generatief model. Bij wijze van voorbeeld: als een dataset slechts 1 persoon bevat met een zeldzame ziekte, en het is toevallig een 43-jarige Limburger, dan riskeren we dat het systeem leert dat alle personen met deze ziekte per definitie 43-jarige Limburgers moeten zijn. Bovendien merken we dat we de beste resultaten bekomen als een dataset weinig variabelen heeft, en voor elke waarde van elke variabele veel datapunten (rijen, samples). Dit alles maakt dat we de beste resultaten vaak bekomen door zoveel mogelijk kolommen te bevriezen, en het aantal te scramblen kolommen te beperken tot het minimum noodzakelijke om het doel van scrambling te bereiken. Die oefening kan voor elke dataset anders zijn.

Een vraag die regelmatig terugkomt is: kunnen we dezelfde analytics op de dusdanig gescramblede / gesynthetiseerde dataset loslaten en leidt dat dan tot dezelfde conclusies? Het antwoord is: het hangt ervan af hoe diep je wilt gaan. De structuur van de gegevens wordt in het generatief model immers approximatief aangeleerd. Daarbij merken we:

• De statistieken en verdeling van individuele variabelen (minimum, maximum, gemiddelde etc.) blijven meestal relatief goed behouden,
• De verbanden tussen twee variabelen (correlatie etc.) blijven matig behouden, en hoe gelijkmatiger en stabieler deze variabelen zijn verdeeld hoe beter dat dat lukt,
• De verbanden tussen meerdere variabelen (regressies etc.) blijven relatief slecht behouden of gaan verloren.

Voor complexe analyses zijn scrambled of synthetische data dus zeker geen drop-in replacement voor de echte data. Ze zijn wel erg nuttig voor het testen of ontwikkelen van data processing scripts of analyse-pipelines, omdat we wel een goed beeld hebben van welke waarden er allemaal voorkomen en in welk bereik deze vallen.

We hebben nog heel wat andere potentiële struikelblokken die we in de praktijk kunnen tegenkomen niet besproken. Er kunnen afhankelijkheden bestaan tussen rijen – bijvoorbeeld, een tabel die verschillende records bevat per persoon. Er kunnen ook verbanden zijn in de tijd – bijvoorbeeld datasets die bestaan uit opeenvolgende kwartalen, of datasets waarin de datums die voorkomen alleen maar werkdagen zijn en nooit weekenddagen, wat maakt dat je niet zomaar eender welke datum kan synthetiseren. Een dataset kan ook bestaan uit meerdere tabellen die met elkaar verbonden zijn. Zulke complexere problemen zijn mogelijk nog voer voor een vervolg-artikel later dit jaar.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Automatisering is een belangrijk wapen om het Mattheus-effect tegen te gaan. Het automatisch toekennen van bepaalde voordelen aan de hand van objectieve criteria zorgt idealiter voor een gelijke behandeling van alle burgers ongeacht stand en rang. Daarnaast zorgt automatisering ook voor tijdswinst, minder papier, en lagere kosten op lange termijn. Veel projecten waar Smals bij betrokken is, dragen daar aanzienlijk toe bij: ze besparen de overheid, burgers en bedrijven jaarlijks miljarden euro’s, om niet te zeggen tonnen papier, inkt en postzegels.

We schreven al uitvoerig over de talloze randvoorwaarden die opduiken als men Artificiële Intelligentie correct wil inzetten ([1], [2], [3], [4], [5], [6]), maar ook een gewone procesautomatisering, zelfs digitalisering, is niet zomaar vrijblijvend, en al zeker niet bij overheden. Automatisering is niet gelijk aan artificiële intelligentie, maar men geeft nog steeds een deel van de controle uit handen aan een machine. Naast winsten in snelheid en kostprijs, kan dat ook allerlei beperkingen introduceren. Door de schaalvergroting loopt het, als het fout loopt, ook ineens heel erg fout. Reden genoeg om reeds vanaf de planningsfase nauwgezet aandacht te besteden aan de bredere effecten van een automatiseringsproject.

Wil een geautomatiseerd proces goed werken, dan is het belangrijk dat het actief en “als een goede huisvader” wordt beheerd. Permanente monitoring is nodig zodat problemen snel gedetecteerd en opgelost kunnen worden. Manueel ingrijpen moet mogelijk blijven, het moet duidelijk zijn wie waarvoor verantwoordelijk is, en alles moet mee evolueren wanneer nodig. In het Engels wordt dat al eens aangeduid met (corporate) “governance“, vrij vertaald “deugdelijk bestuur”. Het is een vaag begrip, maar in dit artikel hoop ik het belang ervan te kunnen illustreren aan de hand van enkele spraakmakende voorbeelden uit het buitenland.

(afbeelding: “corporate governance”, (c) Asmi-corporatereporting.com, 2017, Licensed CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons)

Wat kan er zoal misgaan?

Frankrijk

De Franse Caisse des Allocations Familiale (CAF) nam in 2021 een nieuw systeem in gebruik voor de berekening van huisvestingstoelagen. Helaas was het systeem niet volledig compatibel met een ander systeem voor de registratie van sommige arbeidsprestaties, nodig om de hoogte van die uitkering te bepalen. Als gevolg kregen minstens 120.000 mensen een foutieve schuldvordering in de bus, automatisch aangemaakt, voor zogezegd teveel ontvangen uitkeringen. De toevloed aan reacties, en alle correcties die vaak manueel aangebracht moesten worden, zorgden voor veel extra werklast bij de dienst die al met veel vertragingen te kampen had, wat op zijn beurt aanleiding gaf tot stakingen. Negen maanden later wachtten nog steeds 32.000 mensen op de correctie van hun dossier.

Verenigd Koninkrijk

Het Verenigd Koninkrijk heeft geen rijksregister zoals België. Mensen moeten hun identiteit op een andere manier bewijzen: met een rijbewijs, bankrekening, telefooncontract of een internationaal paspoort. Dat zorgt al voor een eerste probleem, omdat net de meest kwetsbaren die het meeste belang hebben bij die diensten, door hun kleinere administratieve/digitale voetafdruk niet geauthenticeerd geraken. Daarnaast is identiteitsfraude een groot probleem.

Universal Credit is een geautomatiseerd sociaal vangnet voor de laagste inkomens, dat bestaat uit de fusie van 6 aparte uitkeringen. Hun doel om de zaken te vereenvoudigen hebben ze echter ook doorgetrokken in de berekeningswijze: die neemt enkel het inkomen van een vorige maand in rekening. Dat zorgt voor grote problemen bij mensen die onregelmatig betaald krijgen, of wanneer loon plots vervroegd uitbetaald wordt omwille van feestdagen: zij hebben in sommige maanden plots een hoger inkomen, in andere maanden geen, en krijgen daardoor heel erg fluctuerende uitkeringen. Het perverse effect daarvan is dat twee mensen met dezelfde job, gezinssamenstelling en jaarinkomen, toch verschillende uitkeringen kunnen krijgen, enkel en alleen omdat hun salaris op een ander moment wordt uitbetaald.

Een rechtszaak daarover werd door de Britse overheid verloren. Het maken van de opgedragen aanpassingen zal de kost van het geplaagde systeem, nu reeds lopend in de miljarden pond, alleen nog maar verder doen toenemen. Let wel dat het probleem hier niet zozeer bij de automatisering ligt, wel bij het ontwerp: de regering had expliciet besloten tot deze berekeningswijze, omdat ze gemakkelijker en efficiënter te implementeren was.

(afbeelding: Wordmark for Universal Credit, (c) UK Government, licensed under the Open Government Licence version 1.0 (OGL v1.0).

Australië

In Australië deed de RoboDebt affaire veel stof opwaaien. Frauduleus betaalde uitkeringen terugvorderen deden ze al langer, maar in 2015 maakten ze een cruciale verandering: het verifiëren van een “match” tussen de databanken sociale zekerheid (DHS) en financiën (ATO), werd geautomatiseerd. Dat nam effectief een stap van menselijke controle in de ketting weg. Het hoofddoel was om elke “match” op te volgen, daar waar ze vroeger slechts de meest flagrante inbreuken konden najagen omwille van het manuele werk. Dat leidde in het eerste jaar al tot een 40 keer hoger volume.

Helaas was niet elke “match” ook terecht. De uitkeringen werden immers in perioden van 14 dagen toegekend, terwijl de belastingdienst gegevens had per fiscaal jaar. Bij gebrek aan inkomstengegevens per 14 dagen werd een gemiddelde van het jaarinkomen toegepast, maar net zoals in het voorbeeld van UK, leidde dat tot ongewenste neveneffecten, en moesten burgers plots schulden gaan terugbetalen die ze nooit gemaakt hadden. In 2019 werd het systeem door de rechtbank onwettelijk verklaard, en in 2021 moest de overheid een schikking ter waarde van $1.8 miljard Australische dollar treffen met de bijna 500.000 gedupeerden. Ook hier lag de fout bij de wetgever, die niet voldoende had nagedacht over de aannames en mogelijke neveneffecten bij het opstellen van de berekeningswijze van het systeem.

USA

In de Verenigde Staten doken problemen op bij de automatisering van RAI. Dit Resident Assessment Instrument is een lange vragenlijst voor zwaar zorgbehoevenden. Aan de hand van het resultaat wordt o.a. berekend op hoeveel thuiszorg iemand een beroep mag doen. Ook in België wordt een variant ervan gebruikt die BelRAI heet. Het automatiseren daarvan moet heel omzichtig gebeuren. Als bijvoorbeeld de vraag of iemand voetproblemen heeft beantwoord wordt met “nee”, kan dat zijn omdat die gezond is, maar even goed omdat die geamputeerde voeten heeft – en die laatste behoeft uiteraard meer zorg.

In Arkansas liep het fout bij onderaannemers die een verkeerde versie van de vragenlijst hadden gebruikt, en daarnaast bepaalde ziektebeelden, zoals hersenverlamming, niet correct hadden verwerkt. Pas tijdens de rechtszaak werd duidelijk waar de fouten precies lagen, o.a. doordat de rechter verplichtte om de resultaten eens manueel na te rekenen. Het systeem bleek dermate complex, en de code werd zodanig afgeschermd, dat ook de bevoegde ambtenaren niet in staat waren geweest om de fout te ontdekken. Zo was het voor eindgebruikers nooit duidelijk waarom de evaluatie tot een bepaald resultaat leidde, wat het op zijn beurt erg moeilijk maakte een evaluatie aan te vechten of te overreden. Het gebruik van RAI op zich werd door de rechtbank wel als wettig beschouwd.

India

India heeft hetzelfde probleem als het Verenigd Koninkrijk, nl. dat het lange tijd geen eengemaakt burgerregister had en dat andere systemen (rijbewijzen, stembiljetten, geboorteaktes) onderling incompatibel zijn. Het bijhouden van gegevens op kaartjes en papieren is er ook geen sinecure voor de armeren en ongeletterden onder hun bevolking. In een ambitieus programma om iedere Indiër een sociaal identiteitsnummer te geven (zoals onze vroegere SIS-kaart), startte India het Aadhaar project, dat ook biometrische authenticatie op basis van de vingerafdruk omvat.

(afbeelding: “A sample of Aadhaar card”, by Pagelmp, licensed under the Creative Commons Attribution-Share Alike 4.0 International license. Source Wikimedia Commons.)

De praktijk blijkt echter weerbarstiger. Er zijn technologische vereisten om het te kunnen toepassen: een vingerafdruklezer en een stabiele internetverbinding. Bovendien zijn de vingerafdrukken niet altijd meer herkenbaar bij wie een leven lang handenarbeid heeft verricht. Ook fouten bij de manuele data-entry, wat tijd en geld kost om te laten corrigeren, zorgen voor problemen. Er duiken dan ook veel rapporten op van grote aantallen kwetsbaren die de toegang tot sociale diensten, onderwijs, vergunningen, kindergeld of voedselrantsoenen wordt ontzegd omdat ze door de mazen van het Aadhaar-systeem vallen.

Nederland

In Nederland viel de regering over de toeslagenaffaire. Vele duizenden gezinnen kwamen in grote problemen door onterechte beschuldigingen van subsidiefraude. De affaire is complex, maar aan de basis ligt de opsporingsdienst voor belastingfraude die zich danig heeft vergaloppeerd. Het probleem lag hier o.a. bij een gebrekkige training en validatie van een machine-learning model, dat een risicoclassificatie moest geven aan dossiers en daarbij zonder veel nadenken steunde op parameters zoals nationaliteit, die erg gevoelig zijn voor discriminatie. Daarnaast was de inhoud van verschillende onderliggende databanken, o.a. de Fraude Signalerings Voorziening, onoordeelkundig verzameld: een telefoontje naar de belastingdienst kon voldoende zijn om erin opgenomen te zijn als potentieel fraudeur. De opsporingsdienst vertrouwde echter quasi blindelings op de gegevens en risicoscores, en gebruikte ze als rechtvaardiging om drastisch te werk te gaan bij terugvorderingen, weigeringen van afbetalingsplannen, enz. Daarbij ontbrak het aan een richtinggevend kader van bovenaf, interne monitoring of audit, en mogelijkheden tot aantekenen van beroep. De databank werd op basis van inbreuken op de privacywetgeving stopgezet en de belastingdienst kreeg een stevige boete.

Conclusie

De bovenstaande verhalen hebben meestal 1 ding gemeen: alles gaat goed totdat op een bepaald moment ergens een bocht teveel wordt afgesneden zonder dat er tijdig wordt ingegrepen. Dat moet ons niet tegenhouden om te automatiseren, want er zijn ook duidelijke voordelen: voor de overheid qua schaalbaarheid, voor de burger o.a. door vermindering van administratie. Met dit artikel willen we vooral aandacht vestigen op de noodzaak om daarbij voldoende te investeren in planning en opvolging, om een goede grip te houden. Dat omvat ook een realistische blik, aandacht voor user experience en duidelijke adoptie van waarden en principes (transparantie, accountability, …).

Het grote verschil tussen een ambtenaar in persoon en een geautomatiseerd systeem, is dat een ambtenaar aanpassingen kan maken en verfijningen kan toebrengen nog voordat een beslissing genomen wordt, terwijl een algoritme enkel maar gecorrigeerd kan worden nadat het al een beslissing heeft gemaakt. Dat laatste veroorzaakt frustratie en een nood aan ingrijpen achteraf. Er is een risico dat bepaalde doelgroepen onevenredig het slachtoffer zijn van zulke fouten. Ook kan bij de gebruikers van geautomatiseerde systemen, een zekere verblinding, laksheid, of neiging tot het afschuiven van verantwoordelijkheid ontstaan: “de computer zegt het dus het zal wel zo zijn”. Er moeten dus toegankelijke procedures zijn om beroep aan te tekenen tegen een beslissing en correcties moeten eenvoudig doorgevoerd kunnen worden.

Daarnaast blijft het altijd mogelijk dat programmeurs de regels onvolledig of foutief inbrengen in een programma, of dat ze andere interpretaties en aannames hanteren dan de regelgevers. Er is dus nood aan een zekere waakzaamheid, transparantie en inspraak in het hele implementatieproces, zeg maar “project governance“. Ook de uitvoerende ambtenaren moeten blijven begrijpen wat er gebeurt en waarom. Daarbij hoort ook een goede methode om feedback te verwerken die vanop de werkvloer aangebracht wordt.

Er bestaat vooralsnog geen vaste manier om compliance of governance ontegensprekelijk te garanderen. Het zijn nog steeds vage begrippen, en ook nogal wat wetgeving blijft vaag: zo staat het woord “redelijk” maar liefst 38 keer in de GDPR, en het woord “passend” zelfs 125 keer, zonder verdere specificatie van wat we daar nu concreet onder moeten verstaan. In de VS worden basisregels voor bedrijfsbeheer opgelegd door de Sarbanes-Oxley Act. In België bestaan er de Code Lippens voor beursgenoteerde, en Code Buysse voor niet-beursgenoteerde ondernemingen. Ondertussen wordt in Europa verder gewerkt aan o.a. een Data Governance Act om een kader te scheppen voor verantwoord (her)gebruik van gegevens.

Deze en andere regulatorische raamwerken zijn misschien niet perfect sluitend. Ze adopteren, eventueel certifiëren, en regelmatig eraan toetsen, zorgt op korte termijn wel voor extra overhead en kosten, maar het legt de lat ook hoger en kan zo op lange termijn veel zorgen voorkomen. Het is ook meestal goede reclame. Uit alle aangehaalde voorbeelden blijkt natuurlijk ook dat daarvoor de nodige wil moet bestaan bij, en middelen ter beschikking gesteld moeten worden door, de bevoegde beleidsmakers.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Men zou bijvoorbeeld inzichten kunnen afleiden uit gegevens van overheden. Het is nuttig om dit proces uit te voeren op een computer want we zouden liever niet manueel grote hoeveelheden gegevens lezen om de interessante patronen en verbanden af te leiden. Bovendien valt een inzicht misschien pas op als de gegevens worden gelezen in de goede volgorde, bijvoorbeeld door een aantal stukjes informatie te lezen vlak na elkaar die allemaal eenzelfde interessante patroon bevatten. Men weet typisch niet op voorhand welke patronen aanwezig zijn, dus kan men de gegevens niet sorteren om de patronen er manueel uit te halen. Het vinden van patronen laten we daarom best door een computer gebeuren, die vele mogelijkheden kan overwegen.

In deze blog bespreken we een algemeen idee gebaseerd op principes uit Data Mining. We bespreken concreet het principe van regels. Een regel van de vorm A → B drukt de voorspelling uit dat patroon B voorkomt als patroon A wordt waargenomen. We lezen de regel dus als volgt: “als A dan B”. Dergelijke voorspellingen kunnen gebruikt worden om suggesties te doen, om anomalieën te detecteren, en om automatisch beslissingen te nemen.

We vertrekken vanuit de observatie dat veel gegevens van een overheid in gestructureerde vorm worden opgeslagen. Voorbeelden van dergelijke gegevens zijn:

• de data waarop de identiteitskaart van een persoon is uitgegeven,
• de voorgaande en huidige domicilieadressen van elke burger,
• de hoeveelheid belasting die elke burger heeft betaald per jaar,
• de bijdragen aan de sociale zekerheid die elke werkgever heeft betaald per kwartaal.

Gestructureerde gegevens staan in contrast met vrije tekst, afbeeldingen, video’s, geluid, enz.

Patronen en regels

In het vervolg nemen we voor de eenvoud aan dat elke gestructureerde gegevensbron conceptueel bestaat uit een verzameling van entiteiten, zoals mensen, gebouwen, bedrijven, enz. We bekijken elke entiteit als een verzameling van attributen, waarbij elk attribuut een key-value paar is.

We definiëren een patroon als een combinatie van constraints op individuele attributen. De “support” van een patroon X is het aantal voorkomens (of de relatieve frequentie) van X over alle entiteiten heen. Ter illustratie beschouwen we de volgende tabel:

Elke rij stelt een entiteit voor, in dit geval een persoon. Voorbeelden van patronen zijn:

• Straat = “Straat A”;
• Leeftijd > 35;
• Leeftijd > 35 en Gebied_code = 3000.

De support van deze patronen zijn, respectievelijk: 1 rij, 3 rijen, en 2 rijen.

Als we vanuit de gestructureerde gegevens zouden kunnen leren welke patronen vaak samengaan, kunnen we het ene patroon voorspellen na de observatie van een ander patroon. In het bijzonder zouden we regels kunnen leren van de vorm A → B, waar A en B patronen zijn. Deze regel zegt dat als we patroon A zien dat we dan patroon B verwachten. Bij elke regel hoort een betrouwbaarheidsscore, gedefinieerd als volgt:

De betrouwbaarheid van A → B is de support van het gecombineerde patroon A + B gedeeld door de support van patroon A.

Merk op dat het gecombineerde patroon A + B typisch strenger is dan patroon A, en daardoor enkel kan aanwezig zijn in de entiteiten die reeds voldoen aan patroon A. Daardoor is de support van A + B kleiner of gelijk aan de support van A. Intuïtief bekeken, drukt de betrouwbaarheid uit hoe zeker we zijn om patroon B te voorspellen als we patroon A waarnemen.

In het bovenstaande voorbeeld, zouden we de volgende regels kunnen afleiden uit de gegevens:

• Met 2/2 betrouwbaarheid (100%), als Straat= “Straat B” en Gebied_code = 3000 dan (→) Taal = “Frans”;
• Met 2/3 betrouwbaarheid (66%), als Gebied_code = 3000 dan (→) Taal = “Frans”.

Met regels zouden we de volgende toepassingen kunnen uitwerken:

• Men kan waarden voor een attribuut suggereren op basis van andere attributen. Dit zou men decision support kunnen noemen.
• Wanneer een entiteit wordt aangemaakt (of gewijzigd), kan men controleren dat bepaalde verwachtingen rond de attributen voldaan zijn. Anders gezegd: men kan verwachtingen gebruiken als beperkingen. Schendingen van verwachtingen kunnen gemeld worden als anomalieën.

Beide mechanismen zijn gebaseerd op voorspellingen, zoals we hieronder zullen toelichten. Met kennis van de regel A → B kunnen we suggereren dat patroon B kan toegepast worden nadat patroon A wordt waargenomen. Als een beheerder verantwoordelijk blijft voor de uiteindelijke beslissing, dan bekijken we regels enkel als een suggestie-mechanisme. In de context van anomalie-detectie kunnen we een melding sturen naar de beheerder wanneer een voorspelling wordt geschonden bij een entiteit. Ter illustratie:

• Stel dat de bovenstaande voorbeeld-gegevens van personen uit een enquête zouden komen, en dat mensen soms vergeten hun taal in te vullen. In dat geval zouden we kunnen overwegen om een suggestie-mechanisme aan te bieden dat de taal afleidt uit de straat en de gebiedscode. Natuurlijk hangt het af van de toepassing of de voorgestelde waarden aanvaardbare plaatsvervangers zijn, of dat meer echte gegevens moeten verzameld worden.
• Als een voorbeeld van anomalie-detectie, stel dat we proberen om de volgende entiteit toe te voegen aan de tabel: Staat= “Straat B”, Gebied_code = “3000”, en Taal = “Nederlands”. De eerste regel hierboven zou dan geschonden zijn. Als de betrouwbaarheid van een geschonden regel hoog is, zoals hier (100%), dan zou het nuttig kunnen zijn om de anomalie te melden aan een beheerder. Afhankelijk van de toepassing, zou anomalie-detectie kunnen helpen bij het vinden van administratieve fouten of problemen met entiteiten.

Als een regel voldoende wordt vertrouwd, en de patronen erin voldoende concreet zijn, dan kan de regel ook automatisch worden uitgevoerd om gegevens aan te vullen of te veranderen. Daarom zouden regels een manier kunnen zijn om automatisering te bekomen.

Toepasbaarheid

Men zou regels kunnen leren uit verschillende vormen van gestructureerde gegevens zoals:

1. Standaard tabellen zoals in het bovenstaande voorbeeld.
2. XML of JSON gegevens wanneer de diepte van deze structureren op voorhand begrensd is.
3. Doorlopende “streams” waar gestructureerde formaten worden gebruikt om individuele boodschappen voor te stellen. Het leren van regels over streams kan real-time aanvulling van gegevens of anomalie-detectie mogelijk maken.

Nuttige eigenschappen

We bespreken enkele nuttige eigenschappen van het automatisch afleiden van regels:

Aanvullende opmerkingen

Verwante onderzoeksgebieden

We geven enkele wetenschappelijke onderzoeksgebieden verwant aan het thema in deze blog (Engelstalige terminologie):

• association rule mining,
• inductive logic programming,
• knowledge representation and reasoning.

Slim gokken

In het algemeen zijn er teveel mogelijke patronen en regels om systematisch op te sommen of op te slaan. Maar men kan patronen en regels proberen slim te gokken. Het is in principe ook mogelijk om variaties van bestaande regels te verkennen, ten einde

• meer algemene regels te vinden;
• of om regels met lage betrouwbaarheid om te vormen naar regels met hogere betrouwbaarheid, bijvoorbeeld door een meer specifiek patroon te gebruiken in de preconditie.

Trade-off: betrouwbaarheid en support

Er zit een trade-off tussen betrouwbaarheid en support. Regels gebaseerd op gedetailleerde patronen zouden heel betrouwbaar kunnen zijn, maar helaas met een te kleine support om statistisch significant te zijn. Een kleine support duidt immers op zeldzaamheid van het patroon. Daarom zou men aandacht kunnen besteden aan representaties van patronen die zorgen voor een grotere support. Hulpmiddelen daarvoor zijn:

• beperkingen op getal-attributen kan men weergeven met intervallen (en niet met concrete waarden);
• gebruik maken van de NOT operator (“niet”), om te zeggen dat een attribuut niet een bepaalde waarde heeft;
• gebruik maken van de OR-operator om meerdere specifieke patronen te bundelen.

Bijvoorbeeld, door te zeggen NOT Straat = “Straat Z”, laten we toe dat het straat-attribuut zeer veel waarden kan aannemen, zolang het maar niet “Straat Z” is, zoals: “Straat A”, “Straat B”, “Straat C”, en tal van andere mogelijke waarden. De support van het patroon NOT Straat = “Straat Z” kan daarom heel hoog zijn in een concrete tabel.

We geven nu een voorbeeld van het gebruik van de OR-operator. Beschouw het volgende patroon, waarbij we voor de leesbaarheid telkens een komma schrijven om “and” voor te stellen:

P= (a OR b), (u OR v), (x OR y).

Patroon P vervangt de volgende verzameling van specifieke patronen waarin enkel de  AND-operator wordt gebruikt (ook weer vervangen door komma):

• a, u, x
• a, u, y
• a, v, x,
• a, v, y,
• b, u, x,
• b, u, y
• b, v, x,
• b, v, y.

De support van P kan veel hoger zijn dan de support van de individuele AND-patronen. Dit voorbeeld illustreert bovendien dat een representatie met een geneste OR-operator efficiënter kan zijn voor de opslag van de patronen en regels.

Aan de ene kant laten computerprogramma’s, meer bepaald datamining-algoritmes, toe om te leren uit vaststellingen gemaakt in het verleden, en kunnen zij op wetenschappelijk verantwoorde wijze aanleiding geven tot proactieve risicobepaling. De gebruikers dienen wel te beseffen dat het gaat om risico’s, en geen bewijzen. Controle ten gronde, of zelfs ter plaatse, is nodig. Maar datamining kan dus duidelijk bijdragen tot het efficiënter en doelgerichter werken van de overheid.
Bovendien kan automatisatie inderdaad willekeur en voorkeursbehandeling tegengaan, als daar sprake van zou zijn. Zo stelt ook de fiscus, volgens het artikel: “Sinds enkele jaren gebruikt de fiscus een computersysteem om te bepalen wie een controleur op bezoek krijgt. Op die manier wil de overheid willekeur en voorkeursbehandelingen vermijden.”
De tegenstanders, vaak inspecteurs en controleurs zèlf (maar lang niet allemaal), kunnen argumenteren dat de digitale selectie op basis van risicoprofielen net voor een ongelijke behandeling zorgt. Moeten we daar dan uit besluiten dat gelijke behandeling alleen kan mits controledoelen volledig random geselecteerd worden?

Een moderne overheid, die met minder middelen meer resultaat wil, zal niet iedereen kunnen controleren. Het is ook niet haalbaar, dat iedereen om de zoveel jaar gecontroleerd zou worden. Met het huidig effectief, zouden er immers teveel jaren tussen liggen. Maar controles ten gronde zijn nodig, omdat op basis van aangiftes en andere beschikbare digitale gegevens alleen, de juistheid en waarheid van aangegeven data niet kan bepaald worden (cfr. BOYDENS I., “Strategic Issues Relating to Data Quality for E-government: Learning from an Approach Adopted in Belgium”. In ASSAR S., BOUGHZALA I. et BOYDENS I., éds., “Practical Studies in E-Government : Best Practices from Around the World”, New York, Springer, 2011, p. 116 e.v.).

Gegeven dat selectie dus nodig is – is ieder selectieprincipe, dat niet volledig random (en dus blind) is, dan ongelijk en oneerlijk?

Ongelijk misschien wel, maar is dat oneerlijk?

Belastingplichtigen (individuen èn organisaties) gedragen zich niet gelijk – misschien is een daarop gerichte, wetenschappelijk verantwoorde (ongelijke, zo u wil) selectie dan wel eerlijk? Zolang de behandeling en afhandeling van de gecontroleerde op gelijke (en eerbare) wijze gebeurt, kan men toch stellen dat de overheid naar de geest een gelijke behandeling nastreeft – laat staan naar de letter.

In mijn ervaring als dataminer blijken de beste predictieve modellen steeds diegene die zich uitdrukken (dankzij bloed, zweet en tranen in doorgedreven business-analyse) in termen van gedrag (van een systeem, en waarom ook niet van een individu of organisatie). En dus niet alleen in termen van statische variabelen. Dit is een aspect dat ik als best practice wel zou willen meegeven aan iedereen die te maken heeft met selectie, en hopelijk gelijke en eerlijke behandeling nastreeft.

Tegelijk moet bij dit alles een dubbele caveat geformuleerd worden.
Ten eerste moet men ervoor zorgen dat de, overigens onbetwistbaar noodzakelijke, inspecteurs en controleurs niet tot “aapjes” of papegaaien gereduceerd worden, en dat hun terreinervaring blijvend gevaloriseerd wordt. Zowel bij de ontwikkeling van datamining-gedreven systemen als de evolutie ervan, en de ontwikkeling van feedback-systemen die vaststellingen en resultaten registeren. Telkens opnieuw blijkt dit cruciaal voor succes.
Ten tweede, en dit sluit naadloos aan bij de terreinervaring van zulke inspecteurs en controleurs (en waarom niet, ook die van andere betrokken partijen), moet men steeds, naast datamining- en andere geautomatiseerde risicogedreven criteria, tegelijk andere selecties toelaten. Enerzijds random, om minstens de mogelijkheid te verzekeren dat iedereen aan de beurt kan komen – ook degene die onder de reeds geïnstalleerde radars doorglippen. Anderzijds kan de voeling met het terrein van onschatbare waarde zijn om snel genoeg, doelgerichte controleacties uit te voeren. Mits duidelijke afspraken en geregistreerde motivatie voor zulke keuzes, moet dit kunnen.

Verder wil ik nog inpikken op de 80/20 (%) verdeling voor de controles. Zoals gezegd in het artikel worden op dit moment 80% van de controles automatisch geselecteerd op basis van datamining. Of dit een goede verdeling is, hangt af van wat men zou kunnen noemen de dekkingsgraad van de geïmplementeerde predictieve modellen en risicoprofielen t.o.v. de zich in de werkelijkheid voordoende fenomenen en scenario’s. De datamining-modellen worden gevoed met voorbeelden van een welbepaald type probleem of doel. Indien uit de vaststellingen in het kader van de 80% op datamining geïnspireerde controles blijkt dat men steeds dezelfde, beperkte set van resultaten boekt, terwijl men vroeger (of nu, in het kader van de 20% anderszins geïnspireerde controles) meer verschillende – laat staan, belangrijkere – vaststellingen en rechtzettingen optekende, dan lijdt men er duidelijk aan teveel in dezelfde vijver te vissen, en is de 80/20 regel hier aan herziening toe. Of het dan 50/50 moet zijn? Men doet er goed aan te luisteren naar het terrein, het te proberen, en vervolgens rigoureus de resultaten te registreren en te vergelijken. Meten is weten.
Opletten trouwens: de ene controle is de andere niet. Met inbegrip van de afhandeling van onderzoeken tot en met het resultaat, zijn er zwaardere dossiers en lichtere. Niets zegt dus dat de totale effort van inspecteurs en controleurs per dossier diezelfde 80/20-verdeling zal volgen. En voor de 20% anders gekozen controles, moet er ook voldoende tijd zijn om de selectie op een degelijke manier te doen.

Besluit
Het is mijn stelling dat analytisch gedreven werken, het aansturen van kernprocessen op basis van data en gekwantificeerde risico’s, niet fundamenteel verkeerd, ongelijk, of oneerlijk is. Meer nog, een moderne overheid moet zich in de huidige budgettaire omstandigheden verplicht zien om efficiënt en doelgericht te werken, en de hiertoe beschikbare, wetenschappelijk verantwoorde middelen in te zetten. Echter zonder blind te worden voor de beperkingen daarvan. Er is een gulden middenweg tussen automatisatie en voeling met het terrein.

Dat wisten we dus al – maar wat nu we een tijdje verder zijn, de eerste successen geboekt zijn? Enkele lessen kunnen getrokken worden, nu we dit aan den lijve hebben kunnen ondervinden. We geven ze hier al kort mee; elk van deze deelaspecten kan het onderwerp vormen van aparte blogs, waarin we er telkens wat meer aan besteden …

• men heeft specifieke skills nodig (business analyse, data mining, …) die verder gaan dan deze die nodig zijn voor Data Integration en Statistics;
• men moet rekening houden met evolutie in de modellen, onderliggend aan analytics, en dient dus een model management te voorzien;
• men moet een goed idee hebben van hoe (en met welk personeel) men zal afhandelen (workflow, case management, business processen, …) wat men met analytics detecteert;
• afhankelijk van de behoeften van de business (bv. (near) real-time detectie), is er misschien nood aan specifieke implementatie-architectuur (bv. Complex-event Processing, of moderne BI-architecturen, Data Virtualisatie) bij de koppeling van analytics aan de productiesystemen. Klassieke DWH-gebaseerde architecturen kunnen immers tekort schieten! Veel hangt ook af van de aanwezige Enterprise Architectuur.

Zeker en vast “to be continued”, dus … blijf ons volgen!