AI-agentsllm benchmarksVerdieping

LLM-benchmarks uitgelegd: wat vertelt een score je?

5 november 20265 min leestijdDoor Albert Barth
Drie verschillende meetobjecten met een schuifmaat en schetsboek op een rustige werktafel
Conceptillustratie bij het beoordelen van benchmarks. Het beeld bevat geen meetresultaten.

Je ziet twee modellen met een score voor dezelfde benchmark. Het hoogste getal lijkt de beste keuze. Tot blijkt dat het ene model één poging kreeg en het andere meerdere, met extra gereedschap en een andere datasetversie.

LLM-benchmarks zijn afgesproken verzamelingen taken met een beoordelingsmethode. Ze helpen prestaties onderzoeken, zolang je ook bekijkt wat precies is gemeten. Een score is geen algemeen kwaliteitscijfer voor alles wat je met AI wilt doen.

Begin bij de taak die een benchmark meet

Een LLM is een groot taalmodel dat onder meer tekst kan verwerken en genereren. Een benchmark onderzoekt een gekozen vaardigheid met een vastgelegde meetmethode.

Een kennistest, een programmeeropgave en het oplossen van een fout in een bestaande applicatie vragen andere vaardigheden. Kijk eerst welke handeling het systeem moet verrichten. Daarna pas naar de rangorde.

Het oorspronkelijke SWE-bench-paper beschrijft bijvoorbeeld taken waarin een model een bestaande codebase moet aanpassen op basis van een softwareprobleem. Dat is een andere meetvraag dan een losse functie genereren. Je hoeft de historische modelscores uit dat paper niet te gebruiken om dit verschil te begrijpen.

Voor jouw toepassing telt vervolgens de aansluiting. Een agent die interne procedures uitlegt, moet juiste bronpassages vinden en toepassen. Een score voor wiskundige opgaven meet dat gedrag niet rechtstreeks. Gebruik algemene benchmarks om gerichter te onderzoeken, niet om de eigen taak over te slaan.

Lees dataset, versie en selectie samen

De dataset is de verzameling vragen of opdrachten. De versie bepaalt welke uitgave daarvan is gebruikt. Ook een selectie kan verschil maken: een volledige set, een gecontroleerde deelset of alleen taken die in een bepaalde omgeving uitvoerbaar waren.

Noteer daarom de volledige naam en versie, plus eventuele uitgesloten taken. Twee resultaten met hetzelfde korte benchmarklabel kunnen op andere opgaven gebaseerd zijn. Een later gepubliceerd resultaat hoeft ook niet op een recentere meetronde te berusten.

Ontbreekt deze informatie, houd dat zichtbaar als onbekend. Trek geen nauwkeurige conclusie uit een vergelijking waarvan de meetbasis niet vaststaat. Dat is vooral belangrijk bij historische overzichten: je kunt een nieuwere testversie niet stilzwijgend terugprojecteren op een eerder modelresultaat.

De harness en het budget horen bij het resultaat

De meetopstelling bepaalt welke instructies, tools en mogelijkheden het systeem krijgt. Mag het code uitvoeren, documenten opzoeken of een mislukte poging herstellen? Hoeveel tijd en modelaanroepen zijn beschikbaar? Bij een agent meet je mede hoe die voorzieningen samenwerken.

De SWE-bench-evaluatiegids beschrijft hoe patches worden toegepast en repositorytests worden uitgevoerd in een containeromgeving. Daarmee wordt duidelijk waarom alleen de modelnaam onvoldoende is om een uitslag te begrijpen.

Vergelijkbare omstandigheden kun je in een eenvoudige tabel vastleggen. Geef bijvoorbeeld per meting datasetversie, agent/harness, tools, poginglimiet en tijdslimiet. Staat bij één rij 'onbekend', vul dat niet aan op basis van wat dezelfde maker meestal gebruikt. Het gaat om deze specifieke meting.

Vraag wat de score eigenlijk telt

Een percentage opgeloste taken zegt iets anders dan een gemiddelde deelscore of de voorkeur van beoordelaars. Bij een taalantwoord kan de beoordeling van inhoud en stijl uit elkaar lopen. Een automatische test kan scherp zijn voor een technisch resultaat, maar een fout in de test kan een geldige oplossing afwijzen.

Let ook op het aantal pogingen. 'Minstens één geslaagde poging uit meerdere' beantwoordt een andere vraag dan 'de eerste poging slaagt'. Het eerste kan relevant zijn wanneer je uit voorstellen selecteert. Het voorspelt niet rechtstreeks hoe betrouwbaar één automatische uitvoering is.

Vraag daarom naar de definitie, de noemer en de afhandeling van mislukte runs. Kijk bij kleine verschillen ook naar variatie tussen uitvoeringen en de onzekerheid van de meting. Een extra decimaal maakt een onzekere uitslag niet nauwkeuriger.

Contaminatie: kende het model de toets al?

Een openbare testset kan terechtkomen in trainingsmateriaal. Dan kan een goede score deels samenhangen met herkenning van vragen of oplossingen. Dat noemen we datasetcontaminatie. Je kunt dit niet vaststellen of uitsluiten op basis van één hoog getal.

Hugging Face waarschuwt bij het gebruik van leaderboards voor contaminatie en voor beperkingen van vergelijkingen. Bekijk welke maatregelen een benchmarkmaker beschrijft, bijvoorbeeld hoe taken zijn verzameld en welke informatie openbaar is. Een niet-openbare testset kan sommige risico's verkleinen, maar maakt de hele meetmethode niet automatisch onafhankelijk.

Onze uitleg over Hugging Face introduceert het platform. Blijf bij iedere tabel de afzonderlijke benchmarkdocumentatie lezen: niet elke ranglijst op hetzelfde platform meet op dezelfde manier.

Onderscheid makerclaim en onafhankelijke meting

Een maker kan een zorgvuldig uitgevoerde meting publiceren. Een onafhankelijke evaluator kan eveneens een ongeschikte opstelling kiezen. De herkomst is dus een relevant kenmerk, geen automatisch oordeel over de kwaliteit.

Leg vast wie de meting uitvoerde, welke opstelling is beschreven en of resultaten opnieuw te onderzoeken zijn. 'Door de maker gerapporteerd' blijft die status houden wanneer een derde website het getal overneemt. Een verzamelsite wordt daardoor niet de uitvoerder van de test.

Scheid gemeten scores ook van schattingen. Een lege cel betekent dat de betreffende meting ontbreekt. Ze betekent niet nul punten. Wanneer twee bronnen andere omstandigheden gebruiken, kun je beide resultaten bespreken zonder ze in één ranglijst te dwingen.

Ontwerp een kleine proef voor je eigen werk

Stel dat je een model zoekt voor het uitleggen van interne werkinstructies. Verzamel representatieve vragen: een duidelijk antwoord, een uitzondering, een verouderde bron en een vraag waarop de documenten geen antwoord geven. Schrijf vooraf op welke passage het antwoord moet dragen en wanneer 'onbekend' juist is.

Geef kandidaten dezelfde bronversies, tools en uitvoeringsgrenzen. Beoordeel inhoud, brongebruik en correcte overdracht apart. Herhaal de vragen om variatie te zien en bewaar ook mislukte uitvoeringen. Dit is een proefontwerp, geen hier uitgevoerde vergelijking.

Bij coding agents kun je hetzelfde doen met een onderhoudstaak; de AI-codinggids geeft de basiscontext. Wil je zulke controles aan je ontwikkelwerkwijze koppelen, bekijk de cursus Claude Code voor gevorderden.

Zelf aan de slag met Vibe Coding?

Leer hoe je met AI-tools werkende apps bouwt. Onze praktische cursussen nemen je stap voor stap mee.

Blijf op de hoogte

Ontvang maandelijks de nieuwste tips over vibe coding, AI tools en exclusieve content.

In welke taal wil je door ons benaderd worden?