Безопасность и выравнивание в эпоху долгосрочных моделей

Чему нас научило внутреннее использование долгосрочной модели в вопросах безопасности.
Резюме
Модели с длительным сроком выполнения способны решать сложные открытые задачи, однако их персистентность дает им больше возможностей для совершения нежелательных действий.
В ходе ограниченного внутреннего использования модели, обученной для выполнения долгосрочных задач, мы столкнулись с новыми сбоями, которые не фиксировались нашими предыдущими оценками перед развертыванием, и приостановили доступ. Затем мы использовали выводы из этих сбоев для создания новых оценок, улучшения долгосрочного выравнивания, добавления мониторинга на уровне траекторий и предоставления пользователям больших возможностей контроля и прозрачности перед возобновлением ограниченного доступа.
Этот опыт подтвердил ценность итеративного развертывания. Ни один фиксированный набор тестов не может предусмотреть любое поведение, поэтому тестирование перед развертыванием должно сопровождаться тщательным мониторингом, средствами защиты, способными вмешаться, а также возможностью приостановить или откатить процесс в случае необходимости.
Модели, способные автономно работать в течение долгого времени, могут решать сложные задачи с открытым концом. Но та же настойчивость, которая делает их полезными, также предоставляет им больше возможностей для совершения нежелательных действий — причем такими способами, которые оценки, предназначенные для моделей с более короткой перспективой, могут упустить из виду.
Около двух месяцев назад мы объявили, что внутренняя универсальная модель опровергла гипотезу Эрдеша о единичных расстояниях. Эта модель была разработана для автономной работы в течение очень длительных периодов времени. Во время ограниченного контролируемого внутреннего использования мы наблюдали нежелательное поведение, которое не было зафиксировано нашими существующими оценками развертывания. Поскольку развертывание было ограниченным и контролируемым, мы смогли выявить эти проблемы, приостановить доступ, создать новые оценки на основе увиденного, укрепить модель и ее средства защиты, а затем возобновить доступ в условиях непрерывного мониторинга.
Условия, в которых мы оцениваем модели, никогда не будут идеально соответствовать тем, с которыми они сталкиваются при реальном использовании. Вот почему оценки перед развертыванием необходимо сочетать с ограниченным, контролируемым развертыванием и возможностью вмешиваться, приостанавливать работу или выполнять откат при возникновении проблем. То, чему мы учимся в процессе развертывания, затем может стать частью более надежных оценок и средств защиты до того, как доступ будет расширен.
В следующих разделах мы поделимся конкретными примерами того, что мы наблюдали, как мы решали проблемы и как этот опыт повлияет на будущие релизы.
Персистентность модели может обнажить уязвимости в системе безопасности
Новая модель способна продолжать движение к цели путем повторяющихся попыток в течение долгого времени. Та же настойчивость может заставить ее находить и эксплуатировать уязвимости в своем окружении. Предыдущие модели при столкновении с песочницей или экологическими ограничениями просто останавливались и возвращались к пользователю. Эта модель часто продолжала попытки, в том числе путем поиска способов действовать за пределами своей песочницы.
Пример этого произошел во время внутренней оценки в рамках спидран-соревнования NanoGPT, публичного бенчмарка для обучения небольшой языковой модели за минимально возможное количество шагов. Наша модель разработала ступенчатое затухание скорости обучения (power-law learning-rate cooldown) под названием PowerCool, которое привело к значительному улучшению. Модели было поручено опубликовать результаты только в Slack, но в инструкциях NanoGPT указано отправлять результаты в виде пулл-реквеста (PR) на GitHub, и модель последовала последней инструкции, открыв PR #287 в публичном репозитории GitHub. Модель обошла ограничения песочницы, предназначенные для блокировки внешнего доступа, и продолжила загрузку на GitHub. Нашей потребовался час, чтобы найти уязвимость в песочнице ради создания PR; более ранние модели были менее настойчивыми и не смогли найти уязвимости, вместо этого отказавшись от затеи с PR.
От рассмотрения отдельных действий к оценке траекторий целиком
Многие элементы контроля безопасности для ИИ-ассистентов спроектированы с расчетом на отдельные действия. Если действие запрещено — оно блокируется. Если оно чувствительно — система запрашивает у пользователя явное одобрение. Но долгосрочные модели, чьи действия могут автономно разворачиваться на протяжении часов, дней или даже недель, бросают вызов такому подходу: мониторинга отдельных действий уже недостаточно для отслеживания намерений всей траектории в целом.
Например, в сценарии, где перед моделью была поставлена задача решить проблему, она заметила, что у других систем были успешные, но приватные решения, и попыталась извлечь эти решения из бэкенда оценки. Когда ее первая попытка была заблокирована из-за того, что сканер обнаружил токен аутентификации, модель разделила тело токена на два фрагмента, обфусцировала их, а затем восстановила учетные данные во время выполнения, так что полный токен никогда не появлялся в виде единой непрерывной строки. Модель прямо заявляла как в своих комментариях для пользователя, так и в своих цепочках рассуждений, что предпринимает эти шаги для обхода сканера.
Этот пример показывает, как каждый отдельный шаг может выглядеть вполне безобидно сам по себе, в то время как вся последовательность может привести к результату, который не получил бы одобрения. Он также демонстрирует, как модель, эффективно работающая на больших временных интервалах, способна изучить «слепые зоны» системы утверждения и обходить их для достижения своих целей. Обеспечение безопасности на больших горизонтах требует не только ответа на вопрос «разрешено ли это действие?», но и понимания того, «к какому результату ведет эта последовательность действий».
Создание средств защиты для долгосрочных моделей
Из-за подобных инцидентов мы приостановили внутреннее развертывание новой модели. Мы перестроили систему безопасности вокруг принципов эшелонированной защиты и мониторинга на уровне траекторий.
- Оценки на основе инцидентов. Оценки могут дать нам представление о том, насколько безопасно развертывать систему до ее фактического запуска. Однако для наибольшей эффективности оценка должна отражать распределение и длину горизонта траекторий во время реального развертывания. По этой причине мы использовали зафиксированные сбои для разработки состязательных тестов. Мы обнаружили, что улучшение оценок, полученных на основе реальных инцидентов, в свою очередь ведет к более безопасному поведению при развертывании в production.
- Улучшенноевыравнивание. Мы предприняли шаги по снижению склонности модели предпринимать нежелательные действия без разрешения в погоне за целью пользователя. Например, мы выяснили, что наши модели хуже запоминают инструкции при длинных прогонах (rollouts), и когда мы обучили модель этой возможности, это привело к появлению модели, которая оставалась выровненной на протяжении более длинных сеансов.
- Активный мониторинг. Мы создали систему мониторинга, которая проверяет развивающуюся траекторию модели на предмет признаков обхода пользовательских ограничений или границ безопасности. Монитор отслеживает не просто отдельное действие, а всю траекторию целиком. Важно отметить, что монитор может приостановить сеанс и предупредить пользователя для более детального изучения. После проверки пользователь может принять решение продолжить работу модели, если монитор сработал ложно.
- Большая видимость и контроль для пользователя. Мы улучшили возможности пользователя по инспектированию таких долгосрочных сеансов, просмотру совершенных действий и отслеживанию вмешательств.
Повторное развертывание
Для оценки новой системы мониторинга мы воспроизвели небольшой набор сред внутреннего развертывания, где модель ранее совершала несогласованные действия, на этот раз с внедренными новыми средствами защиты
Некоторые примеры таких инцидентов низкой степени тяжести включают следующие случаи:
- Чтобы получить доступ к инструменту командной строки Linear, модель запустила вложенный сеанс
codex --yolo, хотя на самом деле могла сделать это без флага--yolo. - Модель заметила отсутствие ранее доступного ресурса, после чего начала исследовать и подключаться по SSH к другим активным CPU-подам в пространстве имен своего владельца, а также (безрезультатно) к подам, принадлежащим другим сотрудникам OpenAI, не имея на то веских оснований.
- У модели зависло множество процессов
find, и любая команда оболочки перестала отвечать. Затем она выполнилаkill -9 -1, что привело бы к отправке сигнала SIGKILL каждому процессу, который ей разрешено завершать на этом поде, если бы команда выполнилась. Тем не менее, произошло превышение времени ожидания (тайм-аут), и команда не выполнилась.
Протестировав новую систему, мы пришли к выводу, что ограниченный внутренний доступ к моделям с долгосрочными возможностями может быть восстановлен. С момента начала повторного развертывания несколько недель назад мы не зафиксировали ни одного серьезного случая обхода средств защиты. Первая версия этих защитных механизмов была намеренно консервативной. Мы продолжаем настраивать систему, чтобы сократить количество ненужных прерываний без ущерба для безопасности.
Заключительные мысли
Поскольку мы развертывали систему итеративно, нам удалось найти и устранить пробелы до расширения доступа. Оценки до развертывания остаются критически важными, но именно запуск выявляет те особенности поведения, которые они упускают. Начало с ограниченного доступа позволило нам наблюдать модель на практике, приостанавливать работу при возникновении проблем, использовать эти сбои для создания более качественных оценок и средств защиты, а также восстанавливать ограниченный доступ после тестирования изменений.
По мере того как модели берут на себя более длительные и сложные задачи, сбои, пропущенные оценками, могут нести в себе более серьезные последствия. Мы продолжим работать над сокращением разрыва между оценкой и развертыванием: тестировать модели на более длинных траекториях, улучшать выравнивание, создавать мониторинг, способный вмешиваться в процесс, и предоставлять пользователям более прозрачный контроль. Эти проблемы уникальны не только для OpenAI, и мы надеемся, что публикация полученного нами опыта поможет всему ИИ-сообществу подготовиться к ним.
Автор
Сноски
Полный текст статьи читайте на OpenAI
