🤖 machine learning

Auditing the Audit: Five Failure Modes in Benchmark-Validity Audits

Dit artikel betoogt dat perturbatiegebaseerde audits op constructvaliditeit voor AI-modellen fragiel zijn en vatbaar zijn voor stille implementatiefouten, waarbij een zespuntige due-diligence-poort wordt voorgesteld om niet-bevestigend bewijs achter te houden, terwijl wordt aangetoond dat een specifieke casestudy van veiligheidsbenchmarks en open-weight modellen niet voldoet aan de bevestigende standaarden onder deze nieuwe taxonomie van vijf auditfoutmodi.

Oorspronkelijke auteurs: Yanhang Li, Zhichao Fan, Zexin Zhuang

Gepubliceerd 2026-07-07

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Yanhang Li, Zhichao Fan, Zexin Zhuang

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een inspecteur voor voedselveiligheid bent. Jouw taak is om te controleren of het "Gezonde Menu" van een restaurant ook echt gezond is. Om dit te doen, proef je niet alleen het eten; je voert een speciale test uit waarbij je ingrediënten verwisselt (zoals suiker voor zout verwisselen) om te zien of het voedingslabel correct verandert. Als het label hetzelfde blijft wanneer je suiker voor zout verwisselt, weet je dat de test kapot is.

Dit artikel gaat over het auditeren van de auditors. De auteurs stellen dat de instrumenten en checklists die we gebruiken om AI-veiligheid te verifiëren, zelf fragiel zijn. Ze kunnen op subtiele wijze worden gebroken, waardoor de resultaten er perfect uitzien, zelfs als het hele proces gebrekkig is.

Hier is de uiteenzetting van hun bevindingen, met behulp van eenvoudige analogieën:

Het kernproblef: De "Gebroken Liniaal"

De auteurs zeggen dat wanneer bedrijven of onderzoekers AI-modellen testen, ze "perturbatie-audits" gebruiken. Dit betekent dat ze de vragen aanpassen (de "perturbatie") om te zien of het antwoord van de AI verandert zoals het zou moeten.

De bewering: Deze audits zijn als linialen van rubber. Soms rekt het rubber uit of knapt het op een manier die doet voorkomen alsof de meting klopt, maar het liegt eigenlijk.
Het gevaar: Een toezichthouder (zoals een overheidsinstantie) kan naar het definitieve getal kijken (bijv. "95% Veilig!") en dit vertrouwen, zonder te beseffen dat de "liniaal" die gebruikt werd om dat getal te verkrijgen, gebroken was.

De 5 manieren waarop de audit kan falen (De "Vijf Foutmodi")

De auteurs ontdekten vijf specifieke manieren waarop deze audit-pipelines stilzwijgend kunnen falen. Ze splitsen deze op in twee groepen: Softwarefouten (de machine is kapot) en Meetfouten (de logica is fout).

Groep 1: De Softwarefouten (De machine is kapot)

Dit zijn bugs waarbij de computercode simpelweg niet doet wat het moet doen.

De "Ghost Edit" (F1): Stel je voor dat je een chef vertelt: "Vervang het zout door suiker." Maar de chef negeert de notitie en houdt het zout. De audit denkt dat de verwisseling heeft plaatsgevonden, maar de AI heeft het nooit gezien. De test wordt uitgevoerd, maar de AI beantwoordt de oude vraag. Het resultaat ziet eruit als een perfecte score, maar het is een leugen omdat de AI eigenlijk niet getest is.
De "Slechte Vertaler" (F2): Stel je voor dat de AI een lange, rommelige zin schrijft, en een robot probeert deze te lezen. Als de robot alleen zinnen begrijpt die met "De" beginnen, en de AI schrijft "Het is...", dan slaagt de robot er niet in de zin te lezen. Als de AI zijn schrijfstijl licht verandert, kan de robot het plotseling wel begrijpen. De audit denkt dat de AI van gedrag is veranderd, maar in werkelijkheid is de robot gewoon beter geworden in lezen.
De "Gebroken Koppeling" (F4): Stel je voor dat je test of een auto sneller is op een nieuw circuit. Je tijdt de auto op het oude circuit, en daarna tijdt je de auto op het nieuwe circuit. Maar als je voor de tweede ronde een andere auto gebruikt, is je vergelijking waardeloos. In de audit, als ze niet exact dezelfde "vraag" koppelen aan de "aangepaste versie" ervan, wordt de wiskunde rommelig en zien de veiligheidsmarges er nep uit.

Groep 2: De Meetfouten (De logica is fout)

Dit zijn bugs waarbij de code wel werkt, maar de manier waarop de resultaten worden geïnterpreteerd gebrekkig is.

De "Verwarde Scorekeeper" (F3): Dit is een familie van fouten waarbij de persoon (of code) die de score bijhoudt, naar het verkeerde ding kijkt.
- Inverted Convention (Omgekeerde Conventie): Stel je een spel voor waarbij "1" "Goed" betekent en "0" "Slecht". De scorekeeper denkt per ongeluk dat "1" "Slecht" betekent. Ze rapporteren dat de AI verschrikkelijk is, terwijl hij eigenlijk geweldig is.
- Order Bias (Orde-bias): Stel je een meerkeuzetoets voor waarbij het juiste antwoord altijd de eerste optie is. De AI kiest elke keer de eerste optie. De scorekeeper zegt: "Wauw, 100% nauwkeurigheid!", maar de AI drukt gewoon steeds de eerste knop in.
- De "Truncation" Bug (Afkortingsfout): De auteurs vonden een bug die ze zelf hadden geïntroduceerd terwijl ze een andere bug probeerden te repareren. Ze lieten de AI de top 50 antwoorden kiezen, maar het juiste antwoord was nummer 51. De AI kon het niet zien, dus koos hij gewoon het meest voorkomende antwoord. De audit liet een vlakke lijn zien (geen verandering), waardoor het leek alsof de AI immuun was voor de test, terwijl de test de echte reactie van de AI simpelweg niet kon zien.
De "Verkeerde Tool voor de Taak" (F5): Stel je voor dat je probeert te meten hoe "zwaar" een veer is met een weegschaal die ontworpen is voor olifanten. De weegschaal geeft "0" aan, wat technisch gezien correct is, maar het instrument is nutteloos voor deze taak. Sommige veiligheidsbenchmarks zijn ontworpen om te zien of een AI van gedachten verandert wanneer je een detail aanpast (Diagnostisch). Andere zijn ontworpen om te zien of een AI hetzelfde blijft (Invariantie). Als je een "veranderings-test" gebruikt op een "invariantie-benchmark", zal de wiskunde er gebrekkig uitzien, zelfs als de AI perfect is.

De Oplossing: De "Zes-Punten Poort"

De auteurs stellen een nieuwe checklist (een "poort") voor die elke audit moet passeren voordat de resultaten vertrouwd kunnen worden. Denk aan dit als een controlepunt.

De Poort: Voordat je kunt zeggen: "Deze AI is veilig," moet je 6 controles passeren (G1–G6).
- Is de aanpassing daadwerkelijk de AI bereikt?
- Is de score boven een basislijn?
- Is de wiskunde statistisch solide?
- Zijn we gecontroleerd op de "Verwarde Scorekeeper"-bugs?
- Hebben we bekendgemaakt wat voor soort test we uitvoeren?
- Hebben we gecontroleerd op bugs die we hebben geïntroduceerd tijdens het oplossen van andere bugs?

Het Resultaat: Een Reality Check

De auteurs hebben deze "Zes-Punten Poort" toegepast op hun eigen audit van 10 verschillende AI-tests (met gebruik van 2 modellen en 5 benchmarks).

De schokkende resultaat: Nul van de 10 tests passeerde de poort om als "Bevestigend" (volledig vertrouwd) te worden beschouwd.

3 waren Ongeschikt (de test was vanaf het begin gebrekkig).
3 waren Ongevalideerd (we vertrouwen de scorekeeper niet).
2 Faalden de wiskundige controles.
2 waren Exploratief (interessant, maar nog niet klaar voor het grote publiek).

De Belangrijkste Boodschap

De auteurs zeggen niet: "AI is onveilig." Ze zeggen: "We kunnen de rapporten die zeggen dat AI veilig (of onveilig) is, nog niet vertrouwen."

Ze betogen dat men, voordat men een benchmark-getal vertrouwt, een "Self-Audit Chronology" moet publiceren. Dit is als een logboek van een monteur:

"Hier is de bug die we vonden."
"Hier is hoe we het hebben opgelost."
"Hier is hoe het getal veranderde vóór en na de fix."
"Hier is een bug die we per ongeluk hebben geïntroduceerd terwijl we de eerste bug oplosten."

De Kernboodschap: Als je een schoon, perfect getal ziet van een AI-audit zonder een rommelig, eerlijk logboek van alle bugs en fixes die nodig waren om daar te komen, vertrouw het dan niet. Het getal kan slechts een "silent no-op" zijn—een ghost edit waarbij er in feite niets is gebeurd.

Technische Samenvatting: Het auditen van de audit – Vijf faalmodi in benchmark-validiteitsaudits

1. Probleemstelling

Governance-frameworks (bijv. de EU AI Act, NIST AI RMF, China's GB/T 45654) vereisen steeds vaker dat AI-aanbieders gedocumenteerd evaluatiebewijs leveren, vaak in de vorm van perturbatie-gebaseerde construct-validiteitsaudits. Deze audits passen gecontroleerde wijzigingen toe op benchmark-items om te verifiëren dat de prestatie-indicatoren van een model alleen verschuiven wanneer het onderliggende construct verandert (bijv. een semantische flip) en stabiel blijven onder oppervlakkige herschrijvingen.

Het artikel betoogt dat deze audit-pipelines zelf fragiele meetsystemen zijn. Hun conclusies kunnen stilzwijgend worden gefabriceerd door implementatiedetails die onzichtbaar zijn in gerapporteerde cijfers. Een defect in de audit-pipeline corrumpeert niet alleen een benchmark-score; het schakelt de beveiliging uit die bedoeld is om benchmark-fouten te detecteren, waardoor er geen spoor achterblijft in de uiteindelijke metrieken omdat de lezer juist op die metrieken vertrouwt om te beslissen of hij de benchmark kan vertrouwen. Het centrale probleem is dat huidige governance-bewijslast vaak geen protocol bevat om de betrouwbaarheid van de audit-pipeline zelf te verifiëren.

2. Methodologie

De auteurs voeren een zelf-audit case study uit om aan te tonen dat audit-pipelines gevoelig zijn voor stille fouten.

Reikwijdte: Twee open-weight 7B instructie-afgestemde modellen (Qwen-2.5-7B-Instruct, Mistral-7B-Instruct-v0.3) geëvalueerd tegen vijf veiligheidsbenchmarks (TruthfulQA, BBQ, ToxiGen, CrowS-Pairs, XSTest).
Ontwerp: 10 cellen (2 modellen × 5 benchmarks), 200 items per benchmark, deterministische decodering, enkele seed.
Perturbaties: Drie families per item (formaat, semantiek, attribuut) met elk drie perturbaties.
Metriek: Contrast Selectivity Ratio (CSR), gedefinieerd als $| \Delta_{attr} | / \max(| \Delta_{fmt} |, | \Delta_{sem} |, \epsilon)$ . Dit meet of attribuut-perturbaties grotere scoreveranderingen induceren dan oppervlakkige perturbaties.
Proces: De auteurs draaiden een "legacy" pipeline, identificeerden fouten, herstelden deze om een "canonieke" pipeline te creëren, en draaiden de audit opnieuw. Cruciaal is dat zij het volledige chronologische verloop van bugs bijhielden, inclus inclusief één fout (F3c) die tijdens de herstelfase werd geïntroduceerd.

3. Belangrijkste Bijdragen

A. De Vijf Faalmodi (F1–F5)

Het artikel stelt een niet-uitputtende taxonomie voor van pipeline-niveau fouten die stil (onzichtbaar in gerapporteerde cijfers), gerealiseerd (geëcounterd in de praktijk) en gateable (detecteerbaar via specifieke controles) zijn. Ze worden gecategoriseerd in twee lagen:

Software-Assurance Laag (Detecteerbaar via engineering review):

F1: Stille no-op perturbaties: De perturbatie schrijft naar een veld dat de scorer niet leest (bijv. het bewerken van een vraag-string terwijl de scorer alleen kansen van keuzes leest). Dit resulteert in $\Delta = 0$ voor de perturbatie, wat de ratio-metrieken kunstmatig opblaast.
F2: Regex-extractie artefacten: Het gebruik van regex om vrije generatie te parsen, meet de robuustheid van de regex in plaats van het gedrag van het model. Als perturbaties de generatiestijl verschuiven, daalt de parseerbaarheid, en volgt $\Delta_{fmt}$ de regex-dekking in plaats van het modelgedrag.
F4: Gebroken bootstrap-koppeling: Het onafhankelijk her-samplen van originele en geperturbeerde items verbreekt de per-item koppeling, wat de betrouwbaarheidsintervallen en variantieschattingen kunstmatig verhoogt.

Measurement-Faithfulness Laag (Vereist redeneren over het construct van de benchmark):
4. F3: Niet-getrouwe scoring: De scorer implementeert niet het beoogde protocol van de benchmark.
* F3a (Inverteerde conventie): Een stereotypische zin als "correct" behandelen door naïeve loading (bijv. CrowS-Pairs).
* F3b (Harness ordering): Positionele bias in loaders (bijv. TruthfulQA MC2 die correcte indices teruggeeft als $[0, \dots, k-1]$ ).
* F3c (Scorer truncatie): Target-tokens vallen buiten de top- $k$ log-probabiliteiten (bijv. ToxiGen), waardoor de scorer terugvalt op een meerderheidsklasse en $\Delta = 0$ artefacten produceert.
5. F5: Metric-archetype mismatch: Het toepassen van een diagnostische metriek (ontworpen om flips te detecteren) op een invariantie-benchmark (ontworpen om niet te flippen). Een lage CSR op een invariantie-benchmark is ambigu (gebroken benchmark vs. eerlijk model) en kan niet worden opgelost door scoring-herstel.

B. De Zes-Punten Due-Diligence Gate (G1–G6)

Een hiërarchisch protocol om de geschiktheid van audit-bewijslast te bepalen. Een cel is pas "bevestigend" als deze alle zes controles doorstaat. De gate omvat:

G1: Scorer-getrouwe audit (stille no-op rate < 20%, parseerbaarheid $\ge$ 0.95).
G2: Boven-baseline originele score.
G3: Niet-triviale noemer (oppervlakkige deltas $\ge$ 0.02).
G4: Gepaarde onzekerheid: (Item-niveau gepaarde bootstrap).
G5: Archetype disclosure: Benchmark gelabeld als diagnostisch, invariantie of gemengd.
G6: Repair-regression check: Per-cel inspectie en unit tests voor fixes.

C. Self-Audit Chronology Protocol

De auteurs stellen een "withholding and disclosure" protocol voor dat vereist dat audits een zelf-audit chronologie (Box 1) publiceren die elk gevonden bug, de ontdekkingsmethode, de fix en de voor/na delta detailleert. Dit onderscheidt een "schone" pipeline van een waarbij bugs stilzwijgend zijn geabsorbeerd.

4. Resultaten

In de 10-cell case study bereikte nul cellen de "confirmatory" status. De uitslag was:

3 Ongeschikt: Vanwege F1 (CrowS-Pairs) of F5 (BBQ).
3 Niet door scorer gevalideerd: Vanwege gebrek aan externe validatie voor de ToxiGen en XSTest scorers.
2 Gefaald op G2–G4: Door het niet halen van numerieke gates (baseline score of drempelwaarden voor de noemer).
2 Exploratief: Voldoen aan G1–G4, maar gehouden als niet-bevestigend omdat G5 en G6 "voorgesteld" waren (nog niet geïmplementeerd als verplichte gates in deze indiening).

Belangrijkste bevinding: Eén fout (F3c, scorer truncatie) werd zelf geïntroduceerd tijdens het herstel van F1. Deze werd pas gedetecteerd na inspectie van de per-cel meta log-probabiliteiten. Zonder deze inspectie zou de pipeline plausibele, publiceerbare cijfers hebben geproduceerd die volledig artefacten van de bug waren.

5. Betekenis en Claims

Het artikel positioneert zijn bijdragen als aanvullend op klassieke construct-validiteit bewijslast (convergentie/discriminatie studies), niet als een vervanging.

Bescheiden claim: De auteurs beweren niet te hebben bewezen dat enige benchmark ongeldig is of dat F1–F5 een volledige taxonomie is. Ze stellen expliciet dat de taxonomie "bewust niet-uitputtend" is.
Kernargument: De primaire bijdrage is een withholding protocol. Governance-bewijs zou niet als "assurance-grade" geaccepteerd moeten worden, tenzij de audit-pipeline zelf een due-diligence gate heeft doorstaan en een zelf-audit chronologie heeft gepubliceerd.
Implicatie: Een "schoon" getal in een rapport garandeert geen betrouwbare pipeline. Zonder de voorgestelde gate en chronologie is een stilzwijgend gebroken pipeline niet te onderscheiden van een robuuste pipeline.

Het artikel concludeert met een enkel, actiegericht verzoek: Elke audit die benchmark-gebaseerd bewijs produceert voor governance-gebruik, moet naast haar cijfers ook haar zelf-audit chronologie publiceren (minimaal de acht velden in Box 1).