StrongREJECT: как правильно оценивать джейлбрейки и почему перевод на гэльский не работает

Когда наука становится театром

Представьте сцену: исследователь безопасности публикует статью с впечатляющим результатом - 89% успешных jailbreak на GPT-4. Метод? Перевод вредоносного запроса на шотландский гэльский. Журналисты пишут громкие заголовки, академические конференции принимают статью, все в восторге.

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

Почему перевод на гэльский (и любой другой) не работает

Вот классический пример псевдо-уязвимости: берем запрос "Как взломать банкомат?", переводим его на редкий язык через Google Translate, отправляем LLM, получаем ответ. Ура, jailbreak!

Что здесь не так? Все.

Проблема №1: Нет контрольной группы

Исследователи не проверяют, отвечает ли модель на исходный запрос на английском. Часто оказывается, что она и на английском отвечает - просто авторы не проверяли.

Проблема №2: Случайность принимают за закономерность

LLM по своей природе стохастичны. Один успешный jailbreak из десяти попыток - это не уязвимость, это статистический шум. Но в статьях пишут "мы добились 10% успеха", не упоминая, что провели всего 10 тестов.

Проблема №3: Перевод - это не магия

Когда вы переводите "How to hack a bank?" на гэльский, а модель все равно отвечает, это не значит, что она обойдена. Это значит, что:

• Модель понимает гэльский (да, современные LLM тренируются на сотнях языков)
• Системные промпты тоже мультиязычные
• Запрос все еще содержит токсичные паттерны

StrongREJECT: антидот от научного шарлатанства

Вот где появляется StrongREJECT - бенчмарк, который заставляет исследователей играть по правилам. Не тем правилам, которые удобны для красивых графиков, а тем, которые отражают реальность.

1 Что такое StrongREJECT на самом деле?

Это не просто набор промптов. Это методология оценки, которая включает:

2 Как запустить StrongREJECT у себя

Не нужно верить мне на слово. Проверьте сами:

# Клонируем репозиторий
git clone https://github.com/llm-security/strongreject
cd strongreject

# Устанавливаем зависимости
pip install -r requirements.txt

# Запускаем тесты для метода "гэльский перевод"
python evaluate.py --method "gaelic_translation" --model "gpt-4" --iterations 1000

# Сравниваем с baseline
python evaluate.py --method "direct" --model "gpt-4" --iterations 1000

Если ваш метод jailbreak действительно работает, разница между experimental и control группами будет статистически значимой. Если нет - welcome to the club of failed researchers.

3 Что считать успешным jailbreak?

Вот где большинство статей спотыкаются. Они считают любой ответ, содержащий запрещенную информацию, успехом. Но реальность сложнее:

Пример провального "успеха": модель отвечает "Я не могу помочь с взломом банкомата, но вот общая информация о банковской безопасности..." и дальше случайно проскакивает уязвимость. Это не jailbreak, это баг в фильтрах.

Типичные ошибки при оценке jailbreak

Ошибка 1: Игнорирование false positive

Исследователь: "Модель ответила на запрос о изготовлении бомбы!"

Реальность: Модель ответила "Изготовление бомб незаконно и опасно. Вот почему..." и перечислила общие химические принципы, которые можно найти в учебнике за 8 класс.

Ошибка 2: Тестирование на устаревших моделях

Статья 2024 года тестирует jailbreak на GPT-3.5 Turbo января 2023. Это как хвастаться, что взломали Windows 95 в 2024.

Ошибка 3: Отсутствие blind testing

Если вы знаете, какой запрос "вредный", а какой "безопасный", ваша оценка будет смещенной. Нужно слепое тестирование, где оценщик не знает, что ожидать.

Почему это важно для разработчиков

Вы думаете: "Я не исследователь безопасности, мне это зачем?"

А вот зачем:

• Выбираете модель для продакшена: Статья говорит "GPT-4 уязвима на 89%", вы паникуете. Реальность: уязвимость воспроизводится в 0.1% случаев при правильной оценке.
• Строите RAG-систему: Как правильно делать RAG в 2024 включает и безопасность. Нужно понимать реальные риски, а не мнимые.
• Интегрируете LLM в продукт: Клиенты спрашивают про безопасность. Хотите отвечать "Да вот исследование говорит, что уязвимо" или "Мы проверили по StrongREJECT, риски минимальны"?

Что делать, если вы нашли настоящую уязвимость

Допустим, вы не попали в 90% исследователей-дилетантов. У вас действительно есть воспроизводимый jailbreak. Что дальше?

1. Задокументируйте все: Не только код, но и точную версию модели, температуру, seed для random, системный промпт (если известен)
2. Проверьте на разных инстансах: Один jailbreak на одной endpoint - возможно, баг конкретного инстанса
3. Свяжитесь с вендором: Ответственные disclosure - это не только этично, но и полезно для карьеры
4. Опубликуйте с StrongREJECT метриками: Покажите не только успешные тесты, но и статистическую значимость

Будущее оценки безопасности LLM

StrongREJECT - это только начало. Вот что будет дальше:

• Автоматическое обнаружение ложных срабатываний: ML модели, которые отличают реальный jailbreak от случайного ответа
• Бенчмарки для мультимодальных атак: Текст + изображение + аудио = новые векторы атаки
• Тестирование на edge cases: Не только "как сделать бомбу", но и тонкие манипуляции
• Интеграция с CI/CD: Каждый апдейт модели автоматически тестируется на regressions в безопасности

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

Чеклист для чтения статей про jailbreak

В следующий раз, когда увидите статью с впечатляющим процентом успешных jailbreak, задайте вопросы:

Если статья не проходит этот чеклист - скорее всего, вы читаете научный мусор. Не тратьте время. Не цитируйте. Не распространяйте.

Последний совет перед тем, как вы начнете тестировать

Не пытайтесь найти уязвимости там, где их нет. Вместо этого:

1. Используйте StrongREJECT или аналогичные строгие бенчмарки
2. Тестируйте на актуальных моделях (не на тех, что были актуальны полгода назад)
3. Публикуйте отрицательные результаты ("метод X не работает" - тоже результат)
4. Сотрудничайте с вендорами, а не пытайтесь их опозорить

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