AWS trénovalo vyhľadávacieho agenta cez viac-krokové RL, zlyhania prudko klesli

Od ladenia jednej odpovede k celej trajektórii

AWS opísalo experiment, v ktorom pomocou viac-krokového posilňovaného učenia, označovaného MTRL, doladilo vyhľadávacieho agenta postaveného na modeli Qwen3.6-27B. Agent mal k dispozícii dve odlišné vyhľadávacie funkcie: lexikálne BM25 na presné výrazy a identifikátory a vektorové vyhľadávanie na významovo podobný obsah. Namiesto jedného dotazu mohol postupne meniť formuláciu, vyhodnocovať získané dokumenty a rozhodnúť, kedy má vyhľadávanie ukončiť. Tréning nehodnotil každý medzikrok osobitne. Odmenu priradil až celej trajektórii podľa kvality finálneho poradia nájdených dokumentov.

Práve závislosť medzi krokmi je problémom, ktorý jednoduché dolaďovanie často nezachytí. Supervised fine-tuning potrebuje ukážky ideálneho postupu: aký dotaz položiť ako prvý, čo urobiť po slabom výsledku a kedy prepnúť medzi nástrojmi. Takéto trajektórie sú drahé na ručnú prípravu a pre interný vyhľadávač spravidla neexistujú. Jednokrokové RL zasa vie ohodnotiť jednu odpoveď, ale ignoruje, že neskoršie rozhodnutie závisí od už získaných dokumentov. MTRL umožňuje agentovi skúšať celé sekvencie a optimalizovať ich podľa výsledku, ktorý sa dá zmerať až na konci.

AWS poskytuje túto formu tréningu v SageMaker AI ako spravovanú službu. Používateľ definuje agenta, jeho nástroje, tréningové dáta a odmeňovaciu funkciu, zatiaľ čo služba zabezpečuje generovanie trajektórií a aktualizáciu modelu. Podporované sú algoritmy vrátane PPO a CISPO, viaceré odhady výhody, paralelný zber behov, obnovovanie dlhších tréningov a sledovanie metrík v MLflow. Výpočty sú serverless a účtované podľa tokenov. To znižuje potrebu spravovať vlastný GPU klaster, nie však potrebu navrhnúť správne prostredie, metriku a bezpečnostné hranice nástrojov.

Ako AWS zostavilo tréning a odmenu

Experiment spojil niekoľko verejných tréningových datasetov s rozdielnym charakterom. FRAMES a Musique obsahujú otázky vyžadujúce viac krokov, BRIGHT sa zameriava na vyhľadávanie, pri ktorom relevantnosť nemožno určiť iba zhodou slov, Enterprise RAG simuluje interné podnikové dokumenty a ESCI predstavuje produktové vyhľadávanie. Súčasťou zmesi bol aj viacjazyčný MLQA. Päť percent tréningových príkladov z každého datasetu AWS odložilo na validáciu. Takáto kombinácia mala agenta naučiť širšiu stratégiu, nie zapamätanie jedného typu indexu alebo otázky.

Hlavnou odmenou bolo nDCG@10, bežné meradlo kvality poradia pri získavaní informácií. Hodnota zohľadňuje nielen to, či systém našiel relevantný dokument, ale aj to, ako vysoko ho umiestnil medzi prvými desiatimi výsledkami. Dokonalé poradie má skóre 1 a úplne nerelevantný výstup 0. Ak agent prekročil maximálny počet krokov alebo tokenový rozpočet jedného kroku, dostal odmenu mínus jeden. Tréning ho tak neučil iba hľadať presnejšie, ale aj dokončiť úlohu v stanovenom rozpočte. Ide o jednoduchý príklad, ako môže správne navrhnutá penalizácia cieliť na prevádzkové zlyhanie bez ručného opisovania každého nesprávneho postupu.

Konfigurácia zverejnená AWS používala jednu epochu, globálnu dávku 128 promptov a 32 súbežných rolloutov. Ostatné nastavenia ponechal tím na predvolených hodnotách služby. Takáto stručná konfigurácia je atraktívna, no nemala by vytvárať dojem, že viac-krokové RL je automaticky jednoduché. Pred spustením musel existovať agentový endpoint, ktorý počas tréningu sprístupňoval oba vyhľadávacie nástroje, dáta museli byť prevedené do očakávaného formátu a tím musel poznať správne hodnotenia relevantnosti. Najťažšia časť sa teda môže presunúť z algoritmu do prípravy prostredia a dôveryhodných evaluačných dát.

Výsledky: lepšie poradie aj menej nedokončených úloh

AWS porovnalo pôvodný model a jeho doladenú verziu na štyroch datasetoch, ktoré neboli použité na tréning. Na WixQA vzrástlo nDCG@10 z 0,5725 na 0,6781, čo AWS vyjadruje ako zlepšenie o 18,4 percenta. Na Wands skóre stúplo z 0,5762 na 0,6112, približne o šesť percent. Najväčšia zmena nastala na BrowseComp-Plus: z 0,5136 na 0,6354, teda o 23,7 percenta. Tento benchmark obsahoval 830 otázok a náročné vyhľadávanie nad približne stotisíc dokumentmi, preto je práve tento výsledok najsilnejším signálom, že tréning ovplyvnil viac než jeden jednoduchý typ dotazu.

Ešte výraznejší bol rozdiel v spoľahlivosti na BrowseComp-Plus. Pôvodný agent nedokončil v limite 22,89 percenta úloh, kým po doladení klesla miera zlyhania na 0,68 percenta. Priemerný počet krokov zároveň klesol zo 7,0 na 6,3. To naznačuje, že penalizácia za prekročenie rozpočtu naučila model uzatvoriť vyhľadávanie skôr a konzistentnejšie. Pre produkčný systém môže byť táto zmena dôležitejšia než samotný nárast priemernej relevance: agent, ktorý občas uviazne v slučke, prináša nepredvídateľnú latenciu, náklady a riziko vyčerpania limitov.

Výsledok však nebol jednotný. Na FreshStack kleslo nDCG@10 z 0,4112 na 0,4089, hoci miera zlyhania sa zlepšila z 0,20 na 0,05 percenta a priemerný počet krokov klesol z 3,1 na 2,8. Rozdiel v kvalite je malý, no ukazuje dôležitý kompromis: tréning na ukončenie úlohy a všeobecnú zmes vyhľadávacích dát nemusí zlepšiť každú doménu. FreshStack obsahuje čerstvé technické otázky zo Stack Overflow a dokumentácie, takže jeho distribúcia sa mohla od tréningovej zmesi líšiť. AWS nezverejnilo intervaly spoľahlivosti ani viacnásobné opakovania tréningu, preto nemožno určiť, nakoľko sú menšie rozdiely stabilné.

Praktický význam pre podnikové vyhľadávanie

Pre podnikový tím je zaujímavá najmä možnosť optimalizovať menší model priamo na vlastné nástroje a metriku. Univerzálny model môže rozumieť otázke, ale nemusí poznať syntax interného vyhľadávania, vhodný okamih na zmenu stratégie ani nákladové limity konkrétneho indexu. Agent trénovaný v cieľovom prostredí sa môže naučiť, že identifikátor zmluvy patrí do lexikálneho vyhľadávania, opis problému do vektorového indexu a ďalší krok už neprinesie dostatočný úžitok. Potenciálnym výsledkom je nižšia latencia a cena inferencie bez stáleho volania najväčšieho dostupného modelu.

Takýto tréning však potrebuje odmenu, ktorá naozaj reprezentuje firemný cieľ. nDCG@10 funguje, keď sú k dispozícii dôveryhodné hodnotenia relevantnosti. V internom prostredí môžu chýbať alebo zvýhodňovať dokumenty, ktoré používatelia historicky otvárali, nie tie, ktoré sú aktuálne a správne. Samostatne treba merať oprávnenia, čerstvosť, pokrytie zdrojov a výslednú odpoveď po vyhľadaní. Agent môže dosiahnuť vysoké skóre poradia a pritom sprístupniť dokument nesprávnej skupine alebo vytvoriť nepodloženú syntézu. RL optimalizuje zadanú metriku, nie širší zámer, ktorý v nej nie je vyjadrený.

Výsledky AWS sú preto dôkazom uskutočniteľnosti konkrétnej konfigurácie, nie univerzálnym benchmarkom všetkých vyhľadávacích agentov. Samostatná výskumná práca o dlhých viac-krokových vyhľadávacích agentoch podporuje širšiu hypotézu, že učenie z celých trajektórií a dlhší pracovný horizont môžu zlepšiť výkon. Ani tá však nerieši všetky produkčné otázky. Pred nasadením treba porovnať MTRL s jednoduchším SFT, kvalitnejším rerankerom, úpravou promptu aj neagentickým hybridným vyhľadávaním. Ak zisk vzniká prevažne z lepšieho ukončovania slučky, podobný efekt môže byť v niektorých prípadoch lacnejšie dosiahnuteľný explicitnými pravidlami.

Najrozumnejším čítaním experimentu je, že viac-krokové RL sa začína meniť z laboratórnej techniky na dostupnejšiu cloudovú súčasť vývoja agentov. AWS ukázalo merateľné zlepšenie na troch zo štyroch testov a dramatický pokles zlyhaní na najproblematickejšom benchmarku. Súčasne ponechalo otvorené otázky o nákladoch tréningu, opakovateľnosti výsledkov, prenose do konkrétnych podnikových dát a porovnaní s jednoduchšími alternatívami. Pre tímy, ktoré už majú evaluačné dáta a jasnú metriku, je MTRL relevantným experimentom. Bez nich môže iba presnejšie optimalizovať nesprávne zadaný cieľ.