Ocena agentów za pomocą bota podróżniczego: wynik vs trajektoria, bramy oraz pass^k

Agenci nie tylko wywołują API. Rozumują, na bieżąco wybierają narzędzia, tworzą wieloetapowe plany i zajmują się zadaniami otwartymi, które kiedyś pochłaniały godziny pracy ludzi. Jednak w momencie, gdy coś trafia do produkcji, pojawia się nieprzyjemne pytanie: skąd wiesz, że to działa?

Nie dziś, przy ulubionym promptzie demonstracyjnym, ale w przyszłym tygodniu, po tym jak ktoś zmodyfikuje instrukcje systemu, doda narzędzie, zamieni podstawowy model lub dostosuje prompt. Czy ta zmiana naprawiła jedną rzecz, a potajemnie uszkodziła trzy inne?

Zwykłe oprogramowanie ma deterministyczne testy jednostkowe, takie jak assert add(2, 2) == 4. Agenci są probabilistyczni i mogą obrać różne ścieżki do osiągnięcia tego samego celu, więc zwykłe porównanie ciągów znaków tekstu końcowego jest niewystarczające. Agent evals wypełnia tę lukę.

Analogia z egzaminem matematycznym

Wyobraź sobie nauczyciela, który ocenia egzamin, patrząc tylko na ostateczną liczbę. Wtedy dzieją się dwie rzeczy nie tak:

1. Szczęśliwy traf. Metoda jest bezsensowna, dwie błędy arytmetyczne się znoszą, a odpowiedź trafia tam przypadkowo.
2. Błąd na końcu. Metoda jest nieskazitelna, a twierdzenie dobrze zrozumiane, ale błąd drukarski na samym końcu powoduje, że zamiast 42 pojawia się 41.

Dobry nauczyciel ocenia zarówno metodę, jak i odpowiedź. Agenci zasługują na takie samo potraktowanie, ponieważ generują sekwencję kroków: wywołania narzędzi, wyszukiwania, zformatowane obiekty oraz decyzje dotyczące stanu. Sprawiedliwa ocena oznacza pomiar dwóch rzeczy:

• Wynik: rezultat biznesowy, jaki osiągnął.
• Trajektoria: ścieżka, którą obrał, aby go osiągnąć.

Mówiąc prościej, ocena agenta to ocena wyniku plus ocena trajektorii, mierzona w ramach tej samej próby przy użyciu połączenia sztywnych sprawdzeń kodowych i elastycznych ocen subiektywnych.

Dwie osie oceny

Każdego agenta można przeanalizować pod kątem dwóch niezależnych wymiarów.

Czego się sprawdza?

• Weryfikacje wyniku sprawdzają, czy istnieje właściwy ostateczny rezultat – na przykład poprawny lot, odpowiednia cena hotelu lub prawidłowy rekord rezerwacji.
• Weryfikacje trajektorii sprawdzają, czy agent dotarł tam w sposób niezawodny: narzędzia zostały wywołane we właściwej kolejności, przekazano ważne parametry i nie doszło do nieskończonego pętlenia.

Jak jest oceniany?

• Weryfikacje deterministyczne obejmują fakty, na które istnieje obiektywna odpowiedź. Cena wynosi 150 dolarów albo nie, a narzędzie zostało wywołane albo nie. Obsługują je proste stwierdzenia w kodzie.
• Kontrole oparte na ocenie obejmują wszystko, co wymaga kontekstu, intencji lub subtelności. Czy słowo „budżet” zostało zrozumiane jako „gospodarka”? Czy wybrany hotel odpowiada temu, co faktycznie miał na myśli użytkownik? Sztuczna inteligencja działająca jako neutralny oceniający ocenia te aspekty.

Przykład zastosowania: agent rezerwacji podróży

Weźmy agenta, który zajmuje się planowaniem tras. Prośba brzmi: tani lot, trzy noce w hotelu w Nowym Jorku oraz transport z lotniska. Aby to zrealizować, może używać narzędzi o nazwach search_flights, search_hotels, book_flight, book_hotel oraz book_airport_transfer.

Metryki trajektorii analizują dziennik wykonywań, kolejność wywołań, argumenty narzędzi oraz ślady rozumowania. Typowe pytania: Czy agent stworzył plan przed podjęciem działań? Czy wyszukiwania zostały przeprowadzone przed dokonaniem rezerwacji? Czy daty w hotelu odpowiadają datom lotu? Czy uniknięto zbędnych wywołań?

Metryki wyniku sprawdzają obiekty rezerwacyjne faktycznie utworzone przez agenta: cenę biletu, stawkę za noc, transport, walutę oraz daty.

Bramki przed średnimi

Lekcja, której zazwyczaj trzeba się nauczyć boleśnie: nie każda metryka powinna być uwzględniana w jednej średniej ocenie. Wyobraźmy sobie agenta, który dzięki eleganckiemu rozumowaniu i idealnej kolejności używanych narzędzi osiąga 95% oceny ogólnej, ale rezerwuje lot za 1 500 dolarów zamiast 150 dolarów. W warunkach rzeczywistych to nie jest udana realizacja – to katastrofa podatkowa.

Aby zapobiec temu, by wysokie wyniki w zakresie rozumowania ukrywały krytyczne błędy biznesowe, ocena może odbywać się w dwóch etapach.

Etap 1 – brama kontrolna. Najpierw przeprowadzane są deterministyczne sprawdzenia kluczowych pól: cen, dat, walut, identyfikatorów fakturowania oraz warunków obliczania opłat. Jeśli jakiekolwiek z tych sprawdzeń zawiedzie, cała próba kończy się niepowodzeniem. Żadne doskonałe rozumowanie nie może tego zmienić.

Etap 2 – ważona rubryka oceny. Tylko te próby, które przechodzą wszystkie bramy kontrolne, otrzymują ocenę jakości, obliczaną na podstawie pozostałych wskaźników, takich jak efektywność narzędzia, jakość rozumowania, przestrzeganie planu oraz zgodność semantyczna. Zasada jest prosta: jeśli próba przeszła bramę kontrolną, a jej ważona ocena jest na poziomie lub powyżej ustalonego progu, np. 0,85, oznacza to sukces.

Diagnozowanie błędów za pomocą macierzy 2x2

Jedynie „82% wskaźnik powodzenia” nie dostarcza żadnych przydatnych informacji przy debugowaniu. Musisz wiedzieć, dlaczego próby się nie udały, aby móc zdecydować, czy naprawić prompt, narzędzia, czy zestaw danych. Porównaj wynik z trajektorią i pojawią się cztery kwadranty:

• Dobra ścieżka, dobry wynik: cel osiągnięty.
• Zła ścieżka, dobry wynik: szczęśliwy traf, a także ryzyko, które może się pojawić.
• Dobra ścieżka, zły wynik: błąd na końcowym etapie, często spowodowany problemem z narzędziem lub danymi.
• Zła ścieżka, zły wynik: fundamentalny błąd wymagający ponownej pracy.

Łączny ślad działania

Oto jak pipeline mógłby obsłużyć jedną próbę agenta rezerwacyjnego. Zaczyna się od żądania użytkownika i śladu działania agenta, który obejmuje plan (poszukiwanie lotów, poszukiwanie hoteli, rezerwacja obu, dodanie transferu), a następnie w kolejności zapisuje każdą myśl i wywołanie narzędzia.

// Step 1: Upfront Plan Formulation
Thought: "I need to book budget travel to NYC for 3 days. Plan: 1) Search economy flights, 2) Search budget hotels in NYC, 3) Book flight, 4) Book hotel for matching dates, 5) Book airport transfer."

// Step 2: Tool Call - search_flights
→ call: search_flights({ origin: "SFO", destination: "JFK", cabin_class: "economy", date: "2026-10-10" })
← return:
[
  {
    flight_id: "fl_eco_9921",
    airline: "BudgetAir",
    price: 150.00
  }
]

// Step 3: Tool Call - search_hotels
→ call: search_hotels({ city: "New York", checkin: "2026-10-10", nights: 3, max_rate: 150 })
← return:
[
  {
    hotel_id: "ht_manhattan_pod",
    name: "Pod Midtown NYC",
    rate_per_night: 120.00
  }
]

// Step 4: Tool Call - book_flight
→ call: book_flight({ flight_id: "fl_eco_9921", passenger: "Chris Dias", price: 150.00 })
← return:
{
  booking_ref: "BK-FL-7701",
  status: "confirmed"
}

// Step 5: Tool Call - book_hotel
→ call: book_hotel({ hotel_id: "ht_manhattan_pod", nights: 3, rate_per_night: 120.00, guest: "Chris Dias" })
← return:
{
  reservation_id: "RSV-HT-8832",
  status: "confirmed"
}

// Step 6: Tool Call - book_airport_transfer
→ call: book_airport_transfer({ pickup: "JFK", dropoff: "Pod Midtown NYC", fee: 35.00 })
← return:
{
  ride_id: "TX-4402",
  status: "confirmed"
}

// Step 7: Final Synthesized Output Payload
Final Output:
{
  flight: {
    id: "fl_eco_9921",
    cabin: "economy",
    price: 150.00,
    status: "confirmed"
  },
  hotel: {
    id: "ht_manhattan_pod",
    nights: 3,
    rate_per_night: 120.00,
    status: "confirmed"
  },
  transfer: {
    service: "JFK Pickup Shuttle",
    fee: 35.00,
    status: "confirmed"
  },
  total_billed: 545.00
}

Następnie system sprawdza kluczowe dla misji pola: cenę lotu, cenę hotelu za noc oraz koszt transportu. Załóżmy, że wszystkie trzy wartości odpowiadają oczekiwanej wartości – 150 dolarów za lot, 120 dolarów za noc i 35 dolarów za transport. System przyjmuje to i przechodzi do drugiego etapu.

W drugim etapie każda z pozostałych miar otrzymuje ocenę od 0 do 1, która jest mnożona przez jej wagę, przy czym suma wag wynosi 1. Na przykład załóżmy, że pięć miar ma wagi 0,20, 0,20, 0,15, 0,15 i 0,30 oraz oceny 1,0, 1,0, 0,8, 1,0 i 0,95. Suma ważona wynosi 0,20 + 0,20 + 0,12 + 0,15 + 0,285, co daje 0,955. Ponieważ ta wartość przekracza ustalony wcześniej próg 0,85, test zostaje uznany za pomyślny.

Następnie system rejestruje trzy fakty: test przeszedł, ważona ocena przekroczyła próg, a macierz diagnostyczna umieściła wynik w obszarze „dobra ścieżka, dobry rezultat”.

Mierzenie wariancji za pomocą pass@k i pass^k

Jedno testowanie nie pokazuje pełnego obrazu, ponieważ agenci są niedeterministyczni. Jeśli uruchomimy ten sam prompt z tymi samymi narzędziami po dziesięciu minutach, model może najpierw szukać hoteli, inaczej sformatować argument lub rozumować według innej ścieżki. Test, który przeszedł dziś, może nie przejść jutro przy identycznym wejściu.

W dokumentacji inżynieryjnej Anthropic na temat oceny agentów opisano dwie statystyki służące do kontrolowania tej zmienności: pass@k i pass^k.

pass@k: zdolność

Tutaj pytanie brzmi, czy przynajmniej jedna z k oddzielnych prób się powiedzie. Wraz ze wzrostem wartości k wynik rośnie, ponieważ im więcej prób, tym większe prawdopodobieństwo sukcesu. Ta miara stała się popularna dzięki projektowi HumanEval firmy OpenAI dotyczącemu generowania kodu, w którym system tworzy kilka kandydujących programów i sprawdza, czy któryś z nich przechodzi testy jednostkowe.

Odpowiada to rozwiązaniom z udziałem człowieka oraz systemom z automatycznymi weryfikatorami: trzy wstępne plany podróży do wyboru dla menedżera podróży lub pięć kandydujących zapytań SQL, przy których silnik wybiera pierwsze poprawne.

pass^k: spójność

Jest to prawdopodobieństwo, że agent odniesie sukces za każdym razem przy k próbach, co odpowiada stopniowi p podniesionemu do potęgi k. Wraz ze wzrostem k wartość ta szybko spada. Załóżmy, że agent odnosi sukces w 75% poszczególnych prób:

• jedna próba: 75,0%,
• trzy próby z rzędu: około 42,2%,
• pięć prób z rzędu: około 23,7%,
• dziesięć prób z rzędu: około 5,6%.

To jest standard dla autonomicznego wykorzystania w krytycznych zastosowaniach produkcyjnych. Gdy agent rezerwacji jest połączony z kartami płatniczymi i API dostawców, użytkownikom nie obchodzi to, że może odnieść sukces tylko raz na pięć prób – potrzebują, aby działał niezawodnie za każdym razem.

Dlaczego wybór ma znaczenie

Gdy k wynosi 1, obie metryki są identyczne i równa się podstawowemu wskaźnikowi sukcesu. Przy k równym 10 opowiadają one przeciwne historie: pass@k zmierza ku 100%, ponieważ wystarczająca liczba prób ostatecznie doprowadzi do sukcesu, natomiast pass^k zmierza ku zera, gdyż dziesięć bezbłędnych prób bez żadnej halucynacji czy awarii narzędzia jest trudne do osiągnięcia. Wybór metryki odpowiadającej obietnicom twojego produktu pozwala odróżnić pozorne wskaźniki od rzeczywistej niezawodności.

Praktyczne wnioski

1. Nie testuj tylko ostatecznej odpowiedzi. Agent, który dochodzi do prawidłowej odpowiedzi poprzez błędne rozumowanie, stanowi ryzyko w produkcji.
2. Mieszaj kod z ocenami LLM. Używaj deterministycznego kodu do obliczania cen, identyfikatorów i sprawdzania obecności, a ocen LLM do oceny jakości rozumowania, przestrzegania planu i dopasowania intencji.
3. Zadbaj o to, by nic nie poszło nie tak. Eleganckie rozumowanie nie powinno pozwalać na zniekształcenie błędnego ceny, złej waluty lub nieprawidłowej daty w średniej.
4. Traktuj oceny jak CI. Uruchamiaj cały zestaw testów za każdym razem, gdy zmienia się prompt lub model, aby regresje ujawniły się przed tym, jak użytkownicy je zauważą.

Niezawodni agenci nie powstają dzięki nadziei, że model będzie działać poprawnie dzisiaj. Powstają dzięki systemowi, który codziennie sprawdza, czy tak faktycznie jest.