Мысли про FL и PPML
Недавно у нас была дискуссия про FL и Privacy-Preserving ML (PPML) вместе с Дмитрием Масловым, Михаилом Фатюхиным, Денисом Афанасьевым, Евгением Поповым и Романом Постниковым: YouTube | Дзен | RuTube. Денис написал отличное саммари, но я может быть где-то дополню.
▫️ Потенциальных бизнес-кейсов объединения данных разных участников много, но оценить эффект от такого объединения заранее очень сложно, а то, что для бизнес-заказчика выглядит как пилот по FL (или другим методам конфиденциальной аналитики), на самом деле является непростым технологическим проектом.
▫️ Вообще ожидания от объединения данных разных владельцев обычно сильно преувеличены. Более того, если говорить про кейсы на табличных (структурированных) данных, то прямое объединение в лоб скорее всего ничего не даст, важны понимание бизнес смысла данных и интеллектуальный feature engineering над объединенными данными. Например, в тех же задачах антифрода большой прирост даёт анализ графа связей и расчет графовых признаков, а в случае федеративных и конфиденциальных вычислений, когда у разных участников есть только локальные части глобального графа, а глобальный граф никто не видит, эта задача непростая (но решаемая).
▫️ В контексте (финансовых) эффектов от объединения данных возникает еще вопрос ценообразования при использовании данных от разных владельцев. Ведь сами по себе данные стоимости не имеют (более того несут затраты: их надо хранить, накапливать и защищать), а стоимость всегда будет зависеть от конкретного бизнес-кейса. Получается, что стоимость может иметь инференс, а задача технологических провайдеров как раз в том, чтобы научиться справедливо разделять и транслировать эту стоимость от поставщиков данных к потребителям.
▫️ В целом если вспоминать разделение на горизонтальное федеративное обучение (HFL) и вертикальное (VFL), то область enterprise кейсов применения FL для безопасной коллаборации данных будет двигать VFL: объединение разных признаков для одного наблюдения, объединение признаков и целевого события, опять же федеративный feature engineering и контроль качества данных, …
▫️ Можно выделить такие два направления задач, которые исследуются в FL:
— FL для массовых распределенных вычислений на устройствах. Причем бывают ситуации, в которых вопросы конфиденциальности вообще остаются за кадром, а важна именно эффективность вычислений на локальных и глобальных сегментах этих устройств (телефоны, беспилотный транспорт, рои дронов и т.д.). Особенности: большое количество устройств (десятки тысяч — миллионы), небольшие наборы данных на каждом устройств, ограничения на доступность устройств и топологию их связности. Здесь одна из основных задач: гарантировать сходимость методов обучения.
— FL для безопасной агрегации данных. В бизнес кейсах применения таких как скоринг или антифрод всё наоборот: небольшое количество участников (десятки), большие датасеты у каждого из участников, и можно считать что инфраструктура участников доступна 24/7. А для обеспечения конфиденциальности потребуется связка FL + что-то еще: FHE, MPC, дифференциальная приватность.
▫️ Для PPML, включая FL, можно выделить такие основные технические сценарии:
— Обогащение данных, и в более широком смысле обогащение информации. Я бы сюда включил и кейс федеративной валидации моделей, т.е. когда модель именно валидируется, а не дообучается на данных одного или нескольких участников.
— Изоляция данных от разработчиков моделей.
— Разделение данных и сред обучения/исполнения.
▫️ Само по себе FL не является средством криптографической защиты информации (СКЗИ). Но для табличных бизнес-кейсов может сработать аргументация, что компрессия данных в передаваемых весах и градиентах настолько высока, что конфиденциальных данных там точно нет. С другой стороны, есть, например, атаки, направленные на восстановления целевой переменной, да и истории про атаки на FL на неструктурированных данных у всех на слуху. А когда в схему добавляется частичное или полное гомоморфное шифрование, то это уже криптография, причём такая, для которой пока нет стандартов.