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.
De referentie werkt zichzelf ook bij. Een geverifieerde referentie blijft een handmatig gecorrigeerd concept, en de modellen die je benchmarkt zijn de beoordelaars ervan: overal waar de beoordelaar het antwoord van een kandidaat beter vindt dan dat van de referentie (of dat van de referentie fout), overal waar de eigen voorbeelden van het scenario aantonen dat de referentie fout is, en overal waar een model een waarde invult die de referentie leeg liet en de beoordelaar dat bevestigt, legt het resultaat een bevinding vast. Aan het eind van elke scoringsronde worden de bevindingen van alle gescoorde modellen samengevoegd — eerst wat de voorbeelden aantonen, daarna het antwoord dat de meeste modellen gaven — en in de referentie geschreven. Een bewerking die een ronde al heeft gemaakt, wordt alleen vervangen door sterker bewijs (de voorbeelden, een oordeel dat de waarde fout is, of meer modellen die het eens zijn — geteld over alle rondes heen), nooit door de mening van nog één model, zodat het één voor één benchmarken van modellen de referentie niet kan laten afdrijven richting het laatst gescoorde model. Deze automatische bewerkingen markeren scores nooit als verouderd (alleen je eigen opslagacties doen dat), en elke bewerking wordt gelogd met wat die verving en welke modellen die naar voren brachten.
Bekijk ze als bijgehouden wijzigingen: de Referentie-weergave van het scenario, naast de resultaten, toont de referentie zelf met elke automatische bewerking gemarkeerd op de plek waar die staat — de vorige waarde doorgestreept, de nieuwe waarde, hoeveel modellen erachter staan en waarom. Alles wordt geaccepteerd tenzij je het afwijst; een afwijzing herstelt de vorige waarde en houdt dat pad buiten toekomstige rondes. Filter op attribuut of bewijs (bewerkingen van één model zijn een blik waard), selecteer wat wordt getoond en wijs in bulk af.
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 op basis van gelijkenis niet te beoordelen zijn — alle vrijetekstvelden zoals samenvattingen en beschrijvingen, elk getal dat niet identiek is, en een duidelijk afwijkende waarde die door je documenten of de meeste andere modellen wordt ondersteund — gaan naar een jurymodel. De jury is blind: die ziet de twee waarden als A en B, met de plek van het veld in het schema (de bovenliggende velden en hun beschrijvingen, het type, bij welk lijstitem het hoort) en je brondocumenten als het scenario die heeft, en geeft aan welke waarde het veld beter dient, dat beide correct zijn, of dat er één fout is. Een kandidaat die gelijkwaardig aan of beter dan de referentie wordt beoordeeld — of een referentie die fout wordt bevonden — levert de volle score op; een zwakker antwoord levert een deelscore op, een fout antwoord weinig tot niets. Een getal krijgt een deelscore wanneer het veld dat toelaat (een molecuulmassa van 273,37 tegenover 273,35, een halfwaardetijd van 12 tegenover 15) en zakt waar exactheid telt (een releasejaar van 2020 tegenover 2023). Een waarde die de referentie leeg liet, wordt apart voorgelegd: als die correct wordt bevonden, telt hij als een waarde die de referentie had moeten bevatten en die het model heeft gevonden — de score gaat omhoog, het blijft niet bij niet-bestraft — en de referentie neemt hem over.
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, telkens optellend tot 100 en standaard gelijk verdeeld. Geef kosten veel gewicht en een goedkoop, redelijk model verslaat een uitstekend duur model — voor sommige workloads is dat het juiste antwoord en voor andere het verkeerde, dus het platform beslist dat niet voor je. Snelheid en kosten worden op een logaritmische schaal afgezet tegen de andere resultaten van het scenario: het snelste of goedkoopste model scoort 100 en een model dat tien keer trager of duurder is scoort 0, maar een dicht bij elkaar liggend veld wordt nooit uitgerekt over het hele bereik — twee modellen van $10 en $12 komen uit op 100 en 92, niet op 100 en 0.
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 hetzelfde vrijetekstverzoek) 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 ronde over al opgeslagen resultaten — er wordt nooit opnieuw verrijkt, dus je betaalt nooit opnieuw voor de geteste modellen. Er wordt wel tekst geëmbed om waarden te vergelijken (en de beoordelaar uitgevoerd, als het scenario er een heeft), wat credits afschrijft op basis van gebruik. Dit gebeurt automatisch bij elke run — elk model wordt gescoord zodra zijn runs klaar zijn — en opnieuw telkens als je opnieuw scoort. Als je organisatie geen embeddingmodel heeft ingesteld (en het scenario geen override opgeeft), wordt er toch gescoord, maar valt het systeem terug op alleen exacte overeenkomsten (afwijkende schrijfwijzen tellen dan als verschillen), en dat wordt ook gemeld. Een kapotte beoordelaar is iets anders: als een aanroep van de beoordelaar mislukt, stopt het scoren met een expliciete fout en houdt het betrokken model geen gedeeltelijke scores over — een resultaat is ofwel volledig gescoord ofwel helemaal niet, en kan later altijd opnieuw worden gescoord. Antwoorden van de beoordelaar worden per scenario gecachet op basis van hun inhoud: dezelfde vraag die door een ander model, een herhaling of een volgende ronde wordt opgeworpen, wordt nooit dubbel betaald, en een nieuwe scoring nadat de referentie zichzelf heeft bijgewerkt, stelt alleen de vragen bij de bewerkte velden opnieuw. Niets van wat de judge doet blijft verborgen: elke scoringsronde over een model laat een scoringsrecord achter in Geschiedenis — één rij per judge-aanroep met prompt, antwoord, tokens en kosten, inclusief mislukte aanroepen, plus hoeveel vragen de cache gratis heeft beantwoord — en de resultatentabel toont per model de judge-kosten, het aantal aanroepen en de scoringstijd, met een link ernaartoe. 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 beoordelaarsmodel, het embeddingmodel en de striktheid). Vanaf dan scoort elke run automatisch zijn geslaagde resultaten — een sorteerbare kolom Kwaliteit vult zich zonder extra stap. Gebruik Resultaten opnieuw scoren (de knop in de header of het ···-menu) om opnieuw te beoordelen nadat je de referentie of de scoringsconfiguratie hebt aangepast. De badge referentie-updates naast de referentiestatus opent het log van wat de scoringsrondes hebben gewijzigd, met een terugdraaioptie per item.