… Или как Google Фото использует мои личные изображения для самосовершенствования

Введение

В этой статье я представлю и опишу федеративное обучение - новую парадигму машинного обучения, которая была представлена ​​в 2016 году компанией Google. Но сначала позвольте мне установить сцену.

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

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

Но что, если у вас недостаточно данных? Или получение большого количества обучающих образцов может вызвать некоторые проблемы с конфиденциальностью (в конце концов, в чатах часто используются смайлики)? Или, что еще хуже, что, если вы предпочтете использовать существующие вычислительные мощности для проекта с более высоким приоритетом? Что ж, в 2016 году Google представил гениальное решение, и с тех пор оно набирает обороты: пусть пограничные устройства выполняют обучение за вас!

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

Проще говоря, при федеративном обучении вместо владения данными и алгоритмом обучения вы просто владеете алгоритмом и агрегированной (или общей) моделью.

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

Итак, давайте рассмотрим те проблемы, которые у нас были раньше; ваши данные теперь практически безграничны, и всякий раз, когда появляются новые данные, периферийные устройства автоматически обновляют свои локальные модели и отправляют свои «результаты» на сервер. Кроме того, вашим клиентам / пользователям больше не нужно беспокоиться о конфиденциальности, поскольку данные никогда не покидают их устройства. А теперь, поскольку каждое пограничное устройство имеет гораздо меньший объем данных, можно было бы запускать алгоритмы обучения на них, и вам не нужно было бы вообще выделять какие-либо ресурсы для обучения.

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

Цель и виды ФЛ

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

Предположим (я не знаю, как это работает на самом деле) у Google есть обученная модель, которая обычно хороша для группировки фотографий с одним и тем же человеком. Но что, если модель вызывает сомнения? Затем приложение спросит пользователя, появляется ли какой-нибудь случайный человек на двух фотографиях в качестве примера. Ответы пользователей на самом деле являются частью локальных обучающих данных, которые будут использоваться для настройки их локальной модели, а позже обновления могут быть отправлены в глобальную модель для ее точной настройки без переобучения некоторых конкретных данных.

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

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

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

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

Основные вызовы FL

При федеративном обучении одна из самых серьезных проблем, с которыми приходится сталкиваться, - это качество данных. Как правило, вы хотите, чтобы ваши образцы данных были независимыми и одинаково распределенными (iid). Проще говоря, вы хотите иметь почти одинаковое количество выборок для каждого класса, который должна увидеть ваша модель (при условии, что вы выполняете задачу классификации). Например, для классификатора собаки / кошки вы хотите, чтобы соотношение изображений кошек и изображений собак было почти 1: 1.

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

Еще одна проблема, с которой столкнулась концепция FL, - это увеличенная задержка. Обратное распространение в классическом случае требует очень низкой задержки для быстрого обучения. Это требование легко достигается при запуске на локальном компьютере. Но с задержкой в ​​сети, присутствующей в сетях связи, и вы можете себе представить, насколько высока она может быть дана миллионам устройств, которые могут использоваться для обучения, алгоритм может быть замедлен на несколько порядков.

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

Вывод

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

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

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

Если вы хотите внести свой вклад, отправляйтесь на наш призыв к участникам. Вы также можете подписаться на наши еженедельные информационные бюллетени (Deep Learning Weekly и Comet Newsletter), присоединиться к нам в » «Slack и подписаться на Comet в Twitter и LinkedIn для получения ресурсов, событий и гораздо больше, что поможет вам быстрее и лучше строить модели машинного обучения.