Opas: Näin rakennat toimivan kehotteen AI-agentille

Kun kehotteet eivät enää riitä

Muistatko sen ajan, kun tekoälyn kanssa työskentely tarkoitti pelkästään "oikean kehotteen" löytämistä? Kirjoitit huolellisesti laaditun ohjetekstin, painoit Enter-näppäintä ja toivoit parasta. Jos tulos ei ollut tyydyttävä, palasit takaisin muokkaamaan kehotetta sanasta sanaan, kuin hioisit runoa täydellisyyteen.

Tuo aika alkaa olla ohi. Nykyään tekoälysovellusten rakentaminen on siirtynyt uudelle tasolle, jossa pelkkä kehotteen kirjoittaminen ei enää riitä.

Tämä on kontekstisuunnittelun (context engineering) ydin. Siinä missä kehotteen kirjoittaminen (prompt engineering) keskittyi ohjeiden sanamuotoon, kontekstisuunnittelu tarkastelee koko sitä informaatiokokonaisuutta, joka kielimallille annetaan jokaisella käyttökerralla. Tämä opas vie sinut matkalle perusperiaatteista käytännön toteutukseen.

Miksi konteksti on kuin työpöytä täynnä post-it -lappuja

Kuvittele työpöytä, jonka pinnalla on vain rajallinen määrä tilaa. Jokainen uusi dokumentti, muistilappu tai kirja vie siitä osan. Lopulta pöytä täyttyy niin täyteen, että et enää löydä sieltä mitään olennaista – kaikki vain hukuttaa kaiken muun alleen.

Kielimallit toimivat samalla tavalla. Niillä on niin sanottu "huomiobudjetti" (attention budget), joka kuluu jokaisen uuden tokenin (sanan tai merkin) myötä. Tutkimukset ovat osoittaneet ilmiön, jota kutsutaan "kontekstin rapautumiseksi" (context rot): mitä enemmän tokeneita kontekstissa on, sitä heikommaksi mallin kyky käsitellä ja muistaa yksittäisiä tietoja käy.

Tämä ei johdu siitä, että mallit olisivat "tyhmiä" – kyse on arkkitehtuurisesta rajoitteesta. Transformer-arkkitehtuurissa, jolle suuret kielimallit rakentuvat, jokainen token voi teoriassa kiinnittää huomionsa jokaiseen muuhun tokeniin. Kun tokeneiden määrä on n, parien määrä on n². Kun kontekstin pituus kasvaa, mallin kyky hahmottaa kaikkia näitä suhteita heikkenee väistämättä.

Siksi kontekstisuunnittelu on tärkeää: se on taitoa valita juuri ne oikeat palat informaatiota, jotka maksimoidvat halutun lopputuloksen todennäköisyyden ilman että huomiobudjetti kuluu loppuun.

Systeemikehotteet: Ei liian tarkkoja, ei liian epämääräisiä

Hyvä systeemikehote on kuin kartta: sen pitää olla tarpeeksi yksityiskohtainen, että tiedät minne olet menossa, mutta ei niin yksityiskohtainen, että se määrää jokaisen askeleesi. Tätä kutsutaan "oikeaksi lentokorkeudeksi".

Liian matalalla lennettäessä – eli kirjoittamalla jokaiseen tilanteeseen tarkat if-else-säännöt – luot järjestelmän, joka on hauras kuin lasinen karahvi. Yksi odottamaton tilanne, ja koko rakennelma hajoaa.

Liian korkealla lennettäessä – eli antamalla vain epämääräisiä yleisohjeita – annat kielimallille liian vähän ohjattavuutta. "Ole avulias ja ystävällinen" on yhtä hyödyllistä kuin sanoa talven ulkoiluvaatteista: "Pukeudu säähän sopivasti." Teknisesti ottaen totta, mutta käytännössä hyödytöntä.

Kultakutri-vyöhyke on siinä välissä: tarpeeksi spesifinen antamaan selkeät suuntaviivat, mutta tarpeeksi joustava antamaan mallille tilaa soveltaa älyään. Käytännössä tämä tarkoittaa, että jaat ohjeesi selkeisiin osioihin ja käytät XML-tageja tai markdown-otsikoita niiden erotteluun. Esimerkiksi:

<taustatiedot>
Olet asiakaspalveluagentti verkkokaupassa...
</taustatiedot>

<ohjeet>
1. Vastaa aina kohteliaasti...
2. Jos asiakas kysyy tilauksen tilasta...
</ohjeet>

Työkalut: Vähemmän on enemmän

Jos annat agentille 50 erilaista työkalua, mikä tapahtuu? Sama kuin antaisit remonttimiehelle 50 erilaista vasaraa. Hän ei todennäköisesti valitse niistä parasta, vaan viettää puolet ajastaan ihmetellen, mitä vasaraa käyttää.

Tilaa AI-Sanomien Plus-jäsenyys niin näet loput sisällöstä