Суть
Отравлением называют подмену данных или артефактов модели так, чтобы в систему попало вредное поведение, смещение или используемая слабость. «Обучающие данные» здесь понимаются шире традиционного: подмена возможна везде, где данные принимаются, преобразуются, извлекаются или переиспользуются.
Пять стадий, на которых это происходит:
- предобучение — заражённый корпус, из которого модель усваивает вредные образцы и перекошенные представления;
- дообучение — подготовленный набор вносит доменные режимы отказа или скрытые триггеры;
- создание эмбеддингов — отравляются сохранённые векторы, чтобы влиять на извлекаемое (Embedding Attacks);
- перенос обучения и переиспользование — скомпрометированная исходная модель передаёт компрометацию всем, кто на ней строит;
- конвейеры непрерывного обучения — автоматический приём без достаточной проверки позволяет формировать поведение постепенно.
Отдельно от этого стоят инъекции через извлечённое содержимое во время работы: это уже Prompt Injection, там ничего не портится надолго.
Почему обычные проверки не ловят
Целевой вариант атаки специально размывает способность отказывать, сохраняя общую точность. Модель по-прежнему хорошо решает задачи, метрики качества не падают, и деградация не обнаруживается стандартной оценкой — потому что стандартная оценка меряет не то. Это ровно то, чего добиваются намеренно в Abliteration, только полученное чужими руками и без вашего ведома.
Отсюда практическое: набор оценки должен отдельно проверять отказы, а не только правильные ответы. Иначе рост качества и потеря защиты выглядят одинаково.
Бэкдор может молчать до триггера. Поведение модели не меняется, пока не встретится условная фраза, — и модель работает спящим агентом сколько угодно долго. Приёмка, проведённая на обычных данных, такого не видит по определению.
Двести пятьдесят документов
Числа, ломающего интуицию, стоит держать в голове: порядка 250 отравленных документов компрометируют модели от 600M до 13B параметров — независимо от размера обучающего набора (Souly et al., 2025).
Интуиция подсказывает обратное: большой корпус «разбавит» вредное. Не разбавляет. Значит защита не может строиться на масштабе данных, и вопрос «какая доля корпуса под контролем» заменяется вопросом «может ли посторонний вообще положить туда документ».
Заражается не только вес
Модель из общего репозитория несёт с собой не-весовые артефакты, и каждый из них меняет поведение или исполняет код при загрузке: шаблоны чата, конфигурации токенизатора, LoRA/PEFT-адаптеры, артефакты квантизации, плюс классическая небезопасная десериализация. Проверка «просканировали веса» покрывает меньшую часть поверхности (Supply Chain AI).
Чем это дорого
Обычную уязвимость чинят правкой кода. Отравление требует перепроверки данных, повторного обучения, замены модели или перестройки конвейера — и обнаруживается, как правило, сильно позже внедрения. Триггерная фраза, попавшая в популярный открытый набор, расходится по всем моделям, дообученным на нём, и заставляет переобучать их все.
Практическое следствие для планирования: стоимость инцидента здесь не в устранении, а в переобучении, и закладывать её надо при выборе внешнего набора или базовой модели, а не после.
Связано с
- RAG Poisoning — отравление на извлечении: живёт в индексе, чинится удалением документа
- Memory Poisoning — то же на уровне памяти агента
- Abliteration — намеренное снятие отказа; отравление даёт тот же эффект чужими руками
- Supply Chain AI — откуда приходят чужие наборы, модели и адаптеры
- Embedding Attacks — отравление на уровне векторов и геометрии поиска
- LLM Training Stages — стадии, на каждой из которых открыта своя поверхность
- Agent Evals — почему набор оценки должен отдельно мерить отказы