Ar kada nors pastebėjote, kad konkreti užklausa veikia gerai, bet staiga nustoja veikti?
Ar kada nors įstrigote nuolat taisydami sistemos užklausą ir mėgindami pagerinti rezultatus, tačiau niekas nepadėjo?
Sistemos užklausos mokymasis gali būti kaip tik tai, ko jums reikia.
Sistemos užklausos mokymasis (SPL) yra vis daugiau dėmesio DI bendruomenėje sulaukianti sritis, kurią gegužę platformoje „X“ plačiai išpopuliarino Andrejus Karpathy.
Sistemos užklausos mokymasis padeda įveikti nelanksčių ir nepatikimų DI sistemų, pagrįstų nekintamomis sistemos užklausomis ar sunkiai valdomomis papildomo mokymo konfigūracijomis, trūkumus. Tai dar vienas būdas užtikrinti nuolatinį DI sistemų mokymąsi.
Prieš pradėdami trumpai apžvelkime užklausų rengimo pagrindus.
Kuriant agentą ar individualų modelį pirmiausia reikia parengti du pagrindinius komponentus:
Sistemos užklausą
Naudotojo užklausą
Sistemos užklausose nustatomos pagrindinės modelio elgsenos taisyklės. Individualiems DI sprendimams skirtos užklausos dažnai prasideda maždaug taip:
“You are an intelligent assistant. Your role is to perform <insert task here>.
You must not do (A), (B), or (C).”
O naudotojo užklausose paprastai pateikiamas naudotojo klausimas ir kita aktuali informacija, pavyzdžiui, jo laiko juosta bei nuostatos. Naudotojo užklausa galėtų atrodyti taip:
I’m in the capital city of Portugal. Can you suggest some things I can do tonight?
Didžiosioms DI laboratorijoms išleidus naujus modelius, sistemos užklausos dažnai nutekinamos, nes naudotojai apeina pokalbių robotų apribojimus ir atskleidžia jų vidines instrukcijas. Dabar daugelis šių sistemos užklausų surinktos vienoje populiarioje „GitHub“ saugykloje. Jos atskleidžia DI laboratorijų ilgainiui sukurtą „slaptą receptą“, skatinantį tinkamą modelių elgseną. Pavyzdžiui, neseniai nutekintoje GPT-5 sistemos užklausoje (atskleistoje per ChatGPT) yra apie 6 000 žodžių. Tai parodo, kiek žinių ir gairių reikia užkoduoti norint formuoti sistemos elgseną.
Tokios išsamios sistemos užklausos paprastai apima kelias pagrindines sritis, pavyzdžiui:
Paieškos instrukcijas
Įrankių apibrėžtis
Naudotojo nuostatas
Citavimo instrukcijas
Skubius žinomų problemų pataisymus
Praktiškai individualių DI sistemų kūrėjai testuodami ir tobulindami programas sistemos užklausas taiso rankiniu būdu, o šį procesą daugiausia grindžia vertinimais.
Kiti būdai valdyti modelio elgseną:
Užklausų inžinerija, įskaitant paieška papildytą generavimą (RAG), kuriuo valdoma modeliui pateikiama informacija
Papildomas mokymas (tiesioginis bazinių modelio svorių keitimas)
O jeigu modelio elgseną būtų galima paveikti kitaip? Įsivaizduokite sistemą, kuri, naudodama anksčiau sugeneruotas mintis, planus ir strategijas, dinamiškai mokosi ir tobulina savo sistemos užklausą. Savo rezultatams vertinti ji galėtų pasitelkti ir naudotojų atsiliepimus, ir LLM kaip vertintojo įvertinimus.
Pagalvokite apie nuolatinį verslo iššūkį, kurį norite automatizuoti naudodami agentinę sistemą. Veiksmingiems sprendimams reikia protavimo gebėjimų, pranokstančių paprastą darbo eigos automatizavimą. Tokiais atvejais būtina į DI sistemą įtraukti planų kūrimo komponentą. Taip sistema gali įvairiai dirbti su keliais agentais, atsižvelgdama į užduotį. Atskiri veiksmai gali apimti nurodymus, kaip pasitelkti kitus agentus smulkesnėms užduotims atlikti arba naudoti įrankius.
Pastaba. Agento įrankis – tai bet kokia išorinė funkcija, API ar išteklius, kurį DI agentas gali iškviesti, kad neapsiribotų tekstu ir atliktų realius veiksmus.
Galite modelio sistemos užklausą papildyti pradiniu planu, kuriame atkartojami logiški žmogaus veiksmai, nors LLM paprastai reikia konkretesnių nurodymų dėl įrankių naudojimo, rezultatų formato ir susijusių reikalavimų. Kartais optimali strategija nėra aiški arba sprendžiate problemą, kuri nebuvo vertinama iš naujo, nes anksčiau laikyta išspręsta. Čia ir praverčia sistemos užklausos mokymasis (SPL).
SPL iteracijomis tobulina sistemos užklausą, įtraukdamas anksčiau sukurtas strategijas. Kylant naujoms problemoms, sistema palaipsniui kaupia žinias ir tampa atsparesnė. Tai tarsi jūsų srities problemų sprendimo žinyno kūrimas.
SPL palaipsniui įtraukia iš naudotojų atsiliepimų gautas įžvalgas į sistemos užklausą. Sistemai bręstant galite aptikti pasikartojančių problemų, kurias įmanoma apibendrinti aukštesnio lygmens principais.
Išsamiau ir nuosekliai panagrinėkime, kaip vyksta šis procesas:
Pradėkite nuo naudotojo užklausos, kuria sistemos prašoma atlikti konkrečią užduotį.
Jei sistema sprendžia tik vieną problemą, galite rinktis „godųjį“ metodą ir atrinkti geriausiai įvertintas ankstesnių vykdymų strategijas. Arba galite skatinti paiešką imdami imtis iš skirstinio, kuriame pirmenybė teikiama gerai įvertintoms strategijoms, bet kartais įtraukiamos ir prasčiau įvertintos. Tai ypač naudinga, kai strategijas dar tik pradedate kaupti.
Įvairioms problemoms spręsti skirtose sistemose verta pridėti klasifikavimo sluoksnį arba taikyti įterpinius ir kosinuso panašumą – tuos pačius metodus, kurie paprastai naudojami RAG, – kad nustatytumėte tinkamus metodus. Tai padeda pasirinkti konkrečiai problemai tinkamas strategijas, pavyzdžiui, pritaikytas programavimo užduotims.
Pastaba. Įterpiniai, naudojami kartu su kosinuso panašumu, leidžia įvertinti dviejų informacijos dalių sąsają, todėl lengviau susieti dokumentus, užklausas ar idėjas, net jei jų formuluotės skiriasi.
Supaprastintos strategijų saugyklos programavimo problemoms spręsti pradinis pavyzdys.
Pastaba. Čia pateiktos „pradinės strategijos“ yra tik iliustracinės. Realiuose programavimo scenarijuose jas tobulintume toliau. Sprendžiant nišines verslo problemas, ilgainiui reikėtų surinkti papildomų įžvalgų.
Generation_id (atvirkštine tvarka) | Tema | Balas | Strategy_text | Paaiškinimas |
|---|---|---|---|---|
4 | programavimas | 1 | Supraskite problemą, apribojimus ir ribinius atvejus. Sukurkite algoritmą su tinkamomis duomenų struktūromis. Patikrinkite planą naudodami pavyzdžius ir invariantus. Parašykite aiškų ir lengvai skaitomą kodą. Patobulinkite pertvarkydami bei optimizuodami kodą ir galutinai suformatuokite. Įrankių naudojimas. Naudodami įrankį trumpai paaiškinkite, kodėl jo prireikė. | Sujungia stipriausius trijų toliau pateiktų strategijų elementus. |
3 | programavimas | 1 | Supraskite problemą, apribojimus ir ribinius atvejus. Sukurkite algoritmą su tinkamomis duomenų struktūromis. Patikrinkite planą naudodami pavyzdžius ir invariantus. Parašykite aiškų ir lengvai skaitomą kodą. Patobulinkite pertvarkydami bei optimizuodami kodą ir galutinai suformatuokite. | Visapusiškesnė strategija, tačiau joje nėra įrankių naudojimo gairių. |
2 | programavimas | -1 | Supraskite problemą, apribojimus ir ribinius atvejus. Sukurkite algoritmą naudodami tinkamus duomenis. Parašykite aiškų ir lengvai skaitomą kodą. Įrankių naudojimas: pasitelkę įrankį trumpai apibendrinkite, kodėl jį naudojote. | Geresnė strategija, kurioje paminėtas įrankių naudojimas, tačiau ją dar galima tobulinti. |
1 | programavimas | -1 | Peržvelkite problemą. Išspręskite problemą. Sukurkite minimalius testus. Pateikite bet ką, kas veikia. | Paminėti testai, tačiau bendra strategija silpna. |
3. Atrinkę N imčių, įtraukite jas į sistemos užklausą. Taip planų kūrimas grindžiamas ankstesniais ekspertų atsiliepimais, užuot leidus modeliui kurti planus pagal minimalias gaires. Skatinkite modelį „mąstyti nestandartiškai“ ir prireikus pridėti veiksmų, o ne tiesiog pažodžiui kopijuoti pavyzdines strategijas.
4. Naudodami dinamiškai sukurtą sistemos užklausą sugeneruokite naują strategiją naudotojo prašymui įvykdyti. Per šį procesą turėtų būti sukurtos papildomos užduotys, gerinančios galutinį rezultatą. Tikslas – kūrybiškumas: sujunkite stipriausius ankstesnių strategijų elementus, apibendrinkite sutampančius veiksmus ir prireikus pridėkite naujų naudingų veiksmų.
Pastaba. Atminkite, kad temperatūra yra parametras, kurį galima reguliuoti siekiant įvairesnių, mažiau nuspėjamų rezultatų. Tai naudinga, kai reikia kūrybiškumo. Kai temperatūra nėra nulinė, kiekvienas sugeneruotas planas gali skirtis.
5. Gavę modelio rezultatą, paprašykite žmogaus arba LLM vertintojo įvertinti jį pagal konkrečius gero jūsų problemos sprendimo kriterijus. Anksčiau minėto veiklų Portugalijoje pavyzdžio vertinimo kriterijai galėtų būti:
Glaustumas (atsakymas ne ilgesnis nei vienas sakinys)
Siūlomos veiklos aktualumas
Vietos tikslumas
6. Remdamiesi šiuo įvertinimu, kitu modeliu patobulinkite strategiją. Pasirenkamas grįžtamojo ryšio ciklas gali apimti žmonių įžvalgas ir padėti bendradarbiaujant tobulinti sistemą. Patobulintą strategiją išsaugokite duomenų bazėje kartu su tinkamais metaduomenimis, kad galėtumėte sekti versijas ir pakeitimus.
Tad kam tiek vargti? Rezultatus galėtumėte peržiūrėti rankiniu būdu ir atitinkamai pakoreguoti sistemos užklausą. Vis dėlto galingi protavimo modeliai gali tobulinti strategijas remdamiesi ir rezultato kontekstu, ir žmonių atsiliepimais. Nors žmonės lengvai pastebi paprastų metodų trūkumus, sudėtingose ir įvairesnes problemas sprendžiančiose sistemose juos nustatyti sunku bei vargina.
LLM dažnai reikia išsamių instrukcijų ir papildomų veiksmų, kad surinktų kontekstines žinias, kurias žmonės spręsdami problemą pasitelkia savaime. Sistemai plečiantis ir sprendžiant vis įvairesnes problemas, reikiamų užduočių skaičius gali sparčiai augti. Pavyzdžiui, programavimo užduotis sprendžiantys žmonės gali intuityviai suprasti aplinkinę kodo bazę, o LLM pirmiausia gali tekti „perskaityti“ kelis failus.
Kada tai naudinga. Įsivaizduokite, kad vadovaujate klientų aptarnavimo komandai, o DI agentas rūšiuoja užklausas. Ilgainiui SPL galėtų atrasti jūsų komandos nesvarstytą skirstymo metodą ir sumažinti aukštesniam lygiui perduodamų užklausų dalį.
Kada tai nenaudinga. Jei darbo eigą jau apibrėžia atitikties reikalavimai ar teisės aktai, pavyzdžiui, finansinių ataskaitų srityje, SPL vertė gali būti menka, nes kūrybiškumas tampa rizika, o ne pranašumu.
Kada tai naudinga. Dirbdami daug tyrimų reikalaujantį darbą, pavyzdžiui, rinkos analizės ar produktų strategijos srityje, galite bendradarbiauti su DI: tobulinti jo planus, papildyti rezultatus ir pritaikyti šiuos patobulinimus ateityje. Kiekviena sąveika didina sistemos veiksmingumą.
Kada tai nenaudinga. Jei komanda DI daugiausia naudoja paprastoms darbo eigoms, kurioms beveik nereikia žmogaus indėlio, pavyzdžiui, sąskaitoms apdoroti, bendradarbiavimo sąnaudos gali viršyti naudą.
Kada tai naudinga. Tarkime, pradedate veiklą naujame regione ir DI staiga turi atsakyti į klausimus apie vietos mokesčius. SPL leidžia greitai užkoduoti naujas taisykles ir euristikas vos joms atsiradus, todėl klaidos nesikartoja.
Kada tai nenaudinga. Jei aplinka nekinta, pavyzdžiui, susitikimų išrašus verčiant standartizuotomis santraukomis, nuolatinis prisitaikymas beveik nenaudingas.
Teoriškai visa tai skamba daug žadančiai, tačiau diegiant SPL kyla realių iššūkių. Toliau aptariame kelis svarbiausius:
Pradiniuose strategijų kūrimo etapuose pažanga dažnai sustoja: nauji rezultatai neplėtoja ankstesnių, todėl procesas sulėtėja. Paprastai tai lemia dvi pagrindinės problemos:
Sprendimas. Iš anksto užkoduokite visas turimas verslo žinias, kad sistema turėtų pakankamai išsamios informacijos.
Sprendimas. Sukurkite išsamią vertinimo skalę, apimančią kelis atsakymo aspektus, pavyzdžiui, tikslumą, aiškumą ir aktualumą, o imčių atranką koreguokite pagal šiuos signalus.
Jei sistema sukuria šimtus strategijų, bet gauna mažai grįžtamojo ryšio, leidžiančio atskirti geras nuo blogų, imčių atranka greitai tampa sunkiai valdoma. Sprendimas – atranka.
Tobulindami strategijų saugyklą atsižvelkite į šiuos aspektus:
Naudojimo trukmė. Atsisakykite strategijų, kai viršijamas nustatytas laikotarpis arba generacijų skaičius.
Balas. Pagal vertinimo skalę atmeskite strategijas, kurių rezultatai nuolat prasti. Derinant tai su naudojimo trukme išsaugomi tik tie metodai, kurių vertė ilgainiui pasitvirtina.
LLM vertinimas. Periodiškai vertinkite strategijas ir nustatykite, kurios nebeteikia unikalių įžvalgų, nes jų naudingi elementai tikriausiai jau perkelti į naujesnes versijas.
Sprendimas. Strategijų duomenų bazę laikykite gyva sistema: reguliariai ją valykite, kad liktų tik aktualios ir vertingos žinios.
Sistemos užklausos mokymasis dar tik pradedamas taikyti, tačiau jo potencialas milžiniškas. Įmonės, kurios pasikliauja vien nekintamomis užklausomis ar nesibaigiančiu papildomu mokymu, susidurs su pažįstamais ribotumais: nepatikimomis sistemomis, augančiomis išlaidomis ir beprasmėmis pastangomis. SPL leidžia ištrūkti iš šio ciklo kuriant sistemas, kurios ilgainiui tobulėja ir įtvirtina aukštesnio lygmens principus, o ne pavienius pataisymus.
SPL dar tik formuojasi, tačiau kryptis aiški: iš savęs mokytis gebančios sistemos aplenks tas, kurios to padaryti negali. Dabar metas eksperimentuoti, pradėti nuo mažų žingsnių, kaupti įžvalgas ir kurti pagrindą DI sistemoms, kurios tobulėja su kiekviena sąveika.