La chaîne de blocs pour l’apprentissage fédéré fractionné
Achetée sur Gettyimages. Droit d’auteur.
L’apprentissage fédéré (federated learning, FL) permet aux clients, c’est-à-dire les appareils IoT, d’entraîner des modèles localement de manière itérative et collaborative. Or, certains clients ne participeraient que partiellement à l’entraînement en raison de leurs ressources informatiques limitées. Ce frein risque de nuire à la précision du modèle global et à la vitesse d’apprentissage, car les appareils IoT n’auraient pas accès aux précieuses données d’entraînement des clients en question. Pour y remédier, nous présentons dans cet article la Block-FeST, un cadre d’apprentissage fédéré fractionné fondé sur la chaîne de blocs pour la détection d’anomalies par transformateurs, alliant les forces de l’apprentissage fédéré et de l’apprentissage fractionné (Federated and Split Learning, FSL) (recherche en collaboration avec Ericsson). Le FL permet d’atténuer les problèmes de confidentialité des données, tandis que le SL (Split Learning) sert à délester les clients contraints par la surcharge de calcul vers un serveur central. En outre, la chaîne de blocs génère une piste d’audit qui permet de répondre à toute contestation de la part des clients et de prendre des mesures correctives.
Introduction
Les appareils de l’Internet des objets (IdO) génèrent une quantité massive de données. Ces données ont le potentiel de révolutionner tous les secteurs en développant des systèmes intelligents. Malheureusement, elles sont inaccessibles par souci de confidentialité. Pour y remédier, Google a proposé une approche décentralisée d’apprentissage machine, à savoir l’apprentissage fédéré.
Le FL entraîne un modèle d’apprentissage profond (Deep Learning, DL) distribué parmi plusieurs clients. À chaque ronde de FL, un sous-ensemble de clients doit entraîner un modèle local et envoyer un message de mise à jour à un serveur central. Un nouveau modèle global est calculé et renvoyé à la fin de la ronde à tous les clients par le serveur central. Ce procédé se poursuit jusqu’à ce que le modèle global soit convergent.
Toutefois, les clients disposant de ressources limitées risquent de soumettre leur modèle local en retard, en raison de leurs ressources informatiques limitées. La précision du modèle global et la vitesse d’entraînement s’en trouvent affectées, car ces clients ne sont pas en mesure de partager de précieuses données d’entraînement. En outre, dans le système FL traditionnel, le serveur peut spammer les modèles globaux en endossant ses pairs.
Protocole Block-FeST proposé
Le protocole Block-FeST se décline en quatre phases : initialisation, apprentissage fractionné, agrégation et mise à jour. D’abord, le serveur lance le processus FL, en commençant la première ronde FL par l’envoi du modèle global initial à tous les clients, comme le montre la figure 1. Chaque client commence à entraîner son modèle local avec ses données privées. Les clients exécutent l’entraînement en partageant leur surcharge de calcul avec le serveur d’apprentissage fractionné. Ils entraînent la moitié de leur modèle local sur le serveur SL. Une fois l’entraînement du modèle local des clients terminé, le serveur SL le renvoie aux clients. Les modèles locaux des clients sont stockés hors chaîne, c’est-à-dire dans le système de fichiers interplanétaire (InterPlanetary File System, IPFS). Toutefois, le hachage des modèles locaux sera stocké sur la chaîne de blocs afin d’éviter toute falsification. Les modèles locaux seront ensuite agrégés par le serveur FL. Le serveur FL récupère les modèles locaux de l’IPFS à la fin de chaque ronde. Lors de la phase de mise à jour, le serveur FL appliquera l’algorithme FedAVG pour agréger tous les modèles locaux afin de former un modèle global. Chaque ronde de FL produit une chaîne de blocs qui envoie le modèle global modifié aux clients pour commencer la ronde de FL suivante. Ce processus se poursuit jusqu’à ce que les critères de convergence désirés soient remplis. Le serveur FL, basé sur la chaîne de blocs garantit la transparence et l’immuabilité en vérifiant publiquement les modèles locaux et globaux.
Figure 1 : Architecture proposée
Validation de l’approche proposée
Nous avons étudié le cas d’une infrastructure de fournisseurs de services de communication (FSC ou CSP) où différents CSP entraînent un modèle fédéré à partir de leurs données locales. Ces CSP surveillent les indicateurs clés de performance (ICP ou KPI) comme les temps d’arrêt des cellulaires, la latence et le débit pour détecter les anomalies, souvent causées par des pics soudains de trafic ou des pannes d’équipement.
Nous avons évalué la Block-FeST par rapport à des systèmes centralisés et décentralisés connus, à savoir FL, SL et FSL. La solution centralisée a atteint une précision de 0,90 après 20 époques, comme le montre la figure 2. Enfin, la solution que nous proposons, à savoir la Block-FeST, a atteint une précision de 0,86. En outre, la Block-FeST a atteint une précision de 0,65, un rappel de 0,66 et un score F1 de 0,65. La figure 3 montre que la Block-FeST a enregistré un retard de 15 % par rapport à l’approche centralisée.
Figure 2: Base de comparaison Figure 3: Temps d’exécution
Conclusion
La Block-FeST permet aux clients dont les ressources sont limitées de participer à des systèmes de détection d’anomalies des IdO en temps réel. Notre solution garantit un modèle AD plus robuste pour les KPI critiques (latence, débit et temps d’indisponibilité des cellulaires) permettant à Ericsson de répondre de manière plus proactive aux pannes de cellulaires. De plus, la chaîne de bloc servira à orchestrer le processus d’entraînement tout en assurant transparence et traçabilité.
