Бенчмарк Agentic Analytics, раунд второй: GPT-6, Claude Opus 5.5, Claude Sonnet 5.5

• Таблица лидеров: 34 модели, ранжированные по доле успешных ответов (pass rate) на 201 вопросе с лимитом в 60 шагов (turns). Она зафиксирована: новая модель добавляется с тем же набором вопросов, хранилищем данных и судьями.
• Шаг (turn): один вызов модели. За один шаг может выполняться несколько SQL-запросов. Лимит составляет 60 шагов на вопрос.
• Превышение лимита шагов (TL, Turn-limited): запуск, который исчерпал лимит в 60 шагов, так и не дав ответа. Засчитывается как неудача.
• Судейская коллегия: три модели-судьи (по одному месту на каждого провайдера), голосующие по каждому ответу. Модель кандидата никогда не оценивает сама себя.
• Сопоставитель колонок (column linker): два правильных ответа могут содержать разные названия колонок. Если колонки одного ответа включают колонки другого, общие колонки сопоставляются по имени без вызова модели. В противном случае небольшую модель просят определить соответствие колонок, и сравнение результатов выполняется на основе этого маппинга.
• Слой измерений CRM (dbt_dds): нормализованные таблицы хранилища данных. Они требуются для 83 из 201 вопросов, и способность находить их была главным дифференцирующим фактором в первой публикации.

В первой публикации запускался агентный цикл (модель пишет SQL, считывает результаты и решает, когда дать ответ) с лимитом в 60 шагов, детерминированным сравнением результатов и судейской коллегией по одному представителю от провайдера, где ни одна модель не оценивает свои собственные ответы. Всё это осталось неизменным. В этой публикации добавляются пять моделей.

Тестовый стенд (harness) также изменился. Он открыт в репозитории github.com/ClickHouse/data-agent-mnist, синхронизируется с деревом исходного кода, на котором работает таблица, и с момента версии из первой публикации включает следующие изменения:

• Фиксация движка и часового пояса. В манифесте таблицы фиксируются релиз движка запросов и часовой пояс сессии; запуск на другой конфигурации отклоняется. Незаметное обновление движка изменило эталонный ответ (ground truth) для одного из вопросов — именно такой дрейф и призван предотвращать воспроизводимый бенчмарк.
• Предварительная проверка учетных данных (credential preflight). Каждый провайдер, к которому будут обращаться кандидаты, судьи и сопоставитель колонок, проверяется до первого платного вызова, поэтому недействительные учетные данные судьи останавливают прогон сразу, вместо того чтобы портить оценку от вопроса к вопросу.
• Числовые допуски в конфигурации. Модуль сравнения больше не исходит из того, что значения всегда выражают денежные суммы. Округление и допуски вынесены в секцию оценивания конфигурации модели, где значения для валют используются по умолчанию.
• Исправление сопоставителя для широких наборов результатов. Когда колонки одного ответа содержат колонки другого, общие колонки сопоставляются по прямому совпадению имен без вызова модели. Исправление применяется только к будущим прогонам; опубликованная таблица повторно не пересчитывалась.
• Модель судейства с учетом неопределенности. Многоаспектная модель Раша (many-facet Rasch model) на основе кэшированных голосов коллегии рассчитывает способности кандидата, строгость судей и коэффициент родственного семейства с бутстреп-интервалами в офлайн-режиме по файлу результатов.
• Хуки для экспериментов. Подключение второго корпуса задается одной переменной окружения, благодаря чему набор данных для разработки (development set) может сосуществовать с замороженной основной таблицей. Каждый раннер принимает колбэк-гейт, который может прикреплять примечание к результату запроса.
• Раннер для LibreChat. Раннер оценивает агента LibreChat на тех же вопросах, хранилище данных и коллегии судей, что и прямой цикл: на полной таблице этот продукт набрал 69,7% против 66,2% у прямого цикла на той же модели, что укладывается в рамки статистического шума.

Тест на утечку данных (contamination probe) из первой публикации был запущен для всех пяти новых моделей. Ни одна из них не смогла восстановить анонимизированное имя сущности по префиксу вопроса (0 из 25 у каждой), а сходство их дополнений с нашими вопросами находится на том же низком уровне, что и у остальной части таблицы. Sonnet 5.5, единственная модель из пяти с контрольным тестом на Spider, восстанавливает 81% имен сущностей на Spider dev против 7% на наших вопросах, что подтверждает чувствительность теста к запоминанию там, где оно реально присутствует.

На рисунке ниже модели ранжированы по доле успешных ответов при лимите в 60 шагов. Пять новых строк выделены синим цветом.

Таблица лидеров при лимите в 60 шагов, 34 модели. Ярко-желтым цветом отмечены шесть строк со статистической ничьей с лидером; на 201 вопросе 95%-й доверительный интервал составляет около ±6–7 процентных пунктов. Шаги (turns) и SQL-запросы указаны как медианы на вопрос. TL — количество вопросов, которые модель так и не завершила в пределах лимита. Синими полосами отмечены пять моделей, добавленных после первой публикации.

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

GPT-6 Astra, Luna и Sol запускались через тот же OpenAI-совместимый путь, что и другие модели OpenAI в таблице, со стандартным уровнем рассуждений (default reasoning effort). Их результаты лежат в диапазоне от 68,7% до 69,7% с перекрывающимися интервалами — чуть ниже GPT-5.5 (70,4%) и выше GPT-5.6 (67,7%). Ни один из вариантов GPT-6 здесь не превзошел своего предшественника. Все три ответили на каждый вопрос в рамках лимита шагов, продемонстрировав типичный для таблицы характер ошибок: в первую очередь неверный план, без ошибок выполнения.

Стандартный уровень рассуждений — это важное уточнение. В первой публикации на примере линейки Gemini было показано, насколько сильно регулировка бюджета рассуждений может изменить результат, а GPT-6 поддерживает уровень «xhigh», с которым не тестировалась ни одна модель в таблице. Пока этот прогон не выполнен, эти строки следует рассматривать именно как «GPT-6 со стандартным уровнем рассуждений».

Opus 5.5 стартует с результатом 69,7%, что на 2,0 процентных пункта выше показателя Opus 5 и находится в пределах погрешности от него, на одном уровне с Kimi K2.6 и GPT-6 Sol. Как и Opus 5, она довела до конца каждый вопрос, при этом цикл был чуть короче: медиана 4 шага и 6 запросов против 5 и 7 соответственно.

Sonnet 5.5 — самая интересная из пяти моделей: точность изменилась незначительно, а вот всё остальное изменилось существенно.

Точность. 68,7% (138 из 201) против 62,2% у Sonnet 5. При парном сравнении на одних и тех же вопросах она выигрывает 31 раз и проигрывает 18, давая чистый перевес в 13 при p около 0,09: это указывает на тренд, но статистически незначимо. Она делит позицию с GLM-5.2 и GPT-6 Astra, оказавшись на один пункт выше Opus 5 и на один ниже Opus 5.5.

За счет чего получен прирост. На 83 вопросах, требующих слоя измерений CRM (dbt_dds), Sonnet 5 набрала 62,7%, а Sonnet 5.5 — 73,5%; на остальных вопросах — 61,9% против 65,3%. Прирост достигнут на многошаговых вопросах (multi-hop questions), и дело не в более частом нахождении нужных таблиц: обе модели обнаруживают слой измерений примерно в 89% вопросов, где он требуется. Модель просто лучше их использует.

Доля успешных ответов при 60 шагах на 83 вопросах со слоем измерений (dbt_dds) в сравнении со 118 остальными, 34 модели, а также частота обращения SQL-запросов каждой модели к слою измерений. Все новые строки сохраняют или улучшают результат на вопросах с измерениями, за исключением Opus 5.5, у которой результат там на 2 процентных пункта ниже, чем на остальных.

Эффективность. Именно здесь заметно наибольшее улучшение. Sonnet 5 упиралась в лимит в 60 шагов в 16 из 201 запусков, из-за чего ее общая доля успешных ответов была на 5 пунктов ниже, чем на завершенных запусках. Sonnet 5.5 исчерпала лимит 0 раз при среднем числе 3,5 шагов на вопрос против 9,1, медианном времени 13,7 секунды на ответ против 26 и общей стоимости прогона в $10,39 по прайс-листу против $14,40 — примерно 5 центов за вопрос против 7.

Астрономическое время на вопрос (wall-clock), 34 модели, отсортированные по медиане (засечка); полоса показывает 90-й перцентиль. GPT-6 Sol и Sonnet 5.5 входят в число самых быстрых моделей в таблице. Astra — самая медленная из новых строк с медианой 46 секунд и 90-м перцентилем свыше 90 секунд.

Характер ошибок. Из 63 неудач Sonnet 5.5 в 75% случаев виной был неверный план, в 19% — неверный выбор данных, в 6% — неверная реализация. Отсутствия попыток (no-attempts) и ошибок времени выполнения не было вовсе. У Sonnet 5 было 5% отсутствия попыток и 15% неверных реализаций. Sonnet 5.5 всегда предпринимает попытку и чаще производит вычисления корректно; если она ошибается, то ошибается именно в плане.

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

Планирование по-прежнему остается основным источником сбоев. Для каждой новой модели неверный план составляет самую большую категорию ошибок, тогда как ошибки времени выполнения отсутствуют. Выполнение SQL для этого класса моделей уже решено; остается только решить, что именно вычислять.

Цены внутри топовой группы все еще различаются восьмикратно, а разрыв со средним уровнем сокращается. В первой таблице лидеров дешевые модели в линейках исчерпывали бюджет: Sonnet 5 уперлась в лимит на 16 вопросах против нуля у Opus 5, а Gemini 3.5 Flash — на 28. Sonnet 5.5 ломает эту тенденцию. Она проходит весь набор тестов примерно за одну пятую от стоимости Opus 5, без единого прерванного прогона, и отстает от нее всего на один балл.

Средняя стоимость вопроса по прейскуранту в сравнении с долей успешных ответов (pass rate), 30 моделей, логарифмическая шкала. Sonnet 5.5 находится чуть правее границы эффективности затрат (cost frontier) на уровне около 5 центов за вопрос. GPT-6 Astra, Luna, Sol и Opus 5.5 исключены: они запускались через шлюз, чьи логи использования ненадежно разделяют кэшированные и некэшированные входные данные, поэтому расчет стоимости по прейскуранту был бы слишком занижен для GPT-6 и слишком завышен для Opus 5.5.

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

Здесь нет ничего специфичного именно для нашего хранилища данных или ClickHouse. Тестовый стенд (harness) тот же самый, что описан в первой статье: инструментированный ассистент, смоделированная схема хранилища, отобранный и анонимизированный набор вопросов с эталонными ответами, верифицированными экспертами, и судейская панель, в которой ни одна модель не оценивает собственные ответы. Добавление модели — это запись в реестре и одна команда, а фиксация версий движка гарантирует воспроизводимость результатов при повторном запуске.

У вашего хранилища данных будет свой критический фактор. У нас это многомерный CRM-слой; у вас это может быть медленно меняющееся измерение (SCD), полуструктурированная таблица событий или правила именования, которые никто так и не зафиксировал письменно. Единственный способ его выявить — запустить бенчмарк на вашей схеме, с вашими вопросами, и посмотреть, на чем именно спотыкаются модели.

Сетка тестов по уровню вычислительных затрат на рассуждения (reasoning effort) для семейства GPT-6 позволила сравнить три варианта более чем на одном уровне затрат. Вопрос об архитектуре с разделением ролей из первой статьи (самая сильная модель планирует, самая дешевая выполняет) по-прежнему остается наиболее интересным направлением для дальнейших исследований. За этим материалом последует сопутствующая статья о классификации сбоев и ранжировании таблиц.

• Тестовый стенд: , Apache 2.0. Два рабочих примера в директории examples/ запускаются из опубликованного дерева репозитория с использованием трех API-ключей.