Kehotearkkitehtuuri oikeisiin työnkulkuihin, ei lelukehotteisiin

Kehote, joka voittaa demon, ei juuri koskaan ole se kehote, joka selviää tiistaista. Liität siistin esimerkin, malli palauttaa jotain kaunista, kaikki nyökyttelevät, ja sitten kytket sen oikeaan työnkulkuun, jossa syötteenä on puoliksi tyhjiä PDF-tiedostoja, talousihmisen muistiinpanoja kahdella kielellä ja kenttä, jonka joku nimesi uudelleen vuonna 2021. Nokkela yhden rivin kehote hajoaa heti, kun se kohtaa todellisuuden.

Opin tämän kantapään kautta, kun rakensin LLM-vaiheita Nordbriefin avustuspipelineen, ja sitten uudestaan niissä toistuvissa ops-työnkuluissa, joita pyöritin Nuorten Kotkissa. Oppi on joka kerta sama: tuotantokehote ei ole lause. Se on pieni järjestelmä. Ja kuten kaikilla järjestelmillä, sillä on osansa, joista kukin hoitaa yhtä tehtävää, ja se pettää ennustettavista kohdista, jos jonkin niistä jätät pois.

Tässä on ajatusmalli, jota nykyään käytän.

Tuotantokehotteessa on viisi osaa

Ajattele oikeaa kehotetta samalla tavalla kuin pientä palvelua. Viisi komponenttia, joilla kullakin on selkeä vastuu:

1. Kontekstin kokoaminen. Mitä malli saa nähdä, ja missä muodossa.
2. Tehtävän pilkkominen. Työn paloittelu vaiheisiin, jotka malli oikeasti osaa.
3. Tulostesopimus. Tarkka rakenne, johon vastauksen on asetuttava.
4. Evaluaatiot. Mistä tiedät, että se toimii, ennen kuin luotat siihen.
5. Suojakaiteet. Mitä tapahtuu, kun syöte on roskaa tai tuloste on väärä.

Lelukehote latoo kaikki viisi yhteen toiveikkaaseen lauseeseen: "Tiivistä tämä avustushakemus ja poimi budjetti." Se toimii demo-PDF:llä. Se ei toimi niillä neljälläkymmenellä oikealla, joista kolmesta puuttuu budjettitaulukko, yhdessä budjetti on skannattuna kuvana ja kaksi on tunkenut budjetin liitteeseen, otsikon alle, jonka hakija keksi itse.

Käydään jokainen osa läpi niin, että avustuspipeline toimii esimerkkinä.

Kontekstin kokoaminen: malli voi päätellä vain siitä mitä eteen laitat

Suurin osa kehotteiden epäonnistumisista on oikeastaan kontekstin epäonnistumisia. Malli ei saanut sitä mitä se tarvitsi, tai se sai sen hautautuneena kolmen sivun vakiotekstin alle.

Nordbriefissä tehtävänä on auttaa järjestöä muuttamaan sotkuinen projektikuvaus rahoituskelpoiseksi hakemukseksi tietylle rahoittajalle. Naiivi versio ahtaa kaiken yhteen kehotteeseen: rahoittajan ohjeet, järjestön vanhat hakemukset, uudet projektimuistiinpanot ja pyynnön "kirjoita hakemus". Malli hukkuu. Se painottaa vakiotekstiä yhtä paljon kuin sitä yhtä kappaletta, jolla on merkitystä, ja tuloste on kuin mikä tahansa muu avustushakemus: turvalliset verbit, geneeriset vaikutukset, nolla särmää.

Kontekstin kokoaminen tarkoittaa, että päätät tietoisesti mitä menee sisään ja miten se merkitään. Jokaista LLM-vaihetta varten kokoan:

• Rahoittajan todelliset arviointikriteerit lyhyeksi listaksi tiivistettynä, ei koko PDF:ää.
• Pari kolme olennaista aiempaa kappaletta, aiheen mukaan haettuna, ei koko arkistoa.
• Uudet projektifaktat kentiksi jäsenneltyinä (ongelma, kuka, missä, budjettirivit).
• Lyhyen huomion siitä mitä puuttuu, jotta malli ei keksi sitä itse.

Tuo viimeinen painaa enemmän kuin miltä kuulostaa. Jos et kerro mallille mitä sinulta puuttuu, se täyttää aukon uskottavalla fiktiolla. Kun kerrot etukäteen, että "budjetti ei ole vielä saatavilla", siinä on ero rehellisen luonnoksen ja itsevarman valheen välillä, joka koskee lukua, jota ei ole olemassa.

Tehtävän pilkkominen: pyydä yhtä asiaa jonka malli oikeasti osaa

Suurin yksittäinen parannus kehotteisiini oli, että lopetin koko lopputuotteen pyytämisen yhdellä kertaa.

"Kirjoita avustushakemus" on oikeastaan neljä eri työtä saman lauseen sisällä: ymmärrä rahoittaja, sovita projekti hänen kriteereihinsä, rakenna kerronta ja tuota ohjeidenmukaista tekstiä. Niputettuna malli tekee kaikki neljä huonosti. Eroteltuna se tekee jokaisen hyvin.

Siksi Nordbriefin pipeline ajetaan vaiheittain. Yksi vaihe sovittaa projektin rahoittajan kriteereihin ja merkitsee heikot osumat. Erillinen vaihe luonnostelee muutosteorian. Toinen tuottaa budjettikerronnan riveistä. Kolmas tuottaa ohjeidenmukaiset liitteet. Jokainen vaihe on tarkkaan rajattu kehote omalla kontekstillaan ja omalla tulostesopimuksellaan.

Bonuksena: kun jokin menee pieleen, tiedät tarkalleen mikä vaihe sen aiheutti. Yhdellä laukauksella toimiva megakehote, joka tuottaa huonon hakemuksen, ei anna sinulle mitään mistä etsiä vikaa. Pipeline, joka tuottaa huonon budjettikerronnan, kertoo täsmälleen mistä katsoa.

Tässä on aito kompromissi. Enemmän vaiheita tarkoittaa enemmän mallikutsuja, enemmän viivettä, enemmän kustannusta ja enemmän ylläpidettäviä kohtia. En pilko pilkkomisen vuoksi. Sääntö, jota käytän: pilko silloin, kun alitehtävät tarvitsevat eri kontekstin, tai kun yhden alitehtävän epäonnistuminen ei saa pilata muita. Jos kaksi työtä jakavat aina saman syötteen ja onnistuvat tai epäonnistuvat aina yhdessä, pidä ne samassa kehotteessa.

Tulostesopimukset: lopeta proosan parsiminen

Tämän osan ihmiset jättävät väliin ja katuvat sitä myöhemmin. Jos jatkojärjestelmä käyttää mallin tulostetta, tulosteella on oltava sopimus, ei kappaletta tekstiä.

Alkuun yksi ops-työnkuluistani pyysi mallia "luokittelemaan tämä saapuva pyyntö ja ehdottamaan seuraavia askeleita". Se palautti ihanaa proosaa. Sitten jouduin kirjoittamaan jäsentäjän selvittääkseni mihin luokkaan se päätyi, ja jäsentäjä hajosi joka kerta, kun malli muotoili vastauksen vähän eri tavalla. Kirjoitin regexiä fiilistä vastaan.

Korjaus on määrittää tarkka muoto ja pakottaa malli täyttämään se:

{
  "category": "funding | partnership | media | volunteer | other",
  "urgency": "high | normal | low",
  "missing_info": ["string"],
  "suggested_reply_language": "fi | en",
  "confidence": "high | medium | low"
}

Rajatut kentät, enum siellä missä vastausjoukko on kiinteä, ja paikka jossa malli voi sanoa mitä se ei pystynyt päättelemään. Nyt jatkokoodi lukee kentän sen sijaan että tulkitsisi mielialaa. Ja confidence antaa minulle halvan reitityssignaalin: kaikki muu kuin high menee ihmiselle.

Hyvä sopimus myös kurittaa mallin ajattelua. Kun pakotat sen sitoutumaan yhteen luokkaan kiinteältä listalta, se lakkaa kiertelemästä. Rakenne on puolet kehotteesta.

Evaluaatiot: et voi parantaa sitä mitä vain pistokokeilla tarkistat

Tässä se epämukava osa. Useimmat "testaavat" kehotteen kokeilemalla sitä pari kertaa, pitämällä tuloksesta ja julkaisemalla. Sitten he viilaavat sanamuotoa myöhemmin, vilkaisevat yhtä esimerkkiä, päättävät että se on parempi ja julkaisevat taas. Heillä ei ole aavistustakaan auttoiko muutos vai rikkoiko se hiljaa ne muut kolmekymmentä tapausta.

Et tarvitse hienoa evaluaatiokehystä korjataksesi tämän. Tarvitset kansion oikeita, sotkuisia esimerkkejä ja tavan tarkistaa tuloste sitä vasten mitä oikeasti halusit.

Avustusten luokittelijaa varten evaluaatiojoukkoni oli kaksikymmentä oikeaa aiempaa pyyntöä, käsin merkittynä oikealla luokalla ja kiireellisyydellä. Joka kerta kun muutin kehotetta, ajoin kaikki kaksikymmentä ja laskin kuinka monta se sai oikein. Tylsää. Ratkaisevaa. Ensimmäisen kerran kun tein tämän, huomasin että sanamuodon muutos jonka olin varma parantavan asioita oli pudottanut tarkkuutta kaksikielisillä syötteillä, koska olin ylipainottanut kehotteen englanninkieliseen ilmaisuun. Ilman evaluaatiojoukkoa olisin julkaissut sen ja ihmetellyt myöhemmin miksi suomenkieliset pyynnöt jatkoivat väärään paikkaan reitittymistä.

Rakenna evaluaatiojoukko niistä syötteistä jotka pelottavat sinua, ei niistä jotka imartelevat. Se puoliksi tyhjä PDF. Pyyntö joka on kohteliasta jutustelua kolmen kappaleen verran ennen varsinaista asiaa. Se suomenkielinen englanninkielisellä otsikkorivillä. Jos kehotteesi kestää nuo, helpot tapaukset hoituvat itsestään.

Suojakaiteet: oleta että syöte on vihamielinen ja tuloste väärä

Viimeinen osa on se mitä teet kun asiat menevät vinoon, koska niin käy.

Kaksi virhetilaa dominoi. Ensimmäinen on roskasyöte: tyhjä dokumentti, skannaus josta ei saa tekstiä irti, kenttä jota malli ei löydä. Suojakaide on tehdä "en pysty tähän" vastauksesta validi, rakenteinen tuloste. Avustusvaiheeni voivat palauttaa status: "insufficient_input" listan kera siitä mitä puuttuu, sen sijaan että hallusinoisivat budjetin. Malli joka saa kieltäytyä on paljon turvallisempi kuin sellainen joka on pakotettu aina tuottamaan.

Toinen on itsevarmasti väärä tuloste. LLM-teksti on sujuvaa, mikä on juuri se ongelma. Se keksii kumppanuushistorian, silottaa todellisen riskin optimistisella kielellä tai väittää mittaria jota ei ole missään lähdeaineistossa. Suojakaide on varmennusvaihe: erillinen, halvempi tarkistus joka kysyy "onko jokainen tämän luonnoksen faktaväite pohjattu annettuun lähdemateriaaliin?" Kaikki pohjaton merkitään ihmiselle, ei koskaan julkaista automaattisesti.

Halvin suojakaide on inhimillinen tarkistuspiste oikeassa kohdassa. Ei kaiken tarkistaminen, mikä ei skaalaudu. Vaan niiden tarkistaminen jotka järjestelmä itse merkitsi matalan luottamuksen tai pohjattomiksi.

Tämä on se lanka joka kulkee kaiken läpi, ja se on sama vakaumus jonka tuon kaikkeen mitä rakennan: skaalautuminen toimii järjestelmillä, ei hyvällä tahdolla. Et saa luotettavaa tekoälytuotetta toivomalla että malli käyttäytyy. Saat sen suunnittelemalla kohdat joissa se saa epäonnistua turvallisesti.

Mihin tämä jättää sinut

Muutos on pieni kuvailla ja suuri käytännössä. Lopeta kehotteiden kirjoittaminen nokkelina lauseina. Aloita niiden kirjoittaminen pieninä järjestelminä joilla on viisi työtä: kokoa oikea konteksti, pilko tehtävä, sovi tulosteesta, evaluoi oikeita tapauksia vasten ja suojaa reunat.

Se on enemmän työtä etukäteen kuin yhden rivin kehote, ja se on rehellinen kompromissi. Mutta yhden rivin kehote ei koskaan ollut halvempi. Se vain siirsi kustannuksen alavirtaan, siihen tiistaihin kun sotkuiset syötteet saapuivat eikä kukaan tiennyt mikä osa oli rikkoutunut. Rakenna järjestelmä, niin tiistaista tulee tylsä. Tylsä, tuotannossa, on koko pointti.