27 okt 2026 LLM-evaluatie: zo test je AI-antwoorden die nooit twee keer hetzelfde zijn

In het kort: Met LLM-evaluatie test je een applicatie waar een taalmodel in zit. De antwoorden zijn elke keer anders, dus je controleert geen exacte tekst. Je bouwt een vaste set echte vragen, beoordeelt elk antwoord op duidelijke criteria, stelt elke vraag een paar keer en spreekt een drempel af. Mensen blijven de scores controleren.

Is je AI-assistent één keer door de test gekomen, dan weet je nog weinig. Stel morgen dezelfde vraag en je krijgt misschien een ander antwoord, soms een fout antwoord. Daarom vraagt een applicatie met een groot taalmodel erin om een eigen manier van testen. Een groot taalmodel (LLM, large language model) is het soort AI achter tools als ChatGPT: het schrijft antwoorden woord voor woord. LLM-evaluatie is de methode om die antwoorden te testen. En die lijkt meer op gewoon testen dan veel teams denken.

Waarom werkt gewoon goed/fout-testen niet bij een LLM?

Goed/fout-testen werkt niet bij een LLM, omdat dezelfde vraag niet hetzelfde antwoord geeft. Een klassieke test vergelijkt de uitkomst met de verwachte uitkomst. Komen ze overeen, dan slaagt de test. Een taalmodel formuleert zijn antwoord elke keer anders, ook als de inhoud gelijk blijft. Een exacte vergelijking keurt dus onschuldige verschillen in woordkeus af. Erger nog: een antwoord kan goed klinken en toch fout zijn. Er staat een verzonnen getal in, een oud beleid of een belofte die het bedrijf niet kan waarmaken. Daarom test je twee dingen. Voldoet elk antwoord aan de criteria die je hebt afgesproken? En hoeveel verschillen de antwoorden als je dezelfde vraag opnieuw stelt? Software met AI erin vraagt om die andere aanpak, omdat een simpel goed of fout niet genoeg is. Daar weten we mee om te gaan, en hieronder lees je hoe.

Dit vervangt gewone tests niet. De schermen, het inloggen en de koppelingen met andere systemen test je nog steeds op de normale manier. LLM-evaluatie dekt het deel dat de antwoorden schrijft.

Hoe bouw je een evaluatieset?

Een evaluatieset is een vaste lijst vragen met per vraag wat een goed antwoord moet bevatten en wat het nooit mag doen. Het is de LLM-versie van een regressieset. De beste vragen komen uit echt gebruik: supporttickets, chatlogs uit een pilot en de vragen die collega’s uit de business elke week horen. Voeg er bewust lastige gevallen aan toe. Denk aan vage vragen, vragen met een typfout, vragen die de AI moet weigeren en vragen die hij moet doorzetten naar een mens.

Schrijf per vraag korte criteria op. De tabel laat het idee zien voor een webshopassistent.

De OWASP Top 10 for LLM Applications helpt je de kolom “mag nooit” te vullen. Die lijst noemt risico’s zoals het lekken van gevoelige gegevens en het verspreiden van foute informatie. Beheer de set in versiebeheer, net als testcode. En vindt iemand een slecht antwoord, voeg die vraag dan toe aan de set. Een paar dozijn echte vragen zijn een betere start dan duizend gegenereerde.

Hoe beoordeel je antwoorden die steeds veranderen?

Je beoordeelt antwoorden per criterium, over meerdere runs, tegen een drempel die je vooraf afspreekt. Per criterium betekent: geen totaalcijfer. Je kijkt apart of het antwoord klopt, gebaseerd is op je eigen bronnen, veilig is, het bedrijfsbeleid volgt en de juiste toon heeft. Meerdere runs betekent dat je elke vraag vaker stelt, bijvoorbeeld vijf keer. Daarna kijk je naar het slechtste antwoord, niet alleen naar het gemiddelde. Een klant die dat ene slechte antwoord krijgt, heeft niets aan de vier goede. Een drempel betekent dat je vooraf bepaalt wat goed genoeg is. Bijvoorbeeld: elk “mag nooit”-criterium slaagt in elke run, zonder uitzondering.

Met de hand beoordelen schaalt niet, dus veel teams zetten een tweede model in als beoordelaar. Dat heet LLM-as-a-judge. Het is snel, maar het heeft blinde vlekken. Onderzoek van Zheng en anderen liet zien dat zo’n beoordelaar langere antwoorden kan voortrekken, en het antwoord dat hij als eerste ziet. Mensen blijven dus betrokken. Een tester controleert een steekproef van de scores en elk geval waarin de beoordelaar twijfelt. AI helpt met het volume, mensen houden het oordeel.

Eén kanttekening: evaluatie bewijst niet dat een AI altijd gelijk heeft. Het laat zien hoe vaak het misgaat, en waar. Voor een intern hulpmiddel met weinig risico kan een kleine set genoeg zijn. Voor een assistent die met klanten praat niet.

Wanneer draai je de evaluatie opnieuw?

Draai de evaluatie opnieuw na elke wijziging die de antwoorden kan raken, en voor elke release. Denk aan een nieuwe prompt, een nieuwe modelversie van je leverancier, andere instellingen en nieuwe brondocumenten. Leveranciers werken hun modellen vaker bij dan de meeste teams merken, dus houd daar rekening mee. Behandel de set als een regressietest: hij draait automatisch, en zakt de score onder de drempel, dan gaat de release niet door.

Na livegang verhuist het testen naar productie. Echte gebruikers stellen vragen waar niemand aan dacht. Je blijft de antwoorden dus volgen met AI testen na livegang, en nieuwe vragen gaan in je set. Ook het Generative AI Profile van NIST ziet testen en evalueren als doorlopend werk, niet als eenmalige check. Evaluatie is de ene helft van AI testen: de AI zelf testen, naast testen met AI-tools.

Wat betekent dit voor je team?

De eerste evaluatieset bouwen is het makkelijke deel. Het lastige deel komt daarna. De set moet meegroeien met elk nieuw soort vraag, draaien na elke wijziging en uitkomsten geven die mensen buiten het team kunnen lezen. Een product owner wil weten of de nieuwe prompt beter is. Een compliance officer wil weten welke fouten de wet raken. In veel teams ligt dat werk bij één developer, naast zijn eigenlijke werk.

Onze eigen tool VeritasAI is gebouwd voor dat doorlopende werk, en we gebruiken hem om AI testen als dienst te leveren. Hij test je AI-toepassing met echte vragen, en blijft dat doen. Een operationeel dashboard laat zien op welke vragen de toepassing faalt. Bij elke fout zie je aan welke wet, regel of welk framework hij raakt, met de prompt, het antwoord en een prioriteitsscore. Een managementdashboard geeft het overzicht.

Deze week al beginnen? Verzamel twintig echte vragen van je gebruikers en schrijf per vraag op wat een goed antwoord moet bevatten. Met die lijst is je evaluatieset begonnen.

Veelgestelde vragen

Wat is het verschil tussen LLM-evaluatie en gewoon software testen?

Gewoon testen controleert op één verwachte uitkomst. LLM-evaluatie controleert of wisselende antwoorden over meerdere runs aan afgesproken criteria voldoen. De rest van de applicatie test je nog steeds op de normale manier.

Hoeveel vragen heeft een evaluatieset nodig?

Begin met een paar dozijn echte vragen die je belangrijkste taken en risico’s dekken. Laat de set groeien met elk slecht antwoord dat je vindt. Kwaliteit en variatie tellen meer dan omvang.

Kun je een LLM als beoordelaar vertrouwen?

Deels. Een beoordelend model is handig om veel antwoorden snel te scoren. Het heeft bekende vooroordelen, dus laat een mens een steekproef en elk twijfelgeval controleren.

Wanneer draai je een LLM-evaluatie opnieuw?

Na elke wijziging aan de prompt, het model, de instellingen of de brondata, en voor elke release. Na livegang komt daar het volgen van echte antwoorden bij.