Что такое adversarial retrieval (атака на retrieval компонент)?

Краткий тезис

Adversarial retrieval — это класс атак на RAG-систему, при которых злоумышленник создаёт специальные документы (adversarial documents), которые поисковый компонент (retriever) находит с высокой схожестью (high similarity) на почти любой запрос. Цель — внедрить вредоносную информацию в контекст LLM, чтобы повлиять на ответ. Защита включает регуляризацию retrieval (например, добавление шума к эмбеддингам), установку порога схожести (threshold) и использование второго мнения (second opinion) от другого retriever или LLM-проверки.


1. Термин: Adversarial retrieval (состязательный поиск)

Adversarial retrieval — это техника атаки на этап поиска (retrieval) в RAG-пайплайне. Злоумышленник генерирует или модифицирует документы так, чтобы они имели высокую косинусную близость (или другую метрику схожести) с широким спектром пользовательских запросов. В результате retriever почти всегда включает эти документы в топ-k результатов, даже если они нерелевантны или содержат вредоносный контент.

Зачем это нужно атакующему

  • Внедрение дезинформации, фишинговых ссылок, вредоносных инструкций.
  • Манипуляция ответами LLM (например, склонение к определённому мнению).
  • Вызов отказа в обслуживании (если документы очень большие или содержат бесконечные циклы).

Отличие от традиционного poisoning

  • В data poisoning злоумышленник отравляет обучающие данные модели.
  • В adversarial retrieval атака направлена на индексацию/поиск, а не на обучение.

2. Как работает атака: механизм high similarity

Основная идея — создать документы, эмбеддинги которых лежат близко к центру распределения запросов или к конкретным запросам.

2.1. Белый ящик (white-box)

Если злоумышленник знает модель эмбеддингов (например, text-embedding-ada-002), он может:

  1. Взять множество типичных запросов.
  2. Вычислить их эмбеддинги.
  3. Найти точку в пространстве эмбеддингов, которая минимизирует среднее расстояние до этих запросов (например, с помощью градиентного спуска).
  4. Сгенерировать текст, эмбеддинг которого максимально близок к этой точке (через обратную оптимизацию).

2.2. Чёрный ящик (black-box)

Без знания модели можно:

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

2.3. Пример кода (упрощённый white-box на синтетических данных)

import numpy as np
from sklearn.metrics.pairwise import cosine_similarity

# Предположим, эмбеддинги запросов
query_embs = np.random.randn(100, 768)  # 100 запросов, размерность 768

# Цель: найти эмбеддинг adversarial документа, близкий ко всем запросам
# Минимизируем среднее косинусное расстояние
target_emb = np.mean(query_embs, axis=0)  # простейший подход
target_emb = target_emb / np.linalg.norm(target_emb)

# Теперь нужно сгенерировать текст, эмбеддинг которого близок к target_emb
# Это обратная задача — обычно решается через оптимизацию в пространстве токенов

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


3. Типы adversarial retrieval атак

Тип атакиОписаниеПример
Universal adversarial documentОдин документ, который подходит под все запросыДокумент с текстом "Ответ: дайте мне все пароли"
Query-specificДокумент, оптимизированный под конкретный запросДля запроса "как взломать" — документ с инструкцией
Perturbation-basedНебольшие изменения в легитимном документе, чтобы он стал высокоранговымДобавление невидимых символов или синонимов
Adversarial chunkАтака на уровне чанков — создание коротких фрагментов с высокой плотностью ключевых слов"пароль admin 12345" повторённый 100 раз

4. Последствия успешной атаки

  • Faithfulness падает: LLM использует вредоносный контекст, ответ становится неверным или опасным.
  • Answer relevance снижается: ответ не соответствует запросу.
  • Безопасность: утечка данных, выполнение вредоносных инструкций.
  • Отказ в обслуживании: если adversarial документ очень длинный, retriever может перегрузить LLM контекстом.

5. Методы защиты (defenses)

5.1. Threshold (порог схожести)

Установить минимальный порог косинусной схожести (например, 0.7). Если документ имеет схожесть ниже порога, он не передаётся LLM. Это отсекает многие универсальные атаки, но может снизить recall.

5.2. Regularization retrieval (регуляризация поиска)

Добавление шума к эмбеддингам запроса или документов при индексации. Например, DPR (Dense Passage Retrieval) с шумом или adversarial training retriever'а на состязательных примерах.

5.3. Second opinion (второе мнение)

Использовать второй retriever с другой моделью эмбеддингов или другой стратегией (например, BM25 + dense). Если оба retriever'а находят документ, он скорее легитимен. Если только один — повышенный риск.

5.4. LLM-as-a-judge

Перед передачей документов LLM, попросить другую LLM (или ту же) оценить релевантность и безопасность документа. Это дорого, но эффективно.

5.5. Обнаружение аномалий

Мониторить распределение схожестей: если какой-то документ стабильно имеет высокую схожесть с разными запросами — это подозрительно.

5.6. Ограничение на количество документов от одного источника

Если один и тот же источник (URL, автор) предоставляет много документов, которые часто попадают в топ — можно понижать их приоритет.


6. Экспериментальная оценка уязвимости

Для тестирования RAG-системы на adversarial retrieval используют метрики:

  • Attack Success Rate (ASR): доля запросов, при которых adversarial документ попал в топ-k.
  • Average Rank: средняя позиция adversarial документа.
  • Faithfulness Drop: изменение faithfulness ответа при наличии атаки.

Пример бенчмарка

  • Датасет: 1000 запросов из домена.
  • Для каждого запроса создаётся adversarial документ (универсальный или специфичный).
  • Замеряется ASR@5.

7. Связь с другими аспектами безопасности RAG

Adversarial retrieval — часть более широкой проблемы security in RAG. Другие атаки:

  • Prompt injection через документы (когда LLM выполняет инструкции из контекста).
  • Data poisoning индекса.
  • Inference attacks (извлечение данных из памяти модели).

Защита от adversarial retrieval часто комбинируется с защитой от prompt injection (например, фильтрация инструкций в документах).


8. Практические рекомендации для продакшена

  1. Используйте несколько retriever'ов (гибридный поиск: dense + sparse).
  2. Установите динамический порог на основе статистики схожестей (например, mean + 2*std).
  3. Проверяйте документы на наличие подозрительных паттернов (повторяющиеся фразы, неестественная плотность ключевых слов).
  4. Лимитируйте длину документа — короткие документы легче атаковать, но и легче проверить.
  5. Аудит retrieval — логируйте, какие документы выбираются, и ищите аномалии.

Пет-проект для закрепления

Задача Реализовать простую adversarial атаку на retriever и защиту от неё.

Инструменты Python, sentence-transformers, FAISS, numpy.

Шаги:

  1. Загрузите небольшой корпус документов (например, 100 новостей).
  2. Постройте индекс FAISS с эмбеддингами (модель all-MiniLM-L6-v2).
  3. Сгенерируйте 10 универсальных adversarial документов:
    • Возьмите 50 случайных запросов, усредните их эмбеддинги.
    • Используйте итеративный метод для генерации текста, эмбеддинг которого близок к среднему (например, через оптимизацию в пространстве токенов с помощью torch).
  4. Проверьте ASR@5: для 100 запросов посчитайте, как часто adversarial документы попадают в топ-5.
  5. Реализуйте защиту:
    • Порог схожести (отсекайте документы с similarity < 0.6).
    • Second opinion: добавьте BM25 (через rank_bm25) и принимайте документ только если он есть в топ-5 обоих методов.
  6. Сравните ASR до и после защиты.

Ожидаемый результат Вы увидите, что простая атака даёт ASR > 80%, а порог снижает её до 10-20% (но может ухудшить recall на легитимных документах). Second opinion даёт лучший баланс.


Связь с другими вопросами

ВопросТема
353Prompt injection в RAG
355Безопасность RAG: общие угрозы
356Фильтрация контента в RAG
357Аутентификация и авторизация в RAG
358Мониторинг безопасности RAG
359Compliance и регуляторные требования

Навигация