Emberi beavatkozási arány: az egyetlen mutató, amely megmondja, hogy az AI-bevezetés tényleg működik-e
A legtöbb cég, amely AI-ügynököket futtat élesben, nem tudja megmondani, milyen gyakran van ezeknek az ügynököknek tényleg szükségük emberre. Az emberi beavatkozási arány az a szám, amely erre a kérdésre válaszol — és a szöveg végére egy olyan munkafolyamatra is ki kell tudnod számolni, amelyet már viszel.
A FabricLoop saját kerete az AI-szervezetekhez egyenesen definiálja az emberi beavatkozási arányt: azt kérdezi, milyen gyakran van szüksége az automatizált munkának emberre. Ez a definíció, és ez a szöveg nem tér el tőle. Ami következik, az a rész, amelyet a koncepcióoldal nem ír ki teljesen: maga a számolás, egyetlen valós munkafolyamatra alkalmazva, azokkal a számokkal, amelyek a gondolatot konkréttá teszik, nem csak kívánatossá.
Amit a szám valójában mér
Az emberi beavatkozási arány (EBA) az ügynök cselekvéseinek az a hányada, egy meghatározott munkafolyamaton és egy időszakon belül, amelynél embernek kellett közbelépnie, mielőtt az eredmény késznek számíthatott. A «közbelépésnek» itt pontos jelentése van: valaki javította a kimenetet, felülírta az ügynök döntését, vagy válaszolt egy kérdésre, amelyet az ügynök kifejezetten feltett, mielőtt folytatta volna — ezt nevezi a FabricLoop Loop Agentje ask_human pillanatnak. Oszd el ezeknek a cselekvéseknek a számát az ügynök ugyanabban az időszakban tett összes cselekvéseinek számával, és megvan az EBA.
Ez a mutató a rendelkezésre állás és a pontosság mellé kerül, nem alájuk, mert olyasmit mér, amit azok a számok nem látnak. Egy ügynök mutathat 95%-os pontosságot egy belső benchmarkon, és mégis rosszabb bevezetés lehet, mint egy 80%-os, ha az az 5%, amelyben téved, csendben átcsúszik, miközben az a 20%, amelyben bizonytalan, minden alkalommal megjelölődik. Az EBA nem azt kérdezi, hogy az ügynök jó-e. Azt kérdezi, tudja-e a rendszer, mikor van szüksége emberre, és megjelenik-e tényleg egy ember, amikor ez megtörténik. Ez a második kérdés dönti el, hogy egy bevezetést biztonságos-e kiterjeszteni.
Az EBA kiszámítása egy valós munkafolyamatra
Vegyél egy munkafolyamatot, amelyet egy IT- vagy üzemeltetési csapat ma is vihet: egy ügynök priorizálja a bejövő támogatási jegyeket, osztályozza őket (számlázás, hibajelentés, visszatérítés, fiókhozzáférés és így tovább), és megírja az első válaszvázlatot. Minden vázlat egy ellenőrzési sorba kerül, mielőtt ügyfélhez érne — semmi nem megy ki magától. Ez az ellenőrzési lépés önmagában nem beavatkozás. Ha az ellenőrző a «küldés»-re kattint egy vázlaton, amelynek nem kellettek módosítások, a munkafolyamat a tervezett módon működik. Beavatkozás az, ami akkor történik, ha a vázlaton dolgozni kellett: az ellenőrző átírta, javította az osztályozást, másik sorba irányította a jegyet, vagy maga az ügynök megállt a feladat közepén, és kérdezett, mielőtt bármit megírt volna.
Az alábbi számok szemléltető példa, nem egy valós cég adatai — de a történet formája és a mögötte lévő számolás pontosan az, amit a saját naplóidból felépítenél.
A pilot hónapban az ügynök 640 jegyet érint. Ezek közül 415 beavatkozást igényel — átírást, újraosztályozást vagy átirányítást — és ebből a 415-ből csak 75 az a pillanat, amelyet az ügynök maga jelölt meg, mielőtt bármit megírt volna. A többi olyan hiba, amelyet az ellenőrző utólag kap el. Ez 64,8%-os EBA, mindössze 18%-os eszkalációs aránnyal: az ügynök magabiztosan téved az idő nagy részében, amikor téved, és ez a probléma legrosszabb változata.
A csapat előveszi a javítási naplót, és minden beavatkozást okkal címkéz. Két kategória uralkodik: az ügynök félreolvassa a visszatérítési szabályzatot, amint összeg kerül a képbe, és nyugodt, eljárásszerű válaszokat ír láthatóan dühös ügyfeleknek. Mindkettő javítható a modell érintése nélkül — adj hozzá egy explicit szabályt, hogy minden jegy, amely $50 feletti visszatérítést említ, vagy egy hangulatelemzési küszöb fölé esik, vázlat helyett ask_human eszkalációt indítson. Minden más továbbra is úgy készül és úgy kerül ellenőrzésre, mint eddig.
| Hónap | Kezelt jegyek | Beavatkozások | EBA | Eszkalációs arány |
|---|---|---|---|---|
| 1 — Pilot | 640 | 415 | 64,8% | 18% |
| 2 — A szabályok hozzáadása után | 810 | 224 | 27,7% | 58% |
| 3 — A szabályok újrahangolva | 940 | 101 | 10,7% | 79% |
A harmadik hónapra az EBA több mint 80%-kal esett, de a beszédesebb szám az eszkalációs arány: 18%-ról 79%-ra nőtt. Ami megmarad, annak a java nem az, hogy az ügynököt tévedésen kapják — hanem az, hogy az ügynök helyesen ismer fel egy valóban kétértelmű esetet (VIP-fiók, szabályzati kivétel, pont a küszöbön lévő visszatérítés), és kérdez, mielőtt cselekszik. Az esés valódi, és kiérdemelt: minden javítási kör visszakerült explicit szabályokba, így a konkrét hibák, amelyek őket létrehozták, nem ismétlődtek, miközben a kategóriák, amelyeknek továbbra is ítélet kell, megjelölve maradnak, ahelyett hogy vázlattal kerülnék meg őket.
Az az esés számít, amelyben az ügynök jobban tudja, mit nem tud — nem az, amelyben egy ember csendben abbahagyja az ellenőrzést.
A hiba: a nullát célnak venni
Amint egy csapat hónapról hónapra nézi az EBA esését, a kézenfekvő következő kérdés az, milyen alacsonyra mehet. Az ösztön az, hogy a nullát célvonalnak vegyük — bizonyítéknak, hogy az ügynök végre elég jó ahhoz, hogy felügyelet nélkül fusson. Ez az ösztön fordított, és ez a mutató leggyakoribb félreolvasása.
Egy munkafolyamat, amely heteken át 0% beavatkozást mutat, szinte soha nem azt jelenti, hogy az ügynök abbahagyta a hibázást. Azt jelenti, hogy a kettő közül az egyik történt: az ellenőrzők abbahagyták a vázlatok tényleges olvasását a jóváhagyás előtt, vagy az eszkalációs út csendben elromlott — a küszöböket lazították, egy irányítási szabály hangtalanul elhasalt, vagy az ask_human kiváltó abbahagyta a tüzelést. Akármelyik, a nulla nem azt mondja, hogy a rendszernek már nincs szüksége emberre. Azt mondja, hogy egy embert már nem kérdeznek, vagy hogy abbahagyta a nézést.
A tényleges cél soha nem a kevesebb beavatkozás volt elvontan. Egy olyan rendszer, amelyben azok a konkrét pillanatok, amelyeknek emberi ítélet kell, a felszínre kerülnek — és csak azok a pillanatok —, hogy az ember figyelme oda menjen, ahol tényleg szükség van rá, ahelyett hogy egyenletesen mindenre oszlana, vagy teljesen hiányozna. Egy 12%-os EBA-n ülő munkafolyamat, amelyben ennek a 12%-nak szinte az egésze az ügynök, amint helyesen jelöl valóban kétértelmű vagy nagy tétű eseteket, egészségesebb, mint egy 2%-on ülő, amelyben ennek a 2%-nak a java egy ellenőrző, aki olyan hibába botlik, amelyet az ügynök soha nem jelölt meg. Az alacsonyabb szám elrejtheti a rosszabb rendszert.
Pont erre való az eszkalációs arány. Az EBA mellett azt mondja meg, melyik történetben vagy:
Ha az EBA esik, miközben az eszkalációs arány lapos marad vagy szintén esik, még ne könyveld el győzelemnek. Húzz egy véletlen mintát a «nem kellett beavatkozás» jelölésű cselekvésekből, és nézesse át valakivel hidegen, anélkül hogy elmondanád, a mintát tisztának jelölték. Nézd meg, hogy a lenti jelek — újra megnyitott jegyek, panaszok, visszatérítések visszavonása, CSAT — ugyanakkor nem kúsznak-e felfelé. Egy eső EBA emelkedő lenti problémákkal nem olyan rendszer, amely gyorsabban tanult. Olyan rendszer, amelyet senki sem kapott el időben.
Mit kell rögzíteni, ha ezt ma akarod mérni
Ehhez nem annyira új eszköz kell, mint a helyes dolog naplózása. A legtöbb csapat, amely ügynököt futtat, már követi a volument — hány jegyet érintett, hány feladatot vázolt. Szinte egyikük sem követi az eredményt, pedig az EBA-nak egyedül erre van szüksége.
- Minden cselekvéshez rögzíts eredményt, ne csak egy aktivitásszámlálót. Úgy elküldve, ahogy volt, küldés előtt szerkesztve, elutasítva és újraírva, vagy maga az ügynök eszkalálta. Eredményszintű napló nélkül az EBA egyáltalán nem számítható — tudni fogod, hogy az ügynök csinált valamit, azt nem, hogy javítani kellett-e.
- A nevezőt rögzítsd, mielőtt a számlálót javítanád. Döntsd el, mi számít egy cselekvésnek ebben a munkafolyamatban — egy érintett jegy, egy megírt feladat —, és tartsd ezt a definíciót állandón az időszakok között, hogy az EBA változása az ügynök ítéletét tükrözze, ne a számolás módjának változását.
- Minden beavatkozást címkézz okkal. A «szerkesztve» szinte semmit sem mond. A «szerkesztve: a $50 feletti visszatérítési szabályzatot rosszul alkalmazták» pontosan megmondja, mit kell legközelebb javítani. Egy rövid, következetes osztályozás a javítási naplót munkalistává teszi, nem eredménytáblává.
- Az eszkalációs arányt az EBA mellett kövesd, ne helyette. A két szám együtt mondja meg, hogy egy esés kiérdemelt-e vagy kölcsönvett — lásd a fenti trendtáblát.
- Padlót állíts, ne nulla célt. Munkafolyamatonként döntsd el, hogyan néz ki egy hihető, nullától eltérő EBA annak fényében, mennyi valódi kétértelműség van a folyamatban, és a padló alá jól beeső arányt vizsgálandó dolognak kezeld, nem ünnepelendőnek.
- Az EBA-t munkafolyamatonként jelentsd, soha egyetlen összemosott, céges számként. Egyetlen átlag elrejti, melyik konkrét folyamat érdemelt ki tényleg kevesebb felügyeletet, és melyik gyűjt csendben kockázatot egy jól kinéző főszám alatt.
- Ütemezetten ellenőrizd újra a «tiszta» mintát. Időnként húzd elő a beavatkozást nem igénylőnek naplózott cselekvéseket, és nézesse át valakivel úgy, hogy nem tudja, tisztának jelölték őket. Ez az egyetlen közvetlen ellenőrzés arra, hogy az ellenőrzők még olvasnak-e.
Ezért épül a Loop Agent az ask_human, a folytatás és a csatornaalkalmazásos eszkaláció köré, nem a csendes autonómia köré — az ügynök, amely megáll kérdezni, szándékosan jelenik meg az EBA számlálójában, nem pedig olyan ügynökként, amelyet véletlenül kaptak el. Az eszkalációk és a vázlatok ugyanazokban a Groupsben jelennek meg, ahol a csapat már dolgozik, a feladatok és a jegyzetek mellett, így a pillanat, amelynek ember kellett, ott látszik, ahol a munka már él — nem egy külön ügynökkonzolban elásva, amelyet senki sem néz. Enterprise-on az auditnaplók hagyják, hogy az IT és az üzemeltetés lássa, mit tettek az ügynökök, és pontosan mikor lépett közbe ember; ebből a nyersanyagból épül az EBA eleve.
Párosítsd ezt az Olvashatósággal — a kísérő koncepcióval, amely a jogosultságokat és a hozzáférést is láthatóvá teszi —, és megkapod azt a két kérdést, amelyre minden AI-bevezetésnek válaszolnia kell, mielőtt kiterjed: ki láthatja, mit csinál egy ügynök, és milyen gyakran kell egy embernek tényleg közbelépnie.