Milloin ongelma ratkeaa paremmalla promptilla?

Tekoälyongelmissa on houkutteleva oletus: jos lopputulos on huono, prompti oli huono. Tämä on joskus totta. Yllättävän usein se ei ole.

Prompt engineering on hyödyllinen taito, mutta siitä tulee helposti tekoälyajan vastine lauseelle ”käyttäjävirhe”. Kun järjestelmä epäonnistuu, käyttäjää pyydetään määrittelemään asia tarkemmin, lisäämään esimerkkejä, kirjoittamaan negatiivisia ehtoja, määräämään rooli ja rakentamaan lopulta puolen sivun ohjeistus tehtävään, jonka ihminen olisi ymmärtänyt yhdestä virkkeestä.

Liiketoiminnan näkökulmasta olennaisempi kysymys kuuluu:

Milloin epäonnistumisen marginaalisesti halvin korjaus todella on parempi prompti – ja milloin ongelma sijaitsee muualla järjestelmässä?

Prompti on vain yksi tuotantofunktion muuttuja

Tekoälyllä tuotettua lopputulosta voidaan ajatella yksinkertaistetusti funktiona:

Y = f(M, P, C, T, R)

missä:

• M = mallin kyvykkyys,
• P = prompti,
• C = käytettävissä oleva konteksti ja data,
• T = työkalut ja integraatiot,
• R = tarkistus- ja palautemekanismi,
• Y = toteutunut lopputulos.

Jos lopputulos on huono, ei tästä vielä seuraa, että P pitäisi optimoida. Ongelma voi yhtä hyvin olla mallin kyvyssä, puuttuvassa datassa, väärässä työkalussa tai siinä, ettei kukaan tarkista, täyttääkö tulos alkuperäisen tavoitteen.

Promptia kannattaa parantaa silloin, kun sillä on suuri vaikutus onnistumisen todennäköisyyteen:

Δp = P(onnistuminen | parempi prompti) − P(onnistuminen | nykyinen prompti)

Jos tämä erotus on suuri, prompt engineering luo arvoa. Jos erotus on lähes nolla, promptin hiominen on helposti vain uudenlaista hallinnollista työtä.

Ensimmäinen testi: ymmärtääkö järjestelmä väärin?

Prompttiongelman tunnusmerkki on, että järjestelmän muodostama käsitys tehtävästä poikkeaa käyttäjän tavoitteesta.

Käyttäjä esimerkiksi pyytää analysoimaan yrityksen kannattavuutta, mutta tekoäly tulkitsee tehtävän yleiseksi yritysesittelyksi. Tässä tarkempi tavoite, rajaus ja hyväksymiskriteeri voivat ratkaista ongelman.

Tilanne voidaan kuvata näin:

käyttäjän tavoite ≠ mallin tehtävärepresentaatio

Tällöin prompti toimii informaation siirtokanavana. Parempi prompti vähentää epävarmuutta siitä, mitä pitäisi tehdä.

Toinen testi: muuttaako promptin vaihtaminen tulosta?

Hyvä diagnoosi ei perustu tunteeseen vaan interventioon.

Pidä malli, aineisto ja tehtävä samoina. Muuta vain promptia.

Jos ensimmäinen prompti onnistuu neljä kertaa kymmenestä ja toinen yhdeksän kertaa kymmenestä, olet löytänyt aidon prompttiongelman.

Jos viisi erilaista, huolellisesti laadittua promptia epäonnistuu suunnilleen samalla tavalla, kannattaa lopettaa promptien kirjoittaminen ja etsiä seuraava pullonkaula.

Tämä kuulostaa triviaalilta, mutta organisaatioissa tehdään helposti päinvastoin: promptia kehitetään kuukausia ilman kontrolloitua vertailua.

Kolmas testi: pystyykö malli tekemään osatehtävät?

Jos järjestelmä epäonnistuu monimutkaisessa tehtävässä, tehtävä kannattaa hajottaa.

Osaako malli:

• tunnistaa oikean tiedon?
• luokitella sen oikein?
• tehdä tarvittavan laskelman?
• noudattaa formaattia?
• arvioida oman vastauksensa hyväksymiskriteeriä?

Jos kaikki osat onnistuvat erikseen mutta kokonaisuus ei, ongelma saattaa olla tehtävän orkestroinnissa. Tällöin parempi prompti, vaiheistus tai agenttirakenne voi auttaa.

Jos ratkaiseva osatehtävä ei onnistu edes yksinään, prompti ei ole ensimmäinen korjauskohde.

Tärkein raja: ymmärtämisvirhe vai toteutusvirhe?

Ajatellaan yksinkertaista tapausta. Käyttäjä pyytää kuvageneraattorilta koiraa. Järjestelmä tuottaa kissan.

Käyttäjä korjaa:

”Koira. Ei kissa.”

Järjestelmä vastaa:

”Ymmärretty. Generoin koiran, en kissaa.”

Ja tuottaa jälleen kissan.

Tässä tapahtuu jotain olennaista. Järjestelmän kielellinen representaatio tavoitteesta näyttää jo olevan oikea:

sisäinen tehtävärepresentaatio = käyttäjän tavoite

mutta:

lopputulos ≠ käyttäjän tavoite

Tässä vaiheessa neuvo ”kirjoita parempi prompti” alkaa olla diagnostisesti heikko. Järjestelmä tietää jo, mitä siltä pyydetään. Ongelma sijaitsee todennäköisemmin ohjauksen ja tuotannon välisessä rajapinnassa tai lopputuloksen validoinnissa.

Prompti ei korvaa validointia

Monessa yritysten tekoälysovelluksessa todellinen ongelma ei ole huono prompti vaan puuttuva valmistumiskriteeri.

Järjestelmä tekee jotain, tuottaa tekstin ja ilmoittaa työn valmistuneeksi.

Mutta kuka tarkistaa esimerkiksi, että:

• kaikki laskut täsmäävät,
• kaikilla keskeisillä väitteillä on lähde,
• asiakkaan nimeä ei ole sekoitettu toiseen yritykseen,
• pakolliset kentät ovat mukana,
• tuotos todella ratkaisee tehtävän, jonka vuoksi prosessi käynnistettiin?

Jos vastaus on ”käyttäjä”, tekoäly ei ehkä ole automatisoinut tehtävää. Se on siirtänyt työn tuotannosta tarkastukseen.

Tällöin oikea investointi voi olla parempaa promptia arvokkaampi: automaattinen tarkistus, sääntöpohjainen validointi, toinen malli arvioijana tai ihmisen hyväksyntäpiste vain niihin tapauksiin, joissa epävarmuus ylittää tietyn rajan.

Promptattavuustesti yrityksen prosesseille

Tietotyötehtävän automatisoitavuutta voisi arvioida kysymällä seuraavat kysymykset järjestyksessä:

1. Onko haluttu lopputulos yksiselitteisesti määriteltävissä?
2. Onko onnistumisen ja epäonnistumisen ero havaittavissa?
3. Onko mallilla tehtävään tarvittava peruskyvykkyys?
4. Onko tarvittava informaatio saatavilla?
5. Parantaako promptin muuttaminen onnistumisastetta olennaisesti?
6. Voidaanko lopputulos validoida automaattisesti?

Jos ensimmäiset neljä ehtoa täyttyvät ja viides tuottaa suuren vaikutuksen, kyseessä on hyvä prompt engineering -kohde.

Jos viides ei auta mutta kuudes onnistuu, ratkaisu voi olla agentti tai validointikerros.

Jos onnistumista ei edes voida luotettavasti havaita, ollaan vaikeammassa tilanteessa: järjestelmältä puuttuu palautesignaali, jonka perusteella sen toimintaa voisi ohjata.

Prompt engineeringin taloudellinen raja

Yrityksen ei lopulta pitäisi kysyä, voidaanko promptia vielä parantaa. Lähes aina voidaan.

Oikea kysymys on:

Onko seuraava euro järkevämpää käyttää promptin parantamiseen kuin datan, mallin, integraation, validoinnin tai koko prosessin uudelleensuunnitteluun?

Prompt engineering on siis optimointiongelma, ei uskonto.

Kun hyvä prompti muuttaa epäselvän tehtävän selkeäksi, se voi poistaa suuren määrän tietotyötä lähes ilmaiseksi. Se on juuri sellainen kustannusrakenteen sievennys, jota tekoälyltä kannattaa etsiä.

Mutta kun järjestelmä jo tietää, mitä pitäisi tehdä, ja tekee silti jotain muuta, uuden adjektiivin lisääminen promptiin ei ole automaatiota.

Se on käyttöliittymän kautta tehtävää vikojen kompensointia.

Flutterby Ninja Consulting
Etsimme tietotyöstä kohtia, joissa kustannus voidaan poistaa – ei vain siirtää ihmiseltä promptiin.