Federated averaging : entraînement local, pondération des clients et données hétérogènes

Ce que désigne le federated averaging

L'apprentissage fédéré coordonne l'entraînement d'un modèle alors que les données d'entraînement restent réparties entre les clients. Dans le federated averaging (FedAvg), les clients entraînent des copies locales d'un modèle partagé, et un serveur agrège les paramètres ou les mises à jour obtenus. La méthode d'origine a été conçue pour une communication limitée et pour des données clients inégales en volume et distribuées différemment. [1]

Déroulement d'un tour d'entraînement de base

Le serveur distribue le modèle courant aux clients participants. Chacun part de ce même modèle et effectue une quantité définie d'optimisation locale. Le serveur calcule ensuite une agrégation des modèles renvoyés, généralement pondérée par le nombre d'exemples d'entraînement contribuant chez chaque client. Le tour suivant repart du modèle agrégé. L'architecture du modèle, l'ordre des paramètres et l'interprétation des features doivent coïncider : il ne s'agit pas d'une moyenne arbitraire de réseaux conçus indépendamment. [1]

Concevoir une évaluation

Une évaluation pratique consigne la politique d'échantillonnage des clients, les époques locales, la taille de batch, le taux d'apprentissage, les poids d'agrégation ainsi que les contributions échouées ou retardées. Il faut comparer ensemble les tours de communication, les octets transférés et la qualité du modèle. Une configuration qui nécessite moins de tours peut malgré tout être plus lente si le travail local ou la charge utile de communication augmente.

Conservez des partitions de clients réalistes pendant l'évaluation. Rapportez à la fois la performance pondérée par les exemples et une vue par client, avec les effectifs. Ce schéma de restitution, proposé ici, permet de voir si une amélioration globale profite surtout aux plus gros clients.

Exemple illustratif de pondération

Supposons que les trois clients participent tous, avec respectivement 100, 300 et 600 exemples d'entraînement de poids égal. Leurs poids d'échantillon normalisés sont 0.1, 0.3 et 0.6. Pour un paramètre, des valeurs locales de 1, 3 et 5 donnent 0.1*1 + 0.3*3 + 0.6*5 = 4.0.

Une moyenne où chaque client compte autant donnerait 3.0, ce qui correspond à un autre choix de pondération. Aucun de ces deux nombres n'établit une qualité prédictive. Cet exemple arithmétique illustre uniquement l'agrégation ; ce n'est ni un résultat d'entraînement ni un argument en faveur d'une domination systématique de l'objectif par les plus gros clients.

Limites et confidentialité

Les clients peuvent différer par la fréquence des classes, la distribution des features, les relations entre étiquettes et la disponibilité. Cette hétérogénéité peut faire diverger les mises à jour locales. Augmenter l'entraînement local modifie le compromis entre communication et optimisation et n'est pas une amélioration universelle. [2]

Stocker les données brutes en local ne rend pas les mises à jour du modèle inoffensives. L'agrégation sécurisée peut masquer les contributions individuelles au serveur, dans le cadre des hypothèses de son protocole, mais l'agrégat et le modèle publié peuvent tout de même révéler des informations. La confidentialité différentielle exige un mécanisme supplémentaire explicitement défini et une comptabilité de la confidentialité ; ce n'est pas une propriété automatique de FedAvg. [2] Aucune expérience d'entraînement fédéré, preuve de confidentialité ou benchmark de déploiement n'est revendiqué ici.

Sources

[1] Communication-Efficient Learning of Deep Networks from Decentralized Data

[2] Advances and Open Problems in Federated Learning