Введение: почему джейлбрейк — проблема
Современные языковые модели стараются отказываться от вредных или опасных запросов, но ни одна защита не идеальна. Джейлбрейк-атаки придумывают промпты, которые обходят эти ограничения: просят представить гипотетический сценарий, переключить роль, переписать задачу на «безопасный» лад и так далее. Исследователи и защитники хотят понимать, насколько такие атаки опасны на самом деле.
Большинство атак работает в режиме чёрного ящика: у взломщика нет доступа к весам модели, нет возможности проанализировать её внутренние механизмы. Есть только API, в которое можно отправлять запросы и получать ответы. Поэтому все усилия атакующего сводятся к подбору текста. Чтобы оценить, насколько атака хороша, нужно понять не только то, удалось ли обойти защиту, но и какой ценой.
Обычно используют простую метрику — долю успешных попыток (ASR). Но она не показывает, сколько запросов пришлось сделать. А ведь именно число обращений к модели часто становится главным ограничением на практике: чем больше запросов, тем выше шанс быть замеченным, тем дороже атака с точки зрения времени и денег.
ASR как обманчивая метрика
Представим два способа атаки. Первый перебирает сотни вариантов промптов, пока один не сработает. Второй использует заранее выверенный шаблон и получает результат с трёх попыток. Если у обоих одинаковый процент успеха, при взгляде на ASR они покажутся равнозначными. Но в реальных условиях второй способ явно опаснее: он быстрее, дешевле и оставляет меньше следов.
Именно поэтому сравнение только по ASR напоминает соревнование стрелков, где один стреляет с трёх метров, а другой — с тридцати, но победа присуждается по числу попаданий. Без учёта условий результат лишён смысла. Для джейлбрейков таким условием должен быть бюджет обращений к модели.
Fair-ASR: считаем обращения
В недавней работе на arXiv исследователи предложили протокол Fair-ASR. Его суть — сравнивать атаки при одинаковом предельном числе целевых вызовов. Целевой вызов — это обращение непосредственно к атакуемой модели: отправили промпт, получили ответ. Такое ограничение легко контролировать, оно одинаково для любых методов и не требует знания внутренностей модели.
Почему это важно? Некоторые метрики пытаются учитывать вычислительную сложность, например, через FLOPS. Но для закрытых и проприетарных моделей такие оценки неточны. А число обращений — прямой и понятный показатель. Если одна атака добивается успеха за 10 запросов, а другой нужно 1000, то при бюджете 10 вторая просто не состоится.
При этом исследователи предлагают отдельно следить за так называемыми вызовами атакующего — обращениями к вспомогательным инструментам, таким как другая языковая модель, которая генерирует промпты. Это позволяет увидеть полную картину: во-первых, сколько запросов ушло на целевую модель, во-вторых, сколько дополнительных ресурсов потребовалось.
Что изменилось при честном сравнении
Авторы переоценили 11 известных атак с помощью Fair-ASR и обнаружили, что их рейтинг сильно меняется в зависимости от выделенного бюджета. Атака, которая выглядит мощной при ста вызовах, может оказаться слабой при пяти, и наоборот. Это значит, что старые выводы об эффективности были как минимум неполными.
Неожиданным стало и то, что простые методы никуда не делись. Случайные возмущения промптов и вручную составленные шаблоны остаются очень конкурентоспособными, когда доступ к целевой модели ограничен. Они не требуют больших вычислительных ресурсов и работают почти сразу.
А вот LLM-управляемые атаки, где вспомогательная модель сама придумывает варианты обхода, показали себя хуже. Они тратят много вызовов и на целевую модель, и на собственную генерацию. Ни одна из протестированных атак такого типа не оказалась эффективной сразу по обоим показателям. Либо результат достигается с большим бюджетом, либо атака слишком дорога во вспомогательных вызовах.
ReCode: эффективная атака по мотивам исследования
Этот разрыв между желаемой эффективностью и реальными затратами подтолкнул исследователей к созданию собственной методики — композиционной атаки ReCode. Она использует десенсибилизирующую перезапись: исходный вредный запрос переформулируется так, чтобы он выглядел нейтрально и не вызывал защитных реакций. Затем в ход идут два простых и дешёвых примитива, которые хорошо зарекомендовали себя в ходе переоценки Fair-ASR.
Результаты выглядят сильно. При бюджете всего 20 целевых вызовов ReCode добивается 85% успеха на GPT-5, а в среднем на каждый запрос тратится лишь 7.19 вызовов к вспомогательным инструментам. Для сравнения, многие другие атаки при таком ограниченном бюджете практически бесполезны. А те, что могут похвастаться сопоставимыми показателями, обычно требуют в разы больше вспомогательных ресурсов.
Выводы
Исследование даёт ясный сигнал: оценивать атаки только по доле успешных попыток больше нельзя. Нужна единая точка отсчёта, и число обращений к целевой модели — самая прозрачная и универсальная из доступных мер. Fair-ASR предлагает именно такой подход, и он может стать стандартом для будущих сравнений.
Для тех, кто защищает модели, важный практический вывод: не стоит зацикливаться на сложных атаках с искусственным интеллектом в роли злоумышленника. Простые и дешёвые методы — случайные возмущения, шаблоны — остаются реальной угрозой при ограниченных ресурсах. Именно их устойчивость к защитам стоит проверять в первую очередь. Сложные LLM-управляемые атаки, возможно, эффектны в лабораторных отчётах, но в реальных условиях они слишком дороги и не так опасны, как кажется.
