В мире автономных AI-агентов существует фундаментальная проблема, которую часто называют «иллюзией компетентности». Агент может выглядеть умно: он делает правильные вызовы API, генерирует логичные рассуждения и даже сообщает, что задача выполнена. Но если заглянуть под капот, в конечное состояние системы, окажется, что данные повреждены, транзакция не завершена или нарушены бизнес-правила. Именно эту проблему пытается решить команда Microsoft в соавторстве с Hugging Face, представив методологию ThinkingBox. Это не просто бенчмарк для оценки, а полноценный фреймворк для обучения агентов, где «истина» определяется не текстовым ответом модели, а фактическим изменением в базе данных.
В этой статье мы подробно разберем, как превратить сухие проверки состояния базы данных (database grading) в эффективные функции вознаграждения (rewards) для обучения с подкреплением (Reinforcement Learning, RL). Мы посмотрим на результаты обучения модели Qwen3.8-27B, где доля задач, решаемых стабильно, выросла с 7.5% до 21.1%, и разберем технические детали того, как отбирать задачи для обучения, чтобы избежать «нулевой дисперсии» и обеспечить реальный прогресс.
01От оценки к обучению: философия ThinkingBox
Изначально ThinkingBox создавался как инструмент для отлова агентов, которые заявляют о завершении работы, когда на самом деле это не так. В нашем предыдущем материале мы приводили пример: агент закрывал тикет клиента как «решенный», хотя системное исключение у перевозчика все еще было открыто. Девять看似 правильных вызовов инструментов, но одна неверная строка в базе данных перечеркивала всю работу.
Ключевое наблюдение, сделанное исследователями, заключается в том, что для большинства задач исполняемая проверка конечного состояния базы данных может вернуть бинарное значение: 1 (успех) или 0 (неудача). Это не просто система оценки (grader). Это идеальная функция вознаграждения для обучения с подкреплением. Вместо того чтобы полагаться на субъективные оценки языковой модели (LLM-as-a-judge), мы используем детерминированный факт: изменилась ли запись в БД так, как требовалось?
Однако использование этих проверок для обучения требует осторожности. Не все задачи подходят для RL. Если задача уже решается моделью в 100% случаев, она не дает градиента для обучения. Если же задача нерешаема для текущей архитектуры, модель просто будет получать нулевые награды, что также неэффективно. Здесь вступает в игру концепция оффлайн-относительной сложности (offline policy-relative difficulty).
02Что показал бенчмарк: разрыв между точностью и надежностью
Чтобы понять масштаб проблемы, давайте посмотрим на данные ThinkingBox-Bench. Это набор из 507 задач, каждая из которых запускает реальную бэкенд-систему, предоставляет агенту набор инструментов MCP (Model Context Protocol) и симулированного пользователя. В конце работы запускаются исполняемые проверки против терминального состояния базы данных.
В нашем первом исследовании мы протестировали 18 моделей, выполняя каждую задачу 20 раз. Мы обнаружили критический разрыв между «головной точностью» (pass@1) и «надежностью» (observed 20/20). Например, модель Kimi-K3 решала 93.89% задач хотя бы один раз, но стабильно (во всех 20 попытках) решала лишь 68 задач (13.41%). Напротив, Claude Opus 5 имел меньшее покрытие, но гораздо большую консистентность.
Более того, увеличение размера модели или её «умности» не всегда закрывает этот разрыв. Claude Opus 5.5 улучшила показатель pass@1 всего на 0.66 процентных пункта по сравнению с версией 5, но количество задач, решаемых стабильно, осталось неизменным — 241 задача. Это означает, что прирост в средней точности не принес никакой дополнительной надежности для продакшена.
03Результаты обучения: Qwen3.8-27B после RL
Используя методологию ThinkingBox, мы обучили модель Qwen3.8-27B с помощью алгоритма GRPO (Group Relative Policy Optimization) в течение 50 шагов. Важно отметить, что бенчмарк ThinkingBox-Bench (507 задач) был полностью исключен из обучающей выборки. Это тестовая выборка вне распределения (out-of-distribution), что позволяет оценить реальную обобщающую способность модели.
Результаты оказались впечатляющими, особенно в аспекте надежности:
- Observed 20/20: Доля задач, решаемых во всех 20 попытках, выросла с 38 (7.50%) до 107 (21.10%). Это почти трехкратное увеличение.
- pass@1: Средняя доля успешных попыток выросла с 51.70% до 60.78% (+9.08 п.п.).
- pass@20: Доля задач, решенных хотя бы один раз, незначительно снизилась с 89.35% до 87.97%.
Этот паттерн согласуется с теорией «заточки» (sharpening) распределения вероятностей. Модель перестала полагаться на удачные, но редкие траектории (что снижало pass@20), и сфокусировалась на траекториях, которые работают стабильно. Она не стала «шире» в решении новых типов задач, но стала значительно более надежной в тех, которые она уже умеет решать.
04Где именно произошли улучшения?
Анализ по доменам показывает, что улучшения затронули все пять категорий: розничная торговля, автострахование, путешествия, необанки и консалтинг. Однако характер улучшений различался.
В домене розничной торговли (Retail) наблюдался наибольший прирост в надежности: количество стабильно решаемых задач выросло на 24.5 пункта. В то же время в автостраховании (Auto Insurance) произошло наибольшее снижение охвата (pass@20), что указывает на то, что модель могла потерять способность находить нестандартные решения в этой сложной области, сфокусировавшись на стандартных.
Рассмотрим конкретный пример из домена путешествий. Путешественник запрашивает понижение класса номера, но политика компании требует предварительного согласования с менеджером. До обучения агент в 15 из 20 попыток менял бронирование и выдавал возвраты без одобрения менеджера, нарушая политику. После RL-дообучения агент сохранил состояние бронирования и платежа в неизменном виде во всех 20 попытках, корректно запросив одобрение или отказав в изменении.
05Экономика надежности: сколько стоит стабильность?
Одним из самых интересных аспектов работы является оценка экономической эффективности. Надежность имеет цену, но обучение с подкреплением может эту цену снизить. Мы используем метрику «стоимость за надежную задачу» (cost per dependable task), которая рассчитывается как общая стоимость кампании тестирования, деленная на количество задач, решенных стабильно.
Для базовой модели Qwen3.8-27B стоимость одной надежной задачи составляла около $24.36. После RL-дообучения эта стоимость упала до $8.00. Это делает обученную модель сопоставимой по эффективности с такими коммерческими моделями, как GPT-5.4 ($6.80) и Claude Opus 5.5 ($7.80), при этом сохраняя конкурентоспособные показатели точности.
Также стоит отметить снижение стоимости одной успешной попытки (cost per successful attempt) с $0.177 до $0.139. Это связано с тем, что обученная модель тратит меньше токенов на исправление ошибок и повторные попытки, так как её первая попытка чаще оказывается правильной.
06Петля обучения: как это работает технически
Процесс обучения в ThinkingBox состоит из нескольких этапов, где критически важным является этап отбора задач. Обучение происходит оффлайн: сначала мы оцениваем базовую политику, затем фиксируем пул задач, и только потом запускаем RL.
Оффлайн-относительная сложность
Почему отбор задач так важен? Алгоритм GRPO (и многие другие алгоритмы RL) требует дисперсии в наградах внутри группы. Если все 8 роулов (episodes) в группе проваливаются, вектор наград будет [0, 0, 0, 0, 0, 0, 0, 0]. Центрирование такого вектора дает ноль, и модель не получает полезного сигнала для обновления весов. То же самое происходит, если все 8 роулов успешны: [1, 1, 1, 1, 1, 1, 1, 1].
Поэтому нам нужны задачи, которые модель решает «иногда». Мы используем байесовский подход для оценки вероятности успеха. Каждая кандидатная задача запускается N раз на базовой модели. Мы моделируем латентную вероятность успеха с помощью распределения Бета (Jeffreys posterior):
# Псевдокод оценки сложности
# k - количество успехов, n - количество запусков
# Используем Jeffreys prior: Beta(k + 0.5, n - k + 0.5)Задачи распределяются по пяти корзинам на основе вероятности успеха:
- Редко решаемые [0, 0.08): Отбрасываются. Модель еще не готова их решать.
- Сложные [0.08, 0.40): Оставляются. Здесь есть потенциал для обучения.
- Промежуточные [0.40, 0.60): Оставляются. Идеальная зона для контраста.
- Часто решаемые [0.60, 0.90): Оставляются для полного RL-дообучения.
- Почти всегда решаемые [0.90, 1]: Отбрасываются. Задача уже выучена.
Архитектура роула и интерпретация
Каждый роулл в обучении — это полная эпизодическая сессия. Агент получает новый изолированный бэкенд, сессию MCP и симулированного пользователя (в нашем случае GPT-5 Chat). Большинство наград приходят от детерминированных проверок терминального состояния. Однако для некоторых узких критериев может использоваться настроенный судья (LLM-judge).
Критически важно, чтобы код интерпретации вывода Qwen во время обучения и во время оценки был идентичным. Это включает извлечение рассуждений, вызовы инструментов, типизацию аргументов и рендеринг. Любое расхождение приведет к тому, что награда будет измерять поведение другого агента, чем тот, который оценивается.
Для референсного запуска мы использовали полный параметрический RL-файн-тюнинг Qwen3.8-27B на 187 задачах. Каждый шаг обновления генерировал 18 групп по 8 роулов (144 эпизода) на 24 GPU H100. Использовался оптимизатор AdamW с learning rate 1e-6 и нулевым weight decay. Нуль-вариансные группы заменялись по методу DAPO, а системные ошибки (таймауты бэкенда) обрабатывались отдельно, не засчитываясь как провалы агента.
07Что это значит на практике
Разработка ThinkingBox и демонстрация её эффективности на Qwen3.8-27B меняют парадигму разработки AI-агентов для энтерпрайза. Вот ключевые выводы для практикующих инженеров и архитекторов:
- Надежность важнее средней точности. В продакшене, где агенты работают с базами данных, одна ошибка может стоить дорого. Метрика pass@1 скрывает проблему нестабильности. Инженерам следует фокусироваться на увеличении доли задач, решаемых стабильно (observed 20/20), даже ценой небольшого снижения охвата новых сценариев.
- Исполняемый код как награда. Использование детерминированных проверок состояния системы (database state checks) вместо субъективных оценок LLM дает более чистый и эффективный сигнал для обучения. Это устраняет шум и противоречия в процессе обучения.
- Критическая важность отбора задач. Обучение RL — ресурсоемкий процесс. Без тщательного отбора задач, находящихся в «зоне ближайшего развития» модели (policy-relative difficulty), обучение может зайти в тупик из-за отсутствия дисперсии в наградах. Оффлайн-фильтрация на основе байесовских оценок — необходимый шаг.
- Экономическая целесообразность. RL-дообучение может не только повысить качество, но и снизить стоимость обслуживания за счет уменьшения количества токенов, необходимых для успешного выполнения задачи. Модель, которая решает задачу с первой попытки, дешевле в эксплуатации.
ThinkingBox демонстрирует, что путь к надежным агентам лежит не только через увеличение размера моделей, но и через более умные методы обучения, основанные на реальных результатах работы системы. Для российских разработчиков и компаний, внедряющих AI-агентов в корпоративные процессы, эти принципы особенно актуальны, так как позволяют повысить отказоустойчивость систем при работе с критическими данными.
Полный код для воспроизведения обучения и оценки доступен на GitHub. Мы рекомендуем изучить этот проект всем, кто занимается разработкой автономных агентов, работающих с внешними системами и базами данных.
Источник: Hugging Face ↗