Коэффициент вмешательства человека: единственная метрика, которая показывает, работает ли внедрение ИИ на самом деле
Большинство компаний, которые запускают ИИ-агентов в продакшене, не могут сказать, как часто этим агентам на самом деле нужен человек. Коэффициент вмешательства человека — это число, которое отвечает на этот вопрос. К концу текста вы сможете посчитать его для рабочего процесса, который у вас уже идёт.
Собственная рамка FabricLoop для организаций с ИИ определяет коэффициент вмешательства человека прямо: он спрашивает, как часто автоматизированной работе нужен человек. Это и есть определение, и этот текст от него не отходит. Дальше — та часть, которую страница концепции не расписывает до конца: настоящий расчёт на одном реальном процессе, с числами, которые делают идею конкретной, а не только желательной.
Что это число на самом деле измеряет
Коэффициент вмешательства человека (HIR) — это доля действий агента внутри одного заданного процесса и одного периода, которым понадобилось, чтобы человек вмешался, прежде чем результат можно было считать завершённым. «Вмешаться» здесь значит конкретное: человек исправил вывод, отменил решение агента или ответил на вопрос, который агент явно задал, прежде чем продолжить — то, что Loop Agent в FabricLoop называет моментом ask_human. Поделите число таких действий на общее число действий агента за тот же период — и получите HIR.
Эта метрика стоит рядом с доступностью и точностью, а не под ними, потому что измеряет то, чего эти числа не видят. Агент может показать 95% точности на внутреннем бенчмарке и всё равно оказаться худшим внедрением, чем агент с 80%, если те 5%, в которых он ошибается, проходят молча, а те 20%, в которых он не уверен, помечаются каждый раз. HIR не спрашивает, хорош ли агент. Он спрашивает, знает ли система, когда ей нужен человек, и появляется ли человек, когда это происходит. Второй вопрос решает, можно ли безопасно расширять внедрение.
Как посчитать HIR для одного реального процесса
Возьмите процесс, который команда ИТ или эксплуатации может вести уже сегодня: агент сортирует входящие заявки в поддержку, классифицирует их (счета, отчёт об ошибке, возврат, доступ к аккаунту и так далее) и пишет черновик первого ответа. Каждый черновик попадает в очередь проверки, прежде чем дойдёт до клиента — ничего не уходит само. Сам шаг проверки вмешательством не является. Ревьюер, который нажимает «отправить» на черновике, не требовавшем правок, — это процесс, работающий так, как задуман. Вмешательство — это когда черновик нужно было доработать: ревьюер переписал его, исправил класс, перенаправил заявку в другую очередь, или сам агент остановился посреди задачи и задал вопрос, прежде чем что-либо написать.
Цифры ниже — поясняющий пример, а не данные реальной компании. Но форма истории и арифметика за ней — ровно то, что собирается из ваших собственных журналов.
В пилотный месяц агент касается 640 заявок. Из них 415 требуют вмешательства — переписать, переклассифицировать или перенаправить — и только 75 из этих 415 агент сам отметил до того, как что-либо написал. Остальное — ошибки, которые ревьюер ловит постфактум. Это HIR 64,8% при доле эскалаций всего 18%: когда агент ошибается, он чаще всего ошибается уверенно, и это худший вид этой проблемы.
Команда выгружает журнал правок и помечает каждое вмешательство причиной. Две категории доминируют: агент неверно читает политику возврата, как только в деле есть сумма в долларах, и пишет спокойные процедурные ответы клиентам, которые явно злы. И то и другое чинится без правки модели — добавьте явное правило: любая заявка, где упомянут возврат свыше $50 или балл тональности выше порога, запускает эскалацию ask_human, а не черновик. Всё остальное по-прежнему пишется и проверяется как раньше.
| Месяц | Заявок обработано | Вмешательства | HIR | Доля эскалаций |
|---|---|---|---|---|
| 1 — Пилот | 640 | 415 | 64,8% | 18% |
| 2 — После добавления правил | 810 | 224 | 27,7% | 58% |
| 3 — Правила снова подстроены | 940 | 101 | 10,7% | 79% |
К третьему месяцу HIR упал больше чем на 80%, но более информативное число — доля эскалаций: она выросла с 18% до 79%. Большая часть того, что осталось, — это не агент, которого поймали на ошибке, а агент, который верно узнаёт по-настоящему неоднозначный случай (VIP-аккаунт, исключение из политики, возврат ровно на пороге) и спрашивает, прежде чем действовать. Снижение настоящее и заслуженное: каждый круг правок возвращался в явные правила, поэтому конкретные ошибки, которые их породили, перестали повторяться, а категории, которым всё ещё нужно суждение, продолжают помечаться, а не обходиться черновиком.
Имеет значение то снижение, при котором агент лучше понимает, чего он не знает, — а не то, при котором человек тихо перестаёт проверять.
Ошибка: считать ноль целью
Когда команда месяц за месяцем видит, как HIR падает, следующий вопрос кажется очевидным: насколько низко он может опуститься. Инстинкт — считать ноль финишем, доказательством, что агент наконец стал достаточно хорош, чтобы работать без присмотра. Этот инстинкт перевёрнут, и это самое частое неверное чтение метрики.
Процесс, который неделями показывает 0% вмешательств, почти никогда не значит, что агент перестал ошибаться. Это значит, что случилось одно из двух: ревьюеры перестали по-настоящему читать черновики перед тем, как их утверждать, или путь эскалации тихо сломался — пороги ослабили, правило маршрутизации отказало без звука, или триггер ask_human перестал срабатывать. В любом случае ноль не говорит, что системе больше не нужен человек. Он говорит, что человека перестали спрашивать или что человек перестал смотреть.
Настоящая цель никогда не была в том, чтобы абстрактно уменьшить число вмешательств. Цель — система, в которой конкретные моменты, требующие суждения человека, становятся видимыми, и только они, чтобы внимание человека попадало туда, где оно действительно нужно, а не делилось поровну на всё или не отсутствовало вовсе. Процесс с HIR 12%, где почти все эти 12% — это агент, верно помечающий по-настоящему неоднозначные или высокорисковые случаи, здоровее процесса с HIR 2%, где большая часть этих 2% — ревьюер, наткнувшийся на ошибку, которую агент так и не пометил. Более низкое число может скрывать худшую систему.
Именно для этого нужна доля эскалаций. Рядом с HIR она говорит, в какой вы истории:
Если HIR падает, а доля эскалаций держится или тоже падает, пока не записывайте это как победу. Возьмите случайную выборку действий, помеченных как «вмешательство не нужно», и пусть кто-то пересмотрит их вхолодную, не зная, что выборку отметили как чистую. Проверьте, не ползут ли вверх сигналы ниже по потоку — переоткрытые заявки, жалобы, отзыв возвратов, CSAT. Падающий HIR при растущих проблемах ниже по потоку — это не система, которая учится быстрее. Это система, которую никто не поймал вовремя.
Что измерять, если хотите считать это уже сегодня
Для этого меньше нужны новые инструменты, чем запись правильной вещи. Большинство команд, которые ведут агента, уже считают объём — скольких заявок он коснулся, сколько задач набросал. Почти никто не считает исход, а именно исход и нужен HIR.
- Записывайте исход каждого действия, а не только счётчик активности. Отправлено как есть, отредактировано перед отправкой, отклонено и переписано или эскалировано самим агентом. Без записи на уровне исхода HIR вообще нельзя посчитать: вы знаете, что агент что-то сделал, но не знаете, нужно ли было это исправлять.
- Сначала зафиксируйте знаменатель, потом числитель. Решите, что для этого процесса считается одним действием — одна затронутая заявка, одна набросанная задача — и держите это определение постоянным между периодами, чтобы изменение HIR отражало суждение агента, а не смену способа счёта.
- Помечайте каждое вмешательство причиной. «Отредактировано» почти ничего не говорит. «Отредактировано: политика возврата свыше $50 применена неверно» говорит точно, что чинить дальше. Короткая устойчивая таксономия превращает журнал правок в список дел, а не в табло.
- Следите за долей эскалаций вместе с HIR, а не вместо него. Два числа вместе говорят, заслужено снижение или взято взаймы — см. таблицу тренда выше.
- Задайте пол, а не цель в ноль. Для каждого процесса решите, как выглядит правдоподобный ненулевой HIR с учётом того, сколько в нём настоящей неоднозначности, и считайте долю, которая падает сильно ниже этого пола, поводом для разбора, а не для праздника.
- Считайте HIR по каждому процессу, никогда одним смешанным числом на всю компанию. Среднее прячет, какой именно процесс действительно заслужил меньше надзора, а какой тихо копит риск под красивым заголовком.
- По расписанию перепроверяйте «чистую» выборку. Периодически вынимайте действия, записанные как не требующие вмешательства, и пусть кто-то пересмотрит их, не зная, что их пометили чистыми. Это единственная прямая проверка того, читают ли ревьюеры до сих пор.
Поэтому Loop Agent построен вокруг ask_human, resume и эскалации через приложения канала, а не вокруг тихой автономии: агент, который останавливается, чтобы спросить, — это агент, который нарочно попадает в числитель вашего HIR, а не тот, кого случайно поймали. Эскалации и черновики появляются в тех же группах, где команда уже работает, рядом с задачами и заметками, так что момент, которому был нужен человек, виден там, где работа и так живёт, а не закопан в отдельной консоли агента, в которую никто не заглядывает. На Enterprise журналы аудита дают ИТ и эксплуатации увидеть, что сделали агенты и в какой именно момент вмешался человек, — это и есть сырьё, из которого HIR собирается с самого начала.
Поставьте это рядом с прозрачностью — парной концепцией, которая делает видимыми также выдачи прав и доступ, — и у вас будут два вопроса, на которые каждое внедрение ИИ должно уметь ответить, прежде чем расширяться: кто может видеть, что делает агент, и как часто человеку на самом деле нужно вмешаться.