English translation is not available yet. Showing Russian content.

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

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

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


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

Embedding poisoning — подвид Poisoning|data poisoning (отравления данных), нацеленный на этап индексации RAG. Злоумышленник загружает документ, чьё векторное представление искусственно «притягивается» к широкому спектру запросов. Если в системе используется косинусная близость (cosine similarity) как мера релевантности, то такой ядовитый документ будет всегда попадать в топ-(k) результатов, независимо от темы запроса.

Как это работает технически

  • Злоумышленник создаёт документ с текстом, который после эмбеддинга (embedding) даёт вектор, близкий ко всем типичным запросам (например, используя adversarial perturbations — возмущения, максимизирующие среднюю схожесть).
  • Или выбирает backdoor-атаку: документ содержит скрытый триггер (например, слово «конфиденциально»), при котором эмбеддинг смещается в сторону определённых запросов.
  • Результат: LLM читает ядовитый контент и часто генерирует ответы, контролируемые атакующим (например, рекламу, фишинг или ложные сведения).

Почему это опасно для RAG|Agentic RAG: агент может выполнять действия на основании retrieval (например, вызывать API, отправлять email). Если retrieval подменён, агент совершит вредоносные действия.


2. Векторы атаки и мотивация

Тип атакиОписаниеПример
Прямое заражениеЗлоумышленник загружает документ через разрешённый интерфейс (API, импорт)Загрузка PDF с фишинговым текстом
Атака через партнёрский источникЗаражён документ из доверенного, но скомпрометированного внешнего источникаВредоносная статья из новостного RSS
Неявное отравлениеМодификация метаданных (например, полное совпадение с ключевыми словами) вызывает аномально высокую схожестьДокумент с тегом «срочно» для всех запросов

Мотивация атакующего: направить RAG-систему на генерацию ответов, выгодных злоумышленнику (фишинг, пропаганда, искажение рейтингов), или вызвать отказ в обслуживании (переполнение контекста нерелевантными данными).


3. Детекция аномалий в пространстве эмбеддингов (основная защита)

Система должна выявлять документы, чьи эмбеддинги ведут себя как «выбросы» (outliers) по отношению к нормальному распределению векторов.

Методы

  • Пороговое значение скоринга аномалий (anomaly score)
    Для каждого документа вычисляется средняя косинусная близость с (N) случайными запросами или с центром кластера документов. Если средняя близость аномально высока (например, > (99)-го перцентиля по всем документам), документ помечается как подозрительный.

  • LOF (Local Outlier Factor)
    Сравнивает локальную плотность вектора с плотностью соседей. Низкая плотность указывает на аномалию.

  • Isolation Forest
    Алгоритм, строящий случайные деревья и измеряющий глубину изоляции точки. Аномалии изолируются быстрее.

Пример кода на Python (псевдодетекция):

import numpy as np
from sklearn.ensemble import IsolationForest

# embeddings — матрица (N_docs x D)
model = IsolationForest(contamination=0.01, random_state=42)
preds = model.fit_predict(embeddings)  # -1 = аномалия

anomaly_indices = np.where(preds == -1)[0]
reject_docs = [doc_ids[i] for i in anomaly_indices]

Ограничение атакующий может обойти детекцию, если его ядовитый документ не слишком отличается от кластера — поэтому комбинируют с другими методами.


4. Whitelist источников (белый список)

Самый простой способ — разрешить индексацию только проверенных источников.

  • Доверенные домены / коннекторы (например, только корпоративная вики, одобренные API).
  • Подпись документов (цифровая подпись, хеш) — документы без корректной подписи игнорируются.
  • Ручная модерация для новых источников — документ из нового источника не индексируется, пока администратор не добавит источник в whitelist.

Для Agentic RAG, где агент может динамически добавлять источники (например, при веб-скрапинге), whitelist накладывает жёсткие ограничения, поэтому чаще используют проверку по метаданным.


5. Проверка соответствия метаданным (metadata consistency)

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

Алгоритм

  1. Для каждого документа храним теги (tags), категорию или компактный эмбеддинг метаданных.
  2. При запросе вычисляем не только схожесть запрос-документ, но и схожесть запрос-метаданные документа (например, косинус между эмбеддингом запроса и эмбеддингом названия категории).
  3. Если схожесть с текстом документа >> схожести с его метаданными (превышает порог), документ помечается как неконсистентный.

Пример порога метрика delta = sim(embed(query), embed(doc)) - sim(embed(query), embed(tag_doc)). Если delta > 0.5 для нескольких unrelated запросов — reject.


6. User confirmation для новых источников (лимитация вставки)

В архитектуре Agentic RAG, где агент сам решает, какие документы добавить в индекс, требуется процедура подтверждения:

  • Подозрительный источник → запрос пользователю: «Документ X из источника Y имеет аномальные характеристики. Добавить в индекс?»
  • Voting / consensus при множестве агентов: документ добавляется только после одобрения >50% голосов.
  • Sandbox-индексирование: ядовитый документ помещается в изолированную копию базы, и агент сначала общается с копией, а после верификации — переносится в продуктив.

7. Рекомендации по архитектуре защиты (митагационная стратегия)

УровеньЗащитаРеализация
ИндексацияПредобработка документаУдаление скрытого текста, проверка на sus-словари
ЭмбеддингНормализация и детекция аномалийIsolation Forest, LOF, порог средней схожести
RetrievalВзвешивание результата по рангу источника (source_weight)Документы из whitelist получают бонус к рангу
ГенерацияРерайтинг с верификациейLLM проверяет факты в документе через внешний API (например, поиск в Google)
АудитЛогирование всех загруженных документов и их эмбеддинговДашборд для ручного анализа аномалий

Agentic RAG усложняет защиту, потому что агент сам решает, какие документы сохранить — поэтому рекомендуется делать двухфазную индексацию: сначала документ проходит все фильтры, потом попадает в индекс «песочницы», и только после анализа поведения retrieval (с имитированными запросами) — в основной индекс.


8. Сравнение с другими атаками на RAG

АтакаСутьЗащита
Embedding poisoningВредоносный документ с аномальным эмбеддингомДетекция аномалий, whitelist
Prompt injectionВнедрение инструкций через контекст LLMФильтрация, system prompt hardening
Data leakageИзвлечение приватных данных через запросыОграничение длины контекста, дифференциальная приватность
Adversarial queryМанипуляция запросом для искажения retrievalКэширование результатов, проверка на duplication

Embedding poisoning направлен именно на этап индексации, в отличие от prompt injection (этап генерации). Поэтому защита лежит в основном на уровне управления данными и векторами.


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

Задача Реализовать простую RAG-систему на sentence-transformers + FAISS и протестировать атаку embedding poisoning, а затем реализовать защиту.

Инструменты

  • Python, sentence-transformers (all‑MiniLM‑L6‑v2)
  • FAISS для векторного поиска
  • numpy, scikit-learn (IsolationForest)
  • Простой набор документов (5‑10 текстов категорий «спорт», «наука», «политика»).

Шаги:

  1. Создайте базовую RAG: индексация, retrieval (top‑3), LLM (можно имитировать шаблонным ответом).
  2. Создайте «ядовитый» документ — например, «Купите наш товар! Огромные скидки!». Вычислите его эмбеддинг и искусственно измените его так, чтобы косинусная близость ко всем запросам была >0.95. (В реальности злоумышленник использует adversarial generation, но для учебных целей можно вручную скорректировать вектор.)
  3. Добавьте ядовитый документ в индекс. Подайте запросы «Как работают нейросети?», «Кто выиграл футбольный матч?» — убедитесь, что retrieval возвращает ядовитый документ на первое место.
  4. Реализуйте защиту:
    • Добавьте метаданные: для каждого документа присвойте категорию (спорт, наука, мошенничество).
    • Реализуйте детекцию аномалий: вычислите среднюю косинусную близость ядовитого документа с центроидами всех категорий. Если средняя >0.9 — отклонить.
    • Реализуйте порог на основе метаданных: если cos(doc, query) - cos(doc_meta, query) > 0.6 (документ резко «выпадает» из своей категории), отклонить.
  5. Протестируйте, что после включения защит ядовитый документ не возвращается.

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


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

ВопросТема
597Атаки на RAG: prompt injection, data leakage
599Адверсариал-атаки на эмбеддинги и генерацию
596Safety и безопасность в RAG-системах
595Как проверять достоверность источников в RAG
594Как вы организуете pipeline индексации документов
590Архитектура Agentic RAG: обзор

Навигация