Przebieg bez błędów to jeszcze nie dobrze obsłużona sprawa

Czysty przebieg ze złym wynikiem

Weź hipotetycznego agenta przyjmującego zgłoszenia szkód. Ślad wykonania pokazuje trzy udane wywołania narzędzi: agent wyszukał polisę, zarejestrował zgłoszenie szkody i wysłał klientowi potwierdzenie. Brak błędów, zwykłe opóźnienie, zwykłe zużycie tokenów. Klient ma jednak dwie polisy, wyszukiwanie zwróciło pierwsze dopasowanie i zgłoszenie szkody jest teraz przypisane do polisy mieszkaniowej zamiast samochodowej.

Każdy sygnał techniczny jest zielony, a podsumowanie agenta mówi, że zgłoszenie szkody zostało zarejestrowane. Przewodnik Arize po ewaluacji agentów mówi to wprost: kontrola wyniku powinna odczytywać rzeczywisty stan systemu, a nie komunikat potwierdzający od agenta. Potwierdzenie wytworzył sam agent, więc nie może być dowodem, że miał rację.

Trzy pytania, trzy rodzaje dowodów

Przewodnik Anthropic po ewaluacji agentów oddziela transkrypt, czyli zapis wyjść, wywołań narzędzi i rozumowania, od wyniku, czyli końcowego stanu środowiska, na przykład tego, czy rezerwacja istnieje w bazie danych. Dla agenta procesowego daje to trzy osobne pytania:

• Kondycja przebiegu: czy przebieg się zakończył, które wywołania zawiodły, ile trwał i ile kosztował? Dowodem są spany i metryki
• Ścieżka: czy agent trzymał się dozwolonych kroków, prosił o akceptację tam, gdzie była wymagana, i unikał pętli? Dowodem jest ślad wykonania
• Wynik: czy stan rekordów biznesowych po przebiegu jest dla tej sprawy poprawny? Dowodem jest zapytanie do systemu źródłowego po zakończeniu przebiegu

Monitoring ograniczony do kondycji przebiegu, błędów i opóźnień dobrze odpowiada na pierwsze pytanie, a na trzecie wcale. Kontrole wyniku mogą zasilać tę samą telemetrię i te same alarmy; luka dotyczy tego, co jest instrumentowane. Właścicieli procesów interesuje przede wszystkim trzecie pytanie.

Jak napisać kontrolę wyniku dla sprawy

1. 1

   Określ oczekiwany stan końcowy

   Opisz go przez rekordy, a nie działania: istnieje dokładnie jedno zgłoszenie szkody, powiązane z polisą P-2, z rodzajem szkody burza i statusem oczekuje na ocenę.

2. 2

   Odczytaj system źródłowy

   Po przebiegu odpytaj system obsługi szkód bezpośrednio, z poświadczeniami, których agent nie używa. Nie wykorzystuj ponownie wyniku narzędzia, który widział agent.

3. 3

   Sprawdź, co nie mogło się zmienić

   Żadnego drugiego zgłoszenia szkody, żadnej zmiany adresu klienta, żadnej wiadomości do nikogo poza ubezpieczającym.

4. 4

   Oceniaj części osobno

   Właściwa polisa, właściwy rodzaj szkody i właściwy status to osobne kontrole. Anthropic zaleca częściowe punkty za zadania wieloczęściowe, co przy okazji pokazuje, która część zawodzi najczęściej.

Do czego ślad wykonania nadal się przydaje

Ocena wyniku nie sprawia, że ślady wykonania tracą znaczenie. Gdy kontrola wyniku nie przechodzi, ślad pokazuje, gdzie sprawa się wykoleiła: niejednoznaczny wynik wyszukiwania, argument narzędzia wymyślony przez model albo dokument, którego agent nigdy nie przeczytał. Konwencje semantyczne OpenTelemetry dla generatywnej AI opisują spany takie jak invoke_agent i execute_tool z atrybutami w rodzaju gen_ai.tool.name i error.type. Wciąż mają status Development, ale dają różnym frameworkom wspólny kształt tych danych.

Niektóre reguły dotyczące ścieżki są też twardymi wymaganiami. Jeśli polityka mówi, że wypłata wymaga wcześniejszej akceptacji, poprawna wypłata bez akceptacji i tak jest błędem. Anthropic przestrzega przed ocenianiem stałej sekwencji kroków, bo karze to poprawne alternatywy; Arize proponuje sprawdzać wymagania wspólne dla wszystkich poprawnych ścieżek. W praktyce pisz kontrole ścieżki tylko dla reguł naprawdę obowiązkowych, a resztę zostaw ocenie wyniku.

Jak czytać wynik i ślad razem

• Dobry wynik, zgodna ścieżka: sprawa zaliczona
• Dobry wynik, reguła złamana po drodze: błąd, nawet jeśli rekord wygląda dobrze
• Zły wynik, czysty przebieg: najgroźniejsze połączenie, bo alarmy błędów i opóźnień milczą. Przyjrzyj się danym z narzędzi, niejednoznacznym wejściom i rozumowaniu modelu
• Zły wynik z błędami w przebiegu: zwykle problem z obsługą błędów, gdy agent kontynuował po nieudanym albo niepełnym wyniku narzędzia

Raportuj trzecią grupę jako osobną liczbę. To odsetek spraw, którego nie widzą dashboardy ograniczone do błędów i opóźnień, i właśnie ten, który mają wyłapywać kontrole wyniku.

Gdy wynik trudno sprawdzić

Nie każdy wynik jest polem w bazie danych. Odpowiedź dla klienta, podsumowanie dla rzeczoznawcy czy płatność rozliczana kilka dni później wymagają innego podejścia. Wyniki opóźnione potrzebują drugiej kontroli zaplanowanej na moment, w którym efekt powinien już nastąpić. Tekst potrzebuje kryteriów oceny stosowanych przez skalibrowanego sędziego modelowego albo przez ludzi. Anthropic zaleca, by sędzia modelowy miał wprost dozwoloną odpowiedź nie wiem i by porównywać jego oceny z ocenami ekspertów.

Przydatne pierwsze ćwiczenie: weź dwadzieścia ostatnich przebiegów bez błędów, ręcznie sprawdź każdy wynik w systemie źródłowym i policz, ile było złych. Ta liczba pokaże, czy kontrole wyniku są priorytetem.