AI-toepassingen testen vraagt om meer dan een paar voorbeeldvragen aan een model voorleggen. Je leest hoe je testsets opbouwt, kwaliteit meetbaar maakt en wijzigingen controleert zonder uitsluitend op handmatige beoordeling te vertrouwen.
Waarom AI-uitvoer anders testen is dan gewone software
Bij traditionele software levert dezelfde invoer onder dezelfde omstandigheden meestal dezelfde uitvoer op. Bij generatieve AI kan een prompt meerdere plausibele antwoorden opleveren, zelfs wanneer het model, de instellingen en de context gelijk blijven. Een test die alleen controleert of de uitvoer exact overeenkomt met één verwacht antwoord, is daarom vaak ongeschikt. De beoordeling moet vaststellen of de uitkomst voldoet aan inhoudelijke en functionele eisen, niet of de formulering identiek is.
Dat vraagt om tests op verschillende niveaus. Controleer bijvoorbeeld of de toepassing de juiste informatie gebruikt, de gevraagde taak uitvoert, onzekerheid gepast behandelt en geen verboden gegevens prijsgeeft. Bij een chatbot kan een antwoord taalkundig overtuigend zijn maar toch een verouderde bron citeren. Bij een classificatiemodel kan de algemene nauwkeurigheid hoog zijn terwijl een belangrijke categorie vaak verkeerd wordt ingedeeld. Gemiddelden verbergen zulke fouten.
Leg daarom vooraf vast wat een fout betekent in de context van de toepassing. Een onjuiste samenvatting, een ontbrekende bronverwijzing en het verzinnen van een feit zijn niet altijd even zwaarwegend. De testaanpak volgt uit het risico en het gebruik: welke beslissingen beïnvloedt de uitvoer, wie controleert die en wat gebeurt er wanneer het systeem faalt? Zonder die afbakening is een testsuite vooral een verzameling voorbeelden, geen betrouwbare kwaliteitsmeting.
Beoordelingscriteria formuleren voor AI-uitvoer
Een bruikbare evaluatie begint met criteria die beoordelaars op dezelfde manier kunnen toepassen. Termen als ‘goed’, ‘nuttig’ of ‘natuurlijk’ zijn te breed zolang niet duidelijk is welk waarneembaar gedrag erbij hoort. Beschrijf per criterium wat de test beoordeelt en welke uitkomsten acceptabel zijn. Voor een antwoord op basis van interne documenten kan dat bijvoorbeeld betekenen: de hoofdvraag wordt direct beantwoord, relevante feiten zijn terug te vinden in de aangeleverde bronnen en ontbrekende informatie wordt niet ingevuld met aannames.
Splits samengestelde kwaliteitsbegrippen waar mogelijk op. Feitelijke juistheid is iets anders dan volledigheid; brongetrouwheid verschilt van leesbaarheid. Een score op één totaalcijfer kan problemen verbergen doordat een hoge stijlscore een inhoudelijke fout compenseert. Gebruik daarom aparte dimensies en bepaal welke daarvan harde voorwaarden zijn. Als een antwoord persoonsgegevens onthult, mag een goede toon dat niet goedmaken.
Een beoordelingsschaal moet concrete ankerpunten bevatten. Bij een schaal van nul tot twee kan nul staan voor een onjuist of niet-onderbouwd antwoord, één voor gedeeltelijk bruikbaar maar onvolledig, en twee voor correct en voldoende onderbouwd. Voeg voorbeelden toe van grensgevallen en laat beoordelaars die gezamenlijk bespreken. Dat maakt verschillen in interpretatie zichtbaar voordat de evaluatie op grote schaal begint. Criteria zijn bovendien niet permanent: wijzigingen in productgedrag, bronnen of beleid kunnen een nieuwe definitie van acceptabele uitvoer noodzakelijk maken.
Representatieve testdata samenstellen
Een testset moet weerspiegelen hoe de toepassing werkelijk wordt gebruikt, inclusief invoer die onvolledig, dubbelzinnig of ongebruikelijk is. Alleen nette voorbeeldvragen testen vooral de demonstratieversie van een systeem. Verzamel daarom uiteenlopende gevallen uit gebruiksscenario’s, gesprekken, formulieren of bestaande processen, en anonimiseer gevoelige gegevens voordat materiaal wordt hergebruikt. Als echte data niet beschikbaar zijn, kunnen synthetische voorbeelden helpen, maar die moeten worden gecontroleerd op realisme en dekking.
Verdeel de voorbeelden bewust over relevante groepen en situaties. Voor een documentassistent kan dat verschillende documenttypen, talen, lengtes, versies en kwaliteit van bronmateriaal betekenen. Neem ook voorbeelden op waarbij het juiste gedrag is om te weigeren, een verduidelijkende vraag te stellen of te melden dat informatie ontbreekt. Zonder zulke gevallen kan een model dat altijd een antwoord produceert ten onrechte hoog scoren.
Let op dat testdata geen onbedoelde vertekening introduceert. Veelvoorkomende voorbeelden kunnen de score domineren, terwijl zeldzame maar risicovolle gevallen te weinig gewicht krijgen. Maak daarom onderscheid tussen een representatieve set voor gemiddeld gebruik en een gerichte set voor uitzonderingen of veiligheidsrisico’s. Bewaar herkomst, selectiegrond en relevante labels van elk voorbeeld. Zo kunnen teams later nagaan of een scoreverandering komt door gewijzigd modelgedrag, een aangepaste testset of een andere interpretatie van de criteria. Een testset is geen neutrale afspiegeling vanzelf; de samenstelling bepaalt mede welke kwaliteit zichtbaar wordt.
Golden datasets en referentieantwoorden beheren
Een golden dataset is een verzameling testgevallen met een zorgvuldig vastgelegde referentie: bijvoorbeeld het verwachte label, de relevante bronpassages of de kenmerken waaraan een antwoord moet voldoen. Zo’n dataset maakt vergelijkingen tussen modelversies en promptwijzigingen mogelijk. De referentie hoeft niet altijd één ideale tekst te zijn. Bij een open vraag zijn meerdere formuleringen correct, terwijl bij extractie uit een formulier een exact veld of label juist wel passend kan zijn.
Kies de referentievorm op basis van de taak. Voor classificatie kan een label met toelichting volstaan. Voor vraagbeantwoording op basis van documenten is het vaak nuttiger om toegestane feiten en bronverwijzingen vast te leggen dan één voorbeeldantwoord letterlijk te eisen. Dat voorkomt dat correcte alternatieve formuleringen als fouten tellen. Leg ook vast wanneer een antwoord als gedeeltelijk correct geldt en hoe beoordelaars omgaan met ontbrekende of tegenstrijdige informatie.
Beheer de dataset als een versieerbaar onderdeel van de toepassing. Registreer wijzigingen aan voorbeelden, labels en beoordelingsregels, zodat resultaten uit verschillende evaluatieruns vergelijkbaar blijven. Houd een deel van de gevallen buiten de ontwikkelcyclus als onafhankelijke controle. Als ontwikkelaars voortdurend op dezelfde voorbeelden optimaliseren, kan het systeem die gevallen uit het hoofd leren zonder robuuster te worden. Voeg nieuwe voorbeelden toe wanneer productgebruik of foutanalyse daar aanleiding toe geeft, maar wijzig bestaande referenties niet stilzwijgend. Een dataset die meegroeit zonder versiebeheer maakt historische scores moeilijk interpreteerbaar.
Automatische meetmethoden en hun beperkingen
Automatische metrics zijn geschikt voor grote aantallen tests en terugkerende controles. Bij classificatie kun je bijvoorbeeld precisie, recall en verwarringsmatrices gebruiken. Die laten zien welke categorieën vaak worden verwisseld en of het systeem te vaak een label toekent. Voor extractie kunnen veldnauwkeurigheid en exacte overeenkomst inzicht geven. Bij gegenereerde tekst zijn woordoverlapmetrics soms bruikbaar voor specifieke taken, maar ze beoordelen niet vanzelf of een antwoord feitelijk klopt of de vraag goed begrijpt.
Gebruik een metric alleen wanneer de relatie met de gewenste kwaliteit duidelijk is. Een hoge overeenkomst met een referentietekst kan een antwoord belonen dat dezelfde woorden gebruikt maar een feit verkeerd weergeeft. Omgekeerd kan een inhoudelijk juist antwoord een lage overeenkomstscore krijgen door een andere formulering. Voor retrieval kan de dekking van relevante passages worden gemeten, maar dat zegt nog niet of het taalmodel die passages correct gebruikt. Evalueer componenten daarom afzonderlijk waar dat diagnostisch voordeel oplevert.
Combineer scores met foutcategorieën en voorbeelden. Een daling in gemiddelde kwaliteit is pas bruikbaar wanneer duidelijk wordt welke gevallen verslechteren en waarom. Stel drempels niet uitsluitend in op basis van een aantrekkelijke totaalscore; kijk naar prestaties per taaktype, taal, bronsoort en risicoklasse. Automatische beoordelaars, waaronder een tweede taalmodel, kunnen helpen bij het voorselecteren of rubriceren van uitvoer. Valideer hun oordeel echter tegen menselijke beoordelingen, want ook zo’n beoordelaar kan systematische voorkeuren of blinde vlekken hebben. Een metric is een instrument voor besluitvorming, geen definitie van kwaliteit.
Menselijke beoordeling doelgericht inzetten
Menselijke controle blijft belangrijk wanneer kwaliteit contextafhankelijk is, fouten gevolgen hebben of automatische metrics de taak niet goed vangen. Beoordelaars kunnen bijvoorbeeld vaststellen of een samenvatting een nuance verkeerd weergeeft, of een antwoord misleidend klinkt ondanks feitelijk correcte losse zinnen, en of een weigering passend is. Hun inzet werkt het best met een afgebakende taak, duidelijke criteria en toegang tot de informatie die nodig is om de uitvoer te verifiëren.
Ongeleide beoordeling levert wisselende resultaten op. De ene beoordelaar let op volledigheid, de andere op stijl; persoonlijke voorkeur kan dan worden aangezien voor kwaliteitsverschil. Gebruik daarom rubrics met definities, voorbeelden en instructies voor twijfelgevallen. Laat een deel van de voorbeelden onafhankelijk door meerdere beoordelaars beoordelen. Meet hoe vaak zij overeenstemmen en bespreek structurele verschillen. Lage overeenstemming kan wijzen op onduidelijke criteria, onvoldoende context of een taak waarvoor een eenvoudige schaal niet geschikt is.
Handmatige controle alleen schiet tekort zodra aantallen, variatie of herhaalbaarheid belangrijk worden. Mensen kunnen niet iedere uitvoer uit productie nalopen, raken vermoeid en herkennen niet altijd subtiele verschuivingen tussen modelversies. Bovendien zijn beoordelingen achteraf moeilijk vergelijkbaar wanneer beoordelaars geen vaste procedure volgen. Gebruik menselijke evaluatie daarom voor risicovolle voorbeelden, validatie van automatische methoden en analyse van nieuwe foutpatronen. Leg vast wie beoordeelde, welke informatie beschikbaar was en hoe meningsverschillen zijn opgelost. Zo wordt menselijke expertise onderdeel van een reproduceerbaar proces in plaats van een incidenteel oordeel.
Regressietests voor prompts, modellen en data
Een wijziging aan een prompt, model, retrieval-instelling of bronverzameling kan bestaande prestaties ongemerkt beïnvloeden. Regressietests voeren een vaste set gevallen opnieuw uit en vergelijken de resultaten met een eerdere basislijn. Dat is vooral nuttig wanneer een aanpassing één probleem lijkt op te lossen, maar mogelijk andere taken schaadt. Een prompt die antwoorden beknopter maakt, kan bijvoorbeeld ook belangrijke voorwaarden weglaten; een gewijzigde zoekinstelling kan relevante passages beter vinden voor één vraag en slechter voor een andere.
Bewaar per evaluatierun de relevante configuratie: modelidentificatie, promptversie, parameters, gebruikte data en evaluatiecode. Zonder die informatie is een verschil in score lastig te verklaren of te reproduceren. Omdat generatieve uitvoer kan variëren, zijn herhaalde runs soms nodig om toevallige fluctuaties te onderscheiden van een echte verschuiving. Voor deterministische onderdelen volstaat vaak een directe vergelijking, maar bij variabele uitvoer moet de testprocedure rekening houden met spreiding.
Beoordeel veranderingen niet alleen op basis van één algemene drempel. Een kleine gemiddelde verbetering kan samengaan met een ernstige terugval in een specifieke categorie. Stel per criterium vast welke afwijkingen nader onderzoek vragen en welke fouten blokkeren dat een wijziging wordt geaccepteerd. Houd ook rekening met veranderingen in de testset zelf: vergelijk scores alleen wanneer de meetbasis bekend is. Regressietests vervangen geen inhoudelijke analyse, maar maken veranderingen zichtbaar en geven een concrete lijst gevallen om te onderzoeken. Zo wordt model- en promptontwikkeling minder afhankelijk van indrukken uit enkele handmatig gekozen voorbeelden.
Kwaliteit in productie volgen en testsets bijwerken
Een toepassing kan in een testomgeving goed presteren en in productie toch andere invoer tegenkomen. Gebruikers formuleren vragen anders, bronnen veranderen en randgevallen worden pas zichtbaar wanneer het systeem in een echte workflow wordt gebruikt. Productie-evaluatie volgt daarom niet alleen de gemiddelde score, maar ook signalen zoals foutmeldingen, ontbrekende bronnen, herhaalde pogingen, escalaties en handmatige correcties. Zulke signalen zijn aanwijzingen, geen direct bewijs van een modelprobleem: een gebruiker kan bijvoorbeeld een antwoord aanpassen om redenen die buiten de kwaliteit van de uitvoer liggen.
Leg alleen gegevens vast die nodig zijn voor analyse en pas passende privacymaatregelen toe. Gevoelige invoer kan niet zonder meer als testmateriaal worden bewaard. Een praktische aanpak is om gebeurtenissen te categoriseren, relevante gevallen te redigeren en toegang tot ruwe gegevens te beperken. Maak bovendien onderscheid tussen observaties die automatisch zijn gemeten en oordelen die door mensen zijn bevestigd. Anders kunnen dashboards schijnzekerheid geven over wat er daadwerkelijk misgaat.
Gebruik productiegevallen om de testset gericht te verbeteren. Voeg voorbeelden toe wanneer een nieuwe foutklasse terugkeert, wanneer een bronsoort verandert of wanneer gebruikersgedrag een eerdere aanname onder druk zet. Controleer vóór opname of het geval geen duplicaat is en of de beoordelingsregel duidelijk is. Pas daarna de evaluatie aan en vergelijk de nieuwe resultaten met eerdere runs. Zo blijft de testset verbonden met het werkelijke gebruik, zonder elke tijdelijke uitschieter meteen als structurele tekortkoming te behandelen. Het beheer vraagt om een vaste cyclus van signaleren, beoordelen, labelen en opnieuw testen; die cyclus maakt zichtbaar waar AI-kwaliteit standhoudt en waar aanvullende controle nodig is.
Veelgestelde vragen
Hoe test je een AI-toepassing op prompt injection?
Test prompt injection met aanvallen die proberen de instructies of gegevensverwerking van de toepassing te manipuleren. Neem zowel directe aanvallen in gebruikersinvoer op als indirecte aanvallen in documenten of webpagina’s die het systeem ophaalt. Controleer niet alleen de tekst van het antwoord, maar ook of de toepassing vertrouwelijke informatie afschermt en geen ongewenste acties uitvoert.
- Test verschillende formuleringen, talen en omzeilpogingen.
- Controleer of opgehaalde inhoud als onbetrouwbare invoer wordt behandeld.
- Verifieer toegangsrechten en vereiste bevestiging voor risicovolle acties.
Wanneer moet AI-uitvoer door een medewerker worden gecontroleerd?
Laat AI-uitvoer door een medewerker controleren wanneer de mogelijke gevolgen van een fout groot zijn of wanneer het systeem onvoldoende zekerheid heeft. Baseer die keuze niet alleen op een zelfgerapporteerde betrouwbaarheidsscore: zo’n score kan slecht gekalibreerd zijn. Kijk ook naar de impact van de beslissing, de mogelijkheid om fouten te herstellen en de kwaliteit van de beschikbare bronnen.
- Stuur risicovolle of onvolledige gevallen door naar een medewerker.
- Laat de toepassing stoppen of om verduidelijking vragen als essentiële informatie ontbreekt.
- Maak duidelijk welke informatie de medewerker nodig heeft om de uitvoer te controleren.
Hoe neem je AI-evaluaties op in een CI/CD-pipeline?
Neem AI-evaluaties op in een CI/CD-pipeline door bij wijzigingen automatisch een passende testset uit te voeren en vooraf vastgelegde acceptatieregels toe te passen. Een kleine, snelle controleset kan bij iedere wijziging draaien; uitgebreidere tests kunnen volgen vóór een release of op vaste momenten. Zo worden afwijkingen vroeg zichtbaar zonder dat iedere ontwikkelstap dezelfde volledige evaluatie hoeft uit te voeren.
- Laat kritieke veiligheids- of functionele fouten een release blokkeren.
- Bewaar scores, foutgevallen en configuratie bij iedere run.
- Gebruik een mislukte test als aanleiding voor analyse, niet alleen als reden om de wijziging terug te draaien.
Welke gegevens moet je loggen om AI-problemen in productie te onderzoeken?
Log genoeg context om een probleem te kunnen reconstrueren, maar beperk persoonsgegevens en andere gevoelige inhoud tot wat daarvoor noodzakelijk is. Bewaar bijvoorbeeld welke model- en promptversie actief waren, welke bronnen of tools zijn gebruikt, wanneer de aanvraag plaatsvond en welke foutmelding of uitkomst volgde. Zonder die context is vaak niet vast te stellen of een probleem door het model, de invoer of een gewijzigde bron is ontstaan.
- Leg versies en relevante instellingen vast.
- Registreer toolaanroepen en foutstatussen waar dat nodig is.
- Stel toegangsrechten en bewaartermijnen in en anonimiseer of redigeer gevoelige inhoud.
Hoe test je een AI-systeem dat externe tools of API’s aanroept?
Test een AI-systeem met tool- of API-aanroepen op zowel de keuze van de actie als de uitvoering ervan. Een overtuigend antwoord is niet voldoende als het systeem de verkeerde API kiest, onjuiste parameters meestuurt of een actie uitvoert zonder de juiste bevoegdheid. Gebruik testomgevingen of gesimuleerde diensten, zodat evaluaties geen echte transacties of wijzigingen veroorzaken.
- Controleer of de juiste tool wordt gekozen en de argumenten geldig zijn.
- Test time-outs, foutmeldingen, lege antwoorden en dubbele verzoeken.
- Verifieer autorisatie, bevestiging voor ingrijpende acties en veilige afhandeling van gedeeltelijke fouten.
