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

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

Документът

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

Авторите моделират това като Децентрализиран частично наблюдаем марковски процес на вземане на решения (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 ясно разделя какво наблюдава всеки играч и кои инструменти може да извиква всеки от тях. Това е по-строго от ad-hoc подхода „потребител с телефон“, който може да прикрепите към съществуваща система с един агент.
• Композиционен генератор на задачи: Задачите се сглобяват от 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%. Всички модели постигат значително по-ниски резултати тук, отколкото в търговията на дребно или авиолиниите.
• Наказание за двоен контрол: Сравнение (ablation) съпоставя режима по подразбиране (потребителят има инструменти) с режима без потребител (агентът контролира всеки инструмент сам). 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 задачи са достатъчни, за да се избегнат случайни успехи, надуващи резултатите. Авторите признават, че техният набор от задачи е подизвадка. Също така намирам анализа на потребителските персонажи за повърхностен: статията показва, че „Трудният“ персонаж (64-годишен пенсионер с ниска технологична увереност) е по-труден от „Лесния“ персонаж, което не е изненадващо. Това, което бих искал да видя, е дали типът на провала в координацията се различава — дали по-трудният персонаж води до повече грешки в разсъжденията или до повече комуникационни грешки?

Статията също така не изследва какво се случва, когато документът с политики на агента е грешен или непълен, което е реалистичен сценарий за производствени внедрявания. Всеки резултат предполага, че на агента са дадени точни политики.

Защо това е важно за финансовия AI

Предположението за единичен контрол, заложено в τ-bench, WorkArena и повечето диалогови бенчмаркове, насочени към задачи, не съответства добре на действителния сценарий за поддръжка на Beancount. Потребител, който моли Beancount агент да коригира неговата главна книга, не просто описва проблем — той може едновременно с това да редактира файла в своя текстов редактор, да изпълнява bean-check или да качва нов CSV експорт от своята банка. Това е среда с двоен контрол точно в смисъла на τ²-bench.

Спадът от 18–25 процентни пункта при преминаване от режим „Без потребител“ към режим „По подразбиране“ е числото, към което ще се връщам често. То подсказва, че дори и да изградим Beancount агент, който е почти перфектен в автономната работа с главната книга, въвеждането на активен потребител, който споделя достъп за запис, би намалило процента на успеваемост с около една четвърт. Проектите за сигурен обратен запис (safe write-back), които обмисляхме (GuardAgent, ShieldAgent, проверим MCP), бяха проектирани за среди с единичен контрол; те се нуждаят от преосмисляне, ако потребителят също е агент, извикващ инструменти в същата среда.

Подобрението на надеждността на потребителския симулатор също е пряко приложимо. Ако искам да извършвам офлайн оценки на Beancount агент без набиране на счетоводители хора, тясното обвързване на симулирания потребител с детерминирана среда на главната книга — вместо разчитането на ролева игра с LLM в свободна форма — е правилното инженерно решение.

Какво да прочетете след това

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