Introduction
Les approches traditionnelles de l’apprentissage automatique doivent rassembler toutes les données en provenance des clients, dans un seul endroit centralisé, généralement un centre de données Cloud. Selon la nature des données traitées, ce principe peut enfreindre les lois sur la vie privée des utilisateurs et la confidentialité des données. Par exemple, le secteur de la santé est tenu de respecter des clauses de confidentialité strictes et peut être confronté à des contraintes juridiques, administratives ou éthiques si ses données sont partagées.
De ce fait, une autre approche d’apprentissage a pour but d’entraîner un algorithme sur les machines des utilisateurs tout en gardant les données locales dans des appareils décentralisés. Il s’agit de l’apprentissage fédéré (Federated learning). Plutôt que de centraliser les données brutes dans le Cloud et d’entraîner l’algorithme en local sur le serveur central, ce dernier envoie le modèle avec les paramètres initiaux à tous les clients qui participent à l’entraînement, chacun l’améliore par la modification des paramètres en apprenant à partir des données locales, puis envoie sa mise à jour au serveur où elle est immédiatement agrégée avec d’autres mises à jour d’utilisateurs pour améliorer le modèle partagé.
Concept
L’apprentissage fédéré peut être utilisé dans différents domaines tels que l’analyse des sentiments, le suivi de l’activité du téléphone mobile, etc. Les clients distants peuvent être des organisations ou des institutions telles que les hôpitaux, ou bien des appareils mobiles d’individus puisqu’ils contiennent une multitude de données adaptées aux modèles d’apprentissage telles que les images prises par l’utilisateur, sa position, ses notes, ses applications…
Avant chaque entraînement, seulement un ensemble fixe de clients est autorisé à participer pour des raisons d’efficacité, notamment ceux qui sont éligibles en fonction de certaines heuristiques. Si nous testons par exemple sur des appareils mobiles, les appareils éligibles seraient ceux : complètement chargés, avec des configurations hardware spécifiques, connectés à un réseau WiFi fiable et gratuit et inactifs. Ceci est dans le but de ne pas interrompre l’entraînement si l’appareil est déconnecté ou épuise sa batterie, et pour minimiser l’impact négatif que l’entraînement local pourrait avoir sur l’expérience des utilisateurs, par exemple la durée d’entraînement si l’appareil est en cours d’utilisation.
Un entraînement de modèle est composé de plusieurs “rounds” (le nombre de fois où les paramètres du modèle initial seront mis à jour). Pour chaque round, seulement une fraction de clients, dont le nombre est fixé d’avance, est utilisée et peut différer d’un round à un autre (par exemple 20% des clients participants).
Au début, le modèle est envoyé aux clients sélectionnés avec les paramètres initiaux (les poids du réseau de neurones) qui sont fixés soit par le serveur suivant une stratégie à définir, soit par un client choisi aléatoirement.
Initialisation des paramètres par un client aléatoire
Initialisation des paramètres par une stratégie du serveur
Chacun des clients effectue ensuite un calcul local basé sur l’état global du modèle partagé et son ensemble de données locales. Les gradients sont calculés puis envoyés au serveur. Le serveur réalise ensuite une agrégation de ces mises à jour et l’applique à son état global et le processus se répète pour tous les rounds.
Les étapes d’un apprentissage fédéré
Les communications entre le serveur et les différents clients doivent se faire de manière sécurisée, efficace, évolutive et tolérante aux pannes, en utilisant le protocole SSL (Secure Sockets Layer) pour les échanges cryptés entre les machines. Ainsi, les risques d’écoute ou d’interception sont diminués et la confidentialité et la protection des données des utilisateurs est garantie.
Ensemble des échanges Serveur/Clients
Contrairement à l’apprentissage des modèles de machine learning traditionnels, où les ensembles de train, test et de validation sont obtenus via des fractionnements explicites des données, ils sont obtenus dans le cas de l’apprentissage fédéré en divisant les appareils clients en trois populations distinctes. La probabilité de réutilisation des clients dans les ensembles de test, train ou validation est très faible dans une population de clients suffisamment importante.
Deux approches peuvent être utilisées pour l’entraînement d’un modèle fédéré :
les mêmes clients participent au train et au test, le dataset local sera simplement divisé en deux parties
des clients sont utilisés pour le train, d’autres pour le test
Ainsi, chaque client participant au test, retourne au serveur un ensemble de métriques selon son dataset local et la dernière version du modèle reçu après l’entraînement.
Méthodes d’agrégation
Les données utilisées dans un apprentissage fédéré sont généralement non-IID (indépendantes et identiquement distribuées), c’est à dire que les données d’un client particulier sont basées sur l’utilisation de l’appareil mobile par cet utilisateur, et par conséquent ces données ne seront pas représentatives de la répartition de la population. Pour cela, le serveur vise à agréger autant de mises à jour de modèle que possible, et cela par différentes méthodes d’agrégation. Chaque méthode peut être configurée au niveau du serveur pour mieux s’adapter à la nature des données des clients.
FedAvg : la plus utilisée et consiste à combiner la descente de gradient stochastique (SGD) locale sur chaque client avec un serveur qui effectue la moyenne du modèle. Cet algorithme est robuste aux distributions de données déséquilibrées et non-IID.
FedOpt : permet l’utilisation des optimiseurs adaptatifs (par exemple ADAM, YOGI, etc..) au lieu de SGD pour avoir des méthodes telles que FedAdam, FedYogi, FedAdagrad, etc. Il utilise aussi un learning rate qui peut dépendre du numéro de l’itération (round k).
FedFS : une nouvelle stratégie utilisée dans des scénarios de clients hétérogènes. Elle identifie les clients “fast and slow” et planifie intelligemment les rounds entre eux afin de minimiser le temps de convergence total.
FedProx : permet des quantités de travail variables à effectuer localement sur les appareils en fonction de leurs ressources système disponibles, puis regroupe les solutions partielles envoyées.
FedCurv : spécifique dans le cas des données non-IID. Il ajoute la pénalité EWC (Elastic Weight Consolidation) pour forcer chaque modèle local à conserver la connaissance acquise à partir des données d’autres appareils. Chaque client envoie son modèle et la diagonale de sa matrice d’informations de Fisher (une métrique pour quantifier l’information relative à un paramètre contenu dans une distribution). Il n’est cependant compatible qu’avec PyTorch.
La disponibilité des méthodes d’agrégation dépend du framework utilisé, puisque certains ne supportent pas toutes les méthodes. Le choix de la méthode à adopter dépend aussi de la nature des clients et de la distribution de leurs données locales.
Apprentissage fédéré Vs Apprentissage de ML classique
Afin de comparer l’efficacité de l’apprentissage fédéré avec celle de l’apprentissage des modèles de machine learning classiques, nous avons effectué plusieurs tests sur deux ensembles de datasets différents (MNIST et CIFAR10) qui contiennent chacun 10 classes différentes. Nous avons comparé ensuite les métriques obtenues, ainsi que le temps d’exécution et l’usage en mémoire.
Dans le cas du federated learning, nous avons utilisé la configuration suivante :
un ensemble de 10 clients qui participeront à l’apprentissage
10 rounds globaux
Les tests ont été réalisés sur les deux datasets, une fois avec une architecture MLP sur un CPU puis sur un GPU, et une fois avec une architecture CNN sur un CPU puis GPU.
Afin de mieux généraliser le comportement de l’apprentissage fédéré, nous l’avons testé avec deux répartitions différentes des données locales : IID et non-IID.
Le tableau suivant montre un exemple des résultats obtenus en utilisant le dataset MNIST avec l’architecture CNN sur un GPU :
Nous constatons que l’apprentissage fédéré est aussi précis qu’un apprentissage classique dans le cas d’une distribution des données IID (indépendantes et identiquement distribuées), mais plus faible dans le cas d’une distribution non-IID. L’usage en mémoire pour tous les types d’apprentissage dans les deux cas, CPU ou GPU, est presque égal pour les deux modèles. Cependant, le temps d’exécution pour un modèle fédéré est presque le double d’un modèle de ML classique, et ceci est valable pour tous les tests réalisés.
La différence du temps d’exécution qui s’ajoute dans le cas du federated learning est due aux multiples communications entre le serveur et les clients, ainsi que le nombre potentiellement considérable d’appareils dans le réseau (par exemple, des millions de smartphones).
Différents frameworks
Plusieurs frameworks sont utilisés dans l’apprentissage fédéré, selon le besoin et l’environnement de travail, parmi lesquels nombreux sont open-source tels que PySyft, Flower, OpenFL, TensorFlow Federated, etc.. D’autres offrent un service payant pour une utilisation en production tels que IBM Federated Learning et NVIDIA Clara Train. Certains sont limités dans la compatibilité avec les frameworks Python ML, par exemple TensorFlow Federated n’est compatible qu’avec TensorFlow, quant à NVIDIA Clara Train, il n’est compatible qu’avec PyTorch. Cependant, la plupart des autres sont compatibles avec tous les frameworks Python ML.
PySyft : permet de créer des clients virtuels et leur envoyer les datasets et le modèle. Il contient une méthode pour itérer sur le dataset d’une manière fédérée et utilise PyGrid comme API pour la gestion et le déploiement.
Flower : interopérable avec différents systèmes d’exploitation et hardwares pour bien fonctionner dans des environnements d’appareils hétérogènes. Il peut ainsi être implémenté sur tous types de serveurs et appareils, y compris les mobiles (AWS, GCP, Azure, Android, iOS, Raspberry Pi, Nvidia Jetson).
NVIDIA Clara Train : basé sur l’environnement NVIDIA FLARE qui fournit l’infrastructure distribuée de l’apprentissage fédéré, et utilise la fonction configurable MMAR (Mediacal Model ARchive) qui permet aux développeurs de contrôler si l’entraînement local est exécuté sur un ou plusieurs GPU.
OpenFL : se compose de plusieurs collaborateurs, qui entraînent le modèle global sur des datasets locaux et d’un agrégateur, qui reçoit les mises à jour du modèle et les combine à chaque round. Il utilise une authentification mutuelle pour les communications (gRPC + mTLS) et ne supporte pas toutes les méthodes d’agrégation.
TensorFlow Federated : est organisé en 2 couches :
1/ Federated Learning (FL) : cette couche propose un ensemble d’interfaces de haut niveau permettant aux développeurs d’appliquer les implémentations d’évaluation et d’apprentissage fédéré incluses dans leurs modèles TensorFlow.
2/ Federated Core (FC) : cette couche sert de base pour le développement de l’apprentissage fédéré.
IBM Federated Learning : se base sur le principe d’un “Aggregator” et des “Parties” qui correspondent respectivement au serveur et clients. Il ne dépend pas d’un framework spécifique.
Substra : ajoute aux principes de l’apprentissage fédéré la traçabilité complète de toutes les opérations de ML, qui est essentielle non seulement pour garantir la confidentialité des données, mais aussi pour fournir un historique de l’entrainement des modèles
FATE : implémente plusieurs protocoles de calcul sécurisés pour permettre un traitement Big Data tout en garantissant la protection des données. Il contient plusieurs composants tels que des libraires, des pipelines, des outils.. (FATEFlow, FederatedML, FATE Serving, FATEBoard, Federated Network, KubeFATE).
Remerciement
Merci à notre collègue Ismail EL HATIMI pour la revue de l’article.
A propos de l’auteur
Bochra BEN JABALLAH est étudiante en Master 2 en Intelligence Artificielle, Science des données et Systèmes Cyber-physiques à l’UPEC. Elle rejoint La Javaness en 2022 pour son stage de fin d’étude sur le sujet de Federated Learning.