Menneskelig interventionsrate: det ene mål, der viser, om jeres AI-udrulning faktisk virker
De fleste virksomheder, der kører AI-agenter i produktion, kan ikke sige, hvor ofte de agenter faktisk har brug for, at en person træder til. Menneskelig interventionsrate er tallet, der svarer på det spørgsmål — og når du er færdig med denne tekst, skal du kunne regne den ud for en arbejdsgang, I allerede kører.
FabricLoops eget rammeværk for AI-organisationer definerer menneskelig interventionsrate ligeud: den spørger, hvor ofte automatiseret arbejde har brug for en person. Det er definitionen, og denne tekst afviger ikke fra den. Det, der følger, er den del, konceptsiden ikke skriver helt ud: det faktiske regnestykke, lagt ned over én virkelig arbejdsgang, med de tal, der gør ideen konkret i stedet for blot noget at stræbe efter.
Hvad tallet faktisk måler
Menneskelig interventionsrate (HIR) er andelen af en agents handlinger, inden for én afgrænset arbejdsgang og én periode, der krævede, at en person trådte til, før udfaldet kunne gælde som færdigt. «Træde til» har en bestemt betydning her: en person rettede outputtet, tilsidesatte en beslutning, agenten tog, eller svarede på et spørgsmål, agenten stillede udtrykkeligt, før den ville gå videre — det, FabricLoops Loop Agent kalder et ask_human-øjeblik. Divider antallet af de handlinger med det samlede antal handlinger, agenten tog i samme periode, og du har HIR.
Målet hører ved siden af oppetid og træfsikkerhed, ikke under dem, fordi det måler noget, de tal ikke kan se. En agent kan vise 95 % træfsikkerhed på et internt benchmark og alligevel være en dårligere udrulning end en på 80 %, hvis de 5 %, den tager fejl i, glider igennem i stilhed, mens de 20 %, den er usikker på, bliver markeret hver gang. HIR spørger ikke, om agenten er god. Den spørger, om systemet ved, hvornår det har brug for en person, og om en person faktisk dukker op, når det sker. Det andet spørgsmål afgør, om en udrulning er sikker at udvide.
Sådan regner du HIR ud for én virkelig arbejdsgang
Tag en arbejdsgang, som et IT- eller driftsteam kan køre allerede i dag: en agent, der triagerer indgående supportsager, klassificerer dem (fakturering, fejlrapport, refundering, kontoadgang og så videre) og skriver et første svar. Hvert udkast lander i en gennemgangskø, før det når en kunde — intet sendes af sig selv. Det gennemgangstrin er i sig selv ikke intervention. En gransker, der klikker «send» på et udkast, som ikke skulle ændres, er arbejdsgangen, der virker, som den er tegnet. Intervention er det, der sker, når udkastet skulle bearbejdes: en gransker skrev det om, rettede klassificeringen, sendte sagen til en anden kø, eller agenten selv stoppede midt i opgaven og stillede et spørgsmål, før den skrev noget som helst.
Tallene nedenfor er et illustrativt eksempel, ikke data fra en virkelig virksomhed — men historiens form, og regnestykket bag den, er præcis det, du bygger ud fra dine egne logs.
I pilotmåneden rører agenten 640 sager. Af dem har 415 brug for en intervention — en omskrivning, en omklassificering eller en omstyring — og kun 75 af de 415 er øjeblikke, agenten selv markerede, før den skrev noget. Resten er fejl, en gransker fanger bagefter. Det er en HIR på 64,8 %, med en eskaleringsandel på kun 18 %: når agenten tager fejl, tager den oftest fejl med selvtillid, og det er den værste udgave af dette problem.
Teamet henter korrektionsloggen og mærker hver intervention med en grund. To kategorier dominerer: agenten læser refundpolitikken forkert, så snart et beløb i dollar er med, og den skriver rolige, proceduremæssige svar til kunder, der tydeligt er vrede. Begge kan rettes uden at røre modellen — tilføj en tydelig regel: enhver sag, der nævner en refundering over $50, eller som scorer over en tærskel for stemning, udløser en ask_human-eskalering i stedet for et udkast. Alt andet skrives og gennemgås som før.
| Måned | Sager håndteret | Interventioner | HIR | Eskaleringsandel |
|---|---|---|---|---|
| 1 — Pilot | 640 | 415 | 64,8 % | 18 % |
| 2 — Efter regler er tilføjet | 810 | 224 | 27,7 % | 58 % |
| 3 — Regler justeret igen | 940 | 101 | 10,7 % | 79 % |
I måned tre er HIR faldet med mere end 80 %, men det mere oplysende tal er eskaleringsandelen: den steg fra 18 % til 79 %. Det meste af det, der er tilbage, er ikke, at agenten bliver grebet i at tage fejl — det er, at agenten korrekt genkender et reelt tvetydigt tilfælde (en VIP-konto, en politikundtagelse, en refundering, der ligger lige på tærsklen) og spørger, før den handler. Faldet er ægte, og fortjent: hver runde korrektioner blev ført tilbage ind i tydelige regler, så de konkrete fejl, der skabte dem, holdt op med at gentage sig, mens de kategorier, der stadig kræver skøn, fortsat bliver markeret i stedet for at blive skrevet udenom.
Det fald, der betyder noget, er det, hvor agenten bliver bedre til at vide, hvad den ikke ved — ikke det, hvor en person stille holder op med at tjekke.
Fejlen: at behandle nul som målet
Når et team ser HIR falde måned for måned, er det næste spørgsmål indlysende: hvor lavt kan den gå. Instinktet er at behandle nul som målstregen — beviset på, at agenten endelig blev god nok til at køre uden opsyn. Det instinkt er bagvendt, og det er den mest almindelige fejllæsning af dette mål.
En arbejdsgang, der viser 0 % intervention uge efter uge, betyder næsten aldrig, at agenten holdt op med at lave fejl. Det betyder, at én af to ting skete: granskerne holdt op med faktisk at læse udkastene, før de godkendte dem, eller eskaleringsvejen gik i stykker i stilhed — tærskler blev løsnet, en ruteregel fejlede uden lyd, eller ask_human-udløseren holdt op med at fyre. Uanset hvad siger nullet ikke, at systemet holdt op med at have brug for en person. Det siger, at en person holdt op med at blive spurgt, eller holdt op med at se efter.
Det egentlige mål var aldrig færre interventioner i det abstrakte. Det er et system, hvor de konkrete øjeblikke, der har brug for en persons skøn, bliver synlige — og kun de øjeblikke — så en persons opmærksomhed går derhen, hvor den faktisk er nødvendig, i stedet for at blive delt jævnt over det hele eller mangle helt. En arbejdsgang på 12 % HIR, hvor næsten alle de 12 procent er agenten, der korrekt markerer reelt tvetydige eller højrisikotilfælde, er sundere end et på 2 %, hvor det meste af de 2 procent er en gransker, der snubler over en fejl, agenten aldrig markerede. Det lavere tal kan skjule det dårligere system.
Det er præcis det, eskaleringsandelen er til for. Set ved siden af HIR fortæller den, hvilken historie du er i:
Hvis HIR falder, mens eskaleringsandelen ligger fladt eller også falder, så bogfør det ikke som en sejr endnu. Træk en tilfældig stikprøve af handlinger logget som «ingen intervention nødvendig», og lad nogen gennemgå dem koldt, uden at fortælle dem, at stikprøven var markeret ren. Tjek, om signaler nedstrøms — genåbnede sager, klager, tilbageførsel af refunderinger, CSAT — driver opad samtidig. En faldende HIR med stigende problemer nedstrøms er ikke et system, der lærte hurtigere. Det er et system, ingen fangede i tide.
Hvad du skal instrumentere, hvis du vil måle det i dag
Intet af dette kræver nye værktøjer så meget, som det kræver, at du logger det rigtige. De fleste teams, der kører en agent, følger allerede volumen — hvor mange sager den rørte, hvor mange opgaver den skrev. Næsten ingen følger udfaldet, og det er det eneste, HIR faktisk har brug for.
- Log et udfald for hver handling, ikke kun en aktivitetstælling. Sendt, som det var, redigeret før afsendelse, afvist og skrevet om, eller eskaleret af agenten selv. Uden logning på udfaldsniveau kan HIR slet ikke udregnes — du ved, at agenten gjorde noget, ikke om det skulle rettes.
- Lås nævneren, før du retter tælleren. Beslut, hvad der tæller som én handling i denne arbejdsgang — én sag, der er berørt, én opgave, der er skrevet — og hold den definition stabil på tværs af perioder, så en ændring i HIR afspejler agentens skøn og ikke en ændring i, hvordan du tæller.
- Mærk hver intervention med en grund. «Redigeret» siger næsten ingenting. «Redigeret: refundpolitik over $50 forkert anvendt» siger præcis, hvad der skal rettes næste gang. En kort, ensartet taksonomi gør en korrektionslog til en opgaveliste i stedet for en resultattavle.
- Følg eskaleringsandelen sammen med HIR, ikke i stedet for den. De to tal tilsammen siger, om et fald er fortjent eller lånt — se tendensskemaet ovenfor.
- Sæt et gulv, ikke et mål på nul. Beslut pr. arbejdsgang, hvordan en plausibel HIR over nul ser ud givet, hvor meget reel tvetydighed det flow indeholder, og behandl en rate, der falder et godt stykke under det gulv, som noget, der skal undersøges, ikke fejres.
- Rapportér HIR pr. arbejdsgang, aldrig som ét blandet tal for hele virksomheden. Et gennemsnit skjuler, hvilket flow der faktisk har fortjent mindre opsyn, og hvilket der stille samler risiko under en overskrift, der ser god ud.
- Tjek den «rene» stikprøve efter en plan. Træk med jævne mellemrum handlinger logget som uden behov for intervention, og lad nogen gennemgå dem uden at vide, at de var markeret rene. Det er det eneste direkte tjek af, om granskerne stadig læser.
Derfor er Loop Agent bygget omkring ask_human, resume og eskalering via kanalapps, snarere end omkring stille autonomi — en agent, der pauser for at spørge, er en agent, der med vilje dukker op i tælleren for din HIR, ikke en, der blev grebet ved et tilfælde. Eskaleringer og udkast kommer frem i de samme Grupper, hvor teamet allerede arbejder, ved siden af opgaver og noter, så det øjeblik, der havde brug for en person, er synligt dér, hvor arbejdet allerede lever — ikke begravet i en separat agentkonsol, som ingen tjekker. På Enterprise lader revisionslogs IT og drift se, hvad agenter gjorde, og præcis hvornår et menneske trådte til, og det er råmaterialet, HIR bygges af i første omgang.
Sæt det sammen med Læsbarhed — det ledsagende koncept, der også gør tildelinger og adgang synlige — og du har de to spørgsmål, enhver AI-udrulning skal kunne svare på, før den udvides: hvem kan se, hvad en agent gør, og hvor ofte har en person faktisk brug for at træde til.