Отравление данных может изменить ответы ИИ-модели или корпоративного ассистента, даже если система в целом продолжает работать как обычно. Для этого не всегда нужно портить весь датасет: иногда достаточно нескольких метко подобранных записей или одного подменённого документа. Хрю, самый коварный баг с пятачком — тот, что скрывается за неизменной общей метрикой.

Старший эксперт по защите ИИ Альфа-Банка Керимбай Акылжан объясняет, где в AI-пайплайне могут подменить данные, почему такая атака проходит мимо обычных проверок и как проследить путь от документа до ответа модели.

Что именно могут отравить

Под отравлением данных часто понимают изменение обучающей выборки: в неё добавляют неправильные примеры или метки, и модель усваивает ошибочные закономерности. Но на систему можно повлиять и после завершения обучения — например, подменив источник, к которому ассистент обращается при подготовке ответа.

Злоумышленник может изменить метки, удалить важные записи, нарушить баланс классов или добавить фразу-триггер, которая вызывает определённую реакцию. Последствия зависят от цели атаки. Массовая подмена может ухудшить качество модели в целом, а целевая атака заставляет её ошибаться только при определённом условии. Такое скрытое поведение называют бэкдором, или закладкой.

Во втором случае общие метрики могут почти не измениться: модель нормально отвечает на типовые запросы, но реагирует неправильно на отдельную фразу, объект или категорию. Поэтому проверка только среднего качества не гарантирует, что в системе нет скрытой уязвимости.

Точки риска: обучение, RAG и файлы моделей

Предварительное обучение и дообучение

При предварительном обучении модель получает большой корпус, в который могут входить документы из внешних источников. Если один из них скомпрометирован, изменённый материал может попасть в выборку. Большой объём корпуса сам по себе не защищает от целевой атаки: небольшого количества примеров может хватить, чтобы закрепить нужную реакцию.

Разработчик готовой модели может не знать, какие именно документы использовались при её первоначальном обучении. При дообучении важно контролировать происхождение, версию и состав дополнительного датасета: он может быть значительно меньше, поэтому отдельные записи способны сильнее повлиять на результат.

RAG и база знаний

В системе RAG (Retrieval-Augmented Generation) модель получает информацию из внешнего хранилища при обработке запроса. Система находит в базе знаний подходящие фрагменты, добавляет их в контекст, а модель формирует ответ.

Если подменить документ с правилами согласования операций, ассистент может использовать ложный текст как действующую инструкцию и сообщить сотруднику неправильный порядок действий. Сама модель при этом не изменилась: для атаки достаточно повлиять на источник, который она читает.

Другой сценарий — prompt injection: в документ помещают текст, адресованный непосредственно модели, например требование игнорировать предыдущие инструкции. Информация, которая должна была быть лишь содержимым документа, начинает влиять на поведение ассистента. Хрю, здесь важно проверять не только, убедительно ли звучит ответ, но и откуда взялись его утверждения.

Загружаемые модели и репозитории

Риск возникает и при получении готовой модели из внешнего репозитория. В нём могут быть не только веса, но и скрипты, зависимости, установщики и настройки, запускающие дополнительный код. Некоторые форматы, в частности связанные с pickle, могут выполнять код при десериализации. Это отдельный от отравления обучающих данных сценарий, но его нужно учитывать ещё до тестирования ответов.

Проверяйте автора и репозиторий, конкретную версию или коммит, лицензию, историю изменений и всё содержимое, а не только файл весов. Для PyTorch загрузка недоверенных файлов с weights_only=False рискованна; для обычных весов стоит предпочесть weights_only=True. В Hugging Face параметр trust_remote_code=True разрешает выполнение кода из репозитория, поэтому его не следует включать без отдельной проверки. По возможности используйте safetensors и фиксируйте точную ревизию. Первый запуск должен выполняться в изолированной среде без рабочих секретов и доступа к внутренним системам.

Почему может хватить небольшой подмены

В приведённом экспертом примере исследователи Anthropic использовали для обучения 250 документов с триггером <SUDO>. После появления этой фразы модель начинала выдавать бессмысленный текст, но без триггера работала как обычно. Для самой большой из проверенных моделей вредоносные данные составляли лишь 0,00016% обучающих токенов.

Этот пример показывает, почему атака может не проявиться при обычном тестировании: если в тестовых запросах нет нужного условия, модель будет проходить проверки. Для классических ML-моделей стоит анализировать метрики на отдельных сегментах, распределения признаков и классов, а также аномальные метки. Для языковых моделей важно проверять реакции на разные формулировки и редкие условия, особенно связанные с новыми данными.

Поиск точных дубликатов тоже не является универсальной защитой. Вредоносные примеры можно перефразировать или изменить с помощью невидимых символов: записи будут буквально отличаться, но закреплять схожее нежелательное поведение. Изменение распределения или необычная запись — повод для проверки, но не автоматическое доказательство атаки.

Как зафиксировать происхождение данных

Прежде чем загружать материал, установите владельца источника, конечный адрес, версию документа и условия использования. Проверьте, соответствует ли файл заявленному формату, нет ли в нём вредоносного кода, макросов или вложений. Для датасета дополнительно проанализируйте структуру, объём, полноту, дубликаты, аномалии, скрытые символы и наличие конфиденциальной информации.

После получения сохраните неизменную копию оригинала. Очищенный и проверенный набор оформите как отдельную версию и зафиксируйте его контрольную сумму. Перед обучением система должна повторно сверить сумму и остановить процесс, если файл изменился. Идентификатор набора и контрольную сумму следует записывать вместе с результатом обучения.

Контрольная сумма подтверждает, что файл не изменился относительно зафиксированной версии, но не доказывает правдивость его содержимого. Если команда сохранила уже отравленный документ, хеш не разоблачит ложные утверждения. Поэтому проверка целостности должна идти рука об руку с проверкой источника и содержания.

Как найти источник ошибочного ответа в RAG

Для каждого запроса стоит сохранять сам запрос, идентификаторы найденных фрагментов, исходные документы и их версии, контекст, переданный модели, и итоговый ответ. Это позволяет воспроизвести проблему и увидеть, какие именно материалы повлияли на результат.

Подозрительные документы проверяют по авторству, времени загрузки, истории изменений и контрольной сумме. Документ можно временно убрать из индекса и повторить запрос: если ошибка исчезает, это подтверждает связь с источником. Затем нужно исследовать весь путь, ведь при обработке файл мог превратиться в отдельные фрагменты, эмбеддинги и записи в индексе. Простого исправления исходного файла может быть недостаточно.

Защита пайплайна и действия после обнаружения подмены

Загрузку данных стоит организовать как контролируемый процесс с определёнными источниками, ролями и согласованием изменений. Не следует разрешать прямую непроверенную публикацию в продуктовую среду; операции нужно журналировать, а сервисным учётным записям предоставлять только минимально необходимые права. Отдельно определите владельца данных, ответственного за загрузку и независимого согласующего. Для RAG контролируйте доступ к документам и фрагментам, которые система может передать модели.

Если подмена уже обнаружена, сначала остановите использование подозрительного набора, документа, индекса или модели и сохраните материалы для расследования. Не удаляйте их в спешке: так можно потерять историю изменений и доказательства. Сопоставьте версии и журналы загрузки, определите, где появился вредоносный контент и какие данные или ответы могли быть им затронуты.

В RAG недостаточно удалить только исходный документ: нужно также убрать связанные фрагменты, эмбеддинги и кэшированные ответы, перестроить индекс на проверенных данных и повторить запрос, на котором проявилась ошибка. Если отравленные данные использовались для обучения, удаление примеров из хранилища не исправит уже полученную модель. Нужно вернуться к доверенной версии датасета, повторить обучение и валидацию и вывести скомпрометированную модель из эксплуатации.

Надёжная проверка сочетает контроль происхождения и целостности, анализ содержимого и тестирование поведения в разных сценариях. Для каждого ответа и версии модели должна быть возможность установить, на каких документах они основывались. Именно такая история данных поможет найти подмену, воспроизвести сбой и восстановить систему.