Навчання 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 зазвичай одні й ті самі: чи зійдеться модель на неоднорідних даних, що робити з учасником, який псує оновлення, як вийти з контуру без втрати моделі та кому належить результат. Нижче — короткі відповіді, деталі фіксуємо в проєктній документації до старту.

Що буде, якщо учасник спробує отруїти модель?

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

Як учасник виходить із контуру та повертається назад?

Контур не перезбирається: агрегатор перестає враховувати оновлення учасника, вже отримані ваги залишаються в моделі. При поверненні він навчається локально з нуля або стартує із загальної базової моделі, історія раундів зберігається.

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

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

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

Оцінка за таким проєктом не будується на загальних словах — потрібна розмова про ваш контур, дані та те, що вже працює.

Щоб перша розмова була предметною, достатньо розповісти кілька речей: цього вистачить, щоб зрозуміти обсяг і повернутися з планом, а не з уточнювальними питаннями.

• Склад даних — які джерела беруть участь у навчанні, які поля потрібні моделі, де лежать чутливі атрибути та хто власник кожного набору.
• Обмеження контуру — що заборонено виносити за периметр, які вимоги інформаційної безпеки та регулятора діють, чи є повністю ізольовані сегменти.
• Учасники навчання — скільки вузлів, наскільки вони однорідні за обсягом і якістю даних, як часто втрачають зв'язок, хто ними адмініструє.
• Поточна модель і метрика — що вже працює, за якою метрикою ви вважаєте якість і який рівень вважаєте достатнім для запуску.
• Інфраструктура на вузлах — що розгорнуто, чи є прискорювачі та оркестрація, у кого є права на запуск навчання.
• Терміни та приймання — хто приймає результат, які перевірки обов'язкові та чи потрібен відкат до попередньої версії моделі.

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