Возможность атаки проистекает из того, что ждать, пока гигантский трансформер генерирует ваше поздравление с днем космонавтики в стиле Эминема ответ, очень скучно. Чтобы вы не скучали, LLM-чатботы отправляют ответ стримингом прямо токен за токеном. Но токены имеют разный размер в символах, а значит и пакеты, в которых они отправляются, тоже будут иметь разный размер. Таким образом, внеся определенные корректировки, чтобы скомпенсировать зашумленность канала, по зашифрованному трафику можно с достаточно большой точностью вычислить длину каждого токена в символах. Например, получив последовательность 1 5 4 можно предположить, что это потенциальное I _love _you. Разумеется, все, как обычно, не так однозначно, ведь это может быть и I _hate _you.

Тем не менее, информации тут уже довольно много. Например, 1 в середине текста почти всегда является знаком препинания, а 3 1 1 - началом нумерованного списка. Используя несколько таких эвристик, исследователи делят полученные ими последовательности на что-то вроде предложений.

Дело за малым – раскодировать предложения. Хотя исследователи замечают, что тут неплохо подошли бы старые советские марковские цепи, разумеется, они берут датасет UltraChat, превращают его в пары «последовательность длин токенов -> фраза» и файнтюнят T5 решать эту задачу. При этом они файнтюнят две LLM (A и B), одна из которых умеет предсказывать первое предложение ответа, а вторая – последующие по предыдущему контексту. Сделано это потому, что первую тренировать немного проще – чатботы часто отвечают типовыми фразами (“As an AI language model” или “Sure, I can” и так далее), поэтому можно отдельно собрать соответствующий датасет. Для обучения используется скромная одна A6000.

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

Атака очень остроумная, а статья написано очень интересно, поэтому вполне могу порекомендовать прочитать. Особенно порадовало использование достаточно большого объема приемов из NLP для реализации и оценки задачи (ROUGE, T5, MiniLM). Некоторые вещи показались странными (например, исследователи сэмплировали k декодировок неуказанным методом, а потом оценивали их той же T5, а не использовали, например, beam search, который напрашивается), но в целом статья показывает, что иногда угрозы приходят оттуда, откуда их совсем не ждешь, и LLM тут не исключение.

Gradient Cuff: Detecting Jailbreak Attacks on Large Language Models by Exploring Refusal Loss Landscapes
Hu et al., 2024
Статья, сайт

Сегодня снова поговорим о защитах, и на этот раз у нас свежая статья исследователей из Гонконга и IBM Research про защиту от джейлбрейков. Есть несколько способов предотвращать джейлбрейки, которые могут включать в себя повышение устойчивости модели (например, за счет системного промпта) или попытки задетектировать джейлбрейк до того, как он вообще в сеть попадет, например, расчет перплексии ввода, если речь идет об атаках типа GCG. Предлагаемый в статье метод относится ко второй категории и крутится вокруг идеи расчета «функции потери от отказа» (refusal loss function). Что это такое? Давайте разберемся.

На этом можно бы было, наверное, остановиться, но авторы не для того учили матан. Далее предлагается посчитать от этой красоты градиент, а потом еще и посчитать его величину. К сожалению, это не так просто, потому что наш «детектор отказа» (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 между генерацией и тем, что было в оригинальном дырявом коде.

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