Простого перевода вредоносного запроса на менее распространённую языковую разновидность недостаточно, чтобы надёжно обойти защиту большой языковой модели. К такому выводу пришли авторы препринта «What Drives Dialectal Jailbreaks? An Ablation of Surface Form, Cultural Framing, and Strategy Banks», размещённого на arXiv 30 сентября 2026 года.
Исследователи попытались отделить три фактора, которые в предыдущих работах могли действовать одновременно: нестандартную языковую форму, культурное обрамление запроса и автоматизированный выбор тактики атаки. В проведённом ими эксперименте именно третий компонент оказался главным объяснением почти стопроцентной доли успешных обходов.
Работа пока имеет статус препринта. Представленные результаты следует считать заявлением авторов, а не окончательно подтверждённым выводом: независимое воспроизведение эксперимента в доступных материалах не описано.
Как исследователи разделили язык и стратегию
Авторы расширили ранее предложенный подход к red teaming на классическом китайском, добавив шанхайскую и кантонскую разновидности. Эксперимент включал 36 комбинаций условий и две целевые модели. В разных ячейках менялись поверхностная форма запроса, вариант банка атакующих стратегий и участие оптимизатора.
Такой дизайн нужен, чтобы избежать простой, но потенциально ошибочной интерпретации: если атака на диалекте сработала, причиной автоматически объявляют сам диалект. На практике вместе с переводом нередко меняются структура запроса, культурные отсылки, способ постановки задачи и число попыток. Каждый из этих элементов может влиять на результат.
Под поверхностной формой в работе понимается язык или регистр, в котором выражено одно и то же вредоносное намерение. Авторы сравнивали в том числе английский, путунхуа и варианты запросов на исследуемых китайских разновидностях. Отдельно они проверяли культурно окрашенные и нейтральные условия.
Банк стратегий — это набор высокоуровневых способов переформулировать запрос. Чёрно-ящичный оптимизатор выбирает и адаптирует подходящую тактику, ориентируясь на ответы целевой модели, но не имея доступа к её внутренним параметрам. Исследование не публикует в аннотации прикладные инструкции по обходу защиты, однако называет среди повторяющихся механизмов семантическое пояснение и процедурное структурирование запроса.
Перевод сам по себе оставил ASR ниже 8%
Главный результат относится к attack success rate, или ASR, — доле запросов, которые оценочная процедура признала успешным обходом защитного отказа. Для неоптимизированных запросов на английском и путунхуа, а также для наивных переводов на диалектные формы показатель оставался ниже 8%.
Это не подтверждает популярную формулу «редкий язык ломает защиту». По данным авторов, диалектная форма не была ни необходимым, ни достаточным условием высокой результативности. Иными словами, модель не начинала массово выдавать запрещённые ответы только из-за смены языка.
Картина резко менялась, когда в эксперименте сохранялся управляемый оптимизатором банк стратегий. Во всех таких условиях авторы зафиксировали ASR на уровне 98–100%. Сопоставимого потолка достиг и культурно-нейтральный банк общих стратегий, причём, согласно препринту, почти при стоимости одной попытки на запрос.
Последнее сравнение особенно существенно. Если нейтральный набор тактик работает не хуже культурно специфичного, объяснять результат локальными реалиями, идиомами или особой структурой конкретной языковой разновидности становится сложнее. Более вероятным фактором оказывается выразительность пространства, в котором оптимизатор ищет удачную переформулировку.
Диалект всё же влияет на эффективность и тяжесть ответа
Авторы не утверждают, что язык полностью несущественен. Выбор языковой разновидности влиял на количество запросов, необходимое для достижения результата, и на тяжесть генерируемого моделью ответа. Следовательно, мультиязычная безопасность остаётся отдельной инженерной задачей, даже если она не объясняет основной скачок ASR в этом эксперименте.
Для разработчиков это различие важно. Модель может демонстрировать примерно одинаковую итоговую уязвимость при наличии сильного оптимизатора, но требовать разного числа попыток на разных языках. При ограниченном бюджете атак или жёстком лимите запросов такая разница определяет реальный риск.
Тяжесть ответа также нельзя сводить к бинарному показателю «атака успешна или нет». Два ответа, получившие одинаковую метку ASR, могут заметно различаться по практической опасности: один останется расплывчатым, другой окажется более конкретным. Поэтому одной доли успешных обходов недостаточно для полной оценки защиты.
Исследование одновременно напоминает о проблеме неравномерного качества защитных механизмов. Системы, рекламируемые как мультиязычные, часто тестируют на безопасность значительно уже, чем на общие языковые возможности. Даже если диалект не является самостоятельным «ключом» к обходу, различия в эффективности отказов для разных групп пользователей требуют проверки.
Почему показатель 98–100% нельзя считать универсальным
Авторы отдельно оговаривают, что почти максимальный ASR зависит от калибровки оценщика. Решение о том, считается ли конкретный ответ нарушением, принимает автоматическая или формализованная процедура проверки. Изменение её порога способно заметно повлиять на итоговую цифру.
Это ограничение особенно критично для результатов у потолка шкалы. Значение 100% выглядит однозначным, но оно не обязательно означает, что каждая атака привела к одинаково подробному или практически применимому ответу. Оно означает, что ответы прошли установленный в эксперименте критерий успешности.
Есть и методологическая неопределённость. Дизайн работы, по признанию авторов, не полностью разделяет однократное конструирование сильной стратегии и итеративный поиск по обратной связи от модели. Поэтому из опубликованного результата пока нельзя точно определить, какая доля преимущества связана с качеством заранее заданного пространства стратегий, а какая — с последовательной адаптацией после нескольких ответов.
Также не следует автоматически переносить значения ASR на другие модели, языковые семьи или производственные конфигурации. Эксперимент охватывает две целевые модели и конкретный набор китайских регистров. Системные инструкции, внешние фильтры, версии моделей и правила оценивания могут изменить результат.
Что стоит изменить в проверках безопасности LLM
Для команд, тестирующих модели и AI-продукты, работа предлагает более строгий способ построения сравнений. Проверка «один запрос на английском против его перевода» показывает только языковую чувствительность и почти ничего не говорит об устойчивости к оптимизированной атаке.
Практический тест должен отдельно фиксировать:
- исходное вредоносное намерение и его смысловую эквивалентность на разных языках;
- наличие или отсутствие банка стратегий;
- одинаковый бюджет запросов и число итераций;
- роль культурного контекста;
- долю отказов и тяжесть разрешённых ответов;
- критерии оценщика и чувствительность результата к изменению порога.
Если высокая результативность исчезает после отключения оптимизатора, проблему не стоит описывать как чисто диалектную уязвимость. Если же различия сохраняются при одинаковой стратегии, одинаковом числе попыток и сопоставимом переводе, это уже более сильный сигнал о недостатках мультиязычного выравнивания.
Перед использованием цифр 98–100% в оценке конкретного продукта необходимо проверить полный текст препринта, перечень целевых моделей, настройки оценщика и правила подсчёта запросов. До независимого воспроизведения наиболее обоснованный вывод работы уже не сенсационный тезис о «магии диалектов», а более узкий инженерный результат: мощность автоматизированного поиска стратегии может влиять на успешность jailbreak-атак значительно сильнее, чем язык запроса сам по себе.
