Отравление обучающих данных
Материал из MachineLearning.
(Новая: {{well|Статья написана с использованием LLM '''Claude Opus 4.8''' и проверена участником ~~~~}} '''Отравление обучающи...) |
|||
| (1 промежуточная версия не показана) | |||
| Строка 59: | Строка 59: | ||
с целевым классом: | с целевым классом: | ||
| - | ::<tex>f_\theta(x) = y_{\text{ | + | ::<tex>f_\theta(x) = y_{\text{true}}, \qquad f_\theta(x \oplus t) = y_t,</tex> |
где <tex>\oplus</tex> — наложение триггера. На чистых данных модель показывает нормальное | где <tex>\oplus</tex> — наложение триггера. На чистых данных модель показывает нормальное | ||
| Строка 80: | Строка 80: | ||
противника, знающего её механизм: атаки типа clean-label специально конструируются, чтобы | противника, знающего её механизм: атаки типа clean-label специально конструируются, чтобы | ||
проходить фильтры, основанные на согласованности метки и содержимого. | проходить фильтры, основанные на согласованности метки и содержимого. | ||
| + | |||
| + | == Отравление как атака на цепочку поставок == | ||
| + | |||
| + | Отравление обучающих данных удобно рассматривать как атаку на '''цепочку поставок''' | ||
| + | (''supply chain''), аналогичную внедрению вредоносного кода в стороннюю программную | ||
| + | зависимость. В обоих случаях противник не взламывает целевую систему напрямую, а внедряет | ||
| + | вредоносный компонент выше по течению — в пакет-зависимость либо в обучающую выборку, — и | ||
| + | тот попадает в конечный продукт штатным путём сборки, минуя защиту периметра. | ||
| + | |||
| + | В инженерии безопасной разработки (DevSecOps) происхождение и целостность программных | ||
| + | артефактов контролируют на каждом шаге конвейера: состав зависимостей фиксируют в виде | ||
| + | '''ведомости состава ПО''' (''Software Bill of Materials'', SBOM), автоматически | ||
| + | проверяют его на известные уязвимости, а готовые артефакты '''криптографически подписывают''', | ||
| + | чтобы гарантировать, что в развёртывание попадёт именно проверенная сборка, а не подменённая. | ||
| + | Так известная уязвимость в зависимости сопоставляется с записью в публичной базе (CVE) и | ||
| + | блокирует сборку до её устранения. | ||
| + | |||
| + | Для обучающих данных требуется симметричный, но пока менее зрелый контроль: | ||
| + | * '''происхождение данных''' (''data provenance'') — фиксация источников каждой части | ||
| + | выборки и цепочки её преобразований; | ||
| + | * '''версионирование и контроль целостности''' датасетов — воспроизводимость обучения и | ||
| + | возможность отследить, какие данные попали в конкретную версию модели; | ||
| + | * '''проверка источников''' при сборе из открытых каналов (пользовательская разметка, | ||
| + | веб-краулинг, федеративное обучение), где внесение отравленных примеров не требует доступа | ||
| + | к инфраструктуре. | ||
| + | |||
| + | Принципиальное отличие двух задач в следующем. Скомпрометированную зависимость можно | ||
| + | сопоставить с '''сигнатурой''' известной уязвимости и отклонить автоматически. Отравленный | ||
| + | объект такой сигнатуры не имеет: по отдельности он выглядит как обычный обучающий пример, а | ||
| + | его вредоносность проявляется не в самом объекте, а лишь в '''поведении обученной на нём | ||
| + | модели'''. Поэтому перенос практик безопасности цепочки поставок на машинное обучение | ||
| + | требует не только контроля происхождения данных, но и отдельного класса проверок самой | ||
| + | модели — например, поиска [[#Backdoor-атаки|закладок]] и оценки устойчивости после обучения. | ||
== См. также == | == См. также == | ||
Текущая версия
| | Статья написана с использованием LLM Claude Opus 4.8 и проверена участником Zarina Sibgatullina 18:35, 18 июля 2026 (MSD) |
Отравление обучающих данных (data poisoning) — класс атак на модели машинного обучения, при которых противник вмешивается в обучающую выборку, а не во входные данные на этапе применения. Внедряя специально подобранные или искажённые объекты, атакующий изменяет саму обученную модель — снижает её качество в целом либо закладывает скрытое нужное ему поведение. В отличие от состязательных атак, действующих на этапе вывода, отравление поражает более раннюю стадию конвейера обучения и потому относится к угрозам целостности процесса обучения (см. безопасность машинного обучения).
Атака особенно актуальна там, где обучающие данные собираются из открытых или слабо контролируемых источников: пользовательской разметки, веб-краулинга, федеративного обучения. В таких условиях внесение отравленных примеров не требует доступа к внутренней инфраструктуре.
Содержание |
Модель угрозы
Возможности противника характеризуются долей отравленных объектов и степенью контроля над ними:
- контроль над меткой (label flipping) — атакующий может менять только метки части
объектов;
- контроль над признаками — можно внедрять произвольно сконструированные объекты
(clean-label-атаки сохраняют визуально корректную метку, что затрудняет обнаружение);
- доля отравления — обычно единицы процентов выборки; сильные атаки достигают цели при
доле менее 1 %.
По цели различают:
- атаки доступности (availability) — общая деградация качества модели;
- целевые атаки (targeted) — ошибка на конкретных объектах при сохранении общего
качества;
- backdoor-атаки (закладки) — модель работает штатно, но выдаёт нужный атакующему
ответ при появлении заранее выбранного триггера.
Формальная постановка
Пусть модель обучается минимизацией эмпирического риска на выборке :
Противник добавляет к чистой выборке множество отравленных
объектов
ограниченного размера и стремится максимизировать свою цель
(например, потери на целевом объекте или на отложенной выборке):
Это двухуровневая (bilevel) задача оптимизации: внутренний уровень —
обучение модели на отравленной выборке, внешний — подбор отравления
. Её вложенная структура делает точное решение вычислительно трудным, поэтому
на практике применяют приближения: атаки на основе градиента по внесённым объектам,
влияние-функции (influence functions), градиентное сопоставление (gradient matching).
Backdoor-атаки
Наиболее исследованный частный случай — внедрение закладки. Атакующий добавляет в
обучение объекты с фиксированным триггером (например, небольшой узор в углу
изображения), помеченные целевым классом
. Обученная модель связывает триггер
с целевым классом:
где — наложение триггера. На чистых данных модель показывает нормальное
качество, поэтому закладка не выявляется обычной проверкой на отложенной выборке. Активирует
её только знание триггера, которым владеет атакующий.
Защита
Универсальной защиты нет; применяют несколько дополняющих подходов:
- фильтрация данных — выявление аномальных или влиятельных объектов до обучения
(например, по спектральным сигнатурам скрытых представлений, по активациям);
- робастное обучение — методы, устойчивые к части испорченных меток
(робастные функции потерь, обрезка по влиянию);
- дифференциальная приватность как побочная защита — ограничивает влияние отдельного
объекта на модель, что затрудняет и отравление;
- контроль происхождения данных (data provenance) — организационная мера:
отслеживание источников обучающих данных и цепочки их поставки.
Как и в случае состязательных атак, защиту следует проверять против адаптивного противника, знающего её механизм: атаки типа clean-label специально конструируются, чтобы проходить фильтры, основанные на согласованности метки и содержимого.
Отравление как атака на цепочку поставок
Отравление обучающих данных удобно рассматривать как атаку на цепочку поставок (supply chain), аналогичную внедрению вредоносного кода в стороннюю программную зависимость. В обоих случаях противник не взламывает целевую систему напрямую, а внедряет вредоносный компонент выше по течению — в пакет-зависимость либо в обучающую выборку, — и тот попадает в конечный продукт штатным путём сборки, минуя защиту периметра.
В инженерии безопасной разработки (DevSecOps) происхождение и целостность программных артефактов контролируют на каждом шаге конвейера: состав зависимостей фиксируют в виде ведомости состава ПО (Software Bill of Materials, SBOM), автоматически проверяют его на известные уязвимости, а готовые артефакты криптографически подписывают, чтобы гарантировать, что в развёртывание попадёт именно проверенная сборка, а не подменённая. Так известная уязвимость в зависимости сопоставляется с записью в публичной базе (CVE) и блокирует сборку до её устранения.
Для обучающих данных требуется симметричный, но пока менее зрелый контроль:
- происхождение данных (data provenance) — фиксация источников каждой части
выборки и цепочки её преобразований;
- версионирование и контроль целостности датасетов — воспроизводимость обучения и
возможность отследить, какие данные попали в конкретную версию модели;
- проверка источников при сборе из открытых каналов (пользовательская разметка,
веб-краулинг, федеративное обучение), где внесение отравленных примеров не требует доступа к инфраструктуре.
Принципиальное отличие двух задач в следующем. Скомпрометированную зависимость можно сопоставить с сигнатурой известной уязвимости и отклонить автоматически. Отравленный объект такой сигнатуры не имеет: по отдельности он выглядит как обычный обучающий пример, а его вредоносность проявляется не в самом объекте, а лишь в поведении обученной на нём модели. Поэтому перенос практик безопасности цепочки поставок на машинное обучение требует не только контроля происхождения данных, но и отдельного класса проверок самой модели — например, поиска закладок и оценки устойчивости после обучения.
См. также
- Безопасность машинного обучения
- Состязательная атака
- Дифференциальная приватность
- Федеративное обучение
Литература
- Biggio B., Nelson B., Laskov P. Poisoning Attacks against Support Vector Machines // ICML. — 2012. — arXiv:1206.6389.
- Gu T., Dolan-Gavitt B., Garg S. BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain. — 2017. — arXiv:1708.06733.
- Shafahi A. et al. Poison Frogs! Targeted Clean-Label Poisoning Attacks on Neural Networks // NeurIPS. — 2018. — arXiv:1804.00792.
- Chen X. et al. Targeted Backdoor Attacks on Deep Learning Systems Using Data Poisoning. — 2017. — arXiv:1712.05526.
- Steinhardt J., Koh P.W., Liang P. Certified Defenses for Data Poisoning Attacks // NeurIPS. — 2017. — arXiv:1706.03691.

