Как обучать ИИ, не передавая данные: федеративное обучение выходит на корпоративный уровень

Представьте: несколько больниц хотят совместно обучить модель для диагностики, но ни одна из них не может передать данные пациентов другой стороне. Или банки, которым нужно бороться с мошенничеством сообща, но делиться транзакционными данными клиентов им запрещает закон. Классический подход к машинному обучению здесь не работает – он требует собрать все данные в одном месте. Федеративный ИИ предлагает другую логику: модель «едет» к данным, а не данные к модели.

Принцип работы и преимущества федеративного обучения данных

Модель едет к данным – а не наоборот

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

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

Возможности фреймворка Flower для разработки федеративных моделей

Flower: «пиши один раз, запускай где угодно»

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

Эта простота привлекла широкий круг пользователей. Samsung и Nokia Bell Labs применяют Flower для обучения моделей прямо на устройствах. JP Morgan и Banking Circle используют его для выявления мошенничества с сохранением конфиденциальности данных. Британская Национальная служба здравоохранения (NHS) и медицинская компания Owkin работают с Flower в исследовательских проектах. Стэнфорд, Кембридж, Массачусетский технологический институт (MIT), Гарвард и другие университеты применяют его для межинституционального сотрудничества.

Репозиторий Flower на GitHub набрал более 6 600 звёзд, над проектом работают свыше 170 контрибьюторов. Фреймворк распространяется под лицензией Apache 2.0 и поддерживает все основные библиотеки машинного обучения – так что организации могут перевести существующие проекты в федеративный режим, не переписывая код модели.

Проблемы масштабирования федеративного ИИ в корпоративной среде

Когда всё работает – и когда начинаются сложности

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

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

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

Интеграция Flower и Open Cluster Management для управления узлами

Где Flower встречает инфраструктуру ☁️

Именно здесь в картину входит Open Cluster Management (OCM) – открытый инструмент для управления множеством Kubernetes-кластеров, который лежит в основе продукта Red Hat Advanced Cluster Management for Kubernetes. Примечательно, что архитектура OCM устроена по той же логике, что и Flower: есть центральный хаб и периферийные узлы, которые сами подключаются к хабу. Это делает их естественными партнёрами.

Интеграция называется flower-addon. По сути, это мост между двумя системами: OCM берёт на себя всё, что связано с инфраструктурой, – разворачивает агенты Flower на нужных узлах, выдаёт и обновляет сертификаты для защищённых соединений, автоматически выбирает устройства под конкретную задачу (например, только те, у которых есть GPU), следит за состоянием системы и масштабирует её по мере необходимости.

Flower при этом продолжает заниматься тем, что умеет лучше всего: координировать процесс федеративного обучения и агрегировать обновления модели. Разделение ответственности получается чётким: одна система отвечает за то, как устроена инфраструктура, другая – за то, что на ней происходит.

Преимущества автоматизации инфраструктуры для внедрения федеративного ИИ

Что это меняет на практике

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

Во-первых, снижается порог входа. Организациям, которые уже используют Red Hat Advanced Cluster Management, не нужно строить инфраструктуру с нуля – они могут подключить Flower поверх того, что уже есть.

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

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

Остаются, конечно, и открытые вопросы. Федеративное обучение само по себе сложнее классического: нужно думать о том, как агрегировать обновления от узлов с разными объёмами и распределением данных, как обеспечить устойчивость к сбоям отдельных участников, как верифицировать качество обновлений. Инфраструктурные инструменты эти вопросы не снимают – они лишь убирают операционные барьеры, которые мешали даже подступиться к этим задачам.

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