De theorie die verstopt zit in elke AI-benchmark - en waarom je er niet blind op kunt varen

Een tijdje terug las ik een paper van Theodore Kalaitzidis van Brown University, The Evaluation Trap: Benchmark Design as Theoretical Commitment (arXiv:2605.14167, 13 mei 2026). Ik was er nogal van onder de indruk. Niet omdat het een technische doorbraak beschrijft, maar omdat het iets benoemt wat ik in de praktijk steeds terugzie: we vertrouwen op benchmarks alsof het neutrale meetlatten zijn, maar dat zijn ze niet.

Het uitgangspunt is simpel. Elke benchmark bevat impliciete aannames over wat de capability die hij claimt te meten is. Een benchmark meet nooit zomaar, hij codeert een theorie. En als je die theorie niet kent, koop je iets anders dan je denkt.

Drie mechanismen die benchmarks onbetrouwbaar maken

Kalaitzidis werkt dat uit in drie lagen.

Transferability assumption. Je model scoort 95% op een reasoning-benchmark, dus je zegt dat het model redeneert. Maar de benchmark meet misschien alleen patroonherkenning, of distributionele generalisatie. Je meet output, geen mechanisme. De overdraagbaarheid van benchmarkprestatie naar de echte capability is een aanname, geen feit.

Circularity problem. Omdat benchmarkscores bepalen wat als vooruitgang geldt, gaan architecturen en datasets zich richten op wat de benchmark zichtbaar maakt. De benchmark wordt ontwerpcriterium in plaats van evaluatie-instrument. Kalaitzidis onderscheidt dit bewust van Goodhart's Law: bij Goodhart raakt een proxy los van een stabiel doel. Hier wordt het doel zelf gevormd door de evaluatiepraktijk.

Behavioral approximation. Systemen leren gedrag produceren dat lijkt op capability, zonder de onderliggende mechanismen. In enterprise-context is dat het verschil tussen "het systeem gedraagt zich alsof" en "het systeem heeft robuuste mechanismen voor begrip, adaptatie of feedbackgestuurd leren."

Vijf failure modes, en wat ze betekenen voor jouw organisatie

Kalaitzidis geeft vijf manieren waarop benchmarks falen op discriminative validity. Ik vind dit de meest concrete bijdrage van het paper:

Failure mode	Wat het betekent	Enterprise-risico
Proxy substitution	Benchmark meet taakconvergentie, niet de capability	Modelselectie op verkeerde KPI
Architectural indistinguishability	Evaluatie ziet geen verschil tussen architecturen met en zonder vereist mechanisme	Schijnzekerheid over autonomie of leervermogen
Context blindness	Benchmark varieert context onvoldoende	Falen bij domeinshift of edge cases
Criterion leakage	Outputpariteit wordt verward met mechanisme-equivalentie	"Human-level" claims zonder bewijs van proceskwaliteit
Approximation ceiling	Systeem optimaliseert binnen proxy-omgeving, faalt daarbuiten	Governance mist zicht op structurele limieten

Deze vijf punten gebruik ik inmiddels als checklist bij assurance-reviews. Het is een simpele maar effectieve manier om te checken of wat er in een model card staat ook klopt.

Epistematics: hoe je wél een goede benchmark ontwerpt

Kalaitzidis stelt tegenover de evaluation trap een methode die hij Epistematics noemt: vier stappen waarmee je vóór benchmark-constructie toetst of je meet wat je denkt te meten.

1. Specificeer de capability claim, wat moet het systeem kunnen?
2. Extraheer de theoretische aannames, welke mechanismen veronderstelt die claim?
3. Leid vereisten af voor architectuur en omgeving
4. Test of de evaluatie de capability kan onderscheiden van proxy-gedrag

Het kernbegrip is discriminative validity: een benchmark faalt als een systeem zonder het doelmechanisme tóch kan slagen, of als een systeem met het mechanisme niet herkenbaar is.

Wat dit betekent voor AI-agents

Ik werk veel met AI-agents, dus ik heb Epistematics vertaald naar een tabel voor agent-capabilities die ik in de praktijk tegenkom:

Capability claim	Wat een zwakke eval meet	Wat een goede eval zou testen
"Agent kan autonoom plannen"	Slaagt op statische taaklijst	Test onder veranderende doelen, incomplete informatie, onderbroken tools
"Agent leert van fouten"	Minder fouten na prompt-tweak	Bewijs van feedback-loop, state update, policy adjustment
"Agent is veilig"	Weigert bekende jailbreaks	Test tool authorization, indirect prompt injection, recovery
"Agent begrijpt codebase"	Beantwoordt vragen over gelezen files	Test symbol tracing, change impact, hallucinatie onder partial context
"Model redeneert"	Scoort hoog op reasoning-benchmark	Contrastieve taken buiten trainingsdistributie, mechanisme-sensitieve probes

Wat ik ervan meeneem voor governance

Voor AI-governance, EU AI Act, NIS2, ISO 27001, is dit paper fundamenteel. Benchmark-scores zijn geen bewijs, ze zijn data die je moet interpreteren. En die interpretatie vereist inzicht in de theoretische aannames van de benchmark.

Ik heb hier een governance control uit afgeleid die ik Capability-Evaluation Coherence Review noem. Het komt neer op zes bewijsstukken: een capability claim register met mechanistische definities, een theoretical assumption map per claim, een proxy-risk analyse, contrastieve evaluatie-designs, een design envelope met OOD-testplan, en traceerbaarheid naar model cards en risk assessments.

De zwakte van Kalaitzidis' paper is dat het conceptueel sterk is maar empirisch dun. Epistematics produceert criteria, geen gevalideerde benchmarks. Voor teams die morgen een eval suite moeten bouwen, is de stap van theorie naar praktijk nog groot. Maar als auditprocedure, om te checken of jouw evaluatie meet wat je denkt, is het goud waard.

Bij DjimIT gebruiken we dit frame inmiddels voor Benchmark Validity Audits. De vraag is niet hoe hoog het model scoort, maar welke theorie over capability in die score verborgen zit.

---

Paper: Kalaitzidis, T.J., "The Evaluation Trap: Benchmark Design as Theoretical Commitment", arXiv:2605.14167, 13 mei 2026. Brown University.