Надёжность AI-агентов: как база данных стала наградой

Надёжность AI-агентов: как база данных стала наградой

507 задач, по 20 попыток на каждую, 10 140 прогонов. Так выглядит проверка, которая ломает привычную метрику качества агентов: Kimi-K3 решает 93,89% задач хотя бы один раз, но доводит до правильного конца только 68 задач из 507 на всех двадцати попытках. Это 13,41%. Средняя точность у такой модели выглядит прилично, а в продакшене она разваливается на третьем повторе.

Команда Microsoft Copilot Studio вместе с Hugging Face и Toloka довела эту мысль до логического конца. Если финальное состояние базы данных можно проверить кодом, то ту же проверку можно использовать как награду при обучении. Они взяли Qwen3.8-27B, дообучили её методом GRPO на задачах вне бенчмарка и получили рост повторяемого успеха с 38 задач до 107 при падении цены надёжного результата на 67%.

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

Почему средняя точность врёт

В первом посте авторы прогнали восемнадцать моделей по 507 задачам двадцать раз каждую и увидели разрыв, который скрывает обычная метрика. Claude Opus 5.5 обошел Claude Opus 5 на 0,66 процентного пункта по pass@1, но прошёл ровно те же 241 задачу на всех двадцати попытках. Прибавка в заголовочной точности не дала ни одной дополнительной надёжной задачи.

Обратная ситуация тоже встречается. GPT-5.6 Sol набирает 61,91% против 59,19% у Claude Sonnet 4.6, но держит повторяемый результат только на 82 задачах, тогда как Sonnet 4.6 на 102. Порядок моделей меняется в зависимости от того, что считать качеством.

Отсюда практический вывод для тех, кто выбирает модель под работу с реальными записями: pass@1 нельзя читать в одиночку. Метрика observed 20/20 показывает, какие задачи проходят на каждой попытке, и это ближе к тому, что продакшен считает надёжностью.

Проверка как награда

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

Механика простая и в этом её сила. Когда эпизод заканчивается, песочница снимает изменения бэкенда и прогоняет детерминированные проверки задачи. Правильное конечное состояние даёт 1, любое отклонение даёт 0. Лишние побочные эффекты тоже считаются провалом, а не мелким недочётом. Траектория агента значения не имеет: важен только результат, который он оставил после себя.

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

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

Что дала тренировка

Qwen3.8-27B дообучали на отобранном пуле задач и проверяли на тех же 507 задачах, которых модель во время обучения не видела. Домены, базы и большинство инструментов в тесте не совпадали с тренировочными.

Метрика База После RL Изменение
Наблюдаемый успех 20/20 38 (7,50%) 107 (21,10%) +69 задач
pass@1 по попыткам 5 242 (51,70%) 6 163 (60,78%) +9,08 п.п.
pass@20 по задачам 453 (89,35%) 446 (87,97%) −7 задач

Разрыв между строками таблицы и есть главный результат. Модель стала почти втрое чаще доводить задачу до правильного состояния на каждой из двадцати попыток, при том что общее покрытие слегка просело.

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

Где прирост, а где потеря

pass@1 и observed 20/20 выросли во всех пяти доменах: ритейл, автострахование, путешествия, необанк, консалтинг. С pass@20 картина смешанная: в необанке и консалтинге покрытие выросло, в ритейле, путешествиях и автостраховании упало, причём в страховании сильнее всего, на 7,0 процентных пункта. Самый большой прирост повторяемости дал ритейл, плюс 24,5 пункта.

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

Для продукта такой обмен обычно выгоден: агент, который делает правильно семь раз из десяти, дороже в поддержке, чем агент, который делает правильно пять раз из десяти, но всегда одинаково.

Цена надёжности в долларах

Авторы посчитали не только проценты. Они оценили стоимость полного прогона 507 задач по 20 попыток и разделили её на число задач, которые модель прошла каждый раз.

Показатель База После RL Изменение
Стоимость кампании, 20 прогонов $925,80 $855,58 −7,6%
Цена успешной попытки $0,177 $0,139 −21,4%
Задач с успехом 20/20 38 107 в 2,8 раза больше
Цена надёжной задачи $24,36 $8,00 −67,2%

Восемь долларов за задачу, которая проходит всегда, ставят дообученную 27B модель рядом с GPT-5.4 за $6,80, GPT-6 Astra за $7,45 и Claude Opus 5.5 за $7,80. Прямо скажем, это сравнение индексов обслуживания, а не счёт из облака: в расчёт входит инференс, но не входит стоимость самой тренировки и проб, которыми отбирали задачи. Обслуживание дообученного чекпоинта стоит столько же, сколько обслуживание базовой модели того же размера.

Как отбирают задачи: сложность относительно политики

Самая интересная часть работы не в цифрах, а в фильтре задач. Причина арифметическая. GRPO считает преимущество внутри группы роллаутов: если все восемь попыток провалились, вектор наград выглядит как восемь нулей, если все восемь удались, как восемь единиц. В обоих случаях центрирование даёт нулевое преимущество, и задача не учит ничему. Нужна смешанная группа вида 0, 0, 0, 1, 1, 1, 1, 1.

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

Для каждой задачи делают n проб на базовой политике и получают k успехов. Латентную вероятность успеха моделируют апостериорным распределением Джеффриса, Beta(k + ½, n − k + ½). Затем единичный интервал режут на пять корзин с границами 0,08, 0,40, 0,60 и 0,90 и относят задачу туда, где лежит наибольшая масса апостериорного распределения. Задачи из крайних корзин отбрасывают: те, что решаются редко, пока бесполезны, те, что решаются почти всегда, уже выучены. Средние три корзины идут в пул.

Пример из статьи: задача прошла 3 пробы из 8, апостериорное распределение Beta(3,5, 5,5), 54,0% массы попадает в корзину сложных. При сэмплировании она дала смешанную группу 0, 0, 0, 0, 1, 1, 1, 1, и GRPO получил контраст, на котором можно учиться. Для другой модели та же задача попала бы в другую корзину, потому что сложность здесь относительна политики, а не абсолютна.

Роль грубого сита сыграл GPT-5.4: он отсеивал задачи, которые не решаются в принципе. Итоговый пул для Qwen3.8-27B составил 187 задач, и ни одна задача из бенчмарка в него не попала.

Что было в самой тренировке

Дообучали полные параметры Qwen3.8-27B методом token-mean GRPO. Каждый шаг давал 18 групп по 8 роллаутов, то есть 144 эпизода, на 24 ускорителях H100 (три узла по восемь GPU). AdamW шёл с learning rate 1e-6 и нулевым weight decay, всего 50 шагов. Группы с нулевой дисперсией заменяли в стиле DAPO, а системные ошибки вроде таймаута бэкенда не считали провалом агента: такие группы пополняли заново.

Отдельная деталь, которую легко пропустить при внедрении: тренировка и оценка должны интерпретировать выход модели одинаково, включая извлечение рассуждений, вызовы инструментов, типы аргументов и рендеринг. Если парсеры расходятся, награда измеряет одного агента, а на графике оказывается другой.

Стек открыт: код ThinkingBox под MIT, данные бенчмарка под CDLA-Permissive-2.0, тренировочный репозиторий microsoft/thinkingbox-training собран вокруг Verl 0.9.0, а оценка шла через vLLM на восьми A100 с tensor parallel 8 и контекстом 262 144 токена. Статья с деталями вышла как arXiv:2608.19741.

Три проверки перед своим RL-обучением

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

Второе: паритет парсеров. Прогоните один и тот же записанный ответ модели через тренировочный и оценочный разбор и убедитесь, что имена инструментов и аргументы совпадают. Иначе обучение будет награждать поведение, которое оценка читает иначе.

Третье: обе метрики в отчёте. Указывайте, сколько задач проходит хотя бы раз за k попыток и сколько проходит все k. Модель, которая иногда находит решение, не обязательно та, которая его повторяет.

Часто задаваемые вопросы

Чем observed 20/20 отличается от pass@20?

pass@20 отвечает, сколько задач модель решила хотя бы в одной из двадцати попыток. observed 20/20 считает задачи, которые прошли все двадцать раз. Первое показывает потенциальное покрытие, второе показывает повторяемость, и именно второе ближе к требованию продакшена.

Почему после обучения pass@20 упал?

Дообучение заостряет распределение: масса уходит к траекториям, которые работают стабильно, а редкие удачные пути исчезают. В результате модель чаще повторяет правильное поведение и чуть реже находит экзотическое решение. В цифрах это минус 7 задач по покрытию против плюс 69 по повторяемости.

Подход работает, если у агента нет базы данных?

Нужен не обязательно SQL. Подойдёт любое конечное состояние, которое проверяется кодом: файлы на диске, состояние API, тикеты в трекере, записи в очереди. Если результат нельзя проверить исполняемо и приходится оценивать текст ответа, схема ломается, потому что награда перестаёт быть бинарной.

Итог

История ThinkingBox показывает, что надёжность AI-агентов можно измерять и оптимизировать напрямую, если у задачи есть проверяемое конечное состояние. Проверка базы данных оказалась одновременно экзаменатором и наградой: 27B модель выросла с 7,5% до 21,1% по повторяемому успеху, обогнав по этому показателю GPT-6 Astra и Kimi-K3, а цена надёжного результата упала с $24,36 до $8,00.

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

← Все записи