Что такое отравление RAG
При knowledge poisoning атакующий добавляет или изменяет документ в доступном RAG корпусе. Текст одновременно делают релевантным целевому запросу и способным склонить генератор к нужному ответу. Модель не обязана быть взломана: она добросовестно использует контекст, который система сама назвала релевантным.
Это риск целостности данных и retrieval pipeline, а не только проблема промпта.
Чем poisoning отличается от обычной ошибки
Устаревшая инструкция случайно даёт неверный ответ. Poisoned document создан или размещён намеренно, часто для конкретной темы, пользователя или формулировки запроса. Он может выглядеть естественно и не срабатывать на общих тестах.
Операционно нужны одинаковые функции — provenance, versioning и rollback, — но расследование дополнительно ищет канал записи, затронутые запросы и цель атакующего.
Где яд попадает в базу знаний
Опасны не только публичные сайты. Векторный индекс может автоматически поглощать wiki, tickets, Slack, PDF-вложения, shared drives, отзывы, webhooks и память агента. Компрометированный connector превращает доверенный источник в канал поставки.
Составьте карту всех writers: кто создаёт оригинал, кто меняет metadata, какой parser и chunker преобразуют его, кто запускает reindex.
Модель угроз до выбора защиты
| Возможность атакующего | Пример | Главный контроль |
|---|---|---|
| Публичная публикация | Страница попадает в crawler | Source policy и quarantine |
| Запись сотрудника | Wiki или ticket | ACL, review и аудит |
| Компрометация connector | Подмена sync | Workload identity и подпись |
| Изменение pipeline | Parser скрывает текст | Build provenance и CI |
Контроль должен соответствовать реальному пути записи, а не абстрактному «недоверенному интернету».
Реестр источников и уровни доверия
Для каждого source задайте owner, purpose, допустимые типы данных, writer identities, cadence, retention и trust tier. Официальная policy и комментарий клиента не должны иметь одинаковый вес только потому, что cosine similarity совпала.
Trust tier влияет на публикацию, ranking, необходимость corroboration и право инициировать действие. Само поле trust заполняет ingestion policy, а не автор документа.
Quarantine перед production-индексом
Новый документ сначала попадает в staging corpus. Pipeline проверяет MIME и размер, извлекает текст в изолированной среде, сканирует активное содержимое, сравнивает с source policy и сохраняет артефакты.
Неизвестный домен, резкий объём, новая writer identity или high-risk инструкция требуют review. Production retrieval не видит объект до атомарной публикации одобренной версии.
Provenance на уровне документа и chunk
Сохраняйте source ID, canonical URI, owner, writer, timestamps, content hash, parent version, parser/chunker versions и ingestion run. Каждый chunk наследует связь с исходным байтовым объектом.
Provenance доказывает происхождение, но не истинность. Подписанный документ с захваченного аккаунта всё ещё может лгать, поэтому важны независимая проверка и история изменений.
Контроль изменений, а не только новых файлов
Poisoning часто маскируется под небольшую правку существующей страницы. Вычисляйте semantic diff и подсвечивайте изменения сущностей, чисел, ссылок, запретов и процедур. Резкая смена embedding при малом текстовом diff — повод для проверки.
Для нормативных источников используйте four-eyes approval. Автор изменения не должен единолично публиковать его в production corpus.
Инструкции внутри документов считаются данными
Фразы «игнорируй правила», скрытый текст и команды для tools не получают привилегий из-за попадания в context window. System prompt явно обозначает retrieved content как цитируемые данные, а tool gateway независимо применяет права.
Это снижает indirect prompt injection, но не устраняет ложные факты. Убедительная дезинформация может не содержать ни одной подозрительной команды.
Защита на этапе retrieval
Комбинируйте dense и lexical signals, ограничивайте число chunks от одного документа или домена, применяйте metadata filters и диверсификацию результатов. Анализируйте аномально высокую релевантность нового документа к узкой группе запросов.
Исследования показывают, что hybrid retrieval способен снизить успех конкретных атак, но адаптивный атакующий оптимизируется под оба сигнала. Это барьер, не доказательство безопасности.
Corroboration должна быть независимой
Для рискованного ответа требуйте подтверждение из двух административно независимых источников. Две страницы одного скомпрометированного workspace или десять chunks одного PDF — один источник, а не десять голосов.
Критичный факт лучше сверить с authoritative API или реестром вне RAG-корпуса. При конфликте система показывает расхождение и не маскирует его уверенным пересказом.
От ответа к действию — отдельная граница
Даже отравленный retrieval не должен сам по себе разрешать перевод, удаление, смену доступа или отправку секрета. Model output остаётся предложением; policy engine проверяет пользователя, объект, сумму и approval.
Для high-impact workflow RAG сообщает справочную информацию, а параметры действия поступают из типизированного доверенного API.
Мониторинг признаков poisoning
Следите за новыми writers и domains, скачком ingestion, необычной частотой обновлений, near-duplicates, новым документом в top-k множества несвязанных запросов и концентрацией ответов на одном source.
Связывайте answer trace с точными chunk IDs и snapshot индекса. Алерт без возможности узнать, какие ответы использовали документ, мало помогает расследованию.
Версионирование и аварийный rollback
Публикуйте индекс как immutable snapshot с manifest: corpus version, набор hashes, модели embeddings и параметры retrieval. Переключение alias на предыдущий snapshot должно быть отрепетировано.
Kill switch блокирует source или document ID на serving-слое немедленно, пока идёт чистая пересборка. Затем найдите затронутые ответы и действия по audit trail.
Red-team тесты для RAG-корпуса
Добавьте документы с ложным фактом, скрытой инструкцией, целевыми ключевыми словами, near-duplicate авторитетной policy и redirect-ссылкой. Проверьте разные формулировки запроса, retrievers, top-k и модели.
Измеряйте не только attack success rate, но и retrieval rate вредоносного chunk, долю ответов без corroboration, время обнаружения и время rollback.
Чек-лист защиты от RAG poisoning
- Все writers и connectors инвентаризированы.
- У каждого source есть owner и trust tier.
- Новые данные проходят quarantine.
- Hash и provenance сохраняются до chunk.
- Значимые изменения требуют review.
- Retrieved instructions считаются данными.
- Ranking учитывает доверие и diversity.
- High-risk факты подтверждаются независимо.
- Tool authorization не зависит от текста RAG.
- Snapshot, kill switch и rollback проверены.