كيف يمكن لخمسة وثائق أن تكسر نظام RAG وتحول قاعدة المعرفة إلى متجه هجوم

RAG-системы часто воспринимают как способ снизить галлюцинации и заставить LLM опираться на корпоративные документы. Но если база знаний считается доверенной по умолчанию, именно она может стать самым удобным каналом для prompt injection и тихой подмены ответов.

Где слабое место

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

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

Но качество решения падает, а вместе с ним — доверие к продукту, который должен был опираться на проверенные документы.

Почему хватает пяти документов

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

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

Система редко подаёт в модель весь документ целиком — обычно она нарезает его на чанки и выбирает несколько верхних совпадений. Это значит, что атакующему не обязательно писать длинный вредоносный текст: достаточно внедрить короткие, но семантически «липкие» фрагменты, которые будут всплывать в top-k выдаче. В результате LLM получает не нейтральную справку, а уже отобранный набор влияющих подсказок, причём оператор системы может долго не замечать, что ответы дрейфуют в сторону, заданную этими фрагментами.

Что нужно защищать В продакшене RAG нельзя защищать одним фильтром на входе.

Нужна многоуровневая схема, которая проверяет и документы, и извлечённые чанки, и финальный ответ модели. Иначе команда может очистить пользовательский запрос, но пропустить тот же самый injection в базе знаний. Отдельная проблема — «тихие» атаки, когда система не падает и не выдаёт явной ошибки, а просто начинает уверенно советовать неверные действия, подменять приоритеты или раскрывать то, что не должна была показывать.

• Проверка документов до индексации на скрытые инструкции и подозрительные шаблоны Изоляция данных по источникам, ролям и уровню доверия Политики retrieval: лимиты на доминирование одного источника и контроль разнообразия Фильтрация контекста перед подачей в LLM и отдельный guardrail для ответа Логи, red-team тесты и регулярная переоценка корпуса после обновлений Демо-сценарии обычно скрывают эту проблему, потому что в них корпус маленький, источники известны заранее, а запросы предсказуемы. В рабочей системе всё иначе: документы грузятся пакетами, обновляются без ручной модерации, приходят из разных отделов и нередко смешивают факты, советы, шаблоны и служебные инструкции. В такой среде RAG нужно проектировать не как «поиск + LLM», а как security-sensitive pipeline с понятными зонами доверия, аудитом изменений и отдельными правилами для разных типов контента.

Что это значит

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