Menneskelig intervensjonsrate: det ene målet som viser om AI-utrullingen din faktisk virker
De fleste selskaper som kjører AI-agenter i produksjon, kan ikke si hvor ofte de agentene faktisk trenger at en person trer inn. Menneskelig intervensjonsrate er tallet som svarer på det spørsmålet — og mot slutten av denne teksten skal du kunne regne den ut for en arbeidsflyt du allerede kjører.
FabricLoops eget rammeverk for AI-organisasjoner definerer menneskelig intervensjonsrate rett ut: den spør hvor ofte automatisert arbeid trenger en person. Det er definisjonen, og denne teksten avviker ikke fra den. Det som følger, er delen konseptsiden ikke skriver helt ut: den faktiske regningen, brukt på én ekte arbeidsflyt, med tallene som gjør ideen konkret i stedet for bare noe å strebe etter.
Hva tallet faktisk måler
Menneskelig intervensjonsrate (HIR) er andelen av en agents handlinger, innenfor én avgrenset arbeidsflyt og én periode, som krevde at en person trådte inn før utfallet kunne gjelde som ferdig. «Tre inn» har en bestemt betydning her: en person rettet utdata, overstyrte en beslutning agenten tok, eller svarte på et spørsmål agenten stilte uttrykkelig før den ville gå videre — det FabricLoops Loop Agent kaller et ask_human-øyeblikk. Del antallet slike handlinger på det totale antallet handlinger agenten tok i samme periode, og du har HIR.
Målet hører ved siden av oppetid og treffsikkerhet, ikke under dem, fordi det måler noe de tallene ikke ser. En agent kan vise 95 % treffsikkerhet på en intern målestokk og likevel være en dårligere utrulling enn en på 80 %, hvis de 5 % den tar feil i glir igjennom i stillhet mens de 20 % den er usikker på, blir flagget hver gang. HIR spør ikke om agenten er god. Den spør om systemet vet når det trenger en person, og om en person faktisk dukker opp når det gjør det. Det andre spørsmålet avgjør om en utrulling er trygg å utvide.
Regne ut HIR for én ekte arbeidsflyt
Ta en arbeidsflyt et IT- eller driftsteam kan kjøre allerede i dag: en agent som triagerer innkommende supportsaker, klassifiserer dem (fakturering, feilrapport, refusjon, kontotilgang og så videre) og skriver et første svar. Hvert utkast lander i en gjennomgangskø før det når en kunde — ingenting sendes av seg selv. Det gjennomgangstrinnet er i seg selv ikke intervensjon. En gransker som klikker «send» på et utkast som ikke trengte endringer, er arbeidsflyten som virker slik den er tegnet. Intervensjon er det som skjer når utkastet trengte arbeid: en gransker skrev det om, rettet klassifiseringen, sendte saken til en annen kø, eller agenten selv stoppet midt i oppgaven og stilte et spørsmål før den skrev noe som helst.
Tallene under er et illustrerende eksempel, ikke data fra et ekte selskap — men formen på historien, og regnestykket bak den, er nøyaktig det du bygger ut fra dine egne logger.
I pilotmåneden berører agenten 640 saker. Av dem trenger 415 en intervensjon — en omskriving, en omklassifisering eller en omruting — og bare 75 av de 415 er øyeblikk agenten selv flagget før den skrev noe. Resten er feil en gransker fanger i etterkant. Det er en HIR på 64,8 %, med en eskaleringsandel på bare 18 %: når agenten tar feil, tar den oftest feil med selvtillit, og det er den verste utgaven av dette problemet.
Teamet henter korreksjonsloggen og merker hver intervensjon med en grunn. To kategorier dominerer: agenten leser refusjonspolitikken feil så snart et beløp i dollar er med, og den skriver rolige, prosedyreriktige svar til kunder som synlig er sinte. Begge kan rettes uten å røre modellen — legg til en tydelig regel: enhver sak som nevner en refusjon over $50, eller som scorer over en terskel for sentiment, utløser en ask_human-eskalering i stedet for et utkast. Alt annet skrives og gjennomgås som før.
| Måned | Saker håndtert | Intervensjoner | HIR | Eskaleringsandel |
|---|---|---|---|---|
| 1 — Pilot | 640 | 415 | 64,8 % | 18 % |
| 2 — Etter at regler ble lagt til | 810 | 224 | 27,7 % | 58 % |
| 3 — Regler justert igjen | 940 | 101 | 10,7 % | 79 % |
I måned tre har HIR falt med mer enn 80 %, men det mer informative tallet er eskaleringsandelen: den steg fra 18 % til 79 %. Det meste av det som er igjen, er ikke at agenten blir tatt i å ta feil — det er at agenten korrekt kjenner igjen et genuint tvetydig tilfelle (en VIP-konto, et policyunntak, en refusjon som ligger rett på terskelen) og spør før den handler. Nedgangen er ekte, og fortjent: hver runde med korreksjoner ble ført tilbake inn i tydelige regler, slik at de konkrete feilene som skapte dem, sluttet å gjenta seg, mens kategoriene som fortsatt trenger skjønn, fortsetter å bli flagget i stedet for å bli skrevet rundt.
Nedgangen som betyr noe, er den der agenten blir flinkere til å vite hva den ikke vet — ikke den der en person stille slutter å sjekke.
Feilen: å behandle null som målet
Når et team ser HIR falle måned for måned, er neste spørsmål opplagt: hvor lavt kan den gå. Instinktet er å behandle null som målstreken — beviset på at agenten endelig ble god nok til å kjøre uten tilsyn. Det instinktet er bakvendt, og det er den vanligste feillesingen av dette målet.
En arbeidsflyt som viser 0 % intervensjon i uke etter uke, betyr nesten aldri at agenten sluttet å gjøre feil. Det betyr at én av to ting skjedde: granskerne sluttet å lese utkastene før de godkjente dem, eller eskaleringsveien brast i stillhet — terskler ble løsnet, en rutingsregel feilet uten lyd, eller ask_human-utløseren sluttet å fyre. Uansett sier nullen ikke at systemet sluttet å trenge en person. Den sier at en person sluttet å bli spurt, eller sluttet å se.
Det egentlige målet var aldri færre intervensjoner i det abstrakte. Det er et system der de konkrete øyeblikkene som trenger en persons skjønn, blir synlige — og bare de øyeblikkene — slik at en persons oppmerksomhet går dit den faktisk trengs, i stedet for å bli delt jevnt over alt eller mangle helt. En arbeidsflyt på 12 % HIR, der nesten alle de 12 prosentene er agenten som korrekt flagger genuint tvetydige eller høyrisikotilfeller, er sunnere enn en på 2 %, der det meste av de 2 prosentene er en gransker som snubler over en feil agenten aldri flagget. Det lavere tallet kan skjule det dårligere systemet.
Det er nettopp dette eskaleringsandelen er til for. Sett ved siden av HIR forteller den hvilken historie du er i:
Hvis HIR synker mens eskaleringsandelen ligger flatt eller også synker, ikke bokfør det som en seier ennå. Trekk et tilfeldig utvalg av handlinger logget som «ingen intervensjon nødvendig», og la noen gjennomgå dem kaldt, uten å si at utvalget var merket rent. Sjekk om signaler nedstrøms — gjenåpnede saker, klager, tilbakekreving av refusjoner, CSAT — driver oppover samtidig. En fallende HIR med stigende problemer nedstrøms er ikke et system som lærte raskere. Det er et system ingen fanget i tide.
Hva du bør instrumentere hvis du vil måle dette i dag
Ingenting av dette krever nye verktøy så mye som det krever at du logger riktig ting. De fleste team som kjører en agent, følger allerede volum — hvor mange saker den berørte, hvor mange oppgaver den skrev. Nesten ingen følger utfallet, og det er det eneste HIR faktisk trenger.
- Logg et utfall for hver handling, ikke bare en aktivitetstelling. Sendt som det var, redigert før sending, avvist og skrevet om, eller eskalert av agenten selv. Uten logging på utfallsnivå kan ikke HIR regnes ut i det hele tatt — du vet at agenten gjorde noe, ikke om det måtte rettes.
- Lås nevneren før du retter telleren. Bestem hva som teller som én handling i denne arbeidsflyten — én sak som er berørt, én oppgave som er skrevet — og hold den definisjonen stabil på tvers av perioder, slik at en endring i HIR speiler agentens skjønn og ikke en endring i hvordan du teller.
- Merk hver intervensjon med en grunn. «Redigert» sier nesten ingenting. «Redigert: refusjonspolitikk over $50 feil anvendt» sier nøyaktig hva som skal rettes neste gang. En kort, konsistent taksonomi gjør en korreksjonslogg til en oppgaveliste i stedet for en resultattavle.
- Følg eskaleringsandelen sammen med HIR, ikke i stedet for den. De to tallene sammen sier om en nedgang er fortjent eller lånt — se trendtabellen over.
- Sett et gulv, ikke et mål på null. Bestem, per arbeidsflyt, hvordan en plausibel HIR over null ser ut gitt hvor mye ekte tvetydighet flyten inneholder, og behandle en rate som faller godt under det gulvet som noe å undersøke, ikke noe å feire.
- Rapporter HIR per arbeidsflyt, aldri som ett blandet tall for hele selskapet. Et gjennomsnitt skjuler hvilken flyt som faktisk har fortjent mindre tilsyn, og hvilken som stille samler risiko under en overskrift som ser bra ut.
- Sjekk det «rene» utvalget etter en plan. Trekk med jevne mellomrom handlinger logget som uten behov for intervensjon, og la noen gjennomgå dem uten å vite at de var merket rene. Det er den eneste direkte sjekken av om granskerne fortsatt leser.
Derfor er Loop Agent bygget rundt ask_human, resume og eskalering via kanalapper, heller enn rundt stille autonomi — en agent som pauser for å spørre, er en agent som med vilje dukker opp i telleren for HIR-en din, ikke en som ble tatt ved en tilfeldighet. Eskaleringer og utkast kommer i de samme Gruppene der teamet allerede jobber, ved siden av oppgaver og notater, slik at øyeblikket som trengte en person, er synlig der arbeidet allerede lever — ikke begravd i en egen agentkonsoll som ingen sjekker. På Enterprise lar revisjonslogger IT og drift se hva agenter gjorde, og nøyaktig når et menneske trådte inn, og det er råstoffet HIR bygges av i utgangspunktet.
Sett det sammen med Lesbarhet — det ledsagende konseptet for å gjøre tildelinger og tilgang synlige også — og du får de to spørsmålene enhver AI-utrulling skal kunne svare på før den utvides: hvem kan se hva en agent gjør, og hvor ofte trenger en person faktisk å tre inn.