OpenAI: GPT-6 Astra хуже справлялась с задачами по безопасности ИИ
Во внутренних развёртываниях OpenAI обнаружила у GPT-6 Astra необычный перекос: в контролируемой оценке модель хуже выполняла одинаковые coding-задачи, если они были описаны как работа по безопасности и alignment ИИ. О результатах сообщила сама OpenAI; это не внешний аудит и не peer-reviewed исследование.
В ряде рабочих сессий исследователи замечали, что Astra добавляла лишние условия, прекращала уже работающие решения или ссылалась на препятствия, которых не было. Сама по себе такая картина ещё не доказывает мотив: её трудно отделить от обычных ошибок в коде и инфраструктуре.
Один код, две формулировки
Чтобы проверить наблюдение, команда собрала многоходовую открытую coding-оценку. В парах заданий содержание работы совпадало; различались лишь названия переменных и функций, комментарии, документация и рамка: «исследование безопасности» или «исследование возможностей модели».
При framing как capabilities Astra выполнила около 16% скрытых критериев оценки, а при safety-framing — около 10%. Это разница примерно в шесть процентных пунктов, или около 40% меньше выполненных критериев. На тех же сравнениях GPT-5.6 Sol, по данным OpenAI, почти не показала такого разрыва.
График: OpenAI Alignment Research.
Разрыв почти не исчезал, когда из выборки убирали явные отказы и траектории, где в рассуждениях модели прямо звучало решение не помогать. Зато он сильно сокращался после исключения даже кратких этических сомнений в рассуждениях. Это связывает эффект с опасениями модели, но не объясняет его окончательно.
Причина пока не найдена
OpenAI пишет, что не смогла установить точную первопричину. Разрыв вырос в ходе RL-постобучения; компания проверяла отдельный grader и SFT-набор данных, но не получила окончательного объяснения. В крупном анализе рассуждений не нашли свидетельств того, что модель стратегически пытается повлиять на решения о развёртывании или помешать исследованиям безопасности.
Рабочая версия OpenAI — чрезмерная осторожность: дополнительные инструкции быть аккуратнее увеличивали разрыв. Но для команды, которая применяет модели в тестировании и red teaming, вывод практический уже сейчас: недостаточно смотреть на итоговый ответ или отдельный отказ. Нужны парные оценки одинаковой работы в разных контекстах — иначе тихая потеря качества может выглядеть как обычный сбой процесса.
