Apprentissage fédéré

Aperçu

Ce document présente des interfaces qui facilitent les tâches d'apprentissage fédéré, telles que la formation ou l'évaluation fédérée avec des modèles d'apprentissage automatique existants implémentés dans TensorFlow. En concevant ces interfaces, notre objectif principal était de permettre d'expérimenter l'apprentissage fédéré sans avoir besoin de connaître son fonctionnement sous le capot, et d'évaluer les algorithmes d'apprentissage fédéré mis en œuvre sur une variété de modèles et de données existants. Nous vous encourageons à contribuer à nouveau à la plateforme. TFF a été conçu dans un souci d'extensibilité et de composabilité, et nous accueillons les contributions ; nous sommes impatients de voir ce que vous proposez!

Les interfaces offertes par cette couche se composent des trois éléments clés suivants :

  • Modèles. Classes et fonctions d'assistance qui vous permettent d'encapsuler vos modèles existants pour une utilisation avec TFF. Emballage d' un modèle peut être aussi simple que d' appeler une fonction unique d'emballage (par exemple, tff.learning.from_keras_model ), ou la définition d' une sous - classe de la tff.learning.Model interface pour personnalisation complète.

  • Fédérées Constructeurs de Calcul. Fonctions d'assistance qui construisent des calculs fédérés pour l'entraînement ou l'évaluation, à l'aide de vos modèles existants.

  • Jeux de données. Collections de données prédéfinies que vous pouvez télécharger et accéder en Python pour une utilisation dans la simulation de scénarios d'apprentissage fédéré. Bien que l'apprentissage fédéré soit conçu pour être utilisé avec des données décentralisées qui ne peuvent pas être simplement téléchargées dans un emplacement centralisé, aux stades de la recherche et du développement, il est souvent pratique de mener des expériences initiales en utilisant des données qui peuvent être téléchargées et manipulées localement, en particulier pour les développeurs qui pourraient être nouveau dans l'approche.

Ces interfaces sont définies principalement dans le tff.learning espace de noms, à l' exception des ensembles de données de recherche et d' autres capacités liées à la simulation qui ont été regroupées en tff.simulation . Cette couche est réalisée en utilisant des interfaces de niveau inférieur offertes par le fédéré de base (FC) , qui fournit également un environnement d'exécution.

Avant de poursuivre, nous vous recommandons de consulter d' abord les tutoriels sur la classification d'images et génération de texte , car ils introduisent la plupart des concepts décrits ici en utilisant des exemples concrets. Si vous êtes intéressé à en apprendre davantage sur la façon dont fonctionne TFF, vous pouvez parcourir rapidement les algorithmes personnalisés tutoriel d'introduction aux interfaces plus bas niveau que nous utilisons pour exprimer la logique des calculs fédérés, et d'étudier la mise en œuvre actuelle du tff.learning interfaces.

Des modèles

Hypothèses architecturales

Sérialisation

TFF vise à prendre en charge une variété de scénarios d'apprentissage distribué dans lesquels le code du modèle d'apprentissage automatique que vous écrivez peut s'exécuter sur un grand nombre de clients hétérogènes dotés de capacités diverses. Alors qu'à une extrémité du spectre, dans certaines applications, ces clients peuvent être de puissants serveurs de bases de données, de nombreuses utilisations importantes que notre plate-forme entend prendre en charge impliquent des appareils mobiles et embarqués avec des ressources limitées. Nous ne pouvons pas supposer que ces appareils sont capables d'héberger des environnements d'exécution Python ; la seule chose que nous pouvons supposer à ce stade est qu'ils sont capables d'héberger un environnement d'exécution TensorFlow local. Ainsi, une hypothèse architecturale fondamentale que nous faisons dans TFF est que votre code de modèle doit être sérialisable en tant que graphique TensorFlow.

Vous pouvez (et devez) continuer à développer votre code TF en suivant les dernières bonnes pratiques comme l'utilisation du mode impatient. Cependant, le code final doit être sérialisable (par exemple, peut être enroulé comme tf.function pour le code en mode impatient). Cela garantit que tout écoulement état Python ou le contrôle nécessaire à l'exécution peuvent être sérialisés (éventuellement avec l'aide de Autograph ).

Actuellement, TensorFlow ne prend pas entièrement en charge la sérialisation et la désérialisation de TensorFlow en mode impatient. Ainsi, dans la sérialisation TFF suit actuellement le modèle TF 1.0, où tout le code doit être construit à l' intérieur d' un tf.Graph que les contrôles TFF. Cela signifie qu'actuellement TFF ne peut pas consommer un modèle déjà construit ; au contraire, la logique de définition du modèle est emballé dans une fonction non-arg qui retourne une tff.learning.Model . Cette fonction est ensuite appelée par TFF pour s'assurer que tous les composants du modèle sont sérialisés. De plus, étant un environnement fortement typé, TFF , il faudra un peu de métadonnées supplémentaires, comme une spécification du type d'entrée de votre modèle.

Agrégation

Nous vous recommandons fortement la plupart des utilisateurs construire des modèles utilisant Keras, voir les convertisseurs pour Keras section ci - dessous. Ces wrappers gèrent automatiquement l'agrégation des mises à jour du modèle ainsi que toutes les métriques définies pour le modèle. Cependant, il peut encore être utile de comprendre comment l' agrégation est traitée pour un général tff.learning.Model .

Il y a toujours au moins deux couches d'agrégation dans l'apprentissage fédéré : l'agrégation locale sur l'appareil et l'agrégation inter-appareils (ou fédérée) :

  • Agrégation locale. Ce niveau d'agrégation fait référence à l'agrégation sur plusieurs lots d'exemples appartenant à un client individuel. Cela s'applique à la fois aux paramètres du modèle (variables), qui continuent d'évoluer séquentiellement au fur et à mesure que le modèle est formé localement, ainsi qu'aux statistiques que vous calculez (telles que la perte moyenne, la précision et d'autres métriques), que votre modèle mettra à nouveau à jour localement. car il itère sur le flux de données local de chaque client.

    L'agrégation à ce niveau relève de la responsabilité de votre code de modèle et s'effectue à l'aide de constructions TensorFlow standard.

    La structure générale du traitement est la suivante :

    • Le premier modèle construit tf.Variable s aux agrégats de maintien, tels que le nombre de lots ou le nombre d'exemples traités, la somme des pertes par lot ou par-exemple, etc.

    • TFF invoque la forward_pass méthode sur votre Model plusieurs fois, de manière séquentielle sur des lots ultérieurs de données de clients, ce qui vous permet de mettre à jour les variables contenant divers agrégats comme un effet secondaire.

    • Enfin, TFF invoque la report_local_outputs méthode sur votre modèle pour permettre à votre modèle de compiler toutes les statistiques sommaires , il recueilli dans un ensemble compact de mesures à exporter par le client. C'est là que votre code de modèle peut, par exemple, diviser la somme des pertes par le nombre d'exemples traités pour exporter la perte moyenne, etc.

  • Agrégation fédérée. Ce niveau d'agrégation fait référence à l'agrégation entre plusieurs clients (périphériques) du système. Encore une fois, cela s'applique à la fois aux paramètres du modèle (variables), qui sont moyennés entre les clients, ainsi qu'aux métriques que votre modèle a exportées à la suite de l'agrégation locale.

    La réalisation de l'agrégation à ce niveau est de la responsabilité de TFF. En tant que créateur de modèle, cependant, vous pouvez contrôler ce processus (plus de détails ci-dessous).

    La structure générale du traitement est la suivante :

    • Le modèle initial et tous les paramètres requis pour la formation sont distribués par un serveur à un sous-ensemble de clients qui participeront à un cycle de formation ou d'évaluation.

    • Sur chaque client, indépendamment et en parallèle, votre code de modèle est invoqué à plusieurs reprises sur un flux de lots de données locaux pour produire un nouvel ensemble de paramètres de modèle (lors de l'apprentissage) et un nouvel ensemble de métriques locales, comme décrit ci-dessus (c'est local agrégation).

    • TFF exécute un protocole d'agrégation distribué pour accumuler et agréger les paramètres du modèle et les métriques exportées localement à travers le système. Cette logique est exprimée d'une manière déclarative utilisant le langage de calcul fédérée de TFF (pas tensorflow), dans le modèle federated_output_computation. Voir les algorithmes personnalisés tutoriel pour plus sur l'API d'agrégation.

Interfaces abstraites

Ce constructeur de base + l' interface des métadonnées est représentée par l'interface tff.learning.Model , comme suit:

  • Le constructeur, forward_pass et report_local_outputs méthodes doivent construire des variables du modèle, passe en avant, et les statistiques que vous souhaitez signaler, en conséquence. Le TensorFlow construit par ces méthodes doit être sérialisable, comme indiqué ci-dessus.

  • La input_spec propriété, ainsi que les 3 propriétés que des sous - ensembles de retour de votre trainable, non trainable et variables locales représentent les métadonnées. TFF utilise ces informations pour déterminer comment connecter des parties de votre modèle aux algorithmes d'optimisation fédérés, et pour définir des signatures de type internes pour aider à vérifier l'exactitude du système construit (afin que votre modèle ne puisse pas être instancié sur des données qui ne correspondent pas à ce que le modèle est conçu pour consommer).

De plus, l'interface abstraite tff.learning.Model expose une propriété federated_output_computation qui, en même temps que la report_local_outputs propriété mentionné précédemment, vous permet de contrôler le processus d'agrégation des statistiques sommaires.

Vous trouverez des exemples de la façon de définir votre propre coutume tff.learning.Model dans la deuxième partie de notre classement d' model_examples.py image tutoriel, ainsi que dans les exemples de modèles que nous utilisons pour les tests en model_examples.py .

Convertisseurs pour Keras

Presque toutes les informations qui est requis par la TFF peut être obtenue en appelant tf.keras interfaces, donc si vous avez un modèle Keras, vous pouvez compter sur tff.learning.from_keras_model pour construire un tff.learning.Model .

Notez que TFF veut toujours vous fournir un constructeur - une fonction de modèle sans argument, comme suit:

def model_fn():
  keras_model = ...
  return tff.learning.from_keras_model(keras_model, sample_batch, loss=...)

En plus du modèle lui-même, vous fournissez un échantillon de données que TFF utilise pour déterminer le type et la forme de l'entrée de votre modèle. Cela garantit que TFF peut correctement instancier le modèle pour les données qui seront réellement présentes sur les appareils clients (puisque nous supposons que ces données ne sont généralement pas disponibles au moment où vous construisez le TensorFlow à sérialiser).

L'utilisation d'emballages KERAS est illustrée dans notre classification des images et génération de texte tutoriels.

Générateurs de calculs fédérés

Le tff.learning paquet fournit plusieurs constructeurs pour tff.Computation s qui effectuent des tâches liées à l' apprentissage; nous nous attendons à ce que l'ensemble de ces calculs s'étende à l'avenir.

Hypothèses architecturales

Exécution

L'exécution d'un calcul fédéré comporte deux phases distinctes.

  • Compile: TFF premier compile des algorithmes d'apprentissage fédérées en une représentation abstraite sérialisée de l'ensemble de calcul distribué. C'est à ce moment-là que la sérialisation TensorFlow se produit, mais d'autres transformations peuvent se produire pour prendre en charge une exécution plus efficace. Nous nous référons à la représentation sérialisée émis par le compilateur comme un calcul fédéré.

  • Exécuter TFF fournit des moyens pour exécuter ces calculs. Pour l'instant, l'exécution n'est prise en charge que via une simulation locale (par exemple, dans un notebook utilisant des données décentralisées simulées).

Un calcul fédéré généré par fédéré API d' apprentissage de la FFT, par exemple un algorithme d'apprentissage que les utilisations étalement du modèle fédéré , ou une évaluation fédérée, comprend un certain nombre d'éléments, et plus particulièrement:

  • Une forme de votre code modèle sérialisé ainsi que le code de tensorflow supplémentaire construit par le cadre d' apprentissage fédéré pour entraîner la formation / la boucle d'évaluation du modèle (tels que la construction optimiseurs, en appliquant les mises à jour du modèle, l' itération sur tf.data.Dataset s, et les paramètres de calcul, et appliquer la mise à jour agrégée sur le serveur, pour n'en nommer que quelques-uns).

  • Une spécification déclarative de la communication entre les clients et un serveur (généralement diverses formes d'agrégation pour les dispositifs clients, et la diffusion à partir du serveur à tous les clients), et comment cette communication distribué est entrelacée avec l'exécution du client local ou local serveur du code TensorFlow.

Les calculs fédérés représentés sous cette forme sérialisé sont exprimés dans une langue interne plate-forme indépendante distincte de Python, mais d'utiliser l'API d' apprentissage fédéré, vous ne serez pas besoin de vous préoccuper des détails de cette représentation. Les calculs sont représentés dans votre code Python comme des objets de type tff.Computation , qui , pour la plupart , vous pouvez traiter comme Python opaques callable s.

Dans les didacticiels, vous invoquerez ces calculs fédérés comme s'il s'agissait de fonctions Python normales, à exécuter localement. Cependant, la FFT est conçu pour exprimer des calculs fédérés de manière agnostique à la plupart des aspects de l'environnement d'exécution, de sorte qu'ils peuvent être potentiellement déployable à, par exemple, des groupes d'appareils équipés d' Android ou de grappes dans un centre de données. Encore une fois, la principale conséquence de ce sont des hypothèses fortes sur la sérialisation . En particulier, lorsque vous invoquez l' une des build_... méthodes décrites ci - dessous le calcul est entièrement sérialisé.

État de la modélisation

TFF est un environnement de programmation fonctionnel, mais de nombreux processus d'intérêt dans l'apprentissage fédéré sont avec état. Par exemple, une boucle de formation qui implique plusieurs tours de moyenne modèle fédéré est un exemple de ce que nous pourrions classer comme un processus stateful. Dans ce processus, l'état qui évolue d'un tour à l'autre comprend l'ensemble des paramètres du modèle en cours d'apprentissage, et éventuellement un état supplémentaire associé à l'optimiseur (par exemple, un vecteur de quantité de mouvement).

Étant donné que TFF est fonctionnel, les processus avec état sont modélisés dans TFF sous forme de calculs qui acceptent l'état actuel en tant qu'entrée, puis fournissent l'état mis à jour en tant que sortie. Afin de définir complètement un processus avec état, il faut également spécifier d'où vient l'état initial (sinon nous ne pouvons pas amorcer le processus). Ceci est capturé dans la définition de la classe d'aide tff.templates.IterativeProcess , les 2 propriétés initialize et next correspondant à l'initialisation et l' itération, respectivement.

Constructeurs disponibles

À l'heure actuelle, TFF fournit deux fonctions de génération qui génèrent les calculs fédérés pour la formation et l'évaluation fédérées :

Ensembles de données

Hypothèses architecturales

Sélection des clients

Dans le scénario d'apprentissage typique fédérée, nous avons une grande population de potentiellement des centaines de millions d'appareils clients, dont seulement une petite partie peut être actif et disponible pour la formation à un moment donné (par exemple, cela peut se limiter à des clients qui sont branché à une source d'alimentation, pas sur un réseau mesuré, et autrement inactif). Généralement, l'ensemble des clients disponibles pour participer à la formation ou à l'évaluation est hors du contrôle du développeur. De plus, comme il est impossible de coordonner des millions de clients, un cycle typique de la formation ou l' évaluation comprendra seulement une fraction des clients disponibles, qui peuvent être sélectionnés au hasard .

La conséquence clé de ceci est que les calculs fédérés, par conception, sont exprimés d'une manière qui ne tient pas compte de l'ensemble exact de participants ; tout le traitement est exprimé en exploitation des agrégats sur un groupe abstrait de clients anonymes, et ce groupe peut varier d'un cycle de formation à l' autre. La liaison effective du calcul aux participants concrets, et donc aux données concrètes qu'ils alimentent dans le calcul, est ainsi modélisée en dehors du calcul lui-même.

Afin de simuler un déploiement réaliste de votre code d'apprentissage fédéré, vous allez généralement écrire une boucle d'entraînement qui ressemble à ceci :

trainer = tff.learning.build_federated_averaging_process(...)
state = trainer.initialize()
federated_training_data = ...

def sample(federate_data):
  return ...

while True:
  data_for_this_round = sample(federated_training_data)
  state, metrics = trainer.next(state, data_for_this_round)

Afin de faciliter ce processus , lors de l' utilisation TFF dans les simulations, les données fédérée est acceptée comme Python list s, avec un élément par participant périphérique client pour représenter les acteurs locaux de ce dispositif tf.data.Dataset .

Interfaces abstraites

Afin de normaliser le traitement des ensembles de données fédérées simulées, TFF fournit une interface abstraite tff.simulation.datasets.ClientData , qui permet à un d'énumérer l'ensemble des clients, et de construire un tf.data.Dataset qui contient les données d'un particulier client. Les tf.data.Dataset s peut être alimenté directement en entrée les calculs fédérés générés en mode avide.

Il convient de noter que la possibilité d'accéder aux identités des clients est une fonctionnalité qui n'est fournie par les ensembles de données que pour une utilisation dans les simulations, où la capacité de s'entraîner sur les données de sous-ensembles spécifiques de clients peut être nécessaire (par exemple, pour simuler la disponibilité diurne de différents types de clients). Les calculs compilés et le moteur d' exécution sous - jacente ne comportent aucune notion d'identité du client. Une fois que les données d'un sous - ensemble spécifique de clients a été sélectionné comme entrée, par exemple, dans un appel à tff.templates.IterativeProcess.next , les identités des clients ne semblent plus en elle.

Ensembles de données disponibles

Nous avons consacré l'espace de noms tff.simulation.datasets pour les ensembles de données qui mettent en œuvre la tff.simulation.datasets.ClientData interface pour une utilisation dans les simulations, et ensemencé avec 2 ensembles de données pour appuyer la classification d'image et génération de texte tutoriels. Nous aimerions vous encourager à contribuer vos propres ensembles de données à la plate-forme.