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