(** Обновление 2020/01/11: значительно улучшенная версия библиотеки, описанной в этой статье, под названием dc_federated, теперь сделана с открытым исходным кодом. В настоящее время это бета-версия. и был разработан для развертывания в масштабе консорциума. **)

Введение

Построение моделей машинного обучения (ML) обычно требует большого количества данных, но во многих важных практических приложениях данные хранятся в разрозненных хранилищах, которые нельзя взломать из соображений конфиденциальности или конфиденциальности. Каноническим и очень уместным примером является проблема построения моделей машинного обучения для прогнозирования COVID-19 на основе медицинских изображений, которые находятся в разных больницах, расположенных в разных юрисдикциях. Федеративное обучение (FL) - это недавно разработанный распределенный метод машинного обучения с сохранением конфиденциальности, который позволяет избежать этого потенциального препятствия. Пожалуйста, см. [1] для отличного и всестороннего технического обзора этой области.

Но вкратце FL пытается решить проблему построения модели машинного обучения, которая обучается на данных, распределенных между множеством различных сотрудников / клиентов , без сбора или перемещения данных в какое-либо центральное место. Эта модель расположена на центральном сервере, и этот сервер отвечает за управление процессом федеративного обучения. Рабочие потенциально находятся в разных сетях и физических местах и ​​имеют потенциально разные возможности обработки. Во время обучения модели на сервере данные никогда не покидают воркера, у которого они возникли. Распределение данных потенциально различается среди рабочих, но атрибуты / поля данных и архитектура модели обычно считаются одинаковыми (хотя эти ограничения ослабляются при федеративном обучении). См. Рисунок 1 ниже a для схематической иллюстрации процесса федеративного обучения и разделы ниже для получения дополнительных сведений. Пожалуйста, прочтите этот сопутствующий пост в блоге, чтобы получить общее представление о федеративном пространстве, включая примеры развернутых систем, будущих приложений и значение FL с точки зрения бизнес-моделей.

В этой статье мы сосредоточимся исключительно на том, как можно создать открытую, расширяемую и общую библиотеку для федеративного обучения, которая легко поддается исследованиям, экспериментам и последующему развертыванию в реальном времени. Обсуждение основано на нашем собственном опыте создания независимой от платформы библиотеки проверки концепции в Digital Catapult. Мы также рассмотрим существующие библиотеки и фреймворки и обсудим, чем этот подход отличается от этих текущих подходов и почему они отличаются. В заключение мы рассмотрим следующий шаг: как мы можем построить открытую экосистему для НИОКР и разработки приложений в федеративном обучении. Это поможет предотвратить фрагментированный рынок решений для федеративного обучения, поможет сохранить функциональную совместимость этих решений, а также будет способствовать инновациям в этой сфере.

Многоуровневая архитектура для федеративных обучающих библиотек

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

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

Шаг 1. Локальные модели на клиентах обновляются с использованием частных локальных данных:

Этот шаг состоит из одной или нескольких итераций обычного алгоритма машинного обучения. Например, если используются глубокие нейронные сети, то этот шаг может состоять, возможно, из одного или нескольких пакетов или эпох обучения локальной модели на локальных данных с использованием SGD и т. Д. Следовательно, этот шаг зависит от приложения (распознавание медиального изображения, НЛП, обнаружение мошенничества, оценка рисков и т. Д.), А также платформу, выбранную для реализации местной модели.

Шаг 2. Рабочие (или подмножество рабочих) отправляют «локальные обновления» на центральный сервер.

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

Шаг 3. Сервер объединяет локальные обновления в глобальную модель.

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

Шаг 4. Сервер отправляет глобальную модель всем рабочим.

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

Шаг 5. Рабочие интегрируют глобальную модель в свою локальную.

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

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

  1. Приложение + платформа внедрения (локальная или глобальная).
  2. Алгоритм федеративного обучения + платформа для реализации.
  3. Независимо от алгоритма федеративного обучения и платформы, то есть является общим для всех систем федеративного обучения.

Следовательно, мы можем разбить федеративную систему обучения на классическую многоуровневую архитектуру с тремя уровнями, по одному для каждой из зависимостей, указанных выше. Каждый уровень предоставляет четко определенный API, но в остальном не зависит от других уровней, при этом все детали абстрагируются. Наиболее известной из этих многоуровневых архитектур, вероятно, является стек TCP / IP, на котором работает Интернет. Более точно мы определяем слои следующим образом:

Прикладной уровень

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

Слой алгоритма

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

Серверный уровень связи

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

Наша федеративная обучающая библиотека на Python, созданная в Digital Catapult, под названием dc_federated реализует эту архитектуру. Мы предоставляем определение и реализацию эталонного API в pytorch для уровня приложения и алгоритма, а также платформенно-независимую реализацию уровня коммуникационного бэкэнда. Библиотека изначально разрабатывалась как инструмент для демонстрации федеративного обучения нашим клиентам, а с тех пор превратилась в библиотеку, которую можно развернуть для реальных приложений. Серверная часть связи предоставляет услуги аутентификации и управления сотрудниками, поддерживает шифрованную и сжатую связь и масштабируется до сотен сотрудников, подходящих для федеративного обучения на уровне консорциума. На приведенной ниже диаграмме более подробно показана архитектура для конкретного алгоритма и приложения. В настоящее время репозиторий имеет эталонные реализации для двух доменов приложений на уровне приложений (MNIST, PlantVillage) и одного алгоритма (FedAvg) на уровне алгоритмов.

Будущее: открытые экосистемы для федеративного обучения

Мы мотивируем открытые экосистемы для FL, выясняя, почему мы создали нашу библиотеку. В частности, учитывая, что существуют хорошо известные библиотеки, такие как tf-federated (для тензорного потока), pysyft (для pytorch), и такие фреймворки, как FATE от WeBank и Clara SDK для NVIDIA, возможно, было бы разумнее использовать одну из этих ?

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

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

А. Коллективное согласование общей архитектуры для систем FL (например, гораздо более развитой версии архитектуры, представленной выше) с общим базовым API.

Б. реализация общих аспектов масштабируемым, эффективным, безопасным, открытым и прозрачным способом с использованием решения с открытым исходным кодом

C. оставляя индивидуальные части для реализации и разработки в соответствии с потребностями отдельных разработчиков или пространств решений.

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

Вывод

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

использованная литература

[1] Кайруз и др. Успехи и открытые проблемы в федеративном обучении. ARXIV: 1922.04977, 2019. https://arxiv.org/abs/1912.04977