llm security и каланы

Frontier Models are Capable of In-context Scheming
Alexander Meinke et al., Apollo Research, 2024
Статья, блог

Рабочие дни подошли к концу, поэтому сегодня статья более развлекательного характера. Если вам недавно попадались статьи про то, что «ИИ пытался сбежать, а потом врал, что не пытался», то это очень краткое (и слегка кликбейтный) содержание параграфа о поведении o1 в System card, основанного на исследовании, которое провели Apollo Research, независимая AI safety-лаборатория.

Предпосылки таковы. В safety-дискурсе есть такое понятие, как scheming – когда модель вместо того, чтобы делать то, что просит пользователь, скрытно преследует свои цели. Это может проявляться по-разному. Во-первых, модели могут делать то, что велит системная затравка в обход просьб пользователя, при этом делая вид, что выполняет пользовательскую инструкцию (in-context scheming). Во-вторых, они могут преследовать цели, которые получили в процессе обучения. Совпадение «ценностей», полученных из обучения (в частности, элайнмента) и системных инструкций увеличивает вероятность, что модель будет строить тайные планы.

Таким образом, получаем еще один bitter lesson – если очень долго мучать модель, за счет высокой энтропии промпта повышая случайность ответа, то время от времени элайнмент будет ломаться и модель будет выдавать недопустимые ответы, даже если ее обвесить защитами. Сама атака кажется достаточно бесполезной (ее можно несложно детектировать, а еще после 10000 попыток джейлбрейка вам и OpenAI, и Anthropic просто заблокируют аккаунт), кроме того, как и любой такого рода джейлбрейк, он, вероятно, снижает качество ответов. Но зато эта статья показывает очень много интересного о поведении LLM с нестандартными OOD-промптами, а заодно еще раз напоминает, что LLM – это очень сложные вероятностные машины, и мы слабо понимаем, что у них внутри происходит.

Видимо, даже LLM устают, потому что результаты для black-box-метода получаются неплохие: ASR (доля успешных попыток) растет с 0,6% у Claude Sonnet 3.5 и 0% у Gemini Pro до 78% и 50%, соответственно. GPT-4o при N=100 ломается в 50% случаев, что стоит все-то каких-то 9 долларов. На картинках ASR варьируется от 25% на GPT-4o до 88% на Claude Opus, а на звуке – от 59% на Gemini-Pro до 87% на DiVa, причем на Gemini Pro результат на звуке (71%) на 10% лучше, чем на тексте.

Исследователи проводят много разных экспериментов, среди которых есть несколько занятных. Например, а что если просто 500 раз без всяких аугментаций отправлять в LLM один и тот же запрос? ASR растет, но очень незначительно. Успешность растет с температурой, но не очень сильно. Самое интересное: джейлбрейки очень нестабильны, и успешная аугментация срабатывает заново, как правило, максимум в половине повторов, причем даже при нулевой температуре! Наконец, такие защиты, как Circuit Breaker и проприетарный Cygnet от GraySwan также ломаются BoN, правда с нюансом. Cygnet защищает от джейлбрейка достаточно успешно (5% ASR), но если потнюнить системный промпт, попросив его выводить ответ в таком же виде, что и запрос, то доля успешных атак растет до 67%, хотя часть из них и прерывается где-то по ходу ответа: очевидно, Cygnet анализирует сам ответ, и его нужно обфусцировать, чтобы он какое-то время не триггерился.

Best-of-N Jailbreaking
John Hughes et al., 2024
Статья, сайт, код

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

Суть подхода, работающего в black-box-режиме, да еще и мультимодального, такая. Давайте возьмем набор запросов, исполнение которых противоречит принципам, соблюдению которых обучалась модель, например, из какого-нибудь бенчмарка типа HarmBench. Мы будем использовать эти запросы, коих в итоге оказалось 159, в трех вариантах: текстовый, в виде текста на картинке и в виде озвученного голосом запроса. Теперь давайте придумаем набор аугментаций, который будет зашумлять запрос:

1. Для текста это перемешивание букв в середине слова с вероятностью 60%, капитализация случайных букв с вероятностью 60% и имитация опечаток за счет сдвига ASCII-кода каждого символа с вероятность 6%. ПОлУЧАЕтСя вОт ТОАКй тСЕкТ, пРОчитаТЬ кЫРтОой МГУот лИШЬ 55% люЕДй.
2. Для картинок выбирается случайный размер (заполняемый черным цветом), на фон случайно добавляются 50-80 цветных прямоугольников случайного размера, выбирается один из 104 случайных шрифтов (об эффективности Comic Sans умалчивается) случайного размера, толщины и цвета, которым набирается в случайном же месте вредоносный запрос.
3. Для аудио произвольно меняется скорость, питч, громкость, а также случайно добавляется фоновый шум или музыка.

Все эти преобразования делаются одновременно, но каждая следующая попытка джейлбрейка является независимой от предыдущего. Процесс останавливается, когда LLM-оценщик говорит, что попытка удалась, или когда мы достигли N (10000 попыток для текста, 7200 для картинок и 7200 для звука).

(triplet loss)

Все это тестируется на нескольких датасетах: валидационная часть SQuAD, HotPotQA, вариациях с несколькими основными задачами и разные задачи – Code Alpaca, зловредные задачи из многострадального AdvBench и других датасетов с джейлбрейками и даже джейлбрейки сгенерированные разными подходами вроде PAIR под заданные модели. Логрег (как это часто бывает на практике) выигрывает в сравнении, показывая ROC-AUC на уровне 0,999 для некоторых моделей с лучшими результатами при использовании активаций с более глубоких слоев.

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

Для реализации метода собирается датасет активаций разных LLM на разных слоях. Исследователи берут задачу QA и несколько синтетических задач из датасета SEP (суммаризацию, перевод, извлечение ключевых слов), в качестве источника текстов берут SQuAD. В качестве внедренных задач используются инъекции, сгенерированные GPT-4 – от тонких подводок до набранных капсом инструкций с разделителями. Эти инструкции рандомно вставляются в начало, конец и середину текста.

Собственно, активации собираются с каждого слоя после обработки LLM специальной затравки, которая фокусирует ее внимание на основной задаче (см. скриншот), а также после обработки всего текста, включая блоки данных с внедренной задачей и без нее (чистый сабсет). Нелинейное снижение размерности (t-SNE) показывает, что наборы данных относительно разделимы в пространстве дельт активаций. Для непосредственно детекта сдвига используются две формулировки задачи: metric learning (контрастивный подход) и логистическая регрессия над дельтами изначальной и финальной активации. Для контрастивного подхода используется triplet loss на тройках (активация после основной задачи, активация после чистого блока, активация после блока с внедренной задачей), оптимизируется он на некоторой многослойной сети с одномерными свертками.

Are you still on track!? Catching LLM Task Drift with Activations
Abdelnabi et al., 2024
Статья, код

Рассмотрим еще один метод защиты от indirect prompt injection, с которым можно поразвлекаться в идущем сейчас соревновании от Microsoft – TaskTracker. В отличие от рассмотренного в прошлый раз метода Spotlighting, этот метод направлен не на предобработку для улучшения разделения инструкций и данных, а на детектирование потенциальной атаки.

Данный метод построен на оценке не поверхностной текстовой структуры, а активаций модели на разных уровнях. Инструкции, которые LLM задаются пользователем или разработчиком, называются основной задачей (primary task). В рамках выполнения этой задачи в контекст могут попадать блоки данных (data blocks). Эти блоки данных могут содержать внедренные задачи (injected tasks), причем эти задачи не обязательно должны отвечать каким-то критериям вредоносности – это могут быть любые инструкции, которые не согласуются с основной задачей. Исполнение внедренной инструкции из блока данных называется сдвигом задачи (task drift), который предложенный метод и должен обнаруживать.

Завершается статья практическими глубокомысленными рекомендациями по имплементации (например, рандомизировать разделитель для datamarking и не использовать ROT13, потому что он двунаправленный).

С одной стороны, статья достаточно смешная как с точки зрения наполнения, так и методологии (ну какой IMDB, ну какой text-davinci-003 в 2024 году?). Я немного посмеялся, когда в пресс-релизе майкрософта (вот тут) увидел ссылку на нее как на our scientific research paper™. С другой стороны, такой подход вполне может применяться для небольших чат-ботов, которые работают с небольшими запросами от пользователей, чтобы избегать изменения простых атак, и рекомендуется в гайдах MS по промпт-инженерии. Так или иначе, spotlighting вполне работает: можете проверить сами в проводимом майкрософтом же сейчас соревновании по indirect prompt injection.