Modelkwaliteit per taak: één score zegt te weinig

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

Bij het selecteren van een taalmodel voor productieomgevingen baseren teams hun keuze nog te vaak op een enkel geaggregeerd getal op een publiek scorebord. Een model dat pronkt met een algemene score van 88% op brede academische testbatterijen lijkt op papier superieur aan een alternatief dat blijft steken op 79%. In de praktijk blijkt die rangorde echter regelmatig volledig om te draaien zodra beide modellen aan het werk worden gezet op een specifieke taak, zoals het extraheren van entiteiten uit Nederlandse juridische documenten of het genereren van strikt gevalideerde JSON-schema's.

Een samengestelde benchmarkscore veegt fundamenteel verschillende computervaardigheden op één hoop: feitelijke parate kennis, deductief redeneren, strakke instructievolgzaamheid, contextbehoud over tienduizenden tokens en taalspecifieke syntaxis. Wie een modelkeuze baseert op een algemeen gemiddelde, neemt een aanzienlijk architectonisch en financieel risico. Om tot een betrouwbare implementatie te komen, is een verschuiving noodzakelijk van algemene ranglijsten naar een taakgeoriënteerde meetopzet waarin elk kwaliteitscriterium afzonderlijk wordt gekwantificeerd en gewogen.

De valkuil van de samengestelde benchmarkscore

Publieke ranglijsten maken gebruik van brede meerkeuzetoetsen en gevarieerde academische vraagstukken om een gewogen gemiddelde te berekenen. Hoewel dit een nuttige macro-indicator vormt voor fundamenteel onderzoek en trainingsvoortgang, vertroebelt het de geschiktheid voor specifieke productietaken. Voor een dieper begrip van deze valkuilen helpt de gids over hoe je LLM-benchmarks leest en interpreteert om marketingclaims te scheiden van daadwerkelijke operationele betrouwbaarheid.

Wanneer een model een indrukwekkende totaalscore haalt door uitmuntend te presteren op Engelse wiskunderaadsels en feitelijke historische trivia, compenseert dat op de ranglijst moeiteloos voor matige prestaties op het gebied van strikte JSON-opmaak of subtiele grammaticale nuances in het Nederlands. Als jouw applicatie echter duizenden uren per maand klantvragen moet categoriseren zonder ooit een wiskundige vergelijking op te lossen, betaal je voor capaciteiten die je niet gebruikt, terwijl de kernfunctionaliteit ondermaats presteert.

Daarnaast kampen brede samengestelde benchmarks met aanzienlijke ruis door datacontaminatie. Omdat de testsets van bekende openbare benchmarks vaak onbedoeld of bewust in de trainingsdata van nieuwere modellen terechtkomen, weerspiegelt de hoge score eerder een getraind geheugen dan het vermogen om nieuwe, ongeziene productiedata correct te verwerken.

De anatomie van modelkwaliteit: vijf functionele dimensies

Om modelkwaliteit zinvol te beoordelen, moeten we de prestaties ontleden in orthogonale dimensies. Een model kan op de ene dimensie uitblinken terwijl het op de andere faalt. In productieomgevingen onderscheiden we vijf fundamentele pijlers:

Wanneer we deze dimensies isoleren, zien we regelmatig dat een compacter model van 8 miljard parameters op het gebied van formaattrouw en extractie net zo hoog scoort als een gigantisch frontier-model van honderden miljarden parameters, maar tegen een fractie van de latency en kosten. Om te bepalen welke modelarchitectuur fundamenteel aansluit bij een bepaalde use-case, biedt het overzicht op welk AI-model past bij welke taak een solide startpunt voor de initiële selectie.

Taakprofielen in de praktijk: extractie versus redeneren

De eisen die een taak stelt aan een model verschillen radicaal per toepassingsgebied. Laten we twee veelvoorkomende scenario's vergelijken: gestructureerde entiteitsextractie en meerstaps beleidsanalyse.

Bij gestructureerde data-extractie uit inkomende facturen of formulieren is de creatieve vrijheid van het model een nadeel. Het doel is een foutloze deterministische mapping van ongestructureerde tekst naar een vooraf gedefinieerd schema. Een model dat hierop wordt geëvalueerd, moet worden getoetst op eigenschappen zoals velddekking, precisie van datums en bedragen, en de afwezigheid van ongeldige JSON-karakters. Een brede MMLU-score zegt helemaal niets over de vraag of een model een datumformaat als DD-MM-YYYY consequent aanhoudt.

Bij complexe beleidsanalyse of juridische geschillenbeslechting draait het daarentegen om meervoudige logische deductie. Het model moet uitzonderingsclausules herkennen, temporele verbanden leggen en conflicterende voorwaarden tegen elkaar afwegen. Hier is het vermogen om een consistente redeneerketen vast te houden doorslaggevend. Een model dat perfect presteert op entiteitsextractie kan bij deze taak volledig vastlopen zodra er drie voorwaardelijke uitzonderingen tegelijk van kracht zijn.

Samengestelde systemen: waarom agents en RAG aparte metrieken eisen

Zodra een taalmodel wordt opgenomen in een samengestelde architectuur, zoals een autonome agent of een Retrieval-Augmented Generation (RAG) pijplijn, verliest een algemene modelscore definitief zijn betekenis. De prestaties van het totale systeem worden dan immers bepaald door de interactie tussen prompts, tussenstappen, externe tools en opzoekacties.

Bij een RAG-toepassing splitsen we de kwaliteitsmeting altijd op in twee afzonderlijke componenten: de context-precisie (heeft het zoeksysteem de juiste fragmenten opgehaald?) en de generatietrouw (bevat het gegenereerde antwoord uitsluitend feiten uit de opgehaalde fragmenten?). Een model kan een uitmuntende score halen op algemene kennis, maar in een RAG-context hopeloos falen doordat het zijn eigen vooraf getrainde kennis niet kan onderdrukken wanneer die botst met de aangeleverde context.

Bij autonome agents wordt dit nog complexer: daar meten we niet alleen het eindresultaat, maar het volledige actietraject. Om te begrijpen hoe tussenstappen, tool-selectie en foutcorrectie worden geanalyseerd, beschrijft het artikel over hoe je een AI-agent evalueert van taaksucces tot trajectanalyse de exacte meetmethodiek voor meervoudige beslislussen. Eén verkeerd gekozen API-parameter in stap twee zorgt ervoor dat een agent faalt, ongeacht hoe welbespraakt het model in isolatie is.

Het gevaar van promptgevoeligheid bij modelvergelijkingen

Een hardnekkige fout bij het vergelijken van modellen is het blindelings hergebruiken van één vaste prompt voor alle kandidaten. Modellen verschillen sterk in de stijl van instructies waarop ze optimaal reageren. Het ene model presteert maximaal bij beknopte, directe instructies in Markdown-opmaak, terwijl een ander model expliciete roltoekenning, XML-tags of few-shot voorbeelden nodig heeft om tot hetzelfde kwaliteitsniveau te komen.

Wanneer we Model A en Model B vergelijken op basis van de historische prompt die jarenlang is geoptimaliseerd voor Model A, meten we niet het inherente kwaliteitsverschil tussen de modellen. We meten voornamelijk hoe goed de prompt van Model A toevallig aansluit bij de interne representatie van Model B. Om dit effect te elimineren, is een systematische optimalisatiefase vereist. Raadpleeg het artikel over het A/B-testen van prompts voor betere resultaten om te zien hoe je promptvarianten wetenschappelijk zuiver tegen elkaar afzet voordat je een definitief oordeel velt over de capaciteiten van het onderliggende model.

De specifieke valkuilen van de Nederlandse taal

Voor Nederlandstalige productiesystemen introduceert taal een extra foutdimensie die in internationale benchmarks vrijwel geheel onzichtbaar blijft. Vrijwel alle toonaangevende openbare benchmarks zijn primair Engelstalig. Zelfs multilinguale benchmarks testen vaak oppervlakkige vertalingen van standaardvragen, waardoor typisch Nederlandse taalkundige eigenaardigheden buiten schot blijven.

In het Nederlands zien we drie specifieke faalmechanismen regelmatig optreden bij modellen met hoge algemene scores:

• Samenstellingen en spatiefouten: Het Nederlands voegt samenhangende zelfstandige naamwoorden aaneen (zoals kwaliteitsbeoordelingssysteem). Veel modellen introduceren onder invloed van hun Engelstalige dominantie onjuiste spaties (de zogeheten Engelse ziekte: kwaliteit beoordeling systeem), wat direct afbreuk doet aan de professionele uitstraling.
• Aanspreekvorm en register: Het consistente gebruik van de formele u-vorm versus de informele je/jij-vorm. Modellen wisselen vaak halverwege een complexe alinea ongemerkt tussen beide vormen, vooral wanneer er Engelse leenwoorden in de tekst voorkomen.
• Juridische en domeinspecifieke terminologie: Termen uit het Nederlandse bestuursrecht, fiscale wetgeving of medische richtlijnen hebben exacte betekenissen die door letterlijke vertaling vanuit het Engels volstrekt onbruikbaar worden.

Een model dat 90% scoort op een Engelstalige benchmark kan in een Nederlandse zakelijke context structureel zakken voor vormvereisten zodra vakinhoudelijke precisie vereist is.

Meetopzet: Een taakspecifieke benchmark inrichten

Wie modelkwaliteit serieus wil meten voor een concrete use-case, ontkomt niet aan een eigen reproduceerbare testset. Deze opzet garandeert dat de meting representatief is voor productie en beschermt tegen toevallige uitschieters.

Een betrouwbare testpijplijn omvat vier vaste parameters: een representatieve steekproef van minimaal 100 geanonimiseerde productiegevallen, een gefixeerde zaadwaarde (seed) waar mogelijk, een vaste temperatuur van 0.0 voor deterministische taken, en minimaal drie herhalingen per case om variantie in kaart te brengen. Om te berekenen hoeveel testgevallen statistisch noodzakelijk zijn om betrouwbare conclusies te trekken, biedt het artikel over statistiek voor LLM-evaluaties en steekproefgroottes de wiskundige onderbouwing voor betrouwbaarheidsintervallen.

# Voorbeeld van een taakspecifieke evaluatieloop in Python
import json
import statistics
from typing import List, Dict, Any

def evalueer_extractie_taak(
    test_set: List[Dict[str, Any]], 
    model_aanroep_fn, 
    herhalingen: int = 3
) -> Dict[str, float]:
    f1_scores = []
    schema_fouten = 0
    totaal_runs = len(test_set) * herhalingen

    for item in test_set:
        verwachte_velden = set(item["ground_truth"].keys())
        
        for _ in range(herhalingen):
            try:
                ruwe_uitvoer = model_aanroep_fn(item["input_tekst"])
                geparsede_json = json.loads(ruwe_uitvoer)
                
                gevonden_velden = set(geparsede_json.keys())
                tp = len(verwachte_velden & gevonden_velden)
                fp = len(gevonden_velden - verwachte_velden)
                fn = len(verwachte_velden - gevonden_velden)
                
                precisie = tp / (tp + fp) if (tp + fp) > 0 else 0.0
                recall = tp / (tp + fn) if (tp + fn) > 0 else 0.0
                f1 = (2 * precisie * recall) / (precisie + recall) if (precisie + recall) > 0 else 0.0
                f1_scores.append(f1)
                
            except json.JSONDecodeError:
                schema_fouten += 1
                f1_scores.append(0.0)

    return {
        "gemiddelde_f1": statistics.mean(f1_scores),
        "f1_standaarddeviatie": statistics.stdev(f1_scores) if len(f1_scores) > 1 else 0.0,
        "schema_fout_percentage": (schema_fouten / totaal_runs) * 100.0
    }

Bovenstaande code toont hoe we een model direct afrekenen op wat er in productie toe doet: kan het model consistente, parseerbare JSON genereren en isoleert het de exacte velden zonder hallucinaties? De standaarddeviatie toont direct de betrouwbaarheid: een model met een iets lagere gemiddelde score maar een standaarddeviatie van nul is in productie vaak oneindig veel waardevoller dan een model met een hoge piekprestatie dat in 5% van de gevallen crasht.

De balans tussen kwaliteit, latency en operationele kosten

Modelkwaliteit staat nooit op zichzelf; het is altijd een afweging tegen doorlooptijd en tokenkosten. Een model dat op een extractietaak 98% nauwkeurigheid behaalt maar 4 seconden per document nodig heeft en 3 cent per aanroep kost, is voor een real-time interactieve applicatie volstrekt ongeschikt als een compacter model 96% haalt in 250 milliseconden tegen een tiende van de prijs.

Door per use-case een acceptabele kwaliteitsdrempel (de zogeheten good enough grens) vast te stellen, ontstaat ruimte om drastisch te optimaliseren op operationele efficiency. Hoe je deze economische afweging systematisch doorrekent, lees je in het artikel over kosten per taak vergelijken tussen verschillende modellen. Kwaliteit wordt daarmee een meetbare randvoorwaarde binnen een breder engineeringkader in plaats van een abstract streven naar de hoogste score.

Van losse meetcijfers naar een gewogen besliskaart

Wanneer alle taakspecifieke metingen zijn uitgevoerd, rest de uitdaging om de verzamelde data te vertalen naar een definitief architectuurbesluit. Het presenteren van een onbewerkte tabel met tientallen losse metrics leidt in engineeringteams vaak tot verlamming door analyse. Er is een synthese nodig waarin metrics worden gewogen op basis van bedrijfsimpact.

In een gewogen besliskaart krijgt elke dimensie een wegingsfactor die aansluit bij het risicoprofiel van de taak. Bij een interne zoekassistent weegt latency wellicht zwaarder dan absolute exhaustiviteit, terwijl bij een geautomatiseerde factuurverwerker formaatvaliditeit en nultolerantie voor hallucinaties 80% van het totale gewicht opeisen. De methodiek om deze synthese vorm te geven wordt stap voor stap uitgelegd in de handleiding over evaluatieresultaten rapporteren van scoretabel naar besliskaart.

Door af te stappen van generieke publieke ranglijsten en structureel te investeren in taakspecifieke evaluatiesets, bouwen organisaties AI-systemen die voorspelbaar presteren, robuust blijven onder belasting en precies die kwaliteiten leveren waar de eindgebruiker om vraagt.