Sistēmas uzvedņu mācīšanās: jauna MI sistēmu paradigma

Vai jums kādreiz ir gadījies, ka konkrēta uzvedne darbojas labi, bet tad pēkšņi pārstāj darboties?

Vai esat nonācis nebeidzamā sistēmas uzvednes labošanas ciklā, cenšoties uzlabot rezultātus, taču nekas nedarbojas?

Iespējams, sistēmas uzvedņu mācīšanās ir tieši tas, kas jums vajadzīgs.

Sistēmas uzvedņu mācīšanās (SPL) ir jauns intereses virziens MI kopienā, ko maijā platformā X plaši popularizēja Andrejs Karpatijs.

Sistēmas uzvedņu mācīšanās novērš trūkumus neelastīgās un trauslās MI sistēmās, kuras paļaujas uz statiskām sistēmas uzvednēm vai grūti pārvaldāmiem pielāgošanas risinājumiem. Tā piedāvā vēl vienu veidu, kā MI sistēmās nodrošināt nepārtrauktu mācīšanos.

Pirms iedziļināmies, īsi pārskatīsim uzvedņu veidošanas pamatus.

Izstrādājot aģentu vai pielāgotu modeli, vispirms jāizveido divi galvenie komponenti:

1. Sistēmas uzvedne

2. Lietotāja uzvedne

Sistēmas uzvednes nosaka modeļa darbības pamatnoteikumus. Pielāgotiem MI risinājumiem tās bieži sākas aptuveni šādi:

“You are an intelligent assistant. Your role is to perform <insert task here>.

You must not do (A), (B), or (C).”

Savukārt lietotāja uzvednēs parasti ir lietotāja vaicājums un cita būtiska informācija, piemēram, laika josla un preferences. Lietotāja uzvedne varētu izskatīties šādi:

I’m in the capital city of Portugal. Can you suggest some things I can do tonight?

Pēc lielāko MI laboratoriju jauno modeļu izlaišanas sistēmas uzvedņu noplūdes ir kļuvušas ierastas, jo lietotāji apiet tērzēšanas robotu ierobežojumus, lai atklātu to pamatā esošās instrukcijas. Daudzas no šīm sistēmas uzvednēm tagad vienuviet apkopo populārs GitHub repozitorijs. Tās atklāj „slepeno recepti“, ko MI laboratorijas laika gaitā izstrādājušas, lai veicinātu atbilstošu modeļu darbību. Piemēram, nesen nopludinātajā GPT-5 sistēmas uzvednē (kas atklāta ChatGPT) ir aptuveni 6000 vārdu. Tas parāda, cik daudz zināšanu un norāžu jāiekodē, lai veidotu sistēmas darbību.

Šādas visaptverošas sistēmas uzvednes parasti aptver vairākas galvenās jomas, piemēram:

• Meklēšanas norādes

• Rīku definīcijas

• Lietotāja preferences

• Atsauču norādes

• Ātri labojumi zināmām problēmām

Praksē pielāgotu MI sistēmu izstrādātāji, testējot un pilnveidojot lietotnes, sistēmas uzvednes iteratīvi labo manuāli. Šo procesu galvenokārt virza novērtējumi.

Citi modeļa darbības virzīšanas veidi ir:

• Uzvedņu inženierija, tostarp izguvē papildināta ģenerēšana (RAG), kas kontrolē modelim sniegto saturu

• Pielāgošana (tieši mainot modeļa pamatā esošos svarus)

Bet ja nu modeļa darbību varētu ietekmēt citādi? Iztēlojieties sistēmu, kas dinamiski mācās un pilnveido savu sistēmas uzvedni, izmantojot iepriekš radītas domas, plānus un stratēģijas. Tā varētu novērtēt savus rezultātus, izmantojot gan lietotāju atsauksmes, gan LVM kā vērtētāja novērtējumus.

Padomājiet par pastāvīgu uzņēmējdarbības problēmu, kuru vēlaties automatizēt ar aģentu sistēmu. Efektīviem risinājumiem vajadzīga spriestspēja, kas pārsniedz vienkāršu darbplūsmu automatizāciju. Šādos gadījumos MI sistēmā ir būtiski iekļaut plānu ģenerēšanas komponentu. Tas ļauj sistēmai atkarībā no uzdevuma dažādos veidos sadarboties ar vairākiem aģentiem. Atsevišķos soļos var būt norādes par citu aģentu izmantošanu apakšuzdevumu veikšanai vai rīku lietošanu.

Piezīme. Aģenta rīks ir jebkura ārēja funkcija, API vai resurss, ko MI aģents var izsaukt, lai neaprobežotos ar tekstu un veiktu reālas darbības.

Varat izvēlēties modeļa sistēmas uzvedni „iesēt“ ar plānu, kas atbilst cilvēka veiktajiem loģiskajiem soļiem, lai gan LVM parasti vajag konkrētākas norādes par rīku lietošanu, rezultātu formātu un saistītajām prasībām. Dažkārt optimālā stratēģija var nebūt skaidra vai arī problēma nav atkārtoti izvērtēta, jo iepriekš tika uzskatīta par atrisinātu. Te noder sistēmas uzvedņu mācīšanās (SPL).

SPL iteratīvi uzlabo sistēmas uzvedni, tajā iekļaujot iepriekš ģenerētas stratēģijas. Rodoties jaunām problēmām, sistēma pakāpeniski uzkrāj zināšanas un kļūst noturīgāka. Uztveriet to kā rokasgrāmatas veidošanu problēmu risināšanai savā jomā.

SPL sistēmas uzvednē pakāpeniski iekļauj no lietotāju atsauksmēm gūtās atziņas. Sistēmai nobriestot, varat atklāt atkārtotas problēmas, no kurām iespējams izsecināt vispārīgākus augstāka līmeņa principus.

Aplūkosim tuvāk, kā šis process darbojas soli pa solim:

1. Sāciet ar lietotāja vaicājumu, lūdzot sistēmai izpildīt konkrētu uzdevumu.

2. 1. Ja sistēma risina tikai vienu problēmu, varat izmantot „alkatīgu“ pieeju, izvēloties iepriekšējo izpildes reižu visaugstāk novērtētās stratēģijas. Varat arī veicināt izpēti, veicot atlasi no sadalījuma, kas dod priekšroku augstu novērtētām stratēģijām, bet reizēm ietver arī zemāk novērtētās. Tas ir īpaši noderīgi, kad tikai sākat apkopot stratēģijas.

   2. Sistēmām, kas paredzētas dažādu problēmu risināšanai, apsveriet klasifikācijas slāņa pievienošanu vai izmantojiet iegultnes un kosinusa līdzību (tās pašas metodes, ko parasti izmanto RAG), lai noteiktu atbilstošās pieejas. Tas palīdz izvēlēties konkrētajai problēmai piemērotas stratēģijas, piemēram, programmēšanas uzdevumiem pielāgotas stratēģijas.

Piezīme. Iegultnes, kas izmantotas kopā ar kosinusa līdzību, ļauj noteikt divu informācijas vienību saistības ciešumu. Tādējādi dokumentus, vaicājumus vai idejas var vieglāk salāgot pat tad, ja to precīzais formulējums atšķiras.

Vienkāršotas programmēšanas problēmu stratēģiju krātuves sākuma piemērs.

Piezīme. Šeit parādītās „sākotnējās stratēģijas“ ir tikai ilustratīvas. Reālos programmēšanas scenārijos mēs tās pilnveidotu tālāk. Specifiskām uzņēmējdarbības problēmām laika gaitā būtu jāapkopo papildu atziņas.

3. Pēc N elementu atlases iekļaujiet tos sistēmas uzvednē. Tādējādi plānu ģenerēšana balstās uz iepriekšējām ekspertu atsauksmēm, nevis modelis veido plānus ar minimālām norādēm. Mudiniet modeli „domāt ārpus ierastajiem rāmjiem“ un vajadzības gadījumā pievienot soļus, nevis vienkārši vārds vārdā kopēt stratēģiju paraugus.

4. Izmantojot dinamiski izveidoto sistēmas uzvedni, ģenerējiet jaunu stratēģiju lietotāja pieprasījuma izpildei. Šajā procesā būtu jārada papildu uzdevumi, kas uzlabo gala rezultātu. Mērķis ir radošums: apvienojiet iepriekšējo stratēģiju spēcīgākos elementus, sapludiniet soļus, kas pārklājas, un vajadzības gadījumā pievienojiet jaunus noderīgus soļus.

Piezīme. Atcerieties, ka temperatūra ir parametrs, ko var pielāgot, lai iegūtu daudzveidīgākus un mazāk determinētus rezultātus; tas noder, ja vajadzīgs radošums. Ja temperatūra nav nulle, katrs ģenerētais plāns var atšķirties.

5. Kad saņemts modeļa rezultāts, lūdziet to novērtēt cilvēkam vai LVM vērtētājam pēc konkrētiem kritērijiem, kas nosaka labu jūsu problēmas risinājumu. Iepriekš minētajā Portugāles aktivitāšu piemērā vērtēšanas kritēriji varētu būt:

• Īsums (atbilde nepārsniedz vienu teikumu)

• Ieteiktās aktivitātes atbilstība

• Atrašanās vietas precizitāte

6. Pamatojoties uz šo novērtējumu, pilnveidojiet stratēģiju ar citu modeli. Papildu atgriezeniskās saites ciklā var iekļaut cilvēku ieguldījumu un kopīgu pilnveidošanu. Saglabājiet pilnveidoto stratēģiju datubāzē kopā ar atbilstošiem metadatiem, lai izsekotu versijas un izmaiņas.

Kādēļ gan tā pūlēties? Jūs varētu rezultātus pārskatīt manuāli un attiecīgi pielāgot sistēmas uzvedni. Tomēr jaudīgi spriestspējas modeļi var pilnveidot stratēģijas, izmantojot gan rezultāta kontekstu, gan cilvēku atsauksmes. Vienkāršu pieeju trūkumus cilvēki pamana viegli, taču sarežģītās sistēmās, kas risina plašāku problēmu loku, to konstatēšana kļūst grūta un nogurdinoša.

LVM bieži vajag detalizētas norādes un papildu soļus, lai iegūtu kontekstuālās zināšanas, kuras cilvēki problēmas risināšanā izmanto dabiski. Sistēmai aptverot arvien plašāku problēmu loku, vajadzīgo uzdevumu skaits var strauji pieaugt. Piemēram, cilvēki, risinot programmēšanas uzdevumus, apkārtējo kodu bāzi var izprast intuitīvi, bet LVM, iespējams, vispirms „jāizlasa“ vairāki faili.

• Kad tas palīdz. Iedomājieties, ka vadāt klientu atbalsta komandu un MI aģents šķiro pieteikumus. Laika gaitā SPL varētu atklāt jūsu komandai nezināmu kategorizēšanas metodi, tā samazinot tālāk nodoto gadījumu skaitu.

• Kad tas nepalīdz. Ja darbplūsmas jau nosaka atbilstības prasības vai noteikumi, piemēram, finanšu pārskatu jomā, SPL var sniegt maz ieguvumu, jo radošums kļūst par risku, nevis priekšrocību.

• Kad tas palīdz. Pētniecības ietilpīgos amatos, piemēram, tirgus izpētē vai produktu stratēģijā, varat sadarboties ar MI, pilnveidojot tā plānus, bagātinot rezultātus un saglabājot uzlabojumus turpmākai izmantošanai. Katra mijiedarbība uzlabo sistēmas efektivitāti.

• Kad tas nepalīdz. Ja komanda MI galvenokārt izmanto vienkāršās darbplūsmās, kur cilvēku ieguldījums ir minimāls, piemēram, rēķinu apstrādē, sadarbības izmaksas var pārsniegt ieguvumu.

• Kad tas palīdz. Pieņemsim, ka sākat darbību jaunā reģionā un MI pēkšņi jāapstrādā jautājumi par vietējiem nodokļiem. SPL ļauj ātri iekodēt jaunus noteikumus un heiristikas, tiklīdz tie rodas, novēršot atkārtotas kļūdas.

• Kad tas nepalīdz. Ja vide ir statiska, piemēram, sapulču atšifrējumus pārvēršot standartizētos kopsavilkumos, pastāvīga pielāgošanās sniedz minimālu ieguvumu.

Teorētiski tas viss izklausās daudzsološi, taču SPL ieviešana rada reālus izaicinājumus. Tālāk aplūkojam dažus no galvenajiem izaicinājumiem:

Stratēģiju ģenerēšanas sākumposmā progress bieži apstājas: jaunie rezultāti nebalstās uz iepriekšējiem, un virzība palēninās. To parasti izraisa divas galvenās problēmas:

• • Risinājums. Jau sākumā iekodējiet visas pieejamās uzņēmuma zināšanas, lai sistēmai būtu plašs pamats.

• • Risinājums. Izveidojiet niansētu vērtēšanas sistēmu, kas novērtē vairākus atbildes aspektus, piemēram, precizitāti, skaidrību un atbilstību, un pielāgojiet atlasi šiem signāliem.

Ja sistēma ģenerē simtiem stratēģiju, bet saņem pārāk maz atsauksmju, lai atšķirtu labās no sliktajām, atlase ātri kļūst grūti pārvaldāma. Risinājums ir atsijāšana.

Pilnveidojot stratēģiju krātuvi, ņemiet vērā:

• Kalpošanas laiku. Pārtrauciet izmantot stratēģijas, kad tās pārsniedz noteikto termiņu vai paaudžu skaitu.

• Vērtējumu. Izmantojiet vērtēšanas sistēmu, lai atsijātu stratēģijas, kuru sniegums pastāvīgi ir zems. Apvienojot to ar kalpošanas laika ierobežojumu, saglabāsiet tikai tās pieejas, kas laika gaitā ir pierādījušas savu vērtību.

• LVM vērtēšanu. Regulāri izvērtējiet stratēģijas, lai noteiktu tās, kas vairs nesniedz unikālas atziņas, jo to noderīgie elementi, visticamāk, jau ir iekļauti jaunākās versijās.

Risinājums. Uztveriet stratēģiju datubāzi kā dzīvu sistēmu: regulāri to atsijājiet, lai paliktu tikai būtiskas un vērtīgas zināšanas.

Sistēmas uzvedņu mācīšanās joprojām ir agrīnā attīstības posmā, taču tās potenciāls ir milzīgs. Uzņēmumi, kas paļaujas tikai uz statiskām uzvednēm vai nebeidzamu pielāgošanu, saskarsies ar ierastajiem ierobežojumiem: trauslām sistēmām, augošām izmaksām un izšķiestu darbu. SPL piedāvā izeju no šī cikla, veidojot sistēmas, kas laika gaitā uzlabojas un atsevišķu labojumu vietā iekodē augstāka līmeņa principus.

SPL vēl tikai attīstās, taču virziens ir skaidrs: sistēmas, kas spēj mācīties pašas no sevis, pārspēs tās, kuras to nespēj. Tagad ir īstais laiks eksperimentēt, sākt ar mazumiņu, apkopot gūtās atziņas un likt pamatus MI sistēmām, kas uzlabojas ar katru mijiedarbību.