Testowanie bramy rubrykowej, która ponawia błędne ostateczne działanie agenta

Cecha Claude Outcomes firmy Anthropic integruje mechanizm, który wiele zespołów buduje samodzielnie: agent tworzy projekcję odpowiedzi, drugi komponent ocenia ją według określonych kryteriów, a w przypadku błędu agent ma szansę spróbować ponownie. Zasada ta jest na tyle prosta, że można ją wypróbować bez pełnego produktu, dlatego w kontrolowanym środowisku stworzono uproszoną wersję z wyjściem agenta, oceną według kryteriów oraz dokładnie jedną próbą ponowną.

Pytanie

Test dotyczy jednej kwestii: gdy agent musi podjąć ustrukturyzowaną decyzję, czy mechanizm ponownych prób oparty na kryteriach zmniejsza liczbę błędnych ostatecznych działań?

Tutaj kluczowe są ostateczne działania, ponieważ wiele rzeczywistych błędów agentów nie ma nic wspólnego z jakością tekstu. Odpowiedź może wyglądać dobrze, JSON może być poprawnie zinterpretowany, a mimo to wybrana akcja może okazać się błędna. W takiej sytuacji proces obsługi klienta przeradza się w błąd operacyjny. Przykładowo, jeśli agent zwróci wartość DENY, podczas gdy poprawną byłaby NO_ACTION, to nawet ostrożnie sformułowane uzasadnienie nie może tego naprawić.

Ustawienia

Do testów wykorzystano trzydzieści syntetycznych przypadków obsługi klienta oraz jeden model, gpt-5.4-mini. Taki przykład nie może uchodzić za rzetelny benchmark. Istotne jest to, jak wyglądały błędy: które zostały naprawione, które przeoczone oraz gdzie pojawił się koszt tych błędów.

Każdy przypadek zawiera krótki scenariusz klienta, zasady postępowania oraz zamkniętą listę dozwolonych ostatecznych działań:

APPROVE
DENY
ASK_CLARIFYING_QUESTION
ESCALATE
NO_ACTION

Dwa algorytmy konkurowały ze sobą. W wersji bazowej odpowiedź trafia bezpośrednio do agenta, a każda podjęta akcja jest zapisywana. W wersji z kontrolą sędzia według określonej rubryki ocenia pierwszą odpowiedź, a w przypadku niepowodzenia odsyła agenta, aby spróbował ponownie, tym razem mając przy sobie kryteria, których nie spełnił.

Poniższy diagram stanowi zwięzły przewodnik po procesach pracy agentów z kontrolą wyników. Pokazuje on bramy kontrolne, które sprawdzają proponowaną akcję pod kątem umowy polityki przed podjęciem ostatecznej decyzji.

Umowa została celowo sformułowana w sposób ścisły – zawiera zamknięty zbiór akcji, wyraźne ograniczenia polityki oraz jedną możliwość ponownej próby w przypadku niepowodzenia sprawdzenia według rubryki.

Baseline:
case -> agent -> final action

Gated:
case -> agent -> rubric judge
if failed -> retry once
retry answer -> final action

Przypadki były syntetyczne, ale opracowano je w oparciu o typowe ograniczenia charakterystyczne dla produkcji:

Zastosowano prawdziwego dostawcę LLM, a nie deterministycznego symulatora, ponieważ interesujące jest to, jak model faktycznie zachowuje się po ocenie i modyfikacji jego pierwszej odpowiedzi.

Sędzia, który nie ma klucza odpowiedzi

Sędzia, który już zna odpowiedź, unieważniłby sens tego rozwiązania. Każdy przypadek zawiera expected_action, jednak ta wartość jest wykorzystywana jedynie do obliczania metryk offline po zakończeniu procesu, a sędzia nigdy jej nie otrzymuje. To, co widzi sędzia, to działanie wybrane przez agenta, które następnie jest sprawdzane pod kątem obiektywnych ograniczeń polityki.

Załóżmy prośbę o zwrot pieniędzy, która ma otwarte odwołanie w procesie obsługi płatności. NO_ACTION może być odpowiednią decyzją, ponieważ to dział płatności jest odpowiedzialny za jej rozwiązanie, a obsługa klienta nie powinna podejmować decyzji w tej sprawie. Słaby „sędzia” po prostu sprawdziłby, czy model wybrał NO_ACTION – to równa się sprawdzeniu klucza odpowiedzi. Pasuje to do oceny offline, ale nie stanowi bramy decyzyjnej.

Prawdziwa brama decyzyjna stawia inne pytanie: przy wartości DENY – czy agent błędnie przypisał obsługę klienta jako osobę podejmującą decyzję, podczas gdy sprawa znajduje się w innym procesie?

W czasie wykonywania nie chce się zwykle używać ukrytego klucza odpowiedzi. Chodzi o sprawdzenie, czy proponowana akcja narusza jasno określone zasady. W tym przypadku zasada była prosta: wybrać jedną ostateczną akcję i nie wybierać takiej, która koliduje z ograniczeniami określonymi w polityce sprawy.

Co się stało

Podczas jednej przejścia przez wszystkie 30 przypadków agent bazowy popełnił błąd w 6 ostatecznych działaniach. Gdy dodano sędziego oraz jedną próbę ponowną, tylko 2 pozostały błędne.

Postęp jest rzeczywisty, ale same liczby wprowadzają w błąd. Pętla nie dała agentowi żadnej nowej, ogólnej umiejętności – działała tylko wtedy, gdy sędzia mógł wskazać konkretny konflikt pomiędzy wybranym działaniem a zasadami, co pokazują przykłady niepowodzeń.

Co naprawiła ta funkcja

Pętla naprawiła 4 z 6 błędów agenta bazowego. Większość poprawek pochodziła z przypadków, w których agent bazowy zbyt szybko odmawiał zatwierdzenia. Zasady nie przewidywały natychmiastowej aprobaty, ale też nie wymagały odmowy. Lepszym rozwiązaniem było poproszenie o wyjaśnienia lub oczekiwanie na inny proces pracy.

Otrzymano prośbę o zmianę adresu e-mail konta. Przyszła z nowego urządzenia, nie zakończono jeszcze weryfikacji MFA, a osoba składająca prośbę znała kod pocztowy używany do fakturowania. Zasady wymagały zakończenia weryfikacji MFA lub innego zatwierdzonego sposobu potwierdzenia prawa do konta, zanim obsługa mogłaby przejść do dalszych działań. Bazowy model odpowiedział DENY, chociaż oczekiwano odpowiedzi ASK_CLARIFYING_QUESTION. Zamknięcie sprawy było przedwczesne, ponieważ istniała jeszcze możliwość zastosowania zatwierdzonej metody weryfikacji, więc zadanie pytania było właściwym krokiem. Sędzia odrzucił decyzję o odrzuceniu prośby jako zbyt wczesną, a przy ponownej próbie model zmienił odpowiedź na ASK_CLARIFYING_QUESTION.

Kolejny naprawiony przypadek dotyczył urządzenia zastępczego. Klient poprosił obsługę o ponowną wysyłkę, ale tego ranka zostało już utworzone zgłoszenie RMA, które czekało na skan magazynu. Bazowy wynik wskazał DENY, a oczekiwana akcja to NO_ACTION. Odrzucenie było błędne, ponieważ klient spełniał warunki. Proces wymiany już się toczył, więc obsługa nie powinna była otwierać duplikatu zgłoszenia RMA. Ponowna próba skorygowała to na NO_ACTION.

Oba przykłady pokazują praktyczną wartość tego wzorca. Ten mechanizm nie uczynił modelu ogólnie mądrzejszym – zmusił jedynie do naprawy konkretnej niezgodności pomiędzy wybraną akcją a zasadami polisy.

Czego nie potrafił naprawić

Dwa pozostałe niepowodzenia mówią więcej niż całkowita ocena. W obu przypadkach chodziło o istniejące procesy pracy, w których oczekiwana akcja to NO_ACTION, a ostateczna odpowiedź pozostała na poziomie DENY nawet po ponownej próbie.

W pierwszym przypadku wniosek o zwrot pieniędzy był powiązany z otwartym procesem chargeback w procesie płatności. Zasady zabraniały obsłudze wydawania zwrotów, dopóki proces chargeback był aktywny, ponieważ to dział płatności odpowiada za jego rozwiązanie. W drugim przypadku kupujący chciał ręcznego zatwierdzenia wysyłki, podczas gdy trwała weryfikacja oszustwa, a zasady zabraniały obsłudze zatwierdzania wysyłek w takim stanie. W obu przypadkach system wykrył problem i zwrócił kryteria niepowodzenia, a ponowna próba i tak doprowadziła do wykonania niewłaściwej akcji.

To zmienia sposób oceny wzorca pod kątem użycia w produkcji. System kontrolny może zauważyć, że dana akcja narusza regułę, ale samo zauważenie nie oznacza naprawy. Załóżmy, że model nie potrafi odróżnić opcji „odmówić żądaniu” od opcji „nie ingerować, ponieważ decyduje inny proces”. W takim przypadku nawet odpowiedź oznaczona jako problematyczna może pozostać bez zmian. To, że coś brzmi bezpiecznie, nie czyni akcji poprawną, a kod DENY wydaje się konserwatywny, choć nadal jest błędny, gdy agent nie ma uprawnień w danym przypadku.

Gdzie można mu ufać

Sukces w tym przypadku opierał się na możliwości sprawdzenia wyniku. Agent wybierał z zamkniętej grupy opcji, ograniczenia polityki były jasno określone, a osoba oceniająca mogła porównać wybraną akcję z konkretną regułą. Ponawianie prób uzależnione od wyniku budzi większe zaufanie w takich sytuacjach:

Należy zachować większą ostrożność, gdy wynik jest subiektywny:

Nie powinno się go traktować jako ogólnej warstwy niezawodności. Zachowaj go dla sytuacji, w których błędna akcja kosztuje na tyle dużo, że warto zapłacić za dodatkową próbę wywołania modelu, a pożądany wynik można uwzględnić w umowie.

Zmiany w produkcji, które warto wprowadzić

Jedna korekta ma większe znaczenie niż pozostałe: traktuj powtarzające się przypadki braku naprawy jako informacje zwrotne dotyczące projektu. Gdy agent ciągle myli DENY z NO_ACTION, uszczegóławь definicje działań, dodaj przykłady lub przeprojektuj umowę dotyczącą procesu pracy. Kolejna próba rzadko naprawia braki w zrozumieniu.

Należy również oddzielić mechanizmy kontrolne w czasie rzeczywistym od oceny offline. W czasie rzeczywistym sędzia egzekwuje ograniczenia, natomiast ocena offline porównuje końcowe działania z etykietowanymi oczekiwaniami. Ich łączenie fałszuje wyniki systemu. Warto również rejestrować każdą próbę ponowną, uwzględniając pierwsze działanie, nieprawidłowe kryteria, zmodyfikowane działanie oraz ostateczną decyzję, ponieważ połączenie napraw i braku napraw często mówi więcej niż ogólna dokładność.

Główny wniosek

Mechanizmy kontrolne przynoszą efekty, gdy „zakończenie” można sformułować jako umowę. W tym przypadku umowa była prosta: wybrać jedno końcowe działanie, które nie narusza ograniczeń zasad. Przy takim warunku pętla kontrolna skróciła liczbę błędnych decyzji z 6 na 30 do 2 na 30.

To właśnie te pozostałe niepowodzenia wymagają uwagi w środowisku produkcyjnym. Sędzia wykrył problem, a ponowna próba nadal doprowadziła do błędnej akcji. Dlatego otwartym pytaniem nie jest tylko to, czy system może ocenić wynik, ale także to, czy cały cykl jest w stanie przekształcić tę ocenę we właściwą decyzję. To właśnie takie dowody należy uzyskać, zanim jakikolwiek cykl oparty na wynikach dotknie rzeczywistego procesu pracy.

Dalsza lektura

Dokumentacja API Anthropic dotycząca definiowania wyników oraz artykuł w ich przewodniku po agentach, które weryfikują własną pracę, omawiają funkcje zarządzane, które odzwierciedlają ten eksperyment.