Résumé technique : Action collective au moment du test (TTCA)

Énoncé du problème

Les systèmes d'apprentissage automatique présentent fréquemment des disparités de performance entre les sous-groupes d'utilisateurs, entraînant des préjudices de « qualité de service » (QoS) où des groupes spécifiques subissent systématiquement une précision inférieure à celle des autres. Bien que des interventions de équité centrées sur le fournisseur (pré-traitement, traitement en cours et post-traitement) existent, elles dépendent de la volonté et de la capacité de la plateforme à réentraîner les modèles. Dans les scénarios où la remédiation est indisponible, retardée, ou lorsque la plateforme refuse d'agir, les utilisateurs affectés manquent de leviers externes pour corriger ces disparités.

Les cadres existants d'« Action collective algorithmique » (ACA) permettent aux utilisateurs d'orienter les algorithmes en contribuant des données, mais ces mécanismes exigent généralement que la plateforme réentraîne sur les données modifiées du collectif — une condition que les utilisateurs contrôlent rarement. De plus, les interventions de type « empoisonnement de données » peuvent être contournées si les fournisseurs attendent des mises à jour de modèles robustes ou s'entraînent sur des données pré-attaque. Par conséquent, il existe un besoin d'une intervention côté utilisateur opérant au moment du test sur un modèle boîte noire figé, sans nécessiter la coopération de la plateforme ni l'accès à la boucle d'entraînement.

Méthodologie : Action collective au moment du test (TTCA)

Les auteurs proposent TTCA, un cadre permettant à un groupe coordonné d'utilisateurs de corriger les préjudices algorithmiques en mutualisant l'accès aux requêtes d'une API boîte noire. Le mécanisme opère en deux phases :

Phase 1 : Extraction de proxy collectif et optimisation de perturbation

1. Mutualisation des requêtes : Un collectif de $n$ utilisateurs, chacun disposant d'un budget de requêtes $B$, mutualise ses ressources pour interroger le modèle de plateforme $f_{plat}$ sur un pool d'images publiques non étiquetées $D_{pub}$. Cela génère un ensemble de données $D_{proxy}$ de paires entrée-sortie $(x, f_{plat}(x))$.
2. Entraînement du proxy : Le collectif entraîne un modèle de substitution (proxy) $f_{proxy}$ sur $D_{proxy}$ en utilisant la méthode KnockoffNets. Pour améliorer la transférabilité, un ensemble de $K=5$ proxies est entraîné avec des graines aléatoires indépendantes.
3. Optimisation de la perturbation : Pour chaque classe $y$ du sous-groupe sous-desservi $G$, le collectif optimise une perturbation universelle par classe $\delta_y$. L'objectif est de minimiser la perte d'entropie croisée de l'ensemble de proxies pour les entrées appartenant à la classe $y$, sous réserve d'un budget $\ell_\infty$ ($\|\delta_y\|_\infty \le \epsilon$). L'optimisation cible la classe de vérité terrain, « poussant » efficacement les entrées mal classées vers la frontière de décision correcte. Un régularisateur de variation totale et un flou gaussien sont appliqués pour biaiser la perturbation vers des composantes de basse fréquence, améliorant ainsi la transférabilité boîte noire.

Phase 2 : Application au moment du test

Au moment de l'inférence, les membres du sous-groupe sous-desservi appliquent la perturbation pré-calculée $\delta_y$ à leurs entrées $x$ avant la soumission. Si l'entrée d'un utilisateur appartient à la classe $y \in G$, ils soumettent $x' = \text{clip}(x + \delta_y, 0, 1)$ ; sinon, ils soumettent $x$ inchangé. Ce processus ne nécessite aucune interaction supplémentaire avec la plateforme au-delà du budget de requêtes initial utilisé pour construire le proxy.

Contributions clés

1. Mécanisme correctif au moment du test : TTCA introduit un cadre où les utilisateurs peuvent corriger des disparités sur un modèle figé et boîte noire sans réentraîner la plateforme. Il réutilise la logique des attaques d'évasion (perturbations adverses universelles) à des fins correctives plutôt que malveillantes.
2. Efficacité basée sur le proxy : En extrayant un proxy collectif et en optimisant une perturbation universelle réutilisable, la méthode amortit le coût de l'intervention sur l'ensemble du sous-groupe.
3. Transfert inter-architectures : Le mécanisme démontre qu'un modèle proxy plus petit (par exemple, ResNet-18) peut générer efficacement des perturbations qui se transfèrent vers des architectures de plateforme plus grandes et inconnues (par exemple, ResNet-50, RegNet-Y).
4. Analyse de l'efficacité des coûts : L'article fournit une analyse rigoureuse montrant que la mutualisation des requêtes est nettement moins coûteuse que les attaques individuelles par image, même avec de petits collectifs.

Résultats expérimentaux

Les auteurs évaluent TTCA sur CIFAR-10, CIFAR-100 et FairFace (pour l'équité démographique) dans des régimes d'entraînement de plateforme à la fois équilibrés et délibérément déséquilibrés.

• Précision du sous-groupe : TTCA améliore considérablement la précision du sous-groupe sous-desservi (défini comme les 10 % inférieurs des groupes) avec des budgets de requêtes très faibles. Par exemple, sur CIFAR-100, un collectif de seulement 5 à 6 utilisateurs mutualisant leurs requêtes peut atteindre une précision du sous-groupe comparable ou supérieure à celle des attaquants individuels, tout en utilisant un nombre total de requêtes inférieur de plusieurs ordres de grandeur.
• Efficacité du budget de requêtes :
  • Référence individuelle : Les utilisateurs individuels attaquant seuls en utilisant SimBA (une attaque boîte noire par image) nécessitent jusqu'à 308 fois plus de requêtes totales à la plateforme pour atteindre une précision du sous-groupe comparable.
  • Point d'équilibre : Un collectif d'aussi peu que 5 à 10 membres suffit à rendre la mutualisation plus rentable que l'intervention individuelle.
  • Compromis du plafond : Bien que les attaques individuelles puissent atteindre une précision maximale plus élevée (par exemple, 97,9 % sur CIFAR-100) en optimisant par image, elles le font à un coût agrégé massif (2,3 millions de requêtes pour 1 000 utilisateurs). L'approche collective sature à un plafond de précision plus bas (83 %) mais atteint cela avec un coût fixe et réutilisable (~23 000 requêtes), la rendant bien plus efficace pour les grands groupes.
• Métriques d'équité : L'intervention améliore les métriques standard d'équité de groupe, notamment la précision du groupe le plus défavorisé (WGA), l'écart d'opportunité égale (EOD) et l'impact disproportionné (DI), sans dégrader les performances des autres groupes.
• Fidélité du proxy : Des proxies de haute fidélité ne sont pas strictement nécessaires ; une fois qu'un proxy est « suffisamment fidèle » (par exemple, 60–90 % de fidélité), des requêtes supplémentaires produisent des rendements décroissants en termes de précision du sous-groupe.

Importance et affirmations

L'article positionne TTCA comme une intervention corrective pour les utilisateurs confrontés à des préjudices de QoS lorsque la remédiation côté plateforme est indisponible. Son importance réside dans :

• L'agence : Il fournit aux utilisateurs un levier externe pour reprendre le contrôle sur les systèmes algorithmiques sans avoir besoin d'accéder aux détails internes du modèle ou aux données d'entraînement.
• L'évolutivité : Il démontre qu'une action coordonnée à petite échelle de la part des utilisateurs peut efficacement atténuer les disparités systémiques grâce à la mutualisation des ressources.
• La complémentarité : Il agit comme une approche complémentaire aux cadres ACA existants, adressant spécifiquement le « vide du moment du test » où les modèles sont déjà déployés et immuables.

Les auteurs notent que cette approche est plus efficace lorsque la tâche sous-jacente est globalement utile mais exécutée de manière inégale. Ils reconnaissent des limites : si la tâche elle-même est nuisible (par exemple, la reconnaissance automatique du genre causant des préjudices de représentation), le cadre correctif de TTCA peut être insuffisant, et les utilisateurs peuvent devoir recourir au refus ou à la contestation plutôt qu'à l'optimisation. De plus, la méthode suppose un modèle boîte noire statique ; des défenses côté plateforme (par exemple, lissage aléatoire) pourraient potentiellement atténuer l'efficacité de ces perturbations, bien que de telles défenses puissent également dégrader la précision globale de la plateforme.