Onko jokin kehote ensin toiminut hyvin mutta lakannut yhtäkkiä toimimasta?
Oletko jäänyt jatkuvasti paikkaamaan järjestelmäkehotettasi tulosten parantamiseksi, vaikka mikään ei tunnu toimivan?
Järjestelmäkehotteen oppiminen voi olla juuri tarvitsemasi ratkaisu.
Järjestelmäkehotteen oppiminen (SPL) on tekoäly-yhteisössä kasvava kiinnostuksen kohde, jonka Andrej Karpathy teki laajalti tunnetuksi X:ssä toukokuussa.
Järjestelmäkehotteen oppiminen auttaa ratkaisemaan joustamattomien ja hauraiden tekoälyjärjestelmien rajoitteita, joita staattiset järjestelmäkehotteet tai kömpelöt hienosäätöratkaisut aiheuttavat. Se tarjoaa uuden tavan tukea tekoälyjärjestelmien jatkuvaa oppimista.
Ennen kuin syvennymme aiheeseen, kerrataan lyhyesti kehottamisen perusteet.
Agenttia tai mukautettua mallia kehitettäessä on ensin suunniteltava kaksi keskeistä osaa:
Järjestelmäkehote
Käyttäjäkehote
Järjestelmäkehotteet määrittävät mallin toiminnan perussäännöt. Mukautettujen tekoälyratkaisujen järjestelmäkehotteet alkavat usein esimerkiksi näin:
“You are an intelligent assistant. Your role is to perform <insert task here>.
You must not do (A), (B), or (C).”
Sen sijaan käyttäjäkehotteet sisältävät yleensä käyttäjän kysymyksen ja muita olennaisia tietoja, kuten aikavyöhykkeen ja mieltymykset. Käyttäjäkehote voisi olla tällainen:
I’m in the capital city of Portugal. Can you suggest some things I can do tonight?
Järjestelmäkehotteiden vuotamisesta on tullut yleistä suurten tekoälylaboratorioiden uusien mallijulkaisujen jälkeen, kun käyttäjät kiertävät chatbottien rajoituksia paljastaakseen niiden taustalla olevat ohjeet. Suosittu GitHub-repositorio kokoaa nykyään monia näistä järjestelmäkehotteista yhteen paikkaan. Ne paljastavat tekoälylaboratorioiden ajan mittaan kehittämän ”salaisen reseptin”, jolla malleja ohjataan toimimaan asianmukaisesti. Esimerkiksi äskettäin vuotanut GPT-5:n järjestelmäkehote (joka paljastui ChatGPT:ssä) sisältää noin 6 000 sanaa. Tämä havainnollistaa, kuinka paljon tietoa ja ohjeistusta järjestelmän toiminnan muovaaminen vaatii.
Näissä kattavissa järjestelmäkehotteissa käsitellään yleensä useita keskeisiä alueita, kuten:
Hakuohjeet
Työkalujen määritelmät
Käyttäjän mieltymykset
Lähdeviitteitä koskevat ohjeet
Tunnettujen ongelmien pikakorjaukset
Käytännössä mukautettujen tekoälyjärjestelmien kehittäjät paikkaavat järjestelmäkehotteita manuaalisesti ja vaiheittain testatessaan ja hioessaan sovelluksiaan. Parannustyötä ohjaavat pääasiassa arvioinnit.
Mallin toimintaa voidaan ohjata myös seuraavilla tavoilla:
Kehotemuotoilu, mukaan lukien hakua hyödyntävä generointi (RAG), jolla hallitaan mallille annettavaa sisältöä
Hienosäätö (mallin taustalla olevien painojen muuttaminen suoraan)
Entä jos mallin toimintaan voisi vaikuttaa jollakin muulla tavalla? Kuvittele järjestelmä, joka oppii ja hioo omaa järjestelmäkehotettaan dynaamisesti aiemmin tuottamiensa ajatusten, suunnitelmien ja strategioiden pohjalta. Se voisi arvioida tuotoksiaan sekä käyttäjäpalautteen että suuren kielimallin tekemien arviointien avulla.
Ajattele jatkuvaa liiketoiminnan haastetta, jonka haluat automatisoida agenttipohjaisella järjestelmällä. Tehokkaat ratkaisut edellyttävät päättelykykyä, joka ylittää työnkulkujen perusautomaation. Tällöin tekoälyjärjestelmään on olennaista sisällyttää suunnitelmia tuottava osa. Näin järjestelmä voi työskennellä eri tavoin useiden agenttien kanssa tehtävän mukaan. Yksittäisiin vaiheisiin voi sisältyä ohjeita muiden agenttien käyttämisestä osatehtävien suorittamiseen tai työkalujen käyttämisestä.
Huomautus: Agentin työkalu on mikä tahansa ulkoinen toiminto, API tai resurssi, jota tekoälyagentti voi kutsua ylittääkseen pelkän tekstin tuottamisen ja suorittaakseen todellisia toimia.
Voit päättää ”alustaa” mallin järjestelmäkehotteen suunnitelmalla, joka noudattaa ihmisen loogisesti valitsemia vaiheita. Suuret kielimallit tarvitsevat kuitenkin yleensä täsmällisempiä ohjeita työkalujen käytöstä, tulostusmuodosta ja muista vaatimuksista. Joskus paras strategia ei ole selvä, tai saatat käsitellä ongelmaa, jota ei ole arvioitu uudelleen, koska sitä pidettiin aiemmin ratkaistuna. Tässä järjestelmäkehotteen oppiminen (SPL) astuu kuvaan.
SPL parantaa järjestelmäkehotetta vaiheittain sisällyttämällä siihen aiemmin luotuja strategioita. Uusien ongelmien ilmaantuessa järjestelmä kartuttaa vähitellen tietoa ja muuttuu vankemmaksi. Ajattele sitä oman alasi ongelmanratkaisukäsikirjan rakentamisena.
SPL sisällyttää käyttäjäpalautteesta saadut oivallukset vähitellen järjestelmäkehotteeseen. Järjestelmän kypsyessä saatat tunnistaa toistuvia ongelmia, jotka voidaan kiteyttää yleisemmiksi, ylemmän tason periaatteiksi.
Tarkastellaan prosessin toimintaa vaihe vaiheelta:
Aloita käyttäjän kyselystä, jossa järjestelmää pyydetään suorittamaan tietty tehtävä.
Jos järjestelmäsi ratkaisee vain yhtä ongelmaa, voit käyttää ”ahnetta” lähestymistapaa ja valita aiempien suoritusten parhaat pisteet saaneet strategiat. Vaihtoehtoisesti voit kannustaa tutkimaan eri vaihtoehtoja tekemällä otannan jakaumasta, joka suosii korkealle arvioituja strategioita mutta sisältää ajoittain myös heikommin arvioituja. Tämä on erityisen hyödyllistä, kun strategioiden kerääminen on vasta alussa.
Erilaisia ongelmakokonaisuuksia käsittelevissä järjestelmissä kannattaa harkita luokittelukerroksen lisäämistä tai upotusten ja kosinisamankaltaisuuden käyttämistä olennaisten lähestymistapojen tunnistamiseen. Samoja tekniikoita käytetään yleensä RAG:ssa. Näin voit valita kyseiseen ongelmaan sopivia strategioita, kuten ohjelmointitehtäviin räätälöityjä strategioita.
Huomautus: Upotusten ja kosinisamankaltaisuuden avulla voidaan mitata kahden tiedon välistä yhteyttä. Näin asiakirjojen, kyselyiden tai ideoiden vastaavuus on helpompi tunnistaa, vaikka niiden sanamuodot eroaisivat toisistaan.
Esimerkki ohjelmointiongelmien ratkaisemiseen tarkoitetun yksinkertaisen strategiavaraston lähtötilanteesta.
Huomautus: Tässä esitetyt ”alkustrategiat” ovat vain havainnollistavia. Todellisissa ohjelmointitilanteissa niitä hiottaisiin pidemmälle. Erikoistuneet liiketoimintaongelmat edellyttäisivät lisähavaintojen keräämistä ajan mittaan.
Sukupolven_tunnus (käänteinen järjestys) | Aihe | Pistemäärä | Strategian_teksti | Selitys |
|---|---|---|---|---|
4 | ohjelmointi | 1 | Ymmärrä ongelma, rajoitteet ja reunatapaukset. Suunnittele algoritmi käyttäen sopivia tietorakenteita. Validoi suunnitelma esimerkkien ja invarianttien avulla. Toteuta siistiä ja helppolukuista koodia. Hio lopputulosta refaktoroimalla, optimoimalla ja viimeistelemällä muotoilu. Työkalujen käyttö: Kun käytät työkalua, selitä lyhyesti, miksi sitä tarvittiin. | Sisältää ja yhdistelee kolmen jäljempänä olevan strategian parhaat osat. |
3 | ohjelmointi | 1 | Ymmärrä ongelma, rajoitteet ja reunatapaukset. Suunnittele algoritmi käyttäen sopivia tietorakenteita. Validoi suunnitelma esimerkkien ja invarianttien avulla. Toteuta siistiä ja helppolukuista koodia. Hio lopputulosta refaktoroimalla, optimoimalla ja viimeistelemällä muotoilu. | Tasapainoisempi strategia, mutta se ei sisällä ohjeita työkalujen käytöstä. |
2 | ohjelmointi | -1 | Ymmärrä ongelma, rajoitteet ja reunatapaukset. Suunnittele algoritmi käyttäen oikeita tietoja. Toteuta siistiä ja helppolukuista koodia. Työkalujen käyttö: kun käytät työkaluja, kerro lyhyesti, miksi käytit kyseistä työkalua. | Parempi strategia, jossa mainitaan työkalujen käyttö mutta jossa on vielä parannettavaa. |
1 | ohjelmointi | -1 | Silmäile ongelma. Ratkaise ongelma. Luo suppeat testit. Lähetä mikä tahansa toimiva ratkaisu. | Mainitsee testit, mutta kokonaisstrategia on heikko. |
3. Kun olet poiminut N strategiaa, sisällytä ne järjestelmäkehotteeseen. Näin suunnitelmien luonti perustuu aiempaan asiantuntijapalautteeseen sen sijaan, että malli joutuisi laatimaan suunnitelmia vähäisen ohjeistuksen varassa. Kannusta mallia ”ajattelemaan laatikon ulkopuolelta” ja lisäämään tarvittaessa vaiheita sen sijaan, että se vain kopioisi esimerkkistrategiat sanatarkasti.
4. Luo dynaamisesti laaditun järjestelmäkehotteen avulla uusi strategia käyttäjän pyynnön käsittelemiseksi. Tämän prosessin pitäisi tuottaa lisätehtäviä, jotka parantavat lopullista tuotosta. Tavoitteena on luovuus: yhdistä aiempien strategioiden parhaat osat, kokoa päällekkäiset vaiheet yhteen ja lisää tarvittaessa hyödyllisiä uusia vaiheita.
Huomautus: Muista, että lämpötila on parametri, jota säätämällä voidaan tuottaa vaihtelevampia ja vähemmän deterministisiä tuloksia. Tästä on hyötyä, kun tavoitellaan luovuutta. Kun lämpötila ei ole nolla, jokainen luotu suunnitelma voi olla erilainen.
5. Kun olet saanut mallin tuotoksen, anna ihmisen tai suuren kielimallin arvioida se niiden kriteerien perusteella, jotka määrittävät ongelmasi hyvän ratkaisun. Aiemmin mainitussa Portugalin aktiviteetteja koskevassa esimerkissä arviointikriteerejä voisivat olla:
Tiiviys (vastaus on rajattu yhteen virkkeeseen)
Ehdotetun aktiviteetin osuvuus
Sijainnin oikeellisuus
6. Hio strategiaa tämän arvioinnin perusteella toisella mallilla. Valinnaiseen palautesilmukkaan voidaan sisällyttää ihmisten näkemyksiä ja yhteistä kehitystyötä. Tallenna hiottu strategia tietokantaan asianmukaisine metatietoineen, jotta versioita ja muutoksia voidaan seurata.
Miksi nähdä kaikki tämä vaiva? Voisit tarkistaa tuotokset manuaalisesti ja muokata järjestelmäkehotetta niiden perusteella. Tehokkaat päättelymallit voivat kuitenkin hioa strategioita sekä tuotoksen kontekstin että ihmisten palautteen avulla. Ihmisten on helppo havaita yksinkertaisten lähestymistapojen puutteet, mutta laajoja ongelmakokonaisuuksia käsittelevissä monimutkaisissa järjestelmissä niiden tunnistamisesta tulee vaikeaa ja työlästä.
Suuret kielimallit tarvitsevat usein yksityiskohtaisia ohjeita ja lisävaiheita kerätäkseen kontekstitietoa, jonka ihmiset tuovat ongelmanratkaisuun luontevasti. Tarvittavien tehtävien määrä voi kasvaa nopeasti, kun järjestelmä laajenee käsittelemään suurempia ongelmakokonaisuuksia. Esimerkiksi ohjelmointiongelmia ratkaiseva ihminen saattaa ymmärtää ympäröivän koodikannan vaistonvaraisesti, kun taas suuren kielimallin on ehkä ensin ”luettava” useita tiedostoja.
Milloin siitä on hyötyä: Kuvittele johtavasi asiakastukitiimiä, jossa tekoälyagentti lajittelee tukipyynnöt. Ajan mittaan SPL saattaa löytää luokittelumenetelmän, jota tiimisi ei ollut tullut ajatelleeksi, ja vähentää näin eskalointeja.
Milloin siitä ei ole hyötyä: Jos vaatimustenmukaisuus tai sääntely määrittää työnkulut jo valmiiksi, kuten talousraportoinnissa, SPL:stä voi olla vain vähän hyötyä, sillä luovuus muuttuu edun sijasta riskiksi.
Milloin siitä on hyötyä: Tutkimuspainotteisissa tehtävissä, kuten markkinatiedon tai tuotestrategian parissa, voit tehdä yhteistyötä tekoälyn kanssa hiomalla sen suunnitelmia, rikastamalla sen tuotoksia ja hyödyntämällä parannuksia myöhemmin. Jokainen vuorovaikutustilanne parantaa järjestelmän tehokkuutta.
Milloin siitä ei ole hyötyä: Jos tiimisi käyttää tekoälyä lähinnä suoraviivaisiin työnkulkuihin, joissa ihmisiltä tarvitaan vain vähän panosta, kuten laskujen käsittelyyn, yhteistyön vaatima työ voi ylittää sen hyödyt.
Milloin siitä on hyötyä: Oletetaan, että laajennat toimintaasi uudelle alueelle ja tekoälyn on yhtäkkiä vastattava paikallisia veroja koskeviin kysymyksiin. SPL:n avulla voit sisällyttää uudet säännöt ja heuristiikat nopeasti järjestelmään sitä mukaa kuin niitä ilmenee, mikä ehkäisee toistuvia virheitä.
Milloin siitä ei ole hyötyä: Jos toimintaympäristösi ei muutu, kuten muunnettaessa kokoustallenteita vakiomuotoisiksi yhteenvedoiksi, jatkuvasta mukautumisesta on vain vähän hyötyä.
Teoriassa tämä kaikki vaikuttaa lupaavalta, mutta SPL:n käyttöönottoon liittyy todellisia haasteita. Seuraavassa käsittelemme niistä tärkeimpiä:
Strategioiden luonnin alkuvaiheessa edistyminen usein pysähtyy: uudet tuotokset eivät kehitä aiempia eteenpäin, ja eteneminen hidastuu. Tähän on yleensä kaksi pääsyytä:
Ratkaisu: Sisällytä kaikki käytettävissä oleva liiketoimintatieto järjestelmään heti alussa, jotta sillä on riittävästi syvällistä tietoa hyödynnettäväksi.
Ratkaisu: Laadi monipuolinen arviointikehikko, joka pisteyttää vastauksen eri osa-alueita, kuten oikeellisuutta, selkeyttä ja osuvuutta, ja mukauta otantaa näiden signaalien perusteella.
Jos järjestelmä tuottaa satoja strategioita mutta saa vain vähän palautetta hyvien erottamiseksi huonoista, otannasta tulee nopeasti vaikeasti hallittavaa. Ratkaisu on karsiminen.
Kun hiot strategiavarastoasi, ota huomioon seuraavat seikat:
Elinkaari: Poista strategiat käytöstä, kun niiden määritetty aikaraja tai sukupolvien määrä ylittyy.
Pistemäärä: Suodata arviointikehikon avulla pois strategiat, jotka menestyvät jatkuvasti heikosti. Kun tähän yhdistetään elinkaaren seuranta, säilytät vain lähestymistavat, jotka osoittavat arvonsa ajan mittaan.
Suuren kielimallin arviointi: Arvioi strategioita säännöllisesti ja tunnista ne, jotka eivät enää tarjoa ainutlaatuisia oivalluksia, sillä niiden hyödylliset osat on todennäköisesti jo omaksuttu uudempiin versioihin.
Ratkaisu: Käsittele strategiatietokantaa elävänä järjestelmänä ja karsi sitä säännöllisesti, jotta vain olennainen ja arvokas tieto säilyy.
Järjestelmäkehotteen oppiminen on vielä alkutekijöissään, mutta sen mahdollisuudet ovat valtavat. Pelkästään staattisiin kehotteisiin tai loputtomaan hienosäätöön turvautuvat yritykset kohtaavat tuttuja rajoitteita: hauraita järjestelmiä, kasvavia kustannuksia ja hukkaan menevää työtä. SPL tarjoaa ulospääsyn tästä kierteestä: sen avulla voidaan rakentaa ajan mittaan kehittyviä järjestelmiä, jotka yksittäisten paikkausten sijasta omaksuvat ylemmän tason periaatteita.
SPL on vielä kehittyvä ala, mutta suunta on selvä: itseltään oppivat järjestelmät ohittavat ne, jotka eivät siihen pysty. Nyt kannattaa kokeilla, aloittaa pienestä, ottaa opit talteen ja luoda perusta tekoälyjärjestelmille, jotka paranevat jokaisen vuorovaikutustilanteen myötä.