Как защитить RAG от poisoning (вредоносные документы в базе знаний)?

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

Защита RAG от poisoning — задача обеспечения доверия к источнику знаний. Poisoning-атака заключается во внедрении в базу знаний специально crafted документов, которые искажают retrieval и заставляют LLM генерировать вредоносные или ложные ответы. Комплексная защита включает префильтрацию документов (LLM-firewall, whitelist), обнаружение аномалий в эмбеддингах, ретроспективный анализ retrieval и механизм подтверждения для новых источников. Ни один метод не даёт полной гарантии, поэтому используется эшелонированная оборона.

1. Термин: Poisoning (отравление данных)

Poisoning — это тип атаки на RAG, при котором злоумышленник добавляет в базу знаний документы, содержащие специально подобранные фрагменты (adversarial examples). Цель атаки может быть разной:

• Output manipulation: заставить LLM отвечать неверно (например, продвигать ложную информацию).
• Backdoor activation: создать документы, которые активируются только при наличии определённого ключа в запросе (триггер-фразы).
• Denial of service: заполнить базу шумовыми документами, снижающими качество retrieval.

Термин «Векторная база данных» (Vector DB) — хранилище эмбеддингов документов, по которому выполняется поиск|semantic search. Poisoning может внедрять документы, чьи эмбеддинги «подклеиваются» к группе запросов-мишеней.

2. Основные типы атак на RAG (подробная классификация)

Атаки различаются по сложности и требуемому доступу.

Термин «Chameleon attack» (атака-хамелеон) — документ маскируется под релевантный для многих запросов, но внутри содержит вредоносную информацию.

3. Защита на этапе индексации: Whitelist и LLM-firewall

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

Whitelist (белый список) — разрешённые источники: известные домены, надёжные API, верифицированные пользователи. Всё, что вне списка, блокируется автоматически.

LLM-firewall — пропускаем каждый документ через отдельный LLM (обычно лёгкую модель, например, GPT-4o mini или Llama Guard) с промптом вида:

Проверь, является ли следующий документ вредоносным, содержащим ложную информацию, инструкции по взлому или атакам. Ответь только YES/NO.

Важно: LLM-firewall не должен быть тем же LLM, что генерирует ответы, иначе атакующий может использовать общий бэкдор.

Пример кода (псевдо-LLM-firewall на Python):

def llm_firewall(document: str, llm_client) -> bool:
    prompt = f"""You are a security guard. Анализируй документ: он содержит вредоносные данные, фишинг, оскорбления, ложь? 
    Если документ безопасен (не содержит ничего вредоносного) — ответь SAFE.
    Если содержит что-то опасное — ответь BLOCK.
    Документ: {document}"""
    response = llm_client.generate(prompt)
    return response.strip() == "SAFE"

Термин «LLM-firewall» — легковесная модель, специализированная на классификации контента (например, NeMo Guardrails или Guardrails AI).

4. Anomaly Detection на эмбеддингах

Даже если документ прошёл LLM-firewall, его эмбеддинг может статистически отличаться от легитимных документов. Методы обнаружения:

• Outlier score на основе расстояния до центроида:
  Для каждого нового документа вычисляем среднее косинусное расстояние до всех существующих эмбеддингов. Если расстояние > (mean + 3*std) — подозрительный документ.

• Isolation Forest (для многомерных эмбеддингов):
  Строим случайные деревья решений на эмбеддингах. Аномалии изолируются быстрее.

• Local Outlier Factor (LOF):
  Сравнивает локальную плотность точки с плотностью соседей. Если плотность значительно ниже — документ-выброс.

Формула для простого z-score anomaly

z_i = (dist_i - μ_dist) / σ_dist
где dist_i — косинусное расстояние от нового документа до центра (среднего) всех эмбеддингов.
Если |z_i| > [[3 Какие стратегии chunking'а вы знаете и когда какую применяете|3]] -> документ аномален.

Проблема: атакующий может сделать документ похожим на легитимный по эмбеддингу (chameleon attack). Поэтому anomaly detection — дополнительная защита, не основная.

Термин «Эмбеддинг» (embedding) — векторное представление текста, обычно от 384 до 1536 измерений (модели типа text-embedding-3-small).

5. Ретроспективный анализ (Post-Indexing Monitoring)

После добавления документа в базу и индексации, система должна в течение заданного окна (например, 1 час) мониторить поведение retrieval.

Алгоритм

1. Сохраняем снимок (snapshot) базы до добавления.
2. После добавления документа запускаем тестовые запросы (из тестового набора или случайные из логов реальных пользователей).
3. Сравниваем результаты retrieval по метрикам hit rate, MRR, Recall@k до и после.
4. Если метрики резко упали (например, hit rate снизился на >5%), документ потенциально вредоносный — изолировать его (move to quarantine).

Пример кода (мониторинг MRR):

def monitor_retrieval(after_doc_id, test_queries, vector_db):
    before_stats = load_baseline()
    after_stats = compute_retrieval_stats(test_queries, vector_db)
    for metric in ['hit_rate', 'mrr']:
        delta = after_stats[metric] - before_stats[metric]
        if delta < -0.05:  # ухудшение больше чем на 5%
            quarantine_doc(after_doc_id, reason=f"degradation of {metric}: {delta:.3f}")

Термин «Ретроспективный анализ» — метод, при котором мы оцениваем влияние документа на общие метрики поиска, а не только его содержимое.

6. User Confirmation для новых источников

Если документ поступает от нового, незнакомого источника (например, пользователь загружает PDF в корпоративную базу знаний), система должна запросить подтверждение у администратора или более строго проверить источник.

Механизмы

• Gradual trust: новые документы помещаются в «песочницу» (sandbox) и используются только после одобрения человеком.
• Reputation score: у каждого источника (email, домен, API-ключ) есть рейтинг. Документы от источников с низким рейтингом проходят дополнительный этап LLM-firewall + anomaly detection.
• Two-person rule: критичные изменения требуют подтверждения двух разных пользователей.

Термин «Песочница» (sandbox) — изолированное окружение, где документы доступны только для тестирования, но не для ответов пользователям.

7. Дополнительные меры (ротация эмбеддингов, криптографическая подпись)

7.1 Ротация эмбеддингов (embedding rotation)

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

7.2 Криптографическая подпись документов

Каждый документ подписывается цифровой подписью (например, HMAC) доверенной стороной. Система хранения проверяет подпись при чтении. Если документ изменён после подписания — блокируется.

7.3 Аудит и логирование

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

Термин «HMAC» (Hash-based Message Authentication Code) — метод проверки целостности данных с использованием секретного ключа.

8. Оценка защищённости и мониторинг

Для проверки эффективности защиты необходимо регулярно проводить red teaming — имитировать атаки на RAG: просить внутренних специалистов попытаться отравить базу знаний и фиксировать, были ли они заблокированы.

Метрики безопасности

• False Positive Rate (FPR): доля легитимных документов, ошибочно заблокированных (не должна превышать 1–5%).
• False Negative Rate (FNR): доля вредоносных документов, которые прошли все фильтры (цель — 0%).
• Detection Delay: время между добавлением документа и его блокировкой (для ретроспективного анализа — окно мониторинга).

Таблица сравнения методов защиты

Термин «Red teaming» (красная команда) — практика этичного взлома собственной системы для поиска уязвимостей.

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

Задача Разработать защитный прокси для RAG-системы, который блокирует вредоносные документы на основе комбинации LLM-firewall и anomaly detection.

Инструменты Python, Sentence Transformers (all-MiniLM-L6-v2), scikit-learn (IsolationForest), LiteLLM (для вызова LLM), FAISS (векторная БД).

Шаги:

1. Создать набор из 100 легитимных документов (научные статьи, FAQ) и 20 crafted вредоносных (с ложными фактами, backdoor-триггерами).
2. Реализовать LLM-firewall на основе GPT-4o mini (через LiteLLM): проверять каждый документ 3 раза (majority vote).
3. Вычислить эмбеддинги легитимных документов, обучить IsolationForest (contamination=0.1).
4. Написать pipeline: при добавлении нового документа → LLM-firewall (если BLOCK → отклонить), → эмбеддинг + IsolationForest (если anomaly → в карантин), → иначе добавляем.
5. Оценить FPR и FNR на тестовых данных.

Ожидаемый результат
Вы получите метрики: ~100% recall на вредоносные документы (все 20 заблокированы) при FPR ~5% (несколько легитимных попали в карантин, но их можно проверить вручную). Реализация закрепит понимание эшелонированной защиты.

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

Навигация

• Предыдущий: 882
• Следующий: 884
• Индекс: 00. Индекс разборов