В статьях про эффективность ИИ регулярно попадаются красивые числа: чат-боты для поддержки окупаются на 200% за три-шесть месяцев, антифрод — на 300%, в среднем по отраслям операционные затраты падают на 20–30%.
Числа, возможно, честные. К вашему проекту они не имеют отношения ровно по одной причине: вы не знаете, что считали в числителе и что в знаменателе. Считали ли зарплаты высвобожденных людей, если никого не уволили? Включали ли стоимость поддержки на второй год? Мерили ли качество после того, как провайдер обновил модель?
Единственное число, которое что-то значит, — то, которое посчитали у вас и по правилу, записанному до начала работы.
Почему до начала
Потому что после начала мерить уже поздно.
Механика простая и неприятная. Внедрение прошло, все устали, кто-то спрашивает «ну как, сработало?». Дальше начинается подбор аргументов под уже существующее мнение. Тот, кто продавливал проект, найдёт улучшения. Тот, кто был против, найдёт проблемы. Оба будут правы, потому что критерия нет, а значит побеждает тот, кто настойчивее.
Есть и вторая причина, менее очевидная. Метрика, сформулированная заранее, меняет само внедрение. Когда вы знаете, что через три месяца будете смотреть на долю заявок, закрытых без человека, вы иначе проектируете фолбэк, иначе относитесь к отказам модели и иначе спорите о промпте. Метрика работает не только как отчёт, но и как техническое задание.
Что мерить
Годная метрика отвечает четырём условиям: считается автоматически, была измерима до внедрения, не зависит от чьего-то мнения, и на неё можно повлиять только тем, что вы делаете в проекте.
Рабочие варианты:
Доля потока, закрытая без человека. Самая честная и самая универсальная. Не «система обработала 90% обращений», а «90% ушли клиенту без участия оператора и не вернулись повторным обращением». Второе условие обязательно, иначе вы просто перенесли работу на следующий шаг.
Время от события до результата. От поступления документа до заполненной карточки, от заявки до назначенного исполнителя. Хорошо тем, что измеряется по данным, которые у вас уже есть, — значит, baseline можно снять задним числом.
Стоимость обработки одной единицы. В рублях, с учётом токенов, инфраструктуры и остаточного человеческого труда. Единственная метрика, которую можно положить рядом с фондом оплаты труда.
Доля честных отказов. Сколько раз система сказала «не знаю» вместо того, чтобы придумать ответ. Звучит как метрика неудачи, а на деле — метрика управляемости: отказ дёшев, уверенная ошибка дорога.
Чего мерить не надо: удовлетворённость команды, «скорость работы с системой», количество обработанных моделью запросов. Первые два — опросы, третье растёт само по себе и ничего не доказывает.
Как снять baseline, когда его никто не снимал
Обычная ситуация: процесс существует пять лет, никто никогда не мерил, сколько он занимает.
Три способа, по убыванию точности.
По данным, которые уже есть. Метки времени в CRM, тикеты, письма, логи. Если в системе видно, когда обращение пришло и когда по нему появился ответ, baseline восстанавливается за час SQL-запросом. Это лучший вариант, и он доступен чаще, чем думают.
Замер на неделю. Люди фиксируют, сколько раз в день делают операцию и сколько времени она занимает. Данные получатся завышенные по аккуратности и заниженные по объёму — люди забывают отмечать мелочи. Поправка на глаз в большую сторону.
Наблюдение за одним человеком за один день. Худший по точности и лучший по скорости. Порядок величины даёт, а порядок величины — это уже достаточно, чтобы решить, начинать или нет.
Важно: baseline снимается на реальном потоке, а не на «типичном случае». Типичный случай всегда быстрее среднего, потому что человек, который его описывает, вспоминает удобный пример.
Когда мерить результат
Не через неделю после запуска. Первая неделя показывает эффект новизны: люди внимательнее, поток аккуратнее, все смотрят.
Разумный горизонт — три месяца, с промежуточным замером на первом. Причина: качество LLM-контура не постоянно. Оно уезжает, когда меняется характер входных данных, когда провайдер обновляет модель, когда кто-то правит промпт ради одного случая. Метрика, снятая один раз, ничего не говорит о том, как система будет жить.
Отсюда практический вывод: дашборд с метрикой — часть поставки, а не приятное дополнение. Если считать надо руками, считать перестанут на третьей неделе.
Что делать с плохим результатом
Метрика не дотянула. Дальше есть три честных варианта и один нечестный.
Честные: доработать конкретное узкое место, если из логов видно, где именно теряется; сузить задачу до подмножества, где система работает, и оставить остальное людям; закрыть проект и вернуться к ручному процессу.
Нечестный: переопределить метрику задним числом. Он встречается чаще двух первых, и именно он превращает 95% пилотов в статистику из исследования MIT NANDA — формально всё внедрено, а измеримого эффекта нет.
Именно поэтому я записываю метрику в договор до начала работы. Не из любви к бюрократии, а потому что это единственный способ через три месяца иметь разговор о фактах, а не о том, чьё впечатление весомее.
И да, у этого правила есть неприятная для меня сторона: иногда цифра показывает, что сработало хуже ожидаемого. Это тоже результат, и он полезнее, чем удачно подобранная формулировка в отчёте.
