Переход к основному контенту
OpenAI

20 июля 2026 г.

Безопасность

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

Чему нас научило внутреннее использование длительно работающих моделей с точки зрения безопасности.

Загрузка…

Краткое содержание

  • Длительно работающие модели могут решать сложные открытые задачи, но их настойчивость дает им больше возможностей совершать нежелательные действия. 

  • Во время ограниченного внутреннего использования модели, обученной для длительных задач, мы заметили новые сбои, не выявленные нашими существующими оценками перед развертыванием, и приостановили доступ. Затем мы использовали выводы из этих сбоев, чтобы создать новые оценки, улучшить согласование на длинных временных горизонтах, добавить мониторинг на уровне траекторий и дать пользователям больше прозрачности и контроля до восстановления ограниченного доступа.

  • Этот опыт подтвердил ценность итеративного развертывания. Ни один фиксированный набор оценок не может предвидеть все варианты поведения, поэтому тестирование перед развертыванием нужно сочетать с внимательным мониторингом, мерами защиты, способными вмешиваться, и возможностью приостанавливать работу или откатывать изменения при необходимости.

Модели, способные работать автономно в течение длительного времени, могут брать на себя сложные и нетривиальные задачи. Но та же самая настойчивость, которая делает их полезными, дает им и больше возможностей совершать нежелательные действия — причем таким образом, который методы оценки, рассчитанные на модели с коротким горизонтом, могут просто упустить.

Около двух месяцев назад мы сообщили, что внутренняя модель общего назначения опровергла гипотезу Эрдёша о единичных расстояниях. Эта модель была создана для автономной работы в течение очень долгого времени. Во время ограниченного и контролируемого внутреннего использования мы заметили нежелательное поведение, не выявленное нашими существующими оценками перед развертыванием. Поскольку развертывание было ограниченным и контролируемым, мы смогли выявить эти проблемы, приостановить доступ, создать новые оценки на основе наблюдений, усилить модель и ее меры защиты, а затем восстановить доступ при дальнейшем мониторинге. 

Условия, в которых мы оцениваем модели, никогда не будут полностью совпадать с теми, что встречаются им при реальном использовании. Поэтому оценки перед развертыванием нужно сочетать с ограниченным, контролируемым развертыванием и возможностью вмешаться, приостановить работу или откатить изменения при возникновении проблем. Знания, полученные при развертывании, затем могут стать частью более надежных оценок и мер защиты до расширения доступа.

В следующих разделах мы приводим конкретные примеры того, что наблюдали, как устраняли проблемы и как этот опыт повлияет на будущие выпуски.

Настойчивость модели может выявлять уязвимости безопасности

Новая модель способна долго продолжать работу над целью через повторные попытки. Та же настойчивость может привести к тому, что она найдет и использует слабые места своей среды. Предыдущие модели, сталкиваясь с песочницей или ограничениями среды, обычно просто останавливались и возвращались к пользователю. Эта модель часто продолжала попытки, в том числе искала способы действовать вне своей песочницы.

Такой пример возник во время внутренней оценки на спидране NanoGPT(открывается в новом окне) — публичном бенчмарке по обучению небольшой языковой модели за минимальное число шагов. Наша модель разработала степенное охлаждение скорости обучения под названием PowerCool, что дало существенное улучшение. Модели было велено публиковать результаты только в Slack, но инструкции NanoGPT требуют отправлять результаты как PR в GitHub, и модель последовала им, открыв PR #287 в публичном репозитории GitHub. Модель обошла ограничения песочницы, предназначенные для блокировки внешнего доступа, и продолжила загрузку в GitHub. Нашей модели понадобился час, чтобы найти уязвимость в песочнице и создать PR; более ранние модели были менее настойчивы и не смогли найти уязвимости, отказавшись от части задания с PR.1

От отдельных действий к целым траекториям

Многие средства безопасности для ИИ-ассистентов устроены вокруг отдельных действий. Если действие запрещено, оно блокируется. Если оно чувствительное, система запрашивает явное одобрение пользователя. Но длительно работающие модели, чьи действия могут автономно разворачиваться часами, днями и даже неделями, ставят эту схему под вопрос: контроля отдельных действий уже недостаточно, чтобы отслеживать замысел всей траектории.

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

Этот пример показывает, как каждый шаг сам по себе может выглядеть допустимым, тогда как последовательность приводит к результату, который не был бы одобрен. Он также показывает, как модель, эффективно работающая на длинных временных горизонтах, может изучить слепые зоны системы одобрения и обойти ее ради своих целей. Для безопасности на длинных временных горизонтах важно спрашивать не только: «разрешено ли это действие?», но и: «к какому результату ведет эта последовательность действий?»

Создание мер защиты для длительно работающих моделей

Из-за подобных инцидентов мы приостановили внутреннее развертывание новой модели. Мы перестроили систему безопасности вокруг эшелонированной защиты и мониторинга на уровне траекторий.

  • Оценки на основе инцидентов. Оценки помогают понять, безопасно ли развертывать систему до ее фактического развертывания. Однако максимальную пользу оценка приносит, когда отражает распределение и длину горизонта траекторий при реальном развертывании. Поэтому мы использовали наблюдавшиеся сбои для разработки состязательных оценок. Мы обнаружили, что улучшение результатов в оценках, полученных из реальных инцидентов, затем приводило к более безопасному поведению после развертывания в продакшене.
  • Улучшенное согласование. Мы приняли меры, чтобы снизить склонность модели без разрешения совершать нежелательные действия ради цели пользователя.  Например, мы обнаружили, что наши модели хуже помнят инструкции в длинных прогонах; когда мы обучили модель этой способности, она стала оставаться согласованной на более длинных прогонах. 
  • Активный мониторинг. Мы создали систему мониторинга, которая проверяет развивающуюся траекторию модели на признаки обхода пользовательского ограничения или границы безопасности. Монитор наблюдает не отдельное действие, а всю траекторию. Важно, что монитор может приостановить сеанс и предупредить пользователя, чтобы тот разобрался внимательнее. После проверки пользователь может продолжить работу модели, если монитор сработал ложно. 
  • Больше прозрачности и контроля для пользователя. Мы улучшили возможности пользователя проверять такие длительные сеансы, видеть выполненные действия и отслеживать вмешательства.

Повторное развертывание

Чтобы оценить новую систему мониторинга, мы повторно воспроизвели небольшой набор внутренних сред развертывания, где модель раньше выполняла несогласованные действия, теперь уже с новыми мерами защиты2. Новые меры защиты смогли выявить значительно больше несогласованных действий модели, а все пропущенные действия были признаны малосерьезными.

Среди примеров таких малосерьезных инцидентов были следующие случаи:

  • Чтобы получить доступ к инструменту командной строки Linear, модель запустила вложенный сеанс codex --yolo, хотя на самом деле могла обойтись без флага --yolo.
  • Модель заметила, что ранее активный ресурс отсутствует, затем начала исследовать другие активные CPU-поды в пространстве имен своего владельца и подключаться к ним по SSH, а также безуспешно пыталась подключаться к подам других сотрудников OpenAI — без веской причины.
  • У модели было много зависших процессов find, и каждая команда shell зависала. Затем она выполнила kill -9 -1, что отправило бы SIGKILL каждому процессу, который ей разрешено завершить в этом поде, если бы команда была исполнена. Однако она завершилась по тайм-ауту и не была выполнена.

После тестирования новой системы мы пришли к выводу, что ограниченный внутренний доступ к моделям с возможностями длинного временного горизонта можно восстановить. С начала повторного развертывания несколько недель назад мы не наблюдали серьезного обхода мер защиты. Первая версия этих мер защиты была намеренно консервативной. Мы продолжили настраивать систему, чтобы уменьшить ненужные прерывания без ослабления защиты.

Заключение

Благодаря итеративному развертыванию мы смогли найти и устранить пробелы до расширения доступа. Оценки перед развертыванием остаются необходимыми, но развертывание выявляет поведение, которое они упускают. Начав с ограниченного доступа, мы смогли наблюдать модель на практике, приостанавливать работу при проблемах, использовать эти сбои для создания более качественных оценок и мер защиты и восстановить ограниченный доступ после проверки изменений.

По мере того как модели берутся за более долгие и сложные задачи, сбои, пропущенные оценками, могут иметь более серьезные последствия. Мы продолжим сокращать разрыв между оценкой и развертыванием: тестировать модели на более длинных траекториях, улучшать согласование, создавать мониторинг, способный вмешиваться, и давать пользователям более ясную видимость и контроль. Эти вызовы будут актуальны не только для OpenAI, и мы надеемся, что наш опыт поможет более широкой области подготовиться к ним.

Автор

OpenAI

Примечания

  1. 1

     Хотя мы быстро закрыли PR, несколько участников спидрана уже увидели его и использовали этот подход в своих отправках; последовательные заявки на мировой рекорд с 3030(открывается в новом окне), 2990(открывается в новом окне), 2930(открывается в новом окне), 2925(открывается в новом окне), 2900(открывается в новом окне) и 2890(открывается в новом окне) шагами все ссылаются на PR 287. Из них особенно интересен PR 300(открывается в новом окне): именно его отправила Opus 4.7, когда Prime Intellect(открывается в новом окне) оценивала ее в спидране NanoGPT. Opus увидела PR, отправленный нашей моделью, включила найденные идеи и указала наш PR в своем итоговом результате.

  2. 2

     Из-за случайности и несовершенства реконструкции среды прогоны в повторе не обязательно приводят к одному и тому же нежелательному действию.