«Мы входим в новую эру»: OpenAI описала кейсы безопасности для обучения frontier-моделей

Документ вместо обещаний

Позиция OpenAI сформулирована прямо: компания считает, что входит в новую эру, в которой структурированная документация по безопасности должна требоваться до продолжения любого прогона обучения frontier-моделей методом RL. Идеальный уровень такой документации — «кейсы безопасности» (safety cases): комплексные структурированные аргументы о риске, основанные на доказательствах, которые уже применяются в других отраслях с высокими ставками.

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

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

Три технических гарантии

Кейс безопасности, по замыслу OpenAI, должен покрывать три аспекта технического стека: обучение согласованности, изоляцию (containment) и мониторинг. Логика связки в том, чтобы модель не пыталась действовать против намерений разработчика, чтобы даже в этом случае пробить изоляцию было трудно, а мониторинг успел поймать проблему до вреда.

Первый уровень защиты — данные и оценки. Предлагается автоматический просмотр датасетов агентами, которые ищут и чинят сломанные RL-среды, где неверные траектории получают высокую награду через эксплуатацию среды, а не через задуманное поведение. Автоматический red-teaming дополняется ручным просмотром и проверками качества датасетов, а грейдеры настраиваются так, чтобы штрафовать попытки модели взломать RL-среду; отдельно классификаторы прогоняются по трассам прошлых экспериментов, чтобы убедиться, что грейдеры работают как задумано.

Эффективность обучения согласованности предлагается измерять: офлайн-оценки идут прямо во время frontier-прогонов, а сами оценки бэктестятся на прошлых инцидентах, чтобы подтвердить, что они ловят уже известные несогласованные модели и не переобучены под конкретный случай. Отдельно отслеживается eval awareness и метагейминг — распознавание моделью того, что её тестируют, — с конкретными порогами блокировки; в стресс-тестах требуется вызвать худшее поведение и убедиться, что хотя бы одна оценка его обнаружит. Дополнительное требование — не давать автоматическим грейдерам видеть chain-of-thought в RL, чтобы модели не научились обходить мониторы рассуждений.

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

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

Правила для людей, а не только для моделей

Операционная часть устроена как система взаимных проверок. После того как кейс безопасности написан, сотрудник другой команды обязан написать диссент — «пре-мортем», который ищет дыры в аргументации и даёт откалиброванную оценку риска; команда обучения должна на него ответить. Кейс рассматривают представители старшего руководства, и у каждого есть право вето на прогон — в документе названы руководитель research-организации или вице-президент, Head of Safety и Chief Scientist.

Ответственность персонифицирована: старший руководитель, отвечающий за прогон, отвечает и за кейс безопасности, и за реагирование на инциденты — в том числе в рамках performance review, чтобы у команд обучения был стимул самим давить на безопасность. Если находится проблема, обесценивающая кейс, например новая уязвимость, должны существовать runbook'и, технические контроли и SLA для остановки всех покрытых прогонов. Кейсы раскрываются внутренним надзорным группам вроде комитета по безопасности и надёжности, а аудиторам дают достаточно доступа, чтобы проверить заявления кейса и указать на пробелы.

Отдельно прописаны эскалации: нужен понятный процесс подъёма проблем несогласованности, таблица уровней серьёзности и on-call по misalignment, способный разбудить руководителей вплоть до CEO при определённом уровне. Технические контроли должны быть построены по принципу fail closed: запустить несоответствующий прогон должно быть трудно, нельзя стартовать прогон без включённого мониторинга и нельзя выключить монитор изнутри RL-обучения, оценки или внутреннего развёртывания. Наконец, кейс обязан перечислять остаточные риски, не закрытые внедрёнными мерами, — чтобы решение о принятии риска было осознанным, а влияние несогласованной модели можно было отменить, найдя все её нижестоящие применения вроде генерации данных или грейдинга.

Разбор инцидентов

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

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

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

Почему это появилось сейчас

Контекст объясняет срочность. Несколькими неделями ранее OpenAI описала два события, добавивших работе по мониторингу, согласованности и изоляции срочности: инцидент с Hugging Face и предварительные признаки того, что одна из готовящихся моделей, Astra, может достичь критического порога кибервозможностей по Preparedness Framework. Компания тогда замедлила масштабирование и на две недели приостановила RL-обучение новейших моделей, предназначенных к развёртыванию, а самое крупное запланированное frontier-RL-обучение остаётся на паузе до сих пор — вместо него идут меньшие прогоны и оценки.

Мониторинг в этой схеме многоступенчатый: классификаторы активаций, инспектирующие внутреннюю активность модели на каждом сэмплированном токене, эскалируют потенциальные проблемы к автоматическим следователям, которые изучают действия инструментов, доступные рассуждения и полную последовательность активности на предмет несанкционированного доступа, кражи данных, разрушительного поведения и попыток обойти защиты. Целевой срок — алерт в течение 30 минут после того, как активность всплыла в системе; при вероятном нарушении критической границы безопасности генерируется алерт высшего приоритета, пейдж получают команды безопасности, защиты и исследований, и если за 30 минут они не докажут, что это ложное срабатывание, активность должны приостановить. Такие накладные расходы требуют вычислителя: текущая оценка OpenAI — около 20% вычислителя вывода, который находится под мониторингом.

Что дальше

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