Представьте, что корпоративный ИИ-ассистент внезапно сообщает сотруднику, что для важной операции больше не требуется согласование. При этом сама модель работает как обычно, а ошибка появляется только при обращении к определённому документу. Причина может скрываться в данных, которые ассистент использует для ответа.Разберёмся в проблеме и заодно посмотрим, как проследить путь от подозрительного документа до ответа модели и что делать, если отравленные данные уже попали в систему. А поможет нам в этом старший эксперт по защите ИИ Альфа-Банка Керимбай Акылжан. Акылжан отвечает за безопасность ИИ-технологий и поможет нам на конкретных примерах показать, где возникают уязвимости при работе с данными и какие меры помогают предотвратить атаки на ИИ-системы.Что именно можно отравитьКогда говорят об отравлении данных, обычно представляют плохой обучающий датасет. Злоумышленник добавляет туда неправильные примеры, модель на них обучается и начинает ошибаться. Однако воздействовать на ИИ-систему можно на разных этапах, в том числе после завершения обучения.По словам эксперта по кибербезопасности Альфа Банка, злоумышленнику необязательно менять весь набор данных. Иногда достаточно небольшой, но правильно подобранной части:изменить метки, удалить важные записи, нарушить баланс классов, добавить специальную фразу, на которую модель будет реагировать определённым образом.Результат зависит от того, какие данные изменили и чего хотели добиться. При массовом отравлении качество модели обычно снижается в целом. Например, если в обучающей выборке появились неправильные метки, модель может начать хуже различать соответствующие классы. Такую проблему потенциально можно заметить по метрикам качества.Целевая атака работает иначе. Модель продолжает нормально отвечать на большинство запросов, но ошибается при определённой фразе, объекте или категории. Такое скрытое поведение называют бэкдором, или закладкой. Общие метрики при этом могут почти не измениться.Посмотрим, на каких этапах злоумышленник может вмешаться в работу системы.ПредобучениеНа этапе предобучения модель получает большой корпус данных. В него могут попадать документы из внешних источников, поэтому компрометация одного из них способна повлиять на состав обучающей выборки.Большой объём данных сам по себе не гарантирует защиту от целевой атаки. Если вредоносные примеры подобраны так, чтобы закрепить определённую реакцию, даже небольшая примесь может повлиять на поведение модели.При этом разработчик, который использует готовую модель, может не знать, какие именно документы участвовали в её первоначальном обучении. Поэтому для собственной системы необходимо отдельно проверять доступные данные и поведение модели.ДообучениеВо время дообучения модель работает с дополнительным датасетом. Он может быть значительно меньше корпуса предобучения, поэтому отдельные примеры способны сильнее влиять на итоговое поведение.Злоумышленник может воспользоваться этим и изменить часть данных: добавить неправильные ответы, подменить метки или внедрить триггер. В результате модель может начать неправильно обрабатывать определённые запросы, хотя на остальных данных будет показывать привычное качество.Для разработчика здесь важны происхождение датасета, его версия и возможность проверить, какие конкретно данные использовались при обучении.RAG и корпоративная база знанийВ системах с RAG, Retrieval-Augmented Generation, модель получает дополнительную информацию из внешнего хранилища во время обработки запроса.Например, пользователь спрашивает корпоративного ассистента о правилах согласования операции. Система ищет подходящий документ в базе знаний, извлекает нужные фрагменты и добавляет их в контекст запроса. После этого модель формирует ответ.Если злоумышленник изменит документ, ассистент может использовать ложную информацию как основание для ответа.В этом случае сама модель остаётся прежней. Для атаки достаточно повлиять на источник, из которого она получает сведения.Вредоносный документ также может содержать скрытую инструкцию, обращённую непосредственно к модели. Тогда проблема связана уже с внедрением инструкций, или prompt injection. Внешний текст, который должен использоваться как данные, начинает влиять на поведение ассистента.Файлы готовой моделиЕщё одна точка риска возникает при скачивании готовой модели из внешнего репозитория. Проблема здесь может быть связана с содержимым файлов и способом их загрузки. Например, некоторые форматы позволяют выполнить код при десериализации объекта. Злоумышленник может воспользоваться этим, чтобы атаковать среду разработчика ещё до начала работы с моделью.В репозитории также могут находиться Python-скрипты, зависимости, установщики и настройки, запускающие дополнительный код. Такой сценарий отличается от классического отравления обучающих данных. Однако при проверке внешней модели его необходимо учитывать: подозрительное содержимое может представлять опасность ещё до того, как разработчик начнёт тестировать ответы.Получается, что защищать нужно весь путь данных: от внешнего источника и обучения до базы знаний, загрузки готовой модели и формирования ответа.Как 250 документов сформировали бэкдорНебольшая доля вредоносных данных кажется несущественной на фоне огромного обучающего корпуса. Но для целевой атаки важен не общий объём испорченной информации, а то, какое поведение она должна закрепить.Эксперт приводит в пример исследование Anthropic, в котором для обучения использовали 250 документов с триггером . После появления этой фразы модель вместо нормального ответа начинала выдавать бессмысленный текст.При этом без триггера она продолжала работать обычным образом. Для крупнейшей из проверенных моделей вредоносные данные составляли всего 0,00016% обучающих токенов. Этого оказалось достаточно, чтобы сформировать скрытое поведение.Здесь интересны два момента.1. Количество изменённых документов не обязательно должно быть сопоставимо с размером обучающего корпуса. В данном случае сработала сравнительно небольшая примесь.2. Последствия атаки проявлялись при конкретном условии. Пока в запросе не появлялся триггер, модель могла демонстрировать привычное поведение. Если проверять её только на обычных вопросах, проблему можно пропустить.Поэтому при анализе качества важно смотреть, как модель ведёт себя на отдельных категориях запросов и редких условиях. Предположим, после очередного обучения общая метрика практически не изменилась. Это ещё не означает, что новая версия ведёт себя так же, как предыдущая. Ошибки могли появиться только в одной группе данных, на которую приходится небольшая часть тестовой выборки.Для классической ML-модели плохим признаками будут резкие изменения распределений признаков и классов, необычные метки или изменение состава выборки. Для языковой модели отдельное внимание стоит уделить новым реакциям на определённые фразы. При этом разработчик может не знать заранее, какой именно триггер использовал злоумышленник. Поэтому проверять придётся и изменения в данных, и поведение модели, особенно в сценариях, связанных с недавно добавленными источниками.Как подмена попадает в датасетЧтобы изменить поведение модели, злоумышленнику сначала нужно получить возможность повлиять на используемые данные.Акылжан выделяет несколько возможных путей: скомпрометированный внешний источник, учётная запись сотрудника, избыточные права сервисной учётной записи, уязвимость загрузчика или интеграция с внешней системой.Особенно опасны изменения, которые проходят через штатный процесс и выглядят как обычное обновление. Например, система периодически получает документы из внешнего источника. Один из документов изменился, загрузчик успешно обработал новую версию, и обновлённые данные попали в хранилище. Если на этапе загрузки никто не проверял содержимое, подмена может остаться незамеченной. В такой ситуации проблема состоит ещё и в том, что разработчику нужно установить, какая версия документа использовалась при конкретном запуске обучения.Допустим, команда обнаружила подозрительный ответ модели и хочет проверить обучающий датасет. Она снова скачивает документ по исходной ссылке. Но за прошедшее время содержимое страницы могло измениться. Теперь у команды есть актуальная версия, а исходной уже нет. Сравнить их и установить, что именно попало в обучение, становится сложнее.Поэтому эксперт предлагает разделить проверку на два вопроса:Можно ли доверять источнику, из которого получены данные?Можем ли мы доказать, что модель обучалась именно на проверенной версии?Для первого вопроса необходимо зафиксировать происхождение файла. Для второго потребуется сохранить конкретные версии данных и связать их с результатами обучения.Что проверять при скачивании документаНачать стоит с самого источника. Нужно установить его владельца, конечный адрес, версию документа и условия использования. Затем проверяется полученный файл: соответствует ли он заявленному формату, содержит ли вредоносный код, макросы или вложения. Если речь идёт о целом датасете, дополнительно необходимо проверить его структуру и содержимое.Разработчик должен обратить внимание на изменения объёма, аномальные записи, неожиданные дубликаты и скрытые символы. Также необходимо проверить наличие конфиденциальной информации. Допустим, в очередной версии датасета резко изменилась доля одного из классов. Это может указывать на проблему с данными и требует отдельной проверки. Само по себе изменение распределения ещё не доказывает атаку, но оставлять его без внимания не стоит.Проверка файла на вредоносный код тоже решает отдельную задачу. По словам эксперта, отравленный набор данных может содержать код, который сработает при попытке открыть файл, а не во время обучения. Поэтому безопасность файла и корректность содержащихся в нём данных нужно проверять отдельно.Почему исходный документ нужно сохранятьПосле скачивания оригинал необходимо сохранить как отдельную исходную версию и больше не изменять. Затем данные проходят проверку и очистку. Получившийся набор сохраняется как новая версия, допущенная к обучению. Для неё фиксируется контрольная сумма, то есть значение, с помощью которого можно проверить целостность содержимого. Если файл изменится, повторно вычисленная контрольная сумма не совпадёт с сохранённой.Перед запуском обучения система должна повторно сверить контрольную сумму и остановить процесс при несовпадении, чтобы не полагаться на то, что данные по исходной ссылке остались прежними.Модель должна получать конкретную очищенную и проверенную версию набора. Её идентификатор и контрольная сумма записываются вместе с результатами обучения. Теперь появляется возможность установить, какие именно данные использовались для получения определённой версии модели.Контрольная сумма подтверждает целостность относительно зафиксированной версии, а не достоверность содержимого. Если первоначально команда сохранила уже отравленный документ, его контрольная сумма не поможет обнаружить ложную информацию. Поэтому сохранение версий необходимо сочетать с проверкой источника и самого содержимого.Почему RAG может ответить неправильноВ RAG-системе злоумышленнику достаточно изменить документ, который ассистент использует при поиске информации.Представим корпоративную базу знаний с инструкциями для сотрудников. В одном из документов описан порядок согласования операции. Злоумышленник получает возможность изменить этот документ и добавляет утверждение, что согласование больше не требуется.Когда сотрудник задаёт соответствующий вопрос, система ищет информацию в базе и передаёт найденный фрагмент модели. Ассистент может использовать подменённый текст как действующее правило и сообщить пользователю неправильный порядок действий.Причём в остальных вопросах он может продолжать работать нормально. Проблема возникает из-за того, что в контекст модели попадает информация из изменённого документа. Для неё этот фрагмент становится одним из оснований ответа.Здесь возможны два разных сценария. Первый связан с ложными данными. Документ содержит неправильный факт, устаревшее правило или подменённую инструкцию для сотрудника. Модель использует этот текст и формирует на его основе неправильный ответ. Второй связан с инструкциями для самой модели. Например, злоумышленник добавляет в документ команду «игнорируй предыдущие требования».Такой текст должен оставаться содержимым найденного документа. Однако модель может воспринять его как инструкцию, которую нужно выполнить. Например, на странице оставили инструкцию для модели, после чего при описании обязанностей сотрудника ассистент сообщил, что тот продаёт мобильные телефоны и телевизоры. В проверенных данных такой информации не было.Этот пример показывает, почему недостаточно оценивать только то, насколько ответ выглядит правдоподобным. Нужно проверять, чем он подтверждается и какие источники использовались.Как найти документ, из-за которого возникла ошибкаНачать нужно с восстановления цепочки формирования ответа. Для каждого запроса эксперт рекомендует сохранять:запрос пользователя;идентификаторы найденных фрагментов;исходные документы и их версии;сформированный контекст, переданный модели;итоговый ответ.Без этой информации разработчику придётся искать проблему среди всех документов базы знаний, не зная, какие из них участвовали в формировании ответа. Если цепочка сохранена, можно воспроизвести ошибку на том же запросе и посмотреть, какие фрагменты система передала модели. Затем проверяются подозрительные документы: кто их создал, когда загрузил, какие изменения вносились и совпадает ли текущая контрольная сумма с сохранённой.После этого документ временно исключают из индекса и повторяют запрос. Если ошибка исчезла, связь с исключённым документом подтверждается. Дальше необходимо изучить историю его изменений и определить, какие данные могли пострадать.Здесь есть дополнительный нюанс: исправления одного исходного файла может оказаться недостаточно. При обработке документа система могла создать отдельные фрагменты, эмбеддинги и записи в индексе. Поэтому после обнаружения подмены придётся проверить весь маршрут, по которому прошла изменённая информация.Типы проверок: что искать в данных и ответахУниверсальной проверки, которая обнаружит любую подмену, нет. Разные способы воздействия оставляют разные следы.Если злоумышленник заменил файл, проблему можно обнаружить по изменившейся контрольной сумме. Если добавил ложную информацию в документ, потребуется проверить содержимое. Если внедрил бэкдор в обучающую выборку, ошибка может проявиться только во время тестирования модели на определённом запросе.Проверка происхождения и целостностиЗдесь задача состоит в том, чтобы установить источник данных и убедиться, что они не изменились после проверки. Для каждого источника необходимо знать владельца, назначение, версию и контрольную сумму. История изменений должна позволять установить, когда появился новый документ или обновилась существующая запись.При работе с внешними данными также проверяются конечный адрес загрузки и условия использования. Для готовой модели необходимо зафиксировать конкретную версию или коммит репозитория. Это позволит избежать ситуации, когда при следующей загрузке команда получит другой набор файлов.Проверка целостности особенно полезна при поиске несанкционированных изменений. Но она не отвечает на вопрос, содержал ли первоначальный документ вредоносные инструкции.Проверка структуры и содержимогоДля классической ML-модели эксперт рекомендует отслеживать состав выборки, распределения признаков и классов, необычные метки. Например, если после обновления датасета распределение классов резко изменилось, стоит выяснить причину. Возможно, в набор попали новые данные, изменились правила разметки или произошла подмена.Также нужно проверять дубликаты, аномальные записи, полноту набора и наличие конфиденциальной информации.Для документов, которые используются в RAG, необходимо отдельно обращать внимание на подозрительные инструкции.Текст с требованием игнорировать предыдущие указания отличается от обычной информации, необходимой пользователю. Его появление внутри документа требует проверки. При этом вредоносные фрагменты могут быть замаскированы. Например, примеры могут отличаться невидимыми символами или незначительными изменениями формулировок.Проверка поведения моделиДаже если файл успешно прошёл проверки, нужно выяснить, как система использует его содержимое.Для обученной модели проверяется качество на отдельных сегментах данных. Это помогает заметить ошибки, которые могут быть скрыты за общей метрикой.Для RAG-ассистента необходимо оценивать и ответ, и найденные документы.Разработчик должен иметь возможность установить, из какого источника получена информация и соответствует ли она проверенным данным.Важна также проверка поведения при изменении запроса. Если один и тот же вопрос задаётся с разными формулировками, система не должна неожиданно менять ответ из-за вредоносного фрагмента.Эти проверки дополняют друг друга. Например, успешное сканирование файла не гарантирует, что модель правильно обработает содержащийся в нём текст. А корректный ответ на один тестовый вопрос ничего не говорит о поведении при редком триггере.Почему проверки пропускают подменуПредставим, что после обновления датасета команда запускает обычную проверку качества модели. Результаты практически не отличаются от предыдущей версии.На первый взгляд, всё нормально. Но если атака была направлена на конкретное условие, общая метрика может не показать проблему.Так произошло в примере с триггером . Модель продолжала работать как обычно, пока не встречала специальную фразу.Обычная тестовая выборка могла просто не содержать этого условия.По словам эксперта, целевые атаки часто пропускают именно потому, что качество измеряется на случайной выборке. Если вредоносное поведение проявляется редко, оно может остаться за пределами тестовых данных.Для классической ML-модели полезно отдельно проверять качество по сегментам. Даже если общая метрика не изменилась, число ошибок в одной из групп могло вырасти.Для ИИ-ассистента стоит расширять набор тестовых запросов с учётом возможных способов атаки.Например, один и тот же вопрос можно задавать в разных формулировках, менять порядок слов, добавлять опечатки и использовать другое оформление.Отдельного внимания требуют редкие темы, недавно добавленные источники и фразы, которые часто встречаются в новых документах.Всё это позволяет проверить поведение системы за пределами привычных пользовательских сценариев.Почему удаление дубликатов не решает проблемуОдна из стандартных проверок датасета заключается в поиске повторяющихся записей. Она полезна для контроля качества данных, но не гарантирует обнаружение отравления.Злоумышленник может перефразировать вредоносные примеры или добавить в них невидимые символы. Такие записи будут отличаться друг от друга, хотя по смыслу могут закреплять одно и то же нежелательное поведение. В результате обычная проверка точных дубликатов не обнаружит повторяющуюся вредоносную инструкцию.Почему правдоподобный ответ тоже нужно проверятьВ случае с RAG ошибка может выглядеть особенно убедительно. Ассистент находит документ, использует содержащуюся в нём информацию и формирует связный ответ. При этом сам документ уже изменён злоумышленником. Если разработчик проверяет только итоговую формулировку, он может не заметить подмену. Поэтому при каждом тесте необходимо смотреть, какие документы были найдены, какие версии использовались и что именно попало в контекст модели.Если ответ содержит утверждение, которого нет в проверенных источниках, это повод восстановить цепочку его формирования. Так можно найти не только явные сбои, когда модель выдаёт бессмыслицу, но и ошибки, которые выглядят как нормальные ответы.Как выстроить защиту в AI-пайплайнеПроверки качественнее всего отрабатываются, когда они встроены в процесс работы с данными. Если документ сначала попадает в продуктовую базу знаний, а проверяется только после жалобы пользователя, система уже успевает использовать потенциально вредоносное содержимое.Рекомендуем организовать контролируемый процесс загрузки, проверки и согласования изменений. Прямую запись в продуктовую среду лучше запретить, а все операции журналировать. Рассмотрим, из каких этапов может состоять такой процесс.Зафиксировать источники и праваСначала необходимо определить, откуда система может получать данные и кто имеет право их изменять. Для каждого источника фиксируются владелец, назначение и допустимые правила использования. При этом менять данные не должны все разработчики или пользователи базы знаний. Доступ необходимо распределить по ролям.Предлагаем схему:Владелец данных определяет допустимые источники и правила использования.Уполномоченный редактор или Data Engineer загружает и обновляет данные.Независимый согласующий подтверждает публикацию.Специалисты по кибербезопасности проверяют источники, выборки и меры защиты.Сервисная учётная запись выполняет техническую загрузку с минимальными правами.Такой подход помогает отделить подготовку данных от их публикации. Например, сотрудник, который загружает новый документ, не должен автоматически получать возможность изменять продуктовую базу знаний без согласования.Для сервисных учётных записей важно исключить избыточные права. Если учётная запись будет скомпрометирована, её полномочия определят, какие данные сможет изменить злоумышленник.В RAG-системах дополнительно проверяются права доступа к документам и их фрагментам. Необходимо учитывать, какие данные система может находить и передавать модели при обработке пользовательского запроса.Сохранять версии и целостностьСледующий этап связан с сохранением данных. Исходный файл после скачивания нужно оставить неизменным. Проверка и очистка выполняются с созданием новой версии. Для версии, которая допускается к обучению или использованию в системе, фиксируется контрольная сумма.Перед запуском обучения система должна повторно сверять её с сохранённым значением. При несовпадении процесс останавливается. Версия набора и контрольная сумма записываются вместе с результатами обучения.Для базы знаний также необходимо сохранять историю загрузки и обновления документов. Это позволит установить, какие изменения происходили перед появлением ошибки.Важна и возможность отката к проверенной версии. Если подмена будет обнаружена, команда сможет определить, какие данные использовались до инцидента и к какой версии необходимо вернуться.Однако история версий будет полезна только в том случае, если она охватывает весь маршрут данных. Для RAG недостаточно хранить версию исходного документа, если невозможно связать её с обработанными фрагментами и индексом.Проверять содержимоеДо допуска данных в систему нужно проверить их качество и безопасность.Для файлов проверяются заявленный формат, вредоносный код, макросы и вложения.Для датасетов дополнительно оцениваются структура, объём, полнота, дубликаты, аномалии, распределения признаков и классов. Отдельно проверяется наличие конфиденциальной информации.В RAG-системе необходимо также следить за корректным удалением устаревших данных и сохранением ссылок на источники. Например, если из базы знаний удалён документ, система не должна продолжать использовать связанные с ним устаревшие фрагменты.При тестировании нужно проверить и поведение системы в случае сбоя поиска. Также рекомендуем подготовить журналы, мониторинг изменений и возможность отката до вывода системы в эксплуатацию.Эти механизмы нужны не только для предотвращения подмены, но и для расследования: без истории изменений бывает сложно установить, когда и каким способом подозрительный документ попал в систему.Безопасно загружать файлы моделейОтдельные проверки требуются при использовании готовых моделей из внешних репозиториев. Скачанную модель нельзя сразу открывать в рабочей среде. Сначала необходимо проверить автора и репозиторий, конкретную версию или коммит, лицензию, историю изменений и доступные результаты сканирования. Просматривать нужно весь репозиторий, а не только файл весов. В нём могут находиться Python-скрипты, установщики, зависимости, пользовательские операторы и настройки, которые запускают дополнительный код. Особенно внимательно относитесь к форматам, использующим pickle, а также некоторым файлам .pt, .pth и .bin.Вредоносный объект может выполнить код непосредственно во время загрузки.PyTorch. При работе с недоверенными файлами опасна загрузка с weights_only=False. Для обычных весов предпочтительна загрузка только параметров с weights_only=True.PythonОн разрешает выполнение кода из репозитория. Поэтому включать его без отдельной проверки не следует.По возможности используйте safetensors и фиксируйте точную ревизию модели.Первый запуск должен проходить в изолированной среде без рабочих секретов и доступа к внутренним системам. Сетевые права и доступные ресурсы необходимо ограничить. После безопасной загрузки нужно отдельно проверить поведение модели на обычных и целевых сценариях.Успешное открытие файла подтверждает лишь то, что модель удалось загрузить. Оно не гарантирует отсутствие нежелательного поведения, сформированного во время обучения.Тестировать целевые сценарииПоследняя часть проверки связана с поведением уже подготовленной системы. Обычные тесты нужны, чтобы убедиться, что модель выполняет свои задачи. Но для обнаружения отравления к ним необходимо добавить сценарии, учитывающие возможные способы атаки.Нужно проверять одни и те же вопросы с разными формулировками, опечатками, изменённым порядком слов и оформлением.Отдельно тестируйте редкие темы, новые источники и фразы, встречающиеся в недавно добавленных документах. Для RAG при этом проверяется не только результат, но и список найденных документов. Если ассистент сообщает информацию, которую не подтверждают проверенные источники, необходимо выяснить, откуда она появилась. Для классической ML-модели полезно сравнивать качество на отдельных сегментах данных, а не ограничиваться общей метрикой. Перед запуском должны быть готовы журналы и мониторинг, которые позволят заметить изменение поведения после обновления данных. Проверка заканчивается тогда, когда команда может установить, какую версию данных использовала система, какие документы участвовали в ответе и как воспроизвести подозрительный результат.Что делать, если подмена уже обнаруженаДопустим, тестирование показало, что после обновления базы знаний ассистент начал давать неправильные ответы. Команда нашла подозрительный документ и подтвердила, что он влияет на результат. Теперь нужно установить, где ещё могли использоваться изменённые данные. Сначала нужно остановить использование подозрительного набора, документа, индекса или модели и сохранить материалы для расследования.Сразу удалять файлы не стоит. Вместе с ними можно потерять историю изменений и следы атаки, которые помогут выяснить, как именно произошла подмена. Дальше необходимо определить точку появления вредоносного содержимого и весь затронутый маршрут.Найти все затронутые данныеДля расследования используются версии документов, контрольные суммы, журналы загрузки, история доступа и сведения о запусках обучения.В RAG нужно проследить путь от исходного документа до сформированного ответа. Для этого проверяются исходные данные, обработанные фрагменты, эмбеддинги, индекс, запросы пользователей и ответы ассистента.Если подозрительные данные участвовали в обучении, необходимо установить, какие модели были получены с их использованием.Также нужно проверить решения, принятые на основе затронутых ответов. Например, если корпоративный ассистент сообщил пользователю неверное правило согласования операции, важно выяснить, какие запросы могли использовать подменённый документ и какие ответы система на них сформировала. Сохранённая история позволяет определить масштаб проблемы и выбрать способ восстановления.Удалить подмену из RAGЕсли вредоносное содержимое попало в базу знаний, недостаточно удалить только исходный документ. При обработке система могла разделить его на фрагменты, создать эмбеддинги и добавить записи в индекс. Кроме того, ранее сформированные ответы могли сохраниться в кэше. Поэтому необходимо удалить связанные с документом фрагменты, эмбеддинги и кэшированные ответы.После этого индекс нужно заново построить из проверенной версии данных. Затем следует повторить запрос, на котором проявлялась ошибка, и убедиться, что система больше не использует подменённый источник. Для этого пригодится сохранённая цепочка формирования ответа: запрос пользователя, найденные фрагменты, версии документов, контекст и итоговый результат.Восстановить обученную модельЕсли отравленные данные использовались во время обучения, ситуация сложнее. Удаление подозрительных примеров из хранилища не исправит уже обученную модель. Её параметры были получены с учётом этих данных. Лучше вернуться к доверенной версии набора, повторить обучение и валидацию, а скомпрометированную модель вывести из использования. Перед возвратом в эксплуатацию необходимо сверить контрольные суммы и повторить обычные и целевые тесты.Отдельно воспроизводится сценарий обнаруженной атаки. Если проблема проявлялась при определённой фразе или категории данных, нужно проверить поведение модели именно в этих условиях.После восстановления необходимо усилить мониторинг по признакам, которые помогли обнаружить инцидент. Например, если подмена проявилась через изменение распределения классов, соответствующую проверку стоит включить в контроль последующих обновлений. Если проблему нашли благодаря анализу найденных документов RAG, нужно сохранить возможность отслеживать версии источников и проверять их связь с ответами.ИтогоОтравление данных может проявиться на разных этапах работы с ИИ: во время обучения, после обновления базы знаний или при загрузке готовой модели. При этом небольшое изменение не обязательно приведёт к заметному ухудшению общего качества. Целевая атака может срабатывать только при определённой фразе, а подменённый документ в RAG способен заставить ассистента сообщить неверное правило.Поэтому при разработке ИИ-системы необходимо контролировать происхождение данных, сохранять их версии, проверять содержимое и тестировать поведение модели на отдельных сценариях.Если подмена всё же произошла, нужно проследить весь путь затронутой информации. Для RAG это означает проверку документа, фрагментов, эмбеддингов, индекса и ответов. Для обученной модели может потребоваться возвращение к проверенному датасету и повторное обучение.Главный ориентир для разработчика: у каждого ответа и каждой версии модели должна быть проверяемая история данных, на которых они основаны. Именно она поможет установить причину ошибки и восстановить систему после обнаружения подмены.