FedAvg expliqué : pourquoi la moyenne des gradients n'est pas aussi simple qu'elle paraît

FedAvg, introduit par McMahan et al. en 2017, repose sur une idée élégante : plutôt que d'envoyer des données brutes à un serveur central, chaque client entraîne le modèle localement pendant plusieurs itérations, puis envoie ses mises à jour de paramètres. Le serveur calcule une moyenne pondérée de ces mises à jour — pondérée par la taille des jeux de données locaux — et distribue le nouveau modèle global. Ce cycle se répète jusqu'à convergence. La beauté de ce mécanisme, c'est qu'il réduit considérablement le nombre de communications nécessaires par rapport à un gradient stochastique distribué classique, ce qui le rend pratiquement utilisable même avec des connexions réseau limitées. Mais cette réduction du coût de communication s'achète au prix d'une hypothèse implicite sur laquelle peu d'articles s'attardent : les données locales doivent être distribuées de manière identique et indépendante entre les participants pour que la moyenne pondérée produise un modèle global cohérent. Or, dans un contexte financier, cette hypothèse est presque universellement violée.

Imaginons deux banques cantonales suisses participant à un réseau fédéré pour améliorer leur modèle de détection de fraude. La première opère principalement dans un canton urbain avec une forte proportion de transactions numériques et de paiements internationaux. La seconde dessert une clientèle rurale avec des patterns de transaction radicalement différents — des montants plus faibles, des fréquences hebdomadaires plutôt que quotidiennes, et pratiquement aucune transaction transfrontalière. Quand FedAvg calcule la moyenne pondérée de leurs gradients respectifs, il produit un modèle global qui reflète une réalité fictive — celle d'une banque qui n'existe pas, avec des clients qui n'existent pas. Ce modèle sera systématiquement moins bon que les modèles locaux de chacune des deux banques sur leurs données respectives. C'est ce que la littérature appelle le problème de la non-IID, et c'est le talon d'Achille de FedAvg dans les applications financières réelles.

La réponse de la communauté de recherche à ce problème a été prolifique — peut-être trop. En quelques années, des dizaines de variantes de FedAvg ont été proposées : FedProx ajoute un terme de régularisation pour limiter la dérive locale, SCAFFOLD utilise des variables de contrôle pour corriger le biais de gradient, FedNova normalise les mises à jour selon le nombre d'itérations locales. Chacune de ces variantes résout partiellement le problème de non-IID, mais introduit de nouvelles hypothèses ou augmente le coût de communication. En pratique, le choix entre ces variantes dépend moins de leurs propriétés théoriques que de la topologie spécifique du réseau fédéré considéré — ce que les benchmarks académiques, conduits sur des jeux de données standardisés, ne permettent pas de déterminer à l'avance pour un contexte financier réel. Les performances passées de ces algorithmes sur des jeux de données de référence ne préjugent pas de leurs performances dans votre contexte spécifique.

Un aspect que j'ai trouvé particulièrement sous-discuté dans les présentations grand public de FedAvg est la question de la convergence. Dans les conditions idéales — données IID, participants synchrones, connexions fiables — FedAvg converge vers le même optimum que l'entraînement centralisé. Mais dans les conditions réelles d'un réseau financier fédéré — données non-IID, participants qui rejoignent ou quittent le réseau, connexions intermittentes — les garanties théoriques de convergence s'effondrent rapidement. Ce n'est pas une raison de rejeter FedAvg, mais c'est une raison impérieuse de ne pas prendre pour argent comptant les performances annoncées dans les études de cas présentées par les fournisseurs de plateformes, qui ont tout intérêt à choisir des configurations favorables à leurs benchmarks.