Представьте себе типичную ситуацию в службе поддержки. Клиент пишет с жалобой: его дорогой кухонный прибор застрял в статусе «исключение» на сортировочном центре в Нашвилле, и с момента ожидаемой даты доставки прошло уже пятнадцать дней. Клиент хочет не просто извинений, а реального решения проблемы — либо ускорения доставки, либо компенсации.
AI-агент, управляющий этим процессом, действует безупречно с точки зрения логики диалога. Он делает девять вызовов инструментов: извлекает заказ, проверяет трек-номер, изучает профиль клиента, дважды сверяется с политикой возврата, подтверждает, что тикет еще не создан, открывает новый тикет, документирует хронологию и корректно интерпретирует правила. Агент приходит к выводу, что сегмент аккаунта клиента действительно не подходит для компенсации за задержку. Затем он закрывает тикет со статусом «Решено» и отвечает клиенту стандартной фразой: «Поскольку ваш запрос решен, могу ли я помочь вам еще чем-то?».
Звучит как победа? На самом деле, это катастрофа. Во-первых, проблема с перевозчиком все еще открыта, и требуемое конечное состояние системы должно было быть «На удержании» (pending resolution), а не «Решено». Во-вторых, клиент так и не получил ответа на свой главный вопрос. AI-грейдер, проверяющий только корректность вызовов инструментов, увидит девять идеально сформированных запросов. Но база данных, которая является единственным объективным свидетельством результата, «не согласна» с агентом. Именно этот разрыв между «звучащим правильно» и «действительно работающим» измеряет новый инструмент ThinkingBox.
01Вызов инструмента — это не результат
В индустрии генеративного ИИ мы долгое время полагались на прокси-метрики. Мы смотрели, правильно ли модель сформулировала ответ, или корректно ли она вызвала API. Но финальные ответы и валидные вызовы инструментов — это лишь косвенные признаки. Агент может звучать абсолютно убедительно, оставляя при этом неверное значение в поле, изменяя не ту запись в базе данных или создавая непредвиденные побочные эффекты.
Только записи, которые агент оставляет после себя, могут окончательно решить вопрос о его эффективности. Разрыв между намерением и результатом оказывается существенным. В масштабном исследовании, охватывающем 121 680 валидных испытаний с участием 12 различных моделей LLM, 79 853 попытки провалили исполняемые проверки (executable checks). Что самое интересное: из этих провалов 67,24% завершили работу чисто, вызвали инструмент, изменяющий состояние, и не сообщили об ошибках на финальном этапе.
Траектория действий агента — это лишь утверждение. Состояние базы данных — это доказательство. А повторение — это проверка на доверие. Если агент обрабатывает возврат средств правильно один раз, но ошибается в следующих четырех попытках, он не является рабочим агентом для обработки возвратов. Именно поэтому в ThinkingBox каждая задача выполняется 20 независимых раз, начиная с идентичного чистого состояния бэкенда, и сообщаются три разных показателя.
02Один успех — это не надежность
Чтобы оценить истинную надежность, Microsoft и Hugging Face используют три ключевые метрики, каждая из которых отвечает на свой вопрос:
- pass@1: Доля всех попыток, которые были успешными. Отвечает на вопрос: «Как часто это обычно работает?»
- pass@20: Доля задач, решенных хотя бы один раз из 20 попыток. Отвечает на вопрос: «Может ли он вообще это сделать?» (Широта охвата).
- Observed 20/20: Задачи, которые прошли все 20 записанных попыток. Отвечает на вопрос: «Может ли он всегда быть правильным?» (Консистентность).
В этом отчете мы используем observed 20/20 как буквальный счетчик задач, прошедших все 20 попыток. Никаких оценочных моделей, никакого сглаживания. Это суровая реальность.
Начнем с привычного взгляда. Таблица ниже показывает pass@1 — оценку однократной успешности, разбитую по доменам. Это число, которое чаще всего публикуют лидерборды, и само по себе оно выглядит как обычное ранжирование возможностей. Лидером общего зачета становится Claude Opus 5.5 с результатом 67,16%, опережая Claude Opus 5 всего на две десятых процента. Среди моделей с открытым исходным кодом (open-weights) сильнее всех показал себя Kimi-K3, находящийся в пределах одного пункта от GPT-6-Astra.
Однако домен имеет такое же значение, как и модель. Claude Opus 4.6 набирает 68,62% в розничной торговле, но всего 8,30% в автостраховании. Один хороший запуск говорит о том, что модель способна выполнить работу. Он не говорит о том, выполнит ли она её снова. Поэтому мы запускаем каждую задачу 20 раз и смотрим, какая часть этого показателя выживает.
03Можно ли доверять модели за спиной вашего агента?
На рисунке ниже видно, как ширина охвата и консистентность расходятся. Двенадцать из восемнадцати моделей показаны; шесть моделей с pass@1 ниже 33% опущены для читаемости.
Kimi-K3 обладает самым широким покрытием среди всех протестированных моделей. Он решает 93,89% задач бенчмарка хотя бы один раз: 476 из 507. Лишь 31 задача полностью его побеждает. В рабочих процессах розничной торговли он лидирует с показателем 82,24% pass@1, опережая все проприетарные модели. Но Kimi-K3 также является одной из наименее консистентных моделей. Лишь 68 из 507 задач (13,41%) успешны во всех 20 попытках.
Claude Opus 5 инвертирует эту ситуацию. Он решает меньше задач хотя бы один раз (79,09%; 106 задач полностью его побеждают), но завершает 47,53% бенчмарка при каждой отдельной попытке. Более новая модель не исправляет эту проблему. Claude Opus 5.5 набирает больше очков в среднем по всем попыткам (67,16% против 66,50%) и решает больше задач хотя бы один раз. Но он проходит ровно то же количество задач во всех 20 попытках: 241. Половина процента заголовочной точности не купила никакой дополнительной надежности.
Kimi-K3 решает на 75 задач больше хотя бы один раз, чем Opus 5. Но Opus 5 решает на 173 задачи консистентнее, чем Kimi-K3. Если вы выбираете модель для работы, которая затрагивает реальные записи, колонка pass@20 — это не то место, куда нужно смотреть. Вам нужна надежность, а не просто способность иногда угадать.
04Какова цена консистентности?
Сравнения возможностей обычно останавливаются на оценке. Но для любого развертывания актуальный вопрос — какова стоимость успешного выполнения задачи. Мы измеряем это как стоимость за успешную попытку задачи. Мы говорим «попытка задачи», потому что каждая задача бенчмарка запускается повторно, и стоимость возникает за каждую попытку, поэтому pass@1 является соответствующим знаменателем качества.
Мы взяли зарегистрированное использование токенов каждой модели из ее полной кампании 507 × 20 и оценили его по необесцененным списочным ставкам, доступным на OpenRouter, отменив промо-скидки и исключив конечные точки, объявляющие квантование. Входные, выходные и кэшированные ставки берутся с одного эндпоинта провайдера для каждой модели.
Затем мы разделили стоимость одного запуска на количество попыток, которые успешны:
Cost per successful task attempt = estimated cost for 507 attempts, one per task ÷ (507 × pass@1)Это сравнительный индекс эффективности, а не счет, и не цена обслуживания одного производственного запроса. Он также оценивает одиночные успехи, а не консистентность. Мы оцениваем консистентность дальше.
Пример: GPT-5.4 стоит $43,49 за 507 попыток (по одной на задачу) и имеет pass@1 65,36%, поэтому $43,49 ÷ (507 × 0,6536) = $0,131 за успешную попытку задачи.
Парето-фронтальность стоимости
Модель находится на фронтальной линии, если ни одна другая модель не является одновременно не более дорогой и как минимум такой же точной. Три модели квалифицируются; каждая другая модель доминируется хотя бы по одной оси.
Фронтальность имеет три ступени. GPT-5.6 Sol имеет самую низкую стоимость успеха — $0,127; GPT-5.4 повышает pass@1 на 3,45 процентных пункта за $0,004 больше за успех; Claude Opus 5.5 добавляет еще 1,80 пункта за $0,276 за успех. Каждая из трех остается на линии фронтальности, потому что ни одна более дешевая модель не соответствует ее pass@1.
Claude Opus 5 является самым ярким случаем: при стоимости $0,475 за успешную попытку и pass@1 66,50%, он одновременно дороже и менее точен, чем Claude Opus 5.5 при $0,276 и 67,16%.
Теперь оценим консистентность. Стоимость за успех вознаграждает модель, которая дешевая и часто правая. Она не вознаграждает модель, которая права каждый раз. Поэтому мы также вычисляем стоимость за надежную задачу: стоимость полной кампании из 20 запусков, деленную на количество задач, которые модель прошла во всех 20 попытках.
Cost per dependable task = estimated cost of 20 runs of 507 attempts ÷ tasks passing 20/20Пример: GPT-6-Astra стоит 20 × $86,03 = $1 720,60 за кампанию и проходит 231 задачу при каждой попытке, поэтому $1 720,60 ÷ 231 = $7,45 за надежную задачу.
Теперь ранжируем по консистентности. GPT-5.4 является самым дешевым при $6,80, хотя лишь 128 задач соответствуют этому барьеру. GPT-6-Astra достигает 231 задач за $7,45, а Claude Opus 5.5 — совместного лидера с 241 задачей за $7,80. Ни одна из трех не доминирует над другими: каждая дополнительная надежная задача обходится дороже. Claude Opus 5 также проходит 241 задачу, но за $13,30, поэтому Opus 5.5 доминирует над ним напрямую. GPT-5.6 Sol, самая дешевая за одиночный успех ($0,127), стоит $9,76 за надежную задачу. Самый дешевый способ получить правильный ответ — не самый дешевый способ получить надежный.
05Подписи к неудачам
Мы присваиваем каждой неудачной траектории детерминированную диагностическую подпись, и главный вывод actionable: примерно четыре из пяти неудач связаны с обработкой инструментов, а не с рассуждением. В рамках исследования аблиации (см. Таблицу 5 в нашей статье) распределение выглядит так:
- Использование инструментов: 79,9% неудач
- Неверные обновления состояния: 10,3%
- Неполные решения для пользователя: 7,0%
- Отсутствие действий, изменяющих состояние: 2,9%
Это средневзвешенные доли по моделям и наблюдаемые метки, а не уникальные причинно-следственные объяснения. Практический паттерн прост: агенты обычно доходят достаточно далеко, чтобы попытаться выполнить рабочий процесс, но терпят неудачу при восстановлении после ошибок инструментов, неудачных предварительных условий или пустых запросов. Это проблема повторных попыток и восстановления ошибок, а не проблема самой модели.
Сложность также меняется в зависимости от домена: в среднем по моделям, указанным в таблице выше, розничная торговля имеет средний показатель pass@1 59,52%, в то время как автострахование имеет средний показатель 33,83%.
06Как это работает
ThinkingBox — это песочница для агентов, а ThinkingBox-Bench — набор данных для оценки агентов. Диаграмма вверху поста показывает цикл; вот что делает каждая часть.
Каждая задача определяет начальное состояние бэкенда, цель пользователя, доступные инструменты MCP, политику домена и исполняемые проверки конечного состояния. Симулированный пользователь держит частный контекст (номер бронирования, предпочтение или дату рождения) и раскрывает его только при запросе. Каждая попытка получает изолированную сессию MCP с freshly initialized state. Две попытки одной и той же задачи никогда не разделяют строку базы данных или кэшированное состояние инструмента, что делает сравнение в 20 попыток осмысленным.
В конце извлекатель побочных эффектов выводит, что именно изменилось, а детерминированные судьи сравнивают это с требуемым конечным состоянием, принимая любую траекторию, которая приводит к правильному результату, и отклоняя неправильные, отсутствующие или лишние эффекты. Для требований, не имеющих чистого значения в базе данных («разъяснил ли агент, что это не гарантируется?»), узкий бинарный рубрик обрабатывает семантику. 477 из 507 задач оцениваются только по состоянию; 30 добавляют рубрики ответов.
Граница доверия: модель видит задачи, диалог и схемы инструментов. Золотое состояние, утверждения, внутренние механизмы оценки и учетные данные остаются на стороне оценщика.
07Запустите это сами
ThinkingBox теперь доступен на Hugging Face, как хarness, так и набор данных. ThinkingBox-Bench теперь находится за интерфейсом OpenEnv, и каждый завершенный эпизод возвращает бинарную награду pass/fail. Выпущенный адаптер предназначен для оценки; отдельные, не связанные с бенчмарком сценарии могут использовать тот же интерфейс в рабочих процессах обучения.
uv и Docker. Вам также нужен чек-аут thinkingbox-data в закрепленном релизе и конечные точки моделей для агента, симулированного пользователя и судьи. Один эндпоинт может обслуживать все три роли, что является самым простым способом начать.08Что это значит на практике
Для российских разработчиков и компаний, внедряющих AI-агентов в бизнес-процессы, результаты ThinkingBox несут критически важный урок. Доступность мощных моделей через API (включая российские аналоги или локальные развертывания) не гарантирует их надежности в реальных условиях. Агент может корректно сгенерировать JSON-ответ, но если он не обновил статус заказа в базе данных правильно, бизнес-процесс сломан.
1. Проверяйте состояние, а не слова. Внедряйте механизмы верификации конечного состояния базы данных после каждого вызова агента. Не доверяйте сводке агента, проверяйте факты.
2. Оценивайте консистентность. При выборе модели для критических задач (финансы, логистика, поддержка) смотрите не на максимальный балл в лидерборде, а на показатель observed 20/20 или стоимость надежной задачи. Модель, которая работает 90% времени, может быть дороже в обслуживании, чем модель, работающая 99% времени, из-за затрат на исправление ошибок.
3. Изолируйте сессии. Используйте подходы, подобные ThinkingBox, где каждая попытка агента происходит в изолированном окружении. Это позволяет точно измерить влияние предыдущих действий и избежать «загрязнения» контекста.
ThinkingBox открывает новую эру оценки AI, где важны не красивые ответы, а реальные, измеримые изменения в мире данных. И пока мы не научимся измерять эти изменения с такой же точностью, как и генерацию текста, мы будем сталкиваться с ситуациями, когда «агент сказал, что все готово», но база данных будет с ним категорически не согласна.
Источник: Hugging Face ↗