τ²-bench: Оценка стоимости двойного управления в разговорных ИИ-агентах

Последние несколько недель я изучал семейство бенчмарков τ-bench, и τ²-bench (arXiv:2506.07982) — это именно та работа, которую я ждал: она наконец задает вопрос, что происходит, когда пользователь является не пассивным источником информации, а активным участником со своим набором инструментов. Для любого, кто создает разговорного бухгалтерского агента, этот пробел всегда был очевиден.

Статья

Виктор Баррес, Хунхуа Донг, Сохам Рэй, Сюцзе Си и Картик Нарасимхан (Sierra AI и Университет Торонто) представляют τ²-bench как прямое расширение оригинального τ-bench. Основное наблюдение заключается в том, что предыдущие бенчмарки для разговорных ИИ-агентов являются одноуровневыми (single-control): только агент может вызывать инструменты; пользователь ограничен сообщениями на естественном языке. Реальная техническая поддержка опровергает это предположение. Когда агент службы поддержки говорит вам «выключить режим полета», вы выполняете вызов инструмента на своем устройстве, а не просто озвучиваете свои предпочтения.

Авторы моделируют это как децентрализованный частично наблюдаемый марковский процесс принятия решений (Dec-POMDP), где и агент, и симулятор пользователя имеют отдельные пространства действий (вызовы функций и сообщения) над общим динамическим состоянием мира. Сторона агента выглядит как стандартная CRM: он может просматривать записи клиентов, включать роуминг или заменять SIM-карту. Сторона пользователя — это эмулированный телефон с инструментами чтения (get_status_bar, get_sim_status) и инструментами записи (toggle_airplane_mode, toggle_data, reseat_sim_card). Бенчмарк поставляется с новым телекоммуникационным доменом (114 задач, отобранных из 2285 программно сгенерированных вариантов) наряду с проверенными доменами розничной торговли (115 задач) и авиалиний (50 задач) из оригинального τ-bench.

Ключевые идеи

• Формализм двойного управления: Представление через Dec-POMDP четко разделяет то, что наблюдает каждый игрок, и какие инструменты каждый может вызывать. Это более строго, чем ситуативный подход «пользователь с телефоном», который можно было бы прикрутить к существующей среде с одним агентом.
• Композиционный генератор задач: Задачи собираются из 15 групп атомарных подзадач, охватывающих три типа намерений (service_issue, mobile_data_issue, mms_issue), с явным масштабированием сложности по количеству требуемых шагов решения.
• Производительность в телекоме (pass¹): GPT-4.1 достигает лишь 34%; o4-mini — 42%; Claude 3.7 Sonnet — 49%; GPT-4.1-mini — около 50%. Все модели показывают здесь существенно более низкие результаты, чем в ритейле или авиаперевозках.
• Штраф за двойное управление: Абляционное исследование сравнивает режим по умолчанию (Default, у пользователя есть инструменты) с режимом без пользователя (No-User, агент сам управляет каждым инструментом). Результативность GPT-4.1 падает на 18 процентных пунктов; o4-mini — на 25 пунктов. Этот разрыв и есть стоимость координации с активным пользователем, отделенная от чистой сложности рассуждений.
• Разрыв с идеальным планом (Oracle-plan gap): Даже когда агенту заранее предоставляется полная последовательность действий, производительность не достигает 100%. Это говорит о том, что исполнение и координация с пользователем добавляют ошибки поверх планирования.
• Структурированные инструменты пользователя резко снижают шум симулятора: Симулятор пользователя в телеком-домене выдает только 16% ошибок (6% критических) по сравнению с 40% ошибок (12% критических) для ритейла в оригинальном τ-bench. Улучшение достигнуто за счет замены расплывчатых текстовых подсказок пользователю на жестко ограниченный интерфейс инструментов, отслеживающий состояние устройства.

Что заслуживает доверия, а что — нет

Фреймворк Dec-POMDP — одна из самых тщательно проработанных формулировок проблемы, которые я видел в бенчмаркинге агентов. Программный генератор задач действительно полезен: он предоставляет доказуемо корректные задачи и явно контролируемую сложность, в отличие от наборов задач ручной работы, которыми страдают большинство бенчмарков. Цифры надежности симулятора пользователя впечатляют — сокращение критических ошибок с 12% до 6% имеет большое значение, когда вы пытаетесь доверять результатам оценки.

Тем не менее, телекоммуникационный домен узок. Четыре клиента, девять линий, пять тарифных планов — это контролируемая лаборатория, а не корпоративная система. Показатели pass¹ для gpt-4.1-mini и Claude 3.7 Sonnet (~50%) выглядят на удивление высокими, учитывая, насколько сложным авторы называют этот домен. Это заставляет задуматься, достаточно ли 114 задач, чтобы избежать завышения баллов за счет удачных прогонов. Авторы признают, что их набор задач является выборкой. Также я нахожу анализ персон пользователей поверхностным: статья показывает, что персона «Hard» (64-летний пенсионер с низкой уверенностью в технологиях) сложнее, чем персона «Easy», что неудивительно. Я бы хотел увидеть, отличается ли тип сбоя координации — вызывает ли сложная персона больше ошибок рассуждения или больше ошибок коммуникации?

Статья также не исследует, что происходит, когда регламент (policy document) агента неверен или неполон, что является реалистичным сценарием для промышленного внедрения. Все результаты предполагают, что агенту даны точные инструкции.

Почему это важно для ИИ в финансах

Предположение об одиночном управлении, заложенное в τ-bench, WorkArena и большинство бенчмарков диалогов, плохо проецируется на реальный сценарий поддержки Beancount. Пользователь, просящий агента Beancount исправить его гроссбух, не просто описывает проблему — он может одновременно редактировать файл в текстовом редакторе, запускать bean-check или загружать новый CSV-экспорт из своего банка. Это среда двойного управления именно в понимании τ²-bench.

Падение на 18–25 процентных пунктов при переходе от режима No-User к Default — это цифра, к которой я буду постоянно возвращаться. Она предполагает, что даже если бы мы создали агента Beancount, который почти идеально манипулирует леджером в автономном режиме, появление активного пользователя с общим доступом на запись снизило бы вероятность успеха примерно на четверть. Безопасные архитектуры обратной записи, которые мы рассматривали (GuardAgent, ShieldAgent, верифицируемый MCP), были разработаны для условий одиночного управления; их нужно переосмыслить, если пользователь также является агентом, вызывающим инструменты в той же среде.

Улучшение надежности симулятора пользователя также имеет практическое применение. Если я хочу проводить офлайн-оценку агента Beancount без привлечения реальных бухгалтеров, правильным инженерным решением будет тесная привязка симулированного пользователя к детерминированной среде леджера, а не использование свободной ролевой игры LLM.

Что почитать дальше

• τ-bench (Yao et al., arXiv:2406.12045): Базовый бенчмарк, который расширяет данная работа. Стоит изучить оригинальную конструкцию задач и метрику pass^k перед интерпретацией результатов τ²-bench.
• ToolSandbox (Lu et al., arXiv:2408.04682): Представляет инструменты с сохранением состояния для детальной оценки агентов; наиболее релевантная архитектура для проектирования испытательного стенда Beancount с двойным управлением.
• TheAgentCompany (Xu et al., arXiv:2412.14161): 175 задач внутри симулированной софтверной компании с реальными внутренними инструментами; наиболее реалистичный бенчмарк автоматизации корпоративного уровня на данный момент и следующая статья в моем списке для чтения.