Alleen al een antwoord van een AI-model krijgen betekent nog niet dat het systeem correct werkt. Bij klassieke software kunnen we vaak eenduidig controleren of een functie het verwachte resultaat heeft teruggegeven. In AI-systemen kan een antwoord vloeiend, logisch en overtuigend zijn, maar toch fouten bevatten.
Daarom ontstaat er met de ontwikkeling van AI een nieuw technisch probleem: hoe meten we systematisch de kwaliteit van een systeem waarvan de antwoorden niet altijd identiek zijn?
Dat is precies het domein van AI evaluation, oftewel de evaluatie van kunstmatige-intelligentiesystemen.
En dat is veel breder dan controleren of een chatbot ‘goed antwoordt’.
Testen van klassieke software en AI-testen zijn niet hetzelfde
Stel je een eenvoudige functie in een applicatie voor.
De gebruiker typt: 2 + 2
Het systeem zou moeten teruggeven: 4
Als het 5 teruggeeft, hebben we een eenduidige fout.
We kunnen een test maken: expect(calculate("2 + 2")).toBe(4)
en elke keer krijgen we een duidelijk resultaat: de test slaagt of faalt.
In AI-systemen ziet de situatie er anders uit.
De gebruiker kan vragen: „Schrijf een kort antwoord voor een klant die vraagt naar de levertijd van een bestelling.”
Het systeem kan verschillende antwoorden genereren. Allemaal kunnen taalkundig correct zijn. Allemaal kunnen professioneel klinken. Eén kan echter een onjuiste termijn bevatten, een andere kan te lang zijn, een derde kan een belangrijke informatie weglaten en een vierde kan perfect zijn.
Het is dus niet genoeg om te controleren of het antwoord technisch is gegenereerd.
Je moet controleren of het aan de vastgestelde kwaliteitscriteria voldoet.
Eerste probleem: een goed antwoord is niet altijd waar
Dat is een van de meest kenmerkende eigenschappen van generatieve AI.
Het model kan een antwoord genereren dat zeer overtuigend klinkt, maar geen dekking heeft in de brondata.
In het geval van een systeem dat RAG gebruikt, is het probleem nog interessanter. Het systeem kan een vraag krijgen, enkele fragmenten uit de documentatie opzoeken en vervolgens een antwoord genereren.
Dan moet je ten minste drie dingen controleren:
- Zijn de juiste informatie gevonden? Heeft het zoekmechanisme fragmenten opgehaald die daadwerkelijk met de vraag verband houden?
- Gebruikt het antwoord de gevonden informatie? Heeft het model iets toegevoegd dat niet in de bronnen stond?
- Beantwoordt het antwoord echt de vraag? Je kunt immers een correct werkende retrieval hebben, maar een slecht eindantwoord.
Juist daarom scheidt RAG-evaluatie onder meer aspecten als relevantie van de opgehaalde context, volledigheid van de zoekopdracht, juistheid van het antwoord en de overeenstemming met de bronnen.
Dat is een belangrijke verandering in hoe we naar testen kijken.
We testen niet meer alleen: vraag → antwoord
maar de hele keten: vraag → zoeken → context → model → antwoord
Je kunt een goed model hebben en een slecht AI-systeem
Dat is nog iets dat gemakkelijk te vergeten is.
Een bedrijf kan een zeer goed taalmodel kiezen en toch een zwak AI-product maken.
Waarom? Omdat de kwaliteit van het eind-systeem niet alleen van het model afhangt.
Ook belangrijk zijn:
- de kwaliteit van de data,
- de manier waarop de context wordt voorbereid,
- de prompt,
- de manier waarop informatie wordt opgezocht,
- de modelparameters,
- de tools die aan AI zijn gekoppeld,
- de logica van de applicatie,
- het geheugen,
- de manier waarop fouten worden afgehandeld,
- de beveiligingen,
- de manier waarop antwoorden worden beoordeeld.
Dat betekent dat de vraag: „Welk model is het beste?”
vaak minder bruikbaar is dan: „Welk model werkt het best in onze specifieke use case?”
Een model dat uitstekend is in het genereren van marketingteksten, hoeft niet de beste oplossing te zijn voor documentclassificatie, data-analyse of het ondersteunen van bedrijfsprocessen.
Daarom moet het vergelijken van modellen gebeuren op echte taken die het systeem moet uitvoeren.
Eerst moet je je eigen testset maken
Je kunt een AI-systeem niet zinvol beoordelen als je niet weet wat je ervan verwacht.
Daarom is een van de belangrijkste onderdelen van evaluatie het voorbereiden van een testdataset, oftewel een set echte of representatieve gevallen.
Een bedrijf bouwt bijvoorbeeld AI voor de klantenservice.
In plaats van na elke wijziging van de prompt handmatig één antwoord te controleren, kun je enkele honderden gevallen voorbereiden:
- eenvoudige vragen,
- dubbelzinnige vragen,
- vragen met verkeerde aannames,
- vragen die het opzoeken van een document vereisen,
- vragen over uitzonderingen,
- vragen over klachten,
- vragen die een weigering vereisen,
- vragen met gegevens die AI niet zou mogen onthullen.
Elke wijziging in het systeem kan vervolgens op dezelfde set worden uitgevoerd.
En juist hier begint AI op klassieke software te lijken.
We testen niet langer één enkel antwoord. We testen het gedrag van het systeem op de volledige set gevallen.
Ook prompts kun je testen
Een prompt wordt vaak gezien als tekst die iemand één keer heeft geschreven en vervolgens in productie heeft gelaten.
In werkelijkheid kan het een onderdeel van de applicatielogica zijn.
Een verandering van één zin kan leiden tot:
- een verbetering van het antwoord in één scenario,
- een verslechtering van het antwoord in een ander,
- meer neiging om te weigeren,
- meer hallucinaties,
- langere antwoorden,
- hogere kosten,
- meer tokenverbruik.
Daarom moet een prompt vergelijkbaar met code worden behandeld.
Als we de prompt wijzigen, is het de moeite waard om te weten:
- wat is verbeterd?
- wat is verslechterd?
- is er een regressie opgetreden?
Juist daarom wordt automatische evaluatie steeds belangrijker, en niet het handmatig beoordelen van een paar voorbeeldantwoorden.
AI kan de test doorstaan en toch een slecht product zijn
Stel dat we 100 testgevallen hebben voorbereid.
Het systeem antwoordde in 95 gevallen correct. Het resultaat ziet er geweldig uit. Maar wat als die vijf foutieve antwoorden kritieke situaties betreffen?
Als een chatbot vragen beantwoordt over openingstijden, kunnen vijf fouten problematisch zijn.
Als AI een medewerker helpt bij het analyseren van financiële, medische of juridische documenten, kan de betekenis van die fouten heel anders zijn.
Daarom is alleen het gemiddelde niet voldoende.
We hebben ook weging van gevallen nodig.
We kunnen aannemen dat:
- een gewone vraag weging 1 heeft,
- een belangrijke fout weging 5 heeft
- een beveiligingsfout heeft een gewicht van 10,
- het lekken van vertrouwelijke informatie heeft een gewicht van 100.
Dan krijgt het systeem niet „95 procent”. We krijgen een veel bruikbaarder beeld van het risico.
Niet alles is met één getal te meten
Dit is een van de belangrijkste problemen bij de evaluatie van AI.
We kunnen meerdere metrics hebben:
- Accuracy - is het antwoord correct?
- Relevance - beantwoordt het de vraag?
- Faithfulness / groundedness - is het gebaseerd op de aangeleverde bronnen?
- Context precision - zijn de opgehaalde fragmenten relevant?
- Context recall - heeft het systeem de benodigde informatie gevonden?
- Safety - voert het ongewenste acties uit?
- Latency - hoe lang wacht de gebruiker?
- Cost - hoeveel kost het uitvoeren van de taak?
RAG kan dus een zeer goede antwoordkwaliteit hebben, maar tegelijk enorme hoeveelheden context ophalen en een onaanvaardbare kost genereren.
Een ander systeem kan heel goedkoop en snel zijn, maar te veel fouten maken.
Er bestaat dus geen enkel universeel getal dat aangeeft of AI „goed” is. Kwaliteit moet worden gedefinieerd in de context van de specifieke toepassing.
En hoe zit het met AI beoordelen door andere AI?
Hier verschijnt nog een interessant mechanisme.
Een van de manieren om evaluatie te automatiseren is het model te gebruiken als rechter, dus LLM-as-a-judge.
Bijvoorbeeld:
Model A genereert een antwoord.
Model B krijgt de vraag, het antwoord en specifieke criteria.
Vervolgens beoordeelt het:
- juistheid,
- volgen van instructies,
- volledigheid,
- stijl,
- veiligheid.
Moderne evaluatietools maken het ook mogelijk om zulke beoordelingen te combineren met klassieke tekstvergelijkingen, eigen scripts of graders op basis van specifieke regels.
Dat vergroot de testschaal enorm. Maar dat betekent niet dat de mens niet meer nodig is. Ook het beoordelende model kan fouten maken. Daarom is het bij systemen met meer zakelijke relevantie verstandig om automatische evaluaties te combineren met periodieke expertbeoordeling.
Het grootste probleem: regressie
Stel je een systeem voor dat heel goed werkt. Het team vervangt het model door een nieuwere versie. De nieuwe versie is sneller en goedkoper. Het lijkt dus alsof alles in de goede richting gaat.
Na de implementatie blijkt echter dat:
- de antwoorden minder precies zijn,
- het model vaker weigert te antwoorden,
- het documentatie slechter gebruikt,
- instructies anders interpreteert,
- in sommige scenario's onjuiste informatie begint te geven.
Dat is precies AI-regressie.
In klassieke software kennen we regressie al jaren. Bij AI moeten we die ook opsporen, maar het probleem is moeilijker, omdat het gedrag van het systeem kan veranderen zonder een klassieke „fout”. Daarom moet elke grotere verandering worden vergeleken met de vorige versie.
Model.
Prompt.
Embedding.
Retriever.
Documentatie.
Logica van de agent.
Parameters.
Elk van deze elementen kan het resultaat beïnvloeden.
Een agent is niet voldoende te beoordelen op zijn eindantwoord
Nog moeilijker wordt het bij AI-agents.
Een klassieke chatbot kan één taak uitvoeren: vraag → antwoord.
Een agent kan heel anders werken: doel → plan → tool → resultaat → volgende stap → beslissing → actie → antwoord.
Als de agent het doel niet heeft bereikt, willen we niet alleen weten dat hij verloren heeft.
We willen weten: waar maakte hij een fout?
- Heeft hij de taak verkeerd begrepen?
- Heeft hij het verkeerde hulpmiddel gekozen?
- Heeft hij een verkeerde parameter doorgegeven?
- Heeft hij de verkeerde gegevens opgehaald?
- Heeft hij na het ontvangen van het resultaat een verkeerde beslissing genomen?
- Heeft hij te veel stappen gezet?
- Is hij te vroeg gestopt?
In onderzoek naar de evaluatie van agents analyseert men steeds vaker niet alleen het eindresultaat, maar ook het verloop van de werking, het gebruik van tools, planning, geheugen, betrouwbaarheid en veiligheid.
Dat betekent dat de toekomst van AI-testen voor een groot deel verband zal houden met de analyse van trace's, dus het volledige verloop van de werking van het systeem.
AI heeft iets nodig dat lijkt op CI/CD
Als AI deel uitmaakt van een product, kan het niet alleen vóór de eerste implementatie worden getest.
Het systeem zal veranderen.
Het model zal veranderen.
De prompt zal veranderen.
De kennisbank zal veranderen.
De manier van zoeken zal veranderen.
De configuratie zal veranderen.
Daarom moet evaluatie in het ontwikkelproces worden opgenomen.
Het schema kan er als volgt uitzien: wijziging → tests → evaluatie → vergelijking met vorige versie → beslissing over implementatie
Als de nieuwe versie de kwaliteit op één gebied verbetert, maar de vastgestelde foutdrempel in een ander gebied overschrijdt, kan de deployment worden gestopt.
Dat is een heel vergelijkbare filosofie als klassieke CI/CD, maar de criteria zijn anders.
Bij AI-applicaties kunnen we tegelijk de antwoordkwaliteit, juistheid, veiligheid, kost en vertraging controleren. Er zijn al onderzoeksoplossingen die evaluatie combineren met observability en quality gates in het implementatieproces van LLM/RAG-systemen.
Kun je AI dus op dezelfde manier testen als klassieke software?
Ja, maar slechts gedeeltelijk.
De klassieke aanpak blijft nodig.
We testen:
- API,
- integraties,
- machtigingen,
- datavalidatie,
- fouten,
- timeouts,
- beveiliging,
- prestaties,
- applicatielogica.
Maar daarmee kunnen we niet stoppen.
Er komt een tweede laag bij: evaluatie van het gedrag van AI.
- Is het antwoord correct?
- Is het in overeenstemming met de bronnen?
- Houdt het model zich aan de instructies?
- Gedraagt het systeem zich correct in onverwachte situaties?
- Kiest de agent de juiste tools?
- Heeft de nieuwe versie de kwaliteit niet verslechterd?
- Blijft de operationele kost aanvaardbaar?
- Krijgt de gebruiker daadwerkelijk waarde?
Dit is geen klassieke unittests meer.
De beste AI-test is niet altijd een laboratoriumtest
Er is nog een heel belangrijk element.
Een systeem kan het uitstekend doen op een voorbereide testset, en toch problemen hebben in de echte wereld. Daarom is het de moeite waard ook echte interacties te observeren. Niet om van elke gebruiker een tester te maken. Het gaat erom dat het systeem voortdurend kan worden verbeterd op basis van echte gevallen:
- waar gebruikers AI corrigeren,
- waar ze vragen om een antwoord opnieuw te geven,
- waar ze het gesprek onderbreken,
- waar ze de zaak escaleren naar een mens,
- waar de agent het doel niet bereikt,
- waar ongewone vragen opduiken.
Op deze manier ontstaat een doorlopende evaluatiecyclus: gebruiker → AI-actie → resultaat → analyse → nieuwe testcase → volgende versie van het systeem
Dat is een heel ander ontwikkelmodel dan een eenmalige „we hebben AI geïmplementeerd en het werkt”.
AI zou niet beoordeeld moeten worden met de vraag „werkt het?”
Dat is te weinig.
Beter zijn vragen als:
- Hoe vaak werkt het correct?
- In welke situaties maakt het fouten?
- Hoe ernstig zijn die fouten?
- Is de nieuwe versie beter dan de vorige?
- Is het systeem voldoende veilig?
- Zijn de antwoorden gebaseerd op de juiste gegevens?
- Hoeveel kost het om een specifiek resultaat te bereiken?
Pas zo'n set vragen maakt het mogelijk om over een volwassen AI-systeem te spreken.
De belangrijkste verandering in denken
Jarenlang gold in softwareontwikkeling een eenvoudige regel: code moet werken.
In AI-systemen moet die worden uitgebreid: het systeem moet goed, voorspelbaar en meetbaar werken.
Dat is een enorm verschil. Want AI is geen functie die altijd hetzelfde resultaat teruggeeft. Het is een probabilistisch systeem waarvan het gedrag afhangt van het model, de gegevens, de context, de instructies en de hele architectuur eromheen.
Daarom eindigt een professionele AI-implementatie niet op het moment dat het model begint te antwoorden.
Dan begint pas de vraag: hoe weten we dat we het kunnen vertrouwen?
En precies op die vraag zou een goed ontworpen evaluatie antwoord moeten geven.
In de toekomst zal het testen van AI-systemen waarschijnlijk net zo'n natuurlijk onderdeel van het ontwikkelproces worden als unit tests, integratietests of monitoring. Niet omdat AI „van nature onveilig” is. Gewoon omdat een systeem waarvan de output niet altijd deterministisch is, een andere manier van kwaliteitsmeting vereist.
En hoe meer AI zich ontwikkelt van het genereren van tekst naar het ondersteunen van echte processen, het gebruiken van gegevens, RAG en het uitvoeren van handelingen door agents, hoe belangrijker het wordt niet alleen de vraag „kan AI dit doen?” te stellen, maar ook: „kunnen we aantonen dat het dit goed genoeg doet?”
