Článok AWS opisuje prístup k vyhľadávaciemu agentovi, ktorý dostáva priestor rozhodovať sa počas viacerých interakčných kôl. Agent si autonómne volí, čo bude hľadať, ktorú stratégiu získavania informácií použije a kedy vyhľadávanie ukončí. Tréning sa preto zameriava na celú postupnosť rozhodnutí, nie iba na jednu izolovanú odpoveď. Výsledok každého kroku je súčasťou cesty, ktorá napokon vedie k získaným dokumentom.

Na tento účel článok predstavuje Amazon SageMaker AI MTRL, teda tréning s viacťahovým posilňovaním. Opisuje viacťahové rollouty, ktoré zachytávajú úplnú sekvenciu rozhodnutí agenta, a algoritmy policy gradient. MTRL podľa článku podporuje vlastné odmeny, slučky nástrojov a viacťahové tvary konverzácie. Súčasťou opísaného prostredia je serverless vykonávanie a asynchrónny zber rolloutov a trajektórií. Článok uvádza aj možnosti PPO, CISPO a straty založené na importance sampling, obnoviteľný tréning, pozorovateľnosť trajektórií a evaluačné úlohy.

Vyhľadávanie ako postupnosť rozhodnutí

V uvedenom nastavení agent pri každom kroku rozhoduje o ďalšom vyhľadávaní alebo o ukončení. Použité stratégie rozlišujú typ otázky: BM25 slúži na lexikálne vyhľadávanie presných výrazov alebo identifikátorov, zatiaľ čo vektorové vyhľadávanie sa používa pri sémantických alebo konceptuálnych otázkach. Tento príklad ukazuje, prečo môže byť tréning celej postupnosti dôležitý: postup zahŕňa voľbu stratégie, jej použitie v slučke nástrojov a rozhodnutie, či pokračovať.

Odmena v opísanom tréningu bola nDCG@10 na úrovni trajektórie. Vychádzala z toho, ako dobre sa konečné získané dokumenty zhodovali so známymi správnymi výsledkami. Takto zvolená odmena hodnotí konečný výsledok celej cesty vyhľadávania. Samotný popis však neznamená, že každý jednotlivý krok má rovnakú hodnotu alebo že jedna stratégia je vhodná pre všetky otázky; uvedený príklad naopak rozlišuje presné výrazy od sémantických požiadaviek.

Limity a výsledky uvedené v článku

Článok uvádza konkrétne podmienky, pri ktorých tréningový beh získal odmenu -1: dosiahnutie maximálneho počtu ťahov alebo limitu vzorkovacích tokenov pre jeden ťah. Zároveň menuje zmenené hyperparametre: max_epochs 1, global_batch_size 128 a rollout_max_concurrency 32. Tieto údaje opisujú uvedené nastavenie; samy osebe neurčujú univerzálne hodnoty pre iné úlohy.

Na štyroch odložených benchmarkoch sa podľa článku nDCG@10 zlepšilo na troch. BrowseComp-Plus zaznamenal nárast o 23,7 percenta a WixQA o 18,4 percenta. Wands dosiahol menší nárast, zatiaľ čo FreshStack zaznamenal mierny pokles. Pri BrowseComp-Plus článok uvádza aj pokles miery zlyhania z 22,89 percenta na 0,68 percenta. Výsledky teda zahŕňajú aj benchmark s regresiou a konkrétne čísla sa týkajú opísaného experimentu; neposkytujú dôkaz o rovnakom výsledku pri každej úlohe.

Odporúčaný postup

Pre tímy, ktoré chcú tento typ prístupu preskúmať, článok odporúča pripraviť súbor údajov v požadovanom formáte, určiť funkciu odmeny podľa metriky konkrétnej úlohy, začať s predvolenými konfiguráciami a potom vyhodnocovať a iterovať. Tieto kroky spájajú cieľ tréningu s tým, čo sa má napokon merať: ak sa odmena odvíja od výsledku získaných dokumentov, musí zodpovedať danej úlohe. Vyhodnocovanie a iterovanie umožňujú reagovať na pozorované výsledky, napríklad na rozdiel medzi zlepšením na BrowseComp-Plus a poklesom na FreshStack.

Hlavným praktickým rámcom článku je preto uvažovať o vyhľadávaní ako o sekvencii akcií a navrhovať tréning aj meranie na úrovni tejto sekvencie. MTRL poskytuje podľa opisu podporu pre vlastné odmeny, nástroje a zber trajektórií, zatiaľ čo výsledky benchmarkov ukazujú, že zmeny sa môžu líšiť podľa testovacej úlohy. Článok neuvádza, že každý agent alebo každá dátová sada dosiahne rovnaké zlepšenie. Zdôrazňuje prípravu údajov, odmenu naviazanú na cieľ a opakované vyhodnocovanie ako súčasti postupu.