Wie professioneel met Large Language Models (LLM's) werkt, loopt al snel tegen een fundamenteel probleem aan: hoe weet je zeker of een nieuwe prompt, een nieuw model of een aangepaste generatie-architectuur daadwerkelijk beter is dan de vorige? In de praktijk zien we vaak dat ontwikkelaars tien of twintig testvragen door een model halen. Als de output er op het oog beter uitziet, wordt de wijziging direct doorgevoerd naar productie.
Deze aanpak is statistisch gezien bijzonder riskant. Taalmodellen zijn van nature non-deterministisch; ze produceren variabele output. Een kleine steekproef kan je daardoor volledig op het verkeerde been zetten. Een tijdelijke 'gelukstreffer' op een handjevol vragen wordt dan verward met een structurele verbetering. Om robuuste en betrouwbare AI-applicaties te bouwen, moeten we LLM-evaluaties benaderen als een statistisch proces. In dit artikel behandelen we de essentiële statistiek voor evaluaties in begrijpelijke taal: van het bepalen van de juiste steekproefgrootte tot het berekenen van betrouwbaarheidsintervallen en significantie.
Stel, je hebt een klantenservice-bot en je besluit de systeem-prompt aan te passen om de bot vriendelijker en feitelijker te maken. Je verzint vijftien typische klantvragen en test deze met de oude en de nieuwe prompt. De oude prompt beantwoordt er twaalf goed (80%). De nieuwe prompt beantwoordt er veertien goed (93%). Een duidelijke winnaar, toch?
Niet per se. Bij een steekproef van slechts vijftien vragen is het statistisch gezien heel goed mogelijk dat deze 'verbetering' puur op toeval berust. Als je de test morgen herhaalt met vijftien andere vragen, kan de oude prompt zomaar ineens beter presteren. Dit fenomeen noemen we ruis (noise). Hoe kleiner je testset, hoe groter de impact van ruis op je eindresultaat. Zonder voldoende data ben je in wezen aan het gokken met de kwaliteit van je applicatie. Zeker als je beslissingen over A/B-testen van prompts wilt automatiseren, is een solide statistische basis onmisbaar.
De behoefte aan statistiek komt voort uit variantie. Bij traditionele softwareontwikkeling is code deterministisch: als je tweemaal dezelfde input geeft, krijg je exact dezelfde output. Bij LLM's is dit, afhankelijk van de 'temperature'-instelling en de architectuur van de API, vaak niet het geval. Zelfs bij een temperature van 0 (wat zou moeten resulteren in de meest waarschijnlijke output) zien we door optimalisaties op GPU-niveau soms nog steeds subtiele verschillen in de gegenereerde tekst.
Daarnaast is de inputruimte oneindig. Gebruikers kunnen dezelfde vraag op duizend verschillende manieren stellen. Een model dat goed presteert op grammaticaal perfecte vragen, faalt misschien zodra de gebruiker spelfouten maakt. Jouw evaluatieset is slechts een klein venster op de oneindige realiteit. We gebruiken statistiek om in te schatten in hoeverre de prestaties binnen dit kleine testvenster generaliseren naar de echte wereld.
De meest gestelde vraag in LLM-evaluatie is: "Hoe groot moet mijn testset zijn?" Het eerlijke antwoord is dat dit afhangt van de zekerheid die je wilt hebben en hoe klein het verschil is dat je wilt kunnen aantonen. Toch is er een wiskundige manier om dit te berekenen.
Als we uitgaan van een binaire beoordeling (een LLM-antwoord is 'goed' of 'fout'), kunnen we de formule voor de steekproefgrootte van een proportie gebruiken. De basisformule (zonder correctie voor eindige populaties) ziet er als volgt uit:
Laten we deze variabelen in gewone taal ontleden:
Omdat niet iedereen continu formules wil invullen, hanteren we in de praktijk de volgende vuistregels voor de omvang van evaluatiesets:
Stel je hebt een benchmark-test uitgevoerd op 200 vragen en je nieuwe model haalt een score van 85% (170 van de 200 vragen correct). Betekent dit dat de werkelijke intelligentie van dit model op jouw taak exact 85% is? Nee. Die 85% is een zogenaamde puntschatting.
Een eerlijkere en veiligere manier om over modelprestaties te communiceren, is door middel van betrouwbaarheidsintervallen (Confidence Intervals of CI). Een betrouwbaarheidsinterval geeft een bandbreedte aan waarbinnen de 'echte' prestatie van het model op de gehele populatie van mogelijke vragen met een bepaalde zekerheid valt.
Voor ons voorbeeld van 85% op 200 vragen, ligt het 95% betrouwbaarheidsinterval (berekend via de standaardfout van een proportie) ongeveer tussen de 80% en 90%. Dit betekent dat we er voor 95% zeker van kunnen zijn dat, als we het model op tienduizend of een miljoen soortgelijke vragen zouden testen, het uiteindelijke succespercentage ergens tussen de 80% en 90% zal uitkomen.
Dit inzicht verandert de manier waarop je naar benchmarks kijkt. Als Model A 84% scoort en Model B 86% op een testset van 200 vragen, overlappen hun betrouwbaarheidsintervallen enorm. Je kunt op basis van deze test simpelweg niet beweren dat Model B superieur is. Ze zijn statistisch gezien gelijkwaardig. Voor een diepgaande gids over hoe je kaders opzet voor robuuste evaluatie, raden we aan te kijken naar de methodologieën op bouw-frameworks voor evaluatie.
Wanneer we de prestaties van twee modellen, of twee verschillende prompts, met elkaar vergelijken, willen we weten of het verschil in nauwkeurigheid statistisch significant is. Significantie betekent dat de kans heel klein is (meestal kleiner dan 5%) dat het waargenomen verschil puur door toeval (ruis) is ontstaan.
Bij het evalueren van LLM's testen we vrijwel altijd gepaard (paired testing). Dit betekent dat we Model A en Model B op exact dezelfde set van testvragen loslaten. Omdat de testcases niet onafhankelijk zijn (een heel moeilijke vraag zal door beide modellen waarschijnlijk fout worden beantwoord), mogen we geen standaard ongepaarde t-toets gebruiken. De juiste statistische toets voor het vergelijken van binaire uitkomsten op dezelfde testset is de McNemar-toets.
De McNemar-toets kijkt specifiek naar de vragen waar de modellen het oneens zijn. Als Model A en Model B allebei 150 vragen goed hebben en 20 vragen fout, leveren die 170 vragen geen informatie op over welk model beter is. De toets concentreert zich op de overige 30 vragen: de gevallen waar Model A het goed had en B fout, versus de gevallen waar B het goed had en A fout.
Je hebt een testset van 300 vragen. Je test een basis-prompt (Model A) tegen een geavanceerde Chain-of-Thought prompt (Model B). We sorteren de resultaten in een matrix:
| Model B: Fout | Model B: Goed | |
|---|---|---|
| Model A: Fout | 40 (Beide fout) | 45 (B won) |
| Model A: Goed | 15 (A won) | 200 (Beide goed) |
Op het eerste gezicht ging Model A van 215/300 (71,6%) naar Model B met 245/300 (81,6%). Een stijging van 10 procentpunt. Maar is dit significant? We kijken naar de discrepanties. Model B won 45 keer waar A faalde. Model A won 15 keer waar B faalde.
Zonder al te diep op de formule in te gaan: de p-waarde (de kans dat dit verschil op toeval berust) die hieruit rolt is extreem laag (p < 0,001). Omdat de p-waarde veel kleiner is dan onze drempel van 0,05 (5%), kunnen we met grote zekerheid stellen dat het verschil statistisch significant is. De Chain-of-Thought prompt is daadwerkelijk een verbetering, en geen toevalstreffer.
Een extra complicatie bij moderne evaluaties is dat we steeds vaker gebruikmaken van een ander LLM (vaak GPT-4 of Claude 3.5 Opus) om de antwoorden van onze modellen te beoordelen. Dit wordt LLM-as-a-judge genoemd. Dit lost het probleem van handmatig nakijken op, maar introduceert een nieuwe laag van variantie en mogelijke bias.
De beoordelaar-LLM is zelf ook niet 100% accuraat of consistent. Soms beoordeelt de 'judge' een antwoord vandaag als perfect, en datzelfde antwoord morgen als matig. Deze extra ruis betekent dat je betrouwbaarheidsintervallen nog breder worden. Als je werkt met geautomatiseerde evaluatoren, moet je er rekening mee houden dat een kleine winst (bijvoorbeeld +2%) volledig tenietgedaan kan worden door de foutmarge van de judge zelf. Het streven naar absolute reproduceerbaarheid in je evaluatiepijplijn (bijvoorbeeld door temperature op 0 te zetten en scores te middelen over meerdere beoordelingen) is cruciaal om deze variantie in toom te houden.
Om te voorkomen dat je verdwaalt in de wiskunde, kun je deze praktische vuistregels hanteren bij het bouwen van je evaluatie-infrastructuur:
Statistiek is geen overbodige luxe in het tijdperk van generatieve AI; het is je enige verdedigingslinie tegen de chaos van non-deterministische modellen. Door te werken met vaste betrouwbaarheidsintervallen, robuuste steekproefgroottes (richting de 400+ voor belangrijke beslissingen) en significantietoetsen zoals McNemar, transformeer je LLM-evaluatie van een subjectieve "vibe check" naar een harde, kwantificeerbare wetenschap.