← Derniers articles
🤖 machine learning

Who Trains Matters: Federated Learning under Enrollment and Participation Selection Biases

Ce papier traite de l'écart persistant de performance dans l'apprentissage fédéré, causé par les biais de sélection liés à l'inscription et à la participation, en formalisant un modèle de sélection en deux étapes et en proposant \textsc{FedIPW}, un schéma d'agrégation pondérée par l'inverse de la probabilité qui permet de retrouver efficacement les objectifs de la population cible même lorsque les covariables au niveau des clients sont limitées.

Auteurs originaux : Gota Morishita

Publié 2026-04-30
📖 7 min de lecture🧠 Analyse approfondie

Auteurs originaux : Gota Morishita

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayiez de préparer le gâteau parfait pour une ville entière. Pour ce faire, vous demandez à des milliers de pâtissiers amateurs de vous envoyer un petit morceau de leur pâte afin que vous puissiez les mélanger et déterminer la recette idéale. C'est essentiellement ainsi que fonctionne l'Apprentissage Fédéré (FL) : au lieu de rassembler toutes les données en un seul endroit, un serveur central demande à de nombreux appareils (comme des téléphones) d'entraîner un modèle localement et de renvoyer uniquement les « mises à jour » (les morceaux de pâte).

Le problème, comme l'explique cet article, est que qui vous demandez d'envoyer de la pâte compte tout autant que comment vous la mélangez.

Le filtre en deux étapes : Qui passe la porte ?

L'article soutient que, dans la vie réelle, les pâtissiers dont vous finissez par entendre parler sont rarement un échantillon parfait de la ville entière. Cela se produit en deux étapes distinctes, comme un contrôle de sécurité en deux temps à un concert :

  1. Le biais d'« Inscription » (Qui reçoit l'invitation ?) :
    D'abord, vous devez être éligible pour rejoindre le projet. Peut-être avez-vous besoin d'un type de téléphone spécifique, d'une certaine version de logiciel, ou devez-vous simplement cliquer sur « J'accepte » sur un formulaire de consentement. Si votre téléphone est ancien ou si vous vivez dans une zone avec une mauvaise connexion internet, vous ne recevez même jamais l'invitation. Vous êtes filtré avant même que le jeu ne commence. L'article appelle cela le Biais d'Inscription.

    • Analogie : Imaginez que vous n'invitez que les personnes possédant une voiture rouge à votre club de pâtisserie. Même si vous demandez à tous ceux qui ont une voiture rouge de participer, vous avez déjà manqué tous ceux qui ont une voiture bleue, un vélo, ou aucun véhicule du tout. Votre « club de pâtisserie » est déjà biaisé.
  2. Le biais de « Participation » (Qui se présente réellement ?) :
    Deuxièmement, même parmi les personnes qui ont reçu l'invitation, tout le monde ne se présente pas à chaque réunion. Peut-être que leur batterie est morte, leur connexion internet est instable, ou il est 3 heures du matin dans leur fuseau horaire. Ils sont inscrits, mais ils ne participent pas à cette ronde spécifique. L'article appelle cela le Biais de Participation.

    • Analogie : Même si vous avez invité tous ceux qui ont une voiture rouge, peut-être que seuls ceux qui sont éveillés et ont un réservoir plein se rendent réellement à la réunion.

Le problème : Cuire le mauvais gâteau

La plupart des méthodes existantes tentent de résoudre le deuxième problème (qui se présente). Elles disent : « D'accord, les personnes qui se sont présentées ce soir sont majoritairement des travailleurs de nuit ; ajustons la recette pour en tenir compte. »

Mais cet article soulève un problème plus important : Si les personnes qui ont été invitées dès le départ (les propriétaires de voitures rouges) ne ressemblent pas au reste de la ville, corriger la partie « qui se présente » n'y changera rien. Vous pouvez parfaitement ajuster pour les travailleurs de nuit, mais vous cuisez toujours un gâteau basé entièrement sur les propriétaires de voitures rouges. Le résultat final aura un goût délicieux pour les propriétaires de voitures rouges, mais sera terrible pour tout le monde else.

L'article appelle cela un « Décalage de la Population Cible ». Le modèle apprend à servir les personnes qui sont accessibles, et non les personnes qu'il est censé servir.

La solution : Une balance pondérée (FedIPW)

Pour résoudre cela, l'auteur propose une nouvelle méthode appelée FedIPW (Pondération Inverse de la Probabilité Fédérée).

Imaginez cela comme l'utilisation d'une balance pondérée au lieu d'une simple moyenne.

  • L'ancienne méthode (FedAvg) : Si 10 personnes envoient des mises à jour, vous attribuez à chaque personne un poids de 1/10.
  • La nouvelle méthode (FedIPW) : Vous regardez qui n'est pas venu et vous demandez « Pourquoi ? »
    • Si un groupe de personnes (disons, les propriétaires de téléphones Android) reçoit rarement d'invitation en raison de règles logicielles strictes, mais qu'ils se présentent lorsqu'ils sont invités, l'algorithme donne à leurs mises à jour un poids supplémentaire.
    • Si un groupe (disons, les propriétaires de nouveaux iPhones) reçoit souvent des invitations mais se présente rarement, leurs mises à jour sont également pondérées avec soin pour représenter ceux qui ont effectivement participé.

En « re-pondérant » mathématiquement les mises à jour en fonction de la probabilité d'être invité et de la probabilité de se présenter, le serveur peut reconstruire ce que le « pâtissier moyen de la ville » aurait contribué, même s'il n'a jamais réellement envoyé de morceau de pâte.

Et si nous n'avons pas tous les détails ? (La correction « Information Limitée »)

Parfois, le serveur ne connaît pas les détails des personnes qui n'ont pas reçu d'invitation (par exemple, il ne sait pas combien de personnes dans la ville ont des téléphones anciens). Il ne connaît que la vue d'ensemble (par exemple, « 20 % de la ville utilise Android »).

Dans ce cas, l'article suggère une astuce de Calibration.

  • Analogie : Imaginez que vous cuisez avec un échantillon de pâtissiers, mais que vous ne connaissez pas la démographie exacte de toute la ville. Cependant, vous disposez d'un rapport de recensement indiquant : « La ville est composée de 50 % d'hommes et de 50 % de femmes. »
  • Si votre échantillon de pâtissiers est composé à 80 % d'hommes, vous ne pouvez pas simplement ignorer les femmes. Au lieu de cela, vous attribuez moins de poids aux mises à jour des hommes et plus de poids à celles des femmes jusqu'à ce que votre échantillon ressemble au rapport de recensement (50/50).
  • Cela ne résout pas tout parfaitement, mais cela vous rapproche beaucoup plus de la bonne recette que de ne rien faire.

L'avertissement du « Plafond de Biais »

L'article met également en garde contre un « Plafond de Biais ».
Imaginez que vous essayez de toucher une cible. Si vous manquez légèrement la cible parce que votre visée est instable (erreur aléatoire), vous pouvez vous améliorer avec la pratique. Mais si votre arme est tordue (erreur structurelle), vous manquerez toujours le centre, peu importe combien vous vous entraînez.

L'article prouve que si vous ignorez l'étape d'« Inscription » (l'arme tordue), vous atteindrez un Plafond de Biais. Peu importe le nombre de rounds d'entraînement que vous effectuez, le modèle n'atteindra jamais la véritable meilleure solution pour l'ensemble de la population. Il restera coincé dans une zone « assez bonne » qui est en réalité fausse pour les personnes qui vous importent.

Résumé

  • Le problème : L'apprentissage fédéré échoue souvent parce que les personnes qui rejoignent l'entraînement (inscription) et les personnes qui participent réellement ne sont pas représentatives de l'ensemble de la population.
  • La solution : Utiliser une correction en deux étapes (FedIPW) qui pondère mathématiquement les mises à jour pour tenir compte de qui a été exclu au départ et de qui a abandonné au cours du processus.
  • L'essentiel : Il ne suffit pas de corriger qui se présente à la réunion ; vous devez corriger qui a été invité à la réunion dès le départ. Si vous ne le faites pas, votre modèle sera biaisé en faveur d'un groupe spécifique, peu importe à quel point l'algorithme est intelligent.

Noyé(e) sous les articles dans votre domaine ?

Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.

Essayer Digest →