Przestań przeprowadzać nowe benchmarki modeli i zacznij obserwować, jak Twój agent próbuje anulować subskrypcję. Luka między tymi dwiema aktywnościami to miejsce, w którym giną systemy produkcyjne. Test jednoturnowy może Ci powiedzieć, czy odpowiedź brzmi miło. Nie powie Ci jednak, czy agent właśnie zwrócił pieniądze niewłaściwemu klientowi, zapętlił się czternaście razy przy API kalendarza lub zdecydował się całkowicie pominąć weryfikację oszustw. Tekst jest najmniej niebezpieczną rzeczą, jaką generuje agent. Prawdziwe ryzyka kryją się w narzędziach, których dotyka, danych, które modyfikuje, oraz w momentach, w których powinien poprosić o pomoc, a zamiast tego kontynuował działanie.
Dlaczego benchmarki tekstowe zawodzą w środowisku produkcyjnym
Wysokie wyniki w standardowych benchmarkach stały się zwodniczą formą pocieszenia. Agent, który pisze elegancką prozę, wciąż może stanowić zagrożenie operacyjne. Kiedy Twój system rezerwuje wizyty, edytuje rekordy w bazie danych lub zakłada zgłoszenia wsparcia, wygenerowany tekst jest jedynie widoczną powierzchnią całego procesu. Pod spodem agent podejmuje konkretne decyzje: do którego endpointu uderzyć, jaki payload wysłać i kiedy przestać. Może zajmować pierwsze miejsca w rankingach rozumienia tekstu, jednocześnie generując koszty poprzez podwójną rezerwację zasobów, modyfikację niewłaściwego wiersza lub wyciek wrażliwych danych stanu do pliku logów. Musisz weryfikować mechanikę pracy, a nie tylko dopracowanie wyniku. Jeśli agent może uzyskać wysoki wynik w offline'owym teście QA, a mimo to zawiedzie Twój proces pracy poprzez zapętlenie się lub niewłaściwe użycie narzędzia, oznacza to, że Twoja ewaluacja opiera się na niewłaściwych sygnałach.
Mapowanie pięciu zależności
Zespół Van Data Team zaczyna każdą ewaluację od zmapowania pięciu konkretnych punktów kontrolnych. To całkowicie zmienia postać rzeczy. Przestajesz pytać, czy jeden model jest mądrzejszy od drugiego. Zaczynasz pytać, czy agent jest w stanie faktycznie ukończyć zadanie produkcyjne przy Twoich rzeczywistych ograniczeniach.
Wyniki biznesowe. Zdefiniuj, co oznacza „ukończone” w kategoriach dolarów i wpływu na klienta. Zadanie nie jest ukończone tylko dlatego, że agent wygenerował podsumowanie. Jest ukończone, gdy rekord magazynowy jest dokładny, wizyta została potwierdzona, a klient otrzymał poprawny numer śledzenia.
Stan zmienny. Dokładnie wiedz, co agent może zmieniać. Które tabele, jakie statusy, jakie flagi konta? Jeśli agent może dokonywać zwrotów, zmieniać terminy zadań lub aktualizować adresy rozliczeniowe, musisz sporządzić inwentarz każdego pola, którego dotyka.
Uprawnienia narzędzi. Bądź precyzyjny w kwestii tego, które endpointy API i funkcje są w zakresie. Agent posiadający dostęp do narzędzia wyszukiwania, narzędzia zapisu i narzędzia powiadomień pomyli je, jeśli granice będą niejasne. Przypisz każde uprawnienie do konkretnej potrzeby operacyjnej.
Odzyskiwanie po błędach. Zdecyduj, co się stanie, gdy API kalendarza przekroczy limit czasu, zwróci błąd 500 lub poda błędny format JSON. Agent nie powinien wpadać w panikę, halucynować komunikat o sukcesie ani próbować w nieskończoność. Potrzebuje jasnej ścieżki awaryjnej (fallback).
Bramki weryfikacji ludzkiej. Zidentyfikuj momenty, w których człowiek musi zatwierdzić działanie, zanim agent przejdzie dalej. Nie jest to oznaka słabości automatyzacji. To zawór bezpieczeństwa dla zmian o dużym znaczeniu oraz źródło etykiet typu ground-truth dla Twoich rubryk.
Jak wygląda prawdziwy plan ewaluacji
Gdy zależności zostaną już zmapowane, potrzebujesz planu ewaluacji, który odpowiada chaosowi panującemu na produkcji. Metryki z prezentacji typu slide-deck nie pomogą Ci w tym przypadku.
Twórz zestawy testowe na podstawie rzeczywistych awarii produkcyjnych, a nie z syntetycznych banków pytań. Jeśli Twój agent zawiódł w zeszły wtorek, myląc dwa podobne numery SKU, to dokładnie to zamieszanie powinno stać się stałym przypadkiem testowym. Twój zestaw ewaluacyjny powinien rosnąć za każdym razem, gdy incydent nauczy Cię czegoś nowego.
Twórz rubryki, które definiują pomyślne zakończenie w kategoriach operacyjnych. Niejasne kryteria, takie jak „pomocny” czy „dokładny”, są bezużyteczne. Przydatna rubryka określa, że zadanie zwrotu jest udane tylko wtedy, gdy odwołano się do oryginalnego ID płatności, kwota zgadzała się z żądaniem, e-mail potwierdzający został kolejkowany, a ID transakcji zostało zapisane w logach.
Definiuj specyfikacje trace dla wywołań narzędzi i ponowień. Potrzebujesz obserwowalności (observability) tego, co agent zaplanował, co faktycznie wywołał, ile razy ponawiał próbę i czy strategia ponowień była odpowiednia. Trace bez szczegółowości na poziomie narzędzi to tylko ładna opowieść.
Ustalaj zasady dotyczące powiadamiania człowieka. Agent powinien znać własne granice. Jeśli żądanie przekracza określony próg kwotowy, odnosi się do konta VIP lub napotyka stan, którego nigdy wcześniej nie widział, powinien eskalować problem, zamiast zgadywać.
Zainstaluj bramki wydawnicze (release gates), aby blokować złe aktualizacje modeli. Nowy model jest aktualizacją tylko wtedy, gdy poprawia Twoje konkretne wyniki. Jeśli częściej halucynuje argumenty narzędzi, zwiększa opóźnienia lub wprowadza nowe ryzyka związane z bezpieczeństwem, nie powinien zostać wdrożony. Bramka zapewnia stabilność środowiska produkcyjnego, nawet gdy dostawca modelu bazowego udostępnia nową wersję.
Runtime Grading: Obserwowanie pracy agenta w czasie rzeczywistym
Anthropic naciska na branżę, aby wyjść poza testy offline w stronę runtime grading (oceny w czasie rzeczywistym). Zamiast oceniać transkrypcję po fakcie, runtime grading pozwala systemowi oceniać pracę agenta, gdy zadanie jest jeszcze w toku. Daje to szansę na wyłapanie błędów, zanim przerodzą się w realne problemy.
Dodanie oceniacza (gradera) wiąże się z kosztem tokenów i zwiększeniem opóźnienia. Nie możesz pozwolić sobie na ocenianie każdego najmniejszego kroku. Umiejscowienie każdego oceniacza to decyzja projektowa. Umieszczaj je tam, gdzie błędy są kosztowne. Najbardziej wartościowe punkty kontrolne znajdują się tuż przed zatwierdzeniem zmiany stanu w bazie danych, tuż przed pobraniem płatności i tuż przed wysłaniem wiadomości do klienta. Są to momenty, w których błędna decyzja staje się nieodwracalnym działaniem.
Uważaj na konkretną martwą strefę. Jeśli ten sam model wykonuje pracę i jednocześnie ją ocenia, może przeoczyć te same błędy. Rozumowanie, które wygenerowało błąd, może łatwo go zracjonalizować podczas przeglądu. W przypadku zadań o dużym znaczeniu zachowaj udział człowieka w procesie (human-in-the-loop). Pozwól ludziom weryfikować własne osądy oceniacza, zwłaszcza gdy w grę wchodzą pieniądze lub zaufanie klienta.
Celem jest tutaj kontrola operacyjna. Połącz dane o incydentach, rubryki zadań i ślady wykonania (runtime traces) w jeden cykl informacji zwrotnej. Oceń całą ścieżkę: plan, użycie narzędzi, zachowanie w sytuacjach naprawczych oraz wynik końcowy. Używaj testów offline, aby wyłapać znane, powtarzalne błędy przed wydaniem wersji. Używaj śladów runtime, aby znaleźć nowe awarie, których nie przewidziałeś. Wykorzystaj przegląd ludzki, aby odkryć, w których miejscach Twoje rubryki są zbyt naiwne i wymagają doprecyzowania.
Zadaj sobie więc pytanie: gdzie umieściłbyś oceniacza runtime w swoim przepływie pracy? Przed wywołaniem narzędzia, po wywołaniu narzędzia, czy tylko przed ryzykowną zmianą? Większość zespołów zaczyna zbyt szeroko, oceniając wszystko, a następnie staje w miejscu z powodu kosztów. Zacznij wąsko. Wybierz to jedno działanie, którego niepowodzenie zabolałoby najbardziej. Tam umieść oceniacza w pierwszej kolejności.
Zacznij od jednego kosztownego błędu
Ocena operacyjna to nie ćwiczenie badawcze. To sposób na spokojniejszy sen, gdy agent jest już aktywny. Nie potrzebujesz idealnych ram (frameworka) pierwszego dnia. Potrzebujesz jednego, dobrze zdefiniowanego przepływu pracy, rubryki napisanej prostym językiem biznesowym oraz oceniacza umieszczonego dokładnie w momencie, w którym błąd staje się kosztowny. Zrób to dobrze, a zyskasz fundament, któremu możesz naprawdę zaufać.
Jeśli chcesz zgłębić temat oceny agentów i runtime grading wraz ze społecznością praktyków, znajdziesz społeczność edukacyjną GyaanSetu pod adresem https://t.me/GyaanSetuAi.