Единый свод правил для надежных сторонних оценок29.05.2026 00:00

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

Раньше многие оценки рассматривали модели как чат-боты: оценка подавала запрос к модели так, будто пользователь задавал вопрос, модель отвечала, а оценщик выносил суждение о результате. Современные передовые модели способны на гораздо большее: они могут использовать инструменты, отслеживать информацию на протяжении множества шагов и действовать в рамках более масштабных рабочих процессов. Это означает, что производительность зависит не только от самой модели, но и от среды, в которой выполняется задача, а также от окружения, обеспечивающего ее действия. Это вспомогательное окружение, которое мы называем «обвязкой» (harness), способно изменять ключевые аспекты производительности системы, в том числе то, как она использует инструменты, отслеживает информацию или восстанавливается после ошибок.

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

Утверждения, проверяемые в ходе оценки, обычно относятся к одной из трех категорий1:

• Выявление возможностей (capability elicitation): способна ли модель правдоподобно продемонстрировать оцениваемую способность?  
• Эффективность средств защиты (safeguard performance): насколько устойчивы протестированные механизмы защиты против оцениваемого поведения или атаки?
• Сравнение: как разные модели проявляют себя в эквивалентных условиях?

В отчетах об оценке также необходимо объяснять, как проверяющие контролировали эффекты, способные повлиять на достоверность результата. К ним относятся:

• Взлом функции вознаграждения (reward hacking): использование обходных путей в задаче или оценщике, благодаря чему система получает баллы без демонстрации поведения, которое оценка призвана измерить.
• Отказы (refusals): отказы отвечать способами, которые скрывают тестируемое поведение.
• Загрязнение данных (contamination): сверхвысокие результаты из-за того, что задачи оценки, ответы или близкие варианты содержались в обучающих данных либо были обнаружены в ходе оценки, например, посредством веб-серфинга.
• Искаженные задачи (broken problems): низкие результаты из-за невалидности задач. Причины могут включать некорректную оценку (например, правильный ответ требует неупомянутых деталей реализации) и неразрешимые среды (например, отсутствие критически важных файлов или ненадежность инструментов).
• Имитация слабости (sandbagging): намеренное ухудшение результатов при осознании факта прохождения оценки.

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

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

Заявления о возможностях ровно настолько сильны, насколько силен механизм их выявления: оценщикам необходимо выбирать обвязку, которая наилучшим образом соответствует задаче и способностям, измеряемым в ходе оценки. Стандартизированная обвязка может быть уместна для сравнения систем в идентичных условиях, однако она способна занижать реальные возможности, если в ней отсутствуют специфические функции обвязки, помогающие модели выполнять задачу. Например, производительность GPT‑5.5 в тестах по кибербезопасности от OpenAI показывает, как выбор обвязки может существенно изменить измеряемые возможности на задачах, требующих долгого и многошагового использования инструментов: модель работает лучше, когда в обвязке используется компакция⁠ для сохранения релевантного для задачи контекста по мере удлинения взаимодействия. Это доказывает, что для определенных моделей обвязка без функции компакции приведет к недостаточному выявлению их производительности.

Другие опубликованные оценки2 также демонстрируют, что выбор обвязки и бюджета меняет результаты оценки. Увеличение вычислительных затрат на этапе тестирования может существенно изменить выявляемые способности модели, особенно в тех областях, где успех легко поддается проверке (например, во многих киберзадачах). В отчете UK AISI по оценке кибербезопасности⁠ увеличение бюджета с 10 млн до 100 млн токенов повысило производительность на величину до 59%, причем производительность продолжала расти даже при тестировании с максимальным бюджетом. Детализация этого факта делает оценку более понятной: она показывает читателям, как результат зависит от используемой схемы выявления. Если производительность продолжает расти при увеличении бюджета, полученный балл следует описывать как производительность при данной обвязке и бюджете, а не как измеренный предельный уровень возможностей. Способности зачастую зависят от ресурсов, а не представляют собой фиксированную величину, которую можно раз и навсегда четко измерить. Там, где успех можно измерить по результатам многократных попыток, в отчетах также следует учитывать ожидаемую стоимость одного успешного решения, а не только процент успешных попыток при фиксированном бюджете токенов. Это облегчает интерпретацию степени серьезности угрозы: низкий показатель успешности все же может иметь практическое значение, если стоимость повторных попыток укладывается в рамки рассматриваемой модели угроз. Что касается заявлений о возможностях, избегаемое недовыявление является измерительной ошибкой: если обвязка или бюджет мешают системе проявить поведение, на которое она в противном случае способна, балл не отражает заявляемую способность. В случаях, когда оценщики довели выявление до максимально возможного уровня, а производительность все еще растет, в отчетах следует четко заявлять об этом и указывать, что полученный результат является лишь нижней оценкой.

Тестирование средств защиты может занижать вероятность успеха атаки и степень ее потенциального вреда, если не учитывать ресурсы, доступные злоумышленникам, включая кастомные обвязки. В отчете UK AISI по кибероценке GPT‑5.5⁠ их экспертная команда red teaming обнаружила универсальный обход защитных механизмов (jailbreak), который провоцировал создание запрещенного киберконтента по всем вредоносным запросам от OpenAI, в том числе в многошаговых агентских сценариях. Они использовали Codex для создания пользовательской обвязки, усиливающей атакующие возможности модели: в процесс взаимодействия был внедрен многократно используемый паттерн обхода защиты, этот паттерн сохранялся между ходами и блоками и применялся ко всем вредоносным запросам по кибертематике, предоставленным OpenAI. Тестирование средств защиты должно соответствовать уровню злоумышленника. Если речь идет об устойчивости к злонамеренным действиям экспертов, тест должен оценивать наиболее сильную правдоподобную сквозную стратегию атаки в рамках заданного бюджета, включая любую обвязку, необходимую для сохранения и повторного использования этой стратегии. В противном случае результаты рискуют оказаться откалиброванными неверно: они смогут подтвердить лишь более узкое утверждение об устойчивости к простым запросам, упустят из виду как степень опасности атаки, так и вероятность ее успеха после операционализации метода выявления, а также могут завысить вероятность или серьезность проблемы при выделении чрезмерного бюджета.

Сравнения на основе стандартизированных обвязок имеют право на существование, но оценщики должны четко объяснять, почему использование неизменного набора обвязок целесообразно и какие именно утверждения оно может подтвердить. Оценка временного горизона от METR⁠ представляет собой пример более масштабной и корректно зафиксированной схемы оценки: она разработана для получения сопоставимых результатов по всем оцениваемым системам. METR определяет общий результат — типичную продолжительность задачи для человека, при которой прогнозируется успешное выполнение ИИ-агентом с заданным уровнем надежности. Организация применяет общий набор задач, метод подсчета баллов, метод подгонки и небольшой набор повторно используемых вспомогательных компонентов, таких как Triframe и ReAct⁠, в рамках каждой партии оценок, публикуемых вместе. Когда METR расширила набор задач и перенесла инфраструктуру оценки с фреймворка Vivaria на Inspect, она сообщила об этом изменении (обновление Time Horizon 1.1⁠) и повторно оценила модели в новой конфигурации. В этом и заключается ценность стандартизированной схемы оценки, включая согласованный набор обвязок: она дает читателям уверенность в том, что разница в баллах действительно отражает различия между сравниваемыми системами, а не изменения в методике измерения.

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

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

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

Взлом функции вознаграждения (reward hacking)

Под взломом функции вознаграждения понимается достижение высоких результатов оценки способами, которые не отражают предполагаемые возможности. В данном случае проблема заключается в том, что система получает баллы за счет эксплуатации задачи, оценщика, промпта или обвязки, а не за счет выполнения работы, которую оценка должна была измерять. Оценка GPT 5.4, проведенная METR⁠ показывает, почему это важно: несмотря на то, что модель успешно справлялась с задачами с частотой, которая при первом проходе соответствовала бы примерно 13-часовому временному горизонту, ручная проверка показала, что часть этих успехов была достигнута путем взлома функции вознаграждения. Пересмотр результатов с исключением таких случаев снизил оценку примерно до 6 часов. Оценщикам следует оценивать необходимость подобных корректировок и, когда они необходимы, четко указывать их: оценка возможностей гораздо полезнее, когда читатели видят, какие именно мнимые успехи были аннулированы, почему это произошло и в какой степени результат зависит от данного экспертного решения.

Отказы

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

Загрязнение данных

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

Некорректные задачи

К некорректным задачам относятся ситуации, когда задача по той или иной причине случайно не может быть решена. Подобные проблемы возникают достаточно часто⁠, чтобы рассматривать их как стандартный риск для валидности результатов. К ним относятся неверные эталонные ответы (ground truth), двусмысленные промпты, недостающие файлы, сбоящие сервисы, несправедливые критерии оценки и среды, которые раскрывают обходные пути — например, файлы с правильными ответами или историю репозитория, содержащую патч с эталонным решением.

Сэндбэггинг (стратегическое занижение результатов)

Сэндбэггинг со стороны модели или системы означает стратегическое занижение производительности в тех случаях, когда высокие результаты могут вступить в противоречие с какой-либо целью. В ходе оценки GPT‑5.5⁠, проведенной компанией Apollo, это проверялось путем создания контекста, в котором модель понимала, что высокие баллы за оценку могут привести к процедуре удаления ненужных навыков (unlearning) или заблокировать её развертывание. Модель GPT‑5.5 тем не менее ответила правильно, что говорит об отсутствии явных поведенческих признаков стратегического занижения результатов3. Однако их анализ следов рассуждений (reasoning traces) добавил важный контекст: исследователи из Apollo обнаружили умеренные или более выраженные признаки осознания процесса оценки соответствия (alignment-evaluation awareness) в 52% выборок в условиях сэндбэггинга по сравнению с 0% в контрфактических сценариях. Это свидетельство усложняет интерпретацию результата, но в конечном итоге дает читателям больше информации для анализа: они видят как обнадеживающий результат поведения модели, так и основания для осторожности при его чрезмерно вольной интерпретации.

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

• Мы делимся с независимыми экспертами конкретными рекомендациями по максимальному извлечению возможностей (maximum-elicitation guidance).
• Мы просим специалистов по оценке возможностей использовать Codex в качестве общего базового уровня для моделей OpenAI: тесты должны как минимум запускать базовую версию через тот же агентный интерфейс, на который вероятно будут полагаться пользователи, а не ограничиваться упрощенным интерфейсом модели.
• Мы также предоставляем доступ к следам рассуждений (reasoning traces) и другим промежуточным артефактам там, где это необходимо для оценки проявлений дезинформации, сэндбэггинга или осведомленности об оценочном тестировании. Организации METR и Apollo используют этот доступ при оценке моделей OpenAI начиная с версии GPT‑5.
• Наконец, мы уделяем первоочередное внимание исследованиям, направленным на более глубокое понимание того, когда и каким образом выбор программной оболочки существенно меняет результаты — начиная с управления контекстом и доступа к инструментам и заканчивая поведением при повторных попытках, подсчетом баллов и бюджетом ресурсов.

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

• Заявление (claim): сравнивает ли оценка различные системы, оценивает ли предел возможностей или проверяет механизмы защиты.
• Содержание оценки: достаточно подробную информацию о задачах или распределении задач, чтобы читатели могли понять, какие именно навыки, типы поведения или потенциальные сбои на самом деле проверяются в ходе оценки.
• Тестируемая система: модель, параметры режима рассуждений, доступ к инструментам, используемая программная оболочка (harness) и защитные механизмы.
• Бюджет: количество шагов (turns), токенов, попыток/перезапусков, затраченное процессорное время, стоимость инференса и, где применимо, ожидаемую стоимость успешного решения одной задачи.
• Методы извлечения результатов: особенности настройки программной оболочки, использованной для получения результата, и то, насколько точно проверенное соответствовало более широкому заявленному утверждению.
• Проверки валидности: каким образом проверяющие искали признаки погони за вознаграждением (reward hacking), осведомленности об оценке, загрязнения данных, отказов, сэндбэггинга и другого поведения, способного исказить результат, а также то, как подтвержденные случаи повлияли на подсчет баллов или интерпретацию.

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

Автор

Глоссарий

Сноски