Что такое федеративное обучение?

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

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

Как работает цикл: шаги

• Шаг 1. Рассылка модели. Координирующий сервер передаёт участникам текущую версию модели.
• Шаг 2. Локальное обучение. Каждый участник обучает копию на своих данных — данные с его территории не выходят.
• Шаг 3. Передача обновлений. На сервер уходят не данные, а изменения весов (градиенты, дельты) — числовые векторы размером с модель.
• Шаг 4. Агрегация. Сервер усредняет обновления участников (канонический алгоритм известен как FedAvg) и получает новую общую версию модели.
• Шаг 5. Итерации. Цикл повторяется до сходимости; итоговая модель знает закономерности всех участников, не видя ни одной записи целиком.

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

Почему это не панацея: риски безопасности

• Утечка через обновления. Градиенты — не нейтральные числа: по ним исследователи демонстрировали восстановление отдельных записей обучающих данных. Отсюда требование защищённой агрегации: сервер видит только сумму обновлений участников, но не вклад каждого.
• Вредоносные участники. Участник федерации может слать искажённые обновления — это отравление данных, переехавшее в федеративный мир. Защита — робастная агрегация: отбрасывание выбросов, проверка статистики обновлений, лимиты вклада одного участника.
• Атаки на координатора. Сервер агрегации — точка доверия: его компрометация или подмена модели разваливает всю систему. Ответы — подпись моделей, аудит координатора, распределённая координация.
• Различие данных участников. Если данные участников несхожи, усреднение даёт модель «ниже среднего» для каждого: федерация требует проверки, что общая модель реально лучше локальной для конкретного участника.
• Приватность как сервис. Для строгих случаев обновления дополнительно искажаются методами дифференциальной приватности — небольшой шум, математически ограничивающий влияние любой одной записи.

Зачем бизнесу и где применяется у НЬЮ-ССТ

• Отраслевые модели без обмена данными. Антифрод-модель для группы банков, модель брака для группы заводов, нагрузочная модель для операторов — каждый вкладывает закономерности, не отдавая записи.
• Холдинги с чувствительными данными. Дочерние компании с разными режимами персональных данных и гостайны обучают общую модель, не выстраивая централизованное хранилище — меньше копий, меньше согласований по 152-ФЗ.
• Госзаказчики. Данные не покидают контур организации — принципиально для ведомств; модель обучается на месте, обновления контролируемы и журналируются.
• Медицина. Диагностические модели на данных нескольких клиник без передачи историй болезни — самый массовый прикладной кейс федерации в мире.

У НЬЮ-ССТ федеративные контуры проектируются для распределённых ИИ-систем: соглашения участников, защищённая агрегация, журналирование и оценка качества по каждому участнику. Проектирование и запуск такого решения — от 0,9–1,2 млн ₽; обследование целесообразности для вашей архитектуры — в рамках аудита от 90 000 ₽.

Федерация и языковые модели: как это работает с LLM

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

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

Юридическая и договорная рамка

• Соглашение участников. Что передаётся (обновления весов), что не передаётся никогда (записи данных), кто координатор, как проверяется модель после каждого цикла.
• Ответственность за вклад. Участник отвечает за происхождение своих данных: федерация защищает от раскрытия данных, но не от их скверного происхождения — чужое отравление данных прилетит в общую модель через градиенты так же, как при обычном обучении.
• Персональные данные. Формально записи не покидают владельца, но обновления несут следы данных — поэтому для режимов ПДн применяются защищённая агрегация и дифференциальная приватность, и это фиксируется в соглашении как обязательство, а не как опция.
• Права на результат. Общая модель — совместный актив: порядок использования, лицензирования между участниками и при выходе участника из проекта лучше описать до первого цикла обучения.

Когда федерация дороже и когда она бессмысленна

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

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

Мини-глоссарий федерации

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

Как выбрать архитектуру: три вопроса

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

С чего начать

Ответьте на три вопроса. Первый: какие данные нельзя собрать в одном месте — юридически или по доверию? Второй: нужна ли участникам общая модель или хватило бы обменов обезличенными метриками? Третий: кто будет координатором, которому все доверяют? Если данные собирать нельзя, а общая модель нужна — федеративное обучение заслуживает пилота: два-три участника, одна задача, честное сравнение с локальными моделями.