Помогают защитить Большой Барьерный Риф с TensorFlow на Kaggle Присоединяйтесь вызов

Федеративное обучение

Обзор

В этом документе представлены интерфейсы, которые облегчают задачи федеративного обучения, такие как федеративное обучение или оценка, с существующими моделями машинного обучения, реализованными в TensorFlow. При разработке этих интерфейсов нашей основной целью было дать возможность экспериментировать с федеративным обучением, не требуя знания того, как оно работает изнутри, и оценить реализованные алгоритмы федеративного обучения на множестве существующих моделей и данных. Мы призываем вас внести свой вклад в платформу. TFF был разработан с учетом расширяемости и компоновки, и мы приветствуем вклад; мы рады видеть, что вы придумали!

Интерфейсы, предлагаемые этим уровнем, состоят из следующих трех основных частей:

  • Модели. Классы и вспомогательные функции, позволяющие обернуть существующие модели для использования с TFF. Обертывание модели может быть столь же простым , как вызов одной функции оборачивания (например, tff.learning.from_keras_model ), или определение подкласса tff.learning.Model интерфейса для полной настраиваемости.

  • Федеративные вычислительные строители. Вспомогательные функции, которые создают объединенные вычисления для обучения или оценки с использованием ваших существующих моделей.

  • Datasets. Стандартные коллекции данных, которые вы можете загрузить и получить к ним доступ в Python для использования при моделировании сценариев федеративного обучения. Хотя федеративное обучение предназначено для использования с децентрализованными данными, которые нельзя просто загрузить из централизованного места, на этапах исследования и разработки часто бывает удобно проводить начальные эксперименты с использованием данных, которые можно загружать и обрабатывать локально, особенно для разработчиков, которые могут новичок в подходе.

Эти интерфейсы определяются в первую очередь в tff.learning пространстве имен, для наборов данных исследований и других возможностей моделирования , связанные , которые были сгруппированы в кроме tff.simulation . Этот слой реализуется с помощью интерфейсов нижнего уровня , предлагаемых Федеративного сердечник (FC) , который также обеспечивает среду выполнения.

Прежде чем продолжить, мы рекомендуем вам первый обзор учебников по классификации изображений и генерации текста , так как они представляют большинство концепций , описанными здесь с использованием примеров конкретных. Если вы заинтересованы в получении дополнительной информации о том , как работает ПТФ, вы можете скользить над пользовательскими алгоритмами учебника , как введение в интерфейс нижнего уровня , которые мы используем , чтобы выразить логику федеративных вычислений, а также изучить существующую реализацию из tff.learning интерфейсы.

Модели

Архитектурные предположения

Сериализация

TFF направлен на поддержку множества сценариев распределенного обучения, в которых код модели машинного обучения, который вы пишете, может выполняться на большом количестве разнородных клиентов с различными возможностями. Хотя на одном конце спектра, в некоторых приложениях эти клиенты могут быть мощными серверами баз данных, многие важные применения, которые наша платформа намеревается поддерживать, включают мобильные и встроенные устройства с ограниченными ресурсами. Мы не можем предположить, что эти устройства способны поддерживать среду выполнения Python; единственное, что мы можем предположить на данный момент, - это то, что они способны разместить локальную среду выполнения TensorFlow. Таким образом, фундаментальное архитектурное предположение, которое мы делаем в TFF, заключается в том, что код вашей модели должен быть сериализуемым в виде графа TensorFlow.

Вы можете (и должны) по-прежнему разрабатывать свой TF-код, следуя последним передовым практикам, таким как использование активного режима. Тем не менее, конечный код должен быть сериализациями (например, может быть завернута в качестве tf.function для кода стремится режим). Это гарантирует , что любое состояние Python или управление потоком необходимо во время выполнения , можно сериализовать (возможно , с помощью Autograph ).

В настоящее время TensorFlow не полностью поддерживает сериализацию и десериализацию TensorFlow в активном режиме. Таким образом, сериализации в настоящее время TFF по образцу TF 1.0, где весь код должен быть построен внутри tf.Graph , который управляет TFF. Это означает, что в настоящее время TFF не может использовать уже построенную модель; вместо этого, логика определения модели упакована в не-Arg функция , которая возвращает tff.learning.Model . Затем эта функция вызывается TFF для обеспечения сериализации всех компонентов модели. Кроме того, будучи сильно типизированной средой, ПТФ потребуется немного дополнительные метаданные, такие как спецификация типа ввода вашей модели.

Агрегирование

Мы настоятельно рекомендуем большинство моделей пользователей построить с помощью Keras, см преобразователей для Keras раздела ниже. Эти оболочки автоматически обрабатывают агрегирование обновлений модели, а также любые метрики, определенные для модели. Тем не менее, он все еще может быть полезно , чтобы понять , как агрегация обрабатывается для общего tff.learning.Model .

В федеративном обучении всегда есть как минимум два уровня агрегирования: локальное агрегирование на устройстве и агрегирование между устройствами (или федеративное):

  • Локальное агрегирование. Этот уровень агрегирования относится к агрегированию нескольких пакетов примеров, принадлежащих отдельному клиенту. Он применяется как к параметрам модели (переменным), которые продолжают последовательно развиваться по мере локального обучения модели, так и к вычисляемой вами статистике (например, средним потерям, точности и другим показателям), которые ваша модель снова будет обновлять локально. поскольку он перебирает локальный поток данных каждого отдельного клиента.

    Выполнение агрегирования на этом уровне является обязанностью кода вашей модели и выполняется с использованием стандартных конструкций TensorFlow.

    Общая структура обработки следующая:

    • Модель первых конструкций tf.Variable с , чтобы держать агрегаты, такие как количество партий или количество примеров обработанного, сумма потерь за партию или на-примера, и т.д.

    • ФАТ вызывает forward_pass метод на вашу Model несколько раз, последовательно через последующие порции данных клиента, что позволяет обновлять переменные проведения различных агрегатов в качестве побочного эффекта.

    • Наконец, ФАТ вызывает report_local_outputs метод на вашей модели , чтобы позволить вашей модели , чтобы собрать все сводные статистические данные , собранные его в компактный набор метрик для экспорта клиентом. Здесь код вашей модели может, например, разделить сумму потерь на количество обработанных примеров для экспорта средних потерь и т. Д.

  • Федеративные агрегации. Этот уровень агрегации относится к агрегации по нескольким клиентам (устройствам) в системе. Опять же, это относится как к параметрам модели (переменным), которые усредняются по клиентам, так и к метрикам, которые ваша модель экспортировала в результате локального агрегирования.

    За выполнение агрегирования на этом уровне отвечает TFF. Однако как создатель модели вы можете контролировать этот процесс (подробнее об этом ниже).

    Общая структура обработки следующая:

    • Первоначальная модель и любые параметры, необходимые для обучения, распространяются сервером на подмножество клиентов, которые будут участвовать в раунде обучения или оценки.

    • На каждом клиенте независимо и параллельно код вашей модели вызывается повторно в потоке пакетов локальных данных для создания нового набора параметров модели (при обучении) и нового набора локальных метрик, как описано выше (это локальный агрегация).

    • TFF использует протокол распределенной агрегации для накопления и агрегирования параметров модели и локально экспортированных метрик по всей системе. Эта логика выражается в декларативной форме с использованием собственного федеративного языка вычислений ПТФ ( а не в TensorFlow), в модели federated_output_computation. Смотрите пользовательские алгоритмы учебник для более на агрегацию API.

Абстрактные интерфейсы

Этот базовый конструктор + метаданные интерфейс представлен интерфейс tff.learning.Model , следующим образом :

  • Конструктор, forward_pass и report_local_outputs метода должна построить модель переменной, прямой проход и статистику вы хотите сообщить, соответственно. TensorFlow, созданный этими методами, должен быть сериализуемым, как обсуждалось выше.

  • input_spec собственности, а также 3 свойства, возвращаемые подмножества вашей обучаемый, не-обучаемый, и локальные переменные представляют метаданные. TFF использует эту информацию, чтобы определить, как соединить части вашей модели с объединенными алгоритмами оптимизации, и для определения внутренних сигнатур типов, чтобы помочь в проверке правильности сконструированной системы (чтобы ваша модель не могла быть создана на основе данных, которые не соответствуют модель рассчитана на потребление).

Кроме того, абстрактный интерфейс tff.learning.Model предоставляет свойство federated_output_computation , что вместе с report_local_outputs свойство упоминалось ранее, позволяет контролировать процесс объединения итоговой статистики.

Вы можете найти примеры того , как определить свой собственный tff.learning.Model во второй части нашего изображения классификации учебника, а также в примерах моделей , которые мы используем для тестирования в model_examples.py .

Конвертеры для Кераса

Почти вся информация , которая требуется TFF может быть получена путем вызова tf.keras интерфейсов, поэтому если у вас есть модель Keras, вы можете рассчитывать на tff.learning.from_keras_model построить tff.learning.Model .

Обратите внимание , что ФАТ по- прежнему хочет , чтобы вы предоставить конструктор - функция без аргументов модели , такие как следующие:

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

В дополнение к самой модели вы предоставляете образец пакета данных, который TFF использует для определения типа и формы входных данных вашей модели. Это гарантирует, что TFF может правильно создать экземпляр модели для данных, которые будут фактически присутствовать на клиентских устройствах (поскольку мы предполагаем, что эти данные обычно недоступны в то время, когда вы создаете TensorFlow для сериализации).

Использование Keras оберток иллюстрируется в нашей классификации изображений и генерации текста учебники.

Построители федеративных вычислений

tff.learning пакет предоставляет несколько строителей для tff.Computation s , которые выполняют учебные задания , связанные с ; мы ожидаем, что в будущем набор таких вычислений будет расширяться.

Архитектурные предположения

Исполнение

Выполнение объединенных вычислений состоит из двух отдельных этапов.

  • Compile: ПТФ первый компилирует федеративных алгоритмы обучения в абстрактном упорядоченное представление всей распределенных вычислений в. Это когда происходит сериализация TensorFlow, но могут происходить и другие преобразования для поддержки более эффективного выполнения. Мы имеем в виду сериализованного представления излучаемого компилятора как федеративные вычисления.

  • Выполнить ПТФ обеспечивает способы выполнения этих вычислений. На данный момент выполнение поддерживается только посредством локального моделирования (например, в записной книжке с использованием смоделированных децентрализованных данных).

Федеративное вычисление генерируется ПТФОМ в Федеративных Learning API, такие как алгоритм обучения , который использует федеративную модель усреднения , или федеративную оценку, включает в себя ряд элементов, в первую очередь:

  • Сериализованный форма вашей модели кода, а также дополнительный код TensorFlow построен в рамках федеративного Обучение вождению цикл обучения / оценки вашей модели (например, строительство оптимизаторы, применение обновлений модели, итерация tf.data.Dataset s и вычисления метрик, и применение агрегированного обновления на сервере, и это лишь некоторые из них).

  • Декларативная спецификация обмена данных между клиентами и сервером ( как правило , различные формами агрегации через клиентские устройства и передающие с сервера для всех клиентов), и как это распределенная связь перемежаются с клиентом локального или серверным локальным исполнением кода TensorFlow.

Федеративные расчеты , представленные в этой форме сериализованном выражаются в независимой от платформы внутреннего языка , отличного от Python, но использовать API Федеративные обучения, вам не нужно беспокоиться о деталях этого представления. Расчеты представлены в коде Python в качестве объектов типа tff.Computation , которые по большей части вы можете лечить , как непрозрачный Python callable с.

В учебных пособиях вы будете вызывать эти объединенные вычисления, как если бы они были обычными функциями Python, для локального выполнения. Тем не менее, ПТФ предназначен для выражения федеративного вычисления таким образом , агностик большинства аспектов среды выполнения, так что они могут потенциально быть развертываемыми к, например, группы устройств , работающих под управлением Android или кластеры в центрах обработки данных. Опять же , главным следствием этого являются сильные предположения о сериализации . В частности, при вызове одной из build_... методов , описанных ниже вычислений полностью сериализации.

Состояние моделирования

TFF - это среда функционального программирования, но многие процессы, представляющие интерес для федеративного обучения, имеют состояние. Например, учебный цикл , который включает в себя несколько раундов федеративной модели усреднения является примером того , что мы могли бы классифицировать как с учетом состояния процесса. В этом процессе состояние, которое развивается от раунда к раунду, включает в себя набор обучаемых параметров модели и, возможно, дополнительное состояние, связанное с оптимизатором (например, вектор импульса).

Поскольку TFF является функциональным, процессы с отслеживанием состояния моделируются в TFF как вычисления, которые принимают текущее состояние в качестве входных данных, а затем предоставляют обновленное состояние в качестве выходных данных. Чтобы полностью определить процесс с состоянием, также необходимо указать, откуда происходит начальное состояние (в противном случае мы не сможем запустить процесс). Это фиксируется в определении вспомогательного класса tff.templates.IterativeProcess , с 2 свойства initialize и в next , соответствующих инициализации и итерации, соответственно.

Доступные строители

На данный момент TFF предоставляет две функции построения, которые генерируют объединенные вычисления для объединенного обучения и оценки:

Наборы данных

Архитектурные предположения

Выбор клиента

В типичном федеративном сценарии обучения, у нас есть большое население потенциально сотни миллионов клиентских устройств, из которых лишь малая часть может быть активной и доступной для обучения в любой момент (например, это может быть ограничено для клиентов, которые подключен к источнику питания, а не к сети с измерением, и в противном случае простаивает). Как правило, набор клиентов, доступных для участия в обучении или оценке, находится вне контроля разработчика. Кроме того, как это непрактично координировать миллионы клиентов, типичный раунд подготовки или оценки будет включать в себя лишь часть имеющихся клиентов, которые могут быть в выборке случайным образом .

Ключевым следствием этого является то, что объединенные вычисления по замыслу выражаются таким образом, чтобы не учитывать точный набор участников; вся обработка выражается в виде совокупности операций на абстрактную группу анонимных клиентов, и эта группа может варьироваться от одного раунда подготовки к другому. Фактическая привязка вычисления к конкретным участникам и, следовательно, к конкретным данным, которые они вводят в вычисление, таким образом моделируется вне самого вычисления.

Чтобы смоделировать реалистичное развертывание кода федеративного обучения, вы обычно напишете цикл обучения, который выглядит следующим образом:

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)

Для того , чтобы облегчить эту задачу , при использовании TFF при моделировании, федеративные данные принимаются как Python list s, с одним элементом на участие клиентского устройства для представления локального этого устройства tf.data.Dataset .

Абстрактные интерфейсы

Для того , чтобы стандартизировать дело с моделируемыми объединенными наборами данных, ПТФ предоставляет абстрактный интерфейс tff.simulation.datasets.ClientData , что позволяет перечислить множество клиентов, и построить tf.data.Dataset , который содержит данные о конкретном клиент. Те tf.data.Dataset ы может быть подан непосредственно в качестве входных данных для сгенерированных объединенных вычислений в нетерпеливом режиме.

Следует отметить, что возможность доступа к идентификаторам клиентов - это функция, которая предоставляется только наборами данных для использования в моделировании, где может потребоваться возможность обучения на данных от определенных подмножеств клиентов (например, для моделирования суточной доступности различных типы клиентов). Скомпилированные вычисления и подстилающая среда выполнение не связаны с каким - либо понятием идентичности клиента. После того, как данные из определенного подмножества клиентов были выбраны в качестве входного сигнала, например, при вызове tff.templates.IterativeProcess.next , клиент тождество больше не появляется в нем.

Доступные наборы данных

Мы посвятили пространства имен tff.simulation.datasets для наборов данных , которые реализуют tff.simulation.datasets.ClientData интерфейс для использования в моделировании, и высевают его с 2 - мя наборами данных для поддержки классификации изображений и генерации текста учебники. Мы хотели бы побудить вас внести свои собственные наборы данных на платформу.