Konteksti, ei kontrollia
Jokainen sääntö agenttisi kehotteessa alkoi virheenä.
Joku huomasi huonon toiminnan, kirjoitti säännön ja jatkoi eteenpäin. Joku toinen teki samoin. Kolmas lisäsi "älä koskaan tee X", koska malli teki jotain outoa kerran tiistaina. Kukaan ei poistanut mitään.
Kuusi kuukautta myöhemmin agentti käyttää enemmän konteksti-ikkunaansa sääntökirjansa selaamiseen kuin varsinaisen tehtävän ajattelemiseen.
Tämä on kontrollityylistä ajattelua. Ja mielestäni se on yksi suurimmista suunnitteluvirheistä, joita tiimit tekevät rakentaessaan tekoälyagentteja.
Pieni esimerkki, joka paljastaa isomman kaavan
Törmäsimme ongelmaan, jossa ajastettu tehtävä käynnisti agentin, joka loi uusia ajastettuja tehtäviä suorituksen aikana. Loputon rekursio, mutta oikeilla vaikutuksilla.
Kaksi tapaa reagoida.
Kontrollityyli: Kiellä se. Kirjoita koodi, joka estää ajastuksia luomasta uusia ajastuksia. Lisää kehotteeseen sääntö: "älä koskaan luo ajastusta ajastuksen sisällä." Julkaise.
Kontekstityyli: Kerro agentille, mitä oikeasti tapahtuu.
Sinut käynnisti ajastettu tehtävä klo 3:00 Tyynenmeren aikaa. Ajastuksen tunnus: sched_29x8f. Ajastettu suoritus on erillinen tehtävä, jonka käyttäjä on alun perin hyväksynyt. Uuden ajastetun tehtävän luominen laajentaisi tämän suorituksen laajuutta alkuperäisen hyväksynnän ulkopuolelle.
Ensimmäinen lähestymistapa paikkaa yhden toiminnan. Toinen antaa agentille mallin tilanteesta.
Nyt se voi pohtia myös muita kysymyksiä: Pitäisikö minun lähettää ilmoitus klo 3? Pitäisikö minun luoda jatkoprosessi, jota käyttäjä ei erikseen pyytänyt? Pitäisikö minun muokata jotain, joka ylittää alkuperäisen suorituksen laajuuden?
Sääntöä ei tarvita. Agentti ymmärsi itse.
Monet tiimit turvautuvat kontrolliin, kun he oikeasti tarvitsisivat kontekstia.
Sama ero näkyy kehotteiden sisällä
Kyse ei ole vain järjestelmätason valvonnasta. Konteksti vs. kontrolli -jako näkyy myös kehotteiden sisällä.
Kontekstityylinen kehotus: pääosin faktoja, vähän mielipiteitä:
Suoritat tehtävää ajastetun tehtävän vuoksi. Käynnistetty klo 3:00 Pekingin aikaa. Tehtävän tunnus: sched_29x8f. Käyttäjä hyväksyi tämän suorituksen tietylle laajuudelle.
Kontrollityylinen kehotus: mielipiteellinen, määräävä:
Vältä ajastusten luomista. Sinun tulisi ilmoittaa käyttäjälle työkalulla X. Älä koskaan tee Y, ellei Z.
Joskus määräävät ohjeet ovat hyödyllisiä. Mutta usein ne paikkaavat puuttuvia faktoja. Ja kun alat paikata näin, siitä tulee helposti tapa.
Miten kehotteista tulee byrokratiaa
Tämä on syvempi epäonnistumisen muoto.
Tiimi huomaa ongelman ja lisää säännön. Sitten toisen. Sitten kolmannen. Jokainen paikkaa paikallisen ongelman, mutta yhdessä ne luovat järjestelmän täynnä prokseja.
Bezos kuvasi tätä kaavaa 2016 osakaskirjeessään: hyvä prosessi palvelee sinua, jotta voit palvella asiakkaita. Mutta jos et ole tarkkana, prosessista tulee itse tarkoitus.
Juuri näin käy agenttijärjestelmissä.
Sääntö ei ole itse asia. Sääntö on proksi halutulle lopputulokselle. Ja proksit kasaantuvat. Yksi luo poikkeuksia, jotka vaativat lisää sääntöjä. Pian agentti käy läpi kerroksia ohjeita, jotka on lisätty historian saatossa, syitä enää muistamatta.
Ihmisten organisaatioissa tästä tulee byrokratiaa. Agenttijärjestelmissä siitä tulee valtava kehotteiden arpikudosta.
Faktat vanhenevat, mielipiteet pilaantuvat
Fakta kuten "tämä suoritus käynnistettiin ajastetulla tehtävällä klo 3" on vakaa. Se pitää paikkansa riippumatta siitä, mikä malli sen lukee: Claude, GPT, Gemini tai mikä tahansa seuraava ensi neljänneksellä.
Väite kuten "sinun tulisi välttää aliajastusten luomista" on hauras. Se riippuu tulkinnasta. Se voi auttaa yhdessä tilanteessa ja epäonnistua toisessa.
Kun vaihdat mallia, jokainen mielipide kehotteessa on mahdollinen miina. Uudella mallilla on erilaiset päättelytavat, ja huolellisesti kalibroitu "vältä" voi tarkoittaa sille jotain aivan muuta.
Mutta ympäristöön, oikeuksiin, laajuuteen ja rajoituksiin liittyvät faktat yleistyvät paremmin mallien ja poikkeustapausten yli. Siksi faktat ovat parempaa rakennusmateriaalia.
Mallin oikkujen ansa
Tämä on ehkä kontrolliongelman salakavalin muoto: tiimit muuttavat jatkuvasti väliaikaiset mallivirheet pysyväksi järjestelmärakenteeksi.
Malli käyttäytyy huonosti jossain kapeassa tapauksessa. Tiimi lisää suojakaiteen: kehotepaikan, kooditarkistuksen, omituisen haaran, joka on olemassa vain estääkseen yhden tietyn virhetilan.
Tämä paikkaus on veto siitä, että oikku pysyy. Näin ei juuri koskaan käy.
Kolmen kuukauden päästä malli muuttuu. Alkuperäinen käytös katoaa. Mutta paikkaus jää. Kukaan ei halua poistaa sitä, koska ehkä se oli siellä syystä.
Näin järjestelmäkehotteista tulee legacy-koodia.
Tunnistamme vaaran helposti abstraktisti. Mutta käytännössä Sonnetin tämänhetkisten päättelytapojen paikkaaminen kehotteesta toiseen on sama kaava eri muodossa.
Vakiintuneen järjestelmäkäytöksen dokumentointi on arvokasta. Mallin päättelytapojen paikkaaminen on oravanpyörä. Malli muuttuu nopeammin kuin ehdit ylläpitää paikkauksiasi.
Hyvä testitapaus: Käyttöoikeus evätty
Erot näkyvät selvästi työkalujen diagnostiikassa. Kun agentti kohtaa käyttöoikeusvirheen:
Kontrollityyli:
TOKEN puuttuu. Suorita "zero permissions request gmail.send" korjataksesi.
Suora, mutta agentti ei opi mitään. Seuraavalla kerralla eri käyttöoikeusvirhe jumittaa sen taas.
Kontekstityyli:
process.env.GMAIL_TOKEN → olemassa zero connectors inspect gmail → yhdistetty zero permissions inspect gmail.send → evätty
Vaihtoehdot:
- Pyydä käyttäjän hyväksyntä gmail.send-oikeudelle
- Käytä jo valtuutettua polkua, jos sellainen on
Nyt agentti tietää, että token on olemassa, liitin toimii ja juuri tämä oikeus on evätty. Se ymmärtää järjestelmän tilan ja voi päätellä uusia tilanteita, joita sääntöjen kirjoittaja ei osannut ennakoida.
Heuristiikka
Tähän palaan aina:
Aina kun olet kirjoittamassa "älä", "vältä" tai "älä koskaan" kehotteeseen. Pysähdy. Kysy: minkä faktan puutetta tämä sääntö paikkaa?
Yleensä jokin fakta puuttuu. Agentti ei ymmärrä ympäristöään, mitä käyttäjä on hyväksynyt, mitkä toimet ovat peruuttamattomia tai miksi tämä suoritus eroaa tavallisesta keskustelusta.
Kirjoita se fakta ylös. Poista sääntö.
Joskus haluat silti rajan, erityisesti tuhoavissa toimissa, rahansiirroissa tai turvallisuudessa. Kovat kontrollit ovat yhä tärkeitä.
Mutta monet kehotteiden säännöt eivät ole oikeita rajoja. Ne paikkaavat ymmärryksen puutetta. Ja juuri nämä säännöt kasaantuvat ja pilaantuvat.
Tavoite
Tavoitteena ei ole agentti, joka muistaa tarkistuslistan ulkoa.
Tavoitteena on agentti, joka ymmärtää tilanteensa riittävän hyvin tehdäkseen hyviä päätöksiä selkeiden rajojen sisällä.
Yksi filosofia ohjaa toimintaa kasaamalla sääntöjä. Toinen parantaa toimintaa tekemällä maailmasta ymmärrettävän.
Ensimmäinen johtaa byrokratiaan. Toinen ymmärrykseen.
Luo konteksti. Poista arpikudokset. Julkaise agentteja, jotka osaavat ajatella.
