Stopa ljudske intervencije: jedina metrika koja vam govori radi li vaše uvođenje AI-a stvarno

Većina tvrtki koje u produkciji pokreću AI agente ne može vam reći koliko često ti agenti stvarno trebaju da osoba uskoči. Stopa ljudske intervencije broj je koji odgovara na to pitanje — i do kraja ovog teksta trebali biste je moći izračunati za tijek rada koji već vodite.

Vlastiti okvir FabricLoopa za AI organizacije definira stopu ljudske intervencije jasno: pita koliko često automatizirani rad treba osobu. To je definicija, i ovaj tekst od nje ne odstupa. Ono što slijedi dio je koji stranica koncepta ne ispisuje do kraja: stvarna aritmetika, primijenjena na jedan stvarni tijek rada, s brojevima koji ideju čine konkretnom umjesto tek težnjom.

Što broj zapravo mjeri

Stopa ljudske intervencije (HIR) udio je radnji agenta, unutar jednog određenog tijeka rada i jednog razdoblja, koje su zahtijevale da osoba uskoči prije nego što se ishod mogao smatrati gotovim. „Uskočiti” ovdje ima točno značenje: osoba je ispravila izlaz, poništila odluku koju je agent donio ili odgovorila na pitanje koje je agent izričito postavio prije nego što bi nastavio — ono što FabricLoopov Loop Agent naziva trenutkom ask_human. Podijelite broj tih radnji s ukupnim brojem radnji koje je agent poduzeo u istom razdoblju i imate HIR.

Ova metrika zaslužuje mjesto uz dostupnost i točnost, a ne ispod njih, jer mjeri nešto što ti brojevi ne vide. Agent može na nekom internom benchmarku pokazati točnost od 95% i svejedno biti lošije uvođenje od onog s 80%, ako 5% u kojem griješi prođe tiho, dok se 20% u kojem nije siguran označi svaki put. HIR ne pita je li agent dobar. Pita zna li sustav kada treba osobu i pojavi li se osoba stvarno kad treba. To drugo pitanje odlučuje je li uvođenje sigurno proširiti.

Izračun HIR-a za jedan stvarni tijek rada

Uzmite tijek rada koji bi tim za IT ili operacije danas stvarno mogao voditi: agent koji trijažira dolazne tikete podrške, razvrstava ih (naplata, prijava greške, povrat novca, pristup računu i slično) i sastavlja prvi odgovor. Svaki nacrt stiže u red za pregled prije nego što dođe do klijenta — ništa se ne šalje samo. Taj korak pregleda, sam po sebi, nije intervencija. Pregledavatelj koji klikne „pošalji” na nacrtu koji nije trebao izmjene vidi tijek rada kakav je zamišljen. Intervencija je ono što se dogodi kad je nacrt trebao rad: pregledavatelj ga je prepisao, ispravio razvrstavanje, preusmjerio tiket u drugi red, ili se sam agent zaustavio usred zadatka i postavio pitanje prije nego što je išta sastavio.

Brojevi u nastavku ilustrativan su primjer, ne podaci stvarne tvrtke — ali oblik priče, i aritmetika iza nje, upravo je ono što biste sastavili iz vlastitih zapisa.

U pilot-mjesecu agent dotakne 640 tiketa. Od toga 415 treba intervenciju — prepisivanje, ponovno razvrstavanje ili preusmjeravanje — a samo 75 od tih 415 trenuci su koje je agent sam označio prije nego što je išta sastavio. Ostalo su pogreške koje pregledavatelj uhvati naknadno. To je HIR od 64.8%, s udjelom eskalacija od samo 18%: agent je samouvjereno u krivu većinu puta kad je u krivu, a to je najgora inačica ovog problema.

Tim izvuče zapis ispravaka i svaku intervenciju označi razlogom. Dvije kategorije prevladavaju: agent pogrešno čita pravilo o povratu novca čim je u igri iznos u dolarima, i sastavlja mirne, proceduralne odgovore klijentima koji su vidljivo ljuti. Obje se daju popraviti bez diranja modela — dodajte izričito pravilo da svaki tiket koji spominje povrat veći od $50, ili koji prijeđe prag sentimenta, pokrene eskalaciju ask_human umjesto nacrta. Sve ostalo i dalje se sastavlja i pregledava kao prije.

Do trećeg mjeseca HIR je pao za više od 80%, ali informativniji broj je udio eskalacija: popeo se s 18% na 79%. Većina onoga što je ostalo nije agent kojeg se uhvatilo u krivu — to je agent koji točno prepoznaje doista dvoumičan slučaj (VIP račun, iznimku od pravila, povrat koji pada točno na prag) i pita prije nego što djeluje. Pad je stvaran i zaslužen: svaki krug ispravaka vraćen je u izričita pravila, pa su se konkretne pogreške koje su ih proizvele prestale ponavljati, dok se kategorije koje i dalje trebaju prosudbu i dalje označavaju umjesto da se zaobiđu nacrtom.

Pogreška: tretirati nulu kao cilj

Kad tim gleda kako HIR pada iz mjeseca u mjesec, sljedeće očito pitanje jest koliko nisko može ići. Instinkt je nulu tretirati kao ciljnu crtu — dokaz da je agent napokon dovoljno dobar da radi bez nadzora. Taj instinkt ide u krivom smjeru, i to je najčešće pogrešno čitanje ove metrike.

Stvarni cilj nikad nije bio manje intervencija u apstraktnom smislu. To je sustav u kojem konkretni trenuci koji trebaju ljudsku prosudbu izađu na površinu — i samo ti trenuci — tako da pozornost osobe ide na ono što je stvarno treba, umjesto da se ravnomjerno dijeli na sve ili da je uopće nema. Tijek rada na 12% HIR-a, gdje je gotovo sav taj 12% agent koji točno označava doista dvoumične ili visokorizične slučajeve, zdraviji je od onog na 2%, gdje je većina tog 2% pregledavatelj koji nabasa na pogrešku koju agent nikad nije označio. Niži broj može skriti lošiji sustav.

Upravo zato postoji udio eskalacija. Gledan uz HIR, kaže vam u kojoj ste priči:

Ako HIR pada dok udio eskalacija ostaje ravan ili također pada, još to ne stavljajte u pobjede. Izvucite slučajni uzorak radnji zapisanih kao „nije trebala intervencija” i neka ih netko pregleda na hladno, bez da mu kažete da je uzorak označen čistim. Provjerite pomiču li se nizvodni signali — tiketi koji se ponovno otvaraju, pritužbe, povlačenja povrata, CSAT — u isto vrijeme prema gore. Padajući HIR s rastućim nizvodnim problemima nije sustav koji je brže naučio. To je sustav koji nitko nije uhvatio na vrijeme.

Što instrumentirati ako ovo želite mjeriti danas

Ništa od ovoga ne traži toliko novi alat koliko bilježenje prave stvari. Većina timova koji pokreću agenta već prati volumen — koliko je tiketa dotaknuo, koliko je zadataka sastavio. Gotovo nitko ne prati ishod, a to je jedino što HIR stvarno treba.

1. Zapišite ishod za svaku radnju, ne samo broj aktivnosti. Poslano kako jest, uređeno prije slanja, odbijeno i prepisano, ili eskalirano od samog agenta. Bez zapisa na razini ishoda HIR se uopće ne može izračunati — znat ćete da je agent nešto napravio, ne je li to trebalo popraviti.
2. Sredite nazivnik prije nego što sredite brojnik. Odlučite što se u ovom tijeku rada broji kao jedna radnja — jedan dotaknuti tiket, jedan sastavljeni zadatak — i držite tu definiciju stalnom kroz razdoblja, tako da promjena HIR-a odražava prosudbu agenta, a ne promjenu u načinu brojanja.
3. Svaku intervenciju označite razlogom. „Uređeno” vam ne govori gotovo ništa. „Uređeno: pogrešno primijenjeno pravilo povrata iznad $50” točno vam kaže što sljedeće popraviti. Kratka, dosljedna taksonomija pretvara zapis ispravaka u popis posla, a ne u semafor.
4. Pratite udio eskalacija uz HIR, ne umjesto njega. Dva broja zajedno kažu vam je li pad zaslužen ili posuđen — pogledajte tablicu trenda iznad.
5. Postavite pod, ne cilj nule. Odlučite, po tijeku rada, kako izgleda uvjerljiv HIR različit od nule s obzirom na to koliko stvarne dvojbe taj tijek sadrži, i stopu koja padne znatno ispod tog poda tretirajte kao nešto što treba istražiti, ne proslaviti.
6. Izvještavajte HIR po tijeku rada, nikad kao jedan izmiješani broj za cijelu tvrtku. Jedan prosjek skriva koji je konkretni tijek rada stvarno zaslužio manje nadzora, a koji tiho gomila rizik ispod brojke koja izgleda dobro.
7. Po rasporedu ponovno provjerite „čisti” uzorak. Povremeno izvucite radnje zapisane kao da ne trebaju intervenciju i neka ih netko pregleda ne znajući da su označene čistima. To je jedina izravna provjera čitaju li pregledavatelji i dalje.