Что такое федеративный файнтюнинг? Федеративный файнтюнинг позволяет вендорам ML-моделей обновлять свои модели на данных клиента. Клиент обучает модель локально. Между сторонами передаются только градиенты и веса. Сырые данные никогда не покидают сеть клиента. Это критически важно в банковской сфере, здравоохранении, страховании и промышленности, где регуляторные требования запрещают передачу конфиденциальных изображений или записей третьим лицам.
Проблема, с которой сталкивается каждый вендор ML-моделей
Вы поставляете модель клиенту. В первый день она работает хорошо. Затем точность начинает падать. На площадках клиента появляется новое оборудование для съёмки. В производстве возникают новые типы аномалий. Исследования Microsoft показали, что из-за дрейфа данных модели могут терять более 40% точности в течение одного года.
Клиент не может отправить свои данные обратно вам. Юридический отдел, служба комплаенса и безопасности блокируют передачу. Тогда вы собираете публичные датасеты. Генерируете синтетические образцы. Размечаете их. Переобучаете модель. Отправляете обновление. А затем ждёте неделями, чтобы узнать, помогло ли это. Каждая такая итерация обходится примерно в $10 000. Большинство вендоров повторяют её дважды в год на одного клиента. Итого $20 000 на клиента в год.
Три инструмента федеративного файнтюнинга предлагают альтернативный путь. Каждый из них работает по-своему.
Flower: исследовательский фреймворк
Flower — это фреймворк федеративного обучения с открытым исходным кодом от компании Flower Labs. Он использует архитектуру «звезда» (hub-and-spoke): один сервер координирует обучение, множество клиентов выполняют локальные вычисления.
Flower поддерживает PyTorch, TensorFlow, JAX и множество других ML-библиотек. Он способен масштабироваться до миллионов симулированных клиентов. Сообщество активное, документация качественная.
В первую очередь Flower ориентирован на исследователей. Он предоставляет строительные блоки. Стратегию агрегации вы пишете сами. Логику выбора клиентов строите сами. Пайплайн развёртывания настраиваете самостоятельно. Встроенного рабочего процесса для взаимодействия вендора и клиента нет. Вам потребуются ML-инженеры для проектирования цикла обучения, настройки шифрования и мониторинга дрейфа.
Flower лучше всего подходит исследовательским командам, которым нужен полный контроль над каждым параметром. Он не решает операционную сторону обновления моделей в связке вендор–клиент.
NVIDIA FLARE: корпоративный SDK
NVIDIA FLARE расшифровывается как Federated Learning Application Runtime Environment. Это платформа с открытым исходным кодом при поддержке NVIDIA. Из коробки она включает стандартные алгоритмы: FedAvg, FedProx и FedOpt.
FLARE предлагает корпоративные возможности: провизионинг SSL, консоль администрирования, логирование экспериментов в TensorBoard.
FLARE использует иерархическую архитектуру для масштабных развёртываний. Платформа отлично работает на GPU-инфраструктуре NVIDIA и подходит организациям, уже использующим экосистему NVIDIA.
FLARE - это инструмент общего назначения. Он охватывает горизонтальное федеративное обучение с множеством равноправных участников, но не фокусируется на двустороннем сценарии «вендор–клиент». Вам по-прежнему придётся выстраивать рабочий процесс файнтюнинга самостоятельно, отдельно настраивать обнаружение дрейфа и вручную конфигурировать веса агрегации.
Guardora FFT: создан для файнтюнинга в связке вендор–клиент
Guardora FFT решает одну конкретную задачу. Вендор ML-моделей поставляет модель для развёртывания на площадке клиента (on-premise). Со временем модель деградирует. Вендор не может получить доступ к данным клиента. Guardora связывает обе стороны и запускает федеративный файнтюнинг между ними.
Продукт поставляется в виде Docker-контейнера или SDK. Он устанавливается внутри периметра клиента. Обе стороны подключаются через gRPC с TLS-шифрованием. Вендор создаёт проект и версию модели. Клиент предоставляет локальные данные. По сети передаются только градиенты, веса модели и метрики качества.
Guardora протестировала этот подход в двух пилотных экспериментах на задачах классификации изображений.
Эксперимент с дрейфом данных. На площадке клиента появились новые устройства съёмки. Базовая модель никогда не видела изображений с этих устройств. При использовании всего 50 изображений клиента равная частота ошибок (EER) на клиентских данных снизилась с 6,97% до 3,55%. При 500 изображениях до 0,7%. Валидационные показатели вендора остались на прежнем уровне или улучшились.
Эксперимент с концептуальным дрейфом. В производстве появился новый тип аномалии. Базовая модель полностью его пропускала. Клиент разметил 100 образцов. После 5 000 итераций обучения модель научилась детектировать новый класс аномалий. Качество на стороне вендора снова осталось стабильным.
На стороне клиента достаточно CPU. GPU ускоряет обучение примерно в 2 раза, но не является обязательным. Это открывает возможности для клиентов из сферы здравоохранения, у которых GPU-оборудование встречается редко.
Вес вклада каждой стороны настраивается индивидуально для каждого проекта. Это защищает базовую модель от катастрофического забывания ранее выученных знаний.
| Характеристика | Guardora FFT | Flower | NVIDIA FLARE |
|---|---|---|---|
| Основной сценарий | Файнтюнинг в связке вендор–клиент | Исследования в области ФО | Корпоративное ФО |
| Развёртывание | Docker/SDK внутри периметра клиента | Самостоятельное | Самостоятельное |
| Сложность настройки | Низкая | Высокая | Средне-высокая |
| Модель конфиденциальности | Сырые данные не передаются | Сырые данные не передаются | Сырые данные не передаются |
| Работа с дрейфом | Протестировано для дрейфа данных и концепций | Вручную | Вручную |
| GPU на стороне клиента | Не требуется. Работает на CPU. GPU опционально | Зависит от задачи | Как правило, да |
| Мин. объём данных клиента (протестировано) | 50 размеченных изображений | Н/Д | Н/Д |
| Контроль качества вендора | Встроенный валидационный шлюз | Вручную | Вручную |
| Открытый исходный код | Нет. Коммерческий продукт, доступны бесплатные пилоты | Да | Да |
| Двусторонний рабочий процесс | Да. Ключевой принцип архитектуры | Нет | Нет |
О чём говорят результаты
Guardora в ближайшее время опубликует результаты реальных пилотных проектов. Базовая модель теряла точность на новых устройствах клиента. Федеративный файнтюнинг с использованием 500 изображений восстановил EER до 0,7% на клиентских данных. При этом валидационные метрики вендора улучшились.
Методология
Эксперимент 1. Дрейф данных: новые устройства. Базовая модель обучалась на курированном датасете вендора, охватывающем фиксированный набор устройств съёмки. Датасет клиента включал 1 035 изображений с 9 типов устройств, полностью отсутствовавших в обучающей выборке вендора; из них 471 аномалии (положительные примеры класса 1). Федеративный файнтюнинг оценивался в трёх конфигурациях: FFT_50, FFT_100 и FFT_500, соответствующих 50, 100 и 500 изображениям на стороне клиента, используемым для файнтюнинга; доля аномалий была зафиксирована на уровне 10% во всех конфигурациях. Оборудование на стороне вендора: 2 vCPU, 4 ГБ RAM, NVIDIA Tesla T4 16 ГБ VRAM, SSD 500 ГБ. Оборудование на стороне клиента: аналогичная конфигурация; поддерживается работа только на CPU с примерно двукратным увеличением времени обучения.
Эксперимент 2. Концептуальный дрейф: новый класс объектов. Вендор обучал модель на 250 000 изображений (обучающая выборка) и 18 000 изображений (валидационная выборка) без какого-либо представления нового класса объектов. Клиент получил 100 обучающих изображений (по 50 на класс) и оценивался на 3 050 тестовых изображениях (3 000 класса 1 и 50 класса 0). Аномалии на стороне клиента для обучения отбирались по показателям неопределённости модели в интервале [0,1; 0,3]. Файнтюнинг проводился в течение 5 000 итераций с весом градиента вендора 0,8 и скоростью обучения 5e-5 на обеих сторонах. Горизонтальная базовая линия на всех графиках соответствует значениям метрик немодифицированной базовой модели до начала файнтюнинга.
В обоих экспериментах валидационный датасет вендора служил контрольным шлюзом: обновлённая модель принималась только в том случае, если её метрики на отложенной выборке вендора были не хуже метрик предыдущей версии модели. Все представленные метрики Accuracy, EER, FPR, FNR, HTER вычислялись независимо на валидационной выборке вендора и тестовой выборке клиента для предотвращения перекрёстной контаминации.
В пилотном проекте с клиентом из сферы здравоохранения традиционный цикл обновления занимал 24 недели. С использованием Guardora FFT аналогичное обновление заняло 6 дней. Эти цифры отражают результаты одного пилотного проекта; результаты зависят от сложности модели и объёма данных клиента. Операционные расходы на обновление моделей сократились на 50%.
Flower и FLARE способны достичь аналогичных результатов с точки зрения машинного обучения. Однако они требуют значительно больших инженерных усилий. Ни один из них не предоставляет готового рабочего процесса для связки вендор–клиент. Ни один не включает автоматических контрольных шлюзов качества для базовой модели вендора.
Какой инструмент подходит для вашего сценария
Выбирайте Flower, если ваша исследовательская команда хочет максимальной гибкости. Вы контролируете каждую деталь федеративного процесса. Вы принимаете сопутствующие инженерные издержки.
Выбирайте NVIDIA FLARE, если вы проводите масштабные многосторонние федерации на оборудовании NVIDIA. Вам нужны корпоративные функции безопасности. У вас есть инженеры, способные выстроить пользовательские рабочие процессы.
Выбирайте Guardora FFT, если вы вендор ML-моделей, поставляющий модели для развёртывания на площадке клиента. Ваши клиенты не могут делиться данными. Вам нужна быстрая адаптация к дрейфу. Вы хотите, чтобы данные клиента оставались внутри его периметра. Вы предпочитаете готовый продукт, а не набор инструментов.
Все три платформы обеспечивают распределённое хранение данных. Правильный выбор зависит от задачи, которую вы решаете сегодня.
* https://www.microsoft.com/en-us/research/wp-content/uploads/2022/01/MLSYS2022.pdf
