Wanneer u twee modellen vergelijkt, is de eerste reflex een leaderboard openen en de scores bekijken. MMLU, HumanEval, GSM8K — de cijfers zien er objectief en vergelijkbaar uit. Het probleem is dat frontier-modellen vandaag op MMLU 88–94% halen, en in dit bereik zijn de onderlinge verschillen waarschijnlijk meetruis in plaats van een echt prestatieverschil. Een benchmark die modellen niet meer betrouwbaar van elkaar kan onderscheiden, heeft de titel "gesatureerd" verdiend — en een gesatureerde benchmark vertelt u over uw concrete use-case vrijwel niets.
Dit artikel legt uit waarom benchmarks liegen (of op z'n minst misleiden), welke concrete mechanismen daarachter zitten, en wat u beter kunt doen dan blindelings een leaderboard lezen. Aan het einde krijgt u het praktische kader dat wij gebruiken bij modelkeuze voor klanten.
Waarom MMLU gesatureerd is en wat dat betekent
MMLU (Massive Multitask Language Understanding) was bij zijn introductie een genuïne nuttige tool — het besloeg 57 domeinen van wiskunde tot recht en geneeskunde, en de eerste modellen scoorden ergens rond de 50–60%. Dat klopte: de benchmark was moeilijker dan willekeurig raden, maar niet onoverkomelijk.
Vandaag is de situatie anders. Wanneer alle vergeleken modellen in het bereik van 88–94% vallen, ontstaan er meerdere problemen tegelijk:
- De verschillen zitten binnen de statistische onzekerheid. Een verschil van 1–2 procentpunten op een gangbare testset kan een artefact zijn van promptformulering, de volgorde van de antwoordopties of simpelweg variabiliteit in de generatie.
- De formulering van de prompt verandert het resultaat. Onderzoek laat keer op keer zien dat hetzelfde model ±5–10 procentpunten anders kan scoren enkel door de manier waarop de vraag wordt gesteld. Dat is geen fout van een specifiek model — het is een eigenschap van alle taalmodellen.
- De benchmark meet niet wat u nodig hebt. MMLU test kennis in een multiple-choice-formaat. Uw applicatie genereert waarschijnlijk langere tekst, roept tools aan, werkt met context of opereert in een specifieke taal. Dat zijn volledig andere taken.
Contaminatie van trainingsdata — de stille bron van opgeblazen scores
Een van de minst openlijk besproken problemen bij benchmarking is contaminatie (data contamination). Wanneer de testdata van een benchmark opduiken in de trainingsdata van het model — wat bij modellen getraind op een groot deel van het internet een reëel risico is — "onthoudt" het model feitelijk de juiste antwoorden in plaats van de stof te begrijpen.
Detectie van contaminatie is lastig. De meeste modelaanbieders onderhouden geen publiek beschikbare audit van trainingsdata. Sommigen publiceren interne resultaten van decontaminatietests, anderen niet. Het gevolg is dat u bij het vergelijken van twee modellen op MMLU niet zeker weet of u kijkt naar een echt verschil in capaciteit, of naar een verschil in het aantal testvragen dat in de trainingsdata is verschenen.
Praktische conclusie: geef bij modelkeuze altijd de voorkeur aan benchmarks met dynamisch gegenereerde of niet-publiek beschikbare testsets. Nieuwere sets — zoals LiveBench of MMLU-Pro — proberen dit probleem aan te pakken via regelmatige updates en een grotere nadruk op redeneren in plaats van memoriseren.
Overfitting op het leaderboard als kerprobleem
Er bestaat ook een minder onschuldige versie van hetzelfde probleem: gerichte optimalisatie op specifieke benchmarks. Wanneer modelaanbieders weten dat de markt vergelijkt op MMLU, HumanEval en GSM8K, ontstaat een sterke economische prikkel om modellen juist op die sets te trainen (of te verfijnen).
Dit is niet per se fraude — het kan een gevolg zijn van de keuze van trainingsdata, de manier van instruction-tuning of RLHF-rewardmodellen. Het resultaat is echter hetzelfde: een model dat er geweldig uitziet op het leaderboard kan beduidend slechter zijn op reële taken die de benchmark niet dekt.
We hebben dit in de praktijk gezien bij projecten met industriële documentatie: een model dat won in de coding-benchmark kon niet betrouwbaar gestructureerde data extraheren uit technische PDF's. Een ander model, met een lager totaalscore, bleek op diezelfde taak duidelijk beter — omdat zijn trainingsdata waarschijnlijk meer technische tekst in het relevante formaat bevatte.
Waarom leaderboard-rangorde niet correleert met productiegedrag
Een aggregatieve leaderboard-score is als de gemiddelde temperatuur in een stad: informatief op een heel grof niveau, maar onbruikbaar bij het kiezen van kleding voor een specifieke dag. Enkele redenen waarom de rangorde van een model op een leaderboard niet hoeft te correleren met de prestaties in productie:
Domeinspecificiteit. Algemene benchmarks testen het gemiddelde over tientallen domeinen. Uw use-case is één concreet domein — productiedocumentatie, juridische contracten, klantenservice in het Nederlands. Een model dat gemiddeld sterk is, kan juist zwak zijn in uw specifieke domein.
Taaldegradatie. De meeste benchmarks zijn Engelstalig. Nederlands is weliswaar geen low-resource taal, maar voor talen als Slowaaks of andere Centraal-Europese talen geldt dat modellen er beduidend meer op degraderen dan op Engels — en die degradatie is in een Engelstalig leaderboard helemaal niet zichtbaar. Test altijd apart in de doeltaal. Praktijkervaring: een model dat in het Engels de vergelijking won, kon in de doeltaal derde of vierde eindigen in dezelfde test.
Invoer- en uitvoerformaat. Benchmarks testen doorgaans korte vragen met korte antwoorden. Productieapplicaties werken met lange context, tool calls, het genereren van gestructureerd JSON of multi-turn-gesprekken. Dat zijn andere taken met andere modelvereisten.
Latency en kosten. Leaderboards meten kwaliteit, niet snelheid of prijs. Het model met de hoogste score kan 5× duurder en 3× trager zijn dan een model met een 2% lager score — wat in een productieomgeving doorslaggevend kan zijn. Wilt u een diepgaander overzicht van modelkeuze met aandacht voor deze factoren, lees dan Hoe kiest u een LLM-model in 2026.
Een eigen eval is altijd belangrijker dan een leaderboard
Uit het bovenstaande volgt een heldere conclusie: er bestaat geen externe benchmark die u vertelt welk model het juiste is voor uw use-case. De enige betrouwbare bron van waarheid is een eigen eval, gebouwd op uw data, uw criteria en uw taal.
Hoe doet u dat in de praktijk:
- 1.Verzamel echte invoer vanaf dag één. Log elke vraag en elk antwoord (met anonimisering van PII). Dit is de goudmijn van uw testgevallen.
- 2.Definieer kwaliteitscriteria voor uw specifieke taak. Wat is een "goed antwoord" in uw geval? Feitelijke correctheid? Naleving van het formaat? Afwezigheid van gehallucineerde cijfers? Elke applicatie heeft andere criteria.
- 3.Stel een eval-set samen uit echte gevallen. Minimaal 50–100 voorbeelden, ideaal 200–500. Dek zowel gangbare gevallen als edge cases. Annoteer de verwachte antwoorden of op z'n minst de criteria.
- 4.Automatiseer de beoordeling via `LLM-as-a-judge`. Een sterker model (of een gespecialiseerde eval-prompt) beoordeelt de uitvoer van het geteste model aan de hand van uw criteria. Dit is vandaag gangbare productiepraktijk. Het artikel Hoe meet u de kwaliteit van een LLM-applicatie gaat hier uitgebreider op in.
- 5.Draai de eval vóór elke grotere wijziging. Een modelwissel, een aanpassing van de prompt, een wijziging in de retrievalstrategie — elk ervan kan de kwaliteit onverwacht doen dalen. Zonder regressietests merkt u het pas van de klant.
Tools als Langfuse (open-source, self-hostbaar) of Promptfoo (open-source, CI/CD-integratie) verlagen de drempel voor het invoeren van een eval-proces aanzienlijk. Het zijn geen uitsluitend enterprise-tools — u zet ze ook in kleine teams op.
Benchmarks constructief lezen
Ondanks alle bezwaren is het niet juist om benchmarks volledig te negeren. Ze hebben nut in specifieke contexten:
Grofmazig voorfilteren van kandidaten. Als u tientallen modellen vergelijkt en de selectie wilt terugbrengen naar 3–5 finalisten, is een leaderboard een legitiem eerste filter. Gebruik het niet voor de eindbeslissing, maar wel voor het elimineren van evident zwakke modellen.
Benchmark kiezen op basis van de taak. Niet alle benchmarks zijn even misleidend. Zoek die welke het dichtst bij uw use-case liggen:
- Voor codegeneratie: HumanEval, MBPP, SWE-bench
- Voor wiskundig redeneren: MATH, GSM8K
- Voor lange context: RULER, HELMET
- Voor instructieopvolging: IFEval
- Voor algemeen redeneren: MMLU-Pro (moeilijkere variant, minder gesatureerd)
Dynamische leaderboards. Platforms zoals ArtificialAnalysis aggregeren meerdere dimensies tegelijk — kwaliteit, latency, prijs, context window. Dat geeft een veel realistischer beeld dan een MMLU-score alleen.
Vergelijk onder gelijke omstandigheden. Als u twee modellen zelf evalueert, gebruik dan identieke prompts, identieke temperature en idealiter hetzelfde eval-framework. Elk verschil in condities vervuilt het resultaat.
Speciaal geval: laagresource-talen en gereguleerde domeinen
Voor applicaties in laagresource-talen — zoals Slowaaks, maar ook sommige andere Centraal-Europese talen — geldt één eenvoudige regel: vertrouw nooit een Engelstalige benchmark zonder verificatie in de doeltaal. Modellen degraderen op dit soort talen beduidend meer dan op Engels. Die degradatie verschijnt helemaal niet in gangbare leaderboards, omdat de meeste benchmarks Engelstalig zijn.
Praktische werkwijze: neem de 2–3 finalisten die u op basis van het leaderboard hebt geselecteerd en draai een eigen eval in de doeltaal op uw echte data. De rangorde kan veranderen.
Voor gereguleerde domeinen — recht, geneeskunde, farmacie, financieel advies — geldt een nog sterker voorbehoud: een benchmark-score uit algemene domeinen zegt niets over hoe goed het model juridische clausules, medische afkortingen of regulatoire tekst beheerst. Dit gat is de reden waarom het in gereguleerde sectoren de moeite waard is om fine-tuning op domeindata te overwegen — wat we uitgebreider bespreken in het artikel RAG vs. fine-tuning — wanneer welke aanpak.
Rode vlaggen bij het lezen van benchmark-claims
Wanneer u benchmarkresultaten tegenkomt in de presentatie van een aanbieder of in een PR-artikel, zoek dan naar deze waarschuwingssignalen:
- Benchmark zonder meetdatum. Modellen worden bijgewerkt, benchmarks veranderen — een cijfer zonder datum kan maanden verouderd zijn.
- Selectieve keuze van benchmarks. Als een aanbieder 5 benchmarks noemt waarop hij wint en de overige niet vermeldt, is dat selectiebias.
- Ontbrekende informatie over prompting. "Few-shot" vs. "zero-shot", chain-of-thought vs. direct antwoord — elk ervan kan het resultaat met enkele procenten veranderen. Zonder die informatie zijn de cijfers niet vergelijkbaar.
- Vergelijking met benchmarks van een andere leeftijd. Een nieuw model vergelijken met twee jaar oude concurrenten is legitieme marketing, maar geen objectieve vergelijking.
- Een benchmark die het model waarschijnlijk in training heeft gezien. Hoe ouder en populairder de benchmark (zoals MMLU), hoe groter de kans op contaminatie.
Veelgestelde vragen
Betekent een hogere MMLU-score een beter model voor mijn bedrijf?
Niet noodzakelijk. MMLU is een gesatureerde benchmark — de verschillen tussen frontier-modellen in het bereik van 88–94% zitten op de grens van de statistische onzekerheid. Voor uw specifieke use-case is alleen de score relevant op taken die vergelijkbaar zijn met de uwe, in de taal van uw inzet. Een eigen eval op echte data is een betrouwbaardere indicator dan welk algemeen leaderboard ook.
Kan ik een benchmark vertrouwen als die door de modelaanbieder zelf is gepubliceerd?
Met enig voorbehoud. Aanbieders hebben een legitiem belang om hun model zo goed mogelijk te presenteren, wat kan leiden tot een selectieve keuze van benchmarks of gunstiger testomstandigheden. Dat betekent niet dat de cijfers verzonnen zijn — maar zoek altijd naar onafhankelijke reproducties, bijvoorbeeld op platforms als ArtificialAnalysis, of draai uw eigen vergelijking.
Wat is contaminatie van trainingsdata en waarom is het een probleem?
Contaminatie treedt op wanneer de testvragen van een benchmark opduiken in de trainingsdata van het model. Het model "onthoudt" dan de juiste antwoorden in plaats van ze af te leiden uit begrip. Het gevolg is een opgeblazen benchmark-score die niet overeenkomt met de werkelijke capaciteiten. Detectie is lastig omdat de meeste aanbieders de exacte samenstelling van hun trainingsdata niet openbaar maken.
Hoe snel kan ik een eerste eigen eval opzetten?
Voor een eerste eval volstaan 50–100 echte voorbeelden uit uw applicatie met geannoteerde verwachte uitvoer of kwaliteitscriteria. Tools als Promptfoo of Langfuse maken het mogelijk de eerste geautomatiseerde beoordeling binnen dagen op te zetten, niet weken. Het belangrijkste is klein te beginnen en te itereren — niet wachten op een "perfecte" set.
Verandert de rangorde van modellen tussen versies?
Ja, aanzienlijk en onvoorspelbaar. Een modelupdate (ook bij behoud van dezelfde naam) kan de prestaties op verschillende taken in verschillende richtingen veranderen. Daarom is een eval ingericht als regressietest — niet als eenmalige vergelijking — cruciaal voor productieomgevingen. Elke grotere wijziging (nieuwe modelversie, nieuwe prompt, nieuw retrievalsysteem) moet worden geverifieerd op dezelfde eval-set.
*Wij helpen bedrijven een eval-proces op te zetten dat in productie werkt — van de selectie van testgevallen tot geautomatiseerde beoordeling en integratie in de CI/CD-pipeline. Weet u niet waar u moet beginnen, dan kijken we graag mee naar uw concrete use-case.*