Generatieve AI: nuttig voor het opschonen van gegevens?

Cet article est aussi disponible en français.

Na een eerste ervaring met de analyse van een dataset met behulp van tools voor generatieve AI (GenAI), die indrukwekkende resultaten opleverde, hebben wij ons gericht op een fundamenteel aspect voor elke data-analist, met name in de sector van de administratieve data: de kwaliteit van de data. Door een rigoureuze en systematische aanpak te hanteren, hebben wij geanalyseerd hoe tools zoals ChatGPT, Gemini, Copilot, Claude of Mistral presteerden wanneer het niet langer alleen gaat om data analyseren, maar ook om deze op te schonen. Voor dit experiment hebben wij gekozen voor een type data dat wij goed kennen (1, 2): adressen in België. Er bestaan uiteraard tools die specifiek bedoeld zijn voor het opschonen van adressen, of zelfs voor geocodering. Maar het leek ons relevant om de voordelen en nadelen van deze nieuwe categorie tools te evalueren.

Net als in vorige blogposts zijn wij uitgegaan van een dataset afkomstig van de Kruispuntbank van Ondernemingen. Meer bepaald hebben wij gebruikgemaakt van een oudere dataset uit 2016, aangezien de kwaliteit van de bron inmiddels aanzienlijk is verbeterd; maar om de prestaties van een opschoonprogramma te beoordelen, is het beter om niet uit te gaan van data die al te “schoon” zijn. Een vaatwasmachine test men immers niet met reeds gewassen bestek… Deze dataset bevatte +/- 266.000 adressen, grotendeels in het Frans, van ondernemingen in het Brussels Hoofdstedelijk Gewest.

Wij hebben twee benaderingen geprobeerd:

• Bij gebruik van de chat-versies worden alle adressen in CSV-formaat verzonden, vergezeld van een prompt die wij hieronder nader zullen toelichten. Deze vraagt in hoofdzaak om ”deze adressen te standaardiseren” en om, naast een Excel-bestand met het resultaat, een Python-script te verstrekken waarmee dit kan worden gereproduceerd. In deze post beschrijven wij deze aanpak.
• Bij gebruik van de API wordt een reeks batches verzonden met adressen (in JSON), met instructies die in grote lijnen vergelijkbaar zijn met die van de eerste benadering, maar dan vereenvoudigd. Deze benadering zal in een volgende post aan bod komen.

Wij hebben ons verschillende vragen gesteld:

• Was het proces eenvoudig, of ging het gepaard met hindernissen?
• Werden de instructies nageleefd?
• Was het proces stabiel, of, met andere woorden, krijgen we hetzelfde resultaat als we hetzelfde verzoek met een tussenpoos van enkele uren herhalen?

De grootste uitdaging bij onze aanpak was het definiëren van de juiste prompt. Het uitgangspunt was om één “Markdown”-bestand aan te leveren dat alle instructies bevatte die wij toegepast wilden zien.

Het databestand bevatte een reeks kolommen voor de volgende verschillende gegevens: “straat“ (StreetFR), ”huisnummer“ (HouseNumber), “postcode“ (Zipcode), ”gemeente“ (MunicipalityFR). Veel adressen zijn echter onjuist ingevoerd. Bijvoorbeeld:

• Het huisnummer staat in het veld “straat“, aan het begin (“20 Avenue Fonsny”) of aan het einde (“Avenue Fonsny 20”)
• De namen zijn afgekort (“Av. Fonsny”, “A FONSNY”…)
• De hoofdlettergebruik is niet uniform (“Avenue Fonsny”, “AVENUE FONSNY”)
• Er bestaan meerdere varianten van dezelfde straat (“Boulevard Albert II”, “Boulevard du Roi Albert II”, “Boulevard Albert 2″…)
• Indien het huisnummer niet relevant is, bestaan er talrijke manieren om dit aan te geven: “SN” (sans numéro), “ZN” (zonder nummer), “S/N”, “?”, “*”…

Instructies

In het instructiebestand hebben wij twee opschoningsfasen gedetailleerd beschreven. De eerste bestond uit het afzonderlijk analyseren van elke regel. De tweede vereiste het vergelijken van “vergelijkbare” records onderling om varianten en typfouten te identificeren.

Fase 1: opschoning

In de eerste opschoningsfase moeten er drie nieuwe kolommen aangemaakt worden: “StreetFR_cleansed” en “HouseNumber_cleansed”, om daarin de opgeschoonde versie van de data uit “StreetFR” en “HouseNumber” op te nemen, evenals “ExtraInfo_cleansed”, om daarin de informatie op te nemen die volgens de tool noch deel uitmaakt van de straatnaam, noch van het huisnummer (bijvoorbeeld een verdieping).

Wat het huisnummer betreft, vragen wij (onder andere) het volgende:

• Het uit het veld “StreetFR” te halen indien het daar voorkomt, waarbij diverse voorbeelden worden gegeven;
• Het te standaardiseren, zodat er bijvoorbeeld niet de ene keer “10 a”, de andere keer “10A” of “10/A” staat:

Wat betreft de straatnaam vragen wij het volgende:

• De afkortingen van voorvoegsels uit te breiden, voornamelijk in het Frans: “Av.”, “Blvd”, “Chée”… ;
• Alles in “title case” te zetten, waarbij ervoor wordt gezorgd dat lidwoorden en voegwoorden in kleine letters blijven: “Rue des Chats”, “Avenue de l’Indépendance”… ;
• Ervoor te zorgen dat Romeinse cijfers in hoofdletters blijven: “Boulevard Léopold II”, “Rue Charles VI”…

Instructies voor fase 1

In this first cleansing phase, your task is to create a cleansed copy of columns StreetFR and HouseNumber, which will be named “HouseNumber_cleansed”,  “StreetFR_cleansed”. An additionnal column “ExtraInfo_cleansed” will also be created.

In “HouseNumber_cleansed”, you will:

• In case of the format “20 A FONSNY” in StreetFR (all in upper case ; one number, one space, one letter in ‘A’, ‘R’, ‘C’, ‘B’, ‘S’ or ‘P’, one space, several letters or spaces): extract the number in ‘HouseNumber_cleansed’ ; Do the following street type replacement: A=Avenue ; R=Rue ; C=Chaussée ; B=Boulevard ; S=Square ; P=Place
• Extract housenumber from “StreetFR” if needed, put in “ExtraInfo_cleansed” additionnal information which doesn’t seem to be part of the house number. Extract number only at the beginning of the string (“20 Avenue Fonsny”) or at the end (“Avenue Fonsny 20” or “Avenue Fonsny, 30”), possibly followed by one letter (“Avenue Fonsny 20 A”), or with ranges (“Avenue Fonsny 20-22” or “Avenue Fonsny 20/22”), or with a box number indication (“Avenue Fonsny 20 bus 3”, “Avenue Fonsny 20 box 3”, “Avenue Fonsny 20 bt 3”, “Avenue Fonsny 20 bte 3”, “Avenue Fonsny 20 boite 3”).
• If you have to extract a housenumber “num1” from “StreetFR” but “HouseNumber” already contains a value “num2”, keep them both in “HouseNumber_cleansed” : “num2 / num1”
• Standardise in a safe way the housenumber. For instance, “20A”, “20 A”, “20a” or “20/A” should become “20A”. But do not replace “20/22” by “2022”
• Many values represent “no number” : “SN” (Sans numéro, in French), “ZN” (Zonder nummer, in Dutch), “S/N”, ‘?’, ‘-‘, ‘/’ and many others. Replace them by an empty string

In “StreetFR_cleansed”, you will :

• Standardise street names by expanding abbreviations. For instance “Av Fonsny”, “Av. Fonsny”, “Av.Fonsny” or “A Fonsny” should all become “Avenue Fonsny”. Use several variants : Avenue (Av, Ave, A), Chaussée (Ch, chée), Boulevard (B, Bd, blvd, bvd), Rue (R), Place (Pl), Square (Sq). Replace those pattern only at the begining of the sentence, or if they are only preceded by numbers. Replacement should always be followed by a space.
• Trim heading or leading spaces, and collapse consecutive spaces.
• As described in the previous section, extract housenumber and put them in HouseNumber_cleansed
• Set all words in title case, excepts determiner (le, la, les, du, des, aux, de…).
• Roman numbers should be in uppercase
• Remove all variants of “no number” (‘SN’, ‘ZN’, ‘S/N’, ‘*’, ‘?’, ‘-‘, ‘/’ and many others), at the end of the string and isolated (Not in “FonSNy”)

Fase 2: deduplicatie

In deze tweede fase proberen wij varianten van dezelfde straatnaam te identificeren. Als wij bijvoorbeeld voor dezelfde postcode “Rue V. Horta” in het ene record en “Rue Victor Horta” in een ander record aantreffen, dan behouden wij de meest volledige versie voor de dataset. Het instructiebestand bevat talrijke toelichtingen en voorbeelden (zoals bijvoorbeeld dat “Boulevard Léopold II” niet mag worden samengevoegd met “Boulevard Léopold III”), waarop wij hier niet nader zullen ingaan.

Instructies voor fase 2

In this second phase, you will be more aggressive in the cleansing of street names, and take more risks. Output of this second phase will be in column “StreetFR_cleansed2”. This column will be computed starting from “StreetFR_cleansed” and will:

• If an initial can be expanded from other values within the same zipcode, do it. For instance : “rue V. Horta, 1160 Auderghem” in one record, “rue Victor Horta, 1160 Auderghem” in another, keep the longest one for both. In this case, the extension from an initial to a full name should be the only change. Do not map “Avenue V. Horta” to “Rue Victor Horta”. Do not map “Rue V. Van Horta” to “Rue Victor Van Fonsny”.
• Within different street names sharing the same zip, cluster spelling variants, keeping in “StreetFR_cleansed2” the most frequent value. For instance, if we have, for zipcode 1060, 100 times “Avenue Fonsny” and once “Avenue Fonsmy” or “Avenue Fonsni”, keep “Avenue Fonsny” in StreetFR_cleansed2.
• Before comparing strings, always remove street type (Avenue, Boulevard, Rue, Place, Square, Chaussée…) at the beginning of the street name. But do not map a street on a street with another street type.
• Similarity should be at least 0.9
• If the only difference between two street names is a diacritic symbol or punctuation, keep the most frequent one even if they don’t share the same zipcode : “Chaussée de Wavre” vs “Chaussee de Wavre” or “Chaussée de Wavre,”
• Be aware of roman numbers : “Boulevard Léopold II” should not be merged with “Boulevard Léopold III”

Te leveren resultaat

Tot slot wordt het volgende gevraagd:

• Een downloadbare lijst in Excel-formaat leveren, waaraan de berekende kolommen zijn toegevoegd;
• Een of meer leesbare en gedocumenteerde Python-scripts generen waarmee de opschoning kan worden uitgevoerd.

Vergelijking

Wij hebben dezelfde data met hetzelfde Markdown-instructiebestand meerdere keren, met een tussenpoos van enkele uren, aan een reeks tools voorgelegd. Vervolgens hebben wij:

• Elke gegenereerde lijst geanalyseerd om na te gaan of de instructies correct waren opgevolgd;
• Twee door dezelfde tool gegenereerde outputs vergeleken om de consistentie van het werk te beoordelen;
• Het gegenereerde Python-script uitgevoerd om te controleren of het uitvoerbaar was en inderdaad hetzelfde resultaat opleverde als de output die rechtstreeks door de tool was gegenereerd.

De tools die wij hebben onderzocht, zijn de volgende:

• ChatGPT (OpenAI, “Plus”-abonnement), model GPT 5.6 Thinking;
• Gemini (Google, “Pro”-abonnement), model 3.1 Pro;
• Copilot (Microsoft, “Base”-abonnement, gratis), model GPT 5. Daarnaast hebben wij ook een “Pro”-versie getest, geïntegreerd in Excel en GitHub
• Claude (Anthropic, “Free”-abonnement), model Sonnet 5 Medium
• Mistral (“Free”-abonnement), “Réflexion”

Een eerste blik op elke resultatenlijst geeft een positieve indruk: bij het bekijken van de wijzigingen tussen de in- en outputkolommen lijken deze overwegend relevant. Deze tools “doen dus hun werk”, lijkt het. Maar bij nader inzien is de situatie niet zo rooskleurig.

Consistentie

Het eerste aspect dat opvalt, is het gebrek aan consistentie bij de tools. Geen van de tools heeft tijdens de drie opeenvolgende evaluaties dezelfde bewerkingen op de data uitgevoerd (met, laten we dat nogmaals benadrukken, hetzelfde model, dezelfde data en dezelfde prompt). Hieronder staat bijvoorbeeld het percentage wijzigingen tussen de inputstraat en de gewijzigde straat aan het einde van fase 2:

	Test 1	Test 2	Test 3	Delta
ChatGPT	5,44%	6,97%	8,41%	2,97 %
Gemini	9,62%	5,76%	9,84%	4,08%
Copilot	16,20%	0,27%	13,52%	15,93%
Claude	5,28%	5,22%	5,30%	0,08%
Mistral	32,22%	20,69%	99,79%	79,10%

De kolom “Delta” geeft het verschil aan tussen de grootste en de kleinste waarde: dit komt dus (vrijwel) overeen met het percentage adressen dat de “voorzichtigste” test niet heeft gewijzigd, terwijl de meest “agressieve” variant dat wel heeft gedaan. Er is dus een opmerkelijke consistentie waarneembaar tussen de iteraties van Claude, en zelfs van ChatGPT, terwijl Copilot en vooral Mistral bij hetzelfde probleem radicaal andere keuzes lijken te hebben gemaakt.

Wat de consistentie betreft: hoewel het over het algemeen volstond om in één enkel verzoek de data en instructies te verzenden om het opgeschoonde bestand en het script direct te kunnen downloaden, was dit niet altijd het geval. Bij de tweede iteratie van Copilot was het gegenereerde script bijvoorbeeld leeg. Er moest “onderhandeld” worden (drie opeenvolgende verzoeken) om het uiteindelijk te verkrijgen. In een eerdere fase van ons onderzoek kon Gemini het gevraagde bestand bij een eerste poging correct genereren, maar liep het bij de tweede poging vast: het beweerde dat het onmogelijk was om Pythoncode in zijn omgeving uit te voeren. Hoewel wij hem duidelijk maakten dat hij daar enkele uren eerder nog wel toe in staat was geweest, hielp dat niets. We moesten een nieuwe sessie starten om het opnieuw voor elkaar te krijgen.

Uitvoering

Voor elke test hebben we het gegenereerde Pythonscript uitgevoerd en het resultaat ervan vergeleken met de ontvangen lijst.
Voor ChatGPT valt er niets te melden: de scripts worden in ongeveer één minuut uitgevoerd en leveren een resultaat op dat strikt identiek is aan de lijst.
Voor Claude is het eveneens bijna foutloos: een iets langere uitvoering (+/- 5 minuten), twee iteraties die een strikt conform resultaat opleverden, en één met 12 zeer kleine verschillen, telkens het gevolg van gelijkwaardige alternatieven.
Bij Gemini is de balans gemengder: het eerste script raakte verstrikt in een oneindige lus! Het tweede leverde een conform resultaat op, het derde 70 verschillen.
Bij Copilot is er nog een probleemstelling: bij één van de tests is het ons simpelweg niet gelukt om het script te verkrijgen. Voor een andere test was het direct beschikbaar, en voor de derde hebben we het na onderhandelingen verkregen. De twee scripts leverden respectievelijk 637 en 810 afwijkende regels op ten opzichte van de bijbehorende lijst.
Wat dit aspect betreft, gaat de titel van slechtste leerling naar Mistral (maar, ter herinnering, met een gratis account): het is de enige die nooit direct een lijst heeft kunnen genereren, maar uitsluitend Pythonscripts. Een daarvan was overigens niet uitsluitend in Python geschreven, maar bevatte ook JavaScript-instructies. Nadat wij hem hierop hadden gewezen, heeft Mistral zijn code gecorrigeerd, maar deze was nog steeds niet bruikbaar. Het was pas de derde versie die wij konden laten draaien. Bij een van onze andere tests ontbrak in de code een noodzakelijke “import”. Bovendien varieerde de uitvoeringstijd van 6 tot … 50 minuten!

Indicatoren

Vervolgens hebben wij de verschillende instructies doorgenomen om te beoordelen in hoeverre deze werden nageleefd.

“Zonder nummer”

In onze instructies hebben wij zeven waarden opgegeven die overeenkomen met het ontbreken van een nummer in een adres (SN, ZN, S/N, *, ?, -, /), waarbij wij aangaven dat er nog andere waren. Sommige hebben er geen enkele geïdentificeerd (tweede Copilot-test), andere tot wel 19 (tweede Claude-test). Geen enkele tool identificeerde bij zijn verschillende iteraties dezelfde waarden.

Hoofdletters

We hebben gevraagd om bij de output de hoofdletters van de straatnaam op een enigszins subtiele manier aan te passen: titelhoofdletters (title case, eerste letter van elk woord hoofdletter, de overige letters kleine letters), maar met een extra voorwaarde: de lidwoorden (de, la, des…) moesten in kleine letters blijven. Het resultaat zou dus “Rue de Sainte-Anne” moeten zijn, en niet “Rue De Sainte-Anne” of “Rue de Sainte-anne”. Wij hebben verschillende situaties waargenomen:

• Het volledig ontbreken van correctie, waarbij de oorspronkelijke hoofdlettergebruik behouden bleef (2e Copilot-test);
• Een onjuist gebruik van koppeltekens (“Rue Sainte-anne”) of apostrofs (“Chaussée D’ixelles”). Verrassend, aangezien de “title”-functie van Python “Rue Sainte-Anne” en “Chaussée D’Ixelles” zou hebben geschreven (het was vervolgens “voldoende” om het lidwoord “D” in kleine letters te zetten). Er werden ook enkele inconsistenties binnen één en dezelfde lijst waargenomen, zoals “Sainte-Anne”, maar “Grand-place” of “Eglise-saint-pierre”;
• Een van de Mistral-tests leidde tot een erg willekeurige implementatie: elk woord dat begon met een lidwoord (“de”, “la”, maar ook “d” of “l”) werd in kleine letters weergegeven.

Romeinse cijfers

Naast de hierboven beschreven correctie van hoofdletters en kleine letters hebben wij gevraagd om Romeinse cijfers in hoofdletters te laten staan. Deze komen voornamelijk voor in de namen van Belgische koningen (Albert II, Leopold I, II of III), buitenlandse vorsten (Jozef II, Karel VI…) of zelfs pausen (Leo XIII). Dit is in bijna alle tools correct geïmplementeerd. Verschillen zijn vooral waarneembaar in de manier waarop grensgevallen worden behandeld:

• In Brussel is er een “Rue Vilain XIIII”. Maar 14 wordt vaak geschreven als “XIV” en niet als “XIIII”. Dit verklaart ongetwijfeld waarom deze straatnaam in bijna de helft van de gevallen is weergegeven als “Rue Vilain Xiiii”;
• Woorden als “midi” of “dix” werden door sommige tools als Romeinse cijfers beschouwd en met een hoofdletter geschreven (hoewel “MIDI” geen geldig getal is, in tegenstelling tot “DIX”). Maar aangezien Romeinse cijfers in straatnamen over het algemeen relatief kleine waarden vertegenwoordigen, zou het redelijk kunnen zijn om daarin geen “M” (1000) voor “D” (500) op te nemen. Op basis van deze observatie hebben wij hoofdzakelijk drie implementaties kunnen identificeren:
  • Een eenvoudige reguliere expressie waarin de toegestane tekens worden opgesomd: [IVXLCDM]+; dit was het geval bij de eerste iteratie van ChatGPT, Copilot en Mistral. In onze data worden DIX en MIDI dus beschouwd als Romeinse cijfers, maar we kunnen ons ook andere woorden voorstellen (Civil, Mix, Vil, Il, Clic….)
  • Een lijst met aanvaardbare waarden (‘I’, ‘II’, ‘III’, ‘IV’ …), waarvoor Gemini heeft gekozen, of een van de implementaties van CoPilot
  • Een complexe, veel nauwkeurigere reguliere uitdrukking voor twee implementaties van ChatGPT of Claude, waarbij één daarvan een aanvullende lijst met uitsluitingen bevat (met daarin ‘midi’ en ‘dix’).

Nummerherkenning

Bij het herkennen van het nummer dat in de straatnaam is opgenomen (“20 Avenue Fonsny”, “Avenue Fonsny 20” of “Avenue Fonsny, 20”) bleek er een grote verscheidenheid aan implementaties te bestaan. Hoewel ChatGPT en Claude geen noemenswaardige moeilijkheden ondervonden, liepen de andere systemen allemaal vast op meer of minder subtiele speciale gevallen. Bijvoorbeeld: twee van de drie pogingen van Gemini faalden bij het herkennen van gevallen zoals “Avenue Fonsny, 20 A”). De tweede iteratie van Copilot haalde geen enkel huisnummer aan het begin eruit, en geen enkele versie kon het geval “…, 20 A”) herkennen. Mistral laat zeer gemengde resultaten zien.

Voorvoegsel

Situaties van het type “Av. Fonsny” of “A Fonsny” (te corrigeren naar “Avenue Fonsny”) werden eveneens op zeer uiteenlopende wijze geïmplementeerd. De derde iteratie van ChatGPT schoot volledig naast de doelstelling. Een “Petite rue des Loups” werd zo “Place Etite Rue des Loups”; “Abbaye de la Cambre” werd omgezet in “Avenue Bbaye de la Cambre”

Fase 2

De tweede fase bestond uit het identificeren van kleine varianten tussen twee straatnamen binnen dezelfde postcode, om vervolgens de minst voorkomende waarde te vervangen door de meest voorkomende. Als wij bijvoorbeeld 10 vermeldingen van “Rue Sainte-Anne” en één van “Rue Sainte Anne” tegenkomen , vervangen wij deze laatste door de variant met het koppelteken. De moeilijkheid van deze fase ligt in het bepalen van de methoden en de drempels voor de vergelijking. Hoewel verschillende tests uitstekend zijn verlopen, was dit niet altijd het geval. Er werden met name verschillende “agressieve” fusies waargenomen. Zoals “Rue des Chalets”, gewijzigd in “Rue des Chats”; “Rue des Barques” in “Rue des Briques”, of “Rue des Ramoneurs” in “Rue des Rameurs”. Sommige systemen lijken echter nog toleranter te zijn geweest: Gemini heeft zo “Rue de la Fontaine” veranderd in “Rue de la Montagne”; “Rue Américaine” in “Rue Africaine”, of “Rue Vergote” in “Rue Verte”.

Overigens moet worden opgemerkt dat Copilot deze fase in geen enkele iteratie heeft geïmplementeerd. Nadat wij hierop hadden aangedrongen, constateerden wij een volstrekt willekeurige implementatie. Hierbij werden uitsluitend wijzigingen in het type straat waargenomen (de “Place Saint-Vincent” werd de “Rue Saint-Vincent”; “Rue de Louvain” werd “Chaussée de Louvain”), zonder rekening te houden met de postcode. Dit is precies het tegenovergestelde van wat was gevraagd. Bovendien waren verschillende elementen van de eerste fase die in de eerste implementatie correct werkten, dat niet meer in de versie waarin beide fasen waren opgenomen.

Wat Mistral betreft, was de situatie nog erger. De eerste test voerde geen andere correcties uit dan wijzigingen in hoofdlettergebruik of interpunctie; de tweede test bracht talrijke volstrekt ongepaste wijzigingen aan (van “Rue de Rome” naar “Rue de Mérode”; “Rue des Trois-Tilleuls” -> “Rue du Loutrier”…), en dit voor 650 waarden, oftewel drie keer zoveel als de wijzigingen die bij de beste outputs werden waargenomen; de derde output lijkt simpelweg alle waarden door elkaar te hebben gehaald, met volstrekt willekeurige wijzigingen voor elke waarde. Dit verklaart de delta van 99,79 % in de bovenstaande tabel. Merk op dat het standaardiseren van de waarden van een dataset op basis van interne variaties duidelijk niet de beste aanpak is: het verdient ongetwijfeld de voorkeur om, indien mogelijk, de waarden te vergelijken met een referentiekader, dat in dit geval zou bestaan uit de lijst van alle straatnamen met hun officiële spelling.

Cijfermatige evaluatie

Om de iteraties in hun totaliteit te kunnen vergelijken, hebben wij ongeveer dertig criteria vastgesteld die wij bij elk van de drie iteraties van de vijf onderzochte tools hebben beoordeeld. Voor bepaalde criteria hebben wij 2 punten toegekend indien het criterium correct of vrijwel correct was geïmplementeerd; 1 punt indien dit gedeeltelijk het geval was en 0 punten indien het helemaal niet of zeer slecht was geïmplementeerd. Sommige andere criteria zijn numeriek beoordeeld, zoals bijvoorbeeld het aantal waarden dat als “zonder nummer” werd geïdentificeerd. Dit soort criteria hebben wij omgezet in een schaal van 0 tot 2. Vervolgens hebben wij deze verschillende waarden bij elkaar opgeteld om een score te verkrijgen. Deze totale score is dus geen percentage en heeft op zichzelf geen betekenis. Zij stelt ons eenvoudigweg in staat om, met een zekere mate van objectiviteit, de verschillende outputs van de diverse tools met elkaar te vergelijken.

Deze cijfers bevestigen het beeld dat onze analyse ons had gegeven. Claude is de duidelijke winnaar, zowel wat betreft de totale score als de stabiliteit. ChatGPT volgt op korte afstand. Verderop, op aanzienlijke afstand en nek aan nek, volgen Gemini en Copilot, terwijl Mistral ver achterblijft. Laten wij eraan herinneren dat het hier om de gratis versie gaat, maar dat geldt ook voor Claude.

Algemene indruk

Onze algemene indruk tijdens deze test was dat wij over het geheel genomen het gevoel hadden een junior-ontwikkelaar tot onze beschikking te hebben: snel weliswaar, maar middelmatig, en iemand die voortdurend in de gaten moet worden gehouden. Hij maakt veel fouten en is niet consistent. Als hij gevraagd wordt een probleem op te lossen, is de kans groot dat hij tegelijkertijd problemen veroorzaakt in een heel ander deel van de code. Als hij twee keer hetzelfde moet doen, maakt hij soms radicaal verschillende keuzes.

Het is duidelijk dat de eenvoudige aanpak (alle instructies in één keer versturen, in het vertrouwen dat de gegenereerde code correct is) voor geen van de tools werkt, in ieder geval niet voor dit specifieke gebruiksscenario. Op zijn minst moet dezelfde vraag meerdere keren worden gesteld om het resultaat te beoordelen en de beste onderdelen van elke tool te combineren. Het kostte ons echter veel tijd om deze vergelijkende analyse op te zetten, de problemen te identificeren en deze objectief te benaderen, ongeveer even lang als de tijd die wij nodig zouden hebben gehad om het script volledig zelf te schrijven. Misschien verdient onze opdrachtformulering verbetering. Misschien bevatte deze te veel instructies en hadden wij een meer iteratieve aanpak moeten volgen, maar dat zou de vergelijkingen aanzienlijk hebben bemoeilijkt. De vraag om niet alleen adressen op te schonen, maar ook het script daarvoor te leveren – zodat hergebruik mogelijk is – legde uiteraard een extra beperking op aan de tools. In een toekomstig onderzoek zullen wij deze beperking opheffen. Een meer “agentgerichte“ aanpak, waarbij een agent meerdere scripts zou kunnen opvragen en deze zou kunnen vergelijken, zou waarschijnlijk voordelen kunnen opleveren.

Merk op dat wij ook een verbetering hebben geprobeerd: we hebben ChatGPT gevraagd: “How to improve the attached prompt to make sure ChatGPT implements correctly all instructions?”. Het heeft onze promptbestand aangepast, zodat het veel nauwkeuriger en gedetailleerder werd. Het resultaat was een bestand dat drie keer zo groot was. Maar helaas heeft dit de situatie niet echt verbeterd, integendeel. Copilot heeft het bij de eerste twee pogingen simpelweg opgegeven. Bij de derde poging leverde het ons wel een lijst op, maar niet het script. Gemini was in staat een script te genereren (waarvan twee van de drie moesten worden aangepast om uitvoerbaar te zijn), maar kon dit nooit daadwerkelijk uitvoeren. En we constateerden opnieuw grote verschillen tussen de verschillende iteraties van dezelfde tool.

Bovendien bestaan er voor deze specifieke probleemstelling van het opschonen van adressen talrijke klassieke, zeer doeltreffende tools om deze taak uit te voeren. De trend van “alles met AI“, die we steeds vaker waarnemen, verdient ongetwijfeld enige matiging. In een tijd van grootschalige bosbranden, herhaaldelijke hittegolven en verwoestende overstromingen is het gebruik van tools die aanzienlijk meer energie en water verbruiken dan traditionele, beproefde methoden – die stabieler en vaak efficiënter zijn – duidelijk een aanpak die ter discussie moet worden gesteld.

De informatica van morgen moet ongetwijfeld een belangrijke plaats inruimen voor generatieve AI, die in vele opzichten een onbetwistbare meerwaarde biedt in vele opzichten. Maar dit mag niet op een blinde manier gebeuren, waarbij de traditionele methoden, die in veel opzichten nog steeds duidelijk beter presteren, zomaar terzijde worden geschoven. Bovendien moeten we ons bewust zijn van het gebrek aan consistentie van deze tools. Dit is in veel situaties zeker geen probleem, maar kan dat in bepaalde gevallen wel zijn, met name wanneer een keuze juridische of medische gevolgen kan hebben.