Dlaczego agent AI zatrzymuje się przedwcześnie, gdy narzędzie zwraca częściowy sukces?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Does an AI Agent Stop Early When a Tool Returns Partial Success?

Agent AI może zakończyć działanie zbyt wcześnie, ponieważ pomyli pomyślną odpowiedź narzędzia z dowodem, że wszystkie wymagane warunki zadania zostały spełnione.

Agent domowy może poprosić narzędzie o skopiowanie dziesięciu plików, zaktualizowanie kilku wydarzeń w kalendarzu, przetworzenie partii dokumentów, ponowne uruchomienie zależnych usług lub przeszukanie stronicowanych rekordów. Narzędzie może zwrócić prawidłową odpowiedź po przetworzeniu tylko części elementów, przyjęciu zadania do kolejki lub osiągnięciu wewnętrznego limitu. Jeśli agent śledzi tylko to, czy wywołanie zakończyło się bez błędu, może zamienić lokalny postęp w globalne twierdzenie o sukcesie. Poniższe sekcje rozdzielają sukces transportowy, postęp operacji i zweryfikowane ukończenie.

Pomyślne wywołanie narzędzia to tylko jedno lokalne zdarzenie

Poprawny kod HTTP, prawidłowa odpowiedź JSON lub status narzędzia „ok” potwierdza, że wywołanie zostało zaakceptowane lub przetworzone zgodnie z kontraktem narzędzia. Nie dowodzi automatycznie, że pełny cel użytkownika został osiągnięty.

Microsoft Research wykazało, że rzetelna ocena agentów wymaga weryfikacji wyniku, ponieważ powierzchowne sygnały sukcesu mogą być niezgodne z rzeczywistym stanem docelowym.

Agent potrzebuje oddzielnych predykatów dotyczących powodzenia wywołania, postępu na poziomie elementów, stanu końcowego i akceptacji widocznej dla użytkownika.

Narzędzia wsadowe i stronicowane mogą zwrócić tylko prawidłowy podzbiór

Narzędzie może przetworzyć pierwszą stronę, rekordy, które przeszły walidację, lub elementy ukończone przed upływem limitu czasu. Odpowiedź może być poprawna dla tego podzbioru.

CAR-bench ujawnia przedwczesne działania agentów w sytuacjach, gdy niepewność, brakujące informacje i powiązane narzędzia wymagają więcej niż jednego lokalnie poprawnego kroku.

Schemat narzędzia powinien zwracać żądaną liczbę elementów, liczbę ukończonych elementów, nieudane elementy, token kontynuacji, identyfikator oczekującego zadania oraz możliwość ponowienia próby, zamiast jednego niejednoznacznego pola sukcesu.

Pusta lista błędów nie wystarcza, jeśli narzędzie po cichu skróciło dane wejściowe lub nigdy nie wyliczyło wszystkich zamierzonych elementów.

Agent może utracić niedokończone zobowiązania ze swojego stanu zadania

Długie polecenia i plany wieloetapowe zawierają kilka ograniczeń. Gdy narzędzie zwróci pozytywną odpowiedź, model może skupić się na ukończonym kroku i nie zachować pozostałej listy kontrolnej.

Berkeley Function Calling Leaderboard ocenia stanowe zadania wieloetapowe, w których prawidłowe wywołanie nie dowodzi, że każde wymagane zobowiązanie nadal jest reprezentowane i ukończone.

Trwały rejestr zadań powinien przechowywać każde zobowiązanie jako otwarte, dopóki weryfikator nie oznaczy jego dowodów jako wystarczających. Sama pamięć w języku naturalnym jest niewystarczająca w przypadku długich partii i rozgałęzionych przepływów pracy.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Pewny siebie język końcowy może zastąpić rzeczywistą weryfikację

Modele językowe nauczyły się schematów takich jak „Gotowe”, „Pomyślnie ukończono” i zwięzłe podsumowania, które zwykle następują po pozytywnej odpowiedzi narzędzia.

Badania nad audytowalnym wczesnym kończeniem działania wymagają weryfikowalnego warunku zakończenia zamiast pewnego siebie komunikatu końcowego.

Odpowiedź końcowa powinna być generowana dopiero po weryfikacji stanu, a nie bezpośrednio na podstawie emocjonalnego tonu lub sformułowania ostatniej wiadomości narzędzia.

Częściowy sukces wymaga wyraźnego kontraktu dotyczącego następnego stanu

Niezawodne narzędzie powinno rozróżniać stany: ukończone, częściowo ukończone, dodane do kolejki, nieudane z możliwością ponowienia, trwale nieudane oraz nieznany wynik. Każdy status powinien określać, co orkiestrator musi zrobić dalej.

Inżynieria agentów działających przez długi czas wykorzystuje jawny stan postępu, aby ukończona i niedokończona praca przetrwała zmiany kontekstu oraz ponowne uruchomienia usług.

W przypadku agenta domowego następnym stanem może być przejście do kolejnej strony, odpytywanie zadania, ponowienie próby dla nieudanych elementów, uzgodnienie stanu zewnętrznego, poproszenie o zatwierdzenie albo zatrzymanie się i zgłoszenie dokładnego podzbioru nierozwiązanych elementów.

Wynik częściowy nigdy nie powinien mieć tego samego końcowego statusu co w pełni zweryfikowana operacja.

Uzależnij ukończenie od dowodów z systemu docelowego

Przed powiedzeniem „gotowe” porównaj żądany wynik z bieżącym stanem: liczbą plików i ich skrótami, identyfikatorami wydarzeń, kondycją usług, rekordami w bazie danych, statusem zadania lub innym punktem końcowym przeznaczonym do weryfikacji tylko do odczytu.

Badania ilościowego utrzymywania celów proponują ukończenie kontrolowane przez weryfikator, dzięki któremu agent nie może zakończyć działania, gdy mierzalne zobowiązania pozostają niespełnione.

Przewodnik ZimaSpace dotyczący narzędzi agenta tylko do odczytu zapewnia bezpieczniejszą warstwę weryfikacji plików, usług, urządzeń i planów bez wywoływania kolejnego efektu ubocznego.

Jeśli system docelowy nie może potwierdzić ukończenia, agent powinien zgłosić częściowy postęp, wymienić nierozwiązane elementy i zachować identyfikator operacji umożliwiający wznowienie, zamiast przedstawiać pomyślną odpowiedź końcową.

FAQ

Czy odpowiedź HTTP 200 oznacza pełny sukces?

Nie. Opisuje żądanie na poziomie protokołu. Treść odpowiedzi i stan docelowy muszą określać, czy cała żądana praca została ukończona.

Czy agent powinien automatycznie ponawiać próby dla wyników częściowych?

Tylko wtedy, gdy kontrakt narzędzia wskazuje nieudane elementy, a ponowienie prób jest idempotentne lub chronione przez stały klucz operacji.

Czy sam model językowy może zweryfikować ukończenie?

Może rozumować na podstawie dowodów, ale deterministyczne kontrole systemu docelowego są bardziej niezawodne w przypadku liczby elementów, identyfikatorów, stanów i wymaganych wyników.