# Trening agenta wyszukującego z wieloetapowym RL w Amazon SageMaker AI

- Source: MechNext — https://mechnext.eu/pl/article/29-training-a-search-agent-with-multi-turn-rl-on-amazon-sagemaker-ai
- Published: 2026-10-04
- Updated: 2026-10-04
- Category: Industry News
- Language: pl (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=zh, ?lang=ru)

> Artykuł AWS opisuje agenta, który w kolejnych turach wybiera wyszukiwania i narzędzia, oraz przedstawia wyniki na czterech testach odłożonych.

Artykuł AWS opisuje agenta wyszukującego, który podejmuje decyzje w wielu rundach interakcji. Agent samodzielnie wybiera, czego szukać, z której strategii wyszukiwania skorzystać i kiedy zakończyć. Dlatego podejście treningowe obejmuje pełną sekwencję decyzji, a nie tylko pojedynczą, odizolowaną odpowiedź. Każdy wybór należy do trajektorii, która ostatecznie prowadzi do pobranych dokumentów. Artykuł ujmuje trening agenta jako naukę całego procesu wyszukiwania.

Opisanym rozwiązaniem jest Amazon SageMaker AI MTRL, czyli uczenie ze wzmocnieniem prowadzone w wielu turach. Według artykułu MTRL trenuje agenta na wieloturowych rolloutach obejmujących pełną sekwencję decyzji oraz z użyciem algorytmów policy gradient. Obsługuje niestandardowe nagrody, pętle narzędzi i wieloturowe formy konwersacji. Opis obejmuje również wykonywanie bezserwerowe oraz asynchroniczne zbieranie rolloutów i trajektorii. Wśród wymienionych opcji algorytmicznych są PPO, CISPO i funkcje straty oparte na importance sampling. Artykuł wymienia także możliwość wznawiania treningu, obserwowalność trajektorii i zadania ewaluacyjne.

### Decyzje w trajektorii wyszukiwania

W opisanym ustawieniu agent może zdecydować o kolejnym wyszukiwaniu albo zakończyć działanie. Przykład rozróżnia strategie według rodzaju zapytania: wyszukiwanie leksykalne BM25 służy do znajdowania dokładnych terminów lub identyfikatorów, a wyszukiwanie wektorowe do zapytań semantycznych lub pojęciowych. To rozróżnienie ma znaczenie w przypadku agenta działającego w wielu krokach, ponieważ jego decyzje obejmują zarówno wybór strategii, jak i ocenę, czy potrzebny jest kolejny krok. Artykuł przedstawia te wybory jako sekwencję, a nie niezależne wyszukiwania.

Nagrodą w opisywanym treningu było nDCG@10 liczone na poziomie trajektorii. Zależało ono od tego, jak dobrze końcowe pobrane dokumenty odpowiadały wynikom referencyjnym. Wskazana nagroda odzwierciedla więc jakość dokumentów na końcu procesu wyszukiwania i wiąże cel treningu z jakością pobierania w opisanym eksperymencie. Nie oznacza to, że każdy krok ma identyczną wartość ani że BM25 lub wyszukiwanie wektorowe pasuje do każdego zapytania. Artykuł przypisuje te metody odpowiednio do dokładnych terminów oraz zapytań semantycznych lub pojęciowych.

### Limity treningu i podane wyniki

Artykuł informuje, że osiągnięcie maksymalnej liczby tur albo limitu tokenów próbkowania na turę skutkowało nagrodą -1. Wymienia też zmienione hiperparametry opisanego treningu: max_epochs wynosiło 1, global_batch_size 128, a rollout_max_concurrency 32. Są to szczegóły tej konfiguracji. Nie dowodzą, że te same limity i ustawienia będą odpowiednie dla każdego agenta lub zadania.

Na czterech testach odłożonych nDCG@10 poprawiło się według artykułu w trzech przypadkach. BrowseComp-Plus odnotował wzrost o 23,7%, a WixQA o 18,4%. Wands uzyskał mniejszy wzrost, natomiast FreshStack zanotował niewielkie pogorszenie. Dla BrowseComp-Plus podana częstość niepowodzeń spadła z 22,89% do 0,68%. Wyniki różnią się między wymienionymi testami: raport obejmuje zarówno poprawę, jak i pogorszenie. Są to rezultaty opisanej ewaluacji i nie dowodzą, że wszystkie zadania wyszukiwania przyniosą taki sam układ wyników.

### Praktyczny przebieg pracy

Artykuł zaleca przygotowanie zbioru danych w wymaganym formacie, zdefiniowanie funkcji nagrody opartej na metryce właściwej dla zadania, rozpoczęcie od konfiguracji domyślnych, a następnie ewaluację i iterowanie. Te kroki łączą konfigurację treningu z wynikiem, który zespół chce ocenić. Jeśli zadanie jest mierzone jakością pobranych dokumentów, nagroda powinna odzwierciedlać odpowiednią metrykę zadania. Ewaluacja i kolejne iteracje umożliwiają reagowanie na zaobserwowane wyniki, w tym na wzrosty w BrowseComp-Plus i WixQA oraz niewielkie pogorszenie w FreshStack.

Praktyczne ujęcie polega na traktowaniu wyszukiwania jako sekwencji działań i dopasowaniu do niej treningu oraz ewaluacji. Zgodnie z opisem MTRL wspiera niestandardowe nagrody, interakcje z narzędziami i zbieranie trajektorii, a wyniki testów pokazują, że zmiany mogą zależeć od zbioru ewaluacyjnego. Artykuł nie twierdzi, że każdy agent lub zbiór danych osiągnie takie same wzrosty. Zalecenia koncentrują się na przygotowaniu danych, nagrodzie powiązanej z metryką zadania i powtarzanej ewaluacji. Łącznie te elementy wyjaśniają, jak opisany trening wieloturowy wiąże decyzje wyszukiwawcze agenta z jakością ostatecznie pobranych dokumentów.