Przewidywanie wyników poleceń pomaga w późniejszym treningu agenta

Agent pracujący w terminalu próbuje uruchomić program. Wysyła polecenie, odczytuje komunikat o błędzie i wybiera następne działanie. Musi przy tym powiązać wynik z wcześniejszą komendą: rozpoznać, czy zabrakło pliku, pamięci, czy właściwego argumentu. Od tego zależy, czy kolejna próba poprawi sytuację.

Takiego agenta można uczyć na zapisach pracy sprawniejszego modelu. Zapis zawiera zarówno polecenia, jak i odpowiedzi terminala, ale trening zwykle ocenia tylko przewidywanie tekstu napisanego przez agenta. Odpowiedzi narzędzi są dostępne jako kontekst dla kolejnych decyzji. Model nie musi jednak sam przewidywać, jaka odpowiedź nastąpi po danym poleceniu.

Po naśladowaniu demonstracji agent może dalej uczyć się przez własne próby. Dwa modele równie dobrze odtwarzające udane działania mogą jednak inaczej reagować na nowe sytuacje. Ocena wykonana bezpośrednio po nauce z demonstracji może więc nie pokazać, który model będzie lepszym punktem startowym do dalszego treningu.

Tę zależność bada Don't Mask the Environment: Observation Supervision Changes How Agents Explore Under RL. To preprint z 17 września 2026, dotyczący uczenia agentów opartych na modelach językowych. Juzheng Zhang, Disha Makhija, Manoj Ghuhan Arivazhagan, Vinayshekhar Bannihatti Kumar i Rashmi Gangadharaiah proponują ActObs: podczas nauki z demonstracji model przewiduje również odpowiedzi środowiska, nazywane dalej obserwacjami. Późniejszy algorytm uczenia przez nagrody pozostaje taki sam.

Odpowiedź terminala może być kontekstem albo celem treningu

Uczenie na gotowych demonstracjach jest tu odmianą supervised fine-tuning, w skrócie SFT: zapis pokazuje modelowi pożądany przebieg działania, a trening dostosowuje jego parametry. Tekst dzieli się na tokeny, czyli jednostki przetwarzane przez model. Dla każdej ocenianej pozycji model ma przewidzieć następny token na podstawie wcześniejszego tekstu.

Loss masking określa, które pozycje wpływają na funkcję straty, czyli liczbową ocenę błędu używaną do zmiany parametrów. W wariancie ActionSFT oceniane są tokeny agenta, obejmujące jego rozumowanie i polecenia. Tokeny odpowiedzi terminala pozostają w sekwencji, lecz nie są celami przewidywania. Ich wyłączenie ze straty nie usuwa ich z kontekstu.

ActObs obejmuje stratą obie grupy. Model uczy się przewidywać polecenie, a następnie tekst odpowiedzi narzędzia po tym poleceniu. Początkowa instrukcja zadania nadal jest wyłączona z oceny. Podczas rzeczywistej pracy odpowiedź wciąż pochodzi z narzędzia; ActObs nie zastępuje wykonania komendy tekstem wymyślonym przez model.

Do oceny przewidywania służy cross-entropy: im mniejsze prawdopodobieństwo model przypisał tokenowi obecnemu w demonstracji, tym większa kara. W podstawowym wariancie ActObs każdy token akcji i obserwacji ma taką samą wagę. Średnia jest liczona po wszystkich ocenianych tokenach, a nie po równoważnych grupach „polecenia” i „odpowiedzi”. Dłuższa odpowiedź terminala wnosi więc więcej składników do straty. Taką normalizację określa równanie 1 w pracy.

Te same dwa polecenia dają trzy albo pięć celów przewidywania

Poniższy przykład jest przygotowany do wyjaśnienia metody, nie pochodzi z eksperymentu. Użytkownik prosi o odczytanie liczby zapisanej w pliku. Miniaturowe narzędzie obsługuje dwa polecenia: list podaje nazwę pliku, a read odczytuje wskazany plik. W demonstracji zapisano:

agent:      list
narzędzie:  report.csv
agent:      read report.csv
narzędzie:  42

Przyjmijmy na potrzeby rachunku umowny sposób podziału tekstu na tokeny (tokenizer), w którym list, read, report.csv i 42 są pojedynczymi tokenami. Pomijamy znaczniki ról. W sekwencji występuje pięć pozycji: trzy należą do agenta, dwie do narzędzia. report.csv występuje dwukrotnie i za każdym razem zajmuje osobną pozycję.

ActionSFT ocenia przewidywanie list, a później read i argumentu report.csv. Każda z tych trzech pozycji ma udział 1/3 w średniej stracie. Obie odpowiedzi narzędzia mają wagę zero. Model widzi pierwsze report.csv, zanim przewidzi polecenie read, ale nie jest oceniany za przewidywanie tej nazwy jako wyniku list.

ActObs przetwarza dokładnie ten sam zapis, lecz ocenia wszystkie pięć pozycji, każdą z udziałem 1/5. Pierwsza różnica pojawia się przy odpowiedzi na list: model dostaje teraz sygnał uczący przewidywania report.csv. Druga pojawia się przy 42, które ma przewidzieć po read report.csv. W obu przypadkach widzi tylko wcześniejszą część zapisu, a podczas treningu kolejne pozycje dostają prawdziwy wcześniejszy tekst demonstracji.

Polecenia odpowiadają zbiorowi tokenów akcji w algorytmie, a wyniki narzędzia zbiorowi tokenów obserwacji. Zmienia się ich udział w stracie; żaden fragment demonstracji nie jest losowany ponownie ani usuwany. Sygnał na wyniku read wymaga dopasowania przewidywania do skutku wcześniejszego polecenia. Nie oznacza to, że model potrafi znać dowolną zawartość nieodczytanego pliku: nieprzewidywalne informacje nadal mogą powodować błąd.

Pięć tokenów i dwa wywołania to wyłącznie uproszczenie dydaktyczne. W badaniu sekwencje zawierają rozumowanie, pełne komendy i długie odpowiedzi terminala. ActObs nie dodaje osobnych demonstracji ani przebiegów modelu, ponieważ odpowiedzi narzędzi już były przetwarzane jako kontekst. Cały trening nadal obejmuje zebranie demonstracji i późniejsze wykonywanie zadań przez agenta; jego budżet podano niżej.

Przewaga pojawiła się po wspólnym treningu GRPO

Po SFT autorzy zastosowali GRPO, algorytm uczenia ze wzmocnieniem (RL), który porównuje nagrody w grupie prób wykonania tego samego zadania. Próba obejmuje tu całą interakcję z terminalem, czyli rollout. Automatyczny weryfikator przyznaje nagrodę za wykonanie zadania. W tym etapie oba modele mają ten sam algorytm, dane i budżet, a ActObs nie dokłada już straty za przewidywanie odpowiedzi środowiska.

pass@k określa szansę uzyskania co najmniej jednego poprawnego wykonania wśród zadanej liczby prób; wyższy wynik jest lepszy. Przy pass@1 chodzi o pojedynczą próbę, chociaż jej skuteczność można oszacować z wielu uruchomień.

Najczytelniejszy wynik transferu dotyczy Qwen3-4B na aider-polyglot, zbiorze zadań edycji kodu w kilku językach programowania, sprawdzanych testami jednostkowymi. Po wspólnym harmonogramie GRPO końcowy model rozpoczynający od ActionSFT osiągnął 9,7% pass@1, a model rozpoczynający od ActObs 13,9%. Różnica wyniosła 4,2 punktu procentowego. Zadania tego testu nie występowały ani w demonstracjach SFT, ani w treningu GRPO. Przed GRPO to wariant ActionSFT miał wyższy wynik w tym teście. pass@1 oszacowano z czterech prób na zadanie; nie wybierano najlepszej z czterech odpowiedzi.

Osobny eksperyment z większym Qwen3-8B na zadaniach terminalowych ujawnił kompromis: ActObs pogorszył wynik pojedynczej próby, lecz poprawił szansę sukcesu przy wielu próbach. Nie był więc jednolicie lepszą inicjalizacją przy każdym budżecie. To istotna różnica dla systemu, który ma wykonać zadanie raz, i systemu, który może ponawiać próby oraz sprawdzać ich wyniki.

Szczegóły eksperymentu

Źródło konfiguracji i wyników: §3.1, tabela 1 oraz dodatki A–B preprintu v1. Główne porównania dotyczą końcowych checkpointów, czyli zapisanych wersji parametrów po wspólnym harmonogramie treningu. Autorzy opisują je jako końcowe polityki i porównują stan po zakończeniu treningu; poniższe liczby nie są maksimum odczytanym z krzywej treningowej.

SFT. Qwen3-4B i Qwen3-8B uczono na 50 tys. wieloturowych zapisów pracy w terminalu z syntetycznej części Nemotron-Terminal-Corpus. Demonstracje wygenerował DeepSeek-V3.2. Korpus zawierał 0,71 mld tokenów, z czego około 45% stanowiły obserwacje. Trening trwał jedną epokę, 781 kroków, z 64 przykładami na partię (batch size) i maksymalnym współczynnikiem kroku aktualizacji parametrów (learning rate) 0,00001, zmniejszanym według harmonogramu cosinusowego. Podstawowy ActObs stosował wagę obserwacji równą 1; ActionSFT równą 0. Normalizacja obejmowała liczbę tokenów akcji oraz ważoną liczbę tokenów obserwacji.

GRPO. Następowało 135 kroków na 2392 zadaniach Endless Terminals, rozłącznych z korpusem SFT. Stosowano 16 rolloutów na zadanie, batch size 32, learning rate 0,000001 i weryfikatory binarne. Zestawy ewaluacyjne były rozłączne z oboma etapami treningu. Nie należy mylić tych rolloutów z dwoma wywołaniami miniaturowego narzędzia w przykładzie.

Ewaluacja terminalowa. Terminal-Bench 2.0 zawierał 89 zadań. Każdy główny checkpoint oceniono w 16 próbach na zadanie, zebranych w czterech osobno uruchomionych paczkach po cztery próby. Użyto agenta terminus-2, oficjalnych limitów czasu i wspólnej konfiguracji obsługi modeli: jeden silnik vLLM na ośmiu GPU A100, 12 równoległych prób, kontekst 40 960 tokenów i wykorzystanie pamięci GPU ustawione na 0,90. Temperature, parametr wpływający na losowość wyboru tokenów, wynosiła 0,6. Top-p ograniczał pulę losowania do tokenów o łącznym prawdopodobieństwie co najmniej 0,95, a top-k do 20 najbardziej prawdopodobnych tokenów. Błędy modelu otrzymywały zero; błędy infrastruktury powtarzano raz. Konfigurację obsługi modeli ustalono po porównaniu dziewięciu ustawień, a następnie stosowano wspólnie dla metod.

Ewaluacja edycji kodu. Aider-polyglot obejmował 225 zadań w sześciu językach programowania, po cztery próby na zadanie. Wymieniona wyżej konfiguracja obsługi modeli dotyczy Terminal-Bench 2.0; nie należy automatycznie przypisywać jej testowi aider.

Każdy wiersz poniżej porównuje ActionSFT→GRPO z ActObs→GRPO w tym samym ustawieniu. Tabela obejmuje główne wyniki zwykłego GRPO, bez wariantu ECHO dodającego przewidywanie obserwacji również w RL.

Model i test	Metryka	ActionSFT→GRPO	ActObs→GRPO
Qwen3-4B, aider-polyglot, 4 próby na zadanie	pass@1	9,7 ± 0,6%	13,9 ± 0,7%
Qwen3-4B, aider-polyglot, 4 próby na zadanie	pass@4	20,4 ± 0,9%	25,3 ± 1,0%
Qwen3-4B, Terminal-Bench 2.0, 16 prób na zadanie	pass@1	5,6 ± 0,4%	7,2 ± 0,4%
Qwen3-4B, Terminal-Bench 2.0, 16 prób na zadanie	pass@16	18,0 ± 1,4%	19,1 ± 1,4%
Qwen3-8B, Terminal-Bench 2.0, 16 prób na zadanie	pass@1	12,3 ± 0,5%	11,0 ± 0,5%
Qwen3-8B, Terminal-Bench 2.0, 16 prób na zadanie	pass@16	23,6 ± 1,2%	27,0 ± 1,3%

Dla Qwen3-4B na aider-polyglot przed RL wynik pass@1 wynosił 1,4 ± 0,3% po ActionSFT i 1,0 ± 0,3% po ActObs. Późniejsza przewaga ActObs nie była więc prostym zachowaniem lepszego wyniku początkowego.

Wartości po znaku ± oznaczają jeden błąd standardowy oszacowany przez bootstrap: 20 tys. ponownych losowań prób przy niezmienionym zestawie zadań. Mierzą niepewność z ograniczonej liczby uruchomień agenta. Nie są pomiarem zmienności między niezależnymi treningami ani między różnymi zestawami zadań. pass@k obliczono estymatorem uwzględniającym liczbę sukcesów w dostępnych próbach.

Kontrole i diagnostyki. Wariant Obs→Act najpierw uczył tylko przewidywania obserwacji, potem tylko działań; wymagał dwóch epok i nie odtworzył przewagi wspólnego uczenia przy większych budżetach prób. Przetasowanie odpowiedzi między demonstracjami pogorszyło wyniki po SFT. To oddzielne kontrole, nie kolejne główne wyniki GRPO. Analiza gradientów używała 256 odłożonych demonstracji, a ocena przewidywania obserwacji 300 zapisów z części walidacyjnej korpusu. Pomiary entropy, miary rozproszenia prawdopodobieństw następnego tokena, na końcowych modelach obejmowały po 200 zapisów ewaluacyjnych. W kontroli dopasowania entropy podniesiono temperature ActionSFT→GRPO z 0,6 do 0,64; nie usunęło to różnicy pass@16 na Qwen3-8B.

ActObs zachowuje przewidywanie skutków i więcej wariantów poleceń

Autorzy sprawdzili, jak po SFT modele przewidują odpowiedzi terminala w odłożonych demonstracjach. ActionSFT pogarszał tę umiejętność względem modelu sprzed SFT, natomiast ActObs ją zachowywał i poprawiał. Efekt obejmował właściwą treść wyników, w tym błędy i komunikaty powłoki, a nie tylko powtarzalny nagłówek odpowiedzi narzędzia.

Diagnostyka gradientów, czyli kierunków zmian parametrów wynikających ze straty, pomaga wyjaśnić, dlaczego samo uczenie poleceń tego nie zapewniało. W trakcie SFT kierunek poprawiający przewidywanie działań szybko przestawał pokrywać się z kierunkiem poprawiającym przewidywanie obserwacji. ActionSFT pomijał drugi sygnał. ActObs uwzględniał go przez cały trening, choć bezpośrednie wyniki wykonywania zadań po SFT pozostawały zbliżone.

Po GRPO ActObs zachowywał wyższą entropy, czyli większe rozproszenie prawdopodobieństw następnego tokena. Różnica była widoczna szczególnie w dalszych pozycjach komendy, gdzie występują argumenty, opcje i ścieżki. Więcej takich wariantów pozostawało dostępnych podczas losowania kolejnej próby. Nie znaczy to, że agent odkrywał więcej całkowicie różnych strategii: analiza udanych wykonań wskazywała głównie na różnice w realizacji podobnych procedur.

Te pomiary wspierają wyjaśnienie związane z zachowaniem użytecznych alternatyw, ale nie dowodzą, że sama entropy odpowiada za poprawę. Zwiększenie losowości modelu ActionSFT do podobnego poziomu nie odtworzyło wyniku ActObs. Kontrolowana zmiana maski pokazuje wpływ celu SFT na późniejsze wyniki; pełny łańcuch od przewidywania obserwacji do konkretnego udanego działania pozostaje interpretacją popartą diagnostykami.

Oceniaj inicjalizację po dalszym treningu i przy docelowym budżecie prób

Badanie dotyczy jednej rodziny modeli w dwóch rozmiarach, demonstracji jednego modelu i treningu w terminalu. Transfer do edycji kodu poszerza zakres testu, lecz nie potwierdza działania metody w przeglądarce, interfejsie graficznym ani robotyce. Autorzy ujawniają też różnice między środowiskami etapów: podczas RL komendy wykonywano w świeżej, nieinteraktywnej powłoce, a test terminalowy korzystał z trwałej sesji tmux. Porównania metod wewnątrz etapu były kontrolowane, ale takie różnice mogą zmieniać wyniki bezwzględne. Kod i szczegółowe artefakty autorzy zapowiadają po akceptacji pracy.

Ocena SFT powinna uwzględniać efekt późniejszego RL, ponieważ podobny wynik po demonstracjach nie gwarantuje podobnego efektu dalszego treningu. Własny test ActObs powinien zachować te same dane i budżet, a następnie porównać modele po pełnym planowanym treningu. Ponieważ większy badany model zyskiwał przy wielu próbach kosztem pojedynczej, trzeba mierzyć oba wyniki oraz koszt ponawiania; pass@k nie rozwiązuje problemu rozpoznania, która próba zakończyła się poprawnie.

Źródło: Juzheng Zhang i współautorzy, Don't Mask the Environment: Observation Supervision Changes How Agents Explore Under RL, arXiv:2609.20715v1, 2026. Polskie omówienie na podstawie pełnego tekstu udostępnionego na licencji CC BY 4.0.

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