Mitä tietokoneen käyttö tarkoittaa ja miksi sillä on merkitystä? Tietokoneen käyttö on yksinkertainen ajatus, jolla on laajoja vaikutuksia: sen sijaan, että pyytäisimme malleja vastaamaan kysymyksiin, pyydämme niitä käyttämään ohjelmistoja – selaamaan verkkosivustoja, täyttämään lomakkeita, etenemään työnkuluissa napsauttamalla ja suorittamaan tehtäviä itsenäisesti alusta loppuun.
Näin voidaan hoitaa monia tosielämän tehtäviä, jotka ovat nykyisin hajallaan eri käyttöliittymissä: esimerkiksi varauksia ja verkkokauppaostoksia alusta loppuun, monivaiheista matkasuunnittelua sekä taustatoimintojen työnkulkuja, joille ei ole selkeää API-vastinetta. Nämä ongelmat eivät ole uusia. Uutta on se, että ne voidaan ratkaista yleiskäyttöisillä malleilla.
Anthropicin ja OpenAI:n viimeaikaiset järjestelmät ovat osoittaneet, että agentit osaavat paitsi toimia myös päätellä tilan perusteella, toipua virheistä ja muodostaa tehtäväkohtaisia ratkaisuja lennossa. Selain muuttuu näin agenttien yleiseksi suoritusympäristöksi, mutta samalla syntyy välitön suunnittelukysymys: kuinka suuri osa ympäristöstä pitäisi antaa mallin käyttöön?
Varhaisissa järjestelmissä ratkaisu oli kääriä selain kiinteäksi joukoksi turvallisia, ennalta määritettyjä toimintoja. Kuten tässä kirjoituksessa esitämme, tämä lähestymistapa on saavuttamassa rajansa.
Selainagentteja rakennettaessa ensimmäinen ajatus on usein tuttu: malliin ei pidä luottaa liikaa.
Siksi käärimme selaimen. Tarjoamme ennalta määritettyjä työkaluja, kuten click, type, scroll, select ja read_text. Yksinkertaistamme dokumenttioliomallia (DOM). Pienennämme toimintojen joukkoa. Pyrimme tekemään toiminnasta ymmärrettävää ja hallittavaa itse suunnittelemiemme abstraktioiden avulla.
Tämä on järkevä lähtökohta. Yhä useammin se on kuitenkin väärä pitkän aikavälin arkkitehtuuri.
Edistyneiden mallien parantuessa ongelmana ei enää ole vain työkalujen puute. Ongelma on, että pakotamme mallin toimimaan abstraktioiden kautta, jotka poistavat liikaa alla olevan järjestelmän ominaisuuksia. Tiivistämme sotkuisen ja dynaamisen ympäristön kiinteäksi toimintorajapinnaksi ja pyydämme sitten mallia suoriutumaan hyvin tästä tiedonmenetyksestä huolimatta.
Tämä kompromissi käy yhä vähemmän houkuttelevaksi.
Tutkimamme muutos on helppo kuvailla, mutta sen seuraukset ovat merkittäviä. Sen sijaan, että pitäisimme agenttia ennalta määritettyjen toimintojen valitsijana, käsittelemme sitä ohjelmia muodostavana järjestelmänä, joka toimii rajatussa ajoympäristössä.
Malleista on tullut todella hyviä, eivätkä ne enää tarvitse abstraktioihin perustuvia suojakaiteita. Ne tarvitsevat koko toiminta-avaruuden voidakseen suunnitella ja suorittaa tehtävän sekä kehittää ratkaisua, kunnes tavoite täyttyy.
Tämä kirjoitus käsittelee siirtymää abstraktioita painottavasta selainautomaatiosta rajattuun tietokoneen käyttöön sekä sitä, mikä muuttuu, kun järjestelmät suunnitellaan näin.
Ongelma ei ole se, että kiinteät toimintorajapinnat olisivat käsitteellisesti vääriä. Verkko ei vain mukaudu niihin.
Nykyaikaiset käyttöliittymät rakennetaan Reactilla, Vuella ja Angularilla. Niissä on asynkronisia tilapäivityksiä, synteettisiä tapahtumajärjestelmiä ja upotettuja kolmannen osapuolen pienoissovelluksia, jotka toimivat eri alkuperää olevissa iframe-kehyksissä omine elinkaarineen. Kääre, joka käskee ”kirjoita tähän syötekenttään”, toimii vain, jos sivun käsitys kirjoittamisesta vastaa omaasi. Monilla sivuilla näin ei ole. Arvon asettaminen suoraan ohittaa usein kokonaan sovelluskehyksen muutosten tunnistuksen. Syötekenttä näyttää täytetyltä. Tarkistus ei koskaan käynnisty. Lomake ei edelleenkään toimi.
Tämän voi paikata. React-syötekentille voi lisätä erityistapauksia, kohdistamisen jälkeen voi lähettää blur-tapahtumia ja ennen tilan lukemista voi odottaa verkkoliikenteen hiljenemistä. Jokainen korjaus toimii omassa tilanteessaan. Yhdessä ne kuitenkin muodostavat järjestelmän, jota on yhä vaikeampi ylläpitää ja joka on yhä vahvemmin sidoksissa jo kohdattuihin sivustoihin.
Syvempi ongelma on, että abstraktiokerrokseen koodataan oletuksia vuorovaikutuksen toiminnasta, minkä jälkeen huomataan verkon perustuvan erilaisiin oletuksiin.
Ajatellaan Stripe- tai Adyen-maksulomaketta, joka on upotettu eri alkuperää olevaan iframe-kehykseen. Kääre ei pääse siihen suoraan, koska se sijaitsee eri alkuperässä. read_text-työkalu ei pysty tarkastelemaan sen sisäistä tilaa. type-työkalu ei pysty käyttämään sen syötekenttiä. Kääreeseen perustuva agentti ajautuu tässä umpikujaan. Abstraktio suunniteltiin pääasiakirjaa varten. Varsinainen tehtävä sijaitsee paikassa, jota abstraktio ei näe.
Samanlainen yhteensopimattomuus ilmenee myös vähemmän ilmeisissä työnkuluissa. Sovelluskehyksen hallitsema avattava valikko ei välttämättä reagoi suoriin napsautuksiin lainkaan, koska näkyvä elementti ei ole varsinainen säädin. Taustalla olevan tilasiirtymän käynnistäminen voi edellyttää näppäimistötapahtumien sarjaa. Ulospäin käyttöliittymä näyttää napsautettavalta. Abstraktio käskee ”napsauta”. Mitään ei tapahdu.
Toinen esimerkki on monivaiheinen modaali-ikkunan työnkulku, jossa näkyvän DOM-rakenteen päivitykset tapahtuvat sisäisten tilamuutosten jäljessä. Oikea seuraava toiminto riippuu tilasiirtymästä, joka ei vielä näy kääreen havaitsemissa elementeissä. Kääreeseen perustuva agentti toimii liian aikaisin tai lukee vanhentunutta tilaa, koska sen näkymä järjestelmään on puutteellinen.
Jokaisessa tapauksessa abstraktio kätkee agentin tarvitsemat signaalit.
Alemmalla tasolla toimiva malli voi selviytyä näistä tilanteista tarkastelemalla ajantasaista DOM-rakennetta, päättelemällä kehysten rajojen perusteella ja muodostamalla vuorovaikutussarjan kyseistä rajapintaa varten. Kyse ei ole siitä, että malli olisi luonnostaan älykkäämpi. Sillä vain on käytettävissään aiemmin poistettu tieto.
Tavoittelemamme muutos on helppo kuvailla: sen sijaan, että pyytäisimme mallia valitsemaan ennalta määritetyistä toiminnoista, annamme sille alemman tason suoritusrajapinnan ja rajaamme sitä abstraktiosuunnittelun sijaan ajonaikaisilla toimintaperiaatteilla.
Suunnitteluratkaisu perustuu alan laajempaan muutokseen kohti alemman tason perustyökaluja. Ne hyödyntävät agentin luontaista kykyä korjata toimintaansa ajon aikana ja tuottaa laadukasta koodia, toisin kuin kestävät mutta kiinteästi koodatut erityistyökalut, jotka heikentävät mallin kykyä mukautua eri ympäristöihin.
Tästä kertovat Claude Coden suosio monien kehittäjien ensisijaisena työkaluna ja alan laajempi siirtyminen päätepohjaisiin agentteihin. Claude Coden suurin etu ei ole itse malli vaan alemman tason arviointikehys. Kun mallille annetaan vähemmän mutta modulaarisempia ja alemman tason työkaluja – eli pääte – työkalukutsut onnistuvat paremmin. Tämä johtuu pääasiassa siitä, että agentti voi päätellä ja luoda tehtävään sopivia mukautettuja komentosarjoja sen sijaan, että se yrittäisi käyttää yleiskäyttöisiä työkaluja, jotka kuormittavat konteksti-ikkunaa.
Selainautomaation tapauksessa tämä tarkoittaa käytännössä sitä, että malli voi tarkastella suoraan sivun ajantasaista tilaa, siirtyä kehysten välillä ja muodostaa nykyiseen käyttöliittymään räätälöityä vuorovaikutuskoodia sen sijaan, että kaikki muunnettaisiin kiinteäksi joukoksi ennalta rakennettuja toimintoja.
Malli toimii vähemmän valitsijan ja enemmän ajonaikaisen toteutuksen laatijan tavoin. Se tarkastelee nykyistä tilaa, päättelee käyttöliittymän perusteella ja muodostaa vuorovaikutuslogiikan juuri kyseiseen tilanteeseen. Se voi muodostaa monivaiheisia sarjoja, mukautua epätavallisiin työnkulkuihin ja vahvistaa tulokset ennen jatkamista. Kun toiminto epäonnistuu, malli näkee taustalla olevan virheen ja korjaa toimintaansa. Tämä on tehokkaampaa ja riskialttiimpaa, mutta vastaa paljon paremmin ongelman todellista luonnetta.
On tärkeää huomata, ettei abstraktiokerroksen poistaminen vähennä järjestelmän kurinalaisuutta. Kurinalaisuus vain siirtyy muualle.
Aiemmin kääreiden suunnitteluun ja poikkeustapausten käsittelyyn kuulunut työ siirtyy kolmeen paikkaan: kehotteeseen, josta tulee eräänlaista toiminnallista koulutusta; ajoympäristöön, joka valvoo esimerkiksi siirtymisalueen, arkaluonteisten toimintojen ja uudelleenyritysten rajoja; sekä arviointikerrokseen, joka arvioi onnistumisen lisäksi välivaiheiden oikeellisuutta. Vähemmän hauraita abstraktioita. Vahvemmat ympäröivät järjestelmät.
Yksi tämän muutoksen seurauksista on, että tuotekoodi usein yksinkertaistuu, vaikka koko järjestelmä pystyy entistä enempään. Sen sijaan, että vuorovaikutusmallit koodattaisiin uudelleenkäytettäviksi kääreiksi, agentti muodostaa toimintansa ajon aikana. Laajenevan erikoistyökalujen ja poikkeustapauslogiikan kirjon sijaan ylläpidetään pientä joukkoa tehokkaita perustoimintoja ja rajattua ajoympäristöä.
Tämä muuttaa myös järjestelmän yleistettävyyttä. Kääreisiin perustuva agentti yleistää hyvin tehtäviin, jotka muistuttavat jo rakennettuja kääreitä. Rajatussa ajoympäristössä toimiva agentti yleistää tehtäviin, joilla on yhteinen suoritusalusta, vaikka näkyvä käyttöliittymä olisi erilainen.
Esimerkiksi hakulomakkeen, varausprosessin tai asetussivun käyttö voi näyttää käyttöliittymätasolla täysin erilaiselta. Taustalla niissä on kuitenkin samoja toimintamalleja: tilan lukeminen, tapahtumien käynnistäminen, tulosten vahvistaminen ja asynkronisten päivitysten käsittely. Tällä tasolla toimiva järjestelmä mukautuu luontevammin eri tehtäviin.
Uudelleenkäytettävä osa ei ole toimintoluettelo vaan mallin kyky tarkastella tilaa, toimia turvallisesti ja vahvistaa tulokset.
Tämän työn selkein opetus on, ettei luotettavuus synny tarjoamalla mallille lisää aputoimintoja. Usein se syntyy tarjoamalla vähemmän mutta tehokkaampia perustoimintoja ja rajaamalla ne oikein. Liiallinen avustaminen koodaa kiinteästi oletuksia siitä, miten tehtävä pitäisi suorittaa. Rajoitteet määrittävät turvallisen toiminnan rajat ja antavat mallin löytää paikallisesti parempia ratkaisuja.
Tehokkaampi suoritusrajapinta edellyttää myös tarkempaa turvallisuusmallia. Kun agenttia ei enää rajata pieneen joukkoon ennalta määritettyjä toimintoja, se toimii käytännössä suoraan oikeissa ohjelmistoissa. Tämä muuttaa riskiprofiilia välittömästi.
Suunnittelussa on huomioitava neljä asiaa:
Tietojen paljastuminen. Kun agentti käyttää oikeita käyttöliittymiä, se kohtaa usein arkaluonteisia tietoja. Siksi tietojen peittämiseen ja käyttöoikeuksien hallintaan tarvitaan järjestelmällinen lähestymistapa. Tietoja tulisi näyttää vain suorituksen kannalta välttämättömissä tilanteissa, ja lokeja sekä jäljitystietoja on käsiteltävä huolellisesti, jotta havainnoitavuudesta ei tule järjestelmän arkaluonteisinta osaa.
Suorituksen laajuus. Tehokas agentti ei saa voida toimia mielivaltaisesti. Käytännössä on rajattava, minne se voi siirtyä, mitä verkkotunnuksia se voi käyttää ja minkä järjestelmien kanssa se saa olla vuorovaikutuksessa. Rajoitukset on pantava täytäntöön ajoympäristössä eikä jätettävä kehotteisiin kirjatuiksi käytännöiksi.
Ympäristön luotettavuus. Nykyaikaiset käyttöliittymät voivat sisältää harhaanjohtavia tai tarkoituksellisen vihamielisiä ohjeita, sisältöjä tai työnkulkuja. Sivun sisällön kautta tehtävä kehoteinjektio on todellinen hyökkäyspinta. Järjestelmä tarvitsee selkeän ohjehierarkian, tarkistuksia ja lopetusehtoja, jotta agentti ei seuraa tahattomia ohjeita.
Autonomian asteikko. Kaikkien toimintojen ei pidä olla täysin autonomisia. Monissa tuotantoympäristöissä autonomiaa on tärkeää käsitellä asteikkona. Järjestelmä voi tutkia ja suorittaa tehtäviä hyvin agenttimaisesti mutta edellyttää silti hyväksyntää tiettyihin toimintoihin.
Perusperiaate on selkeä: kun mallille annetaan enemmän valtaa, sitä ympäröivää järjestelmää on vahvistettava. Autonomia ilman toimintaperiaatteita ei ole valmis tuotantokäyttöön.
Lakkasimme kysymästä, mitkä selaintoiminnot pitäisi antaa mallin käyttöön.
Aloimme kysyä, miten mallille voidaan tarjota koko toiminta-avaruus ja miten sen ympärille voidaan luoda turvallisuuden säilyttävät ajonaikaiset toimintaperiaatteet.
Tämä näkökulman muutos muuttaa painopisteitä. Toimintojen luokittelulla ja kääreiden kattavuudella on vähemmän merkitystä. Ajonaikaisilla toimintaperiaatteilla, havainnoitavuudella ja vaihekohtaisella arvioinnilla on enemmän merkitystä. Mallin kyvykkyys ja järjestelmäsuunnittelu eivät korvaa toisiaan. Mallien parantuessa järjestelmän tekemä työ muuttuu entistä tärkeämmäksi, ei vähemmän tärkeäksi.
Esittelyissä toimivat selainagentit onnistuvat usein siksi, että tehtävä on rajattu ja ympäristö toimii niiden kannalta suotuisasti. Tuotantojärjestelmät tarvitsevat muuta: rajattua suoritusta, instrumentoitua toimintaa ja arviointia, joka erottaa oikean tuloksen onnekkaasta sattumasta.
Vähemmän kääreiden suunnittelua. Enemmän järjestelmäsuunnittelua.
Vaikka keskityimme selainagentteihin, tämä viittaa laajempaan tapaan tarkastella tietokoneen käyttöä järjestelmäteknisenä alana.