Scoren verandert een benchmark van “de JSON met het oog beoordelen” in een objectief getal. Het resultaat van elk model wordt beoordeeld tegen een gouden referentie — de verwachte output — wat volledigheid, correctheid en een algehele kwaliteitsscore oplevert waarop je kunt sorteren.
Scoren heeft iets nodig om tegen te scoren. Elk scenario draagt een referentie-output: het juiste antwoord voor zijn ene vaste entiteit. Bouw die op door te genereren met sterke modellen (websearch + een bron-van-waarheid-document), door een bekend-goed resultaat te plakken en het vervolgens handmatig te bewerken — en markeer het als geverifieerd zodra je het vertrouwt. Een geverifieerde referentie is vereist om het scenario überhaupt te benchmarken, dus er is altijd iets om tegen te beoordelen. Als je de referentie later bewerkt — of de scoreconfiguratie van het scenario wijzigt — worden bestaande scores gemarkeerd als verouderd totdat je opnieuw scoort.
Het kernprobleem: twee correcte antwoorden kunnen anders geschreven zijn. Een model dat een acteur “R. Downey Jr.” noemt in plaats van “Robert Downey Jr.” heeft geen ongelijk. Daarom wordt elk veld vergeleken met een getrapte ladder — eerst het goedkoopst en meest zeker, alleen escalerend wanneer nodig:
Identieke waarden komen overeen. Net als waarden die alleen verschillen in hoofdletters, omringende witruimte of numerieke precisie ("Acme" = "ACME", 4.0 = 4). Gratis en volledig deterministisch.
Voor tekst worden de kandidaat en de referentie ingebed en vergeleken op basis van cosinusgelijkenis. Boven de drempel gelden ze als hetzelfde — dus een geldige alternatieve schrijfwijze zoals "R. Downey Jr." versus "Robert Downey Jr." is een match, geen fout. Datums vormen de uitzondering: die worden vergeleken als kalenderwaarden, nooit op gelijkenis, zodat een bijna-maar-verkeerde datum ("1972-03-14" versus "1972-03-24") een duidelijke mismatch is in plaats van een misleidend hoge cosinus. Booleans zijn eveneens exact-of-niets.
Waarden die te dicht bij elkaar liggen om op basis van gelijkenis te beslissen — alle vrije-tekstvelden zoals samenvattingen en beschrijvingen, en elk niet-identiek getal — worden naar een judge-model gestuurd, dat op een schaal van 0–100 beoordeelt hoe goed het antwoord de betekenis van de referentie weergeeft. Het beloont een correct antwoord dat anders of beknopter is verwoord, en geeft een getal gedeeltelijke punten wanneer het veld dat toelaat (een molecuulgewicht van 273,37 vs. 273,35, een halfwaardetijd van 12 vs. 15), terwijl het er nog steeds op afgerekend wordt waar exactheid telt (een releasejaar van 2020 vs. 2023). Zonder judge valt vrije tekst terug op een continue gelijkenisscore, en is een niet-identiek getal simpelweg een mismatch.
Een striktheidsinstelling bepaalt de embeddingdrempel: hoger betekent dat twee anders geschreven waarden meer op elkaar moeten lijken om als gelijk te tellen. De striktheid, het optionele jurymodel en het embeddingmodel worden allemaal op het scenario ingesteld — niet telkens gekozen wanneer je scoort — zodat elk model identiek wordt beoordeeld en de scores vergelijkbaar blijven.
Lijsten — de cast van een film, de bijwerkingen van een medicijn — zijn waar modellen het meest van elkaar verschillen: een klein model vindt misschien 4 acteurs waar een sterk model er 15 vindt. De volgorde maakt niet uit, en meer correcte items vinden hoort te winnen. Daarom worden arrays gescoord als een set, niet positie voor positie:
Vouw een resultaatrij uit om precies te zien welke items zijn gematcht, gemist of gehallucineerd.
Eén enkel getal verbergt te veel, dus elk resultaat draagt subscores:
De uitklapbare rij toont de uitsplitsing per veld: kandidaat versus referentie, welke trede van de ladder de doorslag gaf, en waar relevant de overeenkomst.
Kwaliteit is maar een derde van het verhaal. Waar een benchmark de modelselectie voedt — als scorebron — komt de positie van het model voort uit een mix van kwaliteit, snelheid en kosten, en die verhouding bepaal jij: stel die per scenariotype in via Instellingen → Organisatie → Standaardwaarden, waarbij elke set optelt tot 100 en standaard gelijk verdeeld is. Geef je kosten veel gewicht, dan komt een goedkoop, redelijk model boven een uitstekend duur model — voor sommige workloads het juiste antwoord en voor andere het verkeerde, dus het platform beslist dat niet voor je.
Wanneer een scenario een model meer dan één keer uitvoert (herhalingen), wordt elke run afzonderlijk gescoord en toont de rij de gemiddelde kwaliteit plus een consistentiespreiding (laagste–hoogste van de runs) — zodat een model dat gemiddeld klopt maar grillig is, gemakkelijk opvalt. De zichtbare uitvoer is de run met de mediane kwaliteit.
Benchmarks zijn niet beperkt tot verrijking: een scenario kan ook voorbeeldgeneratie testen (elk model verzint een voorbeeld-JSON voor een entiteittype) of schemageneratie (elk model zet een vast voorbeeld om in een schema). Elk heeft zijn eigen scoreregels:
Hoe dan ook behouden de bekende kolommen hun betekenis — beweeg over een kolomkop voor de typespecifieke definitie, en klap een rij uit voor de volledige uitsplitsing.
Scoren is een aparte doorgang over reeds opgeslagen resultaten — het verrijkt nooit opnieuw, dus je betaalt nooit opnieuw voor de geteste modellen. Het maakt wel embeddings van tekst om waarden te vergelijken (en voert de judge uit, als het scenario er een heeft), wat credits aftrekt op basis van gebruik. Dit gebeurt automatisch bij elke run — elk model wordt gescoord zodra de runs ervan klaar zijn — en opnieuw telkens wanneer je opnieuw scoort. Als je organisatie geen embeddingmodel heeft geconfigureerd (en het scenario geen override instelt), wordt scoren nog steeds uitgevoerd, maar valt het terug op alleen exacte overeenkomsten (alternatieve spellingen tellen dan als niet-overeenkomsten), en dat wordt gemeld. Een kapotte judge is iets anders: als een judge-aanroep mislukt, stopt het scoren met een expliciete fout en behoudt het getroffen model geen gedeeltelijke scores — een resultaat is óf volledig gescoord óf helemaal niet gescoord, en blijft later opnieuw scoorbaar. Houd er bij het kiezen van de beoordelaar rekening mee dat LLM-beoordelaars hun eigen modelfamilie kunnen bevoordelen — kies bij voorkeur een beoordelaar van een provider die je niet benchmarkt.
Stel in Modelbeheer → Benchmarks een referentie in en verifieer die in de scenario-editor (en kies daar het judge-model, embedding-model en de striktheid). Vanaf dan scoort elke run automatisch zijn geslaagde resultaten — een sorteerbare kolom Kwaliteit wordt zonder extra stap ingevuld. Gebruik Resultaten opnieuw scoren (de knop in de kop of het ···-menu) om opnieuw te beoordelen nadat je de referentie of de scoringsconfiguratie hebt bewerkt.