Lepsza pierwsza próba nie gwarantuje skuteczniejszych powtórek agenta

Agent ma znaleźć w sklepie produkt spełniający wymagania użytkownika. Wyszukuje ofertę, otwiera kolejne strony, porównuje cechy i wybiera zakup. Samo podanie nazwy nie wystarcza: liczy się stan, do którego doprowadziły jego działania.

Zespół wdrażający taki system chce zwiększyć odsetek poprawnie wykonanych zadań. Nowsza wersja modelu częściej trafia za pierwszym razem, więc wygląda na dobry wybór. W trudniejszych przypadkach system może jednak uruchamiać kolejne próby i sprawdzać ich wyniki.

Tu pojawia się inne pytanie: czy model potrafi odzyskać zadania, które początkowo mu nie wyszły? Poprawa średniego wyniku może pochodzić z bardziej niezawodnego wykonywania łatwych zadań, podczas gdy trudniejsze stają się rzadziej rozwiązywane. Wtedy dodatkowe próby przynoszą mniej nowych sukcesów.

To ma znaczenie przy wyborze modelu do systemu z ponawianiem zadań. Wynik pojedynczej próby nie wystarcza do przewidzenia, ile zadań uda się ostatecznie wykonać przy większym budżecie obliczeń i wiarygodnym sprawdzaniu rezultatów.

Taką rozbieżność bada Sharpening Tax in Post-Training. To preprint opublikowany po raz pierwszy 1 października 2026, dotyczący oceny agentów opartych na modelach językowych oraz post-trainingu, czyli dalszego uczenia modelu po etapie ogólnego pre-trainingu. Główny wynik: model po post-trainingu może częściej odnosić sukces w pojedynczej próbie, a przy wielu próbach rozwiązywać mniej różnych zadań niż jego wersja bazowa. Nie jest to prawidłowość dotycząca każdego modelu i każdego treningu.

Jedna próba obejmuje całą pracę z narzędziami

Model otrzymuje polecenie, opisy dostępnych działań oraz historię dotychczasowej interakcji. Nie zna poprawnego końcowego przebiegu. Po każdym działaniu środowisko zwraca obserwację, na przykład stronę z wynikami wyszukiwania. Model wybiera następny krok na podstawie tej informacji.

Cały przebieg od początku zadania do zakończenia to rollout. Kolejny rollout zaczyna to samo zadanie od stanu początkowego, z nowo losowanymi odpowiedziami modelu. Nie jest kontynuacją poprzedniej porażki. Sprawdzający program ocenia wynik, ale nie podpowiada modelowi poprawnego rozwiązania podczas wykonywania zadania.

Wersja bazowa wymaga jeszcze adaptera między generowanym tekstem a narzędziami. Autorzy przygotowali prosty harness: podaje definicje narzędzi i format wywołań, odczytuje polecenia modelu oraz przekazuje prawdziwe odpowiedzi środowiska. Zatrzymuje generowanie, zanim model zacznie sam dopisywać odpowiedź narzędzia. Nie dostarcza gotowych rozwiązań zadań.

pass@k mierzy szansę uzyskania przynajmniej jednego sukcesu wśród k prób; wyższy wynik jest lepszy. pass@1 opisuje skuteczność pojedynczego uruchomienia. pass@128 odpowiada na pytanie o sukces wśród wielu uruchomień, nie o to, czy system umie automatycznie wskazać udaną próbę.

Te same zadania mogą poprawić średnią i pogorszyć wynik powtórek

Poniższe wartości są wymyślonym przykładem dydaktycznym, a nie wynikami badania. Mamy cztery polecenia zakupowe, oznaczone A–D. Dla każdego modelu wykonujemy każde polecenie cztery razy, za każdym razem od początku. Sukces oznacza zakup spełniający wszystkie wymagania. Zachowujemy również nieudane próby; nie odrzucamy ich z obliczeń.

Zadanie	Udane próby wersji bazowej, spośród 4	Udane próby po post-trainingu, spośród 4
A	1	4
B	1	2
C	1	0
D	1	0

Wersja bazowa ma łącznie cztery sukcesy w szesnastu próbach. Oszacowanie pass@1 wynosi 25%. Po treningu sukcesów jest sześć, więc pass@1 rośnie do 37,5%. Gdyby mierzyć tylko tę średnią, wybralibyśmy drugą wersję.

Przy całym budżecie czterech prób na zadanie baza rozwiązała jednak wszystkie cztery zadania: pass@4 wynosi 100%. Druga wersja rozwiązała dwa, więc jej pass@4 wynosi 50%. Powtórne sukcesy na A poprawiają niezawodność tego zadania, ale nie zastępują brakujących sukcesów na C i D.

To dokładnie operacja wykonywana w badaniu: autorzy liczą udane pełne rollouty osobno dla każdego zadania, a następnie wyznaczają skuteczność przy różnych budżetach. W przykładzie żadna dodatkowa reguła nie wybiera odpowiedzi ani nie zmienia danych treningowych. Widać tylko, jak inny rozkład sukcesów między zadaniami zmienia ocenę modelu. Każda wersja kosztowała szesnaście pełnych przebiegów, obejmujących kolejne wywołania modelu i narzędzi. Równa liczba przebiegów nie oznacza równej liczby jednostek tekstu przetwarzanych przez model, czyli tokenów, ani równego czasu pracy.

W WebShop wersja bazowa rozwiązała więcej zadań przy dużym budżecie

Najczytelniejsze porównanie dotyczy publicznych checkpointów google/gemma-4-31B i google/gemma-4-31B-it. Checkpoint to zapis parametrów modelu. Autorzy użyli opublikowanej pary, a nie wybrali własnego najlepszego checkpointu z serii treningowej. Nie znają jednak pełnej receptury ani sposobu wcześniejszego wyboru tych wersji przez twórców modeli.

Test wykonano na pierwszych 500 poleceniach WebShop, środowiska symulującego zakupy w katalogu produktów. Każdy model dostał 128 rolloutów na zadanie. Za sukces uznawano wyłącznie zakup spełniający wszystkie wymagania, z końcową nagrodą 1,0. Częściowe dopasowanie produktu nie wystarczało.

W tych warunkach wersja bazowa osiągnęła 87,6% pass@128, a wersja po post-trainingu 56,0%. Różnica wyniosła 31,6 punktu procentowego. To wyniki tej samej pary modeli, tego samego zbioru i tego samego budżetu, podane w tabeli 5 dodatku D.1.

W tej samej ewaluacji udział zadań bez choćby jednego sukcesu wzrósł z 12,4% do 44,0%. Jednocześnie udział zadań udanych we wszystkich próbach wzrósł z 0% do 26,0%. Model stawał się więc niezawodny dla części poleceń, ale dla większej części nie znaleziono udanego przebiegu w dostępnym budżecie. „Bez sukcesu w 128 próbach” nie oznacza matematycznej niemożliwości sukcesu przy dowolnej liczbie prób.

Autorzy interpretują takie przesunięcie jako sharpening: dalszy trening zwiększa prawdopodobieństwo części zachowań, a zmniejsza innych, w tym niektórych prowadzących do poprawnego wyniku. Rozkład wyników jest zgodny z tą hipotezą. Samo porównanie publicznych checkpointów nie dowodzi jednak, który składnik ich treningu wywołał zmianę ani że model utracił daną zdolność w każdym możliwym sposobie użycia.

Dodatkowa metryka nie zastępuje krzywej skuteczności

Proponowany Sharpening Tax porównuje korzyści z dokładania prób przed dalszym treningiem i po nim. Uwzględnia całą krzywą skuteczności, a nie tylko wynik przy końcowym budżecie.

Trzeba go czytać razem z pass@k. Dodatnia wartość może oznaczać mniej osiągalnych sukcesów, ale również to, że model szybciej osiąga swój wynik końcowy i mniej zyskuje z późniejszych prób. Sama metryka nie rozstrzyga między tymi sytuacjami. W opisanym WebShop spadek końcowej skuteczności jest wykazany osobno.

Autorzy proponują też posterior-tempered group sampling (PTGS). Podczas uczenia ze wzmocnieniem (RL), czyli treningu przez nagrody, zbierają dla każdego zadania informacje o sukcesach i porażkach. Na tej podstawie losują oszacowanie jego trudności i zmieniają temperature, parametr wpływający na losowanie kolejnych tokenów: zadania oceniane jako trudniejsze dostają więcej eksploracji, a łatwiejsze mniej.

PTGS zachowuje liczbę rolloutów grupy; dochodzi utrzymywanie statystyk i wybór temperatury. Prawdopodobieństwa używane w aktualizacji treningowej są liczone przy tej samej temperaturze co generowanie. Kontrolowane eksperymenty autorów pokazują możliwość złagodzenia kompromisu w Sokoban, gdzie trzeba przesunąć skrzynię na cel, oraz FrozenLake, gdzie trzeba przejść po siatce, omijając otwory. To osobne badanie dalszego treningu mniejszego modelu, nie naprawa testowanej pary Gemma ani dowód skuteczności PTGS w sklepie.

Szczegóły eksperymentu

Publiczna para Gemma w WebShop. Katalog zawierał 1000 produktów, a rollout mógł obejmować do 30 działań search lub click. Oba modele korzystały z temperature 0,7, top_p 0,95, limitu 256 generowanych tokenów na wywołanie oraz kontekstu 16 384 tokenów. Serwowano je przez vLLM 0.19.0. Thinking mode wyłączano tam, gdzie model je obsługiwał. Budżet liczono w rolloutach, nie w tokenach ani sekundach.

Baza otrzymywała zwykły tekst przez uniwersalny harness; wariant -it używał natywnego szablonu rozmowy, parsera wywołań i standardowej obsługi benchmarku. Jest to porównanie dwóch konfiguracji użytkowych, nie izolowany eksperyment wymieniający wyłącznie wagi. Ablacja tego adaptera miała inny budżet i nie należy mieszać jej wyników z głównym porównaniem.

95-procentowy przedział ufności dla różnicy pass@128 wyniósł 27,2–36,0 punktu procentowego. Autorzy wykorzystali paired task bootstrap: losowali z powtórzeniami te same zadania dla obu modeli, wykonując 1000 takich losowań. Przy końcowym budżecie każde zadanie wnosi tylko informację, czy pojawił się choć jeden sukces, co zwiększa szum tego punktu krzywej.

Całe porównanie obejmuje 14 publicznych par z rodzin Gemma-4, Ministral-3, Qwen2.5 i Qwen3.5 oraz WebShop, BFCL v4 multi_turn_base i ACEBench. Autorzy wybrali środowiska, w których obie wersje osiągały niezerową skuteczność. Niektóre mniejsze modele po treningu zyskiwały również przy wielu próbach, między innymi dzięki poprawniejszym wywołaniom narzędzi.

Osobny trening PTGS. Punktem startowym był Qwen2.5-7B-Instruct. W RAGEN autorzy wykonywali 200 kroków treningu: po osiem zadań i szesnaście rolloutów na zadanie. Filtr zachowywał 90% grup o największej wariancji nagród. Test obejmował 64 niewidziane zadania, po 128 rolloutów z temperature 0,5, bez PTGS podczas testu. Wyniki uśredniano po pięciu treningach. PPO, inny algorytm uczenia ze wzmocnieniem, oceniano po ostatnim kroku, natomiast GRPO, algorytm porównujący nagrody w grupie prób tego samego zadania, według najlepszego checkpointu na walidacji. Parametry PTGS dla GRPO także wybierano według walidacji; ustawienie PPO opisano wraz z porównaniem kilku szerokości zakresu temperatur. Porównania końcowych wyników trzeba czytać z tymi regułami wyboru, a nie jako pomiary dowolnej wersji modelu.

Źródła szczegółów: §3–5, dodatki A.1–A.5, C.2, D.1 i E.2 pełnego preprintu.

Sprawdź, które porażki da się odzyskać

Wynik nie uzasadnia prostego zastąpienia modeli instrukcyjnych wersjami bazowymi. Badanie dotyczy wybranych tekstowych środowisk, różnych sposobów obsługi modeli i publicznych receptur treningowych, których nie ujawniono w całości. Nie izoluje skutku samego RL. Repozytorium autorów zawiera minimalne przykłady działania, a nie kompletny pakiet odtwarzający całą ewaluację.

Przy własnym agencie trzeba dodatkowo rozpoznać poprawny rezultat i uwzględnić koszt prób. W kodzie może pomóc uruchomienie testów. Przy działaniach zmieniających stan zewnętrznego systemu ponowienie wymaga kontrolowanego odtworzenia stanu albo symulacji; seria zakupów nie jest bezpiecznym odpowiednikiem niezależnych epizodów benchmarku.

Mój wniosek inżynierski: oceniaj checkpointy także na tych samych zadaniach, które nie udały się za pierwszym razem. Zmierz, jaki ich odsetek odzyskują kolejne próby przy dopuszczalnym koszcie oraz jak często weryfikator akceptuje błędny rezultat.

Źródło: Changdae Oh, Qi Zeng, Qi Qi, Andrey Zhmoginov, Deren Lei, Yun He, Hoang Phan, Hangoo Kang, Azalia Mirhoseini i Sharon Li, Sharpening Tax in Post-Training, arXiv:2610.01509v1. Omówienie pełnego tekstu na licencji CC BY 4.0. Kod autorów.

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.