Multi-turn RL: agentų mokymasis prasideda tada, kai pokalbis nesibaigia

Svarbiausia

• Kas yra multi-turn RL? Tai mokymas, kai modelis vertinamas per kelių žingsnių sąveiką, o ne vieną atsakymą.
• Kam to reikia? Agentams, kurie dirba su įrankiais, ticketais, moderavimu ar kitais procesais.
• Kaip pradėti testuoti? Kurti scenarijus su klaidomis, trūkstama informacija ir žmogaus eskalacija.

multi-turn RL skamba kaip techninis terminas. Bet kai pažiūri praktiškai, čia yra labai žemiškas klausimas: kiek darbo darome rankomis tik todėl, kad niekas neprisėdo sutvarkyti proceso?

AWS aprašė gerąsias multi-turn reinforcement learning praktikas agentams, kurie turi spręsti užduotis per kelis žingsnius. Vienas atsakymas dar nieko neįrodo. Tikras darbas prasideda tada, kai agentas turi skaityti instrukcijas, kviesti įrankius, taisyti klaidas ir vis tiek nueiti iki rezultato.

Man tokiose naujienose visada įsijungia mažas vidinis buhalteris. Ne tas, kuris skaičiuoja sąskaitas, o tas, kuris klausia: kiek tai kainuos, kas prižiūrės ir kur gali lūžti?

Kas nutiko

Publikacijoje kalbama apie agentus, kurie sprendžia support ticketus ar moderuoja turinį. Jie turi atlikti veiksmų seką: suprasti užduotį, panaudoti įrankius, perskaityti rezultatus, priimti kitą sprendimą ir atsigauti, jei kažkas nepavyko.

Čia kaip pokalbis su darbuotoju pirmą savaitę. Jis gali gražiai atsakyti į klausimą, bet dar neaišku, ar susitvarkys, kai klientas pakeis nuomonę, sistema grąžins klaidą, o instrukcija bus parašyta kreivai.

Kodėl tai svarbu

Multi-turn RL svarbus todėl, kad agentai retai dirbs vienu žingsniu. Jie bus jungiami prie CRM, dokumentų, ticketų, mokėjimų, duomenų bazių. Kokybę reikės matuoti ne pagal gražų sakinį, o pagal visą užduoties kelią.

DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, moka kviesti servisus, gali veikti keliais žingsniais ir pradeda liesti tikrus verslo pinigus. Čia romantika baigiasi. Prasideda tvarka.

Ką tai reiškia verslui

Verslui tai reiškia, kad testai turi keistis. Screenshotas su geru atsakymu vadovų susitikime atrodo smagiai, bet produkcijoje reikia scenarijų: kas nutinka, kai trūksta duomenų, kai įrankis neveikia, kai naudotojas prieštarauja.

• testuoti kelis dialogo posūkius
• kurti klaidų scenarijus
• matuoti užduoties užbaigimą
• aiškiai nurodyti, kada agentas perduoda žmogui

Pavyzdys: support agentas turi ne tik atsakyti klientui. Jis turi rasti užsakymą, patikrinti statusą, pasiūlyti sprendimą ir įrašyti rezultatą sistemoje.

Kur pasislėpusi rizika

Rizika – agentą mokyti tik ant idealių pavyzdžių. Gyvenime idealūs pavyzdžiai greitai baigiasi. Tada pasimato, ar sistema moka atsistoti po klaidos.

Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl verslui reikia ne tik įrankių, bet ir įpročio tikrinti.

Ką pasidaryti šią savaitę

Paimkite vieną procesą ir parašykite penkis blogus scenarijus. Ne gerus. Blogus. Jie geriausiai parodys, ar agentas pasiruošęs.