Skip to main content

29 Tekniikkaa

29Tekniikkaa
29Tekniikka logo
29Tekniikkaa

Recent Post

AWS AgentCore: AI-agentin vieminen tuotantoon on vaikeampi osa

AI-agentin tekeminen ei nykyään vaadi kuukausien projektia. Ensimmäisen version voi saada toimimaan melko nopeasti. Malli osaa keskustella, agentille annetaan muutama työkalu ja sillä voidaan jo hakea tietoa tai tehdä pieniä tehtäviä.
Sitten agentti pitäisi antaa oikeille käyttäjille.
Siinä kohtaa vastaan tulee yleensä aivan eri kysymyksiä.
Missä agentti ajetaan? Miten käyttäjän ja agentin oikeudet erotetaan toisistaan? Mitä tapahtuu, jos ulkoinen API ei vastaa? Entä jos sama tehtävä kestää kymmenen minuuttia? Mihin keskustelun tila tallennetaan? Ja ennen kaikkea: pystyykö kehittäjä myöhemmin selvittämään, miksi agentti teki juuri sen mitä se teki?
Näihin ongelmiin AWS on rakentanut Amazon Bedrock AgentCoren.
AgentCore ei ole uusi tapa kirjoittaa promptteja eikä valmis “älykäs työntekijä”, jonka voi vain ottaa käyttöön. Sen rooli on paljon käytännöllisempi. Se tarjoaa ympärille palveluita, joita tarvitaan, kun agentti ei enää ole pelkkä kokeilu vaan osa oikeaa ohjelmistoa.
Tässä vaiheessa myös itse agentin suunnittelu alkaa merkitä enemmän kuin käytetty kielimalli.

Ensimmäinen demo kertoo yllättävän vähän

AI-agentin demo on helppo saada näyttämään hyvältä.
Käyttäjä kysyy esimerkiksi: “Missä vaiheessa asiakkaan tilaus on?”
Agentti hakee tilauksen tiedot, lukee vastauksen ja kertoo tilanteen. Jos kaikki tapahtuu muutamassa sekunnissa, vaikutelma on hyvä.
Tuotannossa sama kysymys voi johtaa aivan toiseen tilanteeseen.
Asiakkaan tiedot ovat toisessa järjestelmässä. Tilaustiedot ovat ERP:ssä. Toimituksen seuranta tulee ulkopuolisesta rajapinnasta. Käyttäjällä ei ole oikeutta nähdä kaikkia tietoja. Yksi palveluista on hetkellisesti hidas.
Nyt agentin pitää tehdä muutakin kuin muodostaa hyvä vastaus.
Sen pitää tietää, mitä se saa hakea, mitä sen kannattaa hakea ja mitä tehdä silloin, kun jokin vaihe epäonnistuu.
Tätä eroa ei yleensä näe ensimmäisessä demossa. Se näkyy vasta tuotannossa.

Agentin ajaminen on oma ongelmansa

☑️ Perinteinen verkkopalvelu on usein melko suoraviivainen. Pyyntö tulee sisään, palvelin käsittelee sen ja vastaus lähtee takaisin.
☑️ Agentin suoritus voi olla paljon pidempi.
☑️ Yksi tehtävä voi sisältää useita mallikutsuja ja työkaluja. Agentti voi esimerkiksi hakea asiakastiedot, tarkistaa laskutustilanteen, kysyä vielä toisesta järjestelmästä ja tehdä lopuksi yhteenvedon.
☑️ Jos tämä kaikki rakennetaan itse yhden palveluprosessin ympärille, arkkitehtuuri alkaa nopeasti kasvaa.
☑️ AWS AgentCore Runtime on tarkoitettu juuri agentin suoritusympäristöksi. Ajatuksena on, että kehittäjä säilyttää oman agenttilogiikkansa, mutta sen ajamiseen ei tarvitse rakentaa kaikkea infrastruktuuria alusta lähtien.
☑️ Tämä on tärkeä ero.
☑️ Runtime ei päätä, miten agentin pitäisi ajatella. Se ei myöskään korjaa huonoa orkestrointia. Se tarjoaa paikan, jossa agentti voidaan ajaa hallitummin tuotannossa.
☑️ Jos agentti tekee viisi turhaa API-kutsua yhden sijasta, Runtime ei muuta niitä viideksi hyödylliseksi kutsuksi.

Muisti kuulostaa yksinkertaiselta, kunnes sitä oikeasti tarvitaan

➢ Yksi ensimmäisistä kysymyksistä tulee usein vastaan keskustelun aikana: “Mitä agentti muistaa?”
➢ Pienen demon kohdalla vastaus voi olla helppo. Kaikki keskustelu voidaan pitää nykyisessä kontekstissa.
➢ Pitkässä käytössä ratkaisu ei enää toimi samalla tavalla.
➢ Jos käyttäjä käy agentin kanssa pitkän keskustelun, kaikkea vanhaa sisältöä ei ole järkevää lähettää mallille jokaisen uuden viestin mukana. Konteksti kasvaa ja samalla myös kustannukset ja käsittelyaika voivat kasvaa.
➢ Toisaalta jotkut asiat olisi hyvä muistaa.
➢ Jos käyttäjä on esimerkiksi aikaisemmin kertonut työskentelevänsä tietyn projektin parissa, sama tieto voi olla hyödyllinen myöhemmin.
➢ Tässä Amazon Bedrock AgentCore Memory tulee mukaan. Sen avulla agentin käyttöön voidaan rakentaa lyhyemmän ja pidemmän aikavälin muistia.
➢ Mutta tekninen toteutus ei poista tärkeintä kysymystä:
  • Tämä on enemmän sovellussuunnittelua kuin AI-kysymys.
  • Kaikkea keskustelua ei tarvitse tallentaa. Eikä kaikkea tallennettua tietoa tarvitse myöhemmin antaa agentille.
  • Yritysympäristössä mukaan tulee vielä yksi asia: kuka saa nähdä muistissa olevan tiedon?
  • Jos sama agentti palvelee eri asiakkaita tai eri organisaation osastoja, muistia ei voi käsitellä yhtenä suurena tietovarastona.
Mitä tietoa kannattaa säilyttää?

Työkalut muuttavat agentin riskiprofiilin

Chatbotin kanssa väärä vastaus on ikävä.
Agentin kanssa väärä toiminto voi olla paljon vakavampi.
Ajatellaan esimerkiksi yrityksen sisäistä agenttia, jolla on pääsy taloushallinnon järjestelmään. Se voi hakea laskuja ja tarkistaa niiden tilan.
Tämä on vielä melko helppo rajata.
Sitten joku ehdottaa: “Voisihan agentti myös tehdä hyvityslaskun?”
Teknisesti kyllä.
Mutta silloin pitää miettiä käyttöoikeudet uudelleen. Agentilla ei pitäisi olla oikeutta tehdä kaikkea vain siksi, että taustalla oleva API sallii sen.
AgentCore Gateway on yksi ratkaisu tähän kokonaisuuteen. Sen kautta agentille voidaan tuoda erilaisia työkaluja ja API-rajapintoja hallitummin. Gateway voi yhdistää esimerkiksi olemassa olevia API-palveluita, Lambda-funktioita ja MCP-pohjaisia työkaluja agentin käyttöön.
Käytännössä hyöty tulee siitä, että työkalujen ympärille voidaan rakentaa selkeämpi hallintakerros.
Se ei kuitenkaan tarkoita, että kaikki yrityksen API:t pitäisi avata agentille.
Päinvastoin.
Hyvässä toteutuksessa agentille annetaan mahdollisimman vähän toimintoja, joilla se pystyy tekemään tehtävänsä.

Käyttöoikeus ei ole vain tekninen yksityiskohta

☑️ Tämä kohta kannattaa miettiä ennen ensimmäistä tuotantoversiota.
☑️ Käyttäjä voi esimerkiksi nähdä oman yrityksensä tilaustiedot. Agentin taustalla oleva tekninen tunnus ei silti saisi automaattisesti nähdä kaikkien yritysten tietoja.
☑️ Muuten järjestelmään syntyy helposti tilanne, jossa käyttäjän käyttöliittymässä on rajaus, mutta agentin kautta sama tieto onkin saatavilla ilman vastaavaa rajoitusta.
☑️ AgentCore Identity tuo tähän oman kerroksensa agenttien identiteetin ja käyttöoikeuksien hallintaan.
☑️ Silti IAM-politiikka ei ratkaise koko ongelmaa.
☑️ Tekninen oikeus käyttää API:a on yksi asia. Se, saako agentti tehdä tietyn liiketoimintatoiminnon, on toinen.
☑️ Esimerkiksi laskun lähettäminen ja laskun lukeminen eivät ole samanarvoisia toimintoja.
☑️ Tuotannossa nämä erot kannattaa tehdä näkyviksi myös agentin työkaluissa.

Kun jokin menee pieleen, loki ei saisi sanoa vain "error"

➢ Tämä on yksi käytännön ero tavallisen backend-palvelun ja agentin välillä.
➢ Jos verkkopalvelu antaa HTTP 500 -virheen, kehittäjä voi usein lähteä tutkimaan pyyntöä, lokia ja palvelun suoritusketjua.
➢ Agentin kohdalla yksi käyttäjän pyyntö voi sisältää monta vaihetta.
➢ Malli päätti käyttää työkalua.
➢ Työkalu kutsui API:a.
➢ API vastasi hitaasti.
➢ Agentti yritti uudelleen.
➢ Seuraava kutsu onnistui.
➢ Lopulta käyttäjälle tuli vastaus.
➢ Jos lokissa näkyy vain lopullinen onnistuminen, puolet tilanteesta jää piiloon.
➢ AgentCore Observability on tarkoitettu juuri tällaiseen näkyvyyteen. Agentin suoritus voidaan yhdistää metriikoihin, lokeihin ja jäljitettävyyteen, jotta yksittäisen tehtävän kulkua voidaan tutkia tarkemmin.
➢ Tämä ei ole vain kehittäjän mukavuus.
➢ Kun tuotannossa tulee ilmoitus “agentti on hidastunut”, pitää pystyä selvittämään, onko syy mallissa, työkalussa, tietokannassa, ulkoisessa palvelussa vai omassa koodissa.
➢ Muuten vian korjaaminen muuttuu arvailuksi.

Hidas agentti ei tarkoita automaattisesti hidasta mallia

Tässä tehdään helposti väärä johtopäätös.
Jos vastaus kestää kahdeksan sekuntia, vaihdetaan nopeampaan malliin.
Se voi auttaa. Mutta ennen sitä kannattaa katsoa koko suoritus.
Jos agentti tekee esimerkiksi neljä peräkkäistä ulkoista API-kutsua ja jokainen kestää sekunnin, mallin vaihtaminen ei poista kolmea ylimääräistä sekuntia.
Vielä huonommassa tapauksessa agentti tekee saman haun uudelleen, koska työkalun vastaus ei ole sen kannalta riittävän selkeä.
Silloin ongelma on agentin toiminnassa.

Yksi käytännön tapa selvittää tätä on seurata yhden tehtävän koko ketjua:

Käyttäjän pyyntö

↓

Mallikutsu

↓

Työkalun valinta

↓

CRM

↓

ERP

↓

Mallikutsu

↓

Vastaus

Kun suoritus näkyy tällä tavalla, pullonkaula löytyy paljon helpommin.

Ulkoiset järjestelmät ovat usein se vaikeampi osa

☑️ Harva yritys rakentaa agentin ympäristöön, jossa kaikki tieto on yhdessä uudessa AWS-palvelussa.
☑️ Todellisuudessa taustalla voi olla vuosia vanha ERP, CRM, oma tietokanta ja joukko eri toimittajien rajapintoja.
☑️ Osa API:sta toimii nopeasti. Osa ei.
☑️ Jotkin järjestelmät palauttavat suuria vastauksia. Toiset rajoittavat kutsujen määrää.
☑️ Agentin kannalta tämä tarkoittaa, että työkalujen suunnittelu on tärkeää.
☑️ Mallille ei kannata antaa työkalua, joka palauttaa 30 000 riviä tietoa, jos käyttäjä tarvitsee niistä viisi.
☑️ Parempi työkalu voi olla esimerkiksi:
get_customer_open_invoices(customer_id)
kuin:
get_everything_from_erp(customer_id)
☑️ Ensimmäinen kertoo agentille paremmin, mitä toimintoa varten tietoa haetaan.
☑️ Samalla myös käyttöoikeuksia ja valvontaa on helpompi hallita.

Entä jos agentin pitää käyttää selainta?

➢ Kaikissa vanhoissa järjestelmissä ei ole kunnollista API:a.
➢ Tämä on tuttu ongelma monessa yrityksessä.
➢ Tieto löytyy kyllä järjestelmästä, mutta sitä käytetään selaimen kautta. Jos API:a ei ole saatavilla, selainautomaatio voi olla yksi vaihtoehto.
➢ AgentCore Browser tarjoaa hallitun ympäristön selaimen kautta tapahtuvalle agenttitoiminnalle.
➢ Tässä kannattaa kuitenkin hyväksyä yksi tosiasia: selainautomaatio on herkempi muutoksille kuin hyvä API-integraatio.
➢ Jos painikkeen nimi muuttuu tai sivun rakenne vaihtuu, agentin toiminta voi rikkoutua.
➢ Siksi selain kannattaa nähdä viimeisenä keinona silloin, kun parempaa rajapintaa ei ole saatavilla, ei automaattisesti parhaana integraatiotapana.

Pitkä tehtävä vaatii eri ajattelua kuin tavallinen API-pyyntö

Agentti voi joskus joutua tekemään tehtävää, joka ei valmistu muutamassa sekunnissa.
Esimerkiksi raportin muodostaminen voi sisältää useita tietolähteitä, laskentaa ja dokumentin luomisen.
Silloin käyttäjän ei välttämättä pitäisi odottaa yhtä HTTP-pyyntöä avoinna koko aikaa.
Tehtävä voidaan käsitellä erillisenä suorituksena, jonka tila voidaan palauttaa käyttäjälle myöhemmin.
Tässä AgentCore Runtime voi olla hyödyllinen, koska agenttien työskentely ei aina muistuta perinteistä lyhyttä request-response-kutsua.
Tärkeintä on kuitenkin tunnistaa tehtävän luonne jo arkkitehtuurivaiheessa.
Jos kymmenen minuutin työ yritetään väkisin rakentaa yhden normaalin verkkopyynnön sisälle, ongelmia tulee ennen pitkää.

Virheenkäsittelyssä ei kannata olla liian optimistinen

☑️ AI-agentin kohdalla “yritä uudelleen” ei ole aina hyvä ratkaisu.
☑️ Jos tiedon hakeminen epäonnistuu, uuden yrityksen tekeminen voi olla täysin järkevää.
☑️ Jos agentti on lähettämässä maksua, samaa toimintoa ei pidä vain toistaa sokkona.
☑️ Mitä jos ensimmäinen pyyntö meni palvelimelle, mutta vastaus katosi matkalla?
☑️ Agentti voi päätellä, ettei maksu onnistunut, ja tehdä saman uudelleen.
☑️ Tässä tarvitaan idempotenssia ja tapahtumien jäljitettävyyttä aivan kuten muissakin maksamiseen tai tilauksiin liittyvissä järjestelmissä.
☑️ Agentti tuo vain yhden uuden muuttujan: toiminnon käynnistävä päätös ei välttämättä tule suorasta ohjelmakutsusta vaan mallin tekemästä työkalun valinnasta.
☑️ Siksi erityisen tärkeät toiminnot kannattaa rajata selkeästi.

Tietoturva alkaa ennen ensimmäistä promptia

➢ Agentin tietoturvaa ei pitäisi rakentaa vasta siinä vaiheessa, kun ensimmäinen tietoturvatarkastus tulee vastaan.
➢ Jos agentti pääsee asiakkaiden henkilötietoihin, sopimuksiin tai taloustietoihin, pääsyn pitää olla perusteltua jo suunnitteluvaiheessa.
➢ Myös muistissa oleva tieto on tässä merkityksellistä.
➢ Jos agentti muistaa asioita käyttäjästä, pitää tietää:
• mitä tallennetaan
• kuinka pitkään tietoa tarvitaan
• kuka siihen pääsee
• voidaanko tieto poistaa
• käytetäänkö samaa muistia usean käyttäjän välillä.
➢ Sama koskee työkaluja.
➢ Agentin pitäisi nähdä vain ne järjestelmät, joita sen tehtävässä tarvitaan.
➢ AWS:n ympäristössä tähän liittyvät muun muassa IAM, agentin identiteetit ja tarvittaessa yksityisen verkon ratkaisut. AgentCore tukee AWS:n mukaan myös VPC-yhteyksiä useissa palvelukokonaisuuksissa.
➢ Tekniikka tarjoaa välineet. Yrityksen pitää silti itse päättää, mikä on sallittua.

Missä AgentCoresta on oikeasti hyötyä?

AgentCorea ei tarvitse ottaa käyttöön vain siksi, että projektissa käytetään AI-agenttia.
Jos kyseessä on pieni kokeilu, yksi työkalu ja muutama testaaja, yksinkertaisempi toteutus voi olla järkevämpi.
Tilanne muuttuu, kun agentti alkaa olla oikea osa yrityksen palvelua.
Esimerkiksi ohjelmistoyrityksessä agentti voi auttaa asiakastuen työssä. Se hakee asiakkaan tietoja CRM:stä, tarkistaa avoimet tukipyynnöt ja etsii sisäisestä tietopankista sopivan ratkaisun.
Aluksi tehtävä vaikuttaa yksinkertaiselta.
Kun käyttäjiä tulee lisää, tarvitaan kuitenkin istuntojen hallintaa, käyttöoikeuksia, lokitusta, mittareita ja tapa selvittää epäonnistuneet suoritukset.
Silloin AgentCoren kaltaisesta tuotantokerroksesta voi olla todellista hyötyä.
Toisessa yrityksessä agentti voi käsitellä sisäisiä dokumentteja tai tehdä analyysityötä. Kolmannessa se voi käyttää vanhaa selainpohjaista järjestelmää.
Tarpeet ovat erilaiset.
Siksi koko AgentCorea ei pidä ajatella yhtenä pakollisena pakettina. Eri osia voidaan käyttää sen mukaan, missä tuotannon todellinen ongelma on.

Agentin kannattaa aloittaa pienestä tehtävästä

➢ Yksi asia on osoittautunut ohjelmistoprojekteissa yleensä järkeväksi: ensimmäistä tuotantoversiota ei kannata rakentaa liian suureksi.
➢ Jos agentin pitäisi heti:
• lukea CRM:ää
• muuttaa ERP-tietoja
• lähettää sähköposteja
• käsitellä dokumentteja
• käyttää selainta
• tehdä raportteja
➢ on vaikea tietää, mikä osa toimii ja mikä ei.
➢ Parempi lähtökohta voisi olla yksi rajattu tehtävä.
➢ Esimerkiksi:
  • Siinä voidaan ensin selvittää:
  • mitä tietoja agentti tarvitsee, mikä API niitä tarjoaa, millaiset oikeudet tarvitaan, mitä tapahtuu virheessä ja kuinka suoritus näkyy lokissa.
  • Kun tämä toimii oikeassa ympäristössä, seuraava toiminto on helpompi lisätä.
  • Tämä ei ehkä ole yhtä näyttävä demo kuin kymmenen työkalun agentti.
  • Tuotannossa sillä ei kuitenkaan ole niin väliä.
Agentti hakee asiakkaan avoimet laskut ja muodostaa niistä yhteenvedon.
  • AWS tarjoaa AgentCorella paljon valmista infrastruktuuria, mutta sovelluksen vaikeimmat päätökset eivät katoa mihinkään.
  • Kehittäjän pitää edelleen päättää, milloin agentti käyttää työkalua, mitä tietoa sille annetaan ja milloin toiminta pitää pysäyttää.
  • Myös mallin vastaukset pitää arvioida.
  • Jos agentti tekee väärän tulkinnan asiakkaan tiedoista, kyse ei ole välttämättä infrastruktuuriongelmasta.
  • Jos se taas käyttää oikeaa työkalua, mutta työkalu palauttaa väärän tiedon, vikaa pitää etsiä toisesta kohdasta.
  • Tuotannossa nämä asiat täytyy pystyä erottamaan toisistaan.
  • Siksi hyvä agenttiarkkitehtuuri on lopulta aika lähellä hyvää tavallista ohjelmistoarkkitehtuuria.
  • Rajaa vastuut.
  • Pidä käyttöoikeudet pieninä.
  • Tee virhetilanteista ennakoitavia.
  • Mittaa sitä, mikä oikeasti tapahtuu.
  • Älä rakenna riippuvuutta yhdestä oletuksesta.
Suurin virhe olisi ajatella, että AgentCore ratkaisee agentin puolesta kaiken
  • AWS AgentCore on kiinnostava erityisesti silloin, kun AI-agentti on siirtymässä kokeilusta oikeaan käyttöön.
  • Sen arvo ei ole siinä, että se tekisi agentista automaattisesti älykkäämmän.
  • Arvo on tuotantoympäristön ympärillä.
  • Agentille voidaan rakentaa hallittu suoritusympäristö. Sen muistia voidaan käsitellä erikseen. Työkalujen käyttöön voidaan rakentaa Gateway-kerros. Identiteetit voidaan käsitellä omana kokonaisuutenaan. Agentin toimintaa voidaan seurata observability-ratkaisuilla.
  • Nämä asiat eivät näy käyttäjälle samalla tavalla kuin hyvä vastaus chatissa.
  • Silti juuri ne ratkaisevat usein sen, kestääkö agentti oikeaa käyttöä.
  • Kun ensimmäinen agentti toimii kehittäjän koneella, projekti on vasta alussa.
  • Kun sama agentti toimii luotettavasti maanantaiaamuna, käyttäjämäärän kasvaessa, ulkoisen API:n hidastuessa ja yhden työkalun epäonnistuessa, ollaan paljon lähempänä oikeaa tuotantojärjestelmää.
  • Ja juuri siinä kohdassa AWS AgentCoren kaltaisen ympäristön merkitys alkaa näkyä.
Mitä tästä kannattaa ottaa mukaan?