τ-bench: Измерване на надеждността на AI агентите в реални домейни с използване на инструменти

След седмици проследяване на генеалогията на табличното разсъждение и text-to-SQL, реших да погледна отвисоко и да задам различен въпрос: колко добре се справят съвременните агенти, след като бъдат поставени в реален оперативен цикъл с истински потребител? τ-bench дава най-честния отговор, който съм виждал, и цифрите са стряскащи.

Статията

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

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

Ключови идеи

• pass^k като честна метрика: единичен pass@1 резултат е твърде променлив. pass^k разкрива вероятността агентът да успее при всеки един от k повторни пускания на една и съща задача — индикатор за това дали бихте му се доверили в реална експлоатация.
• Спадът в последователността (The consistency cliff): 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: вариантът на агент с извикване на функции (function-calling) на GPT-4o (pass@1 = 0,420 в авиолиниите) превъзхожда както Act (0,365), така и ReAct (0,325) върху същата основа, което предполага, че структурираните API за инструменти намаляват грешките, причинени от формата.
• Симулацията на потребителя е променлива величина: авторите използват езиков модел за симулиране на потребителя, което внася собствена вариативност. По-слаб симулатор на потребител може да намали или повиши резултатите на агента в зависимост от това колко точно представя състезателно поведение на потребителя.
• Оценяването на състоянието на базата данни заобикаля игрите с частично признание: сравняването на крайното състояние, а не на стъпките в диалога, означава, че агент, който предприеме правилно действие и след това неволно го отмени, не получава точки — което е правилното решение за система със запис (write-back).

Какво издържа проверката на времето — и какво не

Рамката pass^k е наистина полезна и очаквам тя да надживее този конкретен бенчмарк. Решението за оценка въз основа на състоянието на базата данни, а не на сходство на ниво токени, е правилно — то директно измерва дали агентът е изпълнил задачата, а не дали е казал правилните неща.

Домейните обаче са тесни по замисъл. Търговията на дребно и авиокомпаниите са процедурно чисти: документите за политики са крайни и написани за бенчмарка, API-тата са малки и добре дефинирани, а симулаторът на потребител е кооперативен по подразбиране. Политиките в реалния свят са двусмислени; реалните потребители лъжат, забравят и се съпротивляват на откази. Авторите на бенчмарка признават това — самото съществуване на τ²-bench (arXiv:2506.07982) като продължение, което се разширява до модел Dec-POMDP с двоен контрол, където потребителят също манипулира състоянието на средата, е признание, че оценката с единствен контрол подценява трудността.

Съществува и въпросът какво всъщност измерва pass^k. Ако самата потребителска симулация е стохастична, вариативността в k опита смесва непоследователността на агента с непоследователността на симулатора. Статията отбелязва това, но не разделя напълно двата източника на вариативност. За критични за безопасността приложения бихте искали да припишете неуспехите — дали агентът игнорира политиката, разчита погрешно намерението на потребителя или просто избира грешен формат за извикване на инструмент?

Класацията на llm-stats.com сега показва модели като Step-3.5-Flash с 0,882, което би изглеждало като драматичен напредък, ако не забележите, че настройката за оценка вероятно се е променила: новите записи изглежда са оценени при различни версии на потребителския симулатор и вероятно различни разпределения на задачите. Сравнението между записи в развиващи се бенчмаркове винаги е подозрително.

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

Агентът за запис (write-back) в Beancount, който имам предвид, е структурно идентичен с агентите, които τ-bench оценява: той има специфични за домейна инструменти (добавяне на трансакция, коригиране на баланс, прекатегоризиране на запис), ограничения на политиките (не променяй затворени периоди, не създавай отрицателни баланси, следвай сметкоплана) и потребител, който дава инструкции на естествен език в разговор, който може да обхване много ходове.

Констатацията за pass^k е най-приложимият резултат за нас. Ако най-съвременен модел като Claude 3.5 Sonnet постига pass@4 от само 0,462 в търговията на дребно — сравнително прощаващ домейн — трябва да очакваме подобна или по-лоша последователност при запис в главната книга, където грешките се натрупват между трансакциите и нарушенията на политиката може да не са видими веднага. Проектирането за последователност при k-опита от самото начало — а не само оптимизирането на pass@1 — променя архитектурата: това е аргумент за консервативно използване на инструменти (питане преди запис, а не след), изрични стъпки за проверка на политиките преди всяко извикване на API и отделен агент за проверка (verifier), който одитира предложените разлики (diff) в базата данни, преди те да бъдат приложени.

Методологията за оценка на състоянието на базата данни също е директно преносима. Структурираният файлов формат на Beancount прави лесно сравняването на очакваното състояние на главната книга с реалното състояние след сесия на запис, което ни дава същия вид обективен сигнал за оценка, какъвто използва τ-bench.

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

• τ²-bench (arXiv:2506.07982): продължението, което се разширява до среди с двоен контрол, където потребителите също използват инструменти; пряко релевантно, ако моделираме потребителя като активен участник в корекциите на главната книга, а не като пасивен заявител.
• AgentEval / GAIA (arXiv:2311.12983): бенчмаркът GAIA оценява общи AI асистенти за задачи от реалния свят, изискващи сърфиране в мрежата и използване на инструменти; полезно допълнение към специфичния за домейна фокус на τ-bench.
• WorkArena (arXiv:2403.07718): оценява агенти при реални корпоративни софтуерни задачи в ServiceNow; домейнът е по-близо до счетоводните работни процеси, отколкото търговията на дребно или авиокомпаниите, и си струва да се прочете за уроци по проектиране на задачи.