Voorbij de benchmark: welk taalmodel werkt voor jouw taak?

Wat een benchmark wel en niet vertelt

Een benchmark is een afgesproken verzameling taken met een beoordelingsmethode. Dat maakt resultaten onder vergelijkbare omstandigheden herhaalbaar. Maar een verzameling kennisvragen meet iets anders dan het correct overnemen van bedragen uit jouw facturen, en Engelstalige tests beantwoorden niet vanzelf je vraag over Nederlandse vaktaal.

Lees daarom naast de score ook de taak, taal, promptopzet en modelvariant. Waren hulpmiddelen toegestaan? Kreeg het model voorbeelden mee? Is de geteste variant dezelfde als de gequantiseerde versie die jij kunt draaien? Ontbreken zulke details, behandel de score dan als een indicatie voor een eerste selectie, niet als een voorspelling voor je eigen toepassing.

Het HELM-onderzoek van Stanford laat zien waarom één getal te beperkt is: de evaluatie kijkt naast nauwkeurigheid naar andere eigenschappen en maakt zichtbaar dat de manier van prompten uitkomsten beïnvloedt. Dat is een methodologisch uitgangspunt, geen actuele ranglijst van de beste modellen. [1]

Twee bekende voorbeelden: MMLU toetst kennis en probleemoplossing over 57 onderwerpen; GSM8K bestaat uit rekenvraagstukken in tekstvorm. [4] [5] Een hoge score op de eerste maakt een model nog geen betrouwbare documentassistent, en de tweede is geen controle van jouw factuurverwerking. Kijk ook of een modelkaart de oorspronkelijke benchmark of een gewijzigde variant rapporteert.

Een goede score is bovendien geen bewijs dat een model onbekende praktijkgevallen aankan. De testverdeling kan afwijken van jouw werk, en mogelijke overlap tussen trainingsmateriaal en openbare testvragen is een reden om ook eigen, niet-openbare voorbeelden te gebruiken.

Begin met een beslissing die je kunt toetsen

“Welk model is het beste?” is te breed. “Welk model zet mijn notities om in een taaklijst zonder deadlines te verzinnen?” is toetsbaar. Voor een bedrijf kan dat zijn: “Kunnen we supportberichten sneller routeren zonder urgente meldingen vaker te missen?”

Maak vóór het testen onderscheid tussen harde eisen en voorkeuren. Een harde eis kan zijn dat gegevens op het eigen netwerk blijven of dat elk antwoord een geldig uitvoerformaat heeft. Een voorkeur kan een prettigere schrijfstijl zijn. Een gewogen totaalscore mag een onaanvaardbare fout niet onzichtbaar maken.

Neem ook een referentie zonder nieuw taalmodel mee: je huidige werkwijze, een zoekopdracht, eenvoudige regels of een bestaand voorspelmodel. Anders meet je alleen welk taalmodel het minst slecht werkt, niet of de investering zinvol is.

Bouw een testset die op je echte gebruik lijkt

Voor een eerste persoonlijke verkenning kun je bijvoorbeeld twintig eigen opdrachten verzamelen: enkele makkelijke, enkele lange, een paar onduidelijke en een paar waarop het juiste antwoord “onbekend” is. Dat aantal is een startpunt voor leren, geen bewijs van betrouwbaarheid.

Een organisatie heeft meestal een grotere en systematischer samengestelde set nodig. Splits op relevante kenmerken: taal, documenttype, lengte, zeldzame categorie en kwaliteit van de invoer. Houd een representatieve steekproef apart van een gerichte stresstest. Rapporteer beide: als je zeldzame problemen expres vaak test, is de totaalscore daarvan niet de verwachte score in productie.

Leg per geval vast wat een correct resultaat inhoudt. Bij een samenvatting kan dat een lijst verplichte feiten en verboden toevoegingen zijn. Bij extractie zijn het de juiste veldwaarden plus welke velden werkelijk ontbreken. Laat onduidelijke gevallen door iemand met domeinkennis beoordelen.

Gebruik een deel om prompts en instellingen te verbeteren en houd een andere set apart voor de uiteindelijke vergelijking. Pas je de prompt telkens aan op dezelfde eindtest, dan verlies je een onafhankelijke controle. Herhaal belangrijke gevallen om gevoeligheid voor variatie in de uitvoer te zien.

Kies meetwaarden die fouten zichtbaar maken

Bij classificatie beschrijft precision welk deel van de voorspellingen voor een categorie klopt; recall beschrijft welk deel van de echte gevallen van die categorie wordt gevonden. Als urgente berichten zeldzaam zijn, kan een hoge totale nauwkeurigheid samengaan met slechte recall juist voor die urgente categorie.

Geef menselijke beoordelaars een korte rubric, bijvoorbeeld: volledig correct, bruikbaar na kleine correctie, of onbruikbaar. Definieer “klein” met concrete voorbeelden. Laat een tweede beoordelaar een deel van de antwoorden nakijken en bespreek verschillen voordat je conclusies trekt.

Vergelijk de versie die je werkelijk gaat gebruiken

Bewaar modelnaam, versie of hash, quantisatie, runtimeversie, contextinstelling, prompt, uitvoerlimiet en samplinginstellingen. Houd testgevallen en toegestane informatie gelijk. Bij een documentassistent horen ook de zoekconfiguratie en documentversie in dat overzicht.

Maak onderscheid tussen twee experimenten. Wil je alleen het model vergelijken, houd dan de rest zo veel mogelijk gelijk, met het passende invoerformaat per model. Wil je de beste oplossing kiezen, dan mag iedere kandidaat een eigen geoptimaliseerde prompt hebben. Besteed daaraan een vergelijkbaar ontwikkelbudget en beoordeel vervolgens op dezelfde onaangeroerde testset.

Voor gestandaardiseerde modeltests biedt de LM Evaluation Harness van EleutherAI configureerbare taken en modelinterfaces. Zo’n hulpmiddel kan de uitvoering herhaalbaarder maken, maar kiest jouw acceptatiecriteria niet. [2]

Meet snelheid zoals de gebruiker die ervaart

Een korte antwoordtijd telt alleen als het antwoord bruikbaar is. Meet de totale tijd van invoer tot afgeronde taak, inclusief documentzoeken, wachten in een wachtrij en menselijke correctie. Noteer daarnaast de tijd tot het eerste token: die bepaalt mede of een interface responsief aanvoelt.

Scheid de eerste aanroep na het laden van het model van latere aanroepen. Test korte én lange invoer en de gelijktijdigheid die je werkelijk verwacht. Rapporteer bijvoorbeeld de mediaan en het 95e percentiel van de totale antwoordtijd. Dat laatste laat zien waar de tragere ervaringen liggen; bij weinig waarnemingen is zo’n schatting instabiel.

Vergelijk tokens per seconde niet als enige maat tussen modellen met verschillende tokenizers. Voor dezelfde tekst kunnen ze verschillende aantallen tokens gebruiken. Voor de gebruiker telt vooral hoe lang het duurt voordat dezelfde taak klaar is.

Een fictieve vergelijking: snel is niet automatisch bruikbaar

Stel dat een team honderd testdocumenten gebruikt. Voor deze verzonnen illustratie geldt vooraf de eis: minstens negentig documenten moeten zonder inhoudelijke correctie bruikbaar zijn. Dit zijn geen gemeten resultaten van bestaande modellen.

B is sneller, maar haalt de vooraf gekozen kwaliteitseis niet. A haalt die grens in deze steekproef wel. Dat maakt A nog niet automatisch productierijp: twee documenten bevatten een verzonnen waarde. Zo’n fout kan afhankelijk van het veld een aparte afwijzingsgrond zijn. Foutcategorieën kunnen overlappen; de tabel is geen optelsom.

Een verschil op honderd documenten bevat onzekerheid. Inspecteer op welke identieke gevallen de modellen verschillen en verzamel extra voorbeelden waar dat voor je besluit nodig is. Trek geen zekerheid uit een paar procentpunten verschil en behandel nul waargenomen fouten niet als nul risico.

Een taalmodel als beoordelaar is niet onfeilbaar

Een tweede taalmodel kan helpen om veel antwoorden langs dezelfde rubric te leggen. Het kan ook fouten missen of voorkeur hebben voor langere antwoorden of voor de positie waarin een antwoord wordt aangeboden. OpenAI adviseert daarom automatische beoordeling te kalibreren met menselijke beoordelingen en aandacht te besteden aan deze vertekeningen. [3]

Verberg bij menselijke beoordeling waar mogelijk de kandidaatnaam, wissel de volgorde af en laat beoordelaars de bron zien. Gebruik een automatische beoordelaar niet als enige scheidsrechter voor fouten met grote gevolgen. Zijn oordeel is een extra meting, geen vervanging van je kwaliteitsdefinitie.

Bewaar tot slot je testset en foutanalyse. Herhaal de relevante controles zodra model, prompt, zoekmethode of runtime verandert. De waarde van een evaluatie zit niet alleen in de eerste keuze, maar ook in het opmerken dat een latere versie een eerder opgelost probleem opnieuw introduceert.