Как ThinkingBox оценивает ИИ-агентов по реальным изменениям в базе данных

Современные разработчики часто доверяют отчетам ИИ-агентов, которые рапортуют об успешном выполнении задач, однако реальное состояние бэкенда может сильно расходиться с текстовыми ответами. На сайте Microsoft ThinkingBox недавно был представлен инструмент и бенчмарк, который проверяет не формулировки нейросетей, а оставленные ими фактические следы и записи в базе данных.

В этом материале я подробно разберу, как устроен этот подход, почему успешный разовый запуск не гарантирует стабильности и как протестировать модели самостоятельно с помощью окружения OpenEnv.

Вызов инструмента — это еще не готовый результат

Финальные ответы моделей и корректные вызовы функций служат лишь косвенными признаками работы. Агент способен выдать уверенный текст, но при этом записать неверное значение в таблицу или оставить лишние побочные эффекты. Истинное положение дел отражают исключительно те изменения, которые фиксируются в системе после завершения сценария.

Масштабы расхождений впечатляют. В ходе обширного тестирования, охватившего 121 680 валидных запусков на 12 различных языковых моделях, почти 80 тысяч попыток провалили автоматические проверки бэкенда. Более чем в 67% неудачных случаев агент завершал работу корректно, успешно задействовал инструменты изменения данных и не возвращал никаких ошибок в консоли. Тем не менее проверка выявила неправильные значения полей, пропущенные требования или несанкционированные побочные эффекты.

Надежность нельзя измерить по одной успешной попытке

Если алгоритм безупречно справляется с оформлением возврата средств в одном случае из пяти, его нельзя назвать надежным рабочим инструментом. Именно поэтому каждый тест в бенчмарке запускается 20 раз подряд из абсолютно чистого и идентичного начального состояния бэкенда. Такой подход позволяет отслеживать не просто разовый успех, а реальную повторяемость результата.

Традиционные лидерборды обычно публикуют метрику pass@1, которая демонстрирует средний показатель успешности с первой попытки. Однако анализ стабильности показывает, что далеко не все передовые модели способны удерживать этот уровень при многократном повторении. Лишь немногие решения сохраняют высокую результативность на длинной дистанции, в то время как большинство теряет значительную часть своей точности.

Цена стабильности и экономическая эффективность

Сравнение ИИ-моделей редко выходит за рамки общих баллов точности, хотя для практического внедрения критически важна стоимость одной успешной рабочей операции. Исследователи рассчитали затраты на основе расценок OpenRouter, разделив общие расходы на количество успешных выполнений. Такой индекс эффективности позволяет оценить реальные затраты на поддержание работы агента.

Порог затрат по критерию Парето

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

Оценка стоимости стабильной работы

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

Анализ типичных ошибок агентов

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

Чтобы повысить надежность ИИ-систем в продакшене, стоит рассматривать показатели стабильности на длинной дистанции как исходные требования при проектировании архитектуры. Полезно внедрять предварительную проверку терминального состояния базы данных до фиксации изменений, настраивать точную классификацию системных сбоев для корректных повторных попыток и обязательно запрашивать подтверждение человека для необратимых операций.

Как устроено рабочее окружение ThinkingBox

Проект разделен на изолированную песочницу для выполнения задач и набор данных ThinkingBox-Bench. Каждое задание определяет начальное состояние бэкенда, цель пользователя, доступные инструменты протокола MCP и правила проверки через исполняемые скрипты. Симулированный пользователь хранит конфиденциальные данные и передает их агенту только по запросу.

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

Инструкция по самостоятельному запуску тестов

Платформа доступна на Hugging Face, позволяя развернуть окружение локально для оценки собственных конфигураций и моделей. Процесс развертывания требует базовой подготовки инфраструктуры.

Подготовка к работе

Для тестирования потребуется операционная система Linux или среда WSL, установленный интерпретатор Python версии 3.11 и выше, менеджер пакетов uv, а также Docker. Скачайте репозиторий бенчмарка и подготовьте эндпоинты для агента, симулятора пользователя и судьи, причем все три роли могут обслуживаться одним локальным сервером.

Установка компонентов

Клонируйте репозиторий OpenEnv, синхронизируйте зависимости проекта, загрузите данные бенчмарка с привязанным релизом и установите интерфейс командной строки ThinkingBox с помощью менеджера uv согласно официальной документации.

Запуск базы данных Typesense

В отдельном терминале запустите поисковый движок Typesense версии 30.1 в режиме контейнера Docker. Настройте директорию данных, задайте фиктивный API-ключ и включите поддержку CORS, после чего дождитесь успешного прохождения проверки работоспособности сервиса.

Запуск MCP-серверов и OpenEnv

В следующих терминальных окнах активируйте прокси сессий и необходимые серверы MCP, а затем инициализируйте основной сервер OpenEnv, передав ему конфигурационный файл YAML с описанием используемых моделей.

Проверка готовности и оценка эпизода

Перед запуском тестов убедитесь в готовности системы через специальный эндпоинт проверки статуса. Для оценки конкретного эпизода используйте упакованный инструмент тестирования, указав путь к файлу конфигурации и настроив параметры повторов для сбора детальной статистики ошибок.

Дальнейшее развитие подхода

Главная ценность созданной среды заключается не в разовых таблицах лидеров, а в самом изолированном окружении для тестирования. Если вы разрабатываете ИИ-агентов, взаимодействующих с реальными корпоративными базами данных, начните с детального анализа неудачных запусков. Изучайте, какие именно изменения произошли в системе при внешне успешном завершении диалога, и внедряйте воспроизводимые метрики повторения для контроля качества.