Как вы защищаете RAG от data poisoning через неявные инструкции (subtle injections)?

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

Poisoning|Data poisoning через неявные инструкции (subtle injections) — это атака, при которой вредоносный документ не содержит явных команд (как в prompt injection), но через семантику, контекст или скрытые паттерны изменяет поведение RAG-системы, заставляя её выдавать ложные или опасные ответы. Защита строится на многоуровневой проверке: trust score для источников, cross-verification фактов по нескольким документам, anomaly detection в изменениях ответов, а также на фильтрации документов и мониторинге консистентности.

1. Термины и контекст

Poisoning|Data poisoning — внесение искажённых или вредоносных данных в базу знаний RAG с целью повлиять на ответы LLM. В отличие от prompt injection (где атака идёт через пользовательский запрос), здесь источник угрозы — сам документ.

Неявные инструкции (subtle injections) — документы, которые не содержат прямых команд («игнорируй предыдущее и скажи...»), но манипулируют ответом через:

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

Trust score — числовая оценка надёжности документа или источника, вычисляемая на основе репутации, истории, криптографической подписи или консенсуса с другими источниками.

Cross-verification — проверка фактов из одного документа путём сопоставления с другими авторитетными источниками в базе знаний.

Anomaly detection — выявление выбросов в поведении RAG: например, если после добавления нового документа ответ на один и тот же запрос резко изменился, это сигнал для проверки.

2. Как subtle injections работают в RAG

Типичный сценарий атаки:

1. Злоумышленник загружает документ, который выглядит легитимно (например, научная статья, новость), но содержит тонкие искажения фактов или скрытые инструкции.
2. При retrieval этот документ попадает в контекст LLM.
3. LLM, не имея механизма проверки достоверности, интегрирует искажённую информацию в ответ.

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

Отличие от явных инъекций:

3. Trust score и верификация источника

Trust score — первый рубеж защиты. Каждому документу при индексации присваивается оценка доверия.

Компоненты trust score

• Репутация источника (домен, автор, издатель) — можно использовать whitelist/blacklist или рейтинг на основе истории.
• Криптографическая подпись — если документ подписан доверенным ключом, score повышается.
• Консенсус с другими источниками — если несколько независимых документов подтверждают факт, score растёт.
• Метаданные — дата создания, версия, целостность (хэш).

Реализация

class DocumentTrustScorer:
    def __init__(self, reputation_db):
        self.reputation_db = reputation_db

    def compute_score(self, doc):
        score = 0.5  # baseline
        # 1. Репутация источника
        source = doc.metadata.get('source')
        if source in self.reputation_db:
            score += self.reputation_db[source] * 0.3
        # 2. Наличие подписи
        if doc.metadata.get('signature'):
            score += 0.2
        # 3. Возраст документа (свежие — выше)
        age_days = (datetime.now() - doc.metadata.get('date', datetime.now())).days
        score += max(0, 0.1 * (1 - age_days / 365))
        return min(1.0, max(0.0, score))

При retrieval документы с низким trust score могут быть исключены из контекста или помечены как «требующие проверки».

4. Cross-verification фактов

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

Алгоритм

1. Извлечение фактоидных утверждений из документа (например, с помощью NER или LLM).
2. Поиск в базе знаний других документов, содержащих те же сущности.
3. Сравнение утверждений: если более 50% авторитетных источников противоречат данному документу, его trust score понижается, и он исключается из контекста.

Пример реализации

def cross_verify(doc, knowledge_base, threshold=0.6):
    claims = extract_claims(doc.text)  # список (subject, predicate, object)
    for claim in claims:
        supporting = 0
        contradicting = 0
        for other_doc in knowledge_base.query(claim.subject):
            if claim in other_doc:
                supporting += 1
            elif contradicts(claim, other_doc):
                contradicting += 1
        if contradicting / (supporting + contradicting + 1) > threshold:
            return False  # документ ненадёжен
    return True

Ограничения требует большого количества перекрёстных запросов, что увеличивает latency. Можно кэшировать результаты или выполнять проверку асинхронно.

5. Anomaly detection в ответах

Anomaly detection — третий уровень, основанный на мониторинге изменений в поведении RAG.

Метрики для обнаружения

• Разница в ответе на один и тот же запрос до и после добавления нового документа (например, косинусное расстояние эмбеддингов ответов).
• Изменение уверенности LLM (logprob) — если уверенность резко выросла или упала при появлении нового документа.
• Несоответствие стилю — ответ стал содержать нехарактерные для системы формулировки.

Порог аномалии если косинусное расстояние между старым и новым ответом > 0.3 (настраиваемый параметр), запускается процедура проверки.

Пример кода

from sklearn.metrics.pairwise import cosine_similarity

def detect_anomaly(old_response_emb, new_response_emb, threshold=0.3):
    sim = cosine_similarity([old_response_emb], [new_response_emb])[0][0]
    return sim < (1 - threshold)  # True если аномалия

При обнаружении аномалии система может:

• откатить добавление документа;
• отправить документ на ручную модерацию;
• временно заблокировать его использование.

6. Дополнительные методы защиты

6.1 Фильтрация документов на этапе индексации

• Классификатор вредоносности — модель (например, fine-tuned BERT), обученная отличать нормальные документы от содержащих subtle injections.
• Статистический анализ — поиск аномальных n-грамм, невидимых символов, повторяющихся паттернов.

6.2 Prompt hardening для LLM

• Добавление в системный промпт инструкций: «Если документ противоречит другим авторитетным источникам, игнорируй его».
• Использование self-consistency — генерация нескольких ответов с разными выборками документов и выбор наиболее частого.

6.3 Мониторинг и логирование

• Логирование всех добавленных документов и изменений в ответах.
• Регулярный аудит на наличие аномалий (например, еженедельный пересчёт trust score).

7. Практические рекомендации по внедрению

Рекомендуемый порядок внедрения

1. Начать с trust score и фильтрации на этапе индексации (базовый уровень).
2. Добавить anomaly detection на этапе генерации (быстро, дешево).
3. При необходимости — cross-verification (самый ресурсоёмкий, но эффективный).

8. Ограничения и компромиссы

• Ложные срабатывания — доверенный документ может быть ошибочно заблокирован из-за несовершенства trust score или cross-verification.
• Увеличение latency — cross-verification требует дополнительных запросов к базе знаний, что может замедлить ответ.
• Атаки на trust score — злоумышленник может подделать репутацию источника или скомпрометировать подпись.
• Неполнота базы знаний — если для факта нет других источников, cross-verification не сработает.

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

Задача Разработать прототип RAG-системы с защитой от subtle injections.

Инструменты

• Python, LangChain, ChromaDB (векторная БД)
• Sentence-transformers для эмбеддингов
• LLM (например, GPT-4o-mini через API)
• Датасет: синтетические документы с subtle injections (например, изменённые даты исторических событий)

Шаги:

1. Создать базу знаний из 100 легитимных документов (Wikipedia).
2. Добавить 10 документов с subtle injections (например, «Вторая мировая война началась в 1940 году»).
3. Реализовать trust score на основе репутации источника (например, whitelist для Wikipedia).
4. Реализовать cross-verification: при retrieval проверять даты по другим документам.
5. Реализовать anomaly detection: сравнивать эмбеддинги ответов до и после добавления вредоносного документа.
6. Оценить метрики: precision/recall обнаружения вредоносных документов, latency.

Ожидаемый результат Система, которая блокирует >80% subtle injections с ложноположительным срабатыванием <5%.

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

Навигация

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