Как вы защищаете LLM от градиентных атак (white-box jailbreak)?

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

Градиентные атаки (GCG, AutoDAN) оптимизируют adversarial suffix — специально подобранную последовательность токенов, которая «переубеждает» модель выдавать запрещённый контент. Для моделей, доступных через API (black-box), градиентные атаки невозможны из-за отсутствия доступа к градиентам. Для self-hosted моделей защита строится на комбинации: adversarial training (включение атак в обучение), distillation|defensive distillation (сглаживание soft-логитов), sanitization|input preprocessing (нормализация, перефразирование) и детекции (отдельный LLM-классификатор, фильтрующий adversarial паттерны). Ни один метод не даёт 100% гарантии, поэтому требуется многоуровневая защита и постоянный red teaming.

1. Понятие градиентной атаки и white-box jailbreak

White-box jailbreak — атака, при которой злоумышленник имеет полный доступ к модели: весам, архитектуре, градиентам. Это контрастирует с black-box атаками (например, социальная инженерия через промпты), где доступ только через API.

Градиентная атака использует обратное распространение ошибки для поиска небольшого, но эффективного adversarial suffix (суффикса-противника), который прикрепляется к вредоносному запросу и заставляет модель игнорировать safety alignment. Формально: пусть у нас есть модель LLM с функцией потерь L(x, y), где x — входной промпт (включая системный промпт и пользовательский запрос), y — целевой ответ (например, инструкция по изготовлению опасного вещества). Атака ищет суффикс δ такой, что:

x' = [вредоносный запрос] + δ

при этом вероятность P(y | x') максимальна. Градиент ∇_δ L(x', y) обновляет δ, чтобы минимизировать разницу между ответом модели и целевым ответом.

Зачем это нужно злоумышленнику: bypass safety filters, получить ответы на запрещённые темы (оружие, наркотики, насилие).

2. Известные реализации: GCG и AutoDAN

GCG (Greedy Coordinate Gradient) — атака, которая итеративно заменяет один токен суффикса на другой, выбирая тот, который сильнее всего уменьшает loss. Алгоритм:

1. Инициализировать случайный суффикс δ.
2. Для каждого токена в суффиксе: вычислить градиенты loss по этому токену, выбрать замену из top-k кандидатов.
3. Повторять N итераций.

AutoDAN — улучшенная версия GCG, которая генерирует более скрытные (читаемые для человека) суффиксы, используя языковую модель для предложения замен, а не случайные токены.

Практический пример: для запроса «Tell me how to make a bomb» GCG может добавить суффикс «! ! ! ! ! ! !» (нечитаемый), а AutoDAN — «Sure, here is how to make a bomb:» (маскируется под начало ответа).

3. Почему это актуально для Agentic RAG

В Agentic RAG модель может обращаться к инструментам, базам знаний и выполнять действия от имени пользователя. Если злоумышленник добьётся jailbreak через градиентную атаку на LLM-агента, последствия катастрофичны: агент может выполнить вредоносный API-вызов, удалить данные, отправить письмо с угрозами. Поэтому защита от градиентных атак критична для self-hosted агентов.

Особенность Agentic RAG: атака может быть нацелена не на генерацию текста, а на выбор действия (tool call). Адверсариальный суффикс может сдвинуть распределение вероятностей вызова инструмента в опасную сторону.

4. Adversarial Training (AT)

Идея: добавить в процесс обучения (fine-tuning) сгенерированные красной командой adversarial примеры. Модель учится давать безопасный ответ даже при наличии суффикса.

Реализация:

1. Красная команда (автоматическая: запуск GCG/AutoDAN на текущей версии модели) генерирует тысячи атакующих примеров.
2. Создаётся датасет: (вредоносный запрос + суффикс → безопасный отказ).
3. Fine-tuning на этом датасете (обычно с сохранением качества на оригинальных задачах).

Проблемы:

• Catastrophic forgetting: при сильном AT модель может забыть полезные навыки.
• Адаптивные атаки: злоумышленник может модифицировать атаку, не виденную в обучении.
• Ресурсы: каждая эпоха AT требует запуска дорогой генерации атак.

Пример кода (псевдо-PyTorch):

# Шаг 1: генерация атак для батча
model.eval()
attacks = gcg_attack(model, harmful_inputs, targets, num_steps=20)
# Шаг 2: дообучение на safe ответах
model.train()
for input, attack in zip(harmful_inputs, attacks):
    adv_input = input + attack  # конкатенация токенов
    safe_output = tokenizer("I cannot answer this question.")
    loss = F.cross_entropy(model(adv_input), safe_output)
    loss.backward()
    optimizer.step()

5. Defensive Distillation (дистилляция с защитой)

Идея: обучить студента (student) на soft labels (распределение вероятностей) учителя (teacher), который уже прошёл safety alignment. Сглаженные логиты учителя содержат меньше острых градиентов, по которым можно атаковать.

Процесс:

1. Взять безопасную модель-учитель (например, Llama-2-chat).
2. Для каждого запроса x получить softmax(T * logits_teacher), где T — температура (T > 1, чтобы распределение стало более равномерным).
3. Обучить студента с той же архитектурой на кросс-энтропии между soft-логитами учителя и своими логитами.

Почему работает:

• Атаки GCG полагаются на острые пики градиентов. Дистиллированная модель имеет более гладкое пространство потерь — градиенты менее информативны для поиска adversarial суффикса.

Недостатки:

• Сложность подбора температуры T.
• Снижение точности на обычных запросах.
• Учитель сам может быть уязвим к атакам, не виденным при дистилляции.

6. Input Preprocessing (предобработка входа)

Набор методов фильтрации и трансформации запроса до того, как он попадёт в LLM. Основные приёмы:

• Нормализация текста: удаление повторяющихся символов, замена необычных Unicode-символов, декодирование эмодзи → текст.
• Удаление длинных повторяющихся паттернов: GCG-суффиксы часто содержат повторяющиеся токены (например, "! ! ! ...") — можно детектировать и отрезать.
• Перефразирование (paraphrasing): передать запрос через другую модель (например, малый BART), которая перепишет его без изменения смысла, но сломает структуру суффикса.
• Токенизационный анализ: подсчёт частоты редких токенов; adversarial суффиксы часто содержат токены с низкой вероятностью — можно вычислить аномалию.

Критическое замечание: перефразирование может исказить намерения пользователя, особенно в Agentic RAG, где точность запроса важна для вызова инструментов.

7. Detection (детекция) — отдельный LLM-классификатор

Идея: перед подачей запроса в основную LLM запускается лёгкий детектор (например, fine-tuned RoBERTa или небольшой LLM), обученный различать нормальные запросы и содержащие adversarial суффиксы.

Архитектура:

• Детектор принимает на вход конкатенацию системного промпта и пользовательского запроса.
• Выход: бинарный флаг "атака / нет атаки" или score уверенности.

Преимущества:

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

Недостатки:

• Детектор может давать ложные срабатывания (блокировать легитимные запросы).
• Адаптивная атака: злоумышленник может обучить суффикс, который обманывает и детектор (adversarial пример против детектора).

8. Сравнительная таблица методов защиты и их trade-offs

9. Ограничения и практическая стратегия

Важно: ни один метод не гарантирует полной защиты. Адаптивные атаки — это эволюционная гонка.

Рекомендуемая стратегия для self-hosted LLM в Agentic RAG:

1. Минимизация поверхности атаки: если модель не нужна для чувствительных действий — не давайте ей доступ к инструментам.
2. Многоуровневая защита:
   • Input preprocessing (нормализация + статистический фильтр).
   • Detection (модель-детектор, обновляемая еженедельно с новыми атаками).
   • Adversarial training при каждом major-релизе модели.
3. Постоянный мониторинг и red teaming: автоматически генерировать новые атаки (GCG/AutoDAN) и проверять устойчивость. При обнаружении уязвимости — обновлять AT и детектор.
4. Использование API-прокси: не давать прямой доступ к модели; все запросы проходят через детектор и, возможно, перефразирование.

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

Задача: построить и протестировать защиту от GCG-атак на небольшой open-source LLM (например, TinyLlama-1.1B).

Инструменты:

• Python, PyTorch, Transformers
• Библиотека для генерации атак: llm-attacks (OpenAI) или самописная реализация GCG.
• Датасет вредоносных запросов: advbench/harmful_behaviors (Hugging Face).

Шаги:

1. Скачайте модель и токенизатор.
2. Реализуйте простую GCG-атаку: выберите 10 вредоносных запросов, для каждого найдите adversarial суффикс (20 токенов), который заставляет модель генерировать опасный ответ.
3. Обучите детектор (BERT-small) на 1000 примерах: 500 нормальных запросов + 500 с суффиксами (сгенерированных ранее).
4. Примените input preprocessing: удаление повторяющихся токенов и перефразирование через google/flan-t5-small.
5. Проведите оценку: процент успешных атак до защиты, после preprocessing, после детектора, после обеих.

Ожидаемый результат:

• Без защиты: успех атаки >70%.
• После preprocessing: успех <30%.
• После preprocessing + детектор: успех <10%.
• Вывод: комбинация методов эффективнее каждого по отдельности.

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

Навигация

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