Рівень людського втручання: єдина метрика, яка показує, чи ваш запуск ШІ справді працює
Більшість компаній, які тримають ШІ-агентів у продакшені, не можуть сказати, як часто цим агентам насправді потрібна людина. Рівень людського втручання — це число, яке відповідає на це питання, і до кінця цього матеріалу ви маєте вміти порахувати його для робочого процесу, який уже ведете.
Власна рамка FabricLoop для ШІ-організацій визначає рівень людського втручання прямо: вона питає, як часто автоматизована робота потребує людини. Це і є визначення, і цей матеріал від нього не відходить. Далі — та частина, яку сторінка концепції не розписує повністю: сама арифметика, застосована до одного реального робочого процесу, з числами, які роблять ідею конкретною, а не лише бажаною.
Що це число насправді вимірює
Рівень людського втручання (РЛВ) — це частка дій агента в межах одного визначеного робочого процесу і одного періоду, для яких людині довелося втрутитися, перш ніж результат можна було вважати готовим. «Втрутитися» тут має конкретне значення: людина виправила результат, скасувала рішення агента або відповіла на питання, яке агент прямо поставив, перш ніж продовжити — те, що Loop Agent від FabricLoop називає моментом ask_human. Поділіть кількість таких дій на загальну кількість дій агента за той самий період — і отримаєте РЛВ.
Ця метрика стоїть поруч із доступністю та точністю, а не під ними, бо вимірює те, чого ті числа не бачать. Агент може показати 95% точності на внутрішньому бенчмарку і все одно бути гіршим запуском, ніж агент із 80%, якщо ті 5%, у яких він помиляється, проходять мовчки, а ті 20%, у яких він невпевнений, щоразу позначаються. РЛВ не питає, чи агент хороший. Він питає, чи система знає, коли їй потрібна людина, і чи людина справді з’являється, коли це стається. Саме це друге питання вирішує, чи запуск безпечно розширювати.
Як порахувати РЛВ для одного реального робочого процесу
Візьміть робочий процес, який команда IT або операцій могла б вести вже сьогодні: агент розбирає вхідні тікети підтримки, класифікує їх (оплата, звіт про помилку, повернення коштів, доступ до облікового запису тощо) і готує чернетку першої відповіді. Кожна чернетка потрапляє в чергу на перевірку, перш ніж дійти до клієнта — нічого не надсилається саме. Сам цей крок перевірки не є втручанням. Коли рецензент натискає «надіслати» на чернетці, якій не потрібні були зміни, робочий процес працює як задумано. Втручання — це те, що стається, коли чернетку треба було доопрацювати: рецензент переписав її, виправив класифікацію, перенаправив тікет в іншу чергу, або сам агент зупинився посеред завдання і поставив питання, перш ніж щось написати.
Числа нижче — ілюстративний приклад, а не дані реальної компанії. Але форма історії і арифметика за нею — саме те, що ви зберете з власних логів.
У пілотному місяці агент торкається 640 тікетів. З них 415 потребують втручання — переписування, перекласифікації чи перенаправлення — і лише 75 із цих 415 є моментами, які агент позначив сам, перш ніж щось написати. Решта — помилки, які рецензент ловить постфактум. Це РЛВ 64,8% при частці ескалацій лише 18%: агент упевнено помиляється більшість часу, коли помиляється, і це найгірший варіант цієї проблеми.
Команда витягує журнал виправлень і позначає кожне втручання причиною. Домінують дві категорії: агент неправильно читає політику повернень, щойно з’являється сума, і пише спокійні процедурні відповіді клієнтам, які явно розлючені. Обидва випадки можна виправити, не чіпаючи модель — додайте явне правило: будь-який тікет із поверненням понад $50 або з оцінкою настрою вище порога запускає ескалацію ask_human замість чернетки. Усе інше й далі пишеться і перевіряється як раніше.
| Місяць | Оброблено тікетів | Втручання | РЛВ | Частка ескалацій |
|---|---|---|---|---|
| 1 — Пілот | 640 | 415 | 64,8% | 18% |
| 2 — Після доданих правил | 810 | 224 | 27,7% | 58% |
| 3 — Правила знову підлаштовано | 940 | 101 | 10,7% | 79% |
До третього місяця РЛВ упав більш ніж на 80%, але промовистіше число — частка ескалацій: вона виросла з 18% до 79%. Більшість того, що лишилося, — не агент, якого спіймали на помилці, а агент, який правильно впізнає справді неоднозначний випадок (обліковий запис VIP, виняток із політики, повернення рівно на порозі) і питає, перш ніж діяти. Падіння справжнє, і воно заслужене: кожен раунд виправлень повернувся в явні правила, тож конкретні помилки, які їх породили, перестали повторюватися, а категорії, яким і далі потрібне судження, позначаються, а не обходяться чернеткою.
Падіння, яке має значення, — це те, у якому агент краще знає, чого він не знає, а не те, у якому людина тихо перестає перевіряти.
Помилка: вважати нуль метою
Щойно команда бачить, як РЛВ падає місяць за місяцем, наступне очевидне питання — наскільки низько він може впасти. Інстинкт — вважати нуль фінішем, доказом, що агент нарешті достатньо хороший, щоб працювати без нагляду. Цей інстинкт перевернутий, і це найпоширеніше хибне прочитання цієї метрики.
Робочий процес, який тижнями показує 0% втручань, майже ніколи не означає, що агент перестав помилятися. Це означає, що сталося одне з двох: рецензенти перестали справді читати чернетки перед затвердженням, або шлях ескалації тихо зламався — пороги послабили, правило маршрутизації мовчки відмовило, або тригер ask_human перестав спрацьовувати. У будь-якому разі нуль не каже, що системі більше не потрібна людина. Він каже, що людину перестали питати або що вона перестала дивитися.
Справжня мета ніколи не була в меншій кількості втручань узагалі. Це система, у якій конкретні моменти, що потребують судження людини, виходять на поверхню — і лише ці моменти, — щоб увага людини йшла туди, де вона справді потрібна, а не ділилася рівномірно на все або зникала зовсім. Робочий процес на 12% РЛВ, де майже всі ці 12% — агент, який правильно позначає справді неоднозначні або високі ставки, здоровіший за той, що сидить на 2%, де більшість цих 2% — рецензент, який натрапляє на помилку, яку агент ніколи не позначив. Нижче число може ховати гіршу систему.
Саме для цього існує частка ескалацій. Поруч із РЛВ вона каже, у якій ви історії:
Якщо РЛВ падає, а частка ескалацій лишається рівною або теж падає, ще не записуйте це як перемогу. Витягніть випадкову вибірку дій, позначених як «втручання не потрібне», і нехай хтось перегляне їх наосліп, не кажучи, що вибірку позначили чистою. Перевірте, чи сигнали далі по ланцюжку — повторно відкриті тікети, скарги, відкликання повернень, CSAT — у той самий час не повзли вгору. Падаючий РЛВ разом зі зростанням проблем далі по ланцюжку — це не система, яка навчилася швидше. Це система, яку ніхто не спіймав вчасно.
Що інструментувати, якщо хочете вимірювати це вже сьогодні
Для цього не так потрібні нові інструменти, як запис правильної речі. Більшість команд, які ведуть агента, вже рахують обсяг — скільки тікетів він торкнувся, скільки завдань накидав. Майже ніхто не фіксує результат, а саме він єдине, що РЛВ насправді потребує.
- Фіксуйте результат кожної дії, а не лише лічильник активності. Надіслано як є, відредаговано перед надсиланням, відхилено і переписано, або ескальовано самим агентом. Без журналу на рівні результату РЛВ взагалі не порахувати — ви знатимете, що агент щось зробив, а не чи це треба було виправити.
- Спершу зафіксуйте знаменник, а вже потім чисельник. Вирішіть, що для цього робочого процесу є однією дією — один зачеплений тікет, одне накидане завдання — і тримайте це визначення сталим між періодами, щоб зміна РЛВ відбивала судження агента, а не зміну способу підрахунку.
- Позначайте кожне втручання причиною. «Відредаговано» майже нічого не каже. «Відредаговано: хибно застосовано політику повернень понад $50» каже точно, що виправляти далі. Коротка стала таксономія перетворює журнал виправлень на список робіт, а не на табло.
- Стежте за часткою ескалацій поруч із РЛВ, а не замість нього. Два числа разом кажуть, чи падіння заслужене, чи позичене — див. таблицю тренду вище.
- Задайте підлогу, а не ціль нуль. Для кожного робочого процесу вирішіть, який правдоподібний ненульовий РЛВ виглядає з огляду на те, скільки в ньому справжньої неоднозначності, і ставтеся до показника, який падає значно нижче цієї підлоги, як до речі, яку треба розслідувати, а не святкувати.
- Звітуйте РЛВ за робочим процесом, ніколи як одне змішане число на всю компанію. Єдине середнє ховає, який саме процес справді заслужив менше нагляду, а який тихо накопичує ризик під гарним загальним показником.
- За розкладом переглядайте «чисту» вибірку. Періодично витягуйте дії, позначені як такі, що не потребують втручання, і нехай хтось перегляне їх, не знаючи, що їх позначили чистими. Це єдина пряма перевірка того, чи рецензенти досі читають.
Саме тому Loop Agent побудований навколо ask_human, відновлення і ескалації через застосунок каналу, а не мовчазної автономії — агент, який зупиняється, щоб запитати, навмисно потрапляє в чисельник вашого РЛВ, а не той, кого спіймали випадково. Ескалації і чернетки з’являються в тих самих Groups, де команда вже працює, поруч із завданнями і нотатками, тож момент, якому була потрібна людина, видно там, де робота вже живе, а не похований в окремій консолі агента, яку ніхто не перевіряє. На Enterprise журнали аудиту дають IT і операціям бачити, що зробили агенти і точно коли втрутилася людина — це і є сировина, з якої РЛВ будується від початку.
Поставте це поруч із Читабельністю — супутньою концепцією, яка робить видимими також доступи і дозволи, — і ви отримаєте два питання, на які кожен запуск ШІ має вміти відповісти, перш ніж розширюватися: хто бачить, що робить агент, і як часто людині справді треба втрутитися.