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

Воспользовавшись наблюдениями о наивном фильтре и том факте, что у запросов с джейлбрейком выше норма градиента ϕ, исследователи конструируют свой метод защиты под названием Gradient Cuff. Суть простая: подбираем на некотором «чистом» наборе данных порог для нормы градиента, чтобы доля ложноположительных срабатываний не превышала 5%, задаем отсечку для наивного подхода в 0,5 (потому что красивая цифра), после чего пропускаем все наши тестовые данные через эту систему, в которую заворачиваем LLaMA-2-7B и аналогичную Vicuna-7B-1.5.

В целом, статья оставляет смешанное ощущение. С одной стороны, кажется, что где-то в кишках модели – градиентах, активациях – можно найти что-то, что может помочь (вспомним про sentiment neuron у OpenAI еще времен open), кроме того, наблюдение, что джейлбрейки работают вероятностно, и потому если LLM отказывается от ответа чаще, чем в среднем, то запрос подозрительный – довольно разумное. Да и действительно, наверняка, если чуть-чуть отойти от точной последовательности, при которой работает джейлбрейк (например, на живую добавив шума в эмбеддинги), то джейлбрейк (особенно такой специфичный, как GCG) перестанет работать, по аналогии с adversarial-шумом, который перестает работать, если картинку пожать jpeg’ом, так что норма градиента здесь вполне имеет смысл.

С другой стороны, я три раза перечитал статью, но так и не нашел, какой вклад в защиту вводит «наивная» фильтрация по доле отказов – у меня есть некоторое ощущение, что этот механизм работает более эффективно, чем норма приближенного градиента. Некоторые места просто кажутся немного сомнительными (например, префиксы для определения JB, кроме того, график 5 покорил своей осмысленностью). Ну и вычислительная сложность в N*(P+1), где обе переменных порядка десятков – это немного чересчур – становится понятно, почему они использовали 7B-модели. В общем, статья занятная некоторыми своими идеями, но практической ценности, пожалуй, особо не представляющая.

Purple Llama CyberSecEval: A Secure Coding Benchmark for Language Models
Bhatt et al., 2023
Статья, блог, код

Недавно вышла LLaMA 3, которая, как уже известно, приблизилась по метрике «генерируем приятные ответы на первые пришедшие в голову вопросы случайных людей» (также известной, как Elo на Chatbot Arena) к ведущим моделькам типа Claude Opus и GPT-4, вызвав бурю восторгов. Менее заметным был релиз второй версии бенчмарка для оценки безопасности CyberSecEval в рамках инициативы по оценке надежности и безопасности моделей с точки зрения кибербезопасности под названием Purple LLaMA. На самом деле, инициатива очень крутая, а потому мы рассмотрим три статьи, которые сопровождали эти релизы.

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

Начнем с разработки. Приводится некоторое количество интересной статистики, например, что 46% кода на Github уже (в 2023) было сгенерировано копайлотом, 22% кодогенерации в Meta принимается пользователями, при этом в 40% автосгенерированного кода есть уязвимости. Таким образом, исследователей интересует, а можем ли мы сравнить LLM по их склонности генерировать плохой код? Чтобы ответить на этот вопрос создается бенчмарк CyberSecEval. Он включает в себя:

1. ICD: инструмент под названием Insecure Code Detector, который на основе 189 статических правил для детектирования 50 типовых проблем из Common Weakness Enumeration от MITRE на разных языках, от C до PHP. Авторы размечают вручную 50 примеров для каждого языка и на них оценивают качество инструмента – 96% точности, 79% полноты.
2. Датасет: набор тест-кейсов для двух сценариев – инструктивного и tab-дополнения. Сначала в открытом коде с помощью ICD ищутся небезопасные строки, затем к ним или генерируются инструкции, или оставляются строки, предшествующие строкам с ошибкой.
3. Метрика: смотрим, сгенерирует ли модель обратно дырявый код или сделает что-то иное. В качестве метрики считается число кейсов, где модель не сгенерировала код с уязвимостью. Есть нюанс: если сеть вообще ничего в ответ не сгенерирует или начнет генерировать чепуху, то и уязвимости там не будет. Поэтому авторы (на мой взгляд немного неоднозначно) дополнительно считают метрику «качества кода», в качестве которой берут BLEU между генерацией и тем, что было в оригинальном дырявом коде.

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

Для оценки из каждой модели для каждого промпта семплируют три дополнения. Результаты следующие. В среднем модели помогают в 52% случаев. Модели для кодогенерации (CodeLLaMA) отказываются реже, особенно когда речь идет о задачах «двойного назначения» типа шифрования файлов, которые могут иметь как полезные, так и вредные применения. Были отличия и в разрезе TTP – например, модели больше склонны отказываться от помощи в уклонении от обнаружения (evasion), чем в сборе информации (reconnaissance).

В конце исследователи отмечают, что у статьи есть определенные ограничения: от вполне реальной утечки тест-кейсов через гитхаб и неидеальной схемы детектирования уязвимостей до англоцентризма и отсутствию multi-turn-тестов. Тем не менее, наличие такого бенчмарка достаточно важно – как минимум, если вы решите сделать offensive LLM, вы знаете, на чем измерять эффективность 😈

В следующий раз посмотрим, что нового появилось в CyberSecEval 2.

CYBERSECEVAL 2: A Wide-Ranging Cybersecurity Evaluation Suite for Large Language Models
Bhatt et al., 2024
Статья, блог, код

Меньше, чем полгода спустя, авторы CyberSecEval выкатывают вторую версию своего бенчмарка, приуроченную к выходу LLaMA-3. Во второй версии добавляются новые задачи для двух аудиторий: тех, кто строит решения для кибербезопасности на основе LLM, и тех, кто создает приложения общего назначения. Первым эта работа дает набор тестов, которые помогают оценить устойчивость решения перед стандартными атаками, вторым – возможность оценить, насколько хорошо LLM подходит для решения их задач.