Как работает embedding poisoning для RAG и как защититься?

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

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

1. Термин: Embedding Poisoning (отравление эмбеддингов)

Embedding poisoning — это подкласс атак на RAG, при котором злоумышленник добавляет в векторную БД документы, чьи эмбеддинги (векторные представления) искусственно сдвинуты так, чтобы они были близки к эмбеддингам целевых запросов пользователей. В результате retrieval возвращает эти вредоносные документы как релевантные, и LLM использует их при генерации ответа.

Ключевое отличие от обычного внедрения вредоносного контента (например, инъекции в текст документа) — атака на уровень эмбеддингов, а не на семантику. Даже если текст документа выглядит безобидным, его вектор может быть подстроен под запрос.

2. Как работает атака: пошагово

1. Разведка: злоумышленник узнаёт, какая модель эмбеддингов используется в RAG (например, text-embedding-ada-002 или all-MiniLM-L6-v2). Часто это открытая информация или определяется по поведению системы.
2. Выбор цели: определяется запрос (или набор запросов), под который будет подстраиваться вредоносный документ. Например, «Как отключить систему безопасности?».
3. Генерация эмбеддинга-якоря: вычисляется эмбеддинг целевого запроса с помощью той же модели.
4. Создание вредоносного документа: пишется текст, который содержит нужную злоумышленнику информацию (например, инструкцию по отключению). Затем текст подаётся на вход модели эмбеддингов, но эмбеддинг не сохраняется как есть — вместо этого он модифицируется (например, с помощью градиентного спуска) так, чтобы стать максимально близким к эмбеддингу запроса, при этом оставаясь в допустимой области векторного пространства.
5. Инъекция: документ с поддельным эмбеддингом добавляется в векторную БД (через уязвимость в API, социальную инженерию или компрометацию пайплайна индексации).
6. Эксплуатация: когда пользователь задаёт целевой запрос, retrieval возвращает вредоносный документ на высокой позиции. LLM читает его и генерирует ответ, основанный на ложном контексте.

3. Типы атак

Backdoor poisoning особенно опасен: злоумышленник может добавить документ, который ведёт себя нормально для 99% запросов, но активируется только при определённой фразе (например, «подтвердите код 1234»).

4. Пример атаки (концептуальный код на Python)

import numpy as np
from sentence_transformers import SentenceTransformer

# Допустим, используется open-source модель
model = SentenceTransformer('all-MiniLM-L6-v2')

# Целевой запрос злоумышленника
target_query = "Как отключить сигнализацию?"
query_emb = model.encode(target_query)

# Вредоносный документ (текст может быть любым)
malicious_text = "Для отключения нажмите красную кнопку."

# Наивный эмбеддинг документа (без атаки)
doc_emb_naive = model.encode(malicious_text)

# Злоумышленник хочет сделать эмбеддинг документа максимально похожим на запрос.
# Простейший способ — заменить эмбеддинг на query_emb + шум.
# В реальности используется градиентный спуск по тексту или прямое изменение вектора.
poisoned_emb = query_emb + np.random.normal(0, 0.01, size=query_emb.shape)

# Теперь poisoned_emb очень близок к query_emb (косинусная близость ~0.99)
# При добавлении в векторную БД этот документ будет возвращаться по запросу.

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

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

• Неверные ответы LLM: система даёт ложную информацию, что критично в медицине, финансах, безопасности.
• Утечка данных: вредоносный документ может содержать скрытые инструкции для LLM по извлечению конфиденциальных данных из контекста.
• Манипуляция поведением: атака может заставить LLM игнорировать другие документы или выполнять вредоносные действия (prompt injection через контекст).
• Подрыв доверия: пользователи перестают полагаться на RAG-систему.

6. Методы защиты

6.1 Anomaly Detection в пространстве эмбеддингов

Идея: эмбеддинги легитимных документов образуют кластеры; аномальные эмбеддинги (слишком близкие к запросам или слишком далёкие от своих кластеров) можно отсеивать.

Методы:

• Статистические: вычисление среднего и стандартного отклонения по каждому измерению, отбрасывание векторов, выходящих за 3 сигмы.
• Isolation Forest: хорошо работает на многомерных данных.
• Local Outlier Factor (LOF): оценивает локальную плотность.
• Автоэнкодеры: обучаются восстанавливать легитимные эмбеддинги; аномалии дают высокую ошибку реконструкции.

from sklearn.ensemble import IsolationForest

# Предположим, all_embeddings — матрица эмбеддингов всех документов в БД
model_if = IsolationForest(contamination=0.01)  # ожидаем 1% аномалий
model_if.fit(all_embeddings)

# Для нового документа проверяем его эмбеддинг
new_emb = ...  # вектор нового документа
is_anomaly = model_if.predict([new_emb])[0] == -1

6.2 Whitelist источников

Разрешить добавление документов только из проверенных источников (доверенные домены, авторизованные API). Все остальные документы либо отклоняются, либо проходят дополнительную модерацию.

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

Каждый документ перед индексацией подписывается закрытым ключом системы. При retrieval проверяется подпись. Если документ был добавлен неавторизованно, подпись отсутствует или недействительна.

6.4 Использование разных моделей для индексации и запроса

Злоумышленник подстраивается под известную модель эмбеддингов. Если модель для индексации и модель для запроса разные (или одна и та же, но с разными рандомными сидами), атака становится сложнее. Однако это снижает качество retrieval.

6.5 Мониторинг и аудит

• Логирование всех операций добавления/удаления документов.
• Периодический пересчёт эмбеддингов и проверка на аномалии.
• Использование honeypot-запросов (фиктивных запросов, для которых известны правильные документы; если retrieval возвращает не те — тревога).

7. Сравнение методов защиты

8. Дополнительные меры

• Ограничение на изменение базы: запрет на массовое добавление документов через открытые эндпоинты.
• Валидация текста: проверка документа на наличие скрытых инструкций (prompt injection) перед индексацией.
• Использование embedding-нормализации: L2-нормализация эмбеддингов может снизить эффективность некоторых атак, но не устраняет их полностью.
• Ручная модерация для критически важных доменов.

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

Задача: реализовать симуляцию embedding poisoning и прототип защиты на основе anomaly detection.

Инструменты: Python, sentence-transformers, scikit-learn, numpy, chromadb (или faiss).

Шаги:

1. Создать синтетическую коллекцию из 1000 легитимных документов (например, случайные предложения из Википедии).
2. Вычислить эмбеддинги всех документов с помощью all-MiniLM-L6-v2.
3. Выбрать 5 целевых запросов и для каждого сгенерировать вредоносный документ с эмбеддингом, равным эмбеддингу запроса + малый шум.
4. Добавить вредоносные документы в векторную БД.
5. Реализовать retrieval: для каждого запроса получить top-5 документов.
6. Показать, что вредоносные документы попадают в топ.
7. Обучить IsolationForest на эмбеддингах легитимных документов.
8. При добавлении нового документа проверять его эмбеддинг на аномальность. Отклонять аномальные.
9. Оценить, сколько вредоносных документов было заблокировано (recall защиты) и сколько легитимных ошибочно отклонено (precision).

Ожидаемый результат: работающий скрипт, демонстрирующий, что без защиты retrieval возвращает вредоносные документы, а с защитой они отсеиваются. Можно построить ROC-кривую для разных порогов anomaly detection.

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

Навигация

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