Míra zásahu člověka: jediná metrika, která řekne, jestli váš rollout AI opravdu funguje
Většina firem, které provozují AI agenty v produkci, neumí říct, jak často ti agenti opravdu potřebují člověka. Míra zásahu člověka je číslo, které na tu otázku odpovídá — a na konci tohoto textu byste ji měli umět spočítat pro workflow, který už vedete.
Vlastní rámec FabricLoop pro AI organizace definuje míru zásahu člověka přímo: ptá se, jak často automatizovaná práce potřebuje člověka. To je definice a tento text se od ní neodchyluje. Dál je ta část, kterou stránka konceptu nerozepisuje celá: samotná aritmetika, použitá na jeden skutečný workflow, s čísly, která z myšlenky dělají něco konkrétního místo jen žádoucího.
Co to číslo ve skutečnosti měří
Míra zásahu člověka (MZČ) je podíl akcí agenta, v jednom vymezeném workflow a jednom období, u kterých musel člověk zasáhnout, než výsledek mohl platit jako hotový. «Zasáhnout» má tady konkrétní význam: člověk opravil výstup, přebil rozhodnutí, které agent udělal, nebo odpověděl na otázku, kterou agent výslovně položil, než bude pokračovat — to, čemu Loop Agent od FabricLoop říká okamžik ask_human. Vydělte počet těchto akcí celkovým počtem akcí, které agent ve stejném období udělal, a máte MZČ.
Tahle metrika si zaslouží místo vedle dostupnosti a přesnosti, ne pod nimi, protože měří něco, co ta čísla nevidí. Agent může mít na interním benchmarku 95% přesnost a pořád být horší rollout než ten s 80 %, pokud těch 5 %, ve kterých se mýlí, projde tiše, zatímco těch 20 %, u kterých si není jistý, se pokaždé označí. MZČ se neptá, jestli je agent dobrý. Ptá se, jestli systém ví, kdy potřebuje člověka, a jestli se člověk opravdu objeví, když to nastane. Tahle druhá otázka rozhoduje, jestli je rollout bezpečné rozšiřovat.
Výpočet MZČ pro jeden skutečný workflow
Vezměte workflow, který by tým IT nebo provozu mohl vést už dnes: agent třídí příchozí tikety podpory, klasifikuje je (fakturace, hlášení chyby, refundace, přístup k účtu a podobně) a sepíše první návrh odpovědi. Každý návrh spadne do fronty ke kontrole, než se dostane k zákazníkovi — nic neodchází samo. Samotný krok kontroly není zásah. Když recenzent klikne na «odeslat» u návrhu, který nepotřeboval změny, workflow funguje, jak byl navržen. Zásah je to, co se stane, když návrh potřeboval práci: recenzent ho přepsal, opravil klasifikaci, přesměroval tiket do jiné fronty, nebo se agent sám uprostřed úkolu zastavil a položil otázku, než cokoli sepsal.
Čísla níže jsou ilustrativní příklad, ne data skutečné firmy — ale tvar příběhu a aritmetika za ním jsou přesně to, co si postavíte z vlastních logů.
V pilotním měsíci se agent dotkne 640 tiketů. Z nich 415 potřebuje zásah — přepsání, překlasifikování nebo přesměrování — a jen 75 z těchto 415 jsou okamžiky, které agent označil sám, než cokoli sepsal. Zbytek jsou chyby, které recenzent chytí až potom. To je MZČ 64,8 % při podílu eskalací jen 18 %: agent se sebevědomě mýlí po většinu času, kdy se mýlí, a to je nejhorší podoba tohoto problému.
Tým vytáhne protokol oprav a každý zásah označí důvodem. Dominují dvě kategorie: agent špatně čte politiku refundací, jakmile se objeví částka, a píše klidné, procedurální odpovědi zákazníkům, kteří jsou viditelně naštvaní. Obojí se dá opravit bez sáhnutí na model — přidejte explicitní pravidlo, že každý tiket se zmínkou o refundaci nad $50 nebo se skóre sentimentu nad prahem spustí eskalaci ask_human místo návrhu. Všechno ostatní se dál sepisuje a kontroluje jako dřív.
| Měsíc | Zpracované tikety | Zásahy | MZČ | Podíl eskalací |
|---|---|---|---|---|
| 1 — Pilot | 640 | 415 | 64,8 % | 18 % |
| 2 — Po přidaných pravidlech | 810 | 224 | 27,7 % | 58 % |
| 3 — Pravidla znovu vyladěna | 940 | 101 | 10,7 % | 79 % |
Do třetího měsíce MZČ klesla o víc než 80 %, ale výmluvnější číslo je podíl eskalací: vystoupal z 18 % na 79 %. Většina toho, co zbývá, není agent přistižený při chybě — je to agent, který správně pozná opravdu nejednoznačný případ (účet VIP, výjimka z politiky, refundace přesně na prahu) a zeptá se, než jedná. Pokles je skutečný a zasloužený: každé kolo oprav se vrátilo do explicitních pravidel, takže konkrétní chyby, které je vyvolaly, se přestaly opakovat, zatímco kategorie, které pořád potřebují úsudek, se dál označují místo toho, aby se kolem nich psal návrh.
Pokles, na kterém záleží, je ten, ve kterém agent lépe ví, co neví — ne ten, ve kterém člověk tiše přestane kontrolovat.
Chyba: brát nulu jako cíl
Jakmile tým sleduje, jak MZČ měsíc po měsíci klesá, další zřejmá otázka je, jak nízko může jít. Instinkt je brát nulu jako cílovou čáru — důkaz, že agent je konečně dost dobrý na to, aby běžel bez dohledu. Ten instinkt je obrácený a je to nejčastější špatné čtení této metriky.
Workflow, který týdny ukazuje 0 % zásahů, skoro nikdy neznamená, že agent přestal dělat chyby. Znamená, že se stalo jedno ze dvou: recenzenti přestali návrhy před schválením opravdu číst, nebo se cesta eskalace tiše rozbila — prahy se uvolnily, pravidlo směrování selhalo bez hluku, nebo spoušť ask_human přestala pálit. Ať tak nebo tak, nula neříká, že systém přestal člověka potřebovat. Říká, že se člověka přestalo ptát, nebo že přestal koukat.
Skutečný cíl nikdy nebyl méně zásahů v abstrakci. Je to systém, ve kterém konkrétní okamžiky vyžadující úsudek člověka vyplavou na povrch — a jen ty okamžiky — aby pozornost člověka šla tam, kde je opravdu potřeba, místo aby se dělila rovnoměrně na všechno nebo chyběla úplně. Workflow na 12 % MZČ, kde skoro celých těch 12 % je agent správně označující opravdu nejednoznačné nebo vysoce rizikové případy, je zdravější než ten na 2 %, kde většina těch 2 % je recenzent, který zakopne o chybu, kterou agent nikdy neoznačil. Nižší číslo může schovat horší systém.
Přesně k tomu je podíl eskalací. Vedle MZČ vám řekne, v kterém příběhu jste:
Pokud MZČ klesá a podíl eskalací zůstává plochý nebo taky klesá, ještě to nezapisujte jako výhru. Vytáhněte náhodný vzorek akcí zapsaných jako «zásah nebyl potřeba» a nechte je někoho zkontrolovat naslepo, aniž byste řekli, že vzorek byl označen jako čistý. Podívejte se, jestli signály dál v řetězci — znovu otevřené tikety, stížnosti, zpětné vymáhání refundací, CSAT — ve stejnou dobu nestoupají. Klesající MZČ s rostoucími problémy dál v řetězci není systém, který se naučil rychleji. Je to systém, který nikdo nechytil včas.
Co instrumentovat, pokud to chcete měřit už dnes
Nic z toho nevyžaduje tolik nové nástroje jako záznam správné věci. Většina týmů s agentem už sleduje objem — kolika tiketů se dotkl, kolik úkolů sepsal. Skoro žádný nesleduje výsledek, a to je jediné, co MZČ opravdu potřebuje.
- Zaznamenejte výsledek každé akce, ne jen počítadlo aktivity. Odesláno beze změny, upraveno před odesláním, odmítnuto a přepsáno, nebo eskalováno samotným agentem. Bez logu na úrovni výsledku MZČ vůbec nejde spočítat — budete vědět, že agent něco udělal, ne jestli to bylo potřeba opravit.
- Nejdřív zafixujte jmenovatel, teprve pak čitatel. Rozhodněte, co se v tomhle workflow počítá jako jedna akce — jeden dotčený tiket, jeden sepsaný úkol — a držte tu definici stálou napříč obdobími, aby změna MZČ odrážela úsudek agenta, ne změnu způsobu počítání.
- Každý zásah označte důvodem. «Upraveno» neříká skoro nic. «Upraveno: špatně použitá politika refundací nad $50» říká přesně, co opravit dál. Krátká, stálá taxonomie změní protokol oprav v seznam práce, ne ve výsledkovou tabuli.
- Sledujte podíl eskalací vedle MZČ, ne místo ní. Obě čísla dohromady řeknou, jestli je pokles zasloužený, nebo vypůjčený — viz tabulka trendu výš.
- Nastavte podlahu, ne cíl nula. U každého workflow rozhodněte, jak vypadá věrohodná nenulová MZČ vzhledem k tomu, kolik skutečné nejednoznačnosti workflow obsahuje, a s mírou, která spadne výrazně pod tu podlahu, zacházejte jako s něčím k prošetření, ne k oslavě.
- Reportujte MZČ po workflow, nikdy jako jedno smíchané číslo za celou firmu. Jeden průměr schová, který konkrétní workflow si opravdu zasloužil méně dohledu a který tiše hromadí riziko pod dobře vypadajícím souhrnným číslem.
- Podle rozvrhu znovu kontrolujte «čistý» vzorek. Pravidelně vytahujte akce zapsané jako nevyžadující zásah a nechte je někoho zkontrolovat, aniž by věděl, že byly označeny jako čisté. Je to jediná přímá kontrola, jestli recenzenti pořád čtou.
Proto je Loop Agent postavený kolem ask_human, obnovení a eskalace přes aplikaci kanálu, ne kolem tiché autonomie — agent, který se zastaví, aby se zeptal, se v čitateli vaší MZČ objeví schválně, ne jako ten, kterého chytili náhodou. Eskalace a návrhy vyplavou ve stejných Groups, kde tým už pracuje, vedle úkolů a poznámek, takže okamžik, který potřeboval člověka, je vidět tam, kde práce už žije — ne zahrabaný v samostatné konzoli agenta, kterou nikdo nekontroluje. Na Enterprise auditní logy umožní IT a provozu vidět, co agenti udělali a přesně kdy člověk zasáhl, a z té suroviny se MZČ od začátku staví.
Dejte to dohromady s Čitelností — doprovodným konceptem, který dělá viditelnými i oprávnění a přístupy — a máte dvě otázky, na které by každý rollout AI měl umět odpovědět, než se rozšíří: kdo vidí, co agent dělá, a jak často musí člověk opravdu zasáhnout.