Недавно мы в red_mad_robot выпустили открытый benchmark для детекции персональных данных в русском тексте. Внутри данные, собранные из реальных продакшен-сценариев.
Параллельно Валера Ковальский сравнивает Drift и другие агентные оболочки на наборе открытых benchmark как дополнительная обратная связь для продукта.
Ранее я писал, что главный инженерный вызов в агентных системах сейчас связан с качеством обратной связи и создатель Claude Code Борис Черный недавно подтвердил эту мысль: «Переход от агентов к loops - такой же большой скачок, как когда-то переход от обычного кода к агентам». Но loop работает, только если система умеет определить ошибку и понять, стоит ли продолжать работу.
Поэтому я решил разобрать семейство открытых бенчмарков
τ-bench. Первая версия проверяла общение агента с пользователем и работу с tools. В τ²-bench пользователь получил возможность действовать в среде, а не только отвечать агенту. А τ³-bench добавил задачи с базами знаний, голосовой режим испытаний и набор исправлений в сценариях. Разбирать такой benchmark удобнее через четыре слоя. Покажу их на одном сценарии:Yusuf Rossi получил заказ #W2378156 и хочет обменять клавиатуру и термостат. Нужная клавиатура с подсветкой недоступна, поэтому пользователь согласен на модель без неё. Провести обмен можно только один раз.
⬥⬥⬥
1. Слой данных и среды
Первый слой создаёт мир, в котором работает агент: данные, связи между ними и последствия действий. Например, в домене Retail, который моделирует интернет-магазин, это пользователи, товары, их варианты, заказы и платежи.
Так появляется Yusuf Rossi, доставленный заказ, две купленные позиции и доступные варианты. Клавиатура существует на двух уровнях, как тип товара
product_id, так и конкретная версия с размером и подсветкой item_id. Поэтому агент может подобрать другой вариант той же клавиатуры, но не заменить её термостатом.Среда определяет, как агент работает с данными: одни инструменты ищут пользователя и заказ, другие меняют состояние. В банковском домене добавляется корпоративная неструктурированная база знаний с регламентами. Агент ищет правило в документах и применяет его к ситуации.
⬥⬥⬥
2. Методология
Методология определяет, какое поведение считается правильным. Сценарий задаёт желание пользователя: Yusuf хочет заменить две позиции и решить всё за один разговор.
Дальше вступают бизнес-ограничения. Правила магазина требуют подтвердить личность, менять только товары из доставленного заказа и получить согласие. Для нашего сценария критично: обменять модно только один раз, поэтому обе позиции нужно подготовить заранее. Из данных это не следует, правило живёт на уровне бизнеса.
Критерии успеха фиксируют итог: в заказе появляются нужные варианты клавиатуры и термостата, пользователь получает возврат разницы на карту, агент объясняет условия и дожидается подтверждения.
⬥⬥⬥
3. Слой исполнения
Симулятор раскрывает запрос Yusuf. Агент уточняет детали, читает заказ, подбирает варианты и решает, когда проводить обмен. Оркестратор передаёт реплики, направляет вызовы в среду и пишет журнал.
В голосовом режиме добавляются задержки, шум, перебивания и ошибки распознавания имени или подтверждения.
⬥⬥⬥
4. Слой оценки
Последний слой превращает испытание в результат: к какому состоянию агент привёл мир.
Оценщик строит эталон из правильных действий. Для Yusuf это заказ, где обе позиции заменены одним вызовом, а разница возвращена на карту. Затем оценщик сравнивает состояние после действий агента с эталоном, если совпало — задача пройдена. Что входит в проверку, задаётся отдельно: состояние базы, обязательная информация в ответе или утверждения на естественном языке. У Yusuf всё держится на состоянии базы.
Для надежности добавляется повторяемость: агент должен пройти одну задачу несколько раз подряд. Один удачный прогон плохо описывает надёжность.
τ³-bench хороший пример устройства benchmark. И он же показывает, что такой инструмент требует отдельной работы: данных, сценариев, среды, оценщика и постоянной чистки ошибок в самих задачах.видео
О чем молчит AI CTO