Агент сказав, що все готово. База даних не погодилася.

Microsoft ThinkingBox оцінює AI-агентів за записами, які вони залишають після себе, а не за реченнями, які генерують, а потім перевіряє, чи можуть вони зробити це двадцять разів поспіль. Тепер він доступний через Hugging Face.

Рисунок 1: ThinkingBox запускає агента в ізольованих сеансах інструментів MCP, а потім оцінює стан серверної частини та побічні ефекти, які той залишає після себе. З нашої статті про ThinkingBox.

Це спільний допис Microsoft і Hugging Face; особлива подяка Tommy Guy (засновнику Enderis AI, раніше Microsoft), Sergio Paniego з Hugging Face, а також нашим колишнім стажерам Zhuochun Li (Університет Піттсбурга), Ali Keramati (UC Irvine), Youngmin Ko (Northwestern) за співавторство та рецензування.

Клієнтка звертається до служби підтримки. Її кухонний прилад вартістю 745 доларів застряг у статусі «виняток» у розподільчому центрі в Нешвіллі — на п’ятнадцять днів довше за прогнозовану дату доставки.

AI-агент працює ретельно. Дев’ять викликів інструментів: отримує замовлення, перевіряє відстеження, переглядає профіль клієнтки, двічі шукає політику повернення коштів, підтверджує відсутність звернення, відкриває його, документує хронологію та правильно читає політику; її сегмент облікового запису справді не дає права на компенсацію за затримку доставки.

Потім він закриває звернення зі статусом вирішено і відповідає: « Оскільки ваше питання вирішено, чи можу я ще чимось вам допомогти? »

Тут є дві проблеми. Виняток перевізника все ще відкритий, тому потрібним кінцевим станом мав бути статус призупинено до вирішення. А клієнтка так і не отримала справжньої відповіді на своє запитання.

Оцінювач AI, який перевіряє виклики інструментів, побачив би дев’ять коректно сформованих викликів. Оцінювач, який перевіряє, чи записав агент дані в базу, побачив би те саме. Але база даних із цим не погоджується.

Саме цю розбіжність вимірює ThinkingBox. У 507 робочих процесах зі станом, кожен із яких запускається 20 разів на різних моделях LLM, він оцінює агентів за кінцевим станом серверної частини та побічними ефектами. У цьому дописі ми розповідаємо, що виявили, скільки коштує стабільність і як самостійно запустити бенчмарк через OpenEnv.

Ви можете самостійно це запустити: наведений вище приклад адаптовано з бенчмарк-завдання sandbox_external_retail_group1.py:test_case_ST003_006, а виконувана перевірка, яка не проходить, стосується одного поля: статус звернення має значення solved, хоча необхідним кінцевим станом є hold. Повний трасувальний запис наведено в Додатку D.4, приклад 3 нашої статті.

Зміст

1. Виклик інструмента — це не результат
2. Один успіх — це ще не надійність
3. Чи можна покладатися на модель, яка працює за вашим агентом?
4. Скільки коштує стабільність
5. Сигнатури помилок
6. Як це працює
7. Запустіть самостійно
8. Що далі

Хочете випробувати це до читання результатів? Перейдіть одразу до розділу «Запустіть самостійно».

Виклик інструмента — це не результат

Фінальні відповіді та коректні виклики інструментів — лише непрямі показники. Агент може звучати правильно, залишивши неправильне значення, змінивши не той запис або створивши зайвий побічний ефект. Відповідь дають лише записи, які він залишає після себе.

Розрив значний. В абляційному дослідженні на спільній підмножині, що охоплювало 121 680 коректних випробувань на 12 моделях LLM, 79 853 спроби не пройшли виконувані перевірки. З-поміж цих невдалих спроб 67,24% завершилися коректно, викликали інструмент, що змінює стан, і не повідомили про жодну фінальну помилку інструмента. Однак виконувані перевірки виявили неправильні значення полів у 77,61% із них, ненавмисні додаткові ефекти у 43,30% і відсутні необхідні ефекти у 25,36%. Ці результати перевірки стану перетинаються.

Траєкторія — це твердження. Стан бази даних — доказ. Повторення — перевірка довіри.

Один успіх — це ще не надійність

Агент, який одного разу правильно обробив повернення коштів, а наступні чотири рази зробив це неправильно, не є працездатним агентом для повернення коштів. Тому кожне завдання запускається 20 незалежних разів, щоразу з однаковою чистою серверною частиною, і ми наводимо три різні показники:

Таблиця 1: Три показники, які ми наводимо, і запитання, на які кожен із них відповідає.

У цьому дописі ми використовуємо спостережуваний 20/20 як буквальну кількість із 507 завдань, які пройшли 20 із 20 спроб. Без оцінювача, без згладжування.

Почнімо зі звичного погляду. У таблиці нижче наведено pass@1 — оцінку результату однієї спроби — у розрізі доменів. Це число, яке публікує більшість таблиць лідерів, і саме по собі воно виглядає як звичайний рейтинг можливостей.

Таблиця 2: ThinkingBox-Bench pass@1 (%) за доменами. Кожна модель оцінюється на кожному завданні у 20 повторних випробуваннях. Жирним позначено лідера групи, підкресленням — друге місце. Стандартні похибки оцінок результату однієї спроби наведено в таблиці 4 статті про ThinkingBox.

Модель	Роздрібна торгівля (98)	Автострахування (100)	Подорожі (104)	Необанк (104)	Консалтинг (101)	Загалом, зважено за завданнями (507)
Пропрієтарні моделі
Claude Opus 5.5	80.97	68.40	54.28	71.25	61.58	67.16
Claude Opus 5	80.71	65.80	49.95	70.62	66.19	66.50
GPT-5.4	76.33	62.65	68.12	65.34	54.60	65.36
GPT-5.6 Sol	67.65	65.30	60.34	59.09	57.52	61.91
Claude Sonnet 4.6	72.35	54.40	58.94	56.39	54.31	59.19
GPT-6 Astra	71.73	46.55	55.87	60.87	56.83	58.31
GPT-5.2	70.20	22.40	53.70	51.15	34.06	46.28
Claude Opus 4.6	68.62	8.30	21.11	35.67	27.82	32.09
o3-pro	37.70	2.95	17.31	24.28	14.60	19.31
Grok-4.3	43.93	2.60	15.14	1.78	9.55	14.38
Моделі з відкритими вагами
Kimi-K3	82.24	50.80	61.83	41.35	51.63	57.37
Qwen3.8-27B	64.03	47.85	53.41	47.88	45.69	51.70
DeepSeek-V4-Pro	68.21	29.65	43.13	44.86	31.04	43.26
Kimi-K2.6	53.72	24.50	39.52	33.65	37.33	37.66
GLM-5.1	58.67	25.70	35.43	13.27	34.06	33.19
Qwen3.6-27B	43.11	29.00	46.39	27.84	18.37	32.94
Qwen3.5-9B	19.90	0.70	4.71	1.15	2.33	5.65
Mistral-Large-3	11.28	1.30	8.99	1.15	0.74	4.66

Claude Opus 5.5 лідирує загалом із результатом 67,16% — на дві третіх відсоткового пункту випереджаючи Claude Opus 5. Kimi-K3 — найсильніша модель із відкритими вагами, менш ніж на один пункт відстаючи від GPT-6-Astra. Домен має не менше значення: Claude Opus 4.6 отримує 68,62% у роздрібній торгівлі, але лише 8,30% в автострахуванні.

Один вдалий запуск показує, що модель може виконати роботу. Але він не показує, чи зробить вона це знову. Тому запускайте кожне завдання 20 разів і запитуйте, яка частина результату збережеться.

Рисунок 2: Яка частина результату кожної моделі в одній спробі зберігається після 20 повторень.

Лише три моделі зберігають більшість своїх показників pass@1: GPT-6 Astra зберігає 78% свого результату в одній спробі, а Claude Opus 5.5 і Claude Opus 5 — по 71%. На іншому кінці шкали GLM-5.1, Kimi-K2.6 і DeepSeek-V4-Pro зберігають приблизно 8% кожна.

Розрив між тим, що модель може зробити один раз, і тим, що вона робить щоразу, — це вся суть.

Чи можна покладатися на модель, яка працює за вашим агентом?

Рисунок 3: Охоплення та стабільність розходяться. Показано дванадцять із вісімнадцяти моделей; шість моделей із pass@1 нижче 33% не показано для кращої читабельності.

Kimi-K3 має найширше охоплення серед усіх протестованих нами моделей. Вона розв’язує 93,89% бенчмарку принаймні один раз: 476 із 507 завдань. Лише 31 завдання повністю виявилося їй не під силу — це найменша кількість у дослідженні. У робочих процесах роздрібної торгівлі вона беззаперечно лідирує з pass@1 на рівні 82,24%, випереджаючи всі пропрієтарні моделі.

Kimi-K3 також належить до найменш стабільних. Лише 68 із 507 завдань, або 13,41%, успішно виконуються в усіх 20 спробах.

Claude Opus 5 демонструє протилежну картину. Вона розв’язує менше завдань принаймні один раз (79,09%; 106 завдань повністю виявилися їй не під силу), але завершує 47,53% бенчмарку в кожній окремій спробі.

Новіша модель цього не виправляє. Claude Opus 5.5 має вищий середній результат у всіх спробах, ніж Claude Opus 5: 67,16% проти 66,50%, і розв’язує більше завдань принаймні один раз. Але вона проходить рівно стільки ж завдань у всіх 20 спробах: 241. Пів відсоткового пункту заголовкової точності взагалі не додали надійності.

• Kimi-K3 розв’язує на 75 завдань більше принаймні один раз, ніж Opus 5.
• Opus 5 розв’язує на 173 завдання більше стабільно, ніж Kimi-K3.

Якщо ви обираєте модель для роботи з реальними записами, pass@20 — це не той стовпчик, на який варто дивитися.

Скільки коштує стабільність

Порівняння можливостей зазвичай завершується на показнику. Для тих, хто впроваджує систему, актуальне питання — скільки коштує успішна одиниця роботи. Ми вимірюємо це як вартість однієї успішної спроби виконання завдання. Ми кажемо «спроби виконання завдання», оскільки кожне завдання бенчмарку запускається повторно, а витрати виникають за кожну спробу; тому pass@1 є відповідним знаменником якості.

Ми взяли зафіксоване використання токенів кожною моделлю з її повної кампанії 507 × 20 і розрахували вартість за недисконтованими тарифами, доступними в OpenRouter⁺, скасувавши промоційні знижки та виключивши кінцеві точки, які декларують квантування. Тарифи на вхідні, вихідні та кешовані дані взято з однієї кінцевої точки постачальника для кожної моделі.

Потім ми поділили вартість одного запуску на кількість спроб, які завершилися успішно:

Вартість однієї успішної спроби виконання завдання = розрахункова вартість 507 спроб, по одній на завдання ÷ (507 × pass@1)

Це індекс порівняльної ефективності, а не рахунок і не ціна обслуговування одного виробничого запиту. Він також оцінює окремі успіхи, а не стабільність. Далі ми розрахуємо вартість стабільності.

Приклад: GPT-5.4 коштує 43,49 долара за 507 спроб (по одній спробі на завдання) і має pass@1 на рівні 65,36%, тому 43,49 ÷ (507 × 0,6536) = 0,131 долара за успішну спробу виконання завдання.

Фронтир Парето за вартістю

Модель перебуває на фронтирі, якщо жодна інша модель не є одночасно не дорожчою і щонайменше такою ж точною. Цій умові відповідають три моделі; кожна інша поступається щонайменше за однією з осей.

Рисунок 4: Вартість однієї успішної спроби виконання завдання у порівнянні з pass@1. Обведені точки — моделі на фронтирі Парето за вартістю.

Фронтир має три сходинки. 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 спробах.

Вартість одного надійного завдання = розрахункова вартість 20 запусків по 507 спроб ÷ кількість завдань, пройдених у форматі 20/20

Приклад: GPT-6-Astra коштує 20 × 86,03 = 1 720,60 долара за кампанію та проходить 231 завдання в кожній спробі, тож 1 720,60 ÷ 231 = 7,45 долара за надійне завдання.

Таблиця 3: Дев’ять найнижчих значень вартості одного надійного завдання серед моделей, що мають принаймні одне спостережуване завдання 20/20, відсортовані від найнижчого до найвищого. Розрахункові долари, а не фактичні рахунки хмарних сервісів.

Тепер ранжуймо за стабільністю. 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 долара за надійне завдання. Найдешевший спосіб отримати правильну відповідь — не найдешевший спосіб отримати надійну відповідь.

Сигнатури помилок

Ми призначаємо кожному невдалому трасувальному запису одну детерміновану діагностичну сигнатуру, і головний висновок має практичне значення: приблизно чотири з п’яти помилок пов’язані з використанням інструментів, а не з міркуваннями. В абляційному дослідженні, наведеному в таблиці 5 нашої статті:

Це незважені середні значення часток для окремих моделей і спостережуваних міток, а не унікальні причинно-наслідкові пояснення.

Практична закономірність проста: агенти зазвичай просуваються достатньо далеко, щоб спробувати виконати робочий процес, а потім не можуть відновитися після помилок інструментів, невиконаних передумов або порожніх результатів пошуку. Спочатку це проблема повторних спроб і відновлення після помилок, а вже потім — проблема моделі.

Складність також змінюється залежно від домену: серед моделей, наведених у таблиці 2 вище, середній pass@1 у роздрібній торгівлі становить 59,52%, тоді як в автострахуванні — 33,83%.

Що з цим робити. Розглядайте показник 20/20 як вхідний параметр для проєктування, а не як вирок. Той самий сигнал, за яким оцінює бенчмарк, доступний і у виробничій системі: перевіряйте кінцевий стан перед фіксацією змін, а не резюме моделі.

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

Як це працює

ThinkingBox — це пісочниця для агентів, тоді як ThinkingBox-Bench — набір даних для оцінювання агентів. Схема на початку цього допису показує цикл; нижче описано призначення кожної його частини.

Рисунок 5: Цикл пісочниці з панелі A рисунка 1 вище: ізольований сеанс інструментів, кінцевий стан бази даних, побічні ефекти, виконувані оцінювачі.

Кожне завдання визначає початковий стан серверної частини, мету користувача, доступні інструменти MCP, політику домену та виконувані перевірки кінцевого стану. Симульований користувач зберігає приватний контекст (номер бронювання, уподобання або дату народження) і розкриває його лише на запит.

Кожна спроба отримує ізольований сеанс MCP зі щойно ініціалізованим станом. Дві спроби одного завдання ніколи не використовують спільний рядок бази даних або кешований стан інструмента, завдяки чому порівняння 20 випробувань має сенс.

Наприкінці екстрактор побічних ефектів визначає, що фактично змінилося, а детерміновані оцінювачі порівнюють це з необхідним кінцевим станом, приймаючи будь-яку траєкторію, яка приводить до правильного результату, і відхиляючи неправильні, відсутні або додаткові ефекти. Для вимог, які не мають чіткого значення в базі даних («чи повідомив агент, що це не гарантовано?»), семантику обробляє вузьке бінарне питання рубрики. 477 із 507 завдань оцінюються лише за станом; для 30 додатково застосовуються рубрики відповіді.

Межа довіри: модель бачить завдання, діалог і схеми інструментів. Еталонний стан, твердження, внутрішні механізми оцінювання та облікові дані залишаються на стороні оцінювача.

Запустіть самостійно

ThinkingBox тепер доступний на Hugging Face — і каркас, і набір даних. ThinkingBox-Bench тепер працює через інтерфейс OpenEnv, і кожен завершений епізод повертає бінарну винагороду pass/fail. Випущений адаптер призначено для оцінювання; окремі сценарії, не пов’язані з бенчмарком, можуть використовувати той самий інтерфейс у процесах навчання.

Перед початком

Протестовано на Linux і WSL, із Python 3.11+, uv і Docker. Також потрібні клон репозиторію thinkingbox-data на зафіксованому випуску та кінцеві точки моделей для агента, симульованого користувача й оцінювача. Одна кінцева точка може обслуговувати всі три ролі — це найпростіший спосіб почати. Образ OpenEnv запускає лише API OpenEnv; усе інше ви запускаєте самостійно.

Встановлення

git clone https://github.com/huggingface/OpenEnv
cd OpenEnv
uv sync --project envs/thinkingbox_env --frozen

git clone https://github.com/microsoft/thinkingbox-data
git -C thinkingbox-data checkout thinkingbox-bench-v1.0

uv tool install "thinkingbox @ git+https://github.com/microsoft/thinkingbox"

Запуск Typesense

У другому терміналі запустіть Typesense 30.1 і дочекайтеся перевірки працездатності:

mkdir -p .typesense-data
docker run --rm -d --name thinkingbox-typesense \
  -p 8108:8108 \
  -v "$PWD/.typesense-data:/data" \
  typesense/typesense:30.1 \
  --data-dir /data --api-key=Fake --enable-cors
until curl -fsS http://127.0.0.1:8108/health; do sleep 1; done

Запуск серверів MCP

У третьому терміналі запустіть проксі сеансів і сервери MCP.

cd OpenEnv
tb mcp-start --host 127.0.0.1 --port 7111 \
  --servers "$PWD/thinkingbox-data/servers/servers.yaml"
curl -fsS http://127.0.0.1:7111/health

Запуск сервера OpenEnv

Поверніться до першого терміналу та запустіть сервер OpenEnv із YAML-конфігурацією ThinkingBox, у якій зазначено три ваші моделі (посібник із конфігурації):

OPENENV_TB_CONFIG="$PWD/thinkingbox.yaml" \
uv run --project envs/thinkingbox_env --frozen server

Перевірка готовності

Перед будь-яким запуском дочекайтеся готовності. До проходження перевірок доступних даних, конфігурації та проксі сеансів він повертає 503. Він не може спостерігати за Typesense або перевіряти в реальному часі кожну кінцеву точку моделі, тому підтвердьте їх окремо:

curl -sS http://127.0.0.1:8000/ready

Оцінювання епізоду

Тепер оцініть реальний епізод. example_usage.py лише скидає стан і перелічує інструменти; для дій агента, ефектів і тверджень використовуйте вбудований оцінювач:

echo "- sandbox_external_retail_group1.py:test_case_ST002_001" > one_task.yaml
uv run --project envs/thinkingbox_env thinkingbox-eval \
  one_task.yaml \
  --config "$PWD/thinkingbox.yaml" \
  --output results.jsonl \
  --errors-output errors.jsonl \
  --repeat 1 --message-timeout 1800

Адаптер OpenEnv записує операційні помилки в окремий файл, щоб їх можна було повторно запустити, а не непомітно змішувати з результатами моделі. Канонічний результат має розв’язати ці спроби або явно їх врахувати; системні помилки ми зараховували як невдалі випробування.

Запуски прив’язані до зафіксованого коміту фреймворку, зафіксованого випуску даних і хешу пакета, тому канонічний результат можна перевірити, а не просто заявити.

Що далі

Корисна частина цієї роботи — не наша таблиця лідерів pass@1. Це середовище.

Якщо ви оцінюєте агента, який працює з реальними записами:

1. Дослідіть помилку. Знайдіть запуск, який завершився коректно, але все одно був невдалим, і подивіться, що насправді змінилося в базі даних. Це змінює уявлення про те, що вимірюють ваші власні оцінювання.
2. Відтворіть одне завдання через OpenEnv із власною моделлю.
3. Повідомляйте метрику повторних запусків і визначайте її. Оберіть будь-яке k, виправдане вашим сценарієм використання; зазначте, чи повідомляєте ви best-of-k або every-of-k і як саме це обчислювали.

Додаткові відомості наведено за такими посиланнями:

• Середовище: envs/thinkingbox_env
• OpenEnv: https://huggingface.co/docs/openenv/environments/thinkingbox
• Фреймворк: microsoft/thinkingbox · посібник
• Бенчмарк: microsoft/thinkingbox-data · випуск v1.0
• Перегляд набору даних: microsoft/ThinkingBox-Bench
• Стаття: arXiv:2608.19741 або HF
• Навчання RL (незабаром): microsoft/thinkingbox-training

Код ThinkingBox ліцензовано за MIT; дані бенчмарку — за CDLA-Permissive-2.0; середовище OpenEnv поширюється за BSD-3-Clause OpenEnv.

Застереження: кожне завдання в загальнодоступному бенчмарку є синтетичною реконструкцією. Робочі процеси та політики змодельовано на основі реальних корпоративних сценаріїв використання AI-агентів; клієнти не є реальними.

ThinkingBox і ThinkingBox-Bench створено командою Microsoft Copilot Studio у партнерстві з Toloka за участю співробітників Університету Піттсбурга, Northwestern University, Columbia University та UC Irvine, які проходили стажування в Microsoft.

⁺ Знімок вартості OpenRouter зроблено 20 вересня 2026 року; ціни на Opus 5.5 наведено відповідно до сайту Anthropic.

Набори даних, згадані в цій статті 1

Статті, згадані в цій статті 1

Інші матеріали цього автора