Model uczony pojedynczych poprawek rozwija harness na nowym benchmarku

Asystent przeszukuje dokumenty, żeby odpowiedzieć na pytanie wymagające połączenia kilku faktów. Najpierw znajduje osobę, potem szuka informacji o jej działalności. Program przekazuje jednak do końcowej odpowiedzi tylko streszczenia znalezionych fragmentów. Jeśli streszczenie pominie potrzebną nazwę albo relację, model odpowiadający nie ma już dostępu do dowodu, choć wyszukiwarka go znalazła.

Inżynier chce poprawić jakość tego procesu. Może zmienić kod tak, żeby krótkie streszczenia nadal pomagały układać kolejne zapytania, ale końcowa odpowiedź korzystała także z oryginalnych fragmentów. Poprawia wtedy przepływ informacji między wywołaniami modelu.

Taka zmiana nie musi rozwiązać całego problemu. Nowe wykonania mogą ujawnić, że część pytań wymaga jeszcze jednego wyszukiwania. Kolejna poprawka powinna uwzględniać skutki poprzedniej, wraz z nowymi błędami, które po niej pozostały.

Można generować wiele wariantów początkowego programu albo rozwijać jedną z jego kolejnych wersji. W drugim przypadku zmieniają się zarówno kod przekazywany modelowi, jak i raport z wykonania. Powstaje pytanie: czy model nauczony poprawiania wyłącznie wersji początkowej będzie umiał pracować również na tych późniejszych stanach?

Model uczy się reguły poprawiania kodu

W badaniu model uczony pojedynczych poprawek początkowego programu potrafił dalej poprawiać go przez kolejne rundy na nowym benchmarku, przy zamrożonych wagach obu modeli podczas adaptacji. To najważniejszy wynik pracy Harness Learning Enables Generalizable Test-Time Adaptation Alvina Zhanga i współautorów. Jest to preprint zgłoszony po raz pierwszy 28 września 2026 roku, dotyczący agentów językowych, uczenia ze wzmocnieniem i adaptacji systemów wyszukujących odpowiedzi.

Harness to wykonywalny program organizujący wywołania modelu, narzędzia i przekazywanie informacji. Autorzy rozdzielają dwie role. Solver odpowiada na pytania w ramach tego programu. Proposer dostaje aktualny kod, opis zadania oraz raport z jego wykonania i proponuje zmianę. Raport obejmuje także poprawność odpowiedzi oraz znalezione i pominięte dokumenty wspierające odpowiedź. Proposer korzysta więc ze sprawdzonych przykładów; nie odkrywa skutecznych zmian bez informacji o wyniku.

W wariancie dla pytań wymagających kilku wyszukiwań proposer przechodzi trening GRPO: kilka proponowanych zmian zostaje uruchomionych, a ich wyniki służą do aktualizacji wag modelu proponującego poprawki. Solver pozostaje zamrożony. Nagroda zależy od trafności odpowiedzi poprawionego programu i zawiera dodatkowy składnik za poprawny, wykonywalny kod. Pytania użyte do oceniania kandydatów są oddzielone od pytań tworzących wejściowy raport.

Po treningu oba modele mają stałe wagi. Proposer nadal może proponować zmiany, ale adaptacja zapisuje się już w kodzie harnessu. To przykład meta-learning: trening ma wykształcić regułę dostosowywania się do kolejnych zadań.

W opisanych wcześniej Procedural Graphs system aktualizował graf wskazówek bez uczenia wag modeli. Tutaj autorzy uczą sam model proponujący poprawki i sprawdzają, czy wyuczona umiejętność działa na zadaniach oraz wersjach kodu niewidzianych w treningu.

Druga runda otrzymuje skutki pierwszej poprawki

Poniższy przykład jest własną ilustracją. Liczby pytań, kandydatów i sukcesów są umowne, nie pochodzą z eksperymentu.

Początkowy harness H0 odpowiada poprawnie na jedno z czterech pytań służących do wyboru wersji. Oddzielne dwa pytania dostarczają raportu: dokumenty zawierały potrzebne informacje, lecz końcowy solver czytał tylko streszczenia. Proposer tworzy trzy warianty H0, a każdy zostaje uruchomiony na tych samych czterech pytaniach oceniających.

Kandydat pierwszej rundy	Zmiana względem H0	Poprawne odpowiedzi
A	Końcowy solver czyta również oryginalne fragmenty	3 z 4
B	Program dodaje kolejne wyszukiwanie	2 z 4
C	Program usuwa drugie wyszukiwanie	0 z 4

Do dalszej pracy przechodzi A. Pozostałe warianty nie są jego rodzicami. System uruchamia A na pytaniach dostarczających raportu i pokazuje proposerowi nowe ślady: dostęp do fragmentów pomógł, ale pozostał problem pytań wymagających dodatkowego wyszukiwania. Druga trójka kandydatów powstaje już z A. W tej ilustracji dodanie kolejnego wyszukiwania daje cztery poprawne odpowiedzi, uproszczenie do jednego wywołania jedną, a powrót do samych streszczeń dwie. Wybrany program zachowuje więc zmianę z A i dodaje następny etap.

Powstało sześć propozycji i wykonano 24 odpowiedzi do oceny kandydatów, oprócz wykonań dostarczających raporty. W porównaniu niezależnym wszystkie sześć propozycji otrzymałoby H0 i jego początkowy raport. Pierwszy moment różnicy to przygotowanie wejścia dla czwartej propozycji: w sekwencji zawiera ono A oraz informacje o skutkach A.

W rzeczywistym protokole QA jedna runda generuje osiem kandydatów. Wygrywa wariant z najlepszym wynikiem na pytaniach przeznaczonych do wyboru, nawet jeśli uzyskał wynik niższy niż rodzic. Nie ma zatem gwarancji, że każda kolejna wersja będzie lepsza. Jeśli wszystkie propozycje nie przejdą wykonania, pozostaje dotychczasowy harness. Test końcowy używa osobnych pytań, które nie służą do wyboru wersji. Protokół adaptacji, Appendix D.3

Na MuSiQue kolejne rundy przewyższyły niezależne poprawki

W tym porównaniu proposerem był Qwen3-4B, wytrenowany na HotpotQA, a solverem zamrożony Qwen3-8B w trybie non-thinking, czyli bez generowania osobnego toku rozumowania. MuSiQue, zbiór pytań wymagających łączenia informacji z kilku fragmentów, nie występował w treningu proposera. Użyto końcowego checkpointu, czyli zapisu wag po 80 aktualizacjach GRPO. Wynik na MuSiQue nie służył do wyboru tego zapisu.

Exact match oznacza odsetek odpowiedzi zgodnych z odpowiedzią referencyjną po normalizacji, z uwzględnieniem dopuszczonych aliasów. Wyższa wartość oznacza więcej poprawnych końcowych odpowiedzi. Test obejmował 299 pytań.

Sposób tworzenia harnessu, ten sam proposer Single-step RL	Exact match na MuSiQue
Średnia wszystkich 80 niezależnych poprawek H0	0,1467
Najlepsza z tych 80 poprawek, wskazana po wynikach testu	0,2408
Średnia końcowych harnessów z czterech przebiegów po dziesięć rund	0,27 — wartość zaokrąglona w tekście pracy

W każdym przebiegu sekwencyjnym powstało 80 propozycji: po osiem w każdej rundzie. Końcowy wynik przewyższył nawet najlepszy wariant z puli niezależnej. Ten drugi wynik jest oracle: autorzy wskazali zwycięzcę, znając wyniki testu, czego nie można użyć jako reguły wyboru w rzeczywistym wdrożeniu. W sekwencji wybór korzystał z oddzielnych pytań sprawdzających. Wynik sekwencyjny, §5.3 i rys. 5, pula niezależna, tabela 24

Najistotniejsze jest to, czego proposer nie widział podczas treningu tego wariantu: późniejszych wersji harnessu. Uczył się wyłącznie poprawiania wersji początkowej, a mimo to pozostawał użyteczny po własnych wcześniejszych zmianach. Wynik wspiera transfer umiejętności poprawiania kodu do nowych stanów adaptacji i nowego benchmarku.

Nie izoluje jednak wpływu samej kolejności. Sekwencja dostaje nowe raporty z pośrednich programów, podczas gdy niezależne warianty korzystają z raportów H0. Cztery przebiegi sekwencyjne zużyły łącznie 320 propozycji. Zrównano liczbę propozycji na jeden przebieg, lecz nie całkowity koszt ani ilość feedbacku. Praca nie wykazuje więc, że sekwencja jest tańsza albo że przy identycznym budżecie tokenów zawsze wygra z próbami niezależnymi.

Szczegóły eksperymentu

Trening QA. Qwen3-4B zaczynał z modelu bazowego, bez etapu SFT, z włączonym thinking mode. Pula zawierała 2000 pytań HotpotQA. Wariant Single-step RL używał 320 kontekstów, zawsze z początkowym harnessem; cztery konteksty na aktualizację dały 80 aktualizacji. Dla każdego kontekstu sześć pytań tworzyło raport, a oddzielne 64 oceniały osiem kandydatów. Nagroda to exact match plus 0,1 za wariant spełniający warunki wykonania. Kod musiał dać się sparsować, definiować run, mieścić się w 200 liniach i ukończyć ocenę. Wyjątki oraz przekroczenie budżetu wywołań liczyły się jako błędne odpowiedzi. Raportowano checkpoint po ostatniej aktualizacji. Appendix D.2, tabela 23

Adaptacja i test MuSiQue. Pula do raportów i wyboru zawierała 500 pytań, oddzielonych od 299 pytań testowych. Korpus wyszukiwania obejmował 21 100 fragmentów z dokumentów wspierających odpowiedzi i dystraktorów udostępnionych w części development MuSiQue. Nie był to otwarty internet ani dowolny korpus produkcyjny. Początkowy harness wykonywał dwa etapy wyszukiwania i streszczania. Każda runda dostarczała sześciu pytań do raportu dla danego przebiegu oraz 64 pytań do wyboru, wspólnych dla czterech przebiegów i oddzielonych od pytań raportowych. Pytania development mogły powtarzać się między rundami. Appendix D.1–D.3

Koszt wykonania. Proposer generował osiem wariantów na rundę z temperature 1,0 i limitem odpowiedzi 10 240 tokenów. Solver korzystał z temperature 0,6, top-p 0,95 i top-k 20. Budżet jednego pytania dopuszczał 12 wywołań solvera i 12 wyszukiwań; wyszukiwanie zwracało najwyżej 20 fragmentów. Każdy kandydat wymagał oceny programu na pytaniach sprawdzających, a nowe raporty dodatkowych wykonań bieżącego harnessu. Po rundzie autorzy uruchamiali też cztery wybrane harnessy na całym teście do pomiaru, bez używania tych wyników do wyboru następnej wersji. Tabela 23 i Appendix D.3

Pula niezależna. Osiemdziesiąt propozycji powstało z czterech raportów pierwszej rundy, po 20 na raport. Wszystkie otrzymywały H0. Identyczne programy współdzieliły jedno wykonanie; błędy parsowania i kompilacji dostawały zero. Średnia uwzględnia wszystkie propozycje, a best-of-80 to maksimum wskazane po wyniku testu. Baseline początkowego harnessu mierzono osobno w ocenie niezależnej i sekwencyjnej, dlatego nie wyliczam przyrostu sekwencji względem wartości seed z tabeli 24. Appendix D.4

Zakres pracy. Autorzy badali także transfer QA do 2WikiMultihopQA oraz osobno syntetyczne zadania Reasoning Gym, z inną konfiguracją modeli i checkpointów. Wyników tych nie łączę z porównaniem MuSiQue. Trening na sekwencjach poprawek nie dawał konsekwentnej przewagi nad treningiem pojedynczych zmian. §5.4

Sprawdź poprawianie wersji pośrednich i dostępność etykiet

Badanie dotyczy konkretnego duetu modeli i krótkiego programu wyszukiwania. Proposer otrzymuje gotowe raporty z poprawnymi odpowiedziami i dokumentami wspierającymi odpowiedź. Sam nie wybiera kroków inspekcji kodu ani prób wykonania przed zgłoszeniem poprawki. Nie ustalono, jak dobrze ta umiejętność przenosi się na innego solvera, rozbudowanego agenta programistycznego czy proces pozbawiony wiarygodnego sprawdzania wyniku. Ograniczenia, Appendix F

Moja interpretacja inżynierska jest następująca: ocenianie modelu poprawiającego agentów wyłącznie na kodzie początkowym pomija ważną zdolność. Po udanej zmianie trzeba sprawdzić, czy model umie odczytać nowy raport i zaproponować użyteczną kolejną poprawkę. To pozostaje sensownym testem również wtedy, gdy użyjemy innej metody treningu niż harness learning.

Własny eksperyment powinien oddzielać pytania dostarczające raportu, pytania wybierające wersję oraz test, a koszt liczyć wraz ze wszystkimi ocenami kandydatów. Przed uruchomieniem automatycznej adaptacji warto ustalić, skąd będą pochodziły poprawne odpowiedzi do raportów, i porównać poprawki niezależne z sekwencyjnymi przy tej samej liczbie wywołań solvera i tokenów.

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