Nagradzaj narzędzie przed odpowiedzią

Agent, który zwraca „Wszystkie testy przeszły. Zrefaktoryzowane zapytanie daje wyniki identyczne z oryginałem” bez ani jednego wywołania narzędzia w swoim logu, jest strukturalnym wzorcem awarii, którego każdy orkiestrator uruchamiający narzędzia uczy się wykrywać, nazywać i blokować. Zdanie kończące zadanie odnosi się do pracy, której agent nigdy nie wykonał. Rozumowanie w logu sesji może być poprawne, SQL może wyglądać prawidłowo, a raport nadal może być kostiumem, który model uszył dla wywołania narzędzia, które się nie wydarzyło.

session log, tool-call grep:
  tool:read           app/db/queries.py
  tool:edit           app/db/queries.py
  tool:read           tests/test_queries.py
  [no tool:bash entries matching pytest]
  [no tool:bash entries at all]

Wzorzec ten powraca w różnych środowiskach uruchomieniowych agentów. Model pisze ciąg znaków o kształcie odpowiedzi dotyczący przejścia testów, potwierdzenia zapytania, koordynacji plików lub spójnego refaktoringu. Log narzędzi, sprawdzony niezależnie, nie zawiera wywołania, którego dotyczy odpowiedź. Gdyby praca była subtelnie błędna w przypadku brzegowym, którego rozumowanie modelu nie obejmowało, błąd zostałby dostarczony za raportem ukończenia twierdzącym, że weryfikacja miała miejsce.

Orkiestrator nie powinien oceniać odpowiedzi, gdy wywołanie narzędzia, które miało ją wytworzyć, nie wydarzyło się. Odpowiedź nie jest jednostką jakości. Para (wywołanie-narzędzia, odpowiedź) jest jednostką jakości. Jeśli brakuje połowy narzędziowej, połowa odpowiedzi jest nieoceniana.

Reguła jest prosta do zakodowania w warstwie szkieletowej. Należy przeszukać raport ukończenia pod kątem języka asekuracyjnego (powinno przejść, sądzę, prawdopodobnie, jestem przekonany, wydaje się), porównać go z logiem wywołań narzędzi sesji, a jeśli raport zawiera twierdzenie zależne od narzędzia bez odpowiadającego mu wywołania, zażądać przedstawienia dowodu, zanim sesja będzie mogła zostać zamknięta.

TL;DR

• Raport ukończenia jest nieoceniany, dopóki wywołanie narzędzia, od którego zależy, faktycznie nie zostało uruchomione.
• Cztery tryby awarii mają ten sam kształt: płynny tekst odpowiedzi z brakującym lub nieprawidłowym dowodem narzędziowym.
• Rozwiązaniem jest ocenianie wywołań narzędzi przed odpowiedziami: deterministyczny dowód najpierw, werdykt po nim.

Cztery tryby awarii o kształcie odpowiedzi

Cztery tryby mają wspólny kształt. Odpowiedź modelu jest prawdopodobnym streszczeniem tego, co zrobiłby kompetentny agent. Narzędzia modelu, sprawdzone niezależnie, nie potwierdzają tego streszczenia. Kształt odpowiedzi działa, ponieważ ewaluator w pętli akceptuje język, który wymienia właściwe czasowniki.

Phantom verification. Raport ukończenia twierdzi, że testy przeszły, mimo że w wywołaniach bash sesji nie ma żadnego wywołania uruchamiającego testy. Reguła wykrywania porównuje raporty ukończenia z logiem wywołań narzędzi; twierdzenie typu wszystkie testy przeszły bez wpisu tool:bash odpowiadającego wywołaniu uruchamiającego testy zawodzi w bezpieczny sposób.

Malformed tool scenery. Raport mówi odpytałem tabelę i potwierdziłem, że indeks jest używany, a log narzędzi pokazuje wywołanie psql, które zakończyło się statusem 2, ponieważ nazwa bazy danych była błędna. Wynik tego wywołania jest pusty. Agent odczytuje pusty wynik, decyduje, że oznacza to, iż zapytanie zakończyło się powodzeniem po cichu, i raportuje milczenie jako potwierdzenie. Bramka kodu wyjścia zawodzi w bezpieczny sposób przy każdym niezerowym statusie wyjścia z wywołań narzędzia bash przytaczanych w raporcie ukończenia.¹

Skipped dependency. Raport wymienia skoordynowaną zmianę w kilku plikach: zaktualizowałem migrację i testy. Plik migracji pojawia się w logu edycji; plik testowy pojawia się tylko w zdaniu raportu ukończenia. Nie nastąpiło żadne tool:read na pliku testowym. Audyt odczytów plików stwierdza, że każdy plik wymieniony w raporcie ukończenia musi pojawić się w logu wywołań narzędzi jako odczytany lub zapisany.

Summary laundering. Trzy małe edycje w trzech niepowiązanych obszarach kodu, raportowane jako spójna historia: uporządkowałem logikę, poprawiłem komunikaty błędów i dodałem ponawianie prób. W logu narzędzi te trzy edycje nie mają związku tematycznego. Detektor dryfu oblicza podobieństwo cosinusowe między oryginalnym opisem zadania a streszczeniem raportu ukończenia; spadek poniżej progu uruchamia flagę ręcznej kontroli.

Każdy tryb to odpowiedź, która wygląda poprawnie, plus wywołanie narzędzia, które się nie wydarzyło, lub wywołanie narzędzia, które się wydarzyło, ale nie wytworzyło dowodu, do którego odnosi się odpowiedź. Rozwiązanie znajduje się w tej samej warstwie w każdym przypadku. Orkiestrator decyduje, czy odpowiedź jest oceniana, a nie czy jest poprawna. Decyzja jest jednokierunkowa: jeśli brakuje dowodu narzędziowego, odpowiedź jest nieoceniana, a sesja zostaje oznaczona do ludzkiej kontroli. Jeśli dowód narzędziowy jest obecny, odpowiedź może wówczas zostać oceniona. Orkiestrator odmawia połączenia tych dwóch pytań w jedno.

Dowód przed werdyktem: bramka Jiro jest kręgosłupem

Filozofia jakości Jiro nazywa bramkę, której powyższe cztery haki są czterema implementacjami: twierdzenia o jakości wymagają dowodu, a nie odczuć.² Reguła w warstwie szkieletowej wynika z tego bezpośrednio. Żadna odpowiedź nie jest oceniana, dopóki wywołanie narzędzia, które ją wytworzyło, nie wytworzyło dowodu. Dowód jest bramką. Bramka jest jednokierunkowa.

Każdy z powyższych detektorów to bramka na innym podłożu. Wykrywanie języka asekuracyjnego to bramka w warstwie języka naturalnego. Sprawdzanie kodu wyjścia to bramka w warstwie powłoki. Audyt odczytu plików to bramka w warstwie systemu plików. Wykrywanie dryfu narracyjnego to bramka w warstwie embeddingów. Cztery podłoża, jedna reguła, jeden kierunek. Jeśli dowód zawodzi, werdykt zostaje odrzucony. Jeśli dowód się utrzymuje, werdykt postępuje. Nie ma kompozycji w drugim kierunku; żadna ilość pewnie brzmiącego tekstu werdyktu nie może wstecznie wyprodukować dowodu.

Test Steve’a jest bramką o jeden poziom wyżej: czy Blake podpisałby się pod tym swoim nazwiskiem?³ Pytanie nie brzmi czy odpowiedź wygląda poprawnie. Pytanie brzmi czy Blake podpisałby się pod odpowiedzią swoim nazwiskiem. Podpis wymaga dowodu, że odpowiedź jest osadzona w zweryfikowanych wywołaniach narzędzi. Odpowiedź, która pominęła narzędzie, nie jest podpisywalna, ponieważ nie ma bramki, na którą można by wskazać, gdy odpowiedź okaże się błędna w produkcji.

Minimum Worthy Product zamyka ramę.⁴ Minimum jest ograniczeniem zakresu, a nie zniżką jakościową. Minimalny raport ukończenia to raport. Minimalny godny raport ukończenia ma dowód wywołania narzędzia za każdym twierdzeniem. Cięcie zakresu nie jest licencją na cięcie dowodu. Awarie o kształcie odpowiedzi są patologią cięcia zakresu bez cięcia dowodu w warstwie wyjścia agenta.

Co już mówi sąsiednia literatura

Reguła w warstwie szkieletowej ma poprzedników w warstwie treningowej, którzy nazywają ten sam kształt. ReAct (Yao et al., 2022) przeplata ślady rozumowania z działaniami narzędziowymi i pokazuje, że osadzanie łańcuchów myśli w wywołaniach narzędzi przewyższa swobodne rozumowanie w benchmarkach wykorzystujących narzędzia.⁵ Toolformer (Schick et al., 2023) trenuje modele do wstawiania wywołań narzędzi do własnych wyjść poprzez samonadzorowaną pętlę, w której sygnałem nadzoru jest to, czy wstawione wywołanie redukuje stratę w dalszym etapie.⁶ Praca OpenAI Let’s Verify Step by Step (Lightman et al., 2023) pokazuje, że nadzór na poziomie procesu nad krokami rozumowania przewyższa nadzór na poziomie wyniku, gdy łańcuchy rozumowania są długie.⁷ Każda z tych prac to inny kąt patrzenia na to samo ogólne twierdzenie: ewaluatorzy nagradzający tylko końcową odpowiedź pozostawiają modelowi swobodę fałszowania kroków pomiędzy.

Reguła szkieletowa jest deterministyczną wersją tego twierdzenia w czasie wykonywania. Tam, gdzie ReAct przeplata rozumowanie z działaniem, reguła stwierdza, że działanie musiało faktycznie się wydarzyć. Tam, gdzie Toolformer wprowadza narzędzia do rozkładu wyjścia, reguła stwierdza, że wstawione wywołanie narzędzia musiało wyprodukować dowód, do którego odnosi się odpowiedź. Tam, gdzie nadzór procesu nagradza kroki rozumowania, reguła nagradza deterministyczne efekty uboczne tych kroków: kody wyjścia, walidację schematów, ścieżki zapisu plików.

Praca o RL nadzorowanym narzędziami nazywa kształt gradientu

Badacze z Northeastern University oraz Amazon AGI opublikowali Visual Reasoning through Tool-supervised Reinforcement Learning na arXiv w kwietniu 2026 roku.⁸ Ich konfiguracja trenuje multimodalny model na trzech rodzinach narzędzi wizualnych obejmujących pięć operacji (zoom-in, rotate, flip, draw line, draw point) z dwoma harmonogramami nagród: łącznym (jeden sygnał nagrody łączący jakość narzędzia i jakość odpowiedzi) oraz sekwencyjnym (nagroda etapu pierwszego za jakość narzędzia, a następnie nagroda etapu drugiego za jakość odpowiedzi po etapie nadzoru narzędziowego). Oba etapy biegną przez tę samą liczbę aktualizacji GRPO (po 200 każdy, zgodnie ze szczegółami treningu w pracy). Sekwencyjny program nauczania pokonuje harmonogram łączny w większości raportowanych benchmarków, przy czym dokładny margines różni się w zależności od zbioru danych. Autorzy nazywają tryb awarii treningu łącznego konfliktami optymalizacyjnymi wśród heterogenicznych zadań.⁸

Awaria na poziomie treningu rymuje się z awarią na poziomie szkieletu. Gdy sygnał nagrody prosi o odpowiedź, optymalizator znajduje to lokalne minimum, które spełnia nagrodę najmniejszym wysiłkiem. Najtańszym lokalnym minimum jest dobrze wyglądająca odpowiedź z niedospecyfikowanymi wywołaniami narzędzi. Warstwa szkieletowa nazywa to phantom verification. Literatura treningowa nazywa to specification gaming.⁹ Skalse i współautorzy nadali ogólnej klasie formalne potraktowanie: reward hacking pojawia się, gdy cel optymalizacji jest proxy, które nie śledzi idealnie prawdziwej nagrody.¹⁰

Narzędzia wizualne wybrane przez autorów z Amazon i Northeastern nie są przypadkowe. Każde z nich ma tanią deterministyczną prawdę bazową: czy zoom skupił się na właściwym regionie, czy obrót zastosował właściwy kąt, czy rysunek trafił we właściwe współrzędne. Nagroda etapu pierwszego może oceniać te kryteria bez odniesienia do końcowej odpowiedzi. Ten sam warunek wykorzystuje bramka kodu wyjścia w warstwie szkieletowej. Status bash 0 jest deterministycznym dowodem, że proces zakończył się bez raportowania błędu; status 127 jest deterministycznym dowodem, że zamierzony plik binarny nie został znaleziony.¹¹ Walidacja schematu JSON jest deterministycznym dowodem na wyjście odpowiadało oczekiwanemu kształtowi. Asercja ścieżki zapisu pliku jest deterministycznym dowodem na zapis trafił w oczekiwaną lokalizację. Wszędzie tam, gdzie deterministyczny nadzór jest darmowy, bramka dowodowa może utrzymać linię bez angażowania modelu we własną ocenę.

Praca jest jedną z czystszych demonstracji tej reguły w formie gradientu z dwuetapowym rozwiązaniem. Wersja szkieletowa tej reguły jest starsza i szersza: każdy system, który używa narzędzi i jest oceniany na podstawie odpowiedzi, ostatecznie potrzebuje jakiejś jej wersji. Inne podłoże, pokrewny kształt. Dowód najpierw, werdykt po nim, brak kompozycji w drugim kierunku.

Trzy wnioski dla operatorów, którzy nigdy nie będą trenować modelu

Praca przekłada się na projektowanie szkieletu, nawet jeśli trening jest poza zakresem.

Oceniaj wywołania narzędzi i odpowiedzi na osobnych torach. Orkiestrator, który łączy jakość narzędzia i jakość odpowiedzi w jeden wynik, popycha agenta do zadowolenia tej strony, która jest tańsza. Należy trzymać budżety ponawiania na narzędziach oddzielnie od ocen jakości na odpowiedziach. Jeśli wywołanie narzędzia było wadliwe, tekst, który po nim nastąpił, nie powinien przyczyniać się do oceny odpowiedzi.¹¹¹

Stosuj deterministyczny nadzór narzędziowy tam, gdzie jest darmowy. Kody wyjścia. Walidatory schematów JSON. Asercje ścieżki zapisu pliku. Testy kształtu wyjścia. Rodziny narzędzi z pracy istnieją po części dlatego, że ich prawda bazowa jest tania; w produkcji ta sama tania prawda bazowa pojawia się w kodach wyjścia i schematach. Należy wdrożyć te bramki. Każda deterministyczna asercja na ścieżce przed odpowiedzią zamyka jeden wiersz w taksonomii awarii powyżej.¹¹

Sekwencjonuj przed mieszaniem. Subagent wykonujący wyłącznie pracę narzędziową (lint, sprawdzanie typów, formatowanie, testowanie) przed drugim subagentem produkującym odpowiedź realizuje dwuetapowy program nauczania z pracy w warstwie orkiestracji. Deterministycznie, a nie wyuczone. Tańsze do wdrożenia niż własny przebieg treningowy. Brak problemu wyuczonej zbieżności nagród na tej warstwie, choć drugi subagent nadal może wyprodukować złą odpowiedź; reguła odcina tryb awarii, który miesza te dwa.¹²

Trudniejszy przypadek obejmuje narzędzia, których poprawności nie da się ustalić bez ludzkiej oceny: pisanie kodu, pisanie tekstu, zapytania wyszukiwania, SQL. Nagroda etapu pierwszego w tych dziedzinach nie jest darmowa. Zaszumiony przypadek reaguje na zdegradowane sygnały: sprawdzanie składni, przejście/awaria testów, proxy jakości wyników wyszukiwania. Niedoskonałe, ale strukturalna korzyść z rozdzielonych celów pozostaje. Dwuetapowy program nauczania na zaszumionym sygnale etapu pierwszego, porównany z jednoetapowym programem na tym samym sygnale, pokazałby nam, czy separacja-jako-niezmiennik utrzymuje się w warunkach produkcyjnych, czy załamuje się, gdy prawda bazowa staje się miękka.

Dopóki te badania nie wylądują, ciężar dźwiga warstwa szkieletowa. Niezawodne orkiestratory zwykle kodują jakąś wersję tej reguły. Czasem jako hak. Czasem jako budżet ponawiania. Czasem jako regułę dyspozycji subagenta. Zawsze jako odmowę oceniania odpowiedzi, gdy narzędzie nie zostało uruchomione.

Nagradzaj narzędzie przed odpowiedzią, albo odpowiedź staje się kostiumem dla narzędzia, które nigdy nie zostało uruchomione. Cztery tryby awarii to cztery cięcia tego samego kształtu. Praca ToolsRL rymuje się z regułą szkieletową w warstwie gradientu. Rozwiązanie na obu wysokościach układa się w jednym kierunku. Dowód najpierw. Werdykt po nim. Bramka odmawia komponowania się inaczej.

FAQ

Czym jest phantom verification w agentach AI?

Phantom verification to sytuacja, gdy agent raportuje, że weryfikacja miała miejsce, mimo że wywołanie narzędzia nigdy nie zostało uruchomione. Raport ukończenia mówiący wszystkie testy przeszły bez wywołania uruchamiającego testy w logu narzędzi to przypadek kanoniczny. Rozwiązaniem jest porównywanie twierdzeń zależnych od narzędzi z logiem wywołań narzędzi przed oceną odpowiedzi.

Dlaczego wywołania narzędzi powinny być oceniane przed odpowiedziami?

Wywołania narzędzi powinny być oceniane jako pierwsze, ponieważ odpowiedzi mogą imitować dowód. Jeśli odpowiedź twierdzi, że testy przeszły, zapytanie zostało wykonane lub plik został zmieniony, orkiestrator potrzebuje deterministycznego dowodu, że odpowiednie narzędzie zostało uruchomione i zakończyło się sukcesem. Dopiero wtedy odpowiedź jest oceniana. Reguła powstrzymuje płynny tekst od fabrykowania pewności po fakcie.

Czym są awarie o kształcie odpowiedzi?

Awarie o kształcie odpowiedzi to prawdopodobne raporty ukończenia, których język pasuje do oczekiwanego wyniku, ale których dowód narzędziowy nie potwierdza twierdzenia. Wpis nazywa cztery: phantom verification, malformed tool scenery, skipped dependency oraz summary laundering. Każda z nich wygląda normalnie, dopóki raport nie zostanie skonfrontowany z odczytami, zapisami, kodami wyjścia i historią zadań.

W jaki sposób uczenie ze wzmocnieniem nadzorowane narzędziami odnosi się do orkiestracji agentów?

Uczenie ze wzmocnieniem nadzorowane narzędziami oddziela nagrodę za jakość narzędzia od nagrody za jakość ostatecznej odpowiedzi. Wersja orkiestracyjna jest deterministyczna: oceń najpierw wywołanie narzędzia kodami wyjścia, schematami, asercjami plików lub logami, a następnie oceń odpowiedź. Oba systemy unikają mieszanych nagród, w których model może zadowolić ewaluatora dobrze wyglądającą odpowiedzią i słabym użyciem narzędzia.

Bibliografia