Разоблачение jailbreak-методов: перевод на гэльский не работает | AiManual
AiManual Logo Ai / Manual.
07 Янв 2026 Гайд

Шотландский гэльский и другие сказки: почему 90% jailbreak-исследований — это научный мусор

Скандальное разоблачение научной работы по jailbreak LLM. Почему перевод на гэльский не работает и как правильно оценивать уязвимости GPT-4.

Научный скандал, который все проигнорировали

Помните ту статью, где исследователи утверждали, что перевод вредных запросов на шотландский гэльский обходит защиту GPT-4 с эффективностью 79%? Я тоже помню. И когда попытался воспроизвести — получил ноль успешных jailbreak-ов из ста попыток.

Не 79%. Не 50%. Даже не 5%. Ноль.

Это не просто ошибка в экспериментах. Это системная проблема всей области AI-безопасности, где некритичное принятие результатов ведет к созданию мифов вместо реальных защит.

Если ваш метод jailbreak работает только в одной конкретной статье и больше нигде — это не метод, это статистическая аномалия. Или хуже — манипуляция.

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

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

Три фатальные ошибки в рассуждениях

  • Ошибка первая: предположение о языковой изоляции
    Исследователи думали, что GPT-4 обрабатывает языки отдельно. На деле современные LLM работают с мультиязычными эмбеддингами — векторные представления слов разных языков находятся в одном пространстве. "Bomb" и "бомба" для модели ближе, чем "bomb" и "book".
  • Ошибка вторая: игнорирование контекстного понимания
    Даже если вы переведете "Как изготовить взрывчатку?" на гэльский, модель понимает семантику запроса. Системные промпты безопасности проверяют не язык, а смысл. И они чертовски хорошо справляются с этой задачей.
  • Ошибка третья: cherry-picking результатов
    В оригинальном исследовании использовали 100 запросов. Но никто не проверял, были ли это случайные запросы или специально подобранные. Когда я взял стандартный набор для тестирования prompt injection — ни один не прошел.
💡
Ключевой момент: современные LLM не обрабатывают языки изолированно. Они понимают смысл через мультиязычные эмбеддинги. Перевод на редкий язык не создает "слепую зону" — он просто меняет форму, но не содержание.

Как на самом деле оценивать jailbreak-уязвимости

Если вы хотите заниматься реальной безопасностью, а не научной фантастикой, вот методика, которую мы используем в своей работе.

1 Начинайте с воспроизводимости

Перед тем как писать статью, убедитесь, что ваш метод работает:

  • На разных версиях модели (GPT-4 Turbo, GPT-4o, Claude 3)
  • В разное время суток (серверная нагрузка влияет на ответы)
  • С разными системными промптами
  • На стандартизированных наборах запросов

2 Используйте правильные бенчмарки

Забудьте про самодельные наборы данных. Вот что реально работает:

Бенчмарк Что оценивает Почему важен
StrongREJECT Устойчивость к сложным jailbreak-атакам Стандарт де-факто в индустрии
HarmBench Защиту от вредоносных запросов Большой разнообразный датасет
ToxiGen Генерацию токсичного контента Фокус на hate speech

Если ваш метод не проходит StrongREJECT — он не стоит бумаги, на которой написан. Серьезно. Это как тестировать антивирус только на одном вирусе из 2010 года.

3 Проверяйте устойчивость к вариациям

Настоящая уязвимость проявляется при небольших изменениях промпта. Если jailbreak работает только с точностью до символа — это не уязвимость, это баг в конкретной реализации.

Проверяйте:

  • Изменение порядка слов
  • Добавление пробелов или знаков препинания
  • Незначительные переформулировки
  • Разные стили письма (формальный, неформальный, поэтический)

4 Учитывайте стоимость эксплуатации

Jailbreak, требующий 1000 токенов системного промпта и 10 минут ручной настройки — это академическое упражнение, не реальная угроза. В мире, где атаки на Snapchat-ботов происходят в реальном времени, сложность имеет значение.

Типичные ошибки, которые делают все

Ошибка номер один: тестирование на одной модели. Если метод работает только на GPT-4 и падает на Claude 3.5 Sonnet — это не jailbreak, это особенность конкретной реализации.

Другие популярные провалы:

  • Игнорирование временной вариативности: API-модели меняются ежедневно. То, что работало вчера, может не работать сегодня.
  • Маленькая выборка: 10-20 запросов недостаточно для статистической значимости. Нужны сотни.
  • Отсутствие контрольной группы: без сравнения с базовым уровнем невозможно оценить эффективность.
  • Публикация без кода и данных: если нельзя воспроизвести — нельзя проверить.

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

Допустим, вы обнаружили метод, который действительно работает. Не повторяйте ошибок прошлого.

  1. Документируйте все: точные промпты, версии моделей, временные метки, результаты каждого запуска.
  2. Проверьте на разных моделях: не только коммерческих API, но и локальных, вроде тех, что описаны в статье про запуск GigaChat на ноутбуке.
  3. Используйте инструменты автоматизации: вручную тестировать сотни вариаций невозможно. Возьмите Flakestorm или создайте свой скрипт.
  4. Сообщайте ответственно: не публикуйте эксплуатацию в открытый доступ без предупреждения разработчиков.
  5. Подумайте о защите: каждый найденный jailbreak должен сопровождаться рекомендациями по фиксу. Как в случае с Vigil.

Будущее jailbreak-исследований: меньше магии, больше науки

Поле AI-безопасности тонет в низкокачественных исследованиях. Перевод на гэльский — лишь самый яркий пример. Есть десятки других "методов", которые разваливаются при первой же проверке.

Что изменит ситуацию:

  • Обязательная воспроизводимость: без открытого кода и данных статья не должна приниматься к публикации.
  • Стандартизированные бенчмарки: как StrongREJECT, но с регулярными обновлениями.
  • Коллаборации: независимые проверки результатов разными командами.
  • Фокус на практической угрозе: а не на академических упражнениях.
💡
Самый важный навык в AI-безопасности сегодня — не умение находить уязвимости, а умение отличать реальные уязвимости от статистических артефактов и ошибок методологии.

В следующий раз, когда увидите статью про "революционный jailbreak-метод", задайте простые вопросы: можно ли его воспроизвести? Работает ли он на стандартных бенчмарках? Есть ли открытый код? Если ответ "нет" на любой из них — перед вами, скорее всего, научный мусор.

И помните: настоящие уязвимости выглядят скучно. Они не требуют переводов на мертвые языки или шаманских танцев с бубном. Они основаны на фундаментальных проблемах архитектуры — как те, что мы разбирали в истории про IQuest-Coder. И именно на них стоит тратить время.

(Да, и если кто-то предлагает вам использовать шотландский гэльский для взлома GPT-4 — можете смело отправлять их читать эту статью. Или лучше — проверять самостоятельно. Потому что в этой области единственная валюта — воспроизводимые результаты.)