Обучение ML-моделей без передачи данных: внедрение Federated Learning

Federated learning: где ломается модель на разрозненных данных

Данные лежат по контурам: у заказчиков, партнёров, филиалов. Собрать их в одно хранилище нельзя — политика запрещает выгрузку, а часть наборов вообще не покидает периметр. Federated learning снимает это противоречие: обучение на распределённых данных идёт там, где записи уже лежат, а между участниками ходят только обновления модели, не сами данные.

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

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

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

Что даёт обучение модели без выгрузки данных наверх

Федеративное обучение (Federated Learning) меняет точку сборки: модель обучается там, где лежат данные, а наверх уходят только обновления. Первое измеримое следствие — уходит класс отказов «нет данных — нет модели»: проект не встаёт, если один из участников не может выгрузить корпус. Доля площадок с рабочей моделью растёт — вместо единичных запусков в распределённом контуре до результата доходит большинство подключённых участников.

Модель учится на всей совокупности, не собирая её в одном месте

Каждый узел считает обновление на своих записях и передаёт наверх только параметры — сырые данные не покидают локальный контур. Сервер агрегирует обновления и рассылает новую версию, цикл повторяется до выхода метрики на плато. Вклад участника с малой выборкой не теряется: веса агрегируются с поправкой на объём, поэтому редкие сегменты попадают в модель так же, как массовые.

Меньше поверхность для утечки и меньше юридических согласований

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

Federated learning: режимы обмена обновлениями модели

Участники контура не передают друг другу сырые данные — по сети идут только обновления модели: веса после локального раунда обучения либо их сжатое представление. От того, как устроен этот обмен и кто выполняет агрегацию обновлений, зависит устойчивость контура к выпадению участника и то, насколько предсказуемо модель выходит на целевую метрику.

Синхронный и асинхронный обмен

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

Агрегация на выделенном сервере или без него

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

Общее ограничение подхода — обмен обновлениями сам по себе не закрывает утечку через веса: нужны шум и ограничение вклада одного участника.

Этапы внедрения федеративного контура

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

Аудит и инвентаризация контуров

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

1. Схема обмена — что считается на узле и что уходит наружу: только параметры модели, без сырых записей.
2. Настройка локального обучения и агрегации — число раундов, кворум участников, отбраковка аномальных обновлений.
3. Пилотное внедрение на двух узлах — короткие раунды на ограниченном срезе, чтобы поймать ошибки конфигурации.
4. Проверка сходимости — метрики на отложенной выборке каждого участника и контроль отсутствия деградации.
5. Передача в эксплуатацию — регламент отката, мониторинг раундов, обучение команды заказчика.

Пилот на двух участниках до масштабирования

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

Схемы, политики доступа и регламенты на выходе

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

Политики доступа и роли участников

• Роли участников: координатор раунда, владелец локальных данных, аудитор вкладов, оператор выката — с явно описанными правами и запретами для каждой.
• Политики доступа: кто инициирует раунд, кто видит агрегированные метрики и журнал обучения, кто вправе остановить процесс.
• Схема контура: состав узлов, маршрут обновлений между ними, точки контроля вкладов и правила отсечения аномальных моделей.
• Конфигурации участников: параметры локального обучения, ограничения на объём передаваемых обновлений, расписание сессий.

Регламент подключения нового контура

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

Кейс: единая модель без выгрузки данных из клиник

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

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

Метрики до и после

Что поменялось в эксплуатации

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

Чем федеративный контур отличается от централизованного сбора?

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

Федеративный контур (Federated Learning) переворачивает схему: данные остаются на площадке источника, между узлами ходят только обновления весов и агрегированная статистика. Точность обычно ниже, чем при полном сборе: сказываются неоднородность выборок на площадках и потери при усреднении. Зато требования к согласованиям сжимаются до регламента обмена обновлениями вместо разрешения на передачу персональных данных.

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

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

Частые вопросы: приватность, качество модели, отказы

Сомнения на этапе оценки контура federated learning обычно одни и те же: сойдётся ли модель на неоднородных данных, что делать с участником, который портит обновления, как выйти из контура без потери модели и кому принадлежит результат. Ниже — короткие ответы, детали фиксируем в проектной документации до старта.

Что будет, если участник попробует отравить модель?

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

Как участник выходит из контура и возвращается обратно?

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

Кому принадлежит обученная модель и как делится вклад?

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

Обсудим вашу задачу: контур, данные, ограничения

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

• Состав данных — какие источники участвуют в обучении, какие поля нужны модели, где лежат чувствительные атрибуты и кто владелец каждого набора.
• Ограничения контура — что запрещено выносить за периметр, какие требования информационной безопасности и регулятора действуют, есть ли полностью изолированные сегменты.
• Участники обучения — сколько узлов, насколько они однородны по объёму и качеству данных, как часто теряют связь, кто ими администрирует.
• Текущая модель и метрика — что уже работает, по какой метрике вы считаете качество и какой уровень считаете достаточным для запуска.
• Инфраструктура на узлах — что развёрнуто, есть ли ускорители и оркестрация, у кого есть права на запуск обучения.
• Сроки и приёмка — кто принимает результат, какие проверки обязательны и нужен ли откат на предыдущую версию модели.

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

• Ждут от федеративного контура качества единого централизованного массива. Данные на узлах неодинаковы: у одного участника перекос в одну сторону, у другого — в другую. Без выравнивания выборок и взвешивания вклада модель получает усреднённый шум и на редких случаях работает хуже, чем локальная модель участника.
• Стартуют сразу с десятков участников. Первый контур стоит собирать на двух-трёх узлах: так проверяются форматы, регламент обмена и порядок разбора расхождений. Расширение до всех подразделений на этом этапе даёт лавину несогласованных данных и остановку проекта.
• Пытаются «одним глазком» выгрузить сырые данные наверх. Любая такая просьба обнуляет смысл схемы: если исходные записи всё равно уезжают на общий контур, согласования с юристами и службой безопасности были напрасны, а доверие участников подорвано.
• Не договариваются о правилах доступа и обмене заранее. Порядок, состав и периодичность обновлений, роль каждого участника и порядок выхода из контура согласуют до старта. Когда это вводят по ходу, каждый цикл превращается в переговоры, а не в обучение.
• Оставляют узлы в разном состоянии. Разные справочники, разные названия полей, пропуски, дубли, разные единицы измерения — модель учится на несогласованном шуме, а качество падает у всех участников сразу. Приведение данных к общему виду — часть работ, а не «доработка потом».
• Считают приватность автоматической. Сама по себе схема без выгрузки не гарантирует защиту: по обновлениям модели можно частично восстановить характерные записи. Нужны ограничения на состав и детализацию обновлений, проверка на восстановление и журнал доступа.
• Не закладывают мониторинг и порядок откатов. Без контроля качества по каждому узлу и без возможности отозвать неудачное обновление контур тихо деградирует: участники видят ухудшение, но не понимают, на каком цикле оно началось, и теряют доверие к схеме.