Ayuda a proteger la Gran Barrera de Coral con TensorFlow en Kaggle Únete Challenge

Aprendizaje federado

Visión general

Este documento presenta interfaces que facilitan las tareas de aprendizaje federado, como la capacitación o la evaluación federada con modelos de aprendizaje automático existentes implementados en TensorFlow. Al diseñar estas interfaces, nuestro objetivo principal era hacer posible experimentar con el aprendizaje federado sin requerir el conocimiento de cómo funciona bajo el capó, y evaluar los algoritmos de aprendizaje federado implementados en una variedad de modelos y datos existentes. Le animamos a contribuir de nuevo a la plataforma. TFF ha sido diseñado teniendo en cuenta la extensibilidad y componibilidad, y agradecemos las contribuciones; ¡Estamos emocionados de ver lo que se te ocurra!

Las interfaces que ofrece esta capa constan de las siguientes tres partes clave:

  • Modelos. Clases y funciones auxiliares que le permiten ajustar sus modelos existentes para usarlos con TFF. Envolviendo un modelo puede ser tan simple como llamar a una sola función de envoltura (por ejemplo, tff.learning.from_keras_model ), o la definición de una subclase de la tff.learning.Model interfaz para la plena personalización.

  • Constructores federados cálculo. Funciones auxiliares que construyen cálculos federados para entrenamiento o evaluación, utilizando sus modelos existentes.

  • Los conjuntos de datos. Colecciones de datos almacenadas que puede descargar y acceder en Python para su uso en la simulación de escenarios de aprendizaje federado. Aunque el aprendizaje federado está diseñado para su uso con datos descentralizados que no se pueden descargar simplemente en una ubicación centralizada, en las etapas de investigación y desarrollo a menudo es conveniente realizar experimentos iniciales utilizando datos que se pueden descargar y manipular localmente, especialmente para desarrolladores que podrían estar nuevo en el enfoque.

Estas interfaces se definen principalmente en el tff.learning espacio de nombres, a excepción de los conjuntos de datos de investigación y otras capacidades relacionadas con la simulación, que se han agrupado en tff.simulation . Esta capa se implementa utilizando las interfaces de nivel inferior que ofrece el Federated Core (FC) , que también proporciona un entorno de tiempo de ejecución.

Antes de continuar, le recomendamos que primero revise los tutoriales sobre la clasificación de imágenes y la generación de texto , ya que introducen la mayor parte de los conceptos descritos aquí usando ejemplos concretos. Si está interesado en aprender más acerca de cómo funciona la TFF, es posible que desee pasar rozando el encargo algoritmos tutorial como una introducción a las interfaces de nivel inferior que utilizamos para expresar la lógica de los cálculos federados, y para estudiar la implementación existente de la tff.learning interfaces.

Modelos

Supuestos arquitectónicos

Publicación por entregas

TFF tiene como objetivo admitir una variedad de escenarios de aprendizaje distribuido en los que el código del modelo de aprendizaje automático que escribe podría ejecutarse en una gran cantidad de clientes heterogéneos con diversas capacidades. Si bien en un extremo del espectro, en algunas aplicaciones esos clientes pueden ser potentes servidores de bases de datos, muchos de los usos importantes que nuestra plataforma pretende admitir involucran dispositivos móviles e integrados con recursos limitados. No podemos asumir que estos dispositivos sean capaces de albergar tiempos de ejecución de Python; lo único que podemos asumir en este punto es que son capaces de alojar un tiempo de ejecución de TensorFlow local. Por lo tanto, una suposición arquitectónica fundamental que hacemos en TFF es que el código de su modelo debe ser serializable como un gráfico de TensorFlow.

Aún puede (y debe) desarrollar su código TF siguiendo las últimas mejores prácticas, como usar el modo ansioso. Sin embargo, el código final debe ser serializable (por ejemplo, puede ser envuelto como un tf.function para código en modo ansioso). Esto asegura que fluyen necesario cualquier estado o de control Python en tiempo de ejecución se pueden serializar (posiblemente con la ayuda de autógrafos ).

Actualmente, TensorFlow no es totalmente compatible con la serialización y deserialización de TensorFlow en modo ansioso. Por lo tanto, la serialización en TFF Actualmente sigue el patrón TF 1.0, donde todo el código debe ser construido dentro de un tf.Graph que los controles de TFF. Esto significa que actualmente TFF no puede consumir un modelo ya construido; En su lugar, la lógica del modelo definición se envasa en una función no-arg que devuelve un tff.learning.Model . Luego, TFF llama a esta función para garantizar que todos los componentes del modelo estén serializados. Además, al ser un entorno fuertemente tipado, TFF requerirá un poco de metadatos adicionales, tales como una especificación del tipo de entrada de su modelo.

Agregación

Se recomienda encarecidamente la mayoría de los modelos de los usuarios de los fragmentos con Keras, vemos los Convertidores para Keras sección de abajo. Estos contenedores manejan la agregación de actualizaciones del modelo, así como cualquier métrica definida para el modelo automáticamente. Sin embargo, todavía puede ser útil para entender cómo se maneja la agregación de un general tff.learning.Model .

Siempre hay al menos dos capas de agregación en el aprendizaje federado: agregación local en el dispositivo y agregación entre dispositivos (o federada):

  • La agregación local. Este nivel de agregación se refiere a la agregación en múltiples lotes de ejemplos propiedad de un cliente individual. Se aplica tanto a los parámetros del modelo (variables), que continúan evolucionando secuencialmente a medida que el modelo se entrena localmente, como a las estadísticas que calcula (como la pérdida promedio, la precisión y otras métricas), que su modelo volverá a actualizar localmente. a medida que itera sobre el flujo de datos locales de cada cliente individual.

    Realizar la agregación en este nivel es responsabilidad de su código de modelo y se logra mediante construcciones estándar de TensorFlow.

    La estructura general del procesamiento es la siguiente:

    • El modelo construye primero tf.Variable s a los agregados de retención, tal como el número de lotes o el número de ejemplos procesados, la suma de las pérdidas por lotes o por-ejemplo, etc.

    • TFF invoca el forward_pass método en sus Model varias veces, de forma secuencial lotes durante posteriores de los datos del cliente, lo que le permite actualizar las variables de la mano de diversos agregados como un efecto secundario.

    • Por último, TFF invoca el report_local_outputs método en su modelo para permitir su modelo para compilar todas las estadísticas de resumen se recoge en un conjunto compacto de métricas para ser exportados por el cliente. Aquí es donde su código de modelo puede, por ejemplo, dividir la suma de pérdidas por el número de ejemplos procesados ​​para exportar la pérdida promedio, etc.

  • Agregación Federated. Este nivel de agregación se refiere a la agregación a través de múltiples clientes (dispositivos) en el sistema. Nuevamente, se aplica tanto a los parámetros del modelo (variables), que se promedian entre los clientes, como a las métricas que su modelo exportó como resultado de la agregación local.

    Realizar la agregación en este nivel es responsabilidad de TFF. Sin embargo, como creador de modelos, puede controlar este proceso (más sobre esto a continuación).

    La estructura general del procesamiento es la siguiente:

    • Un servidor distribuye el modelo inicial y los parámetros necesarios para la capacitación a un subconjunto de clientes que participarán en una ronda de capacitación o evaluación.

    • En cada cliente, de forma independiente y en paralelo, el código de su modelo se invoca repetidamente en un flujo de lotes de datos locales para producir un nuevo conjunto de parámetros del modelo (durante el entrenamiento) y un nuevo conjunto de métricas locales, como se describe anteriormente (esto es local agregación).

    • TFF ejecuta un protocolo de agregación distribuido para acumular y agregar los parámetros del modelo y las métricas exportadas localmente en todo el sistema. Esta lógica se expresa de una manera declarativa usando lenguaje propio cómputo de Federated TFF (no en TensorFlow), en el modelo de federated_output_computation. Ver el encargo algoritmos tutorial para más información sobre la API de agregación.

Interfaces abstractas

Este constructor + interfaz de metadatos básico está representado por la interfaz tff.learning.Model , como sigue:

  • El constructor, forward_pass y report_local_outputs métodos deben construir las variables del modelo, pase hacia adelante, y las estadísticas que desea el informe, correspondientemente. El TensorFlow construido por esos métodos debe ser serializable, como se discutió anteriormente.

  • El input_spec propiedad, así como las 3 propiedades que los subconjuntos de retorno de su entrenable, no entrenable, y las variables locales representan los metadatos. TFF utiliza esta información para determinar cómo conectar partes de su modelo a los algoritmos de optimización federados y para definir firmas de tipo internas para ayudar a verificar la corrección del sistema construido (de modo que su modelo no pueda ser instanciado sobre datos que no coincidan con lo que el modelo está diseñado para consumir).

Además, la interfaz abstracta tff.learning.Model expone una propiedad federated_output_computation que, junto con el report_local_outputs propiedad se mencionó anteriormente, le permite controlar el proceso de agregación de las estadísticas de resumen.

Puede encontrar ejemplos de cómo definir su propio encargo tff.learning.Model en la segunda parte de nuestra imagen clasificación tutorial, así como en los modelos de ejemplo que usamos para probar en model_examples.py .

Convertidores para Keras

Casi toda la información que se requiere por TFF se puede derivar llamando tf.keras las interfaces, así que si usted tiene un modelo Keras, que puede confiar en tff.learning.from_keras_model para construir un tff.learning.Model .

Tenga en cuenta que TFF todavía quiere que proporcione un constructor - una función de modelo sin argumentos como el siguiente:

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

Además del modelo en sí, proporciona un lote de datos de muestra que TFF utiliza para determinar el tipo y la forma de la entrada de su modelo. Esto asegura que TFF pueda instanciar correctamente el modelo para los datos que realmente estarán presentes en los dispositivos cliente (dado que asumimos que estos datos no están disponibles en general en el momento en que está construyendo TensorFlow para ser serializado).

El uso de envolturas Keras se ilustra en nuestros clasificación de imágenes y la generación de texto tutoriales.

Constructores de computación federada

El tff.learning paquete proporciona varios constructores para tff.Computation s que realizar tareas relacionadas con el aprendizaje; esperamos que el conjunto de dichos cálculos se expanda en el futuro.

Supuestos arquitectónicos

Ejecución

Hay dos fases distintas en la ejecución de un cálculo federado.

  • Compilar: TFF primera compila algoritmos de aprendizaje federados en una representación serializada abstracta de toda la computación distribuida. Aquí es cuando ocurre la serialización de TensorFlow, pero pueden ocurrir otras transformaciones para admitir una ejecución más eficiente. Nos referimos a la representación serializada emitida por el compilador como un cálculo federado.

  • Ejecutar TFF proporciona formas de ejecutar estos cálculos. Por ahora, la ejecución solo se admite a través de una simulación local (por ejemplo, en un cuaderno usando datos descentralizados simulados).

Un cálculo federados generada por de TFF Federated Learning API, tal como un algoritmo de entrenamiento que los usos modelo federado de promediado , o una evaluación federado, incluye un número de elementos, lo más notablemente:

  • Una forma de serie de su código de modelo, así como el código TensorFlow adicional construido por el marco Federados aprender a conducir bucle de formación / evaluación de su modelo (como la construcción de los optimizadores, la aplicación de actualizaciones de modelo, interactuando sobre tf.data.Dataset s, y la métrica de computación, y aplicar la actualización agregada en el servidor, por nombrar algunos).

  • Una especificación declarativa de la comunicación entre los clientes y un servidor (típicamente diversas formas de agregación a través de los dispositivos cliente, y a transmitir desde el servidor a todos los clientes), y cómo esta comunicación distribuida se intercalados con la ejecución de cliente-local o servidor local del código de TensorFlow.

Los cálculos federados representadas en esta forma de serie se expresan en un lenguaje interno independiente de la plataforma distinta de Python, pero para utilizar la API Federados de aprendizaje, no será necesario que preocuparse de los detalles de esta representación. Los cálculos están representados en el código Python como objetos de tipo tff.Computation , que en su mayor parte se puede tratar como opacos Python callable s.

En los tutoriales, invocará esos cálculos federados como si fueran funciones normales de Python, para que se ejecuten localmente. Sin embargo, TFF está diseñado para expresar cálculos federados en un agnóstico manera a la mayoría de los aspectos del entorno de ejecución, de manera que potencialmente pueden ser desplegables a, por ejemplo, grupos de dispositivos que ejecutan Android , o para las agrupaciones en un centro de datos. Una vez más, la principal consecuencia de esto son fuertes suposiciones acerca de la serialización . En particular, cuando se invoca una de las build_... métodos descritos a continuación el cálculo está totalmente serializado.

Estado de modelado

TFF es un entorno de programación funcional, sin embargo, muchos procesos de interés en el aprendizaje federado tienen estado. Por ejemplo, un circuito de entrenamiento que implica múltiples rondas de federados promedio de modelos es un ejemplo de lo que podríamos clasificar como un proceso con estado. En este proceso, el estado que evoluciona de una ronda a otra incluye el conjunto de parámetros del modelo que se están entrenando y posiblemente un estado adicional asociado con el optimizador (por ejemplo, un vector de impulso).

Dado que TFF es funcional, los procesos con estado se modelan en TFF como cálculos que aceptan el estado actual como entrada y luego proporcionan el estado actualizado como salida. Para definir completamente un proceso con estado, también es necesario especificar de dónde proviene el estado inicial (de lo contrario, no podemos iniciar el proceso). Esta es capturada en la definición de la clase de ayuda tff.templates.IterativeProcess , con las 2 propiedades initialize y next correspondiente a la inicialización y la iteración, respectivamente.

Constructores disponibles

Por el momento, TFF proporciona dos funciones de construcción que generan los cálculos federados para el entrenamiento y la evaluación federados:

Conjuntos de datos

Supuestos arquitectónicos

Selección de cliente

En el escenario típico de aprendizaje federados, tenemos una gran población de potencialmente cientos de millones de dispositivos de clientes, de los cuales sólo una pequeña porción puede ser activa y disponible para la formación en un momento dado (por ejemplo, esto puede ser limitado a los clientes que están enchufado a una fuente de alimentación, no a una red con medidor y, de lo contrario, inactivo). Generalmente, el conjunto de clientes disponibles para participar en la capacitación o evaluación está fuera del control del desarrollador. Por otra parte, ya que es poco práctico para coordinar millones de clientes, una típica ronda de formación o evaluación incluirá sólo una fracción de los clientes disponibles, que pueden ser tomados al azar .

La consecuencia clave de esto es que los cálculos federados, por diseño, se expresan de una manera que ignora el conjunto exacto de participantes; todo el procesamiento se expresa como operaciones de agregados en un grupo abstracto de clientes anónimos, y ese grupo podría variar de un ciclo de capacitación a otro. La vinculación real del cálculo a los participantes concretos y, por lo tanto, a los datos concretos que alimentan al cálculo, se modela así fuera del cálculo en sí.

Para simular una implementación realista de su código de aprendizaje federado, generalmente escribirá un ciclo de entrenamiento que se ve así:

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)

Con el fin de facilitar esta tarea, cuando se utiliza TFF en las simulaciones, los datos federada se acepta como Python list s, con un elemento por cada dispositivo cliente que participa para representar local del dispositivo que tf.data.Dataset .

Interfaces abstractas

Con el fin de estandarizar tratar con conjuntos de datos federados simulados, TFF proporciona una interfaz abstracto tff.simulation.datasets.ClientData , que le permite a uno para enumerar el conjunto de clientes, y para construir un tf.data.Dataset que contiene los datos de un particular, cliente. Aquellos tf.data.Dataset s se puede alimentar directamente como entrada para los cálculos federados generados en el modo ansioso.

Cabe señalar que la capacidad de acceder a las identidades de los clientes es una característica que solo proporcionan los conjuntos de datos para su uso en simulaciones, donde puede ser necesaria la capacidad de entrenar con datos de subconjuntos específicos de clientes (por ejemplo, para simular la disponibilidad diurna de diferentes tipos de clientes). Los cálculos compilados y el tiempo de ejecución subyacente no implican ninguna noción de la identidad del cliente. Una vez que los datos de un subconjunto específico de clientes ha sido seleccionado como una entrada, por ejemplo, en una llamada a tff.templates.IterativeProcess.next , las identidades de los clientes ya no aparecen en ella.

Conjuntos de datos disponibles

Hemos dedicado el espacio de nombres tff.simulation.datasets para conjuntos de datos que implementan la tff.simulation.datasets.ClientData interfaz para su uso en simulaciones, y se sembró con 2 conjuntos de datos para apoyar las clasificación de imágenes y la generación de texto tutoriales. Nos gustaría animarle a que contribuya con sus propios conjuntos de datos a la plataforma.