Inhimillisen väliintulon osuus: ainoa mittari, joka kertoo, toimiiko tekoälyn käyttöönotto oikeasti
Useimmat yritykset, jotka ajavat tekoälyagentteja tuotannossa, eivät osaa sanoa, kuinka usein nuo agentit oikeasti tarvitsevat ihmistä. Inhimillisen väliintulon osuus on luku, joka vastaa siihen — ja tämän jutun lopussa sinun pitäisi osata laskea se työnkululle, jota jo ajat.
FabricLoopin oma kehys tekoälyorganisaatioille määrittelee inhimillisen väliintulon osuuden suoraan: se kysyy, kuinka usein automatisoitu työ tarvitsee ihmisen. Se on määritelmä, eikä tämä juttu poikkea siitä. Seuraava on se osa, jota käsitesivu ei kirjoita auki: varsinainen lasku, sovellettuna yhteen oikeaan työnkulkuun, luvuilla, jotka tekevät ideasta konkreettisen eikä vain tavoiteltavan.
Mitä luku oikeasti mittaa
Inhimillisen väliintulon osuus (IVO) on se osuus agentin toimista, yhden määritellyn työnkulun ja yhden ajanjakson sisällä, joissa ihmisen piti puuttua ennen kuin tulos saattoi jäädä valmiiksi. «Puuttua» tarkoittaa tässä täsmällistä asiaa: ihminen korjasi tuloksen, kumosi agentin tekemän päätöksen tai vastasi kysymykseen, jonka agentti esitti nimenomaisesti ennen kuin se jatkaisi — sen, mitä FabricLoopin Loop Agent kutsuu ask_human-hetkeksi. Jaa noiden toimien määrä agentin samalla jaksolla tekemien toimien kokonaismäärällä, ja saat IVO:n.
Tämä mittari ansaitsee paikan käytettävyyden ja tarkkuuden vieressä, ei niiden alla, koska se mittaa jotain, mitä nuo luvut eivät näe. Agentti voi saada sisäisessä benchmarkissa 95 % tarkkuuden ja olla silti huonompi käyttöönotto kuin 80 % saava, jos se 5 %, jossa se erehtyy, lipsahtaa läpi hiljaa, kun taas se 20 %, josta se on epävarma, merkitään joka kerta. IVO ei kysy, onko agentti hyvä. Se kysyy, tietääkö järjestelmä, milloin se tarvitsee ihmisen, ja ilmestyykö ihminen silloin oikeasti paikalle. Tuo toinen kysymys ratkaisee, onko käyttöönottoa turvallista laajentaa.
IVO:n laskeminen yhdelle oikealle työnkululle
Ota työnkulku, jota IT- tai operatiivinen tiimi voisi ajaa jo tänään: agentti lajittelee saapuvat tukipyynnöt, luokittelee ne (laskutus, bugiraportti, hyvitys, tilin käyttöoikeus ja niin edelleen) ja laatii ensimmäisen vastausluonnoksen. Jokainen luonnos päätyy tarkistusjonoon ennen kuin se tavoittaa asiakkaan — mikään ei lähde itsestään. Tarkistusaskel ei itsessään ole väliintulo. Kun tarkistaja painaa «lähetä» luonnoksessa, joka ei tarvinnut muutoksia, työnkulku toimii niin kuin se on suunniteltu. Väliintulo on se, mitä tapahtuu, kun luonnosta piti työstää: tarkistaja kirjoitti sen uudelleen, korjasi luokittelun, ohjasi pyynnön toiseen jonoon, tai agentti itse pysähtyi kesken tehtävän ja kysyi ennen kuin laati mitään.
Alla olevat luvut ovat havainnollistava esimerkki, eivät oikean yrityksen dataa — mutta tarinan muoto ja sen takana oleva lasku ovat juuri se, minkä rakentaisit omista lokeistasi.
Pilottikuukautena agentti koskee 640 pyyntöön. Niistä 415 tarvitsee väliintulon — uudelleenkirjoituksen, uudelleenluokittelun tai uudelleenohjauksen — ja vain 75 näistä 415:stä on hetkiä, jotka agentti merkitsi itse ennen kuin laati mitään. Loput ovat virheitä, jotka tarkistaja saa kiinni jälkikäteen. Se on 64,8 % IVO ja vain 18 % eskalointiosuus: agentti on väärässä itsevarmasti suurimman osan siitä ajasta, kun se on väärässä, ja se on tämän ongelman huonoin muoto.
Tiimi vetää korjauslokin ja merkitsee jokaiseen väliintuloon syyn. Kaksi luokkaa hallitsee: agentti lukee hyvityskäytännön väärin heti, kun mukana on summa, ja se laatii rauhallisia, menettelyllisiä vastauksia asiakkaille, jotka ovat selvästi vihaisia. Molemmat korjautuvat koskematta malliin — lisää eksplisiittinen sääntö, että mikä tahansa pyyntö, jossa mainitaan yli $50 hyvitys tai joka ylittää tunnekynnyksen, laukaisee ask_human-eskaloinnin luonnoksen sijaan. Kaikki muu laaditaan ja tarkistetaan yhä kuten ennen.
| Kuukausi | Käsitellyt pyynnöt | Väliintulot | IVO | Eskalointiosuus |
|---|---|---|---|---|
| 1 — Pilotti | 640 | 415 | 64,8 % | 18 % |
| 2 — Sääntöjen lisäämisen jälkeen | 810 | 224 | 27,7 % | 58 % |
| 3 — Sääntöjä säädettiin uudelleen | 940 | 101 | 10,7 % | 79 % |
Kolmanteen kuukauteen mennessä IVO on pudonnut yli 80 %, mutta puhuttelevampi luku on eskalointiosuus: se nousi 18 %:sta 79 %:iin. Suurin osa siitä, mitä jää, ei ole agentti, joka jää kiinni väärässä olemisesta — se on agentti, joka tunnistaa oikein aidosti epäselvän tapauksen (VIP-tili, käytäntöpoikkeus, hyvitys aivan kynnyksellä) ja kysyy ennen kuin toimii. Lasku on aito, ja se on ansaittu: jokainen korjauskierros syötettiin takaisin eksplisiittisiin sääntöihin, joten ne täsmälliset virheet, jotka ne tuottivat, lakkasivat toistumasta, kun taas luokat, jotka yhä tarvitsevat harkintaa, merkitään sen sijaan että niiden ohi laadittaisiin.
Merkityksellinen lasku on se, jossa agentti oppii paremmin tietämään, mitä se ei tiedä — ei se, jossa ihminen lakkaa hiljaa tarkistamasta.
Virhe: nollan pitäminen tavoitteena
Kun tiimi katsoo IVO:n laskevan kuukaudesta toiseen, ilmeinen seuraava kysymys on, kuinka alas se voi mennä. Vaisto on kohdella nollaa maaliviivana — todisteena, että agentti on vihdoin tarpeeksi hyvä pyörimään ilman valvontaa. Tuo vaisto on nurinkurinen, ja se on tämän mittarin yleisin väärinluenta.
Työnkulku, joka näyttää 0 % väliintuloa viikkoja putkeen, ei juuri koskaan tarkoita, että agentti lakkasi tekemästä virheitä. Se tarkoittaa, että tapahtui jompikumpi: tarkistajat lakkasivat oikeasti lukemasta luonnoksia ennen hyväksymistä, tai eskalointipolku hajosi hiljaa — kynnyksiä löysättiin, reitityssääntö epäonnistui äänettä tai ask_human-laukaisin lakkasi laukeamasta. Kummassakin tapauksessa nolla ei kerro, että järjestelmä lakkasi tarvitsemasta ihmistä. Se kertoo, että ihmiseltä lakattiin kysymästä tai että ihminen lakkasi katsomasta.
Varsinainen tavoite ei koskaan ollut vähemmän väliintuloja abstraktisti. Se on järjestelmä, jossa ne täsmälliset hetket, jotka tarvitsevat ihmisen harkintaa, nousevat esiin — ja vain ne hetket — jotta ihmisen huomio menee sinne, missä sitä oikeasti tarvitaan, sen sijaan että se jakautuisi tasaisesti kaikkeen tai puuttuisi kokonaan. Työnkulku, joka istuu 12 % IVO:ssa ja jossa lähes koko tuo 12 % on agentti merkitsemässä oikein aidosti epäselviä tai korkean panoksen tapauksia, on terveempi kuin 2 %:ssa istuva, jossa suurin osa tuosta 2 %:sta on tarkistaja, joka kompastuu virheeseen, jota agentti ei koskaan merkinnyt. Matalampi luku voi kätkeä huonomman järjestelmän.
Juuri tätä varten eskalointiosuus on olemassa. IVO:n vieressä se kertoo, kummassa tarinassa olet:
Jos IVO laskee samalla kun eskalointiosuus pysyy tasaisena tai laskee, älä kirjaa sitä vielä voitoksi. Vedä satunnainen otos toimista, jotka on kirjattu «väliintuloa ei tarvittu», ja pyydä jotakuta katsomaan ne kylmänä, kertomatta että otos oli merkitty puhtaaksi. Tarkista, liukuvatko alavirran signaalit — uudelleen avatut pyynnöt, valitukset, hyvitysten perumiset, CSAT — samaan aikaan ylöspäin. Laskeva IVO ja nousevat alavirran ongelmat eivät ole järjestelmä, joka oppi nopeammin. Se on järjestelmä, jota kukaan ei ehtinyt saada kiinni.
Mitä instrumentoida, jos haluat mitata tämän tänään
Mikään tästä ei vaadi niinkään uusia työkaluja kuin oikean asian kirjaamista. Useimmat agenttia ajavat tiimit seuraavat jo volyymia — kuinka moneen pyyntöön se koski, kuinka monta tehtävää se laati. Lähes yksikään ei seuraa tulosta, joka on ainoa asia, jota IVO oikeasti tarvitsee.
- Kirjaa tulos jokaiselle toimelle, älä vain aktiivisuuslaskuria. Lähetetty sellaisenaan, muokattu ennen lähettämistä, hylätty ja kirjoitettu uudelleen tai agentin itsensä eskaloima. Ilman tulostason kirjausta IVO:a ei voi laskea lainkaan — tiedät, että agentti teki jotain, et sitä, pitikö se korjata.
- Lukitse nimittäjä ennen osoittajaa. Päätä, mikä lasketaan yhdeksi toimeksi tässä työnkulussa — yksi koskettu pyyntö, yksi laadittu tehtävä — ja pidä määritelmä vakaana jaksojen välillä, jotta IVO:n muutos kertoo agentin harkinnasta eikä siitä, miten lasket.
- Merkitse jokaiseen väliintuloon syy. «Muokattu» ei kerro juuri mitään. «Muokattu: hyvityskäytäntö yli $50 sovellettu väärin» kertoo täsmälleen, mitä korjata seuraavaksi. Lyhyt, johdonmukainen luokittelu muuttaa korjauslokin tehtävälistaksi eikä tulostauluksi.
- Seuraa eskalointiosuutta IVO:n rinnalla, älä sen sijasta. Kaksi lukua yhdessä kertovat, onko lasku ansaittu vai lainattu — katso trenditaulukko yllä.
- Aseta lattia, älä nollatavoitetta. Päätä työnkulkukohtaisesti, miltä uskottava nollasta poikkeava IVO näyttää sen mukaan, kuinka paljon aitoa epäselvyyttä työnkulku sisältää, ja kohtele selvästi tuon lattian alle putoavaa osuutta asiana, jota tutkitaan, ei juhlita.
- Raportoi IVO työnkulkukohtaisesti, ei koskaan yhtenä sekoitettuna yrityslukuna. Yksi keskiarvo kätkee, mikä täsmällinen työnkulku on oikeasti ansainnut vähemmän valvontaa ja mikä kerää hiljaa riskiä hyvännäköisen otsikkoluvun alla.
- Tarkista «puhdas» otos aikataululla. Vedä ajoittain toimia, jotka on kirjattu väliintuloa tarvitsemattomiksi, ja pyydä jotakuta katsomaan ne tietämättä, että ne oli merkitty puhtaiksi. Se on ainoa suora tarkistus siitä, lukevatko tarkistajat yhä.
Siksi Loop Agent on rakennettu ask_human-kutsun, jatkamisen ja kanavasovelluksen eskaloinnin ympärille eikä hiljaisen autonomian — agentti, joka pysähtyy kysymään, ilmestyy IVO-osoittajaan tarkoituksella, ei agenttina, joka jäi kiinni vahingossa. Eskaloinnit ja luonnokset nousevat samoihin Groups-ryhmiin, joissa tiimi jo työskentelee, tehtävien ja muistiinpanojen viereen, joten hetki, joka tarvitsi ihmisen, näkyy siellä missä työ jo elää — ei haudattuna erilliseen agenttikonsoliin, jota kukaan ei tarkista. Enterprisessa audit-lokit antavat IT:n ja operaatioiden nähdä, mitä agentit tekivät ja täsmälleen milloin ihminen puuttui, ja siitä raaka-aineesta IVO ylipäätään rakennetaan.
Parita tämä Luettavuuden kanssa — rinnakkaiskäsitteen, joka pitää myös käyttöoikeudet ja pääsyn näkyvinä — ja saat ne kaksi kysymystä, joihin jokaisen tekoälyn käyttöönoton pitäisi osata vastata ennen laajentamista: kuka näkee, mitä agentti tekee, ja kuinka usein ihmisen oikeasti täytyy puuttua.