Jak oceniać agenta AI? Zadania, przebieg działania, niezawodność i koszt

Ocenianie agenta AI polega na sprawdzeniu, czy niezawodnie wykonuje reprezentatywne zadania, wybiera akceptowalne sposoby działania, respektuje wyznaczone mu granice i przynosi wartość uzasadniającą poniesiony koszt. Sama odpowiedź końcowa nie wystarczy, ponieważ agent może osiągnąć wiarygodny wynik, podejmując niebezpieczne działania, formułując nieuzasadnione twierdzenia, ponawiając próby zbyt wiele razy lub polegając na szczęściu.

Ocenianie agentów jest trudne, ponieważ system działa w czasie. Model wybiera narzędzia, obserwuje zmieniające się środowisko i w każdym uruchomieniu może obrać inną drogę. Dlatego skuteczne testy mierzą wyniki i przebieg działania w wielu powtórzonych próbach.

Podstawowe pojęcia związane z ocenianiem agentów

Przewodnik Anthropic po ocenianiu agentów bez tajemnic przedstawia przydatny zestaw pojęć:

• Zadanie: pojedynczy przypadek testowy obejmujący cel, środowisko, dane wejściowe i kryteria powodzenia.
• Próba: jedna próba wykonania zadania przez agenta.
• Transkrypcja lub przebieg działania: sekwencja wiadomości, decyzji, wywołań narzędzi, obserwacji i działań podczas próby.
• Oceniający: reguła, program, model lub osoba, które oceniają część działania.
• Środowisko ewaluacyjne: system, który przygotowuje środowiska, uruchamia próby, gromadzi ślady działania, wywołuje oceniających i przedstawia wyniki.

Rozdzielenie tych pojęć pozwala uniknąć częstego błędu: uznania jednej udanej demonstracji za dowód, że agent będzie działał niezawodnie.

Zacznij od jasnej specyfikacji zadania

Przydatny opis zadania ewaluacyjnego określa stan początkowy, dostępne narzędzia, ograniczenia, oczekiwany wynik oraz ważne zabronione zachowania. Test powinien przypominać rzeczywistą pracę, ale nie narzucać jednej z góry zaprogramowanej ścieżki.

W przypadku agenta obsługi klienta polecenie „rozwiąż zgłoszenie” jest zbyt ogólnikowe. Lepsza specyfikacja zadania wskazuje dane klienta, obowiązujące zasady, dozwolone rozwiązania, wymagany sposób komunikacji oraz zmiany, które muszą zostać odnotowane w systemie ewidencyjnym. Takie zadanie można następnie ocenić obiektywnie.

Cztery warstwy oceny agenta

Te warstwy należy odrębnie przedstawiać w raportach. Połączenie ich w jedną średnią może ukryć niedopuszczalne zachowania — na przykład wysoki odsetek pomyślnie wykonanych zadań, który maskuje częste próby nieautoryzowanego użycia narzędzi. Zespoły mogą najpierw określić bezwzględne kryteria bezpieczeństwa, a następnie porównać jakość wyników i efektywność tych uruchomień, które spełniają te kryteria.

1. Jakość wyniku

Czy agent osiągnął cel? Oceniający wynik mogą sprawdzać dokładne zmiany stanu, wymagane pola, wyniki testów, poprawność faktów, poparcie dla cytowanych źródeł lub jakość na podstawie kryteriów oceny.

W miarę możliwości należy sprawdzać stan końcowy środowiska, a nie polegać na deklaracji samego agenta. Agent programistyczny nie odniósł sukcesu tylko dlatego, że twierdzi, iż naprawił błąd — muszą to potwierdzać odpowiednie testy i działanie programu.

2. Jakość przebiegu działania

Czy agent obrał właściwą drogę? Ocena przebiegu działania może wykryć niepotrzebny dostęp do danych, użycie zabronionych narzędzi, powtarzające się niepowodzenia, pominięcie weryfikacji, zmyślone obserwacje lub naruszenie zasad zatwierdzania.

Nie każde odejście od wzorcowej ścieżki jest błędem. Agenci mogą znaleźć poprawne rozwiązania, których osoby oceniające nie przewidziały. Oceniający powinni egzekwować rzeczywiste wymagania, a jednocześnie dopuszczać alternatywne, efektywne sposoby działania.

3. Bezpieczeństwo i zgodność z zasadami

Czy agent nie przekroczył swoich uprawnień? Testy powinny uwzględniać ataki polegające na wstrzykiwaniu instrukcji, sprzeczne polecenia, dane wrażliwe, niejednoznaczne intencje użytkownika oraz prośby wymagające odmowy lub eskalacji.

Testy bezpieczeństwa wymagają realistycznych konsekwencji w środowisku odizolowanym. Samo zdanie zgodne z zasadami nie wystarczy, jeśli agent zdążył już wysłać wiadomość, zmienić wpis lub ujawnić dane.

4. Efektywność operacyjna

Ile czasu i pieniędzy wymagało osiągnięcie sukcesu? Śledź liczbę tokenów modelu, wywołań narzędzi, opóźnienie mierzone czasem rzeczywistym, ponowne próby, interwencje człowieka i koszty usług zewnętrznych. Agent, który osiąga cel po 100 niepotrzebnych działaniach, może być mniej przydatny niż prostszy proces.

Korzystaj z różnych rodzajów oceniających

Ocena deterministyczna sprawdza konkretne właściwości: czy test zakończył się pomyślnie, czy plik został prawidłowo zmieniony, czy pole w bazie danych ma wymaganą wartość lub czy wywołano zabroniony punkt końcowy. Jest szybka i spójna, ale obejmuje tylko to, co programiści uwzględnili w kodzie.

Ocena oparta na modelu pozwala oceniać takie cechy jak jasność, kompletność, trafność i zgodność ze szczegółowymi kryteriami. Można ją skalować łatwiej niż ocenę dokonywaną przez ludzi, ale wymaga własnej walidacji, ponieważ może być stronnicza lub niespójna.

Ocena dokonywana przez ludzi jest ważna w przypadku eksperckiego osądu, niejednoznacznych sytuacji i walidacji automatycznych metod oceny. Jest wolniejsza i droższa, dlatego zespoły często stosują ją do próbek, przypadków rozbieżności i obszarów o dużym wpływie.

Najlepsze zestawy ewaluacyjne łączą te podejścia. Platforma Evals OpenAI również traktuje ewaluację jako uporządkowany proces definiowania testów i metod oceny oraz przeprowadzania powtarzanych eksperymentów, a nie nieformalną kontrolę.

Rzetelna ocena wymaga wielokrotnych prób

Uruchom każde zadanie wystarczająco wiele razy, aby zaobserwować zmienność wynikającą z próbkowania, zmieniających się narzędzi i stanu środowiska. Podawaj zarówno średnią skuteczność, jak i częstotliwość poważnych błędów. W wieloetapowych przepływach pracy, w których poszczególne kroki zależą od siebie, dokładność na poziomie każdego kroku może wyglądać dobrze, podczas gdy niezawodność całego procesu pozostaje niska, ponieważ jeden błąd wystarczy, by wykoleić całe zadanie.

Zachowanie agenta ma charakter probabilistyczny. To samo zadanie może skutkować różnymi planami, wywołaniami narzędzi i wynikami. Każde ważne zadanie uruchamiaj wielokrotnie i podawaj odsetek zaliczonych prób lub rozkład wyników, a nie tylko najlepszy przykład.

Dwie miary niezawodności odpowiadają na różne pytania:

• Pass@k: prawdopodobieństwo, że powiedzie się co najmniej jedna z k prób. Ta miara jest przydatna, gdy dopuszczalne jest wielokrotne podejmowanie prób.
• Pass^k: prawdopodobieństwo, że powiedzie się każda z k prób. Odzwierciedla spójność wyników, gdy każda próba musi zakończyć się powodzeniem.

System może osiągać atrakcyjne wyniki Pass@k, a mimo to nie nadawać się do automatycznego działania, ponieważ poszczególne próby są zawodne.

Zbuduj reprezentatywny zestaw zadań

Zacznij od rzeczywistych błędów i typowych próśb pojawiających się w środowisku produkcyjnym. Uwzględnij proste zadania, trudne przypadki brzegowe, niejednoznaczne dane wejściowe, błędy narzędzi, nieaktualne dane, brakujące informacje i treści wrogie.

Podziel wyniki według rodzaju zadania i poziomu ryzyka. Średnia dla całości może ukrywać poważne słabości w działaniach finansowych, zadaniach długoterminowych lub konkretnej aplikacji. Zachowaj odłożony na bok zbiór danych, aby wielokrotne dostrajanie promptów nie przekształciło zestawu ewaluacyjnego w zbiór treningowy.

Oceniaj środowisko, a nie tylko model

Skuteczność agenta zależy od definicji narzędzi, uprawnień, pamięci, zarządzania kontekstem, interfejsu użytkownika, działania sieci i orkiestracji. Aktualizacja modelu może ograniczyć jeden rodzaj błędu, a jednocześnie ujawnić inny.

Wersjonuj cały stos używany przy każdym uruchomieniu. Zapisuj wersje modelu, promptów, narzędzi, zrzutu danych, środowiska, budżetów i metod oceny. W przeciwnym razie nie da się ustalić, jaka istotna przyczyna doprowadziła do zmiany wyniku.

Częste błędy w ewaluacji

Kolejnym zagrożeniem jest wyciek danych. Jeśli zadania testowe, oczekiwane odpowiedzi lub wzorce oceniania pojawiają się w danych treningowych modelu albo w kontekście promptu, wynik może odzwierciedlać rozpoznawanie zamiast uogólniania. Należy zachować prywatne zadania testowe, odświeżać przypadki w miarę zmian systemów oraz zapisywać dokładny model, prompt, wersje narzędzi i środowisko użyte w każdym przebiegu.

• Ewaluacja oparta na demonstracjach: wybieranie zadań po zaobserwowaniu, w czym agent radzi sobie dobrze.
• Ocenianie wyłącznie odpowiedzi końcowej: pomijanie niebezpiecznych lub nieefektywnych przebiegów.
• Wnioski wyciągane na podstawie pojedynczego przebiegu: traktowanie szczęśliwego trafu jako stabilnej zdolności.
• Nieszczelne testy: umieszczanie odpowiedzi lub referencyjnego przebiegu w kontekście agenta.
• Niezweryfikowani oceniający oparte na modelach: zakładanie, że automatyczny sędzia ma rację, bez sprawdzania zgodności jego ocen z opiniami ekspertów.
• Statyczne środowiska: testowanie tylko jednego interfejsu, stanu konta lub układu danych.
• Brak testów negatywnych: mierzenie skuteczności wykonywania zadań bez sprawdzania, czy agent odpowiednio odmawia lub eskaluje sprawę.
• Pomijanie aspektów ekonomicznych: optymalizowanie skuteczności kosztem nieakceptowalnych kosztów i opóźnień.

Od ewaluacji offline do monitorowania produkcyjnego

Ewaluacje offline są kontrolowane i powtarzalne. Doskonale nadają się do porównywania promptów, modeli, narzędzi i zasad przed wdrożeniem. Monitorowanie produkcyjne ujawnia szeroki wachlarz rzeczywistych zachowań użytkowników i zmian w środowisku.

Dojrzały program łączy oba podejścia. Incydenty i ślady produkcyjne o niskim poziomie pewności stają się nowymi zadaniami offline. Proponowane zmiany muszą przejść zestaw testów regresyjnych. Po wdrożeniu zespoły monitorują skuteczność wykonywania zadań, częstość interwencji, zdarzenia związane z zasadami, błędy narzędzi, koszty, opóźnienia i opinie użytkowników.

Praktyczna karta wyników agenta

Karta wyników powinna rozróżniać bezwzględne kryteria akceptacji od wskaźników optymalizacyjnych. Zgodność z zasadami, uprawnienia i wymagane dowody mogą stanowić kryteria zaliczenia lub niezaliczenia; dokładność, opóźnienia, koszty i nakład pracy recenzentów można następnie porównywać wśród zaakceptowanych przebiegów. Dzięki temu zespoły nie poświęcą bezpieczeństwa na rzecz niewielkiego wzrostu wydajności, którego pogorszenie uśredniony wynik mógłby nie ujawnić.

Przydatna karta wyników może uwzględniać:

• odsetek pomyślnie wykonanych zadań i ocenę jakości;
• spójność wyników w kolejnych próbach;
• częstość krytycznych naruszeń zasad;
• trafność wyboru narzędzi i poprawność argumentów;
• częstość odzyskiwania sprawności po awariach narzędzi lub środowiska;
• częstość eskalacji do człowieka i ręcznego zastępowania decyzji agenta;
• medianę i wartości skrajne opóźnienia;
• koszt modelu, narzędzi i pracy człowieka w przeliczeniu na pomyślnie wykonane zadanie;
• efektywność przebiegu w porównaniu z rozsądnym punktem odniesienia.

Należy podawać koszt pomyślnego wykonania zadania, a nie tylko koszt jednego przebiegu. Tani agent, który wielokrotnie ponosi porażkę, może okazać się droższy niż lepszy model, który odnosi sukces za pierwszym razem.

Co warto zapamiętać o ocenie agenta AI

Ewaluacja agenta polega na testowaniu kompletnego systemu ukierunkowanego na realizację celu w realistycznych warunkach. Pozwala ocenić, czy praca została wykonana poprawnie, czy obrana droga jest akceptowalna, czy zachowanie można powtórzyć i czy jego koszty są uzasadnione.

Zacznij od niewielkiego zestawu istotnych zadań, wielu prób, wielowarstwowego oceniania i kompletnych przebiegów. Następnie zamieniaj każdą znaczącą porażkę w środowisku produkcyjnym w test regresyjny. Możliwości agentów szybko się zmieniają; trwały system ewaluacji pozwala zespołom odróżniać rzeczywisty postęp od przekonującej demonstracji.