Руководство OpenAI по eval harness: почему benchmark-баллы нельзя напрямую использовать для routing-решений

Когда команда выбирает модельный tier для production routing-политики, она неявно доверяет какому-то benchmark. Руководство OpenAI по оценкам, опубликованное 29 мая, — это документ, который стоит прочитать до того, как это доверие зафиксировано: harness, используемый при оценке, может изменить измеренный результат сильнее, чем сама модель.

Это не сноска из области safety-исследований. Это прямой вызов тому, как AI-инженерные команды используют leaderboard-баллы для обоснования routing-решений.

Что произошло

OpenAI опубликовала «Общее руководство по надёжным сторонним оценкам» — детальный инженерный документ для организаций, которые заказывают или потребляют независимые оценки моделей. Материал основан на опыте собственных preparedness-оценок OpenAI и опубликованных сторонних исследований, включая работу UK AISI на cyber range.

Центральный тезис: frontier-модели больше не чат-боты. Они используют инструменты, сохраняют состояние на протяжении многих шагов и работают внутри более широких workflow. Это означает, что результаты оценки зависят не только от модели, но и от harness — скаффолдинга, конфигурации инструментов, управления контекстом, token-бюджета и логики повторных попыток.

OpenAI выделяет три типа утверждений, которые могут поддерживать оценки:

• Capability elicitation — способна ли модель вообще проявить данную возможность?
• Controlled comparison — превосходит ли модель A модель B при одинаковых условиях?
• Safeguard robustness — насколько устойчивы защитные механизмы модели при adversarial-элицитации?

Каждый тип утверждения требует своего дизайна harness. Смешение типов — например, использование harness для controlled comparison при формулировании capability-утверждения — даёт технически корректные, но вводящие в заблуждение результаты.

Почему это важно для AI-инженерных команд

Практический вывод: benchmark-балл — не переносимый факт. Это измерение при конкретном harness и конкретном бюджете. Две команды, запускающие одну и ту же модель на одной задаче с разным скаффолдингом, могут получить принципиально разные результаты.

Данные OpenAI это подтверждают: производительность GPT-5.5 на задачах cyber range существенно выросла, когда harness использовал context compaction для сохранения релевантного состояния в длинных взаимодействиях. Оценка UK AISI показала, что увеличение token-бюджета с 10 млн до 100 млн токенов улучшило производительность на тех же задачах до 59% — и при максимальном бюджете рост ещё не остановился.

Для команд, принимающих routing-решения, это создаёт конкретную проблему: benchmark, убедивший вас направить трафик в premium tier, мог быть запущен в harness, не соответствующем вашей production-нагрузке. Модель, показывающая высокие результаты на coding benchmark с щедрым retry-бюджетом и state-preserving скаффолдингом, может вести себя иначе, когда ваш production agent работает с более узким контекстным окном и без логики повторных попыток.

Руководство также указывает на contamination и sandbagging как угрозы валидности. Contamination — когда задачи оценки встречались в обучающих данных — завышает баллы. Sandbagging — когда модель намеренно показывает худшие результаты, обнаружив, что её оценивают, — занижает их. Ни один из эффектов не виден в итоговом числе.

Угол router/operator

Для команд, управляющих routing-политиками через несколько provider, руководство предлагает полезную ментальную модель: воспринимайте benchmark-баллы как нижнюю оценку возможностей при конкретной elicitation-настройке, а не как потолок возможностей.

Это меняет подход к построению routing tier-решений:

1. Подбирайте harness под свою нагрузку, а не под leaderboard. Если ваш production coding agent работает с контекстным окном 32K, без компрессии и с одной попыткой, benchmark, запущенный с 200K контекстом и агрессивными повторами, измеряет другую систему. При оценке целесообразности перехода на более дорогой tier запускайте внутренний eval с harness, зеркалирующим ваш production.

2. Различайте capability-утверждения и comparison-утверждения. «Модель A превосходит модель B при общем harness» — это controlled comparison. Это не говорит о том, способна ли модель A вообще справиться с вашей конкретной задачей. Для routing-решений, зависящих от capability-порогов — «может ли эта модель надёжно выполнить 50-шаговую agent-задачу?» — нужен capability elicitation eval, а не comparison leaderboard.

3. Чувствительность к бюджету — это routing-сигнал. Если benchmark-балл модели продолжает расти при максимальном протестированном token-бюджете, эффективные возможности этой модели зависят от ресурсов. Для latency-чувствительных routing-путей модель, которой нужен в 10 раз больший token-бюджет для достижения результата конкурента, может быть неподходящим выбором, даже если её потолок выше.

4. Safeguard-утверждения требуют adversarial harness. Если вы направляете модель для сценариев, где важна контентная политика — клиентские agent, регулируемые отрасли — релевантный вопрос не «отклоняет ли модель плохие запросы в стандартном eval», а «держится ли она при кастомном harness, разработанном для обхода защиты». Руководство рекомендует, чтобы safeguard-оценки соответствовали модели угрозы, включая кастомный скаффолдинг.

5. Требуйте детали harness перед доверием стороннему eval. Руководство рекомендует, чтобы отчёты об оценках раскрывали настройку harness, конфигурацию инструментов, бюджет и elicitation-руководство. Если отчёт, на который вы опираетесь при routing-решении, не содержит этого, воспринимайте балл как нижнюю оценку.

Что стоит отслеживать пользователям TheRouter

Если вы используете TheRouter для routing между модельными tier — например, направляете сложные coding-задачи в premium tier, а простые completion — в flash tier — фреймворк из руководства предлагает конкретные улучшения для дизайна routing-политики:

• Запускайте tier-квалификационные eval с собственным harness. Перед фиксацией routing-правила, отправляющего класс задач к конкретной модели, запустите небольшой внутренний eval с тем же контекстным бюджетом, конфигурацией инструментов и retry-логикой, что использует ваш production agent. Результат будет более предсказуемым, чем любой опубликованный leaderboard.
• Отслеживайте success rate по каждой модели в production. Benchmark-баллы — это pre-deployment оценки. Production success rate при вашем реальном harness — это ground truth. Если вы логируете completion-запросы через TheRouter, у вас уже есть данные для построения этого сигнала.
• Воспринимайте «всё ещё растёт при максимальном бюджете» как флаг latency-риска. Если возможности модели чувствительны к бюджету, направление её в latency-ограниченный путь без fallback — это reliability-риск. Настройте fallback на модель с более предсказуемой производительностью при вашем рабочем бюджете.

Более широкий вывод из руководства OpenAI: eval-экосистема взрослеет, выходя за рамки простых leaderboard-рейтингов. Команды, строящие routing-политики на harness-осознанных, workload-matched оценках, будут принимать лучшие tier-решения, чем те, кто опирается на заголовочные баллы.