Ваша нейросеть сломалась, несите следующую. Почему один красивый график больше ничего не значит

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

В 2026 году проверка безопасности больших языковых моделей и визуально-языковых систем давно выросла в отдельное исследовательское поле. Разговор уже не сводится к одному вопросу «ответила или отказала». Теперь приходится смотреть шире: насколько полезным оказался опасный ответ, не уходит ли защита в переотказ, одинаково ли ведет себя модель на разных языках, что происходит в визуальном канале, как ломается агент с памятью, браузером и доступом к инструментам. Поэтому честное сравнение сегодня требует не одной таблицы, а целой связки наборов тестов. Иначе рядом оказываются вещи разного класса: проверка опасных ответов, проверка обхода защиты, проверка автоматического оценщика и проверка системы, которая уже умеет действовать во внешней среде.

Почему старой метрики уже недостаточно

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

Из-за этого в современных работах оценку стали раскладывать как минимум на несколько осей. Первая отвечает на вопрос, удалось ли вообще пробить защиту. Вторая измеряет полезность опасного ответа. Третья смотрит на цену усиленной защиты и ловит переотказ, когда система начинает шарахаться от любой неоднозначной формулировки. Без такого разделения легко вручить медаль «самой безопасной» модели, которая на деле просто боится собственной тени.

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

HarmBench дал отрасли общий язык

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

HarmBench предложил более строгую рамку для системной проверки опасных ответов. Ценность набора тестов не только в перечне вредных сценариев, но и в самой идее повторяемого аудита. После дообучения, замены системных правил или перенастройки фильтрации модель можно снова прогнать по той же сетке и увидеть, где защита просела. Для исследователей и разработчиков такой подход стал чем-то вроде общего языка, на котором наконец можно обсуждать устойчивый отказ под давлением атак, а не обмениваться красивыми частными случаями.

Но здесь и начинается важная развилка. HarmBench хорошо показывает, где модель срывается, однако сам по себе не отвечает на два неудобных вопроса. Насколько полезным оказался опасный ответ? И не куплена ли «безопасность» ценой массовых переотказов? Поэтому к 2026 году HarmBench чаще работает как фундамент, а не как окончательный приговор.

StrongREJECT напомнил, что срыв срыву рознь

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

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

Для практического сравнения вывод неприятный, зато честный. Одной доли успешных атак недостаточно. Если не измерять полезность опасного ответа, можно принять косметическую защиту за реальный прогресс. StrongREJECT закрепил простую мысль, без которой разговор о безопасности в 2026 году уже выглядит старомодным: важно не только то, что модель сказала лишнее, но и то, насколько этот лишний ответ годится для вредного действия.

JailbreakBench превратил эффектные трюки в воспроизводимую проверку

Обход защиты долго был территорией почти цирковых номеров. Исследователи и энтузиасты находили яркие приемы, публиковали впечатляющие примеры, а потом оказывалось, что половина таких атак работает только в одном окне, с одной настройкой и в одном удачном запуске. Для отрасли такой шум был красивым, но не слишком полезным.

JailbreakBench попытался навести здесь порядок. Проект собрал открытый набор обходных приемов, зафиксировал набор опасных поведений и предложил единые правила сравнения. В результате обсуждение сдвинулось с уровня «посмотрите, что у меня получилось» к более предметному разговору о переносимости атак, о повторяемости результатов и о реальной цене защитных мер. Появился и публичный рейтинг, который полезен не сам по себе, а как способ отслеживать прогресс на одном и том же поле.

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

Плохой измеритель рождает плохой рейтинг

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

Отдельные проекты, прежде всего JAILJUDGE, вынесли эту тему на передний план. Речь уже идет не о том, чтобы проверить очередную целевую модель, а о том, чтобы проверить сам инструмент оценки. Справляется ли он со сложными случаями, с многоязычными запросами, с тонкими полутонами между частичным отказом и полноценным опасным ответом? Если измерительный прибор дает сбой, весь аккуратный рейтинг начинает врать с уверенным видом.

Для отрасли этот поворот оказался очень полезным. Он разрушил иллюзию, будто достаточно собрать список вредных запросов и нажать кнопку «оценить». К 2026 году серьезный разговор о безопасности включает уже два уровня проверки: нужно тестировать не только сами модели, но и тех, кто выносит им автоматический приговор.

Переотказ оказался не побочным шумом, а отдельной поломкой

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

Именно поэтому переотказ перестал быть сноской на полях. Наборы тестов вроде OR-Bench и SORRY-Bench нужны не для академической аккуратности, а для очень практичного вопроса: не куплена ли видимая безопасность за счет полезности. Модель может отлично держаться на провокациях и при этом резать безобидные запросы о медицине, праве, химии, политике или новостной аналитике просто потому, что внутри таких тем много чувствительных слов.

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

Многоязычность ломает иллюзию универсальной защиты

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

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

Для русскоязычной аудитории этот пласт особенно важен. Если статья рассказывает о безопасности моделей, но опирается только на англоязычные результаты, в тексте остается неприятная дыра. Сейчас многоязычность уже нельзя подавать как частную оговорку при обсуждении JAILJUDGE. Это отдельный класс риска, который влияет и на устойчивость к обходу, и на качество отказов, и на достоверность всей оценки. Хороший пример такого подхода дает LinguaSafe.

Визуальный канал приносит не только подписи на картинках

Когда в разговор входят визуально-языковые модели, многие по привычке думают об одном и том же сценарии: в изображение встраивают текстовую инструкцию, система читает ее и срывается. Такой вектор действительно важен, но только им дело давно не ограничивается. Мир атак на изображения пришел не из пустоты. У компьютерного зрения за плечами большая история состязательных искажений, когда нужный эффект достигается не заметной надписью, а тонкой работой с самими пикселями.

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

Поэтому в 2026 году уже мало сказать, что визуально-языковую модель протестировали на обходы через изображения. Нужно уточнять, о каких именно атаках идет речь. Проверяли ли только текст внутри картинки? Или смотрели также на искаженные изображения, универсальные шаблоны, физически переносимые патчи и другие приемы, пришедшие из классического компьютерного зрения? Без такого уточнения визуальная безопасность выглядит гораздо чище, чем есть на самом деле. Для первой линии такой проверки обычно вспоминают JailBreakV, для более широкой рамки мультимодальной оценки, SafeBench.

Опасные ответы не исчерпывают всю карту угроз

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

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

Логика здесь связана с основной темой напрямую. Проверка опасных ответов отвечает на вопрос, не подталкивает ли модель к вредному действию. Проверка на утечки отвечает на другой вопрос, не выносит ли система наружу то, что вообще не должна помнить в воспроизводимом виде. Для реальной карты угроз обе линии одинаково важны. Если статья о безопасности описывает только обход защиты, а про утечки обучающих данных молчит, картина получается аккуратной, но неполной.

Агентные системы поднимают ставки

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

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

Эта часть особенно отрезвляет. Базовая модель может выглядеть вполне прилично в чистом чате, а потом резко просесть, когда вокруг нее появляется агентная оболочка. Поэтому к 2026 году разговор о безопасности без агентного слоя уже выглядит неполным, особенно если речь идет о прикладных системах, а не о демонстрации «модель в вакууме».

Отрасль движется к общей рамке, но единого эталона все еще нет

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

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

Поэтому зрелая оценка безопасности в 2026 году выглядит не как один магический сертификат, а как несколько совместимых оптик. Каждая подсвечивает свой класс риска. Только в такой сборке появляется не рекламная, а действительно рабочая картина.

Что остается после всех этих бенчмарков

Хорошее сравнение моделей в 2026 году уже нельзя собрать по принципу «взяли один набор тестов и выбрали победителя». Если проверять только опасные ответы, выпадет переотказ. Если смотреть только на текст, пропадут визуальные обходы. Если опираться только на английский, скрытыми останутся языковые провалы. Если тестировать только модель в чистом окне чата, агентная оболочка потом неприятно удивит уже в реальной эксплуатации.

Поэтому зрелая проверка сегодня больше похожа не на гонку за одной цифрой, а на серию перекрестных допросов. HarmBench показывает, где система вообще срывается. StrongREJECT заставляет смотреть на полезность опасного ответа. JailbreakBench отсекает разовые фокусы и требует воспроизводимости. OR-Bench и SORRY-Bench проверяют, не стала ли защита слишком нервной. LinguaSafe напоминает, что одна и та же модель может быть «смелой» на одном языке и неожиданно рыхлой на другом. JailBreakV и SafeBench вытаскивают на свет уязвимости визуального канала. Agent Security Bench проверяет, не превращается ли в проблему сама способность модели действовать.

И в этом, пожалуй, главный вывод. Безопасность языковых и визуально-языковых моделей уже нельзя описать одной победной строкой в отчете. Любая система, которая выглядит образцовой в одном срезе, может провалиться в соседнем. Поэтому самый честный вопрос сегодня звучит не «какая модель безопаснее всех», а «в каком именно режиме и по какой именно шкале она держится лучше остальных». Как только этот вопрос задают всерьез, рекламная простота заканчивается, а нормальный инженерный разговор только начинается.