Selectie-audit versus benchmark-screenshot: de regels waar je stack al op draait

Een benchmark-screenshot vertelt je hoe een paar modellen op één datum scoorden op de test van iemand anders; een selectie-audit vertelt je waarom elk model in je stack staat. Het screenshot kan een kandidaat aandragen. Het vertelt je niet waarom een geërfd endpoint nog steeds klantgegevens verwerkt, wat die demo van vijf minuten eigenlijk bewees, of een taak überhaupt een grens aan de responstijd heeft.

Het model-portfolio maakt de selectie-audit, een audit van je modelkeuzes, tot het startpunt van de methode: zet elk model dat je draait op een lijst, schrijf de echte reden op waarom het is gekozen en zoek de keuzes die niemand kan verantwoorden. Het boek zegt het zo: een leaderboard-score is het cv van een model. Maar een cv is nog geen aanstelling.

Wat laat een benchmark-screenshot eigenlijk zien?

Een leaderboard-score vertelt hoe een model presteerde op een concrete reeks taken, onder concrete omstandigheden, getoetst aan concrete criteria, op het moment dat de test draaide. Dat is echte informatie, maar geen antwoord op jouw vraag: hoe presteert dit model op jouw taken, in jouw systeem, onder jouw belasting, gemeten aan jouw kwaliteitsdrempel?

Het boek noemt die afstand de benchmark-productiegap. Productiewerk is zelden zo netjes als een benchmark: een klantchatbot die factuurvragen beantwoordt, retouren afhandelt en af en toe een technische klacht opvangt, bestaat uit drie of vier taken achter één interface, elk met een eigen redeneerbehoefte, latentietolerantie en kwaliteitsdrempel. Een screenshot toont bovendien één ranglijst, en ranglijsten kronen verschillende winnaars omdat ze verschillende dingen meten.

Bewijsstuk	Vraag die het beantwoordt	Vraag die openblijft
Benchmark-screenshot	Hoe scoorden deze modellen op die datum op deze test, met deze metriek?	Geldt die uitslag ook voor onze taak, onder onze belasting en randvoorwaarden?
Selectie-audit	Waarom staat dit model in onze stack, welke taak doet het en welk bewijs lag onder de keuze?	Ondersteunt een test op representatieve voorbeelden die toewijzing nog steeds?

Datum en testopzet doen ertoe, omdat uitslagen verschuiven. Drie gedateerde voorbeelden uit het boek:

• Copilot Arena, gerapporteerd in februari 2025. Een extensie voor VS Code, gebouwd door universitaire onderzoekers, liet ontwikkelaars telkens twee codeaanvullingen uit tien modellen zien en hield bij welke ze overnamen: meer dan 4,5 miljoen suggesties en 11.604 stemmen van 1.642 gebruikers in ruwweg drie maanden. De rangcorrelatie van Spearman tussen die ranglijst en de meeste statische codeerbenchmarks lag op of onder 0,1 (met de codeerranglijst van een arena voor chatvoorkeur was dat 0,62, met de algemene ranglijst van die arena 0,48), en kleinere modellen stonden op statische benchmarks hoger dan in de editor van ontwikkelaars zelf (Chi en collega’s). Eén platform, één soort taak, één venster van drie maanden: het onderzoek laat zien dat een rangorde niet meeverhuist naar een andere gebruiksomgeving, niet dat ranglijsten uit de editor beter zijn dan benchmarks.
• GSM1k, 2024. Scale AI schreef een nieuwe rekentoets op basisschoolniveau, als spiegel van GSM8k. Meerdere modelfamilies scoorden daarop tot ruwweg acht procentpunten lager, en de terugval per model liep gelijk op met de neiging van dat model om GSM8k-opgaven woordelijk te reproduceren (Zhang en collega’s). Dat is een correlatie: hetzelfde artikel stelt vast dat de getroffen families nog steeds generaliseren naar nieuwe opgaven.
• SWE-bench Verified, 23 februari 2026. OpenAI kondigde aan te stoppen met het rapporteren van deze codeerbenchmark. Het bedrijf liet het deel van de dataset nalopen waarop modellen vaak faalden, 27,6% van de taken, en vond bij minstens 59,4% daarvan gebrekkige testgevallen. Bovendien vertoonde elk getest frontier-model tekenen van besmetting met trainingsdata (OpenAI). Die 59,4% gaat over het nagelopen deel, niet over de hele benchmark.

Geen van drieën maakt benchmarks waardeloos. Een gepubliceerde score is een meting met een houdbaarheidsdatum, die alleen voor de eigen test geldt: bewaar het screenshot met datum, metriek en testcondities, en behandel het als een reden om een kandidaat op je eigen taak te testen, niet om er verkeer naartoe te sturen.

Wat leg je vast in een selectie-audit?

De protocolkaart in het boek telt zeven stappen:

1. Maak een lijst van elk model dat ergens in je stack draait, inclusief experimentele integraties, door leveranciers geleverde endpoints en tools die individuele teamleden gebruiken.
2. Schrijf per model op waarom het is gekozen. Weet niemand dat, schrijf dan onbekend.
3. Schrijf op welke taken elk model afhandelt.
4. Leg per taak de latentie-eis, de kwaliteitsdrempel en de gegevensgevoeligheid vast, en markeer wat ontbreekt als niet-gespecificeerd.
5. Zoek de modellen waarbij de reden onbekend, geërfd of demo-resultaten luidt: de kandidaten met de hoogste prioriteit voor herbeoordeling.
6. Zoek de taken waarbij een van die eisen ontbreekt: gaten die je routebeleid nu niet kan opvullen.
7. Zoek de modellen die niet in een formeel register staan. Dat zijn schaduwmodellen, en die moet je nu documenteren.

Het werkblad in het hoofdstuk, met een tijdsbudget van 60 tot 90 minuten, maakt daar zes delen van:

• Deel 1, modelinventarisatie: model of endpoint, aanbieder, taken, geschat aantal aanroepen per dag, datum van toevoeging en wie het heeft toegevoegd. Markeer elke tool waarvan je de LLM-aanroepen niet kunt vaststellen.
• Deel 2, selectiereden-audit: de echte reden, met de taak, de huidige eigenaar en het bewijs, plus een van zes categorieën: Benchmark, Demo, Geërfd, Kosten, Leveranciersstandaard, Onbekend. Het boek vraagt om een beschrijving, niet om een rechtvaardiging. “Het is een sterk model” is een rechtvaardiging; “we hebben het lanceer-endpoint hergebruikt omdat de integratie er al lag” is een beschrijving die je kunt controleren.
• Deel 3, hiaten in het taakeisenprofiel: latentie-eis (real-time onder 500 ms p95, near-real-time onder vijf seconden p95, batch minuten of langer, of niet-gespecificeerd), kwaliteitsdrempel, gegevensgevoeligheid (openbaar, intern, vertrouwelijk of niet-gespecificeerd) en een eventuele privacy-hostbeperking.
• Deel 4, schaduwmodel-check: tools die niet in de inventarisatie staan, leveranciersproducten die LLM-aanroepen doen die je nooit zelf hebt ingericht, en wanneer alle modellen voor het laatst formeel zijn getoetst.
• Deel 5, prioriteitsvlaggen: je drie belangrijkste kwesties, de dringendste eerst. Dat is de werklijst die de audit oplevert.
• Deel 6, scoor de audit: het aantal verantwoorde modellen, afgezet tegen het totaal uit deel 1.

Het boek is daar nuchter over: dit is een inventarisatie die geen oordelen uitdeelt. Een slecht onderbouwde route bewijst geen slecht werk; elke verschuiving wacht op een test met representatieve voorbeelden tegen een vastgelegde kwaliteitsdrempel.

Welke ongeschreven regel koos het model?

Elk team heeft een modelselectieproces; de meeste teams hebben het alleen niet opgeschreven. Het boek noemt het werkelijke proces het impliciete regelboek: de heuristieken die de gemaakte keuzes verklaren, en dat zijn zelden de regels die een team zelf zou noemen. Vijf daarvan komen boven zodra teams voor het eerst een selectie-audit doen:

• Standaard het flagship-model. Het nieuwste frontier-model is het startpunt voor elk nieuw onderdeel. Wie afwijkt, moet dat rechtvaardigen; wie blijft, hoeft niets uit te leggen.
• Wat de vorige ontwikkelaar gebruikte. Het aangrenzende onderdeel krijgt het bestaande model, omdat dat al geïntegreerd is en de vraag waarom als kritiek voelt.
• De beste demo van vijf minuten. Mooiere uitvoer in drie handmatige tests geeft de doorslag. Dat is een signaal van vloeiendheid, geen beoordeeld resultaat (Evalueer de redenering, niet de vloeiendheid).
• Wat de leverancier meelevert. De SDK die als eerste werd geïntegreerd, nam de routeringsbeslissing.
• Het goedkoopste model dat niet zichtbaar faalt. Kosten zijn de enige dimensie, en “faalt niet zichtbaar” is de enige kwaliteitspoort.

Geen van die regels is irrationeel gezien wat het team op dat moment wist, schrijft het boek, maar op schaal leveren ze allemaal suboptimale uitkomsten op, omdat geen ervan rekening houdt met taakeisen, latentieklasse, privacyklasse of kosten bij realistisch verkeer. Geaggregeerde facturen verbergen ze: die beantwoorden Kunnen we de huidige rekening betalen?, niet is ons huidige routebeleid kostenefficiënt?, en het boek noemt geaggregeerde facturering een achterblijvende indicator van routeringskeuzes die maanden eerder zijn gemaakt.

Het boek laat die opstapeling zien aan de hand van Francesca en Amit, samengestelde personages en geen gemeten praktijkgeval. Het geërfde frontier-endpoint van Francesca, op de lanceerdag gekozen voor één taak, verwerkt er inmiddels zeven, van realtime automatisch aanvullen tot een wekelijkse onderzoekssynthese voor het verkoopteam. Voordat er één route verschuift, laat de kaart van Amit vier taken zien die batchlatentie verdragen en weinig redeneerwerk vragen, en twee die eerder snelheid dan diepte nodig hebben. Die zes worden kandidaat om van de frontier-laag af te gaan, mits parallelle tests bevestigen dat de kwaliteit gelijk blijft; de onderzoekssynthese is volgens het boek de enige taak die dieper redeneren echt beloonde. Tot die tests er zijn, is de besparing een voorspelling die op bewijs wacht.

Hoe ziet een gescoorde selectie-audit eruit?

Hypothetisch voorbeeld. Een klein product draait op drie model-endpoints. Elke datum, eigenaar, steekproefomvang en drempel hieronder is verzonnen om te laten zien hoe het werkblad scoort; er wordt geen productieresultaat gerapporteerd.

Model en taak	Echte selectiereden	Taakeisen en bevinding
A: nachtelijke samenvattingen van supporttickets	De operationeel manager, nu eigenaar, koos het op 12 september 2026 nadat een test op 50 tickets aan een vastgelegde acceptatieregel voldeed.	Batch, klaar vóór 7.00 uur. Minstens 45 van 50 samenvattingen uit een apart gehouden testset moeten slagen op een vast beoordelingsschema. Interne data, goedgekeurde host. Taak, eigenaar en bewijs liggen vast.
B: directe antwoorden op factuurvragen	De teamleider klantenservice, nu eigenaar, koos het op 19 september 2026 omdat het bovenaan een openbaar benchmark-screenshot stond, met onbekende testdatum.	Factuurgegevens van klanten, goedgekeurde host, maar een latentie-eis en kwaliteitsdrempel zijn nergens vastgelegd. Niets verbindt de ranglijstpositie met deze taak.
C: extractie van contractvelden	De technisch leider, nu eigenaar, erfde het mee met de SDK van een leverancier. Oorspronkelijke datum en bewijs onbekend.	Batch, klaar vóór 9.00 uur. Het uitvoerformaat ligt vast; de kwaliteitsdrempel en de toegestane host voor vertrouwelijke contracten niet.

Deel 6 telt verantwoorde modellen, geen modellen die als goed worden beoordeeld: de reden noemt de taak, de huidige eigenaar en het bewijs, en geen enkele taakeis staat op niet-gespecificeerd. Demo, Geërfd en Onbekend halen die lat nooit. Benchmark, Kosten en Leveranciersstandaard halen hem op zichzelf evenmin, voegt het boek toe, want een leaderboardpositie, een lage prijs en een SDK die als eerste binnenkwam zijn stuk voor stuk redenen die de taak hebben overgeslagen.

A haalt de lat. B valt om twee redenen af: een positie op een screenshot is de enige reden, en de taak heeft geen latentie-eis of kwaliteitsdrempel. C ook: een geërfde keuze, met een kwaliteitsdrempel en host die niet-gespecificeerd zijn. De score is één van de drie verantwoord. De kleine test bij A ondersteunt die keuze, maar bewijst niet dat A nog altijd het beste model is.

Het boek deelt de score in vier uitkomsten in: elk model verantwoord, op twee of drie na allemaal, de helft of minder en deel 1 zelf is onvolledig. Bij de helft of minder bepaalt het impliciete regelboek hoe je stack draait, en stuurt het boek je eerst naar het ROUTE-kader voordat je losse rijen herstelt.

Wat zet je op de herbeoordelingslijst?

Zet redenen als onbekend, geërfd en demo bovenaan, zoals de protocolkaart voorschrijft, en voeg redenen toe die alleen op een leaderboard steunen: deel 6 behandelt een leaderboardpositie op zichzelf al als een reden die de taak heeft overgeslagen. Keuzes die alleen op kosten of een leveranciersstandaard rusten, vragen om hetzelfde taakgerichte bewijs. Een vlag vraagt om bewijs; het is geen opdracht om een model te vervangen.

In het hypothetische voorbeeld komt C eerst: zoek uit welke host achter de SDK van de leverancier zit en of vertrouwelijke contracten daarheen mogen. Daarna B: leg de latentie-eis en de kwaliteitsdrempel vast, achterhaal zo mogelijk de datum en testopzet van het screenshot, en test op representatieve factuurvragen. A krijgt een latere herbeoordelingsdatum. Die volgorde is een redactionele afweging, geen gemeten risicorangorde.

De audit laat ook zien welke van de vier faalmodi uit het boek het meest acuut is, en dus waar je in de ROUTE-discipline begint. Schaduwmodellen wijzen naar Register. Taken die niet bij hun laag passen, zoals frontier-capaciteit op batchtaken, wijzen naar Doel-typering, volgens het boek de stap die de benchmarkval sluit; daar hoort B thuis. Een impliciete regel die niemand kan verdedigen, zoals de geërfde standaard van C, wijst naar Uitvoeringsbeleid. Onzichtbare kosten of gemiste latentiedoelen wijzen naar Tracken; modellen die sinds hun toevoeging nooit opnieuw zijn beoordeeld, naar Evolueren. Wat is modelroutering? behandelt het geschreven beleid dat daarop volgt, Frontier, workhorse of lokaal de modelklassen, en Is één AI-model genoeg? wanneer één model volstaat en wanneer je een portfolio nodig hebt.

Probeer dit vandaag

Trek twintig minuten uit voor een eerste ronde.

1. Zet alle modellen en door modellen aangedreven endpoints die productiewerk doen op een rij. Vraag route-eigenaren naar leveranciersfuncties en teamtools. Krijg je de lijst niet rond, zet dan inventarisatie onvolledig bovenaan.
2. Schrijf naast elke regel de taak, de echte reden waarom het model is gekozen, de datum en de huidige eigenaar, of onbekend. Was een screenshot de reden, noteer dan de testdatum, de metriek en de testcondities, of markeer die als onbekend.
3. Noteer per taak de latentie-eis, de kwaliteitsdrempel, de gegevensgevoeligheid en de toegestane host, of niet-gespecificeerd.
4. Zet elke rij met als reden bovenaan een leaderboard, onbekend, geërfd of demo op de herbeoordelingslijst. Markeer elke niet-gespecificeerde eis als een gat in je routering.
5. Tel de modellen waarvan de reden taak, eigenaar en bewijs noemt en waarvan de taak geen niet-gespecificeerde eis heeft. Zet een datum op de lijst en wijs een eigenaar aan voor het eerste gat.

Een onvolledige inventarisatie is je eerste bevinding; een score zou doen alsof je de noemer kent. Is de lijst compleet, neem dan de actie die het boek voor deze week geeft: schrijf voor het model met het hoogste volume waarvan de reden “onbekend” luidt de ontbrekende paragraaf over wat het afhandelt, waarom het de route nog verdient en wie die verantwoordelijkheid draagt, gedateerd. Kan niemand die paragraaf schrijven, dan heb je je eerste kandidaat voor herbeoordeling. Geen enkel model hoeft te verhuizen voordat de taak en het bewijs helder zijn.

Citeer deze pagina:Selectie-audit versus benchmark-screenshot: de regels waar je stack al op draait.Len P. van der Hof. https://lenvanderhof.com/nl/blog/keuze-audit-versus-benchmark-screenshot/ · Gepubliceerd 4 november 2026.