τ-bench: Вимірювання надійності ШІ-агентів у реальних сценаріях використання інструментів

Після кількох тижнів відстеження еволюції міркувань над таблицями та перетворення тексту в SQL, я захотів подивитися на ситуацію ширше: наскільки добре нинішні агенти справляються з роботою в реальному операційному циклі з користувачем? τ-bench дає найбільш чесну відповідь, яку я бачив, і цифри вражають.

Стаття

Яо, Шінн, Разаві та Нарасімхан — усі з Прінстона та Sierra Research — представили τ-bench (arXiv:2406.12045, червень 2024), щоб заповнити прогалину, яка є очевидною в ретроспективі: більшість бенчмарків для агентів дають моделі завдання та оцінюють її кінцеву відповідь ізольовано. Реальне впровадження виглядає інакше. Агента служби підтримки перебивають, ставлять уточнювальні запитання, надають суперечливу інформацію, і він має дотримуватися бізнес-політики протягом відкритого діалогу, перш ніж вносити будь-які зміни в базу даних.

τ-bench охоплює дві реальні сфери обслуговування клієнтів — ритейл та авіаперевезення — у середовищі симуляції, де одна мовна модель грає роль користувача, а інша — агента. Агент має доступ до галузевих API (скасувати замовлення, змінити місце, застосувати купон) та документа з правилами, що визначають дозволені дії за певних умов. Оцінювання не враховує проміжні кроки: воно порівнює кінцевий стан бази даних з анотованим цільовим станом. Автори також вводять pass^k — метрику надійності, яка визначає частку випробувань, у яких агент досягає успіху стабільно протягом k незалежних спроб одного й того ж завдання.

Ключові ідеї

• pass^k як чесна метрика: один показник pass@1 є занадто шумним. pass^k показує ймовірність того, що агент досягне успіху в кожному з k повторів одного й того ж завдання — це показник того, чи можна довіряти йому в реальній експлуатації.
• Прірва послідовності: GPT-4o у ритейлі отримує 0,604 у pass@1, але показник падає до 0,383 у pass@4. Це означає, що приблизно в 60% завдань він зазнає невдачі принаймні один раз за чотири спроби — навряд чи такого агента можна назвати безпечним для використання.
• Авіаперевезення складніші за ритейл: показник pass@1 для GPT-4o падає з 0,604 (ритейл) до 0,420 (авіалінії). Claude 3.5 Sonnet (версія за жовтень 2024 року) справляється краще — 0,692 у ритейлі / 0,460 в авіалініях для pass@1 — але його pass@4 все одно сягає лише 0,462 та 0,225 відповідно.
• Виклик функцій перемагає ReAct: варіант GPT-4o з викликом функцій (pass@1 = 0,420 в авіалініях) перевершує як Act (0,365), так і ReAct (0,325) на тій же основі, що свідчить про те, що структуровані API інструментів зменшують кількість збоїв, спричинених форматуванням.
• Симуляція користувача — це змінна: автори використовують мовну модель для імітації користувача, що вносить власну варіативність. Слабший симулятор може штучно занижувати або завищувати оцінки агента залежно від того, наскільки точно він відтворює змагальну поведінку користувача.
• Оцінювання за станом бази даних дозволяє уникнути ігор з «частковими балами»: порівняння кінцевого стану замість етапів діалогу означає, що агент, який виконав правильну дію, а потім випадково її скасував, не отримує балів — і це правильний підхід для систем із записом даних.

Що працює, а що — ні

Підхід pass^k справді корисний, і я очікую, що він переживе цей конкретний бенчмарк. Рішення оцінювати стан бази даних, а не подібність на рівні токенів, є правильним — це безпосередньо вимірює, чи виконав агент завдання, а не те, чи сказав він правильні слова.

Однак сфери застосування за дизайном вузькі. Ритейл та авіаперевезення процедурно чисті: документи з правилами скінченні та написані спеціально для бенчмарку, API невеликі та чітко визначені, а симулятор користувача за замовчуванням налаштований на співпрацю. У реальному світі правила двозначні; реальні користувачі брешуть, помиляються і чинять опір відмовам. Автори бенчмарку визнають це — сама поява τ²-bench (arXiv:2506.07982) як продовження, що розширюється до моделі подвійного контролю Dec-POMDP, де користувач також маніпулює станом середовища, є підтвердженням того, що оцінювання з одним контролером недооцінює складність.

Також залишається питання, що саме вимірює pass^k. Якщо сама симуляція користувача є стохастичною, то варіативність у k випробуваннях змішує непослідовність агента з непослідовністю симулятора. У статті це зазначено, але ці два джерела варіативності не розділені повністю. Для критично важливих застосунків хотілося б знати причини помилок: чи ігнорує агент правила, чи неправильно трактує наміри користувача, чи просто обирає неправильний формат виклику інструменту?

Таблиця лідерів на llm-stats.com зараз показує моделі на кшталт Step-3.5-Flash з показником 0,882, що виглядало б як вражаючий прогрес, якби не той факт, що налаштування оцінювання, ймовірно, змінилися: нові записи, схоже, оцінюються за допомогою інших версій симулятора користувача та, можливо, інших наборів завдань. Порівняння різних моделей на бенчмарках, що розвиваються, завжди викликає сумніви.

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

Агент для запису в Beancount, який я маю на увазі, за структурою ідентичний агентам, які оцінює τ-bench: він має галузеві інструменти (додати транзакцію, виправити баланс, перекатегоризувати запис), обмеження правил (не змінювати закриті періоди, не створювати від’ємні баланси, дотримуватися плану рахунків) і користувача, який дає інструкції природною мовою протягом діалогу, що може тривати багато кроків.

Висновки щодо pass^k — це найкорисніший для нас результат. Якщо сучасна модель на кшталт Claude 3.5 Sonnet досягає pass@4 лише 0,462 у ритейлі — відносно простій сфері — нам слід очікувати подібної або гіршої послідовності при записі в гросбух, де помилки накопичуються в транзакціях, а порушення правил можуть бути не відразу помітними. Проектування з розрахунком на стабільність у k випробуваннях із самого початку — а не просто оптимізація pass@1 — змінює архітектуру: це аргумент на користь консервативного використання інструментів (запитувати перед записом, а не після), кроків явної перевірки правил перед будь-яким викликом API та окремого агента-верифікатора, який перевіряє запропоновані зміни (diff) бази даних перед їх збереженням.

Методологія оцінювання стану бази даних також безпосередньо переноситься. Структурований формат файлів Beancount дозволяє легко порівнювати очікуваний стан гросбуха з фактичним станом після сесії запису, даючи нам такий самий об’єктивний сигнал оцінювання, який використовує τ-bench.

Що читати далі

• τ²-bench (arXiv:2506.07982): продовження, що охоплює середовища з подвійним контролем, де користувачі також використовують інструменти; безпосередньо актуально, якщо ми розглядаємо користувача як активного учасника виправлення гросбуха, а не пасивного замовника.
• AgentEval / GAIA (arXiv:2311.12983): бенчмарк GAIA оцінює загальних ШІ-помічників у реальних завданнях, що потребують перегляду веб-сторінок та використання інструментів; корисне доповнення до галузевого фокуса τ-bench.
• WorkArena (arXiv:2403.07718): оцінює агентів у реальних завданнях корпоративного ПЗ у ServiceNow; ця сфера ближча до бухгалтерських робочих процесів, ніж ритейл чи авіалінії, і її варто вивчити для уроків з проектування завдань.