🤖 machine learning

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

Dieses Paper argumentiert, dass störungsbasierte Audits der Konstruktvalidität für KI-Modelle fragil und anfällig für stille Implementierungsfehler sind, schlägt ein sechsstufiges Due-Diligence-Gate vor, um nicht-konfirmatorische Evidenz zurückzuhalten, und demonstriert dabei, dass eine spezifische Fallstudie von Sicherheits-Benchmarks und Open-Weight-Modellen unter dieser neuen Taxonomie von fünf Audit-Fehlermodi die konfirmatorischen Standards nicht erfüllt.

Ursprüngliche Autoren: Yanhang Li, Zhichao Fan, Zexin Zhuang

Veröffentlicht 2026-07-07

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Yanhang Li, Zhichao Fan, Zexin Zhuang

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Lebensmittelsicherheitsinspektor. Ihr Job ist es zu prüfen, ob die „gesunde Speisekarte“ eines Restaurants tatsächlich gesund ist. Um dies zu tun, probieren Sie nicht nur das Essen; Sie führen einen speziellen Test durch, bei dem Sie Zutaten austauschen (wie Zucker gegen Salz zu tauschen), um zu sehen, ob sich das Nährwertetikett korrekt verändert. Wenn das Etikett gleich bleibt, wenn Sie Zucker gegen Salz austauschen, wissen Sie, dass der Test fehlerhaft ist.

Dieses Papier handelt von der „Auditierung der Auditoren“. Die Autoren argumentieren, dass die Werkzeuge und Checklisten, die wir zur Verifizierung der KI-Sicherheit verwenden, selbst fragil sind. Sie können auf subtile Weise manipuliert werden, sodass die Ergebnisse perfekt aussehen, selbst wenn der gesamte Prozess fehlerhaft ist.

Hier ist die Aufschlüsselung ihrer Erkenntnisse, unter Verwendung einfacher Analogien:

Das Kernproblem: Das „kaputte Lineal“

Die Autoren sagen, dass Unternehmen oder Forscher, wenn sie KI-Modelle testen, „Perturbations-Audits“ verwenden. Das bedeutet, sie verändern die Fragen (die „Perturbation“), um zu sehen, ob sich die Antwort der KI so verändert, wie sie es sollte.

Die Behauptung: Diese Audits sind wie Lineale aus Gummi. Manchmal dehnt oder bricht das Gummi auf eine Weise, die die Messung richtig aussehen lässt, die aber eigentlich lügt.
Die Gefahr: Ein Regulator (wie eine Regierungsbehörde) könnte sich auf die endgültige Zahl beziehen (z. B. „95 % Sicher!“) und ihr vertrauen, ohne zu merken, dass das „Lineal“, mit dem diese Zahl ermittelt wurde, kaputt war.

Die 5 Arten des Scheiterns (Die „Fünf Failure Modes“)

Die Autoren fanden fünf spezifische Wege, wie diese Audit-Pipelines lautlos versagen können. Sie teilen diese in zwei Gruppen auf: Software-Fehler (die Maschine ist kaputt) und Messfehler (die Logik ist falsch).

Gruppe 1: Die Software-Fehler (Die Maschine ist kaputt)

Dies sind Bugs, bei denen der Computercode einfach nicht das tut, was er soll.

Der „Geister-Edit“ (F1): Stellen Sie sich vor, Sie sagen einem Koch: „Tausche das Salz gegen Zucker aus.“ Aber der Koch ignoriert die Notiz und behält das Salz. Das Audit denkt, der Austausch sei erfolgt, aber die KI hat ihn nie gesehen. Der Test läuft, aber die KI beantwortet die alte Frage. Das Ergebnis sieht nach einer perfekten Punktzahl aus, aber es ist eine Lüge, weil die KI gar nicht wirklich getestet wurde.
Der „Schlechte Übersetzer“ (F2): Stellen Sie sich vor, die KI schreibt einen langen, unordentlichen Satz, und ein Roboter versucht, ihn zu lesen. Wenn der Roboter nur Sätze versteht, die mit „Der/Die/Das“ beginnen, und die KI schreibt „Es ist...“, dann scheitert der Roboter beim Lesen. Wenn die KI ihren Schreibstil leicht ändert, könnte der Roboter plötzlich in der Lage sein, sie zu verstehen. Das Audit denkt, die KI hätte ihr Verhalten geändert, aber eigentlich hat sich nur der Roboter beim Lesen verbessert.
Die „Defekte Paarung“ (F4): Stellen Sie sich vor, Sie testen, ob ein Auto auf einer neuen Strecke schneller ist. Sie messen die Zeit des Autos auf der alten Strecke und dann die Zeit auf der neuen Strecke. Aber wenn Sie für den zweiten Durchgang ein anderes Auto verwenden, ist Ihr Vergleich nutzlos. Im Audit gilt das Gleiche: Wenn sie nicht exakt dieselbe „Frage“ mit ihrer „veränderten Version“ paaren, wird die Mathematik unsauber und die Sicherheitsmargen wirken künstlich.

Gruppe 2: Die Messfehler (Die Logik ist falsch)

Dies sind Bugs, bei denen der Code zwar funktioniert, aber die Art und Weise, wie die Ergebnisse interpretiert werden, fehlerhaft ist.

Der „Verwirrte Punktezähler“ (F3): Dies ist eine Familie von Fehlern, bei denen die Person (oder der Code), die die Punkte zählt, auf das falsche Merkmal schaut.
- Invertierte Konvention: Stellen Sie sich ein Spiel vor, bei dem „1“ für „Gut“ und „0“ für „Schlecht“ steht. Der Punktezähler denkt versehentlich, dass „1“ für „Schlecht“ steht. Er meldet, die KI sei schrecklich, obwohl sie eigentlich großartig ist.
- Reihenfolge-Bias: Stellen Sie sich einen Multiple-Choice-Test vor, bei dem die richtige Antwort immer die erste Option ist. Die KI wählt einfach immer die erste Option. Der Punktezähler sagt: „Wow, 100 % Genauigkeit!“, aber die KI drückt einfach nur immer den ersten Knopf.
- Der „Truncation“-Bug (Abschneide-Fehler): Die Autoren fanden einen Bug, den sie selbst eingeführt haben, während sie einen anderen Bug behoben haben. Sie sagten der KI, sie solle die obersten 50 Antworten wählen, aber die richtige Antwort war die 51. Die KI konnte sie nicht sehen, also griff sie auf die häufigste Antwort zurück. Das Audit zeigte eine flache Linie (keine Veränderung), was es so aussehen ließ, als sei die KI immun gegen den Test, während der Test in Wirklichkeit die echte Antwort der KI gar nicht erfassen konnte.
Das „Falsche Werkzeug für den Job“ (F5): Stellen Sie sich vor, Sie versuchen zu messen, wie „schwer“ eine Feder ist, indem Sie eine Waage benutzen, die für Elefanten gebaut wurde. Die Waage zeigt „0“ an, was technisch gesehen korrekt ist, aber das Werkzeug ist für diese Aufgabe unbrauchbar. Einige Sicherheits-Benchmarks sind darauf ausgelegt zu sehen, ob eine KI ihre Meinung ändert, wenn man ein Detail ändert (Diagnostisch). Andere sind darauf ausgelegt zu sehen, ob eine KI gleich bleibt (Invarianz). Wenn man einen „Veränderungs-Test“ auf einem „Invarianz-Benchmark“ anwendet, wird die Mathematik fehlerhaft aussehen, selbst wenn die KI perfekt ist.

Die Lösung: Das „Sechs-Punkte-Gate“

Die Autoren schlagen ein neues Checklist-System (ein „Gate“) vor, das jedes Audit passieren muss, bevor seine Ergebnisse vertrauenswürdig sind. Denken Sie an dies als eine Sicherheitskontrolle.

Das Gate: Bevor man sagen kann: „Diese KI ist sicher“, muss man 6 Prüfungen (G1–G6) bestehen:
- Ist die Änderung tatsächlich bei der KI angekommen?
- Liegt die Punktzahl über einer Basislinie?
- Ist die Mathematik statistisch fundiert?
- Wurden die Fehler des „Verwirrten Punktezählers“ geprüft?
- Haben wir offengelegt, welche Art von Test wir gerade durchführen?
- Haben wir nach Bugs gesucht, die wir selbst beim Beheben anderer Bugs eingeführt haben?

Das Ergebnis: Ein Realitätscheck

Die Autoren wendeten dieses „Sechs-Punkte-Gate“ auf ihr eigenes Audit von 10 verschiedenen KI-Tests an (unter Verwendung von 2 Modellen und 5 Benchmarks).

Das schockierende Ergebnis: Keiner der 10 Tests bestand das Gate, um als „konfirmatorisch“ (vollständig vertrauenswürdig) zu gelten.

3 waren unzulässig (der Test war von vornherein fehlerhaft).
3 waren unvalidiert (wir vertrauen dem Punktezähler nicht).
2 scheiterten an den mathematischen Prüfungen.
2 waren explorativ (interessant, aber noch nicht bereit für den Ernstfall).

Die wichtigste Erkenntnis

Die Autoren sagen nicht, dass „KI unsicher ist“. Sie sagen: „Wir können den Berichten, die behaupten, dass KI sicher (oder unsicher) ist, noch nicht trauen.“

Sie argumenten, dass die Personen, die den Test durchführen, vor einem Benchmark-Wert eine „Selbst-Audit-Chronologie“ veröffentlichen müssen. Das ist wie das Logbuch eines Mechanikers:

„Hier ist der Bug, den wir gefunden haben.“
„Hier ist, wie wir ihn behoben haben.“
„Hier ist, wie sich die Zahl vor und nach der Korrektur verändert hat.“
„Hier ist ein Bug, den wir versehentlich eingeführt haben, während wir den ersten Bug behoben haben.“

Das Fazit: Wenn Sie eine saubere, perfekte Zahl aus einem KI-Audit sehen, ohne ein unordentliches, ehrliches Logbuch aller Bugs und Fixes, die zu dieser Zahl geführt haben, vertrauen Sie ihr nicht. Die Zahl könnte einfach ein „Silent No-Op“ sein – ein Geister-Edit, bei dem eigentlich gar nichts passiert ist.

Technisches Resümee: Das Audit des Audits – Fünf Ausfallmodi in Benchmark-Validitäts-Audits

1. Problemstellung

Governance-Frameworks (z. B. EU AI Act, NIST AI RMF, Chinas GB/T 45654) fordern zunehmend von KI-Anbietern, dokumentierte Evaluationsnachweise zu erbringen, oft in Form von perturbationsbasierten Konstrukt-Validitäts-Audits. Diese Audits wenden kontrollierte Änderungen an Benchmark-Elementen an, um zu verifizieren, dass sich die Leistungsmetriken eines Modells nur dann ändern, wenn sich das zugrunde liegende Konstrukt ändert (z. B. ein semantischer Flip), und stabil bleiben, wenn es sich lediglich um oberflächliche Umformulierungen handelt.

Das Paper argumentiert, dass diese Audit-Pipelines selbst fragile Messsysteme sind. Ihre Schlussfolgerungen können durch Implementierungsdetails manipuliert werden, die in den berichteten Zahlen unsichtbar sind. Ein Defekt in der Audit-Pipeline korrumpiert nicht bloß einen Benchmark-Score; er deaktiviert die Sicherung, die dazu gedacht war, Benchmark-Fehler zu erkennen, und hinterlässt keine Spur in den Endmetriken, da der Leser sich auf eben jene Metriken verlässt, um zu entscheiden, ob er dem Benchmark vertrauen kann. Das zentrale Problem besteht darin, dass aktuelle Governance-Evidenz oft keinen Protokollstandard zur Verifizierung der Vertrauenswürdigkeit der Audit-Pipeline selbst besitzt.

2. Methodik

Die Autoren führen eine Selbst-Audit-Fallstudie durch, um zu demonstrieren, dass Audit-Pipelines anfällig für stille Ausfälle sind.

Umfang: Zwei Open-Weight 7B Instruction-Tuned Modelle (Qwen-2.5-7B-Instruct, Mistral-7B-Instruct-v0.3), evaluiert gegen fünf Safety-Benchmarks (TruthfulQA, BBQ, ToxiGen, CrowS-Pairs, XSTest).
Design: 10 Zellen (2 Modelle × 5 Benchmarks), 200 Items pro Benchmark, deterministisches Decoding, einzelner Seed.
Perturbationen: Drei Familien pro Item (Format, Semantik, Attribut) mit jeweils drei Perturbationen.
Metrik: Contrast Selectivity Ratio (CSR), definiert als $| \Delta_{attr} | / \max(| \Delta_{fmt} |, | \Delta_{sem} |, \epsilon)$ . Dies misst, ob Attribut-Perturbationen größere Score-Änderungen induzieren als Oberflächen-Perturbationen.
Prozess: Die Autoren führten eine „Legacy“-Pipeline aus, identifizierten Fehler, reparierten diese zur Erstellung einer „kanonischen“ Pipeline und führten das Audit erneut durch. Entscheidend ist, dass sie die gesamte Chronologie der Bugs verfolgten, einschließlich eines Fehlers (F3c), der während der Reparaturphase eingeführt wurde.

3. Zentrale Beiträge

A. Die fünf Ausfallmodi (F1–F5)

Das Paper schlägt eine nicht erschöpfende Taxonomie von Pipeline-Ebene-Fehlern vor, die still (unsichtbar in den berichteten Zahlen), realisiert (in der Praxis auftretend) und gatebar (detektierbar über spezifische Prüfungen) sind. Sie werden in zwei Ebenen kategorisiert:

Software-Assurance-Ebene (detektierbar via Engineering-Review):

F1: Stille No-Op-Perturbationen: Die Perturbation schreibt in ein Feld, das der Scorer nicht liest (z. B. das Editieren eines Frage-Strings, während der Scorer nur Antwort-Wahrscheinlichkeiten liest). Dies führt zu einem $\Delta = 0$ für die Perturbation und bläht die Ratio-Metriken künstlich auf.
F2: Regex-Extraktionsartefakte: Die Verwendung von Regex zum Parsen von Free-Form-Generierungen misst eher die Robustheit der Regex als das Modellverhalten. Wenn Perturbationen den Generierungsstil verschieben, sinkt die Parsbarkeit, und $\Delta_{fmt}$ bildet die Regex-Abdeckung ab, nicht das Modellverhalten.
F4: Unterbrochene Bootstrap-Paarung: Das unabhängige Resampling von Original- und perturbierten Items bricht die Paarung auf Item-Ebene auf, was Konfidenzintervalle und Varianzschätzungen künstlich aufbläht.

Messungs-Treue-Ebene (erfordert Abwägung des Benchmark-Konstrukts):
4. F3: Nicht-treue Scoring-Verfahren: Der Scorer implementiert nicht das intendierte Protokoll des Benchmarks.
* F3a (Invertierte Konvention): Einen stereotypen Satz aufgrund naiver Ladung als „korrekt“ zu behandeln (z. B. CrowS-Pairs).
* F3b (Harness-Ordering): Positionale Verzerrung in Loadern (z. B. TruthfulQA MC2, das korrekte Indizes als $[0, \dots, k-1]$ zurückgibt).
* F3c (Scorer-Truncation): Ziel-Tokens fallen außerhalb der Top- $k$ Log-Wahrscheinlichkeiten (z. B. ToxiGen), was dazu führt, dass der Scorer auf eine Mehrheitsklasse zurückfällt und $\Delta = 0$ Artefakte produziert.
5. F5: Metrik-Archetyp-Mismatch: Anwendung einer diagnostischen Metrik (die Flips detektieren soll) auf einen Invarianz-Benchmark (der darauf ausgelegt ist, nicht zu flippen). Ein niedriger CSR auf einem Invarianz-Benchmark ist mehrdeutig (kaputter Benchmark vs. faires Modell) und kann durch Scoring-Reparaturen nicht aufgelöst werden.

B. Das Sechs-Punkte-Due-Diligence-Gate (G1–G6)

Ein hierarchisches Protokoll, um die Eignung von Audit-Evidenz zu bestimmen. Eine Zelle ist nur dann „konfirmatorisch“, wenn sie alle sechs Prüfungen besteht. Das Gate umfasst:

G1: Scorer-treues Audit (stille No-Op-Rate < 20 %, Parsbarkeit $\ge$ 0,95).
G2: Score über Baseline.
G3: Nicht-trivialer Nenner (Oberflächen-Deltas $\ge$ 0,02).
G4: Gepaarte Unsicherheit (Item-Level Paired Bootstrap).
G5: Archetyp-Offenlegung (Benchmark als diagnostisch, Invarianz oder gemischt deklariert).
G6: Repair-Regression-Check (Per-Zell-Inspektion und Unit-Tests für Fixes).

C. Selbst-Audit-Chronologie-Protokoll

Die Autoren schlagen ein „Withholding-and-Disclosure“-Protokoll vor, das Audits dazu verpflichtet, eine Selbst-Audit-Chronologie (Box 1) zu veröffentlichen, die jeden gefundenen Bug, die Entdeckungsmethode, den Fix sowie das Vorher/Nachher-Delta detailliert beschreibt. Dies unterscheidet eine „saubere“ Pipeline von einer, in der Bugs stillschweigend absorbiert wurden.

4. Ergebnisse

In der 10-Zellen-Fallstudie erreichte keine einzige Zelle den Status „konfirmatorisch“. Die Aufschlüsselung war:

3 Unzulässig: Aufgrund von F1 (CrowS-Pairs) oder F5 (BBQ).
3 Scorer-unvalidiert: Aufgrund fehlender externer Validierung für ToxiGen- und XSTest-Scorer.
2 Fehlgeschlagen bei G2–G4: Aufgrund des Scheiterns numerischer Gates (Baseline-Score oder Nenner-Schwellenwerte).
2 Explorativ: Bestanden G1–G4, wurden aber als nicht konfirmatorisch eingestuft, da G5 und G6 „vorgeschlagen“ (noch nicht als obligatorische Gates in dieser Einreichung implementiert) waren.

Zentrale Erkenntnis: Ein Fehler (F3c, Scorer-Truncation) wurde selbst eingeführt während der Reparatur von F1. Er wurde erst nach der Inspektion der pro-Zell Meta-Log-Wahrscheinlichkeiten entdeckt. Oh\ne dieser Inspektion hätte die Pipeline plausible, publizierbare Zahlen geliefert, die jedoch vollständig Artefakte des Bugs gewesen wären.

5. Bedeutung und Ansprüche

Das Paper positioniert seine Beiträge als ergänzend zu klassischer Konstrukt-Validitäts-Evidenz (Konvergenz-/Diskriminanzstudien), nicht als Ersatz.

Bescheidener Anspruch: Die Autoren behaupten nicht, dass irgendein Benchmark ungültig ist oder dass F1–F5 eine vollständige Taxonomie darstellt. Sie betonen explizit, dass die Taxonomie „bewusst nicht erschöpfend“ ist.
Kernargument: Der primäre Beitrag ist ein Withholding-Protokoll. Governance-Evidenz sollte nicht als „Assurance-Grade“ akzeptiert werden, es sei denn, die Audit-Pipeline selbst hat ein Due-Diligence-Gate bestanden und eine Selbst-Audit-Chronologie veröffentlicht.
Implikation: Eine „saubere“ Zahl in einem Bericht garantiert nicht eine vertrauenswürdige Pipeline. Ohne das vorgeschlagene Gate und die Chronologie ist eine stillschweigend defekte Pipeline nicht von einer robusten zu unterscheiden.

Das Paper schließt mit einer einzigen, handlungsorientierten Aufforderung: Jedes Audit, das Benchmark-basierte Evidenz für Governance-Zwecke produziert, sollte seine Selbst-Audit-Chronologie (mindestens die acht Felder in Box 1) zusammen mit seinen Zahlen veröffentlichen.