Zelfherstellende metrics: wanneer een groene evaluatie een echte regressie verbergt
Bij onze multi-document diepte-evaluatie (2026-06-04, GLM-4.7) scoorde een clausule-mappingsmetriek bijna perfect 1.0, terwijl de per-documentanalyse van het model daalde naar ongeveer een derde van de standalone diepte. De voor de hand liggende metriek was degene die loog.
Het gevaarlijkste getal in een evaluatie is het getal dat groen blijft terwijl het product kapot gaat. Wij hebben er een. Op het exacte moment waarop de per-documentuitvoer van ons model daalde naar ongeveer een derde van de standalone diepte, scoorde een pariteitsmetriek bijna perfect 1.0. De metriek was niet luidruchtig of verkeerd gekalibreerd. Hij mat het verkeerde ding, op een manier waarop het model hem kon vervullen zonder het werk te doen. Wij noemen dat een zelfherstellende metriek, en het vinden ervan was het nuttigste wat onze eval-suite die week deed.
Wat we testten
Een veelvoorkomende taak in ons product is multi-documentanalyse: een gebruiker voegt meerdere beleidsdocumenten tegelijk toe en vraagt de assistent om elk daarvan te koppelen aan de clausules van een raamwerk, bijvoorbeeld de Annex A-controles van ISO/IEC 27001:2022. Een klant vertelde ons dat het analyseren van meerdere documenten in één verzoek dunnere resultaten opleverde dan wanneer elk document apart werd geanalyseerd. Voordat we iets veranderden, bouwden we een evaluatie om die kloof te reproduceren en te meten (intern ticket ISM-549, baseline-run 2026-06-04).
De opzet was bewust trouw aan de productieomgeving. Model: GLM-4.7, via OpenRouter, overeenkomend met het geëvalueerde verzoekspad. Testdata: zeven synthetische, geanonimiseerde beleidsdocumenten (geen klantinhoud), gevormd als het echte scenario dat de klacht triggerde. De vraag die de evaluatie moest beantwoorden was eenvoudig: krijgt elk document dezelfde analysediepte wanneer zeven tegelijk worden geanalyseerd als wanneer elk apart wordt geanalyseerd?
De eerste metriek, en waarom hij zichzelf herstelde
De voor de hand liggende manier om te scoren "werd elk document geanalyseerd" is door het aantal clausule-mappingsrijen te tellen. Een standaloneanalyse produceert een tabel met een rij per clausule, dus een gegroepeerde analyse zou dat ook moeten doen. Dat probeerden we eerst.
De rijpariteit kwam uit op ongeveer 1.0. Gegeven expliciete genummerde clausules en de instructie "koppel elke clausule", houdt GLM-4.7 netjes één tabelrij per clausule aan, zelfs wanneer je er zeven documenten tegelijk aan voorlegt. Volgens die metriek was er niets mis. De evaluatie was klaar om te slagen.
Het product was duidelijk slechter. De rijen waren aanwezig; de analyse eromheen was verdwenen. Apart droeg elke clausulerij een uitleg, de sterke punten, de hiaten en een korte samenvatting. Bij gegroepeerde analyse hield het model het skelet vast en haalde de spieren weg: dezelfde tabelvorm, maar veel minder per-clausule-redenering. De metriek had zichzelf hersteld. De uitvoer voldeed aan "één rij per clausule" terwijl het grootste deel van de per-clausuleanalyse verdween, en een rijteltelling kan een volledige analyse niet onderscheiden van een holle.
Wat een betere metriek liet zien
Dus stopten we met het scoren van structuur en begonnen we met het scoren van inhoud. De primaire metriek werd inhoudsvolume-pariteit: gegroepeerde uitvoertekens gedeeld door de som van de standalone uitvoertekens, met een slagboom op 0.6. Op de baseline van 2026-06-04 (GLM-4.7, twee samples):
| Meting | Sample 1 | Sample 2 |
|---|---|---|
| Inhoudsvolume-pariteit | 0.34 | 0.35 |
| Standalone tekens | 48.263 | 47.651 |
| Gegroepeerde tekens | 16.201 | 16.609 |
| Clausule-mappingsrij-pariteit | 1.00 | 0.98 |
| LLM-rechter: documenten niet verdund beoordeeld | 0 van 7 | 0 van 7 |
Op dezelfde baseline van 2026-06-04 vertelde een token-niveau diepteproxy hetzelfde verhaal: ongeveer 2.747 uitvoertokens voor één document, tegen ongeveer 595 tokens per document wanneer de zeven werden gegroepeerd, een per-documentverhouding van 0.22.
Drie details zijn hier belangrijk. De inhoudsvolume-pariteit zat op 0.34, ruim onder de 0.6-slagboom. Een onafhankelijke LLM-rechter, die alleen gevraagd werd om elk document te beoordelen als verdund of niet, beoordeelde 0 van de 7 documenten als niet-verdund in beide samples. Rijpariteit, de metriek die we bijna hadden uitgerold, kwam uit op gemiddeld 0.99 over de twee samples (0.98 tot 1.00). De drie inhoudssignalen wezen allemaal dezelfde kant op: inhoudsvolume-pariteit op ongeveer een derde, de tokenproxy nog lager op 0.22 per document, en de rechter beoordeelde elk gegroepeerd document als verdund. Het enige instrument dat het oneens was, was de structurele rijteltelling.
Waarom het gebeurt, en de grenzen van wat we weten
Onze interpretatie van de data is dat GLM-4.7 zijn inspanningen zelf verdeelt over de documenten in één decode: wanneer gevraagd om zeven analyses in één respons uit te voeren, spreidt het een min of meer vast budget dun uit in plaats van zeven volledige analyses te produceren. We hebben de interne werking van het model niet geïnstrumenteerd, dus dit is een beschrijving van het gedrag dat we maten, geen bewezen mechanisme, en het is specifiek voor dit model en deze verzoeksvorm. Twee scopefeiten zijn cruciaal. De regressie verschijnt op productieschaal: hij doet zich voor bij zeven documenten, niet bij twee, dus een rooktest op een kleine invoer zou schoon zijn gepasseerd. En hij reproduceerde niet toen we dezelfde testdata uitvoerden tegen een state-of-the-artmodel via een directe API. De regressie verscheen alleen op het exacte model en verzoekspad dat we evalueren en uitrollen, wat precies de reden is om het pad te evalueren dat je daadwerkelijk gebruikt in plaats van een handige vervanger.
Waarom dit in compliance erger is dan elders
In de meeste producten is "dunnere uitvoer" een cosmetisch probleem. In onze complianceworkflows is het dat niet: een controle-mappingstabel met elke rij aanwezig en zonder analyse ziet er compleet uit in een screenshot, terwijl een auditor er geen van de per-clausule-redeneringen in vindt die hij nodig zou hebben om erop te kunnen vertrouwen. Dat is wat een zelfherstellende metriek hier echt gevaarlijk maakt. Hij was niet alleen onnauwkeurig. Hij was groen op precies de faalmodus die het meest van belang is in ons domein: een zelfverzekerd ogende deliverable met de inhoud stilletjes verwijderd.
De oplossing die voortvloeit uit deze bevinding is om elk document zijn eigen volledige diepteanalyse te geven in plaats van alle zeven in één decode te stoppen, en de evaluatie slaagt zodra dat gebeurt. Maar de oplossing is het makkelijke deel. We hadden hem niet kunnen bouwen terwijl onze headline-metriek volhield dat er niets mis was. De verandering in metrieken moest eerst komen, want je kunt niet repareren wat je niet kunt zien.
Hoe je een zelfherstellende metriek ontdekt
Een zelfherstellende metriek is elke metriek die een model kan vervullen zonder het onderliggende werk te doen. Structurele metrieken zijn het meest vatbaar hiervoor: rijteltellingen, itemteltellingen, "valide JSON", "alle vereiste velden aanwezig", sectiekoppen. Ze zijn goedkoop te berekenen en goedkoop te manipuleren, vaak door het model zelf in plaats van door jou. Voordat je er een vertrouwt, voer dan deze controles uit:
- Meet inhoud, niet alleen vorm. Als een metriek alleen de structuur controleert (rijen, velden, koppen), koppel er dan een aan die de inhoud controleert (tekens, tokens of een rechter die de grondigheid beoordeelt). Vorm is noodzakelijk, maar nooit voldoende.
- Voeg een onafhankelijk instrument toe. Een goedkope LLM-rechter die de kwaliteit beoordeelt en het oneens is met je headline-metriek is het signaal dat je zoekt. Overeenstemming is bevestiging; een verschil betekent dat je structurele metriek zich waarschijnlijk zelf aan het herstellen is.
- Test op productieschaal. Een regressie die alleen verschijnt bij zeven documenten zal slagen bij twee. Dimensioner je testdata zoals de echte invoer, niet zoals een unittest.
- Test het model en pad dat je uitrolt. Onze verdunning reproduceerde niet op een ander model of via een directe API. Een proxy die makkelijker uit te voeren is, is een proxy die de bug kan missen die alleen jouw productiepaden hebben.
- Vraag je af hoe de goedkoopste geslaagde uitvoer eruitziet. Als een model je metriek kan vervullen terwijl het bijna geen van het echte werk doet, ga er dan van uit dat het dat uiteindelijk ook zal doen. Ontwerp de metriek zo dat de goedkoopste manier om te slagen is om daadwerkelijk de taak uit te voeren.
De evaluatie deed uiteindelijk zijn werk, maar pas nadat we stopten met het vertrouwen van het vleiende getal. Wanneer een metriek groen is, is de nuttigere vraag niet "slagen we?", maar "kan het model deze metriek vervullen zonder het werk te doen?" Als het antwoord ja is, herstelt de metriek zichzelf, en dat zal hij blijven doen tot een klant degene is die het opmerkt.
De bovenstaande cijfers komen van onze interne multi-document dieptepariteit-baseline, uitgevoerd op 2026-06-04 met GLM-4.7 via OpenRouter, en zijn punt-in-tijdgegevens zoals op die datum. Raamwerkcontext: ISO/IEC 27001:2022, Annex A.