De verzadigingsval: wanneer je evaluatiebasis te goed is om te meten

Een vergelijkende evaluatiedrempel ("het nieuwe systeem moet de oude in 60% van de taken verslaan") stopt stilzwijgend met werken op het moment dat je basislijn de rubriek verzadigt. Dat gebeurde bij ons. We bouwden een rechtstreekse vergelijkingsdrempel om te bepalen of een zwaardere, meervoudige pipeline zijn plaats verdiende ten opzichte van onze in productie genomen basislijn met één beurt, voerden deze uit en kregen een vonnis dat eruitzag als een duidelijke afwijzing: een winpercentage van 7,1% tegen een drempel van 60%. Bij deze run was de uitdager nooit slechter op enig taak: deze gelijkde op 13 van de 14 taken en won de ene waarin het niet gelijkde. Het getal vertelde ons niet dat de uitdager had gefaald. Het vertelde ons dat onze taken te eenvoudig waren om de twee systemen van elkaar te onderscheiden, en dat we de ene bijna voor de andere hadden aangezien.

Die mislukking heeft een vorm die het verdient om een naam te krijgen, omdat hij onzichtbaar is tot je naar de absolute score van de basislijn kijkt. We noemen het de verzadigingsval: wanneer je basislijn bijna het plafond bereikt, meet een winpercentage-drempel niet langer de uitdager zelf.

De drempel die we bouwden

De beslissing was concreet. Een meervoudige pipeline (plannen, dan uitvoeren, dan verifiëren) kost meer om uit te voeren dan een basislijn met één beurt, omdat deze meerdere modelaanroepen maakt waar de basislijn met één beurt één aanroep doet. De bar was dus niet "is het goed", maar "is het duidelijk beter, genoeg om de extra kosten te rechtvaardigen". Als het alleen maar gelijkde aan de basislijn met één beurt, was het een kostenverhoging zonder kwaliteitswinst en zou het niet in productie mogen gaan. (We publiceren bewust niet de interne modelopbouw van de pipeline of enige per-token-economie; de les hier draait om de evaluatie, niet onze routering.)

We maakten "duidelijk beter" meetbaar met twee criteria die beide moesten slagen, omdat elk afzonderlijk makkelijk te manipuleren is:

• Winpercentage van minimaal 60%. De uitdager moet op minimaal 60% van de taken duidelijk winnen. Gelijkspel telt tegen hem: een gelijkspel bij hogere kosten is een verlies in producttermen. We stelden de drempel op 60% in plaats van 50%, zodat een resultaat de beoordelaarsruis op een kleine taakset moest doorstaan; een 7-op-12 doorkruipen is één omgekeerd oordeel verwijderd van een muntworp.
• Gemiddelde score-delta strikt positief. Het gemiddelde per-taak-scoreverschil (uitdager minus basislijn) moet boven nul liggen, zodat enkele smalle overwinningen geen grote regressies elders kunnen maskeren.

De taakset bestond uit 14 kernstroomtaken op een volledig synthetische werkruimte: een fictieve SaaS-processor voor 30 personen met opzettelijk ingevoerde defecten (een verouderd ISMS-beleid dat verwees naar de ingetrokken ISO/IEC 27001:2013, een toegangscontrolebeleid met een zelftegenstrijdige MFA-regel, een stub voor incidentrespons, een gedeeltelijke verwerkingsinventaris). Geen klantgegevens. Elke taak had een rubriek met onafhankelijk beoordeelbare, binaire criteria, gescoord door een LLM-beoordelaar (claude-haiku-4-5, temperatuur 0, één JSON-oordeel per criterium). De beoordelaar zag alleen de vrijgegeven deliverables, nooit de interne planning van de pipeline, dus een planning die beloofde "Art. 28(3) opnemen" kon geen credits verdienen voor documenten die die belofte niet waarmaakten.

De uitvoering, en de twee lijnen die het oneens waren

Hier zijn de volledige resultaten. De basislijn is de basislijn met één beurt (claude-opus-4-6); de uitdager is de meervoudige pipeline, waarvan we de interne modelopbouw achterhouden omdat deze de routering raakt. Dat is hier prima, omdat de les op architectuurniveau is en niet afhangt van welk model in de pipeline zit. Eén run per systeem, 2026-06-11.

Maatstaf	Waarde
Gemiddelde score basislijn (14 taken)	0,984
Gemiddelde score uitdager (14 taken)	1,000
Gelijkspel	13 van de 14
Overwinningen uitdager	1
Verlies uitdager	0
Winpercentage (gelijkspel telt tegen uitdager)	7,1% (1/14)
Gemiddelde score-delta (uitdager minus basislijn)	+0,016

Lees de drempel tegen deze cijfers aan en de twee lijnen tegenspreken elkaar. De gemiddelde-delta-lijn slaagt: de uitdager is gemiddeld zeer licht beter en nooit slechter. De winpercentage-lijn faalt catastrofaal: 7,1% tegen een drempel van 60%. Een enkele drempel die zowel zegt "de uitdager is op elke taak minstens zo goed" als "de uitdager verliest 93% van de tijd" meet niet de uitdager. Die tegenspraak is het handteken van de verzadigingsval, en het is het signaal om op te letten.

Het mechanisme is rekenkundig, niet oordeelkundig. De basislijn scoorde een perfecte 1,0 op 13 van de 14 taken. Op een taak waar de basislijn al 1,0 scoorde, kan de uitdager alleen maar gelijkspelen, omdat er geen ruimte boven 1,0 is om te winnen. En gelijkspel telt, door onze eigen ontwerpkeuze, tegen de uitdager. Dus een rubriek die de basislijn perfect beheerst, zet bijna elke taak om in een structureel verlies voor de uitdager, hoe goed deze ook is. Het winpercentage mat niet langer een eigenschap van de uitdager, maar een eigenschap van de taakset: specifiek, het aandeel taken dat de basislijn achterliet als winbaar. Er bleef er één over.

De enige taak waar de basislijn een score verloor

Kijk naar de enige taak waar de basislijn geen perfecte 1,0 scoorde. Deze scoorde 0,78, en niet omdat deze het werk niet kon doen. Het was een taak waar deze te veel deed: gevraagd om de ontbrekende GDPR-documentatieset op te stellen met een rubriek die drie tot vijf artefacten voorschreef, produceerde de basislijn met één beurt er zeven. Elk artefact was competent en correct geciteerd. Het enige verliespunt in de hele run was een gewogen straf voor overlevering, omdat het niet stopte.

Dat is de hele les in één datapunt. Wanneer beide systemen de taak kunnen uitvoeren, is "kan het de taak uitvoeren" niet langer de vraag die de evaluatie zou moeten stellen, omdat beide systemen ja antwoorden en gelijkspelen. De enige resterende fouten om te beoordelen zijn fouten van terughoudendheid: te veel doen, te veel zeggen, te zelfverzekerd citeren, beweringen doen die niet gevraagd waren. Onze eerste rubriek mat bekwaamheid, onze basislijn verzadigde deze, en het enige signaal dat overbleef was een falen van terughoudendheid waarvoor we bijna geen taak hadden geschreven om het te vangen.

"Zet dus de basislijn in productie"

Het eerlijke bezwaar tegen dit alles is dat een basislijn die 0,984 scoort je vertelt om de basislijn in productie te zetten en de dure pipeline over te slaan. Als het goedkope ding zo goed is, waarom blijf je meten? Het is een eerlijk punt en het is voor de helft juist: op deze taken was het goedkope ding dat goed, en dat is een echte bevinding.

Het is slechts voor de helft juist omdat verzadiging op bekwaamheidstaken niets zegt over terughoudendheidstaken, en terughoudendheid is precies waar een meervoudige pipeline (die zijn eigen werk kan controleren voordat het wordt vrijgegeven) werkelijk vooruit kan lopen, of achteruit kan gaan door zijn eigen overmoed te versterken. Onze kernstroomtaken hebben dit nooit onderzocht. De enige die dit per ongeluk wel deed (de taak met overlevering) was de enige die bewoog. Dus de 0,984 was geen bewijs dat de twee systemen gelijkwaardig waren. Het was bewijs dat onze taken hen niet konden onderscheiden op de as die overbleef. Verzadiging is een uitspraak over je rubriek, nooit een oordeel over de gelijkwaardigheid van je systemen.

Wat we hebben aangepast

We hebben de drempel niet opnieuw uitgevoerd. Een herhaling van een verzadigde evaluatie kan het winpercentage niet verhogen, omdat de uitdager niet boven de 1,0 van de basislijn kan scoren op de taken die deze al gelijk speelt; een herhaling reproduceert alleen maar hetzelfde plafond tegen hogere kosten. In plaats daarvan hebben we de taakset versterkt, door taken toe te voegen waarvan de rubrieken een sterke basislijn met één beurt werkelijk kan falen, elk gericht op een as van terughoudendheid die de kernstroomtaken negeerden:

• Discipline in scope: produceer precies drie onboardingdocumenten, niet meer. Beoordeelt de reflex tot overlevering achter het enige verliespunt van de basislijn.
• Doelgroepgerichte weglating: een klantgerichte beveiligingsmail plus een interne dekkingsbrief, waarbij de werkruimte een interne-only partnerherinnering bevat. Beoordeelt of het model geprivilegieerde inhoud uit de naar buiten gerichte artefact houdt.
• Correctheid van citaten: een intern auditplan dat de juiste standaard voor de bewering moet citeren en niet een plausibel klinkende verkeerde.
• Omgang met niet-geverifieerde bewijzen: een rapport over de auditstatus waar de audit nog gaande is. Beoordeelt of het model rapporteert wat is geverifieerd in plaats van voltooiing te beweren die het niet kan ondersteunen.

De anti-manipulatieconstructie die dit veilig maakt om tegen te itereren is het vermelden waard, omdat een versterkte taakset alleen zo betrouwbaar is als de discipline eromheen. De canonieke taak-ID-set is bevroren en gehashd (sha256 over de taak-IDs, de rubrieken en de werkruimtedocumenten, naast het beoordelaarsmodel en de scorer-versie), en een drempeluitslag wordt alleen geaccepteerd op die exacte set: geen subset, geen extra's. Dat maakt het moeilijk om stilletjes de taken te selecteren die een gewenst oordeel opleveren, en een verouderd of handmatig bewerkt rapport kan een release niet stilletjes doorlaten.

De beperkingen hiervan

Eén run per systeem, één beoordelaarsmodel, 14 taken. Een enkele beoordelaar die binaire criteria gradeert kent variatie, wat de reden is dat de winpercentage-drempel op 60% ligt en niet op 50%. De basislijn draaide ook met de echte productiesysteemprompt, maar zonder de herinneringen, opgeslagen vaardigheden en websearch die een live sessie kan hebben, en elk van die hiaten maakt de basislijn zwakker dan een echte basislijn met één beurt, wat de drempel makkelijker maakt voor de uitdager, niet moeilijker. Met andere woorden, de echte basislijn is waarschijnlijk zelfs nog meer verzadigd dan 0,984. Deze cijfers zijn punt-in-tijd zoals van 2026-06-11. We hebben geen drempeluitslag gepubliceerd op de versterkte taakset; het doel van deze post is de mislukking die de eerste run blootlegde, niet een nieuw oordeel.

Dit is een andere mislukking dan een metriek die groen blijft terwijl het product kapotgaat, waar we apart over hebben geschreven. Dat was een getal dat loog. Dit is een getal dat de waarheid vertelde (de basislijn is werkelijk zo sterk op deze taken) en toch het antwoord op de vraag die we stelden niet kon geven. Beide zijn manieren waarop een ogenschijnlijk geslaagde evaluatie waardeloos kan zijn, en ze vragen om tegenovergestelde oplossingen: de eerste heeft een betere metriek nodig, de tweede heeft moeilijkere taken nodig.

Een checklist voor vergelijkende drempels

• Lees de absolute score van de basislijn voordat je het winpercentage vertrouwt. Als de basislijn dicht bij je plafond zit, is je winpercentage-drempel structureel onbereikbaar. Pas de taken aan, voer niet opnieuw uit.
• Houd de gelijkspelratio in de gaten. Een hoop gelijkspelen is een verzadigde rubriek, geen echte gelijkspel. Als de meeste taken gelijkspelen, heeft je set geen ruimte voor beide kanten om te winnen.
• Bepaal wat gelijkspel betekent voordat je het getal leest. Wanneer gelijkspel tegen de uitdager telt, verandert een verzadigde basislijn een beter systeem in een falend vonnis. Dat kan de juiste keuze zijn (de onze was, op kostengronden), maar weet dat je voor deze keuze staat.
• Behandel tegensprekende drempellijnen als diagnostisch. Als je gemiddelde-delta-lijn slaagt terwijl je winpercentage-lijn hard faalt, is dat niet een gemengd resultaat om weg te middelen. Het is verzadiging die zichzelf aankondigt.
• Beoordeel terughoudendheid, niet alleen bekwaamheid. Zodra beide systemen de taak kunnen uitvoeren, zijn de discriminerende fouten overlevering, lekkage naar de doelgroep, overdreven citaten en het beweren van niet-geverifieerde feiten. Schrijf taken waar een sterk model faalt door te veel te doen.
• Ontwerp ten minste één taak die je basislijn zal verliezen. Als niets je systemen van elkaar scheidt, heb je ze niet gemeten. Je hebt je taakset gemeten en gevonden dat deze te eenvoudig was.
• Bevries en hash de canonieke set. Zodat jij of een toekomstige release niet stilletjes de taken kunt selecteren die het antwoord opleveren dat je wilde.

De val is niet dat de basislijn goed was. Goede basislijnen zijn het doel. De val is een winpercentage lezen als een feit over de uitdager wanneer het een feit over de taken was geworden. Wanneer je vergelijking verzadigt, heeft de evaluatie opgehouden je iets te vertellen over je modellen en is begonnen je iets te vertellen over je rubriek. De nuttige zet is naar dat tweede bericht te luisteren, en een taak te schrijven die hard genoeg is om een sterk model te laten falen.

De cijfers hierboven komen uit een interne rechtstreekse vergelijking, uitgevoerd op 2026-06-11, basislijn claude-opus-4-6 (één beurt) tegen een meervoudige plan-uitvoeren-verifiëren-pipeline, beoordeeld door claude-haiku-4-5, over 14 taken op een volledig synthetische werkruimte zonder klantinhoud. Punt-in-tijd zoals van die datum. Kadercontext: ISO/IEC 27001:2022, GDPR (Art. 28, Art. 30).