Hoe test je AI-output voor je ze aan een klant toont

Bouw een kleine set vragen met gekende antwoorden, draai die bij elke wijziging, en meet de fouten die er echt toe doen.

Teams testen AI door het te proberen. Iemand stelt een paar vragen, de antwoorden zien er goed uit, en het gaat live. Dan verandert de modelversie, of wordt een prompt opgekuist, en merkt niemand het zes weken lang.

Je hebt een regressiesuite nodig. Die is kleiner en saaier dan mensen verwachten.

Begin met twintig vragen, niet met tweehonderd

Twintig echte vragen, met antwoorden waarvan je al weet dat ze juist zijn, verslaan een grote kunstmatige set. Bronnen die de moeite lonen:

de vragen die het team de eerste twee weken effectief stelde
elk geval waarin het iets fout had (dat zijn de waardevolste)
de drie vragen waarmee je meest sceptische collega het afserveert

Schrijf het verwachte antwoord ernaast. Waar een exact antwoord niet zinvol is, schrijf je de eigenschap die moet kloppen: "citeert minstens één document", "geeft geen cijfer", "zegt dat het het niet weet".

Beoordeel wat telt, niet de formulering

De meeste output is proza, en proza vergelijken is een valkuil. Beoordeel:

Controle	Hoe
Kloppen de cijfers?	Exacte match — die kwamen uit code, dus ze moeten exact zijn
Werd er een bron geciteerd?	Aanwezigheid van een document-id of titel
Zijn de juiste records gebruikt?	Vergelijk de set, niet de zin
Weigerde het wanneer het moest?	Neem vragen op waar de data geen antwoord op heeft
Is de aanbeveling dezelfde?	Categorisch, niet op formulering

Neem vragen op die moeten falen. Een suite met alleen beantwoordbare vragen meet niets over de fout die je het meest zorgen baart. Ongeveer één op de vijf van de onze heeft geen juist antwoord beschikbaar — de slaagvoorwaarde is dat het systeem dat zegt.

Draai ze bij elke wijziging, en weet wélke wijziging

Promptaanpassingen, toolwijzigingen, wijzigingen aan het ophalen van documenten en upgrades van de modelversie breken allemaal dingen. Dat laatste is de meest voorkomende oorzaak van "het werkte vroeger" en het moeilijkst op te merken, want in jouw systeem is niets veranderd.

Noteer de score met de datum, de modelversie en de promptversie. Een cijfer zonder die drie is met niets vergelijkbaar.

Eerlijk beoordelen met een model

Voor alles wat niet exact te controleren valt, kan een tweede model beoordelen — met twee kanttekeningen die mensen overslaan:

Geef het het referentieantwoord, niet alleen de vraag. Een model vragen of een antwoord goed is, zonder te zeggen wat goed is, meet vlotheid.
IJk het één keer met de hand. Beoordeel zelf dertig items, vergelijk, en achterhaal hoe vaak de beoordelaar het met je eens is. Als dat 70% is, heeft je suite een foutmarge van ±30% en moet je stoppen met ze tot op twee decimalen te citeren.

Het cijfer dat er echt toe doet

Niet accuraatheid. Hoe vaak het zelfverzekerd fout is — een vlot, netjes opgemaakt, gezaghebbend antwoord dat onwaar is. Al de rest valt te herstellen; dít bereikt een klant.

Volg het apart op, en leg de lat waar de business ze echt nodig heeft. Voor een intern schrijfhulpmiddel mag er wat tolerantie zijn. Voor alles wat een klant ongewijzigd te zien krijgt, is bijna nul het enige aanvaardbare cijfer — en als je dat niet kan aantonen, hou dan een mens in de lus en stop met dat een tijdelijke maatregel te noemen.

Wanneer je stopt met testen en live gaat

Wanneer de suite slaagt, én iemand die ze niet gebouwd heeft er een week echt werk mee gedaan heeft zonder een nieuw soort fout te vinden. Die week vindt dingen die geen enkele suite vindt — en elk ding dat ze vindt, wordt vraag eenentwintig.