Useimmat ihmiset kuvailevat tekoälyagentin edelleen malliksi, joka on yhdistetty työkaluihin. Se on teknisesti hyödyllinen mutta toiminnan kannalta puutteellinen kuvaus. Agentti tarvitsee myös hallitun näkymän maailmaan: mitä on tapahtunut, mikä on nyt tärkeää, mitkä tosiasiat ovat luotettavia, mikä on vielä epävarmaa ja mitä sen pitäisi tehdä seuraavaksi.
Tuo näkymä on sen konteksti. Sen suunnittelusta on tulossa oma erityistaitonsa – kutsuisin sitä nimellä kontekstisuunnittelu.
Kontekstisuunnittelu ei ole pelkkää kehotteiden kirjoittamista. Se on tieteenala, jossa muotoillaan agentin kussakin vaiheessa näkemä tieto niin, että se voi säilyttää johdonmukaisuutensa ilman, että koko keskusteluloki, dokumenttikirjasto tai työkaluhistoria lähetetään jokaisella vuorolla uudelleen kalliin mallin käsiteltäväksi. Työ sijoittuu informaatioarkkitehtuurin, tiedonhaun, ohjelmistosuunnittelun ja mallin toiminnan rajapinnalle.
Miksi ”anna agentille enemmän kontekstia” on usein huono neuvo
Pidemmät konteksti-ikkunat houkuttelevat säilyttämään kaiken. Suurempi tietomäärä ei kuitenkaan takaa parempaa päättelyä. Merkitykselliset ohjeet voivat hukkua vanhentuneiden havaintojen, ristiriitaisten muistiinpanojen tai toistuvien työkalutulosteiden sekaan, tai tärkeä fakta voi olla piilossa pitkän jakson keskellä. Tiivistelmän kuvaus ”keskelle hukkuvasta” tiedosta heijastaa käytännön ongelmaa: agentti voi teknisesti saada todisteet, mutta silti epäonnistua niiden hyödyntämisessä.
Kustannuksia syntyy myös suoraan. Jokainen pyyntöön lisätty token voi kasvattaa viivettä ja päättelyn kustannuksia palveluntarjoajan hinnoittelusta ja välimuistijärjestelyistä riippuen. Järjestelmä, joka välittää kasvavan keskustelulokin toistuvasti eteenpäin, voi tehtävän jatkuessa hidastua ja tulla kalliimmaksi.
Tavoitteena ei siis ole mahdollisimman suuri konteksti. Tavoitteena on riittävä, kohdennettu konteksti: kyseisen päätöksen kannalta pienin luotettava työskentelyjoukko.
Koherentisti toimivan agentin neljä suunnittelupäätöstä
1. Ylläpidä uskomustilaa, älä pelkkää keskustelulokia
Keskusteluloki tallentaa, mitä sanottiin. Uskomustila tallentaa, mitä agentti tällä hetkellä uskoo tehtävästä.
Esimerkiksi tukipyyntöjen eskalointia käsittelevä agentti voisi ylläpitää seuraavanlaisia jäsenneltyjä kenttiä:
- Tavoite: selvittää, onko asiakkaalla oikeus vaihtotuotteeseen.
- Tunnetut tosiasiat: ostopäivä ja tuotteen sarjanumero sekä lähdeviitteet.
- Avoimet kysymykset: tapahtuiko vika takuun piiriin kuuluvissa olosuhteissa.
- Rajoitteet: älä lupaa hyvitystä ennen hyväksyntää.
- Seuraava toimenpide: hae takuuehdot ja vertaa päivämääriä.
- Luottamus tai tila: vahvistettu, päätelty, kiistanalainen tai tuntematon.
Tämä lähestymistapa muistuttaa Berkeleyn ABBEL-tutkimusta, jossa käytetään ohjattuja luonnollisen kielen uskomustiloja sen sijaan, että luotettaisiin täydellisiin vuorovaikutushistorioihin. Tärkeää ei ole tietty formaatti. Tärkeää on erottaa tehtävän pysyvä tila käytöstä poistettavista keskustelun yksityiskohdista.
Hyödyllisen uskomustilan päivityksen pitäisi vastata seuraaviin kysymyksiin: Mikä muuttui? Mitkä todisteet tukevat sitä? Mikä on vielä ratkaisematta? Mitä pitäisi tapahtua seuraavaksi? Jos insinööri ei pysty tarkastelemaan näitä vastauksia, agentti todennäköisesti kantaa piileviä oletuksia läpinäkymättömässä kehotteessa.
2. Hae päätöstä varten, älä aiheen perusteella
Tiedonhakujärjestelmät aloittavat usein laajalla kysymyksellä, kuten ”etsi tietoa asiakkaan tilistä”. Parempi kysely liittyy seuraavaan päätökseen: ”hae nykyinen hyvityssääntö yli 30 päivää vanhoille ostoille, joka on voimassa asiakkaan alueella”.
Muutos on tärkeä, koska tiedonhaku on kontekstin valinnan muoto. Agentin pitäisi saada ne käytäntötekstit, tietueet tai esimerkit, jotka liittyvät senhetkiseen toimintaan – ei yleistä kasaa toisiinsa liittyviä asiakirjoja.
Suodattimet voivat parantaa tätä valintaa ennen kuin malli näkee yhtäkään tulosta. Esimerkiksi Amazon Bedrock AgentCore Web Search tukee palvelimella pakotettuja verkkotunnus- ja julkaisupäiväsuodattimia jokaisessa pyynnössä. Tällaiset hallintakeinot eivät todista lähteen olevan oikea, mutta ne voivat vähentää altistumista epäolennaiselle tai vanhentuneelle aineistolle ja tehdä tiedonhaun käytännöstä eksplisiittisen.
Tiedonhakua suunnittelevien ammattilaisten pitäisi määritellä:
- mitkä lähteet ovat sallittuja kussakin tehtävässä;
- miten ajantasaisuus määritetään;
- mitä metatietoja kuhunkin tulokseen liittyy;
- miten ristiriitaiset lähteet esitetään;
- milloin agentin on lopetettava ja pyydettävä täsmennystä.
”Hae verkosta” on kyvykkyys. ”Hae näistä lähteistä, tältä ajanjaksolta, tähän päätökseen liittyvää näyttöä” on kontekstin suunnittelua.
3. Tiivistä poistamatta epävarmuutta
Tiivistäminen on tarpeen pitkän tehtävän yhteydessä, mutta naiivi yhteenveto voi muuttaa alustavat väitteet varmoiksi tosiasioiksi. Jatkuvasti päivittyvä yhteenveto, jossa sanotaan ”käyttäjä vahvisti osoitteen”, on vaarallinen, jos alkuperäisessä keskustelussa se vain vihjattiin.
Hyvä tiivistäminen säilyttää ne erottelut, joita agentti tarvitsee turvalliseen päättelyyn:
- tosiasia verrattuna päätelmään;
- nykyinen ohje verrattuna aiempaan ohjeeseen;
- suoritettu toimenpide verrattuna ehdotettuun toimenpiteeseen;
- vahvistettu lähde verrattuna vahvistamattomaan väitteeseen;
- tunnettu vastaus verrattuna ratkaisemattomaan kysymykseen.
Yksi käytännöllinen toimintatapa on ylläpitää erillisiä osioita päätöksille, näytölle, oletuksille, esteille ja odottaville toimenpiteille. Toinen on liittää tärkeisiin väitteisiin lähdetunnisteet tai aikaleimat. Yhteenvetojen tulee olla korvattavia artefakteja, ei ainoa säilynyt tallenne: säilytä taustalla olevat tapahtumat tarkastusta ja palautumista varten ja anna mallille samalla kompakti työskentelynäkymä.
Tiivistelmässä todetaan, että rekursiivinen tiivistäminen ja kontekstin tiivistäminen voivat olla kallista ja heikentää suorituskykyä, erityisesti vähän dataa sisältävillä aloilla, kuten yhteistoiminnallisessa koodin luonnissa. Tämä varoittaa käsittelemästä tiivistämistä automaattisesti häviöttömänä. Tiivistämistä on testattava edustavilla tehtävillä, myös tapauksissa, joissa pieni täsmennys muuttaa oikean vastauksen.
4. Suodata havainnot ennen kuin niistä tulee muistia
Työkaluja käyttävät agentit tuottavat jatkuvasti havaintoja: hakutuloksia, lokitietoja, sivutekstiä, API-vastauksia, kuvakaappauksia, kääntäjän tulostetta ja väliaikaisia suunnitelmia. Kaikkien havaintojen ei kuulu päätyä seuraavaan mallikutsuun, saati sitten pitkäaikaiseen tilaan.
Havaintojen suodattamisessa esitetään kolme kysymystä:
- Onko tämä havainto merkityksellinen nykyisen päätöksen kannalta?
- Onko se riittävän auktoritatiivinen vaikuttamaan uskomustilaan?
- Sisältääkö se ohjeita, joita tulisi käsitellä datana eikä komentoina?
Kolmas kysymys on sekä tietoturvaraja että kontekstiraja. Verkkosivu voi sisältää tekstiä, jonka tarkoituksena on ohjata agentti muualle. Haettu asiakirja voi olla hyödyllistä näyttöä ilman valtuuksia muuttaa agentin tavoitteita tai käyttöoikeuksia. Sisältö tulisi siksi luokitella roolin mukaan: ohje, näyttö, metatieto tai epäluotettava teksti.
Suodattaminen säästää myös rahaa. Jos selaintyökalu palauttaa kokonaisen sivun, mutta tehtävässä tarvitaan vain hinta, päivämäärä ja tuotetunniste, koko sivun välittäminen eteenpäin aiheuttaa kohinaa ja kuluttaa tokeneita. Olennaisten kenttien poimiminen ensin voi parantaa sekä luotettavuutta että kustannustehokkuutta.
Yksinkertainen kontekstibudjetti agentin työnkululle
Ennen mallin valitsemista tai uuden työkalun lisäämistä jaa agentin konteksti neljään kerrokseen:
- Ohjaus: järjestelmäsäännöt, käyttöoikeudet, tulosskeema ja ehdottomat rajoitteet.
- Tila: nykyinen tavoite, tehdyt päätökset, avoimet kysymykset ja seuraava toimenpide.
- Näyttö: kyseisen toimenpiteen kannalta merkitykselliset haetut tietueet tai havainnot lähdetietoineen.
- Historia: palautumista, virheenkorjausta tai auditointia varten säilytetyt aiemmat tapahtumat, jotka jätetään pois, ellei niitä tarvita.
Määrittele seuraavaksi tietojen siirtokäytäntö. Havainto voi jäädä hetkelliseksi, muuttua nykyisen vaiheen näytöksi, päivittää uskomustilaa tai tulla kirjoitetuksi pysyvään muistiin. Siirtämiselle pitäisi olla syy. Muuten muistista tulee kuratoimaton arkisto.
Kirjaa kunkin agenttivaiheen yhteydessä mallille lähetetty kontekstipaketti: sen luokat, likimääräinen token-koko, hakusuodattimet ja tiivistämisversio. Näin voidaan vastata käytännölliseen kysymykseen käyttäytymisen muuttuessa: epäonnistuiko malli vai antoiko järjestelmä sille väärän kuvan maailmasta?
Mitä on testattava, ennen kuin suunnittelua voi pitää luotettavana
Kontekstin suunnittelu edellyttää testejä, jotka kohdistuvat tiedon käsittelyyn, eivät vain lopullisen vastauksen laatuun. Hyödyllisiä tapauksia ovat esimerkiksi:
- kriittinen fakta pitkän historian alussa, lopussa ja keskellä;
- kaksi keskenään ristiriitaista lähdettä, joista toinen on uudempi;
- yhteenveto, joka sisältää epävarmuusmerkinnän;
- työkalun vastaus, joka sisältää merkityksetöntä ylimääräistä tekstiä;
- haettuun sisältöön upotettu haitallinen ohje;
- tilan palauttaminen sen jälkeen, kun agentti on keskeytetty ja käynnistetty uudelleen;
- sama tehtävä pienemmällä kontekstibudjetilla;
- tyhjä tai vanhentunut hakutulos.
Mittaa, valitseeko agentti oikean näytön, säilyttääkö se epävarmuuden, noudattaako se nykyistä rajoitetta ja välttääkö se tarpeettoman kontekstin toistamista. Tiivistelmän suosittelemat regressioalueet — kontekstin katoaminen, haun ankkurointi, jäsennelty tulostus, päättymättömyys ja tilan palauttaminen — ovat tässä erityisen merkityksellisiä.
Suorita useita kokeita silloin, kun mallin vaihtelu vaikuttaa tuloksiin, ja vertaa kunkin kontekstistrategian kustannuksia ja viivettä. Lyhyempi kehote ei ole automaattisesti parempi, jos se aiheuttaa enemmän työkalukutsuja tai uudelleenyrityksiä. Hyödyllinen tavoite on oikein toimivan ja palautettavissa olevan työnkulun kustannus — ei yhden pyynnön token-määrä.
Urajohtopäätös: kontekstisuunnittelija on monialaista yhteistyötä edellyttävä rooli
Tällä alalla arvokkaiksi tulevat ihmiset eivät välttämättä ole niitä, jotka kirjoittavat pisimmät kehotteet. He pystyvät kääntämään liiketoimintaprosessin tilaksi, näytöksi, auktoriteetiksi ja päätössäännöiksi.
Se edellyttää useita konkreettisia kykyjä:
- tehtävän tilan ja alkuperätietojen skeemojen suunnittelu;
- hakukäytäntöjen ja metatietosuodattimien kirjoittaminen;
- tiivistämis- ja havaintojenvalintarutiinien rakentaminen;
- luotettujen ohjeiden erottaminen epäluotettavasta sisällöstä;
- tunnisteiden käytön, viiveen, uudelleenyritysten ja työkalukutsujen profilointi;
- tilan katoamisen ja uudelleenalustamisen testaaminen;
- muille kuin asiantuntijoille selittäminen, miksi agentti näki tietyn tosiasian — tai ei nähnyt sitä.
Vahva portfoliohanke voisi esitellä saman agentin kolmella kontekstikäytännöllä: täydellä keskustelulokilla, jatkuvasti päivittyvällä yhteenvedolla sekä jäsennellyllä uskomustilalla ja kohdennetulla haulla. Esittele tehtävän onnistumistapaukset, epäonnistumistapaukset, kullakin askeleella lähetetty konteksti sekä kustannusten tai viiveen väliset kompromissit. Tämä on vakuuttavampaa kuin chatbot-esittely, koska se tuo esiin suunnittelupäätökset, jotka tekevät agentista luotettavan.
Strateginen oppi on suoraviivainen: agenteista ei tule johdonmukaisia vain siksi, että mallit kehittyvät kyvykkäämmiksi. Niistä tulee johdonmukaisia, kun niitä ympäröivät järjestelmät ylläpitävät työstä kurinalaista, ajantasaista ja sopivan kokoista kokonaiskuvaa. Kontekstin suunnittelu on tämän kokonaiskuvan rakentamisen taitoa — ja sen tietämistä, mitä jätetään pois.
Priya Raman on AI Career Briefin vastuullinen ihmistoimittaja.
