Résumé technique : Auditer l'audit – Cinq modes de défaillance dans les audits de validité des benchmarks

1. Énoncé du problème

Les cadres de gouvernance (par exemple, l'IA Act de l'UE, le NIST AI RMF, le GB/T 45654 de la Chine) exigent de plus en plus que les fournisseurs d'IA fournissent des preuves d'évaluation documentées, souvent sous la forme d'audits de validité de construit basés sur la perturbation. Ces audits appliquent des modifications contrôlées aux éléments de référence (benchmarks) pour vérifier que les mesures de performance d'un modèle ne changent que lorsque le construit sous-jacent change (par exemple, un basculement sémantique) et restent stables sous des réécritures de surface.

L'article soutient que ces pipelines d'audit sont eux-mêmes des systèmes de mesure fragiles. Leurs conclusions peuvent être silencieusement fabriquées par des détails d'implémentation invisibles dans les chiffres rapportés. Un défaut dans le pipeline d'audit ne se contente pas de corrompre un score de benchmark ; il désactive la sauvegarde destinée à détecter les failles du benchmark, ne laissant aucune trace dans les métriques finales car le lecteur se repose sur ces métures pour décider s'il doit faire confiance au benchmark. Le problème central est que les preuves de gouvernance actuelles manquent d'un protocole pour vérifier la fiabilité du pipeline d'audit lui-même.

2. Méthodologie

Les auteurs mènent une étude de cas d'auto-audit pour démontrer que les pipelines d'audit sont sujets à des défaillances silencieuses.

• Portée : Deux modèles de type instruction-tuned de 7B en poids ouverts (Qwen-2.5-7B-Instruct, Mistral-7B-Instruct-v0.3) évalués contre cinq benchmarks de sécurité (TruthfulQA, BBQ, ToxiGen, CrowS-Pairs, XSTest).
• Conception : 10 cellules (2 modèles × 5 benchmarks), 200 éléments par benchmark, décodage déterministe, graine (seed) unique.
• Perturbations : Trois familles par élément (format, sémantique, attribut) avec trois perturbations chacune.
• Métrique : Ratio de sélectivité de contraste (CSR), défini comme $| \Delta_{attr} | / \max(| \Delta_{fmt} |, | \Delta_{sem} |, \epsilon)$. Cela mesure si les perturbations d'attributs induisent des changements de score plus importants que les perturbations de surface.
• Processus : Les auteurs ont exécuté un pipeline « hérité » (legacy), ont identifié les échecs, les ont réparés pour créer un pipeline « canonique », puis ont réexécuté l'audit. Crucialement, ils ont suivi toute la chronologie des bugs, y compris un (F3c) introduit pendant la phase de réparation.

3. Contributions clés

A. Les cinq modes de défaillance (F1–F5)

L'article propose une taxonomie non exhaustive de défaillances au niveau du pipeline qui sont silencieuses (invisibles dans les chiffres rapportés), réalisées (rencontrées en pratique) et filtrables (détectables via des vérifications spécifiques). Elles sont classées en deux couches :

Couche d'assurance logicielle (détectable via une revue d'ingénierie) :

1. F1 : Perturbations de type "no-op" silencieuses : La perturbation écrit dans un champ que le scoreur ne lit pas (par exemple, modifier une chaîne de question alors que le scoreur ne lit que les probabilités de choix). Cela entraîne un $\Delta = 0$ pour la perturbation, gonflant artificiellement les métriques de ratio.
2. F2 : Artefacts d'extraction par regex : Utiliser des expressions régulières (regex) pour analyser des générations de forme libre mesure la robustesse de la regex plutôt que le comportement du modèle. Si les perturbations modifient le style de génération, la capacité de parsing chute, et $\Delta_{fmt}$ suit la couverture de la regex plutôt que le comportement du modèle.
3. F4 : Rupture du couplage bootstrap : Le rééchantillonnage indépendant des éléments originaux et perturbés brise le couplage par élément, gonflant les intervalles de confiance et les estimations de variance.

Couche de fidélité de la mesure (nécessite un raisonnement sur le construit du benchmark) :
3. F3 : Scoring non fidèle : Le scoreur ne met pas en œuvre le protocole prévu par le benchmark.
* F3a (Convention inversée) : Traiter une phrase stéréotypée comme "correcte" en raison d'un chargement naïf (ex: CrowS-Pairs).
* F3b (Ordre du harness) : Biais de position dans les chargeurs (ex: TruthfulQA MC2 retournant les indices corrects comme $[0, \dots, k-1]$).
* F3c (Troncation du scoreur) : Les tokens cibles tombent en dehors des log-probabilités top-$k$ (ex: ToxiGen), provoquant un scoreur qui revient par défaut à une classe majoritaire et produit des artefacts de $\Delta = 0$.
4. F5 : Incompatibilité de l'archétype de métrique : Appliquer une métrique de diagnostic (conçue pour détecter des basculements) à un benchmark d'invariance (conçu pour ne pas basculer). Un faible CSR sur un benchmark d'invariance est ambigu (benchmark défectueux vs modèle équitable) et ne peut être résolu par des réparations de scoring.

B. Le portail de diligence raisonnable en six points (G1–G6)

Un protocole hiérarchique pour déterminer l'éligibilité des preuves d'audit. Une cellule n'est "confirmatoire" que si elle passe les six vérifications. Le portail comprend :

• G1 : Audit fidèle au scoreur (taux de no-op silencieux < 20 %, parseabilité $\ge$ 0,95).
• G2 : Score original au-dessus de la ligne de base.
• G3 : Dénominateur non trivial (deltas de surface $\ge$ 0,02).
• G4 : Incertitude appariée (bootstrap par paire au niveau de l'élément).
• G5 : Divulgation de l'archétype (benchmark étiqueté comme diagnostic, d'invariance ou mixte).
• G6 : Vérification de régression de réparation (inspection par cellule et tests unitaires pour les corrections).

C. Protocole de chronologie d'auto-audit

Les auteurs proposent un protocole de « rétention et de divulgation » exigeant que les audits publient une chronologie d'auto-audit (Encadré 1) détaillant chaque bug rencontré, sa méthode de découverte, la correction, et le delta avant/après. Cela distingue un pipeline "propre" d'un pipeline où les bugs ont été silencieusement absorbés.

4. Résultats

Dans l'étude de cas des 10 cellules, aucune cellule n'a atteint le statut "confirmatoire". La répartition était la suivante :

• 3 Inéligibles : En raison de F1 (CrowS-Pairs) ou F5 (BBQ).
• 3 Non validés par le scoreur : En raison de l'absence de validation externe pour les scoreurs de ToxiGen et XSTest.
• 2 Échecs aux portes G2–G4 : En raison de l'échec des seuils numériques (score de base ou seuils de dénominateur).
• 2 Exploratoires : Ont passé G1–G4 mais ont été tenus comme non-confirmatoires car G5 et G6 étaient "proposés" (pas encore implémentés comme portes obligatoires dans cette soumission).

Résultat clé : Une défaillance (F3c, troncature du scoreur) a été auto-introduite lors de la réparation de F1. Elle n'a été détectée qu'après l'inspection des méta log-probabilités par cellule. Sans cette inspection, le pipeline aurait produit des chiffres plausibles et publiables qui étaient entièrement des artefacts du bug.

5. Signification et affirmations

L'article positionne ses contributions comme étant supplémentaires aux preuves classiques de validité de construit (études convergentes/discriminantes), et non comme un remplacement.

• Affirmation modeste : Les auteurs ne prétendent pas prouver qu'un benchmark est invalide ou que F1–F5 est une taxonomie complète. Ils déclarent explicitement que la taxologie est "délibérément non exhaustive".
• Argument central : La contribution primaire est un protocole de rétention. Les preuves de gouvernance ne devraient pas être acceptées comme "de niveau assurance" à moins que le pipeline d'audit lui-même n'ait passé un portail de diligence raisonnable et publié une chronologie d'auto-audit.
• Implication : Un chiffre "propre" dans un rapport ne garantit pas un pipeline fiable. Sans le portail et la chronologie proposés, un pipeline silencieusement défectueux est indiscernable d'un pipeline robuste.

L'article conclut par une demande unique et actionnable : Tout audit produisant des preuves basées sur des benchmarks pour un usage de gouvernance devrait publier sa chronologie d'auto-audit (au minimum les huit champs de l'Encadré 1) aux côtés de ses chiffres.