Эта страница переведена с помощью Cloud Translation API.
Switch to English

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

Обзор

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

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

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

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

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

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

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

Модели

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

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

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

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

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

Агрегация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исполнение

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

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

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

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

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

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

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

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

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

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

Поскольку TFF является функциональным, процессы с сохранением состояния моделируются в TFF как вычисления, которые принимают текущее состояние в качестве входных данных, а затем предоставляют обновленное состояние в качестве выходных данных. Чтобы полностью определить процесс с состоянием, также необходимо указать, откуда происходит начальное состояние (иначе мы не сможем запустить процесс). Это зафиксировано в определении вспомогательного класса tff.templates.IterativeProcess с двумя свойствами 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 в моделировании объединенные данные принимаются как list Python, с одним элементом на каждое участвующее клиентское устройство, представляющим локальныйtf.data.Dataset этого устройства.

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

Чтобы стандартизировать работу с смоделированными наборами объединенных данных, TFF предоставляет абстрактный интерфейс tff.simulation.ClientData , который позволяет перечислять набор клиентов и создаватьtf.data.Dataset , содержащий данные конкретного клиента. Этиtf.data.Dataset могут быть переданы непосредственно в качестве входных данных для сгенерированных объединенных вычислений в активном режиме.

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

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

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