Посетите симпозиум «Женщины в машинном обучении» 7 декабря Зарегистрируйтесь сейчас

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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Обзор

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

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

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

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

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

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

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

Модели

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

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

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

Вы можете (и должны) по-прежнему разрабатывать свой код TF, следуя последним передовым методам, таким как использование активного режима. Однако окончательный код должен быть сериализуемым (например, может быть обернут как 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 для хранения агрегатов, таких как количество пакетов или количество обработанных примеров, сумма потерь для каждой партии или для каждого примера и т. д.

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

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

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

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

    Общая структура обработки выглядит следующим образом:

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

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

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

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

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

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

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

Кроме того, абстрактный интерфейс tff.learning.Model предоставляет свойство metric_finalizers , которое принимает незавершенные значения метрики (возвращенные report_local_unfinalized_metrics() ) и возвращает окончательные значения метрик. metric_finalizers и report_local_unfinalized_metrics() будут использоваться вместе для создания межклиентского агрегатора метрик при определении объединенных процессов обучения или оценочных вычислений. Например, простой агрегатор tff.learning.metrics.sum_then_finalize сначала суммирует нефинализированные значения метрик от клиентов, а затем вызывает функции финализатора на сервере.

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

Преобразователи для Кераса

Почти вся информация, необходимая TFF, может быть получена путем вызова интерфейсов tf.keras , поэтому, если у вас есть модель Keras, вы можете положиться на 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 предоставляет способы выполнения этих вычислений. На данный момент выполнение поддерживается только через локальное моделирование (например, в записной книжке с использованием смоделированных децентрализованных данных).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

trainer = tff.learning.algorithms.build_weighted_fed_avg(...)
state = trainer.initialize()
federated_training_data = ...

def sample(federate_data):
  return ...

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

Чтобы облегчить это, при использовании TFF в симуляциях объединенные данные принимаются в виде list Python с одним элементом на каждое участвующее клиентское устройство для представления локального tf.data.Dataset этого устройства.

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

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

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

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

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