Microsoftin viesti on selkeä: agentin rakentaminen käy nopeasti ja helposti. Se pitää paikkansa, kun kyse on henkilökohtaisesta agentista, joka on rakennettu Microsoft 365 Copilotin Agent Builderillä ja hakee vastauksia muutamasta omasta tiedostosta.
Ongelmat alkavat yleensä vasta silloin, kun sama ajattelutapa siirretään tiimin tai koko organisaation käyttöön tarkoitettuun agenttiin.
Olemme nähneet tämän useissa asiakasorganisaatioissa. Agentti vastaa välillä hyvin ja välillä epätarkasti. Se ei löydä dokumenttia, jonka kaikki tietävät olevan SharePointissa. Kaksi käyttäjää saa lähes samaan kysymykseen eri vastauksen. Tekijän omassa testissä kaikki toimi.
Useimmiten ongelma ei ole teknologiassa. Ongelma on siinä, että tuotantokäyttöön tarkoitettua agenttia käsitellään yksittäisenä teknisenä toteutuksena, vaikka sitä pitäisi käsitellä palveluna.
Microsoft jakaa agenttikehityksen kolmeen vyöhykkeeseen: henkilökohtaiset tuottavuusagentit, Copilot Studiolla rakennetut tiimien ja yksiköiden agentit sekä liiketoimintakriittiset ratkaisut, joissa mukana on myös Azure AI Foundry. Mitä ylemmäs noustaan, sitä enemmän tarvitaan IT:n, tietoturvan ja liiketoiminnan yhteistyötä.
Ennen rakentamista pitäisi pystyä vastaamaan kolmeen kysymykseen:
- Kenelle agentti tehdään?
- Minkä ongelman se ratkaisee?
- Miten onnistuminen mitataan?
"Agentti, joka vastaa kaikkeen organisaation tietoon liittyvään" ei ole käyttötapaus. Se on toive.
"Agentti, jolla huoltohenkilöstö löytää laitekohtaisen toimintaohjeen hyväksytyistä dokumenteista alle minuutissa" on käyttötapaus. Sille voidaan määritellä tietolähteet, testikysymykset ja hyväksymiskriteerit.
Kun käyttötapaus on rajattu, seuraavat seitsemän asiaa ratkaisevat, jääkö agentti demoksi vai selviääkö se tuotantoon.
1. ALM-prosessi
Agenttia ei pidä kehittää samassa ympäristössä, jossa käyttäjät sitä käyttävät.
Microsoft suosittelee kolmea ympäristöä:
- Kehitys
- Testaus
- Tuotanto
Muutokset tehdään kehitysympäristössä, testataan erikseen ja julkaistaan tuotantoon vasta hyväksynnän jälkeen.
Ilman tätä yksi virheellinen muutos voi mennä suoraan käyttäjille. Agentin toiminta muuttuu, mutta kukaan ei tiedä miksi eikä edellistä versiota pystytä palauttamaan.
Power Platformin pipelinet tarjoavat tähän kevyen ratkaisun. Tavoitteena ei ole raskas DevOps-prosessi vaan hallittu muutoshallinta. Agentin toimivuus ei saa perustua yksittäisen kehittäjän muistiin tai varovaisuuteen.
2. Hallintamalli
Agentti toimii aina osana Power Platform -ympäristöä.
Ympäristöstrategia, DLP-käytännöt, käyttöoikeudet, yhdistimien rajoitukset ja Managed Environments -ominaisuudet määrittävät pitkälti sen, mitä agentti voi tehdä.
Hallintamallin tulee vastata esimerkiksi seuraaviin kysymyksiin:
- Kuka saa rakentaa agentteja?
- Kuka saa julkaista niitä?
- Milloin tarvitaan tietoturvan arviointi?
- Miten käytöstä poistuvat agentit tunnistetaan?
- Kuka vastaa seurannasta ja ylläpidosta?
Hallinnan pitää kuitenkin olla riskiperusteista. Henkilökohtaista agenttia ei kannata käsitellä samalla tavalla kuin liiketoimintakriittistä agenttia, joka käyttää luottamuksellista tietoa tai suorittaa toimintoja taustajärjestelmissä.
Siksi organisaation kannattaa määritellä vähintään eri vaatimustasot henkilökohtaisille, tiimitason ja liiketoimintakriittisille agenteille.
Hyvän hallintamallin tarkoitus ei ole estää innovointia vaan tehdä turvallisesta rakentamisesta ennustettavaa.
3. Tietolähteiden indeksointi
Tiedonhakuagentin laatu riippuu kahdesta asiasta:
- Löytyykö oikea tieto?
- Muodostetaanko siitä oikea vastaus?
Jos oikea sisältö ei koskaan päädy agentin käyttöön, promptien hiominen ei ratkaise ongelmaa.
SharePoint-lähteet haetaan Microsoftin Graph-haun kautta. Copilot Studion generatiivisessa tilassa agentille voidaan määrittää rajallinen määrä tietolähteitä, joten tietopohjan laatu korostuu.
Ennen agentin rakentamista kannattaa:
- arkistoida vanhentunut sisältö
- poistaa päällekkäiset dokumentit
- tarkistaa käyttöoikeudet
- yhtenäistää dokumenttirakennetta
- päättää, saako agentti käyttää myös yleistä tietoa vai ainoastaan lähteistä löytyvää sisältöä
Moni tekoälyongelmaksi luultu haaste on todellisuudessa tiedonhallinnan ongelma. Agentti vain paljastaa sen näkyvästi.
Jos tietopohjan siivous ei riitä, seuraava askel voi olla Azure AI Search.
Omassa indeksissä voidaan hallita tarkemmin:
- indeksoitavaa sisältöä
- dokumenttien pilkkomista
- metatietojen käyttöä
- hakulogiikkaa
- hakutulosten järjestämistä
Hybridihaku yhdistää avainsanahaun ja vektorihaun. Näin voidaan löytää sekä tarkkoja termejä että käsitteellisesti samankaltaista sisältöä. Semanttinen uudelleenjärjestys parantaa osumien laatua entisestään.
Azure AI Search voi nostaa tiedonhaun laadun uudelle tasolle, mutta samalla siirtää enemmän vastuuta organisaatiolle. Microsoft 365 -haussa käyttöoikeudet huomioidaan pitkälti valmiiksi. Omassa indeksissä tämä on suunniteltava itse.
Siksi etenemisjärjestyksen pitäisi olla:
- Rajaa käyttötapaus
- Kunnosta tietopohja
- Testaa valmiilla haulla
- Mittaa laatu
- Siirry omaan indeksiin vasta tarvittaessa
4. Testaaminen
Agentti ei ole valmis, kun tekijä on saanut viiteen kysymykseen oikean vastauksen.
Todelliset käyttäjät käyttävät eri termejä, tekevät kirjoitusvirheitä, kysyvät epätarkasti ja olettavat agentin ymmärtävän organisaation sisäisen kielen.
Ennen tuotantoa kannattaa rakentaa arviointiaineisto, joka sisältää:
- tavallisia käyttäjäkysymyksiä
- saman asian eri muotoiluja
- organisaation omia termejä ja lyhenteitä
- kysymyksiä, joihin ei löydy vastausta
- tilanteita, joissa agentin pitäisi kieltäytyä vastaamasta
Azure AI Foundryn RAG-arviointien hyödyllisin oppi on, että laatua pitää tarkastella useasta näkökulmasta:
- löytyikö oikea konteksti
- perustuuko vastaus lähteisiin
- vastaako vastaus kysymykseen
- puuttuuko jotain olennaista
Ilman tällaista erottelua kaikki ongelmat näyttävät samalta: "agentti vastaa huonosti".
Todellinen syy voi kuitenkin löytyä tiedosta, käyttöoikeuksista, hausta tai agentin ohjeistuksesta.
5. Jakaminen käyttäjille
Jakaminen näyttää yhdeltä painikkeelta, mutta käytännössä kyse on käyttöönottoprojektista.
Copilot Studiossa jakamiseen liittyy rooleja, käyttöoikeuksia ja hallintasääntöjä. Lisäksi käyttäjien täytyy ymmärtää:
- mihin agenttia kannattaa käyttää
- mitä tietolähteitä se hyödyntää
- miten vastauksiin tulisi suhtautua
- mistä virheistä voidaan antaa palautetta
Käyttöönotto epäonnistuu usein kahdella tavalla: agentti ei tavoita oikeita käyttäjiä tai se julkaistaan liian laajasti ennen kuin sen laatua on arvioitu.
Tekninen julkaisu on vasta ensimmäinen askel.
6. Ylläpito
Julkaisupäivä on agentin elinkaaren alku, ei loppu.
Tietolähteet muuttuvat, dokumentit päivittyvät ja käyttäjät löytävät jatkuvasti uusia käyttötapoja. Samalla Microsoft kehittää alustaa jatkuvasti eteenpäin.
Copilot Studion analytiikka auttaa tunnistamaan:
- laatuongelmia
- toistuvia kysymyksiä
- puuttuvia sisältöjä
- käyttäjien todellisia käyttötapoja
On myös hyväksyttävä, että generatiiviset vastaukset eivät ole täysin deterministisiä. Saman tyyppinen kysymys voi tuottaa hieman erilaisia vastauksia eri tilanteissa.
Siksi seuranta ja kehittäminen kuuluvat agentin normaaliin elinkaareen samalla tavalla kuin mille tahansa muullekin liiketoimintapalvelulle.
7. Omistajuus
Yksi yleisimmistä riskeistä on, että agentti jää yhden innokkaan kehittäjän vastuulle.
Tuotantoagentti tarvitsee käytännössä kolme omistajuutta:
Liiketoimintaomistaja
Vastaa siitä, että agentti ratkaisee edelleen oikeaa ongelmaa.
Tekninen omistaja
Vastaa ratkaisun toimivuudesta, ympäristöistä ja muutosten hallinnasta.
Tietosisällön omistaja
Vastaa siitä, että tietolähteet pysyvät ajan tasalla.
Pienessä organisaatiossa sama henkilö voi hoitaa useita rooleja, mutta vastuut pitää silti nimetä.
Ilman omistajuutta agentti jää helposti ilman ylläpitoa heti ensimmäisen käyttöönottovaiheen jälkeen.
Helppo ja tuotantokelpoinen ovat eri asioita
Agentin rakentaminen on helppoa. Tuotantokelpoisen agentin rakentaminen ei ole.
Ero näiden kahden välillä ei yleensä ratkea yhdellä paremmalla promptilla tai uudella tekoälymallilla. Se ratkeaa sillä, onko agentin ympärille rakennettu oikeat rakenteet:
- käyttötapaus
- ALM-prosessi
- hallintamalli
- laadukas tietopohja
- testaus
- käyttöönotto
- ylläpito
- omistajuus
Hyvä uutinen on, että ensimmäisen agentin ongelmat eivät yleensä tarkoita epäonnistunutta investointia. Useimmiten agenttia ei tarvitse rakentaa uudelleen. Sen ympäriltä pitää korjata ne rakenteet, joiden varassa sen odotetaan toimivan.
Tuotantokelpoinen agentti ei ole vain tekninen toteutus. Se on yhdistelmä tiedonhallintaa, hallintamallia, tietoturvaa, omistajuutta ja jatkuvaa kehittämistä.
Juuri niiden varaan onnistuneet agentit rakennetaan.
Kirjoittaja
Jocke Wilén