τ²-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 пунктів. Цей розрив — вартість координації з активним користувачем, відокремлена від складності самого міркування.
• Розрив з оракул-планом: Навіть коли агенту заздалегідь надається повна послідовність дій, продуктивність не досягає 100%, що свідчить про те, що виконання та координація з користувачем додають помилок понад планування.
• Структуровані інструменти користувача різко знижують шум симулятора: Симулятор користувача в телекомі створює лише 16% помилок (6% критичних) порівняно з 40% помилок (12% критичних) для роздрібної торгівлі в оригінальному τ-bench. Покращення досягнуто завдяки заміні нечітких підказок природною мовою на жорстко обмежений інтерфейс інструментів, який відстежує стан пристрою.

Що витримує критику, а що ні

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

З іншого боку, телеком-домен є вузьким. Чотири клієнти, дев'ять ліній, п'ять тарифних планів: це контрольована лабораторія, а не корпоративна система. Показники pass¹ для gpt-4.1-mini та Claude 3.7 Sonnet (~50%) виглядають напрочуд високими, враховуючи складність домену, про яку заявляють автори. Це змушує задуматися, чи достатньо 114 завдань, щоб уникнути випадкових вдалих запусків, які завищують бали. Автори визнають, що їх набір завдань є лише підвибіркою. Також я вважаю аналіз образів (persona) користувачів поверхневим: стаття показує, що "важкий" образ (64-річний пенсіонер з низькою технічною впевненістю) складніший за "легкий", що цілком очікувано. Я хотів би побачити, чи відрізняється тип помилок координації — чи спричиняє складніший образ більше помилок міркування чи помилок комунікації?

Стаття також не досліджує, що відбувається, коли документ з політикою агента є неправильним або неповним, що є реалістичним сценарієм для промислового впровадження. Усі результати припускають, що агенту надані точні інструкції.

Чому це важливо для фінансового ШІ

Припущення про одноосібне керування, закладене в τ-bench, WorkArena та більшість бенчмарків діалогових систем, погано узгоджується з реальним сценарієм підтримки Beancount. Користувач, який просить агента Beancount виправити гросбух (ledger), не просто описує проблему — він може одночасно редагувати файл у текстовому редакторі, запускати 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 завдань у симульованій програмній компанії з реальними внутрішніми інструментами; найбільш реалістичний бенчмарк корпоративної автоматизації на сьогодні та наступна стаття в моєму списку для читання.