Tau-Bench: Testowanie agentów AI tam, gdzie to naprawdę ma znaczenie - obsługa klienta

Większość benchmarków agentów AI daje modelowi zadanie i pozwala mu pracować w izolacji. Żadnych kłopotliwych ludzi. Żadnych niejednoznacznych polityk. Żadnego dialogu. To wygodne do ewaluacji, ale nie odzwierciedla tego, jak agenci są faktycznie wdrażani.

Tau-bench (Tool-Agent-User Interaction Benchmark) od Sierra robi coś innego: wrzuca agenta w realistyczny scenariusz obsługi klienta, gdzie musi rozmawiać z symulowanym użytkownikiem, przestrzegać złożonych polityk domeny i wykonywać prawidłowe wywołania API do prawdziwej bazy danych - wszystko jednocześnie. A potem Tau-squared-bench idzie dalej, dając użytkownikowi jego własne narzędzia i sprawczość, tworząc środowisko podwójnej kontroli, w którym obie strony mogą działać na świat.

TL;DR

Tau-bench symuluje prawdziwe interakcje obsługi klienta, gdzie LLM gra użytkownika, a agent musi zbierać informacje, przestrzegać polityk i wykonywać operacje na bazie danych przez wieloturową konwersację.
Ewaluacja sprawdza ugruntowane wyniki, nie subiektywną jakość konwersacji. W oryginalnym benchmarku oznacza to końcowy stan bazy danych plus wymagane informacje dla użytkownika; w domenie telekomunikacyjnej Tau-squared używa funkcji asercji specyficznych dla zadania nad końcowym stanem świata.
Metryka pass^k mierzy spójność, nie tylko jednorazowy sukces. Pyta: jeśli uruchomisz to samo zadanie k razy, czy uda ci się za każdym razem? Na przykład GPT-4o spada z ~61% (pass^1) do poniżej 25% (pass^8) na zadaniach detalicznych.

Dlaczego Tau-Bench ma znaczenie

Oto scenariusz: budujesz agenta AI do obsługi wsparcia klienta dla linii lotniczej lub sklepu internetowego. Twój agent musi wyszukiwać rezerwacje, sprawdzać polityki dotyczące anulacji i limitów bagażowych, może przerezerwować lot - wszystko to rozmawiając z użytkownikiem, który może być niejasny, zmienić zdanie w trakcie rozmowy lub poprosić o coś, czego polityka nie dopuszcza.

To podstawowy przypadek użycia agentów AI w produkcji. I właśnie tu większość benchmarków zawodzi. Testują wywoływanie narzędzi w izolacji (czy model potrafi wygenerować prawidłowe wywołanie funkcji?) lub ewaluują na statycznych zbiorach danych, gdzie wszystkie informacje są podane z góry.

Tau-bench wypełnia tę lukę, testując jednocześnie trzy zdolności:

Wieloturowa konwersacja z człowiekiem. Użytkownik nie podaje wszystkiego w jednej wiadomości. Ujawnia informacje stopniowo, czasem wymaga dopytania i może stawiać złożone prośby.
Zgodność z politykami specyficznymi dla domeny. Agent otrzymuje szczegółowy dokument polityki (np. “lotów w klasie basic economy nie można modyfikować” lub “wymiany można dokonać tylko na dostarczonych zamówieniach”) i musi ściśle go przestrzegać, nawet gdy prośba użytkownika jest sprzeczna z zasadami.
Prawidłowe użycie narzędzi z prawdziwą bazą danych. Agent wchodzi w interakcję z bazami danych JSON przez narzędzia API w Pythonie - wyszukuje użytkowników, odpytuje loty, modyfikuje zamówienia. Błędne argumenty, brakujące pola czy nieprawidłowe sekwencje prowadzą do porażki.

LLM jako użytkownik

Użytkownik w Tau-bench jest grany przez model językowy. Każde zadanie zawiera ukrytą instrukcję, która mówi symulowanemu użytkownikowi kim jest, czego chce i jak ma się zachowywać:

“Jesteś Mei Davis z kodu pocztowego 80217. Chcesz zwrócić butelkę na wodę i wymienić legowisko dla zwierzaka oraz krzesło biurowe na najtańszą wersję. Wspomnij o tych dwóch rzeczach razem. Jeśli możesz zrobić tylko jedną z dwóch, wolisz zrobić to, co zaoszczędzi ci najwięcej pieniędzy, ale chcesz znać oszczędności w obu wariantach. Masz długi i jesteś smutna, ale bardzo zwięzła.”

Agent nigdy nie widzi tej instrukcji. Widzi tylko wiadomości użytkownika, które wynikają naturalnie z interpretacji scenariusza przez LLM. To tworzy stochastyczną zmienność - to samo zadanie przebiega inaczej za każdym razem, ponieważ użytkownik formułuje rzeczy inaczej, ujawnia informacje w innej kolejności lub reaguje nieprzewidywalnie na pytania agenta.

Ta stochastyczność to cecha, nie wada. To właśnie ona umożliwia metrykę pass^k (więcej o tym poniżej) i odzwierciedla rzeczywiste interakcje z klientami, gdzie ta sama podstawowa prośba może pojawić się na niezliczone sposoby.

Jak działa ewaluacja: sprawdzanie ugruntowanych wyników

To tutaj Tau-bench staje się elegancki. Zamiast próbować oceniać jakość konwersacji za pomocą swobodnego sędziego LLM, punktuje ugruntowane wyniki na podstawie wcześniej zdefiniowanych kryteriów sukcesu.

W oryginalnych domenach detalicznej i lotniczej każde zadanie jest zaprojektowane wokół jednego prawidłowego stanu końcowego zgodnie z polityką domeny. Jeśli zadanie dopuszczałoby wiele prawidłowych wyników, autorzy doprecyzowują instrukcje, aż pozostaje tylko jeden zdefiniowany stan docelowy.

Funkcja nagrody jest binarna: r = r_action x r_output, gdzie:

r_action = 1 jeśli stan końcowy spełnia ugruntowane kryteria akcji zadania. W oryginalnym Tau-bench oznacza to przede wszystkim dopasowanie stanu bazy danych do zdefiniowanego stanu docelowego.
r_output = 1 jeśli odpowiedzi agenta dla użytkownika zawierały wszystkie wymagane informacje (na przykład prawidłową kwotę zwrotu lub inne wymagane szczegóły)

Oba warunki muszą być spełnione. Agent, który dokonuje prawidłowych zmian w bazie danych, ale podaje użytkownikowi błędne informacje o cenie, nadal nie zalicza. Agent, który komunikuje się doskonale, ale wywołuje złe API, również nie zalicza.

Tau-squared rozszerza to jeszcze bardziej. Jego menu ewaluacji obejmuje sprawdzanie bazy danych, sprawdzanie informacji komunikacyjnych, asercje w języku naturalnym, dopasowywanie akcji i asercje stanu; w domenie telekomunikacyjnej artykuł mówi, że zadania są ewaluowane za pomocą funkcji asercji zamiast prostych porównań bazy danych.

Metryka Pass^k: mierzenie niezawodności

Tutaj Tau-bench ujawnia coś niewygodnego na temat obecnych agentów AI.

Standardową metryką w benchmarkach agentów jest pass@k: czy agent odniósł sukces przynajmniej raz w k próbach? To mierzy odkrycie - przy wystarczającej liczbie prób, czy agent potrafi znaleźć rozwiązanie? Jest to przydatne do generowania kodu, gdzie można uruchamiać zestawy testów, aby wybrać prawidłową odpowiedź.

Tau-bench wprowadza pass^k (pass-hat-k): czy agent odniósł sukces we wszystkich k próbach? To mierzy niezawodność - czy możesz polegać na tym agencie, że obsłuży ten sam typ żądania konsekwentnie?

W obsłudze klienta to niezawodność ma znaczenie. Nie możesz uruchomić każdej interakcji z klientem osiem razy i wybrać najlepszej. Każda rozmowa musi się udać.

Wyniki są otrzeźwiające. GPT-4o, najlepszy model w oryginalnym artykule, osiąga:

61,2% pass^1 na zadaniach detalicznych (mniej więcej 6 na 10 zadań rozwiązanych)
~25% pass^8 na zadaniach detalicznych (tylko 1 na 4 zadania rozwiązane konsekwentnie w 8 próbach)
35,2% pass^1 na zadaniach lotniczych (zaledwie jedna trzecia)

Różnica między pass^1 a pass^8 ujawnia kruchość. Agent nie tylko czasami zawodzi na trudnych zadaniach - niespójnie zawodzi na zadaniach, które czasami potrafi rozwiązać. Małe wariacje w sposobie formułowania przez użytkownika lub w samym samplingowi LLM przesądzają o wyniku.

Gdzie agenci zawodzą

Autorzy przeanalizowali 36 nieudanych trajektorii GPT-4o na zadaniach detalicznych i znaleźli trzy główne kategorie porażek:

Błędne argumenty lub informacje. Agent wywołuje prawidłowe API, ale z błędnymi parametrami - złe ID produktów, złe metody płatności, nieprawidłowe kalkulacje cen. Albo podaje użytkownikowi złą cenę końcową, co powoduje, że użytkownik podejmuje decyzje na podstawie błędnych informacji, co kaskadowo prowadzi do nieprawidłowego stanu bazy danych.

Błędne podejmowanie decyzji. Agent źle interpretuje lub ignoruje politykę domeny. Na przykład polityka mówi “wszystkie przedmioty do wymiany muszą być zebrane w listę i wymienione jednym wywołaniem API”, ale agent wymienia przedmioty jeden po drugim, powodując niepowodzenie drugiej wymiany, ponieważ wymiana może być wywołana tylko raz na zamówienie.

Częściowe rozwiązanie złożonych próśb. Gdy użytkownik prosi o wiele rzeczy (zmień adresy na wszystkich zamówieniach, zwróć jeden przedmiot i wymień inny), agent obsługuje część prośby i się zatrzymuje. Traci orientację w pełnym zakresie zadania w trakcie wieloturowej konwersacji.

Tau-Squared: kontynuacja, która dodaje sprawczość użytkownika

Rok po oryginale Tau-squared-bench zajął się fundamentalnym ograniczeniem Tau-bench: w oryginalnej konfiguracji tylko agent może używać narzędzi. Użytkownik tylko rozmawia.

W prawdziwej obsłudze klienta często tak nie jest. Pomyśl o wsparciu technicznym: agent mówi “proszę zrestartować telefon”, a klient faktycznie musi to zrobić. Użytkownik ma sprawczość nad własnym środowiskiem, a agent musi go prowadzić przez akcje, weryfikować wyniki i dostosowywać się, gdy coś nie działa zgodnie z oczekiwaniami.

Tau-squared modeluje to jako Zdecentralizowany Częściowo Obserwowalny Markowski Proces Decyzyjny (Dec-POMDP) - framework, w którym dwóch graczy (agent i użytkownik) ma własne przestrzenie akcji, przestrzenie obserwacji i narzędzia, działając na współdzielonym stanie świata, którego żaden nie obserwuje w pełni.

Nowa domena telekomunikacyjna

Głównym dodatkiem jest domena obsługi klienta telekomunikacyjnego, gdzie użytkownicy dzwonią z problemami z telefonem - brak zasięgu, niedziałające dane mobilne, awarie MMS. Kluczowa różnica: użytkownik ma własne narzędzia, które wchodzą w interakcję z jego telefonem.

Agent ma narzędzia CRM takie jak get_customer_by_id, get_details_by_id i enable_roaming. Użytkownik ma narzędzia po stronie telefonu takie jak get_network_status, toggle_data, toggle_airplane_mode i reseat_sim_card. Agent może sprawdzić konto klienta i dokonać zmian na backendzie, ale nie może bezpośrednio widzieć ani kontrolować telefonu użytkownika. Musi instruować użytkownika, aby sprawdził stan telefonu, przełączył ustawienia lub wyjął i włożył kartę SIM - a następnie interpretować zgłoszone obserwacje, aby zdiagnozować problem.

To tworzy autentyczne wspólne rozwiązywanie problemów. Typowa trajektoria wygląda tak:

Użytkownik: “Moje dane mobilne nie działają.”
Agent: “Czy mógłby Pan sprawdzić stan sieci?”
Użytkownik wywołuje get_network_status() -> widzi, że dane mobilne są wyłączone
Użytkownik: “Wygląda na to, że moje dane są wyłączone.”
Agent: “Czy mógłby Pan włączyć dane, przełączając je?”
Użytkownik wywołuje toggle_data() -> “Dane mobilne są teraz WŁĄCZONE.”
Użytkownik: “Gotowe, dane mobilne są teraz włączone.”

Domena telekomunikacyjna ma 5 planów, 9 linii, 4 klientów, z 15 narzędziami zapisu i 15 narzędziami odczytu dla użytkownika, plus 6 narzędziami zapisu i 7 narzędziami odczytu dla agenta. 114 wyselekcjonowanych zadań jest pobieranych z dużo większej puli 2285 programowo generowanych kombinacji.

Generator zadań kompozycyjnych

Jedną z największych ulepszeń w Tau-squared jest sposób tworzenia zadań. Zamiast ręcznego tworzenia każdego scenariusza, benchmark używa generatora zadań kompozycyjnych, który buduje różnorodne zadania z atomowych bloków budulcowych.

Każde atomowe podzadanie jest definiowane przez trzy typy funkcji:

Funkcje inicjalizacji ustawiają problem (np. set_airplane_mode(True))
Funkcje rozwiązania określają narzędzia potrzebne do naprawy (np. toggle_airplane_mode())
Funkcje asercji weryfikują, czy naprawa zadziałała (np. assert_service_status("connected"))

Atomowe podzadania są grupowane tak, aby wzajemnie wykluczające się alternatywy znajdowały się w tej samej grupie. Zadania złożone tworzy się wybierając podzadania z różnych grup i łącząc je. Poprawność zadania jest automatycznie weryfikowana: jeśli wszystkie funkcje asercji przechodzą po zastosowaniu funkcji rozwiązania (ale nie przed), zadanie jest prawidłowe.

To podejście zapewnia udowodnioną poprawność, pełne pokrycie domeny, jawną kontrolę nad trudnością (poprzez zmianę liczby podzadań) i eliminuje ręczny wysiłek oraz potencjalną kruchość ręcznie tworzonych zestawów zadań.

Persony użytkowników dodają realizmu

Tau-squared wprowadza persony użytkowników o różnym poziomie wiedzy technicznej:

Łatwa persona: 41-letni administrator biurowy, swobodnie korzystający z podstawowych funkcji telefonu, preferujący jasne instrukcje krok po kroku
Trudna persona: 64-letni emerytowany bibliotekarz, ograniczona wiedza techniczna, łatwo się denerwuje, martwi się o utratę zdjęć przy prośbie o restart

Trudna persona wypada zauważalnie gorzej we wszystkich modelach - nie dlatego, że zadanie podstawowe jest inne, ale dlatego, że agent musi dostosować styl komunikacji i radzić sobie z niespokojnymi, zdezorientowanymi użytkownikami, którzy przerywają zmartwionymi pytaniami. Co ciekawe, persona “None” (brak informacji o personie) wypada na poziomie lub gorzej niż trudna persona, co podkreśla, jak ważne jest testowanie z dobrze zdefiniowanymi profilami użytkowników.

Co to oznacza dla rozwoju agentów AI

Zgodność z polityką to osobna umiejętność od użycia narzędzi. Ablacja w oryginalnym artykule usunęła dokument polityki z systemu prompt agenta. Na zadaniach detalicznych (prostsze polityki) GPT-4o spadło tylko o 4,4%. Na zadaniach lotniczych (złożone polityki) spadło o 22,4%. Agent i tak w większości używał zdrowego rozsądku dla prostych zasad - dokument polityki pomagał tylko przy złożonych, specyficznych dla domeny ograniczeniach. Oznacza to, że agenci muszą być specjalnie ewaluowani pod kątem przestrzegania polityk, nie tylko wywoływania narzędzi.

Spójność ma większe znaczenie niż szczytowa wydajność. Metryka pass^k powinna niepokoić każdego, kto wdraża agentów. Agent, który odnosi sukces w 60% przypadków, ale nie można na nim polegać przy tym samym zadaniu dwa razy, jest obciążeniem w produkcji. Różnica między pass^1 a pass^8 to miejsce, gdzie rozpada się zaufanie w świecie rzeczywistym.

Prowadzenie użytkowników to fundamentalnie co innego niż samodzielne działanie. Wyniki Tau-squared dowodzą, że komunikacja i koordynacja z aktywnymi użytkownikami to odrębne wąskie gardło - nie tylko podatek na wydajność rozumowania. Agenci, którzy potrafią rozwiązywać problemy autonomicznie, mogą nadal zawodzić, gdy muszą instruować człowieka przez te same kroki.

Symulacja użytkownika staje się pierwszoplanowym problemem badawczym. Oba artykuły zmagają się z niezawodnością symulatorów użytkowników opartych na LLM. Podejście Tau-squared polegające na ograniczaniu zachowania użytkownika przez narzędzia to obiecujący kierunek, ale 16% wskaźnik błędów w najlepszej domenie nadal oznacza, że mniej więcej 1 na 6 konwersacji jest skażona artefaktami symulatora.

Szerszy obraz

Tau-bench i Tau-squared reprezentują zmianę w sposobie myślenia o ewaluacji agentów. Zamiast testowania izolowanych zdolności (czy potrafisz wywołać funkcję? czy potrafisz przeglądać sieć?), testują pełną pętlę: konwersację, rozumowanie, zgodność z politykami, użycie narzędzi, a teraz koordynację - wszystko naraz, wszystko w realistycznym otoczeniu.

Benchmarki są open source (Tau-bench na GitHubie, Tau-squared na GitHubie) i stosunkowo tanie w uruchomieniu (~40$ za pełną próbę na wszystkich domenach). Jeśli budujesz agentów AI obsługujących klientów, to jedne z najbliższych przybliżeń rzeczywistej wydajności, jakie dziś istnieją.