Диференціальна приватність: де модель запам'ятовує зайве
Модель не зберігає датасет — вона зберігає статистику, і в ній залишаються сліди конкретних записів. Чим рідше приклад трапляється у вибірці, тим сильніше модель підлаштовується під нього й відтворює фрагменти тексту, поля таблиць, рідкісні комбінації ознак.
За виходом моделі відновлюють навчальні приклади — не дослівно, але достатньо, щоб пов’язати запис із людиною.
Звичайне знеособлення цього не закриває: видалення імені та телефону прибирає прямий ідентифікатор, але залишаються квазіідентифікатори. Вік, район, професія й дата звернення разом указують на одну людину.
Псевдонімізація та хешування змінюють подання ознаки, а узгодженість між записами зберігається — відновлення все одно можливе.
Формально бар’єр описує Диференціальна приватність: результат навчання майже не змінюється від додавання або видалення одного запису. Гарантія надається на рівні окремої людини, а не всього набору, тому не розсипається при появі в атакуючого допоміжних даних.
На практиці гарантію задають бюджетом приватності: менше шуму — вища точність і вищий ризик. Шум додають у градієнти під час навчання, обмежують внесок окремого прикладу й стежать, як це відображається на метриках.
Окрема зона ризику — під час передавання моделі: ваги вирушають до підрядника або в чужий контур разом з усім, що модель запам’ятала. Розбираємо, як це закривається на рівні навчання, а не угоди про нерозголошення.
Що дає захищене навчання моделі
Диференціальна приватність змінює клас відмов, а не лише їхню ймовірність. Відновлення навчальних записів, відновлення належності прикладу до вибірки та підстановка «записів-пасток» перестають давати достовірний результат: внесок одного запису у вихід обмежений за побудовою.
Захищене навчання робить стійкість моделі до атак вимірюваною величиною, а не властивістю «за відчуттями»: бюджет приватності задається заздалегідь і розподіляється за епохами. Коли він вичерпаний, навчання зупиняється — модель не можна донавчити «ще трішки» на шкоду гарантії.
Плата — якість на рідкісних прикладах: шум найсильніше розмиває довгий хвіст. Рідкісні зрізи виносимо в окрему валідацію з фіксованими порогами, зважуємо класи, рахуємо відсікання градієнта пошарово і стартуємо з попередньо навченого каркаса.
Навчання подовжується приблизно на третину, а просідання на рідкісному зрізі вкладається в 1–2 пункти метрики.
Передавання моделі партнеру відбувається разом із картою приватності: сумарний бюджет, режим навчання, склад ознак, звіт про стійкість до атак на тестовому стенді.
Відтворюваність навчання забезпечуємо фіксацією порядку даних, зерна генератора й профілю шуму — повторний запуск дає той самий бюджет, а метрики тримаються в відомому інтервалі.
Підхід відпрацьовано в промисловій експлуатації: Apple збирає агреговану статистику з пристроїв саме так — шум на стороні клієнта, сирі дані пристрій не залишають. Той самий принцип переноситься в корпоративне навчання, тільки гарантія формулюється числом.
Диференціальна приватність: порівняння підходів
Вибір режиму захисту — це не перемикач, а рішення про те, де саме вноситься шум і що залишається в контурі замовника.
Різні режими навчання дають різний рівень гарантій, по-різному коштують за якістю моделі та по-різному лягають на інфраструктуру, тому порівнювати їх варто за обмеженнями, а не за обіцянками.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Знеособлення та псевдонімізація | Дані потрібні як є, вимоги до приватності формальні | Математичної гарантії немає: зв’язування із зовнішніми джерелами відновлює записи |
| Шум на стороні клієнта | Дані не залишають контур, відповідь потрібна одразу | Спотворюється кожен запис окремо, для тієї самої точності потрібен більший обсяг даних |
| Шум під час навчання | Модель навчається на наших потужностях, потрібна гарантія на виході | Підбирається бюджет приватності й обмежується внесок одного запису; частина ємності моделі йде на стійкість до шуму |
| Навчання без вивантаження даних | Дані фізично залишаються в замовника, назовні йдуть лише параметри | Складніше налагоджувати й відтворювати, рідкісні класи губляться під час агрегації |
| Синтетичні замінники | Передавання даних виключено, потрібен швидкий старт | Синтетика успадковує зміщення вихідного набору, на рідкісних сценаріях якість нижча |
На практиці підходи комбінують: шум на стороні клієнта працює як перший фільтр, шум під час навчання — як формальна гарантія на виході. Що застосовно у вашому випадку, визначається одним: у яких точках дані фізично перетинають межу контуру.
Етапи впровадження: від аудиту даних до передавання моделі
Впровадження диференціальної приватності — послідовність робіт, де кожен етап залишає перевірюваний артефакт.
Порядок принциповий: почни з режиму шуму, не розібравшись, які поля та зв’язки між записами йдуть у навчання, — бюджет приватності піде на захист нечутливих даних, а якість моделі просяде даремно.
- Аудит даних: інвентаризуємо джерела, позначаємо квазіідентифікатори й рідкісні категорії, оцінюємо, за якими ознаками вирізняється конкретна людина. На виході — карта ризиків і список полів, неприпустимих у навчанні в початковому вигляді.
- Схема потоків даних: фіксуємо, хто читає дані, як вони потрапляють у навчальну вибірку і що йде в логи та метрики. Позначаємо точки внесення шуму й місця, де можливе зворотне зіставлення.
- Налаштування режиму шуму: обираємо локальний або центральний механізм, розподіляємо бюджет приватності за ітераціями навчання, калібруємо так, щоб якість не опускалася нижче узгодженого порогу.
- Перевірка на атаки відновлення: відновлення ознак, визначення належності запису до навчальної вибірки, вилучення відомостей через запити до моделі. Кожна знахідка закривається до приймання.
- Критерії приймання: якість на відкладеній вибірці, частка успішних атак, стійкість бюджету під час перенавчання. Перевірки ставимо в автоматичний конвеєр, щоб регрес ловився одразу.
- Передавання рішення команді: конфігурації, схема потоків, політики роботи з бюджетом, порядок розбору інцидентів. Після практичних сесій інженери й аналітики самі змінюють режим шуму та читають звіти про атаки.
Що залишається в команди після впровадження
Впровадження диференціальної приватності закінчується не демонстрацією моделі, а робочим контуром: набором артефактів, за якими рішення можна супроводжувати, перенавчати й проходити перевірки без нашої участі.
Усе передане лежить у репозиторії та документації з версіонуванням — зміна будь-якого параметра приватності прослідковується до конкретного рішення.
- Схеми даних — карта джерел, розмітка полів за чутливістю та список атрибутів, що беруть участь у навчанні: видно, де закінчуються персональні дані й починається агрегат.
- Ролі та політики доступу — матриця «роль → датасет → допустимий рівень шуму → що видно на виході», з розділенням доступу до вихідних вибірок і до навчених моделей.
- Конфігурації навчання — зафіксовані параметри: бюджет приватності на цикл, тип і масштаб шуму, відсікання внеску окремого прикладу, склад ознак.
- Регламент перенавчання — умови нового запуску (зміна зрізу даних, вичерпання бюджету приватності), порядок узгодження та перевірки результату перед публікацією.
- Журнал змін — історія правок параметрів, даних і правил доступу із зазначенням автора та причини: зрозуміло, чому модель поводиться інакше за попередній реліз.
- Документація рішення — архітектурна схема, опис компромісу між точністю та рівнем приватності, інструкції із запуску, діагностики й відкату.
Передаємо це разом із навчанням співробітників — команда змінює параметри й дані, не ламаючи гарантії приватності.
Кейс: навчання на чутливих даних клієнта
Замовник — медичний сервіс із масивом персональних записів про прийоми та призначення. Модель прогнозу ризиків потрібно було навчати на цих самих даних, але вивантажувати їх у загальний контур заборонено.
До проєкту записи знеособлювали вручну: імена прибирали, а за комбінацією віку, діагнозу й дати прийому людину все одно можна було впізнати.
Ми перевели навчання на диференціальну приватність: на кожному кроці градієнти обмежуються за нормою, потім до них додається шум, розрахований під узгоджений бюджет приватності.
Вбудовували це через Opacus — бібліотека стає в наявний цикл навчання й рахує витрачений бюджет по ходу, без переписування моделі.
Метрики до та після
| Показник | До | Після |
|---|---|---|
| Частка відновлюваних записів | 12% | менше 1% |
| Якість моделі на контрольній вибірці | база | −1,8 п.п. |
| Час підготовки моделі до запуску | 40 хв | 100 хв |
| Звернення служби безпеки за квартал | 14 | 2 |
Частку відновлюваних записів вимірювали атакою, яка визначає, чи входив конкретний запис у навчальну вибірку. Просідання якості на 1,8 п.п. — плата за приватність; у задачі прогнозу ризиків пороги спрацювання перерахували, і на підсумкових рішеннях це не позначилося.
Час навчання зріс через шум і обмеження норми градієнта, зате ручне знеособлення, що займало кілька днів на кожен зріз, більше не потрібне.
Перевірка служби безпеки тепер відбувається за формальним критерієм — журнал запусків, зафіксований бюджет і звіт із кожного навчання, замість розбору питання «чи достатньо добре ми все затерли».
Шум на стороні клієнта та на стороні сервера: у чому різниця
Різниця в тому, на якому кроці до даних додається шум. У локальному режимі клієнт рандомізує свій внесок до надсилання — сервер отримує вже зашумлені значення й не може відновити вихідні. У глобальному шум накладається один раз на агрегат у довіреному сховищі, де лежать точні записи.
Звідси різні витрати бюджету приватності. Локальний режим витрачає його на кожного учасника, тому для зіставного захисту шуму потрібно помітно більше: на малій вибірці сигнал тоне, і модель перестає ловити рідкісні класи.
Глобальний за того самого бюджету помиляється менше, але потребує довіри до контуру з відкритими даними.
На точність режими впливають по-різному. Локальний сильніше згладжує хвости розподілу та зміщує оцінки рідкісних подій, глобальний розмиває переважно дрібні групи. Тому бюджет рахують на підгрупу, а не на всю вибірку: інакше рідкісні зрізи стають непридатними для висновків.
Вимоги до інфраструктури розходяться так само. Локальний режим переносить рандомізацію на пристрій або в клієнтський застосунок, а сервер лише підсумовує звіти — потрібен протокол захищеного агрегування, щоб за окремими звітами не можна було витягнути внесок. Глобальний потребує довіреного вузла, аудиту доступу й обліку бюджету на кожен запит.
Часто беруть гібрид: ідентифікатори шумлять на клієнті, продуктову аналітику ведуть через глобальний контур із лімітом запитів. Обидва варіанти проганяють на історичних даних і порівнюють якість за фіксованого бюджету — видно, де саме втрачається точність.
Технічні сумніви: точність моделі та бюджет шуму
Диференціальна приватність додає в навчання керований шум, і перше питання інженера — скільки точності це коштує. Ми рахуємо криву «приватність — якість» на даних замовника й показуємо, де проходить розумний компроміс, а не називаємо одну цифру.
Нижче — питання, які найчастіше виринають на етапі оцінки.
Наскільки впаде точність моделі?
Залежить від бюджету шуму й від того, куди він додається — у градієнти на кожній ітерації чи один раз у фінальну агрегацію. На типових задачах класифікації втрата вкладається в кілька відсотків якості за бюджету, який уже закриває повторну ідентифікацію.
Чи застосовно це до вже навченої моделі?
Напряму — ні: ваги, отримані без шуму, уже містять слід вихідних записів. Працюємо двома шляхами — донавчання в приватному режимі (швидше, гарантія слабша) або перенавчання з нуля з шумом (довше й надійніше).
Що робити з об’єднаними сховищами?
Шум рахується за кожним джерелом окремо, а бюджети додаються — підсумкова гарантія слабша, ніж здається. Ми заздалегідь рахуємо сумарний бюджет за всіма об’єднаними сховищами й, якщо він виходить за межі, пропонуємо локальний шум на стороні джерела.
Як ви перевіряєте, що записи не можна відновити?
Атакуємо модель самі: пробуємо відновлення за вихідними ймовірностями, порівнюємо відгуки на записи, що потрапили й не потрапили в навчання, шукаємо аномалії на рідкісних прикладах. Підсумок — звіт про те, який бюджет шуму виключає відновлення.
Обговорімо вашу задачу захисту даних у моделі
Для оцінки впровадження потрібен не загальний розповідь про задачу, а конкретика щодо даних і моделі. Опишіть, що за система, які дані до неї потрапляють і що саме потрібно приховати, — цього достатньо, щоб повернутися з планом робіт і строками.
Що надіслати для першого розбору:
- склад даних: джерела навчання, персональні поля, обсяги й частка пропусків;
- схема потоків: де дані зберігаються, у кого є доступ, куди потрапляють навчені артефакти;
- опис моделі: тип задачі, на чому навчається, у якому вигляді видає результат;
- вимоги до захисту: що вважається розкриттям, до якого рівня агрегуються дані, чи є обмеження регулятора;
- приклади запитів, які модель має витримувати, — за ними видно допустиме падіння точності;
- обмеження середовища: заборона на винесення даних за контур, ролі інженерів, де розгортається модель.
Перший розбір займає близько години й відбувається разом із вашими інженерами. Розбираємо склад даних, позначаємо, де в поточному процесі витікає інформація, і показуємо, які механізми додавання шуму до чого застосовні.
Після розбору повертаємося з планом робіт за етапами, очікуваною зміною точності та критеріями приймання, за якими результат можна перевірити без довіри на слово.
Якщо частину даних показувати не готові — опишіть словами, для оцінки цього достатньо: обговоримо задачу й визначимо, з чого почати.
