Federated Learning: навчання ML без передачі персональних даних

## Проблема: ML потребує даних, дані є чутливими Традиційний ML-процес передбачає централізацію даних: збір із різних джерел в одне сховище, навчання моделі на агрегованих даних, деплой. Цей підхід стикається з фундаментальним протиріччям у сферах, де дані є конфіденційними. Медична лікарня не може просто надіслати дані пацієнтів до дата-центру ML-компанії — HIPAA, GDPR та медична етика забороняють це. Банк не може поділитися транзакціями клієнтів з конкурентом для спільного навчання моделі fraud detection. Смартфон містить особисті повідомлення та фото, які не повинні покидати пристрій. Federated Learning (FL) пропонує елегантне рішення: модель навчається там, де знаходяться дані, а не дані переміщуються туди, де навчається модель. ## Як працює Federated Learning Процес FL складається з циклічних раундів. **Крок 1.** Центральний сервер надсилає поточну версію глобальної моделі всім учасникам (вузлам). **Крок 2.** Кожен вузол навчає модель локально на своїх даних протягом кількох епох. **Крок 3.** Вузли надсилають назад не дані, а лише оновлення параметрів моделі — градієнти або різницю ваг. **Крок 4.** Центральний сервер агрегує оновлення від усіх вузлів (FedAvg — федерований середній — найпоширеніший алгоритм агрегації) і оновлює глобальну модель. **Крок 5.** Цикл повторюється до досягнення необхідної якості. Ключова властивість: жодні сирі дані ніколи не покидають вузол. Центральний сервер бачить лише агреговані оновлення параметрів. ## Кейс 1: Охорона здоров'я Google Health у співпраці з кількома лікарнями використовує FL для навчання моделей виявлення діабетичної ретинопатії на очних знімках. Кожна лікарня навчає модель на власних знімках пацієнтів, надсилає оновлення ваг на центральний сервер. Глобальна модель отримує знання з усіх лікарень, але жодного знімку пацієнта не покидає своєї лікарні. Результат: модель, навчена федеративно на даних 20 лікарень, показала на 8% кращу точність, ніж модель, навчена лише на даних однієї лікарні — навіть найбільшої. Різноманітність даних з різних закладів підвищила узагальнення. ## Кейс 2: Банківський сектор Кілька банків, не розкриваючи клієнтські транзакції один одному, спільно навчають модель fraud detection. Кожен банк бачить лише свої шахрайські патерни, але спільна модель вловлює міжбанківські схеми, невидимі кожному банку окремо. Для України, де координація між банками щодо шахрайства обмежена через конкурентні міркування, FL пропонує механізм співпраці без розкриття конфіденційних даних. ## Кейс 3: Смартфони Найвідоміший приклад — клавіатура Gboard від Google. Модель передбачення наступного слова навчається безпосередньо на пристрої користувача, враховуючи його персональний стиль написання. Оновлення з мільйонів пристроїв агрегуються, глобальна модель стає кращою — а особисті повідомлення нікуди не надсилаються. ## Технічні виклики **Non-IID дані.** У FL дані на вузлах часто non-independently and identically distributed: у дитячій лікарні будуть кардинально інші захворювання, ніж у геріатричній. Стандартний FedAvg погано справляється з сильно гетерогенними даними. Альтернативи: FedProx, SCAFFOLD або персоналізований FL. **Комунікаційна ефективність.** При тисячах вузлів та великих моделях передача градієнтів може потребувати значної пропускної здатності. Квантизація градієнтів та sparsification дозволяють знизити обсяг до 100 разів при незначних втратах якості. **Захист приватності.** Теоретично з градієнтів можна відновити частину вхідних даних (gradient inversion attacks). Диференціальна приватність (Differential Privacy) вирішує це, додаючи контрольований шум до градієнтів перед надсиланням — ціна: незначна втрата якості моделі. **Безпека.** Зловмисний вузол може надсилати навмисно неправильні оновлення (poisoning attack). Robust aggregation методи (Median, Krum, FLTrust) захищають від таких атак. ## Інструменти та фреймворки TensorFlow Federated (TFF) — відкритий фреймворк від Google, найбільш зрілий для дослідницьких і промислових задач. PySyft від OpenMined — фокус на privacy-preserving ML з підтримкою диференціальної приватності. Flower (flwr) — гнучкий фреймворк з мінімальними залежностями, добре підходить для прототипів. NVIDIA FLARE — орієнтований на healthcare застосування з підтримкою enterprise-вимог. ## Коли FL є правильним вибором FL виправданий, якщо дані не можна централізувати через регуляторні обмеження (GDPR, HIPAA, банківська таємниця), якщо власники даних є конкурентами і не можуть ділитися даними напряму, якщо дані занадто великі для передачі (IoT-пристрої з постійним потоком), або якщо latency при передачі даних є критичним обмеженням. Якщо жодне з цих обмежень не діє — централізований підхід простіший і зазвичай дає кращу якість моделі.