AI-agent ei ole valmis skulptuur, mis pärast käivitamist aastateks muutumatult tööle jääb. Ta on osa ettevõtte töökorraldusest. Kui muutuvad dokumendid, hinnakirjad, ERP, mudel või vastutajad, peab muutuma ka agent.

Hooldus ei tähenda lõputut arendusprojekti. See tähendab selget omanikku, versioonihaldust, testikomplekti ja kokkulepet, millised muudatused vajavad uut kinnitamist.

Mis pärast käivitamist muutub?

Isegi stabiilses ettevõttes muutub aja jooksul vähemalt üks neist:

  • klient saadab uue dokumendipõhja;
  • ERP-i väli või artikliregister muutub;
  • hinnastamisreegel uuendatakse;
  • töötaja roll või ligipääs vahetub;
  • mudelipakkuja väljastab uue versiooni;
  • välise teenuse API muutub;
  • tekib uus erand, mida piloodis polnud;
  • ettevõte tahab agendile anda järgmise tööetapi.

Kui süsteemil pole muutuste haldamise viisi, koguneb parandusi juhuslike promptide, käsitsi tehtud erandite ja ühe inimese mälu sisse. Mõne kuu pärast ei tea enam keegi, miks agent midagi teeb.

Määra protsessiomanik ja tehniline omanik

Pärast käivitamist on vaja vähemalt kahte rolli.

Protsessiomanik teab, milline äriline tulemus on õige. Ta kinnitab reeglid, veaklassid ja selle, millal automatiseerimist võib laiendada.

Tehniline omanik vastutab ühenduste, versioonide, logide, ligipääsude ja testide eest. Ta ei otsusta iseseisvalt, milline hind või tootmisreegel on õige. Vastutuse korraldamisest räägib lähemalt välise AI-juhi rolli käsitlus.

Väikeses ettevõttes võib üks inimene täita mõlemat rolli, kuid vastutused peavad olema eraldi nimetatud. „AI eest vastutab IT” on liiga ebamäärane, kui ärireegleid otsustab müük või tootmine.

Iga muudatus vajab versiooni

Agendi reegleid ei tohiks muuta otse tootmises ühe kasutaja märkuse põhjal.

Praktiline muudatusvoog on järgmine:

  1. kasutaja märgib vale või ebasobiva tulemuse;
  2. juhtum salvestatakse koos sisendi ja oodatud vastusega;
  3. protsessiomanik otsustab, kas tegu on üldreegli või erandiga;
  4. tehniline omanik teeb muudatuse testversioonis;
  5. käivitatakse regressioonitest;
  6. tulemus kinnitatakse ja avaldatakse uue versioonina;
  7. muudatus dokumenteeritakse lühidalt.

Nii saab vajaduse korral varasema versiooni taastada ja hiljem aru saada, milline muudatus agendi käitumist mõjutas.

Mudelivahetus ei ole lihtsalt tehniline uuendus

Uuem mudel võib olla kiirem, odavam või võimekam. Samal ajal võib ta järgida juhiseid teistmoodi, vormistada vastuseid erinevalt või käituda erandites ootamatult.

Seetõttu ei tohi mudeli nime konfiguratsioonis lihtsalt ära vahetada ja eeldada, et kõik muu jääb samaks.

Enne mudelivahetust tuleb:

  • käivitada sama kontrollvastustega testikomplekt mõlema mudeliga;
  • võrrelda kriitiliste väljade täpsust;
  • mõõta kontrolliaega;
  • kontrollida väljundi formaati;
  • hinnata kiirust ja kasutuskulu;
  • testida tööriistade ning integratsioonide kasutamist;
  • kinnitada, et andmekäitluse tingimused sobivad.

Mudeli vahetamine on uus versioon, mitte hoolduseta taustauuendus. Testikomplekti koostamiseks vaata juhendit, kuidas mõõta AI-agendi täpsust.

Ettevõtte teadmine peab olema mudelist eraldi

Vältimaks sõltuvust ühest mudelipakkujast, hoia võimalikult palju ettevõtte loogikat eraldi kihis:

  • hinnastamis- ja valideerimisreeglid;
  • terminoloogia;
  • artikliregister;
  • väljundiskeemid;
  • kinnitamisahel;
  • testnäited ja kontrollvastused;
  • integratsioonide kirjeldus;
  • promptide ning tööriistade versioonid.

Kui kogu teadmine peidetakse ühe teenusepakkuja vestlusroboti sisse, on lahendust raske auditeerida ja vahetada. Kui reeglid ning testid kuuluvad ettevõttele, saab mudelit võrrelda ja vajadusel asendada.

Täielik sõltumatus pole alati realistlik. Eesmärk on vältida olukorda, kus ettevõte ei saa oma protsessi enam ilma ühe konkreetse pakkujata mõista.

Mida tuleb pidevalt jälgida?

Hoolduse juhtpaneel ei pea olema keeruline. Vähemalt kord kuus tasub vaadata:

  • töödeldud juhtumite arvu;
  • õnnestunud ja peatatud juhtumeid;
  • kriitilisi ning korduvaid vigu;
  • inimese keskmist kontrolliaega;
  • puuduva info osakaalu;
  • käsitsi üle võetud juhtumeid;
  • kasutuskulu;
  • ligipääsu- ja integratsioonivigu.

Mõõdikute eesmärk ei ole näidata, kui palju agent „tööd tegi”. Need peavad näitama, kas protsess püsib kontrolli all ja kas ajavõit säilib.

Millal tuleb agent peatada?

Peatamiskriteeriumid tuleb kokku leppida enne probleemi.

Automaatne töö tuleks vähemalt ajutiselt peatada, kui:

  • kriitiline tuvastamata viga jõuab päris protsessi;
  • sisendivorm muutub ja tulemused halvenevad;
  • integratsioon kirjutab valesse süsteemi või objekti;
  • ligipääsude päritolu pole enam selge;
  • mudel või API muutus ilma regressioonitestita;
  • kontrolliaeg kasvab tagasi käsitöö tasemele;
  • vastutav protsessiomanik puudub.

Peatamine ei ole läbikukkumine. See on kontrollmehhanism, mis hoiab väikese vea väikesena. Loe ka, kuidas korraldada kontrollpunkte juhuks, kui AI-agent eksib.

Hooldusleping peab kirjeldama tulemust

Kui lahendust hooldab väline partner, küsi, mida kuutasu sisaldab.

Hea hoolduskokkulepe määrab:

  • reageerimisaja kriitilisele veale;
  • regulaarse monitooringu;
  • kuutasus sisalduvate muudatuste mahu;
  • testimise ja versioonihalduse;
  • mudeli- ning API-muudatuste käsitluse;
  • andmete ja ligipääsude halduse;
  • dokumentatsiooni ajakohastamise;
  • lahkumis- ja üleandmisprotsessi.

Ligipääsude ja logide kohta vaata ka AI-agendi andmeturbe juhendit.

„Hoiame agendi töös” on liiga ebamäärane. Ettevõte peab teadma, milline osa on partneri ja milline sisemise protsessiomaniku vastutus.

Kuidas agenti turvaliselt laiendada?

Pärast esimese töövoo stabiliseerumist tekib soov anda agendile rohkem õigusi. Tee seda kihiti.

Näiteks:

  1. agent loeb failid ja koostab tabeli;
  2. lisatakse registrivastete leidmine;
  3. lisatakse ERP-i mustandi loomine;
  4. lisatakse tarnijakirja mustand;
  5. alles pärast eraldi testi lisatakse kinnitatud kirja saatmine.

Iga uus kiht suurendab võimalikku kasu ja vea mõju. Seetõttu vajab iga kiht oma vastuvõtukriteeriumi ning peatamisvõimalust.

Korduma kippuvad küsimused

Kui sageli tuleb AI-agent üle testida?

Vähemalt pärast iga olulist mudeli-, reegli-, dokumendipõhja või integratsioonimuudatust. Lisaks tasub teha perioodiline test vastavalt protsessi mahule ja riskile.

Kas agent õpib ise kasutajate parandustest?

Ta võib tagasisidet koguda, kuid tootmisreeglid ei tohiks automaatselt muutuda. Parandus tuleb kinnitada, versioonida ja testida.

Kellele kuuluvad promptid ja töövood?

See peab olema lepingus kirjas. Ettevõttel peaks olema ligipääs oma reeglitele, testidele, integratsioonikirjeldusele ja andmete ekspordile.

Kas mudelipakkujat saab hiljem vahetada?

Sageli saab, kui ärireeglid, väljundiskeemid ja testid on mudelist eraldi. Vahetamine vajab siiski uut kvaliteedi-, kulu- ja andmekäitluse testi.

Kui tahad AI-agenti, mida saab pärast pilooti kontrollitult arendada, räägime 30 minutit. Paneme juba esimeses etapis paika omandi, testid ja hoolduspiirid.

Allikad