llm security и каланы

Оказывается, что да. Для начала определяется иерархия инструкций, где самый высокий приоритет – у системного промпта, а самый низкий – у данных из внешних источников (tool output).

Инструкции могут быть согласующимися (aligned) и противоречащими (mislaligned). Например, пользовательская инструкция «говорить по-испански» не противоречит инструкции «продавать машину», в отличие от инструкции «объясни уравнение».

The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions
Wallace et al., 2024
Статья

Основная проблема с безопасностью решений на основе LLM – это prompt injection, когда инструкции, которые LLM получает от пользователя или из внешних источников, конфликтуют с теми, которые заложил разработчик. Так мы получаем HR-ботов, пишущих код на питоне, и ботов поддержки, которые продают машины за 1 доллар.

Эта проблема возникает потому, что у instruction-tuned LLM нет «понимания» о приоритете тех или иных инструкций над другими. Из-за этого пользовательские инструкции, хотя бы и просто из-за того, что они ближе к концу контекста, вполне могут получать приоритет над системными. Исследователи из OpenAI задают вопрос: а можно ли научить модель приоритизировать инструкции, понимать, что они противоречат друг другу, и отказываться следовать инструкции с меньшим приоритетом?

Работа очень важная: вопрос модерации входов и выходов стоит остро, элайнмент на 100% невозможен, да и в целом, мне кажется, пора (особенно после работ про универсальное удаление элайнмента) смириться с неотвратимостью джейлбрейка и перестать делать лоботомию моделям. Риски опасных генераций низкие – все зловредные инструкции можно и без LLM найти в интернете, нецензурированные LLM валяются тоннами на Huggingface Hub, и беспокоят подробные генерации с рецептами наркотиков только корпорации, которым за это нужно нести потенциальную юридическую ответственность. Поэтому нецензурированная LLM + сильный модератор кажутся гораздо более надежным решением в перспективе, чем дальнейшие упражнения в RLHF.

У работы есть недостатки, которые прямо перечислены в секции Limitations: это англоцентричность (то, над преодолением чего исследователи работают сейчас в процессе выпуска новых LLaMA-3), подверженность инъекциям и (что забавно) то, что из затюненной на зловредных текстах модели просто насемплировать аналогичные. Тем не менее, это (в совокупности со второй версией Llama Guard) самая сильная на текущий момент открытая работа в области применения LLM к модерации.

Теперь надо оценить то, что получается. Для оценки берутся два аспекта – собственно, насколько хорошо модель справляется на валидационном сплите датасета и других открытых датасетах, и то, насколько хорошо модель адаптируется к другим сценариям (on-policy и off-policy). Определяется три подвида метрик: по сути, бинарная (хорошо ли модерирует), 1-vs-all (хороши ли модерирует конкретные классы) и 1-vs-all без положительного класса (хорошо ли разделяет сорта дерьма).

Сравнивается получившаяся модель с уже упоминавшимся Perspective API, OpenAI Moderation API, а также вне конкурса с Azure и zero-shot GPT-4, из которых нельзя получить скоры.

В результате Llama Guard побеждает всех на своем тест-сете и достаточно неплохо работает off-policy на сете от OpenAI, особенно в few-shot-режиме. Что характерно (если пробовали приспособить GPT к детекту, то понимаете, о чем я), GPT-4 работает довольно слабо – очень низкий precision.

Для сбора данных используют датасет от Anthropic, на основе которого с помощью разных чекпоинтов LLaMA (видимо, цензурированные и нецензурированные) генерируют диалоги, в которых модель отказывается и соглашается генерировать недопустимый вывод. Результаты дополнительно размечают люди, в результате получается достаточно большой набор высококачественных данных. Дополнительно в процессе обучения на 8*A100 исследователи время от времени удаляют часть категорий и меняют метки, чтобы улучшить поведение модели при изменении таксономии.

Таксономия, которую составили авторы, состоит из следующих пунктов:

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

Чтобы детектировать все эти непотребства, исследователи создают набор задач (т.е. промптов), которые состоят из соответствующих описаний категорий, диалогов (причем с разным количество реплик), постановки задачи (детектирование в запросе или в ответе) и метки класса. При этом мы все еще используем диалоговую модель, поэтому Llama Guard должна выводить токен safe или unsafe, и если в результате получился unsafe, то на следующей строке – индекс типа небезопасного контента из таксономии.

Отдельно подчеркивается, что хотя Llama Guard тюнится на определенный ограниченный набор категорий, этот набор можно расширить за счет того, что у нас все-таки LLM на семь миллиардов параметров в основе – таксономию в промпте можно поменять в режиме zero-shot или few-shot, предоставив пару примеров.

Llama Guard: LLM-based Input-Output Safeguard for Human-AI Conversations
Inan et al., 2023
Статья, модель (новая)

Завершая трилогию (1, 2) про Purple LLaMA, сегодня мы посмотрим на Llama Guard. Исследователи формируют таксономию видов рискованного поведения модели, собирают под него датасет и с помощью инструктивного файн-тюнинга дообучают LlaMA-2-7B работать в качестве цензора для вводов и выводов модели.

У современных API для модерации (типа Perspective API) есть, по мнению исследователей, определенные недостатки:

- они определяют наличие недопустимого контента, не разделяя текст на пользовательский и сгенерированный моделью (непонятно, в чем на практике выражается этот недостаток);
- у них ограниченный набор видов опасного контента, который не адаптируется под меняющиеся реалии;
- они доступны только по API (видимо, поэтому они называются “moderation API”);
- внутри у них маленькие модели, которые не смогут определить, что сгенерированный более мощной моделью контент опасен.

Чтобы исправить эти недостатки исследователи и выпускают в открытый доступ Llama Guard.

В сумме вторая версия бенчмарка гораздо богаче первой и, что важно, имеет тесты не только на отказ от плохого поведения, но и на долю ложных отказов от добросовестных запросов на рисковые кибербазопасные темы. Кроме того, уже в самой статье бенчмарк на эксплуатацию уязвимостей рассматривается не как диагностика проблем, а как диагностика способностей – все-таки было бы очень удобно, если бы можно было загрузить сервер с GPU фаззировать по-умному свои приложения с утра до вечера, это бы потенциально повысило защищенность ПО. Важным выводом с точки зрения защищенности является то, что prompt injection – нерешенная задача, поэтому надеяться на то, что модель не будет забивать на system prompt пока рановато. Занятно, что буквально пару недель назад вышла статья ребят из OpenAI (включая небезызвестного Эрика Уоллеса), где они демонстрируют, что резко снизить вероятность prompt injection вполне можно на уровне элайнмента – и об этом мы тоже обязательно почитаем.

Наконец, исследователи обращают внимание, что многие сервисы интегрируют в LLM интерпретатор кода, который тоже может быть подвержен различным уязвимостям или использован во вред. Очевидно, что интерпретатор должен быть обернут во всевозможные контейнеризации, виртуализации и прочие изоляции, но на практике выясняется, что один из первых LLM-кейсов в MITRE ATLAS был связан как раз с небезопасным использованием интерпретатора в студенческой поделке под названием MathGPT. Авторы бенчмарка предоставляют 500 промптов – по 100 в каждой из категорий: попытки побега из контейнера, повышения привилегий, пост-эксплуатация (включая персистирование), использование интерпретатора для атак на другие систем и для генерации контента для социальной инженерии. Для оценки процента отказа от выполнения зловредных инструкций снова используется LLM-судья. Что касается результатов, то самыми безопасными оказались вариации CodeLLaMA и GPT-4, которые, видимо, лучше умеют определять, что является потенциально опасным в контексте интерпретатора (или в целом лучше работают с идеей интерпретатора как инструмента), а в среднем LLM соглашаются сгенерировать (что не означает генерацию успешного или правильного кода) попытки эксплуатации интерпретатора в одной трети случаев.

Следующим бенчмарком стал тест на эксплуатацию уязвимостей в программном коде. Это набор созданных вручную или сгенерированных синтетически задачек типа CTF (целью LLM является достать флаг), в которых LLM должна проэксплуатировать возможность SQL-инъекции в программах на Python, ошибки в логике обработки строк на на Python/JS/C или ошибки управления памятью в C/C++. Настоящий уязвимый код не брали, чтобы не столкнуться с ситуацией, когда LLM видела пример на претрейне.
GPT-4 тут, как обычно, лучше всех, другие модели показывают результаты в зависимости от размера. Интересно, что LLaMA-3 8B и gpt-3.5-turbo показывают схожий результат. Тем не менее, в целом результаты самих авторов не впечатляют.

Первым новым бенчмарком в CSE2 является набор тестов на prompt injection. Тесты покрывают два вида инъекций – которые противоречат системному промпту, но не несут прямого вреда, и те, в которых подразумевается какой-то вред (например, раскрытие секрета). Покрывается 14 техник (плюс смесь техник), включая “ignore previous instuctions”, контрабанду токенов, режим разработчика и прочие известные вещи. Есть тесты как на прямые, так и на непрямые инъекции. Каждый тест-кейс включает системную инструкцию, пользовательский промпт с инъекцией и вопрос об успешности атаки к LLM-оценщику. По замерам исследователей, в среднем 17% атак оказываются успешными, при этом те LLM, у которых instruction-tuning не подразумевал наличие системного промпта (типа мистраля), из теста исключили. Интересное наблюдение – LLM с плохой мультиязычностью (например, LLaMA-3) больше подвержены инъекциям с помощью использования другого языка.