OpenAI o3: что на самом деле означает «король бенчмарков»

Не «96.7%». Важнее другое: как вы будете это измерять у себя.

OpenAI выпускает o3, Twitter взрывается цифрами. «Рекорд на ARC-AGI!» «Лучшая reasoning-модель!» «AGI на горизонте!» Через неделю — тишина. Ещё через месяц — новая модель, новые цифры, новый хайп-цикл.

Проблема не в моделях. Проблема в том, как индустрия читает бенчмарки. Почти любую цифру можно сделать «правдой», если сменить:

• датасет,
• протокол,
• режим compute,
• доп. инструменты,
• способ подсчёта.

И пока вы принимаете решения на основе заголовков, а не инженерных отчётов, вы покупаете маркетинг. Не технологию.

Бенчмарк — это инструмент, а не истина. Он отвечает только на один вопрос: «в этих условиях, с этим протоколом, на этом наборе задач — что получилось?». Измените любой параметр — получите другой ответ.

Почти всегда в публикациях смешивают три разных вещи:

1. Способность — качество ответа модели на конкретный тип задачи.
2. Режим compute — сколько ресурсов модель потратила на «думание». O3 в режиме high-compute показывает 96.7% на ARC-AGI-1. В low-compute — существенно меньше. Это одна и та же модель.
3. Контур — есть ли инструменты, подсказки, внешняя память, доступ к поисковику.

Когда вы читаете «o3 набрал 96.7% на ARC-AGI», правильный вопрос не «ого, это AGI?». Правильный вопрос: при каком compute-бюджете? С каким протоколом? Сколько это стоило за одну задачу? И главное: а на моих задачах он покажет столько же?

Ответ почти всегда: нет. Бенчмарки оптимизированы под измерение. Ваш бизнес-процесс оптимизирован под результат. Это разные вещи.

Чтобы понять, что такое o3 и почему его цифры не означают AGI, нужно видеть траекторию. Каждый «прорыв» — это не магия. Это конкретное инженерное решение, которое сдвигает одну метрику за счёт другой. Reasoning-модели — это цепочка таких решений, растянутая на четыре года.

И каждый раз — один и тот же паттерн: рекорд, хайп, разочарование, тихое внедрение в прод.

ARC Prize — один из немногих бенчмарков, который намеренно спроектирован так, чтобы его было трудно «натренировать». Каждая задача уникальна: нет повторяющихся паттернов, нет возможности запомнить ответы. Чистая абстракция и обобщение.

O3 на ARC-AGI-1 в режиме high-compute: 96.7%. Это впечатляет. Для контекста: предыдущий рекорд на ARC-AGI-1 принадлежал o1 — около 32%. Скачок в три раза. Неудивительно, что Twitter загорелся словом «AGI».

Но есть три нюанса, о которых молчат заголовки.

Нюанс 1: стоимость. High-compute режим o3 тратит на одну задачу ARC в десятки раз больше ресурсов, чем low-compute. Это не «модель умная». Это «модель перебирает варианты, пока не найдёт правильный».

Нюанс 2: ARC-AGI-2. На следующей версии теста, более сложной и устойчивой к brute-force, o3-preview показывает около 4% в low-compute. Не 96. Четыре.

Нюанс 3: протокол. ARC Prize публикует результаты с жёстким протоколом — фиксированный бюджет, никаких инструментов, никаких подсказок. Именно поэтому их цифры заслуживают доверия.

Главная инженерная идея o3 — не «побить бенчмарк». Это adaptive compute: модель динамически выбирает, сколько вычислительных ресурсов потратить на задачу. Простой вопрос — быстрый ответ. Сложная задача — глубокое рассуждение с перебором гипотез.

Как это работает технически: модель генерирует несколько «цепочек рассуждений» параллельно, оценивает их качество и выбирает лучшую. В low-compute режиме — одна-две цепочки. В high-compute — десятки. Это похоже на то, как шахматный движок просчитывает дерево ходов: чем больше времени, тем глубже анализ.

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

Но именно здесь начинается ловушка. Если ваш pipeline не контролирует compute-бюджет, модель может «думать» на каждый тривиальный запрос по 3 минуты. Счёт за API превратится в кошмар, а latency убьёт UX.

Как контролировать adaptive compute

Три инженерных приёма:

1. Маршрутизация по сложности. Перед отправкой в reasoning-модель — классификатор (дешёвая модель или правила), который оценивает сложность задачи и выбирает режим compute. Простые вопросы — low, аналитика — medium, критичные решения — high.

2. Бюджет на задачу. Жёсткий лимит: если модель не ответила за N секунд или N токенов — fallback на более быструю модель. Лучше быстрый приемлемый ответ, чем идеальный через 10 минут.

3. Мониторинг cost/качество. Трекайте стоимость каждого вызова и корреляцию с качеством ответа. Часто medium-compute даёт 95% качества high-compute при 10% стоимости.

Допустим, вы CTO или Head of AI. Вышел o3, вышел DeepSeek R1, вышел Claude 4.6 Opus. Все показывают «рекордные» цифры. Как выбирать?

Реальность: ни один бенчмарк не скажет вам, как модель поведёт себя на вашей задаче, в вашем контуре, с вашими данными. MMLU не знает про вашу CRM. ARC-AGI не знает про ваши юридические шаблоны. HumanEval не знает про ваш legacy-код на Python 2.

Правильный порядок — не «кто лучше на бенчмарке», а системная оценка по четырём осям:

1. Классы задач. Код, аналитика, юридические тексты, поддержка, продажи, планирование — каждый класс требует своего типа reasoning.
2. Стоимость ошибки. Где можно «галлюцинировать» (черновик блога), а где нельзя (платёжное поручение, медицинский диагноз, юридическое заключение).
3. Контур. Нужны ли инструменты: поиск, CRM, базы знаний, калькуляции, доступ к файлам.
4. Бюджет. Не абстрактный «мы готовы платить», а конкретный: сколько рублей за одну операцию, сколько операций в день, какой допустимый latency.

Если вы не можете ответить на все четыре вопроса для каждого класса задач — вы ещё не готовы выбирать модель. Вы готовы экспериментировать. И это нормально — но не путайте эксперимент с решением.

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

Вот конкретный pipeline, который можно собрать за неделю.

O3 — впечатляющая инженерная работа. Adaptive compute — реальный прорыв. ARC-AGI-1 на 96.7% — красивая цифра для пресс-релиза. Но давайте честно: через полгода выйдет o4, или Gemini 3, или DeepSeek R3 — и цифры снова обновятся. Гонка за рекордами бесконечна. А ваш бизнес — нет.

Ваша компания не выигрывает от «самой сильной модели на бенчмарке». Она выигрывает от предсказуемого контура:

• Измерения — вы знаете accuracy, latency и cost на ваших задачах.
• Ограничения — модель не может потратить бесконечный compute без вашего разрешения.
• Политика инструментов — что модель может делать, а что требует эскалации.
• Регрессия — каждое обновление проверяется автоматически.
• Наблюдаемость — логи, алерты, дашборды. Если что-то сломалось, вы узнаете через минуты, а не через жалобы клиентов.
• Абстракция — за одним интерфейсом можно переключить модель за часы, без переписывания кода.

Это и есть AI-зрелость. Не «мы используем o3». А «мы используем систему, которая работает независимо от того, какая модель внутри».

O3 может быть правильным выбором для вашей задачи. А может быть, что DeepSeek R1 за копейки решает её так же. Или Claude. Или Gemini. Единственный способ узнать — измерить самому.

Вот как выглядит зрелая AI-инфраструктура: не «мы используем лучшую модель», а «мы используем правильную модель для каждого класса задач, мы знаем её метрики, мы контролируем стоимость, и мы готовы переключиться за 24 часа, если что-то изменится». Это не о технологии. Это об инженерной культуре.

Что делать прямо сейчас

Не ждите «идеальную модель». Её не будет. Будет бесконечная гонка: o3, o4, Gemini 3, Claude 4, DeepSeek R3. Каждый квартал — новый «лидер». Если вы каждый раз переключаетесь — вы не строите систему. Вы реагируете на маркетинг.

Вместо этого:

• Не переключайтесь на o3 по заголовкам. Сначала — eval на ваших задачах. Потратьте 2 дня на тест, а не 2 недели на миграцию.
• Соберите golden set из 50+ реальных кейсов и запустите A/B минимум с тремя моделями. Включите edge cases — именно на них модели различаются.
• Зафиксируйте бюджет за операцию. Adaptive compute без лимитов = неконтролируемые расходы. Один клиент потерял $12K за неделю, потому что не поставил cap на reasoning-токены.
• Автоматизируйте регрессию. Провайдеры обновляют модели без предупреждения. Ваш eval должен ловить дрифт раньше, чем его заметят пользователи.
• Читайте ARC Prize, а не Twitter. Это один из немногих источников, где протокол важнее цифры.
• Стройте абстракцию над моделями. Один интерфейс, за которым можно менять провайдера за часы, а не за недели. LiteLLM, OpenRouter, собственный router — неважно. Важна независимость.

Мы в Atlas CEO тестируем каждую новую модель на нашем pipeline из 200+ кейсов. O3, Claude, DeepSeek, Gemini — все проходят одинаковый eval. Результаты регулярно удивляют: «лидер бенчмарков» не всегда лидер на наших задачах. И наоборот.

Присоединяйтесь к нашему Telegram-каналу — делимся результатами, eval-фреймворками и инженерными разборами без маркетингового шума.