Home / Vault & Second Brain / De 80% die het echte probleem verbergt: waarom één score niet genoeg is

De 80% die het echte probleem verbergt: waarom één score niet genoeg is

De 80% die het echte probleem verbergt: waarom één score niet genoeg is

De 80% die het echte probleem verbergt

Gisteren publiceerde ik een post over mijn AI die 50% scoorde op een publieke benchmark — en hoe dat ene getal het echte verhaal verborgen hield. Vandaag wil ik een stap verder gaan, want ik vond een paper dat precies formaliseert wat ik niet kon benoemen. Het heet “Towards a Science of AI Agent Reliability” en komt van de groep van Arvind Narayanan in Princeton, geaccepteerd op ICML 2026. Het heeft me doen herdenken hoe ik mijn eigen agents meet.

De kernclaim is simpel en ongemakkelijk: het comprimeren van agent-gedrag tot één success-metric verbergt kritieke operationele gebreken. Een agent die 80% van de tijd slaagt maar 40% van de tijd op een andere manier faalt, is in de praktijk onbruikbaar — ook al ziet het gemiddelde er prima uit. Eén getal kan je niet vertellen of de agent zich consistent gedraagt over runs, of hij kleine verstoringen overleeft, of hij voorspelbaar faalt, of zijn fouten klein en herstelbaar blijven.


Vier dimensies in plaats van één score

Het paper ontleedt betrouwbaarheid in vier dimensies: consistentie (gedraagt het zich hetzelfde bij dezelfde input?), robuustheid (faalt het bij kleine variaties?), voorspelbaarheid (kun je het faalpatroon anticiperen?) en veiligheid (is de ernst van een fout begrensd?). Twaalf metrieken over die vier dimensies. De bevinding die mij het hardst raakte: recente capability-winst in de geteste modellen leverde slechts kleine verbeteringen op in betrouwbaarheid. Hogere benchmarkscores betekenden geen betrouwbaarder gedrag in de praktijk.

Dat is de valkuil waar ik bijna in was gestapt. Ik ben een task pass-rate benchmark aan het ontwerpen voor mijn eigen stack — Home Assistant, WordPress, mijn vault, genealogie. Binair pass/fail, een deterministische verifier, geen LLM-judge. Dat is het juiste vertrekpunt. Maar dit paper liet me zien wat ik miste: pass/fail op de uitkomst zegt niets over consistentie over runs, robuustheid tegen verstoringen, of hoe erg een fout wordt als hij gebeurt.


Wat ik aan mijn benchmark toevoeg

Dus voeg ik twee dingen toe. Ten eerste een consistentie-dimensie: rondt mijn agent dezelfde taak op dezelfde manier af over meerdere runs? Ten tweede een veiligheidscheck die de faal-ernst meet — is een fout klein en corrigeerbaar, of groot en destructief? Want een benchmark die alleen zegt “het werkte” vertelt je minder dan je denkt. De vraag is niet alleen of het slaagt. Het is of je het kunt vertrouwen als het faalt.

Als je zelf agents draait, stel ik je dezelfde vraag: wat vertelt jouw pass-rate je eigenlijk? Vertelt het je hoe je agent faalt — of alleen dat hij soms slaagt? Ik hoor graag hoe jij betrouwbaarheid meet, want ik denk dat de meesten van ons nog naar één getal kijken en dat een oordeel noemen.

Wat vond je van dit bericht?

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *