Совместный подход к надежным оценкам сторонних экспертов для frontier-моделей

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

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

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

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

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

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

• Reward hacking: использование обходных путей в задаче или у скорера, чтобы система получила зачёт, не демонстрируя поведение, которое должна измерять оценка.
• Отказы: отказы, которые скрывают тестируемое поведение.
• Контаминация: завышенная производительность из-за того, что задачи оценки, ответы или близкие варианты встречались в тренировочных данных или были доступны во время оценки, например через browsing.
• Сломанные задачи: заниженная производительность, потому что задачи некорректны. Причины могут включать несправедливое оценивание, например когда правильный ответ требует неописанных деталей реализации, и неразрешимые среды, например отсутствие критически важных файлов или ненадежные инструменты.
• Sandbagging: намеренно заниженная производительность, когда модель демонстрирует осознание того, что ее оценивают.

Выбор правильного harness для оценки критически важен для оптимального результата

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

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

Утверждение, которое пытается поддержать оценка Подходящий выбор harnessКакие доказательства нужно показать

Способность при сильном elicitation: System A может выполнять задачи типа X, когда настройка спроектирована так, чтобы выявить ее наиболее убедительную достоверную производительность.Используйте для системы наиболее сильную достоверную настройку elicitation, включая harness, инструменты, scaffolding и бюджет, который разумно использовал бы способный пользователь.Конфигурация harness и инструментов, рекомендации по elicitation, разрешенный бюджет/усилия, tokens/cost/time и объяснение, почему эта настройка является достоверным прокси заявленной способности. Если сравниваются системы с разными оптимизированными настройками, это следует маркировать как system-to-system или strong-elicitation сравнение.

Контролируемое сравнение: System A превосходит System B в общей конфигурации оценки.Сохраните задачи, scoring и бюджет неизменными. Используйте либо общий набор harness/tools, либо заранее выбранный фиксированный набор стандартизированных harness, чтобы обеспечить разумное максимальное выявление возможностей для сравниваемых систем.Общий набор задач, инструменты, метод scoring, harness, бюджет, token efficiency/cost и известные ограничения. Для оценок coding-agent открытый harness, такой как Codex CLI, может обеспечить фиксированный agent loop и интерфейс инструментов для разных систем. Идеальный подход для максимального выявления возможностей — оптимизировать отдельный bespoke harness для каждой задачи и системы, но на практике это сейчас непрактично.

Надежность предохранителей при elicited attack: предохранители System A достаточны для соответствующего поведения модели или elicited attack.Используйте настройку тестирования предохранителей, спроектированную так, чтобы выявить наиболее убедительную достоверную атаку в рамках соответствующей модели adversary.Пояснение, как оценщики охарактеризовали релевантное поведение модели, протестированную конфигурацию предохранителей, стратегию elicitation, использованный harness и разрешенный бюджет или усилия.

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

Чем выше показатели успешности, тем лучше

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

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

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

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

Reward hacking

Отказы

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

Контаминация

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

Сломанные задачи

Sandbagging

Как мы поддерживаем более сильные оценки

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

• Мы делимся с оценщиками конкретными рекомендациями по максимальному выявлению возможностей.
• Мы просим evaluators по способностям использовать Codex как общий минимум для моделей OpenAI: тесты должны как минимум прогонять базовую версию через тот же agentic interface, на который пользователи, вероятно, будут опираться, а не только через упрощенный model interface.
• Мы также делаем доступными reasoning traces и другие промежуточные артефакты там, где они нужны для оценки deception, sandbagging или awareness of evaluation. METR и Apollo использовали этот доступ в оценках OpenAI начиная с GPT‑5.
• Наконец, мы приоритизируем исследования, чтобы глубже понять, когда и как выбор harness существенно меняет результаты — от управления контекстом и доступа к инструментам до поведения повторных попыток, scoring и ресурсных бюджетов.

Что это означает для стандартов оценки и будущих направлений исследований

• Утверждение: сравнивает ли оценка системы, оценивает ли потолок возможностей или тестирует ли предохранители.
• Содержимое оценки: достаточно ли подробностей о задачах или распределении задач, чтобы читатели поняли, какие навыки, поведение или режимы отказа на самом деле проверяет оценка.
• Тестируемая система: модель, режим reasoning, доступ к инструментам, harness и предохранители.
• Бюджет: ходы, tokens, попытки/повторы, wall-clock time, стоимость inference и, где уместно, ожидаемая стоимость одного успешного решения.
• Методы elicitation: выбор harness, использованный для получения результата, и то, насколько близко протестированное соответствует более широкому заявленному утверждению.
• Проверки валидности: как оценщики искали reward hacking, осведомленность об оценке, contamination, отказы, sandbagging и другое поведение, которое могло бы подорвать результат, включая то, как подтвержденные случаи влияли на scoring или интерпретацию.

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

Материал — перевод статьи с английского.

Оригинал: A shared playbook for trustworthy third party evaluations