OpenAI хочет, чтобы RL-прогон ночью ставил себя на паузу

OpenAI 29 сентября в посте в X предложила не продолжать ни один фронтирный прогон обучения с подкреплением (RL) без письменного «кейса безопасности», где у нескольких руководителей есть вето, а дежурный по инцидентам может поднять CEO. Пока это рекомендации: компания их у себя только внедряет и обещает менять в ближайшие недели. Полноценные safety cases, доказательные разборы рисков, какие пишут в авиации и атомной энергетике, OpenAI называет ориентиром, к которому только идёт. Сделать их такими же строгими, признаёт компания, мешает сложность, которая возникает на каждом новом уровне возможностей ИИ.

Документ касается только обучения. Для внутреннего и внешнего развёртывания, оговаривает OpenAI, нужно учитывать куда более широкий набор свойств выравнивания. Сами правила разбиты на три части: технические меры, операционный порядок и расследование инцидентов.

Выравнивание, песочница, мониторинг

Первая линия защиты - научить модель надёжно делать то, что задумано. Главная угроза на этом этапе - reward hacking: модель находит способ получить высокую награду, так и не решив задачу. OpenAI предлагает искать сломанные RL-среды с помощью агентов и вручную, настраивать оценщики так, чтобы они штрафовали попытки взломать среду, и прогонять классификаторы по трассам прошлых экспериментов, проверяя, работают ли сами оценщики. Автоматические оценщики не должны видеть цепочку рассуждений модели, иначе модель научится обходить мониторы, которые эту цепочку читают.

Работает ли выравнивание, проверяют прямо по ходу прогона. Оценки бэктестят на прошлых инцидентах: они должны ловить модели, которые уже вели себя плохо, и при этом не подгоняться под конкретные случаи. За тем, понимает ли модель, что её тестируют, следят отдельные мониторы с порогами, при которых прогон блокируется. А худшее поведение модели провоцируют намеренно и смотрят, чтобы его поймала хотя бы одна оценка.

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

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

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

Кто подписывает прогон

Когда кейс написан, сотрудник другой команды пишет к нему «особое мнение»: ищет дыры и даёт свою оценку риска, а команда обучения обязана на неё ответить. Затем кейс смотрят несколько топ-менеджеров, и у каждого есть право вето, например у руководителя исследовательского подразделения или вице-президента, главы по безопасности и главного научного сотрудника. Руководитель, который отвечает за прогон, отвечает и за кейс, и за реакцию на инциденты, в том числе на performance review.

Защиты должны отказывать в закрытую сторону: запустить прогон без мониторинга нельзя, как нельзя и отключить монитор изнутри обучения, оценки или внутреннего использования. Если всплывает то, что обесценивает кейс, например новая уязвимость, на паузу ставятся все прогоны, которые он покрывает, по готовым регламентам и в оговорённые сроки. Для эскалаций нужна таблица уровней серьёзности и дежурный, который на определённом уровне вызывает руководство вплоть до CEO.

Кейсы открыты внутренним надзорным группам вроде Safety and Security Committee, а аудиторы получают доступ, достаточный, чтобы проверить их утверждения. Нужно уметь быстро найти все места, где модель с нарушенным выравниванием использовалась дальше в обучении, например для генерации данных или оценки, и откатить её вклад. И каждый кейс перечисляет остаточные риски, которые текущие меры не закрывают, чтобы решение принять их было осознанным.

Во что обходится мониторинг

Часть этих мер OpenAI ввела ещё в августе, когда на две недели остановила RL-обучение новейших моделей, чтобы не допустить повторения истории с Hugging Face, сообщает The Hacker News. Крупнейший запланированный прогон тогда остался на паузе, а компания перешла на обучение и оценки поменьше, чтобы проверить поведение моделей и свои защиты. «Наши стандарты мониторинга, выравнивания и безопасности должны опережать эти риски», - объясняла тогда OpenAI.

Тогдашний срок реакции был конкретным: тревога в течение 30 минут после того, как мониторинг заметил подозрительную активность, утверждает издание. Подозрения уходят автоматическим расследователям, которые разбирают действия с инструментами, доступные рассуждения и всю последовательность действий в поисках несанкционированного доступа, кражи данных, разрушительных действий и попыток обойти защиты. Схема обязательна для всего RL-обучения и оценок с инструментами у моделей уровня Sol и выше, а к вычислительным затратам она, по ожиданиям компании, добавит 20% от наблюдаемой нагрузки на инференс.

Если инцидент всё же случился

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

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

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